- Apr 24, 2024
-
-
Eric Engestrom authored
-
Eric Engestrom authored
-
As per spec we don't have to do anything with that flag. Cc: mesa-stable Part-of: <mesa/mesa!28873> (cherry picked from commit cd5c9870)
-
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: <mesa/mesa!28791> (cherry picked from commit 2d8686cc)
-
Eric Engestrom authored
-
- Apr 23, 2024
-
-
Closes: mesa/mesa#11050 CC: mesa-stable Part-of: <mesa/mesa!28867> (cherry picked from commit d0c4b914)
-
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 a2463ec2 ("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: a2463ec2 ("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: <mesa/mesa!28832> (cherry picked from commit dae6b6a2)
-
This fixes a test on vkd3d-proton commit 836446ce25 VKD3D_TEST_FILTER=test_typed_buffers_many_objects_dxil build/tests/d3d12 Fixes: f1c909ed ("nvk/nir: Add cbuf analysis to nvi_nir_lower_descriptors()") Part-of: <mesa/mesa!28844> (cherry picked from commit 6b22fff6)
-
src and dst can be integer types, and doing an f2f on such types messes up with the original value. Make sure we keep the original type when {up,down}sizing the src, dst and out values. Fixes: f3de2bd6 ("nir: Add blend lowering pass") Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io> Part-of: <mesa/mesa!28839> (cherry picked from commit 34ffa4cd)
-
Eric Engestrom authored
-
Eric Engestrom authored
-
There is no need to pin the ops into channels because these are 32 bit ops that can be executed independent from each other. Fixes: 79ca456b r600/sfn: rewrite NIR backend v2: grammar fixes (lorn10) Signed-off-by: Gert Wollny <gert.wollny@collabora.com> Part-of: <mesa/mesa!28840> (cherry picked from commit 2bb102f0)
-
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: 79ca456b r600/sfn: rewrite NIR backend Signed-off-by: Gert Wollny <gert.wollny@collabora.com> Part-of: <mesa/mesa!28840> (cherry picked from commit 07995b98)
-
This gives more freedom to schedule the group barrier and removes the need to add blocks around a barrier to keep the scheduler in check. This should avoid emitting some CF instructions. Closes: #11002 Fixes: fe881bf0 r600/sfn: move kill handling fully to scheduling v2: grammar fixes (lorn10) Signed-off-by: Gert Wollny <gert.wollny@collabora.com> Part-of: <!28840> (cherry picked from commit bf44ce61)
-
This is probably overdoing debendencies in many cases, but it fixes a bug where scheduling goes wrong. Closes: #10984 Fixes: ddb167e8 r600/sfn: Handle indirect array load/store dependencies better Signed-off-by: Gert Wollny <gert.wollny@collabora.com> Part-of: <!28840> (cherry picked from commit a61b658d)
-
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: 6b14da33 ("intel/fs: nir: Add nir_intrinsic_dpas_intel") Reviewed-by: Ivan Briano <ivan.briano@intel.com> Part-of: <mesa/mesa!28822> (cherry picked from commit 2ce558d9)
-
- Apr 22, 2024
-
-
this needs a separate allocation cc: mesa-stable Part-of: <mesa/mesa!28723> (cherry picked from commit 4b2fe347)
-
Occlusion queries don't go through L2 on GFX6-8, and waiting properly in shaders is more complicated to implement. Use the previous WAIT_REG_MEM logic on these GPUs to fix this. This fixes flickering on many games on GFX8. Closes: mesa/mesa#8954 Closes: mesa/mesa#9415 Fixes: d44651bf ("radv: wait for occlusion queries in the resolve query shader") Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com> Part-of: <mesa/mesa!28796> (cherry picked from commit e18cc3b3)
-
it's legal for a fs to write xyzw components separately, and this pass should handle such cases cc: mesa-stable Reviewed-by: Ivan Briano <ivan.briano@intel.com> Part-of: <mesa/mesa!28752> (cherry picked from commit 042b8a65)
-
cc: mesa-stable Part-of: <mesa/mesa!28815> (cherry picked from commit 160dd5bf)
-
cc: mesa-stable Part-of: <mesa/mesa!28815> (cherry picked from commit fd6468a5)
-
This fixes a number of regressions in Vulkan subgroups tests in CTS. Fixes: 97f5721b ('broadcom/compiler: needs_quad_helper_invocation enable PER_QUAD TMU access') cc: mesa-stable Reviewed-by: Jose Maria Casanova Crespo <jmcasanova@igalia.com> Part-of: <!28797> (cherry picked from commit 1070c9b0)
-
the unordered flags must be set after the barrier to avoid the scenario where the barrier checks buffer usage and resets the flags cc: mesa-stable Part-of: <mesa/mesa!28787> (cherry picked from commit 974b3ab9)
-
should be as simple as checking whether zink is being used cc: mesa-stable Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org> Part-of: <!28570> (cherry picked from commit 6f13b201)
-
if mesa is built without dri3 then dri3 should/can not be checked cc: mesa-stable Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org> Part-of: <!28570> (cherry picked from commit ff37271e)
-
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 40372bd7. 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: 40372bd7 ("panfrost: Implement a disk cache") Signed-off-by: Patrick Lerda <patrick9876@free.fr> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Part-of: <!28743> (cherry picked from commit 4f5e9a21)
-
b-frames can be considered as reference, so the NAL type should refer to reference type and either RASL or TRAIL depending on the irap_pic_flag. Fixes: 72f52329 ("vulkan/video: add a nal_unit lookup for hevc") Reviewed-by: Hyunjun Ko <zzoon@igalia.com> Part-of: <!28657> (cherry picked from commit 363a90d0)
-
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: <!28738> (cherry picked from commit c939111f)
-
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: <mesa/mesa!28406> (cherry picked from commit e3d123b7)
-
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: <!28740> (cherry picked from commit 97f5721b)
-
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: mesa/mesa#10960 Fixes: 6368c144 ("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: <mesa/mesa!28724> (cherry picked from commit 95dc34cd)
-
- Apr 21, 2024
-
-
this otherwise only checked the first component cc: mesa-stable Reviewed-by: Connor Abbott <cwabbott0@gmail.com> Part-of: <mesa/mesa!28751> (cherry picked from commit 98ce4a98)
-
Otherwise, the returned VA from vkGetBufferDeviceAddress() or via VK_EXT_device_address_binding_report doesn't match and applications would have to mask out. Cc: mesa-stable Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com> Part-of: <mesa/mesa!28652> (cherry picked from commit 7f608fc2)
-
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: e59a16bb ("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: <mesa/mesa!28710> (cherry picked from commit 4586451b)
-
Fixes: a13a07d1 ("lavapipe: add descriptor sets bindings for planar images") Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com> Part-of: <mesa/mesa!28697> (cherry picked from commit 8f5fb4e0)
-
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: 12a47b84 ("egl/dri2: trigger drawable invalidation from surface queries for zink") Part-of: <mesa/mesa!28707> (cherry picked from commit 223aedfa)
-
this should be more consistent with hardware driver behavior cc: mesa-stable Reviewed-by: Roland Scheidegger <sroland@vmware.com> Part-of: <mesa/mesa!28671> (cherry picked from commit ede4e4aa)
-
this should be more consistent with hardware driver behavior cc: mesa-stable Reviewed-by: Roland Scheidegger <sroland@vmware.com> Part-of: <mesa/mesa!28671> (cherry picked from commit 129bebd5)
-
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: 330d0607 ("gallium: remove pipe_index_buffer and set_index_buffer") Signed-off-by: Patrick Lerda <patrick9876@free.fr> Part-of: <mesa/mesa!28523> (cherry picked from commit 2b6993cb)
-