This was just broken because individual shaders were still stored
on-disk in many situations:
- for shader object, all compute/graphics shaders were stored
- for fast-GPL, graphics shaders were stored
- for pipeline binaries, when the create flag was used
- for rt capture/replay and ray history
This should stop storing unused binaries on-disk and save space.
Found this by inspection.
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32476>
We never split live ranges, so we don't need to store the location of
each live value when recording live outs, but the physreg assigned to a
register will still be clobbered when we reload it so we have to record
the original physreg and then make sure to use it when reloading the
live out.
We probably never encountered a case where we needed to reload live outs
in a loop before, but after enabling clustered subgroup reductions
dEQP-VK.subgroups.clustered.compute.subgroupclusteredmin_{i,u}64vec4_requiredsubgroupsize
hits this case and fails in RA validation without this fix.
Fixes: fa22b0901a ("ir3/ra: Add specialized shared register RA/spilling")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32468>
Commit 361f362258 ("dri: Unify createImage and createImageWithModifiers")
has introduced new behavior for drivers which don't support explicit
format modifiers. Before this commit, INVALID was not special-cased
and any call to dri_create_image() with one or more modifiers returned
NULL. After this commit, INVALID gained a special meaning: it indicates
that the implicit modifier is accepted by the caller. This is surprising
and is an API break.
This causes further API breaks: for instance, before this commit a BO
created via gbm_bo_create_with_modifiers() was guaranteed to always
return a non-INVALID modifier in gbm_bo_get_modifier().
This is inconsistent with gbm_dri_surface_create(): that function
treats INVALID as a bad entry in the modifier list, and fails if
it's the only acceptable modifier.
Additionally, drivers don't special-case INVALID and just ignore it
if they see it in a modifier list. This causes more inconsistencies.
For instance, let's say that a library user passes the modifier list
{ INVALID, FOO } to GBM. If a driver supports explicit modifiers and
doesn't support FOO for scanout, it'll return NULL. If a driver
doesn't support explicit modifiers, the current logic would return
a non-NULL BO with an INVALID modifier. This discrepency makes it
harder to reason about the system: half of the API ignores INVALID,
while the other half assumes INVALID indicates an implicit modifier.
To fix these issues, revert to the behavior before the commit, and
require use of the dedicated API without supplying any modifier for
implicit modifiers.
Signed-off-by: Simon Ser <contact@emersion.fr>
Fixes: 361f362258 ("dri: Unify createImage and createImageWithModifiers")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32396>
(cherry picked from commit 105fcb9cfd)
This reverts commit c49a71c03c.
It broke radeonsi.
GBM can't set __DRI_IMAGE_USE_BACKBUFFER if gbm itself doesn't use it as
a back buffer by rendering to it and calling SwapBuffers. If another
library uses it as a back buffer, that library should set
__DRI_IMAGE_USE_BACKBUFFER, not GBM. A different flag could be added
to indicate the behavior that the original commit expected.
Fixes: c49a71c03c - gbm: mark surface buffers as explicit flushed
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/11996
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32345>
(cherry picked from commit 1a7c54b840)
This allows `gbm_bo_get_offset()` to return the correct offset for e.g.
the second plane of a resource with the NV12 format. Crucially this
fixes direct scanout / hardware plane usage in Mutter and possibly other
clients.
While on it also add support for stride, modifier and n_planes queries.
The later two should not change in behavior and just safe a few CPU
cycles. The stride query support in theory fixes queries for multi-plane
formats, however in practice most/all currently used formats such as NV12,
P010 and YUV420 use the same stride for all planes.
Cc: mesa-stable
Acked-by: Rob Clark <robclark@freedesktop.org>
Signed-off-by: Robert Mader <robert.mader@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32282>
(cherry picked from commit 379de4cdce)
After the breaking commit, gbm_bo_create_with_modifiers({LINEAR}) returns
a BO with gbm_bo_get_modifier() = INVALID. This restores the functionality
and fixes most notably, hardware cursors for cards without modifiers.
Fixes#12039.
Fixes: 361f362258 ("dri: Unify createImage and createImageWithModifiers")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31725>
(cherry picked from commit 7d1a32fafd)
In certain cases, the hardware fails to properly process a mipmap level
of these special stencil and depth formats. This happens at width=16.
This change adds a software workaround.
Modifying the corresponding mipmap nblk_x, and the other related
values, could make the tests below to work. Anyway, this method
generates regressions.
This change was tested on palm and cayman and fixes the following tests:
spec/arb_framebuffer_object/framebuffer-blit-levels read stencil: fail pass
spec/arb_depth_buffer_float/fbo-clear-formats stencil/gl_depth32f_stencil8: fail pass
Cc: mesa-stable
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31957>
(cherry picked from commit ac78692be4)
This situation is happening, for instance, when the hardware is
using the type FMT_8_8_8_8 (4 bytes) while the software was
requesting a 3 bytes type. The width should be adjusted to the
expected hardware size; otherwise, the last vertex is lost.
Note: The rv770 didn't behave like this. This is definitely
a hardware change between these gpus.
This change was tested on palm and cayman. Here are the tests fixed:
spec/!opengl 2.0/gl-2.0-vertexattribpointer-size-3: fail pass
deqp-gles2/functional/draw/random/62: fail pass
deqp-gles2/functional/vertex_arrays/single_attribute/strides/buffer_0_32_byte3_vec4_dynamic_draw_quads_1: fail pass
deqp-gles2/functional/vertex_arrays/single_attribute/strides/buffer_0_32_short3_vec4_dynamic_draw_quads_1: fail pass
deqp-gles2/functional/vertex_arrays/single_attribute/strides/buffer_0_32_short3_vec4_dynamic_draw_quads_256: fail pass
deqp-gles3/functional/draw/random/117: fail pass
deqp-gles3/functional/vertex_arrays/single_attribute/strides/byte/buffer_stride32_components3_quads1: fail pass
deqp-gles3/functional/vertex_arrays/single_attribute/strides/short/buffer_stride32_components3_quads1: fail pass
deqp-gles3/functional/vertex_arrays/single_attribute/strides/short/buffer_stride32_components3_quads256: fail pass
Cc: mesa-stable
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32184>
(cherry picked from commit 81889f4d5c)
This change fixes the evergreen nonconformity issue on non-mipmap
textures when the minification and the magnification are not in
the same state.
This modification disables 5278436d67 when the minification and
the magnification are different. This fixes the nonconformity
without new regressions. Anyway, I was unable to reproduce
the issue described by 5278436d67 on palm and cayman.
This change was tested on cayman and palm. It fixes 84 deqp-gles2
tests and 128 deqp-gles3 tests:
deqp-gles2/functional/texture/filtering/2d/linear_nearest_*
deqp-gles2/functional/texture/filtering/2d/nearest_linear_*
deqp-gles2/functional/texture/filtering/cube/linear_nearest_*
deqp-gles2/functional/texture/filtering/cube/nearest_linear_*
deqp-gles2/functional/texture/vertex/2d/filtering/linear_nearest_*
deqp-gles2/functional/texture/vertex/2d/filtering/nearest_linear_*
deqp-gles2/functional/texture/vertex/cube/filtering/linear_nearest_*
deqp-gles2/functional/texture/vertex/cube/filtering/nearest_linear_*
deqp-gles3/functional/texture/filtering/2d/combinations/linear_nearest_*
deqp-gles3/functional/texture/filtering/2d/combinations/nearest_linear_*
deqp-gles3/functional/texture/filtering/2d_array/combinations/linear_nearest_*
deqp-gles3/functional/texture/filtering/2d_array/combinations/nearest_linear_*
deqp-gles3/functional/texture/filtering/3d/combinations/linear_nearest_*
deqp-gles3/functional/texture/filtering/3d/combinations/nearest_linear_*
deqp-gles3/functional/texture/filtering/cube/combinations/linear_nearest_*
deqp-gles3/functional/texture/filtering/cube/combinations/nearest_linear_*
deqp-gles3/functional/texture/vertex/2d/filtering/linear_nearest_*
deqp-gles3/functional/texture/vertex/2d/filtering/nearest_linear_*
deqp-gles3/functional/texture/vertex/2d_array/filtering/linear_nearest_*
deqp-gles3/functional/texture/vertex/2d_array/filtering/nearest_linear_*
deqp-gles3/functional/texture/vertex/3d/filtering/linear_nearest_*
deqp-gles3/functional/texture/vertex/3d/filtering/nearest_linear_*
deqp-gles3/functional/texture/vertex/cube/filtering/linear_nearest_*
deqp-gles3/functional/texture/vertex/cube/filtering/nearest_linear_*
Fixes: 5278436d67 ("r600: force LOD range to be only one value when mip.min filter is NONE")
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32185>
(cherry picked from commit 4d24995adb)
These fields are only valid in certain formats, so set them accordingly.
Note the check if !is_send is used because FORMAT_BASIC is reused for
SEND/SENDS in some platforms. If we start to see more cases like that,
we can create a new FORMAT for it.
The cond_modifier is trickier because on top of that, it is not valid
for 64-bit immediates in some platforms. Found when EU validation
complained about moving 64-bit immediates with higher bits.
Fixes: e4440df2d8 ("intel/brw: Add pred/cmod/sat to brw_hw_decoded_inst")
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32287>
(cherry picked from commit 1d704af515)
When we create a new swapchain to replace the one currently presenting on
a surface, we need to reset all these timing variables. Otherwise we can
lose track of corrections that were made for the old swapchain when we
delete undelivered presentation feedback results.
Also, we use these variables when queuing a presentation, but we also use
them in the dispatch code that can be called by WaitForPresent from another
thread. We need to protect these variables against concurrent usage.
This is all much easier to do when they're stored as part of the swapchain
instead of the surface, so just move them there and adjust the locking.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Fixes: c26ab1aee1 ("vulkan/wsi/wayland: Pace frames with commit-timing-v1")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32121>
(cherry picked from commit 2e49448a43)
