_mesa_sha1_format has a few remaining uses, so it's moved to build_id.c,
which is its last user.
Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@intel.com>
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40383>
blorp_copy() will soon start changing the format in a way which drivers
cannot rely on to do things like manage the texture cache (see iris).
Narrow down the scope of blorp_copy_get_formats() and
blorp_copy_get_color_format() such that the returned value can only be
trusted if compression would be enabled on each image.
By doing this (and adapting iris to reflect this), we'll get the
required flushes on the platforms which need
WaSamplerCacheFlushBetweenRedescribedSurfaceReads:
* On the platforms which need the workaround for all formats,
blorp_copy() will stick with the queried format on compressed
surfaces.
* On the platforms which need the workaround when switching from ASTC
and non-ASTC formats, blorp_copy() may actually change the queried
format on compressed surfaces. This is not a problem, because
surfaces which may be read with ASTC formats are not compressible.
Prevents gfx9 from failing tests under:
* KHR-GL46.copy_image.functional_src_target_texture_2d_array_src_format_r3_g3_b2*
* KHR-GL46.copy_image.functional_src_target_texture_2d_array_src_format_rgb5*
* KHR-GL46.copy_image.functional_src_target_texture_2d_array_src_format_rgba2*
* KHR-GL46.copy_image.functional_src_target_texture_2d_array_src_format_rgba4*
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39974>
We're going to be changing the surface format of images but need to
maintain a consistent render compression format to properly
encode/decode. Generalize and use the field that was previously specific
to ISL_AUX_USAGE_MC.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39974>
It was already computed in brw_shader::assign_curb_setup() so we can use it
in brw_assign_urb_setup().
There was a mismatch between assign_curb_setup() and brw_assign_urb_setup() when
push_sizes were not multiple of REG_SIZE, the first one was aligning every
push_sizes before sum it, while brw_assign_urb_setup() was only aligning the sum
of all push_size.
By luck the only places that did not had a push_size aligned to REG_SIZE only
had one push_size, so this was not an issue.
So here also fixing this mismatch and adding an assert to caught any future
mismatch.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39817>
We just read this from the NIR and store it in iris_compiled_shader,
there's no reason for the backend compiler to be involved.
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39926>
These days, our system value concept is just about iris_program
communicating to iris_state which values to upload into a UBO.
Nowhere in that process is the backend compiler involved, so it
doesn't make sense for there to be brw/elk mechanisms.
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39926>
iris needs this, but anv does not, and it's just a small wrapper around
common NIR lowering anyway. This also removes some brw/elk splitting.
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39926>
This drops native support for legacy GL's two-sided color feature
in favor of lowering it via nir_lower_two_sided_color(). Instead
of having a whole bunch of state management hassle to set up the
SBE unit to swizzle between the COL and BFC VUE slots, and have it
transparently deliver one or the other to the fragment shader, we
simply deliver both and insert a conditional select there:
(is-front-facing ? front color : back color)
This also works even for > 16 varyings, where swizzling via the SBE
unit isn't viable.
zink, asahi, freedreno, lima, panfrost, r600, v3d, and vc4 all use
this lowering rather than having native support. Only four games in
our shader-db even use this feature.
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38121>
Writing a back-face color but not a front-face color is undefined
behavior. We were trying to politely work around potential application
bugs, but this is not required to work, and other drivers don't do it.
Drop the extra complexity.
If we do find a broken application that needs this hack, then a better
way to handle it is to have brw_compute_vue_map set the slot for
VARYING_SLOT_BFC(n) to the slot for VARYING_SLOT_COL(n) when COL(n) is
unwritten. That way, this override is handled at shader compilation
time, and the run-time code can remain simple.
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38121>
The "override with a constant" handling appears to take precedence over
the "override with point sprite coordinates" handling. Because we were
overriding undefined inputs to <0, 0, 0, 1>, we needed to avoid this for
sprite coordinates, as they aren't written by a previous stage, but
shouldn't be overridden to zero.
Now that we've dropped that in the previous patch, there's no need to
special case sprite coordinates any longer.
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38121>
iris (and i965 before it) tried to to politely return <0, 0, 0, 1.0>
as the value of undefined FS inputs. anv, however, just returns the
value of the first FS input attribute. This makes iris match anv's
behavior, eliminating some overrides and simplifying the code.
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38121>
We no longer read the VUE header values in the fragment shader, instead
relying on the payload fields. So there's no need to do anything with
them here. (Note that OpenGL's rules for preserving exact values of
layer/viewport built-ins were relaxed a while back, allowing us to use
the payload fields directly. So this code might've been necessary in
the past, but it isn't now.)
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38121>
iris decides to do recompiles or not based on its own program keys,
not the brw or elk keys. So, it makes sense to handle the "why did
we have to recompile a new variant" debugging based on those keys as
well. It also unifies the code, eliminating a brw/elk split, so it's
actually less code.
Additionally, this was the only remaining user of the brw code, so we
can delete that, resulting in even larger cleanups.
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@intel.com>
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39839>
This simplifies some iris wrapping for multiple compilers and also
saves some space in the brw_compiler singleton.
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@intel.com>
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39839>
Having the named field allowed us to indicate that our code conditions
are referring to the specific decision about how we handle indirect
UBOs, rather than some other arbitrary hardware change.
Still, there's no need to store this in a singleton struct - we can
easily have a static inline bool that does the devinfo check for us.
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@intel.com>
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39839>
This is always set to true for elk platforms. No need for the option.
crocus also assumes that we take the sampler path. hasvk had support
for both paths (leftover from when the driver still supported Gfx12).
We started using HDC messages for indirect UBO access on Tigerlake
(Gfx12.x) because of cache reworks that made it more viable. On all
prior platforms, we used the sampler because it has additional L1/L2
caches that the dataport lacks. Additionally, Ivybridge and nearby
platforms had notoriously slow L3 access in some very common cases.
Note that we do use the dataport for constant-offset UBO access,
since we can combine many reads into larger block loads.
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@intel.com>
Acked-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39839>
Commit 2ef29502ed updated the compiler
to expect scratch addresses to be shifted by 6 regardless of platform,
and updated anv, but didn't update iris. Easy fix, copy paste change
from anv.
Fixes: 2ef29502ed ("brw: enable ex_bso for LSC_SS")
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39876>
blend_entries is already a uint32_t so its lenght should only be rt_dwords.
This fix invalid reads in the line below where the memcpy lenght is the
sizeof(blend_entries).
Valgrind warning:
==176211== Invalid read of size 2
==176211== at 0x485A7CF: memmove (vg_replace_strmem.c:1415)
==176211== by 0x810035C: iris_upload_dirty_render_state (iris_state.c:7643)
==176211== by 0x8141B5B: iris_upload_render_state (iris_state.c:9055)
==176211== by 0x8D19941: iris_simple_draw_vbo (iris_draw.c:195)
==176211== by 0x8D1A034: iris_draw_vbo (iris_draw.c:346)
==176211== by 0x7290116: tc_call_draw_single (u_threaded_context.c:3826)
==176211== by 0x7290116: batch_execute (u_threaded_context_calls.h:11)
==176211== by 0x7290116: tc_batch_execute (u_threaded_context.c:5344)
==176211== by 0x7281583: _tc_sync (u_threaded_context.c:744)
==176211== by 0x72868A2: tc_texture_map (u_threaded_context.c:2847)
==176211== by 0x6975C23: pipe_texture_map_3d (u_inlines.h:680)
==176211== by 0x697701C: st_ReadPixels (st_cb_readpixels.c:537)
==176211== by 0x68E97C4: read_pixels (readpix.c:1216)
==176211== by 0x68E97C4: _mesa_ReadnPixelsARB (readpix.c:1233)
==176211== by 0x68E9889: _mesa_ReadPixels (readpix.c:1248)
==176211== Address 0x1a792240 is 0 bytes after a block of size 144 alloc'd
==176211== at 0x484C7A8: malloc (vg_replace_malloc.c:446)
==176211== by 0x80A6829: iris_create_blend_state (iris_state.c:1815)
==176211== by 0x7282E2F: tc_create_blend_state (u_threaded_context.c:1408)
==176211== by 0x71F4FB0: cso_set_blend (cso_context.c:541)
==176211== by 0x695CE93: st_update_blend (st_atom_blend.c:351)
==176211== by 0x64C6C0B: st_validate_state (st_util.h:129)
==176211== by 0x64C6D91: st_prepare_draw (st_draw.c:88)
==176211== by 0x67F1D16: _mesa_draw_arrays (draw.c:1176)
==176211== by 0x67F2795: _mesa_DrawArrays (draw.c:1386)
==176211== by 0x4973339: stub_glDrawArrays (piglit-dispatch-gen.c:12483)
==176211== by 0x49ECF1C: piglit_draw_rect_from_arrays (piglit-util-gl.c:746)
==176211== by 0x49ED3A6: piglit_draw_rect_custom (piglit-util-gl.c:868)
==176211==
==176211== Invalid read of size 2
==176211== at 0x485A7C0: memmove (vg_replace_strmem.c:1415)
==176211== by 0x810035C: iris_upload_dirty_render_state (iris_state.c:7643)
==176211== by 0x8141B5B: iris_upload_render_state (iris_state.c:9055)
==176211== by 0x8D19941: iris_simple_draw_vbo (iris_draw.c:195)
==176211== by 0x8D1A034: iris_draw_vbo (iris_draw.c:346)
==176211== by 0x7290116: tc_call_draw_single (u_threaded_context.c:3826)
==176211== by 0x7290116: batch_execute (u_threaded_context_calls.h:11)
==176211== by 0x7290116: tc_batch_execute (u_threaded_context.c:5344)
==176211== by 0x7281583: _tc_sync (u_threaded_context.c:744)
==176211== by 0x72868A2: tc_texture_map (u_threaded_context.c:2847)
==176211== by 0x6975C23: pipe_texture_map_3d (u_inlines.h:680)
==176211== by 0x697701C: st_ReadPixels (st_cb_readpixels.c:537)
==176211== by 0x68E97C4: read_pixels (readpix.c:1216)
==176211== by 0x68E97C4: _mesa_ReadnPixelsARB (readpix.c:1233)
==176211== by 0x68E9889: _mesa_ReadPixels (readpix.c:1248)
==176211== Address 0x1a792242 is 2 bytes after a block of size 144 alloc'd
==176211== at 0x484C7A8: malloc (vg_replace_malloc.c:446)
==176211== by 0x80A6829: iris_create_blend_state (iris_state.c:1815)
==176211== by 0x7282E2F: tc_create_blend_state (u_threaded_context.c:1408)
==176211== by 0x71F4FB0: cso_set_blend (cso_context.c:541)
==176211== by 0x695CE93: st_update_blend (st_atom_blend.c:351)
==176211== by 0x64C6C0B: st_validate_state (st_util.h:129)
==176211== by 0x64C6D91: st_prepare_draw (st_draw.c:88)
==176211== by 0x67F1D16: _mesa_draw_arrays (draw.c:1176)
==176211== by 0x67F2795: _mesa_DrawArrays (draw.c:1386)
==176211== by 0x4973339: stub_glDrawArrays (piglit-dispatch-gen.c:12483)
==176211== by 0x49ECF1C: piglit_draw_rect_from_arrays (piglit-util-gl.c:746)
==176211== by 0x49ED3A6: piglit_draw_rect_custom (piglit-util-gl.c:868)
==176211==
Cc: stable
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39661>
This is the shader key for the fragment shader. Nobody even knows
what the windowizer/masker unit is or does anymore. Even on Gen4-6,
"fs" is still clearer. This makes the codebase easier to read.
This is only about 15 years overdue.
Acked-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39748>
This is the program data for the fragment shader. Nobody even knows
what the windowizer/masker unit is or does anymore. Even on Gen4-6,
"fs" is still clearer. This makes the codebase easier to read.
This is only about 15 years overdue.
Acked-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39748>
This started out as dynamic configuration for MSAA related state, but
has since expanded to cover many dynamic fragment shader options.
We rename it to intel_fs_config, similar to intel_tess_config, to
better indicate its purpose.
Acked-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39748>
Prepare Iris code for addition of virtio native context support by
open-coding drm prime ioctls instead of using libdrm helpers. This
is needed by virtio to be able to override the ioctls implementation.
Suggested-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Acked-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29870>
Check whether userptr UAPI presents and disable userptr features if not.
Kernel i915 driver has config option that disables userptr ioctl. The
ioctl also may not present in a case of virtio native context driver.
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@intel.com>
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29870>
This is to make sure early culling related Wa_16020518922 is enabled
properly.
Cc: mesa-stable
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39712>
I noticed we disable the prefetch only on Gfx12.5. But surely that
recommendation carries on on later platforms.
It seems other drivers just disable it all the time and only have an
option to force the prefetch. So implementing the same thing here.
Blorp path is left untouched.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39424>
On Xe2+, HSD 14011946253 and the related documents explain that MCS
still only supports a single clear color.
Fixes: df006bba02 ("iris: Update aux state for color fast clears (xe2)")
Reviewed-by: Jianxun Zhang <jianxun.zhang@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37660>
When changing the clear color without a fast clear, use dirty bits to
ensure that surfaces with inline clear colors are updated and that
partial resolves are done as needed.
Remove the flags at the bottom of fast_clear_color() as
blorp_fast_clear() already sets them for us.
Fixes: 64d861b700 ("iris: Skip some fast-clears even on color changes")
Reviewed-by: Jianxun Zhang <jianxun.zhang@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37660>
Since this does most of the work to determine the right aux usage for
a depth texture, turn it into a helper that returns that aux usage in
order to avoid duplication of logic between it and its callers.
Suggested-by: Nanley Chery <nanley.g.chery@intel.com>
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31139>
This appears to be needed to guarantee that a resolved depth surface
has no remaining fast-cleared blocks on DG2 as well as MTL. After
this series this should no longer be hit in practice since we'll be
doing partial resolves in most cases, but it seems sensible to keep
and correct the workaround for our peace of mind to make sure that
full resolves are truly resolving the main surface.
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31139>
v2: Define additional enum BLORP_OP_HIZ_PARTIAL_RESOLVE to track
partial resolves (Nanley).
v3: Add comment regarding fall back to full resolve on Gfx12.0 (Nanley).
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31139>
This works around graphics corruption seen on MTL and DG2 platforms
when sampling from a HIZ-CCS depth surface that was previously fast
cleared and resolved for sampling. Apparently full resolves no longer
guarantee that the CCS surface ends up in a pass-through state due to
the behavior of the L3 cache in presence of compressible data. In
order to work around the problem this makes sure that we use a
CCS-enabled AUX mode for depth textures if the base surface has a CCS
control surface, even if we are instructed to use ISL_AUX_USAGE_NONE.
This appears to fix the corruption without the need to add extra L3
flushes after resolves (as was done in the Vulkan driver, see
5178ad761c).
v2: Use ISL_AUX_USAGE_HIZ_CCS_WT instead of ISL_AUX_USAGE_HIZ_CCS
usage to represent the requirements of sampling from a depth
surface (Nanley).
v3: Add some comments, remove redundant check, disallow creation of
ISL_AUX_USAGE_NONE surface state for depth sampler views since the
hardware is buggy (Nanley).
v4: Preserve use of ISL_AUX_STATE_CLEAR when fast-clearing a surface
(Nanley).
v5: Set ISL_AUX_STATE_COMPRESSED_NO_CLEAR state after clearing a HiZ
CCS WT resource on xe2+ (Nanley).
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31139>
The clear color state has to be allocated since we will be sampling
from non-WT HiZ CCS depth surfaces without disabling compression.
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31139>
Add a new PIPE_CAP_CLEAR_MASKED capability that allows drivers to
handle buffer clears with color and stencil masks directly, instead
of falling back to drawing a quad in Mesa.
This patch introduces several changes:
1. Add the new pipe cap PIPE_CAP_CLEAR_MASKED to pipe_defines.h and
document it in the Gallium screen documentation.
2. Add color_clear_mask and stencil_clear_mask parameters to the
pipe_context::clear() hook:
- color_clear_mask (uint32_t): contains 4 color mask bits per draw buffer
(max 8 buffers = 32 bits)
- stencil_clear_mask (uint8_t): contains the stencil write mask (8 bits)
3. Update the state tracker to use the masked clear path when the
driver supports it:
- Pass ctx->Color.ColorMask for color buffer clears
- Pass ctx->Stencil.WriteMask for stencil clears
- Allow both color and stencil clears to avoid the quad path when
masks are present and the driver advertises support
4. Update all existing driver clear() hooks to accept the new
color_clear_mask and stencil_clear_mask parameter.
This optimization allows drivers that can efficiently handle masked
clears in hardware to do so, improving performance for applications
that frequently clear buffers with masks enabled.
Signed-off-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31512>
BSpec 46969 (r45602) tells us that we get no fast-clears for 3D:
3D/Volumetric surfaces do not support Fast Clear operation.
For Y-tiled surfaces, we work around this in BLORP with
convert_rt_from_3d_to_2d(). However, that function doesn't support Ys-tiling.
We could modify our surface redescription code paths to support clearing
entire Ys tiles, but we choose to hold off on the added complexity until
we have a use-case.
Reviewed-by: Rohan Garg <rohan.garg@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38063>
We'll use isl_surf_supports_ccs() in a scenario in which we want to
check for CCS support without creating a HIZ or MCS surface beforehand.
Reviewed-by: Rohan Garg <rohan.garg@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38063>
Allow them in all cases except for one which prevents
dEQP-GLES31.functional.image_load_store.3d.atomic.xor_r32i_return_value
from hitting the following assertion on TGL:
convert_rt_from_3d_to_2d:
Assertion `!isl_tiling_is_std_y(info->surf.tiling)' failed.
Reviewed-by: Rohan Garg <rohan.garg@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38063>
GL only allows atomics on R32 formats. So, for a shader which does
atomic operations, only decompress the bound R32-formatted images
instead of every image.
Aside from the performance improvement, explicitly limiting the formats
here makes it clear which formats may be resolved on gfx12.0. This helps
us to limit the scope of the Ys + 3D-dim restriction that will be added
in the next patch.
Reviewed-by: Rohan Garg <rohan.garg@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38063>
