Bspec 57023: RENDER_SURFACE_STATE:: Shader Channel Select Red
"Render Target messages do not support swapping of colors with
alpha. The Red, Green, or Blue Shader Channel Selects do not
support SCS_ALPHA. The Shader Channel Select Alpha does not support
SCS_RED, SCS_GREEN, or SCS_BLUE."
Cc: mesa-stable
Signed-off-by: Sagar Ghuge <sagar.ghuge@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28791>
(cherry picked from commit 2d8686ccd5)
We track stencil clears and writes to optimize them. Unfortunately, the
code for doing this tracks the whole resource, not individual layers or
levels within the resource, which can result in incorrect output when
different levels or layers are accessed. Modified to optimize only the first
layer/level; this will handle the common case of a single stencil texture
while allowing arrays or mipmaps to still work (albeit slightly slower).
The original optimization was introduced in a2463ec271 ("panfrost:
Constant stencil buffer tracking") but the code has been reformatted
since then, so this change won't apply as-is that far back (although it's
fairly obvious how to apply it by hand).
Fixes: a2463ec271 ("panfrost: Constant stencil value tracking")
Signed-off-by: Eric R. Smith <eric.smith@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28832>
(cherry picked from commit dae6b6a23d)
Since the group is created from the onset, we have to make
sure that four or eight src values don't have a readport
conflict, so force a pre-loading of the values to registers
evenly distributed over the channels and let copy-propagation
take care of cleaning up un-neccesary moves.
Fixes: 79ca456b48
r600/sfn: rewrite NIR backend
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28840>
(cherry picked from commit 07995b98a8)
For integer types, the signedness is determined by flags on the muladd
instruction. The types of the sources play no role. Previously we were
using the signedness of the type and ignoring the mask.
Adjust the types passed to the dpas_intel intrinsic to match.
Fixes various
dEQP-VK.compute.*.cooperative_matrix.khr_*.matrixmuladd_cross.* tests on
different Intel platforms. Some platforms had failing tests, and some
platforms failed EU validation before the tests could fail.
Fixes: 6b14da33ad ("intel/fs: nir: Add nir_intrinsic_dpas_intel")
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28822>
(cherry picked from commit 2ce558d928)
The pointer "xfb" is allocated with a clone of "so->nir" and lost
without further processing.
The function panfrost_shader_compile() was the one processing "xfb".
The call of this function was removed with the commit 40372bd720.
This makes "xfb" not required anymore.
For instance, this issue is triggered on a Mali-T820 with
"piglit/bin/arb_transform_feedback2-change-objects-while-paused -auto":
Indirect leak of 32776 byte(s) in 1 object(s) allocated from:
#0 0xf78f30a6 in malloc (/usr/lib/libasan.so.6+0x840a6)
#1 0xee9cd4ee in ralloc_size ../src/util/ralloc.c:118
#2 0xee9cf7ae in create_slab ../src/util/ralloc.c:801
#3 0xee9cf7ae in gc_alloc_size ../src/util/ralloc.c:840
#4 0xef74ab82 in nir_undef_instr_create ../src/compiler/nir/nir.c:888
#5 0xef76212c in clone_ssa_undef ../src/compiler/nir/nir_clone.c:328
#6 0xef76212c in clone_instr ../src/compiler/nir/nir_clone.c:438
#7 0xef7642d8 in clone_block ../src/compiler/nir/nir_clone.c:501
#8 0xef7642d8 in clone_cf_list ../src/compiler/nir/nir_clone.c:555
#9 0xef7657dc in clone_function_impl ../src/compiler/nir/nir_clone.c:632
#10 0xef766cb8 in nir_shader_clone ../src/compiler/nir/nir_clone.c:743
#11 0xf007673e in panfrost_create_shader_state ../src/gallium/drivers/panfrost/pan_shader.c:434
#12 0xeeb6766c in st_create_common_variant ../src/mesa/state_tracker/st_program.c:781
#13 0xeeb71d1c in st_get_common_variant ../src/mesa/state_tracker/st_program.c:834
#14 0xeeb72ea2 in st_precompile_shader_variant ../src/mesa/state_tracker/st_program.c:1320
#15 0xeeb72ea2 in st_finalize_program ../src/mesa/state_tracker/st_program.c:1421
#16 0xef3806ec in st_link_glsl_to_nir ../src/mesa/state_tracker/st_glsl_to_nir.cpp:748
#17 0xef3806ec in st_link_shader ../src/mesa/state_tracker/st_glsl_to_nir.cpp:984
#18 0xef2992f6 in link_program ../src/mesa/main/shaderapi.c:1336
#19 0xef2992f6 in link_program_error ../src/mesa/main/shaderapi.c:1445
Fixes: 40372bd720 ("panfrost: Implement a disk cache")
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28743>
(cherry picked from commit 4f5e9a21c5)
panfrost_initialize_surface is called when a surface is written to,
and marks that surface as valid. If the surface is a depth buffer
with a separate stencil, that separate stencil should also be marked
as valid; otherwise, readpixel will skip reading it (and hence the
stencil data will be read as uninitialized). This only affects
DEPTH32F_STENCIL8 formats.
Cc: mesa-stable
Signed-off-by: Eric R. Smith <eric.smith@collabora.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28738>
(cherry picked from commit c939111f3f)
Remove a premature optimization. When PIPE_MAP_DISCARD_WHOLE_RESOURCE
is set we were setting create_new_bo, and then if that was set we skipped
a set of tests which if passed would cause a panfrost_flush_writer.
In fact we need that flush in some cases (e.g. when any batch is
reading the resource). Moreover, we should sometimes copy the resource
(set the copy_resource flag) and that again was being skipped if
create_new_bo was initially true due to PIPE_MAP_DISCARD_WHOLE_RESOURCE
being set.
Cc: mesa-stable
Signed-off-by: Eric R. Smith <eric.smith@collabora.com>
Acked-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28406>
(cherry picked from commit e3d123b7a6)
We take advantage of the needs_quad_helper_invocation information to
only enable the PER_QUAD TMU access on Fragment Shaders when it is needed.
PER_QUAD access is also disabled on stages different to fragment shader.
Being enabled was causing MMU errors when TMU was doing indexed by vertexid
reads on disabled lanes on vertex stage. This problem was exercised by some
shaders from the GTK new GSK_RENDERER=ngl that were accessing a constant buffer
offset[6], but having PER_QUAD enabled on the TMU access by VertexID was
doing hidden incorrect access to not existing vertex 6 and 7 as TMU was
accessing the full quad.
cc: mesa-stable
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28740>
(cherry picked from commit 97f5721bfc)
The device->using_sparse variable is only used at cmd_buffer_barrier()
to decide if we need to apply the heavier-weight flushes that are only
applicable to sparse resources. The big problem here is that we need
to apply the flushes to the non-image and non-buffer memory barriers,
so we were trying to limit those only to applications that ever submit
a sparse resource to the sparse queue.
The reason why we were applying this only to devices that ever
submitted sparse resources is that dxvk games have this thing where
during startup they create and then delete tiny sparse resources, so
switching device->using_sparse to true at resource creation would make
basically every dxvk game start applying the heavier-weight
workaround.
The problem with all that is that even if an application creates a
sparse resource but doesn't ever bind them, the resource should still
behave as an unbound resource (because they are bound with a NULL
bind), so the flushes affecting them should happen. This case is
exercised by vkd3d-proton/test_buffer_feedback_instructions_sm51.
In order to satisfy all the above cases and only really apply the
heavier-weight flushes to applications actually using sparse
resources, let's just count the number of sparse resources that
currently exist and then apply the workaround only if it's not zero.
That covers the dxvk case since dxvk deletes the resources as soon as
they create, so num_sparse_resources goes back to 0.
Testcase: vkd3d-proton/test_buffer_feedback_instructions_sm51
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/10960
Fixes: 6368c1445f ("anv/sparse: add the initial code for Sparse Resources")
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28724>
(cherry picked from commit 95dc34cd97)
Since DGC preprocessing for IBO is supported, the driver generates
an indexed indirect draw but SQTT markers were missing and this
introduced complete non-sense in RGP captures.
Fixes: e59a16bbb8 ("radv: use an indirect draw when IBO isn't updated as part of DGC")
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28710>
(cherry picked from commit 4586451b2d)
I'm not sure why zink would want dri2 here instead of kopper,
I'm sure it's some side effect of something else, let zink
use the kopper paths.
This fixes:
dEQP-GL45-ES3.info.vendor
on zink on nvk with GL cts using EGL.
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Fixes: 12a47b84b7 ("egl/dri2: trigger drawable invalidation from surface queries for zink")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28707>
(cherry picked from commit 223aedfa5d)
Indeed, the pointer processed by r300_upload_index_buffer() was not the right one.
This is the reason why "deqp-gles2 --deqp-case=dEQP-GLES2.functional.draw.draw_elements.indices.user_ptr.index_byte"
was failing (the logs are below). This change corrects this issue and makes the related deqp tests work properly.
This change considers that r300_upload_index_buffer() sets indexBuffer to NULL. The indexBuffer resource
should be properly freed once the buffer is processed. This is required to avoid another refcnt imbalance
(another kind of memory leak).
==9962==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200000721f at pc 0x7fd57b54a9a0 bp 0x7fffd2c39290 sp 0x7fffd2c38a40
READ of size 30 at 0x60200000721f thread T0
#0 0x7fd57b54a99f in __interceptor_memcpy (/usr/lib64/libasan.so.6.0.0+0x3c99f)
#1 0x7fd570d10528 in u_upload_data ../src/gallium/auxiliary/util/u_upload_mgr.c:333
#2 0x7fd57114142b in r300_upload_index_buffer ../src/gallium/drivers/r300/r300_screen_buffer.c:44
#3 0x7fd57113943c in r300_draw_elements ../src/gallium/drivers/r300/r300_render.c:632
#4 0x7fd57113bbc4 in r300_draw_vbo ../src/gallium/drivers/r300/r300_render.c:840
#5 0x7fd570d212e2 in u_vbuf_draw_vbo ../src/gallium/auxiliary/util/u_vbuf.c:1487
#6 0x7fd56fceb873 in _mesa_validated_drawrangeelements ../src/mesa/main/draw.c:1709
#7 0x7fd56fcf28c5 in _mesa_DrawElementsBaseVertex ../src/mesa/main/draw.c:1852
Fixes: 330d0607ed ("gallium: remove pipe_index_buffer and set_index_buffer")
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28523>
(cherry picked from commit 2b6993cb71)
Workaround states that if Destination Alpha Blend
Factor==BLENDFACTOR_ZERO, instead use BLENDFACTOR_CONST_ALPHA with the
constant alpha set to 0.
We had typo while setting the DestinationAlphaBlendFactor, use
BLENDFACTOR_CONST_ALPHA instead of BLENDFACTOR_CONST_COLOR.
Signed-off-by: Sagar Ghuge <sagar.ghuge@intel.com>
Cc: mesa-stable
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28640>
(cherry picked from commit 7cc604ed1b)
