| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
v2: update comments
Reviewed-by: Michel Dänzer <[email protected]>
Tested-by: Dieter Nützel <[email protected]>
|
|
|
|
|
|
|
|
| |
Bionic does not have pthread_setaffinity_np.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107869
Reviewed-by: Jose Fonseca <[email protected]>
Reviewed-by: Tapani Pälli <[email protected]>
|
|
|
|
| |
Reviewed-by: Bas Nieuwenhuizen <[email protected]>
|
|
|
|
| |
Acked-by: Bas Nieuwenhuizen <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Building of 32bit mesa with meson causes linkage issue:
"undefined reference to `util_get_process_name'"
Fixed by adding link-with mesa_util for xmlconfig primary.
v2: Removed '[]', commit message corrected.
v3: Reverted changes in gbm and glx libraries.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107843
Fixes: 2e1e6511f76370870b5cd "util: extract get_process_name from xmlconfig.c"
Cc: Marek Olšák <[email protected]>
Cc: Dylan Baker <[email protected]>
Signed-off-by: Sergii Romantsov <[email protected]>
Reviewed-by: Eric Engestrom <[email protected]>
Reviewed-by: Dylan Baker <[email protected]>
|
|
|
|
|
|
|
|
| |
We no longer need or use Visual Studio 2013.
https://ci.appveyor.com/project/jrfonseca/mesa/build/52
Reviewed-by: Roland Scheidegger <[email protected]>
|
|
|
|
|
|
|
|
|
| |
Spite using thrd_t types, these functions are wed to pthreads, and break
Windows builds, because thrd_current() is not implemented there, as it's
impossible to have an efficient thrd_current() implementation on
Windows.
Trivial.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When creating textures, we avoid creating backing-store for all
multisampled textures, not just depth buffers.
So we can't try to map them later. That's just going to fail. So
let's take the blit-based code-path that seems to avoid this problem.
This make this piglit test-case no longer crash (although it still
fails):
bin/copyteximage 2D -samples=2 -auto
Signed-off-by: Erik Faye-Lund <[email protected]>
Reviewed-by: Dave Airlie <[email protected]>
|
|
|
|
|
|
|
|
| |
We don't use the size we calculate in this function, so let's just
drop the calculation
Signed-off-by: Erik Faye-Lund <[email protected]>
Reviewed-by: Dave Airlie <[email protected]>
|
|
|
|
|
|
|
|
| |
We always return TRUE, and we never check the return-value. Let's
just drop the return value instead.
Signed-off-by: Erik Faye-Lund <[email protected]>
Reviewed-by: Dave Airlie <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
When we fail to map memory, we should also free trans to avoid
leaking memory.
Noticed while reading code.
Signed-off-by: Erik Faye-Lund <[email protected]>
Reviewed-by: Dave Airlie <[email protected]>
|
|
|
|
|
|
|
|
|
| |
As a prelude to handling large address spaces, first allow ourselves the
luxury of handling the full 4G.
Reported-by: Andrey Simiklit <[email protected]>
Cc: Kenneth Graunke <[email protected]>
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
| |
Reviewed-by: Brian Paul <[email protected]>
Reviewed-by: Roland Scheidegger <[email protected]>
Signed-off-by: Mathias Fröhlich <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
Introduce a new capability for the maximum value of
pipe_vertex_element::src_offset. Initially just every driver
backend returns the value previously set from _mesa_init_constants.
So this shall end up in no functional change.
Reviewed-by: Brian Paul <[email protected]>
Reviewed-by: Roland Scheidegger <[email protected]>
Signed-off-by: Mathias Fröhlich <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes the situation where we'd send a shader with just the
header and no data.
piglit/glsl-max-varyings test was causing this to happen, and
the renderer fix was breaking it.
v2: drop fprintf
Fixes: a8987b88ff1d "virgl: add driver for virtio-gpu 3D (v2)"
Reviewed-by: Erik Faye-Lund <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
This extension is required by "Wolfenstein: The Old Blood"
and is exposed in core in the Nvidia binary driver.
All the functions are just alias of the core functions so
there should be nothing more to do.
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
| |
This prevents radeonsi from running out of memory. It also increases
texture upload performance by being nice to the kernel memory manager.
|
| |
|
|
|
|
|
|
| |
This reverts commit 6d477bc5460eec14c6a0d047a0384c9ce5c7609b.
It fixes the Windows build hopefully.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Vulkan 1.1.81 spec says:
"It is legal for offset.x + extent.width or offset.y + extent.height
to exceed the dimensions of the framebuffer - the scissor test still
applies as defined above. Rasterization does not produce fragments
outside of the framebuffer, so such fragments never have the scissor
test performed on them."
Elsewhere, the Vulkan 1.1.81 spec says:
"The application must ensure (using scissor if necessary) that all
rendering is contained within the render area, otherwise the pixels
outside of the render area become undefined and shader side effects
may occur for fragments outside the render area. The render area
must be contained within the framebuffer dimensions."
Unfortunately, there's some room for interpretation here as to what the
consequences are of having the render area set to exactly the
framebuffer dimensions and having a scissor that is larger than the
framebuffer. Given that GL and other APIs provide automatic clipping to
the framebuffer, it makes sense that applications would assume that
Vulkan does this as well. It costs us very little to play it safe and
just clamp client-provided scissors to the framebuffer dimensions.
Fortunately, the user is required to provide us with at least one
scissor so we don't need to handle the case where they don't.
Fixes: fb2a5ceb3264 "anv: Emit DRAWING_RECTANGLE once at driver..."
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
I have no idea if I'm correct about what's going wrong or if this is the
correct fix. However, in my multiple weeks of banging my head on this
hang, a VUE reference counting bug seems to match all the symptoms and
it definitely fixes the hang.
Cc: [email protected]
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107280
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
| |
Known to fix nothing whatsoever but it's in the docs.
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
|
|
| |
Some of the bits of VERTEX_BUFFER_STATE such as access type, instance
data step rate, and pitch come from the pipeline.
Cc: [email protected]
Reviewed-by: Kenneth Graunke <[email protected]>
|
|
|
|
|
|
| |
v2: rebase
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
| |
v2: - use set_context_param
- set set_context_param even if the driver doesn't implement it
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
| |
v2: use set_context_param
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
|
|
| |
State trackers will not use the new param directly, but will instead use
a helper in MakeCurrent that does the right thing.
v2: rework the interface
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
| |
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
| |
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
According to:
https://support.amd.com/TechDocs/54945_PPR_Family_17h_Models_00h-0Fh.pdf
Also Intel:
https://www.microbe.cz/docs/CPUID.pdf
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
| |
Reviewed-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
and _mesa_bitcount_64 with util_bitcount_64. This fixes a build problem
in nir for platforms that don't have popcount or popcountll, such as
32bit msvc.
v2: - Fix additional uses of _mesa_bitcount added after this was
originally written
Acked-by: Eric Engestrom <[email protected]> (v1)
Acked-by: Eric Anholt <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently we have two sets of functions for bit counts, one in gallium
and one in core mesa. The ones in core mesa are header only in many
cases, since they reduce to "#define _mesa_bitcount popcount", but they
provide a fallback implementation. This is important because 32bit msvc
doesn't have popcountll, just popcount; so when nir (for example)
includes the core mesa header it doesn't (and shouldn't) link with core
mesa. To fix this we'll promote the version out of gallium util, then
replace the core mesa uses with the util version, since nir (and other
non-core mesa users) can and do link with mesautils.
Acked-by: Eric Engestrom <[email protected]>
Reviewed-by: Ian Romanick <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
gen9 hardware has a bug in the sampler cache that can cause GPU hangs
whenever an texture with aux compression enabled is in the sampler cache
together with an ASTC5x5 texture. Because we can't control what the
client binds at any given time, we have two options: resolve the CCS or
decompresss the ASTC. Doing a CCS or HiZ resolve is far less drastic
and will likely have a smaller performance impact.
Cc: [email protected]
Reviewed-by: Kristian H. Kristensen <[email protected]>
Tested-by: Tapani Pälli <[email protected]>
Reviewed-by: Topi Pohjolainen <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
There were two bugs working together to make things mostly work: I wasn't
dividing the VPM output size available by the size of a batch (vertex),
but I also had the size of the VPM reduced by a factor of 8.
Fixes dEQP-GLES3.functional.vertex_array_objects.all_attributes and it
seems also my intermittent varying failures.
Fixes: 1561e4984eb0 ("v3d: Emit the VCM_CACHE_SIZE packet.")
|
|
|
|
|
|
|
|
| |
Fixes
dEQP-GLES3.functional.fragment_ops.blend.default_framebuffer.rgb_func_alpha_func.dst.src_alpha_saturate_src_alpha_saturate
and friends with --deqp-egl-config-name=rgb565d0s0
Cc: "18.2" <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Lionel Landwerlin <[email protected]>
Reviewed-by: Jason Ekstrand <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
Building of 32bit mesa with meson causes issue:
"implicit declaration of function ‘__builtin_ia32_clflush’".
Fixed by adding msse2 compilation flag.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107843
Fixes: 314879f7fec0 (i965: Fix asynchronous mappings on !LLC platforms.)
Signed-off-by: Sergii Romantsov <[email protected]>
Reviewed-by: Lionel Landwerlin <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Seems in case of 32-bit library, usage of msse2 makes
some stack corruption or incorrect instructions.
Usage with mstackrealign fixes that case.
v2: Fixed meson.
v3: Definition of c_sse2_args moved on the top (L.Landwerlin).
Added mstackrealign for Android's mks where msee4.1 is used.
v4: Added for Vulkan also.
v5: Commit message correction.
CC: <[email protected]>
Fixes: 6b05c080f202 (i965: Compile with -msse3)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107779
Signed-off-by: Sergii Romantsov <[email protected]>
Reviewed-by: Dylan Baker <[email protected]>
Reviewed-by: Emil Velikov <[email protected]>
Reviewed-by: Lionel Landwerlin <[email protected]>
|
|
|
|
|
| |
Fixes: daa19363def gallium: split depth_clip into depth_clip_near & depth_clip_far
Signed-off-by: Rob Clark <[email protected]>
|
| |
|
|
|
|
| |
for AMD_depth_clamp_separate.
|
|
|
|
|
|
|
|
|
|
|
|
| |
The brw_vs_prog_data::double_inputs_read field comes directly from
shader_info::double_inputs which may contain inputs which are not
actually read. Instead of using it directly, AND it with inputs_read
which is only things which are read. Otherwise, we may end up
subtracting too many elements when computing elem_count.
Cc: [email protected]
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103241
Reviewed-by: Lionel Landwerlin <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It was very inconsistently handled; the only things that made use of it
were glsl_to_nir, glspirv, and nir_gather_info. In particular,
nir_lower_io completely ignored it so anyone using nir_lower_io on
64-bit vertex attributes was going to be in for a shock. Also, as of
the previous commit, it's set by every driver that supports 64-bit
vertex attributes. There's no longer any reason to have it be an option
so let's just delete it.
Reviewed-by: Alejandro Piñeiro <[email protected]>
Reviewed-by: Timothy Arceri <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We were going out of our way to disable dual-location re-mapping in NIR
only to then do the remapping in st_glsl_to_nir.cpp. Presumably, this
was so that double_inputs would be correct for the core state tracker.
However, now that we've it to gl_program::DualSlotInputs which is
unaffected by NIR lowering, we can let NIR lower things for us. The one
tricky bit here is that we have to remap the inputs_read bitfield back
to the single-slot convention for the gallium state tracker to use.
Since radeonsi is the only NIR-capable gallium driver that also supports
GL_ARB_vertex_attrib_64bit, we only have to worry about radeonsi when
making core gallium state tracker changes.
Acked-by: Marek Olšák <[email protected]>
Reviewed-by: Timothy Arceri <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, we had two field in shader_info: double_inputs_read and
double_inputs. Presumably, the one was for all double inputs that are
read and the other is all that exist. However, because nir_gather_info
regenerates these two values, there is a possibility, if a variable gets
deleted, that the value of double_inputs could change over time. This
is a problem because double_inputs is used to remap the input locations
to a two-slot-per-dvec3/4 scheme for i965. If that mapping were to
change between glsl_to_nir and back-end state setup, we would fall over
when trying to map the NIR outputs back onto the GL location space.
This commit changes the way slot re-mapping works. Instead of the
double_inputs field in shader_info, it adds a DualSlotInputs bitfield to
gl_program. By having it in gl_program, we more easily guarantee that
NIR passes won't touch it after it's been set. It also makes more sense
to put it in a GL data structure since it's really a mapping from GL
slots to back-end and/or NIR slots and not really a NIR shader thing.
Tested-by: Alejandro Piñeiro <[email protected]> (ARB_gl_spirv tests)
Reviewed-by: Alejandro Piñeiro <[email protected]>
Reviewed-by: Timothy Arceri <[email protected]>
|
|
|
|
| |
Reviewed-by: Roland Scheidegger <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
MSDN:
"va_end must be called on each argument list that's initialized
with va_start or va_copy before the function returns."
Reviewed-by: Eric Engestrom <[email protected]>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107810
Fixes: c6267ebd6c8a "gallium/util: Stop bundling our snprintf implementation."
Signed-off-by: Andrii Simiklit <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
We should exit from the function 'util_vasprintf'
with error code -1 for case where 'malloc'
returns NULL
Reviewed-by: Eric Engestrom <[email protected]>
Fixes: 864148d69e1e "util: add util_vasprintf() for Windows (v2)"
Signed-off-by: Andrii Simiklit <[email protected]>
|
|
|
|
|
|
|
|
| |
The first usage of the 'va_list' instance could change it.
Reviewed-by: Eric Engestrom <[email protected]>
Fixes: 864148d69e1e "util: add util_vasprintf() for Windows (v2)"
Signed-off-by: Andrii Simiklit <[email protected]>
|