Also ensure that 'needs_scratch_reg' is always true if SCC might be overwritten.
Few changes, because some p_split_vector get SCC as scratch reg assigned,
and thus, can inhibit some postRA optimizations.
Totals from 3 (0.00% of 79395) affected shaders: (Navi31)
Instrs: 10501 -> 10500 (-0.01%); split: -0.02%, +0.01%
CodeSize: 51580 -> 51520 (-0.12%); split: -0.12%, +0.01%
Latency: 84166 -> 84174 (+0.01%)
InvThroughput: 13109 -> 13111 (+0.02%)
SALU: 859 -> 860 (+0.12%)
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32217>
(cherry picked from commit a04e096339)
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/32227>
(cherry picked from commit 08c9dca8db)
If applications doesn't send any attributes to describe the format,
we would always use driver preferred format (NV12). This is wrong
for any RT format other than the driver preferred (YUV420).
Driver doesn't have a choice here, we must use the matching format.
Cc: mesa-stable
Reviewed-by: Leo Liu <leo.liu@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32089>
(cherry picked from commit c8a893becd)
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)
We assume everywhere that RGB is not planar, so sampling
and color space conversions will not work correctly with RGBP.
Drivers can still support RGBP, but processing entrypoint with
shaders doesn't support it.
Fixes: bdb7f36aa8 ("frontends/va: add support for RGBP rt_format")
Reviewed-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32252>
(cherry picked from commit 6c83f3c3bb)
Currently if you try to probe the virtio ICD on a non-virtio system
it will fail in CreateInstance which causes the loader to spit on the
screen.
However instance creation shouldn't fail, the driver should just
not enumerate any devices in this case. It's a bit tricky to ensure
this, but return instance and then handle instance destruction
and fail device enumeration.
Cc: mesa-stable
Reviewed-by: Ryan Neph
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32266>
(cherry picked from commit 25b8f4f714)
Instead of using unreliable polling to wait for foz db updater to parse
and load from the dynamic list, also use inotify to wait for foz db
updater close the list file after its done updating.
Fixes: 4dfd306454 ("disk_cache: Disable the "List" test for RO disk cache.")
Signed-off-by: Juston Li <justonli@google.com>
Reviewed-by: David Heidelberg <david@ixit.cz>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32237>
(cherry picked from commit cbb3bb5c7b)
For a TU_PIPELINE_GRAPHICS_LIB we were taking a ref to the descriptor
set layout but never releasing on VK_PIPELINE_COMPILE_REQUIRED.
Since VK_PIPELINE_COMPILE_REQUIRED is technically an error, the user
doesn't call vkDestroyPipeline() for it so the descriptor sets
referenced were never getting freed.
Addresses:
```
Direct leak of 304 byte(s) in 1 object(s) allocated from:
#0 0x7fa5a93ee0 in __interceptor_malloc
../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145
#1 0x7fa44bac84 in vk_default_alloc ../src/vulkan/util/vk_alloc.c:26
#2 0x7fa32ea5d8 in vk_alloc ../src/vulkan/util/vk_alloc.h:48
#3 0x7fa32ea60c in vk_zalloc ../src/vulkan/util/vk_alloc.h:56
#4 0x7fa32ea750 in vk_descriptor_set_layout_zalloc
../src/vulkan/runtime/vk_descriptor_set_layout.c:49
#5 0x7fa306fc98 in tu_CreateDescriptorSetLayout(VkDevice_T*,
VkDescriptorSetLayoutCreateInfo const*, VkAllocationCallbacks
const*, VkDescriptorSetLayout_T**)
../src/freedreno/vulkan/tu_descriptor_set.cc:161
```
and
```
Direct leak of 48 byte(s) in 1 object(s) allocated from:
#0 0x7f9b4b3ee0 in __interceptor_malloc
../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145
#1 0x7f9925e900 in ralloc_size ../src/util/ralloc.c:118
#2 0x7f9925e8d4 in ralloc_context ../src/util/ralloc.c:105
#3 0x7f98b4b214 in tu_pipeline_builder_build<(chip)7>
../src/freedreno/vulkan/tu_pipeline.cc:3898
#4 0x7f98b46bd8 in tu_graphics_pipeline_create<(chip)7>
../src/freedreno/vulkan/tu_pipeline.cc:4203
#5 0x7f98b22588 in VkResult
tu_CreateGraphicsPipelines<(chip)7>(VkDevice_T*,
VkPipelineCache_T*, unsigned int, VkGraphicsPipelineCreateInfo const*,
VkAllocationCallbacks const*, VkPipeline_T**)
../src/freedreno/vulkan/tu_pipeline.cc:4234
```
seen in:
dEQP-VK.pipeline.pipeline_library.shader_module_identifier.pipeline_from_id.graphics.4_variants.no_spec_constants.no_pipeline_cache.all_zeros_id.no_exec_properties.vert_tesc_tese_frag
Cc: mesa-stable
Signed-off-by: Karmjit Mahil <karmjit.mahil@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32188>
(cherry picked from commit 21baf2f6c1)
We updated maxImageDimension2D etc to report the actual max size, but we
forgot to update GetPhysicalDeviceImageFormatProperties in the same way.
Let's do that to make things consistent.
This fixes the following CTS test-case:
dEQP-VK.wsi.wayland.swapchain.create.image_extent
Fixes: d5ed77800e ("panvk: Fix GetPhysicalDeviceProperties2() to report accurate info")
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32221>
(cherry picked from commit 9c1de5c6b3)
On modern Mali GPUs, we can have 16 bits for the X and Y sizes, already
overflowing 32-bit barrier even with a single layer of byte-sized
formats.
So let's make sure we have enough bits to avoid overflows here.
Fixes: d5ed77800e ("panvk: Fix GetPhysicalDeviceProperties2() to report accurate info")
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32221>
(cherry picked from commit 00b25ec769)
If we have NIR such as:
32x4 %48 = @load_vulkan_descriptor (%47) (desc_type=SSBO)
32x4 %76 = deref_cast (tint_symbol_11 *)%48 (ssbo tint_symbol_11) (ptr_stride=0, align_mul=4, align_offset=0)
32x4 %77 = deref_struct &%76->tint_symbol_10 (ssbo int) // &((tint_symbol_11 *)%48)->tint_symbol_10
A single nir_rematerialize_deref_in_use_blocks() will rematerialize the
deref_struct and then it's deref_cast. However,
nir_foreach_instr_reverse_safe is not safe if the next iteration's
instruction is removed. This can result in the instruction loop exiting
and the load_vulkan_descriptor never having an LCSSA phi.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Fixes: 439e8c42cc ("nir/lcssa: Fix rematerializing derefs")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/11770
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32225>
(cherry picked from commit 65a54b4ec4)
The code wants the number of components used by the variable in the
current attribute slot, not the total number of components.
For e.g. a 4x3 matrix, glsl_get_components() returns 12, leading to the
following error reported by AddressSanitizer:
```
Test case 'dEQP-VK.tessellation.shader_input_output.cross_invocation_per_patch_mat4x3'..
../src/compiler/nir/nir_lower_io_to_vector.c:265:16: runtime error: index 4 out of bounds for type 'nir_variable *[4]'
```
Fixes: 5ef2b8f1f2 ("nir: Add a pass for lowering IO back to vector when possible")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32193>
(cherry picked from commit ba5c65f10b)
The game aliases two images. It binds a memory object to two different
images, the first one being an image with 4 mips and the second with
only one mip but the bind offset is incorrect. It's like it queried
the first image size with different usage flags, so that DCC was
disabled.
Force disabling DCC for mips fixes the incorrect rendering and doesn't
hurt performance.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/10200
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32190>
(cherry picked from commit 2f13723c0a)
In two functions implementing resource discard rebind_resource is called
on resource before its track record is reset. This prevents update of
dirty_resource or dirty_shader_resource because of conditions in
needs_dirty_resource. With rsc->track reset and dirty_resource bits
missing further calls to transfer_map will not try to reallocate
resource storage when needed.
A way to reproduce the issue in both functions is by executing at least
3 draws modifying bound texture or VBO each time. This patch fixes those
cases and some related piglit tests on a5xx and should fix it on other
GPUs. Also it fixes rendering in Firefox and vsraytrace (except vertical
line at right edge).
Fixes: 0a62a874fc ("freedreno: Re-work dirty-resource tracking")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/10374
Reviewed-by: Rob Clark <robclark@freedesktop.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32167>
(cherry picked from commit 6d14cad330)
We were accidentally doing a signed integer comparison here for ult32,
or a sign-extending shift for ushr.
One notable bit of fallout was that load_global_uniform_block_intel
address calculations broke on platforms that don't have native 64-bit
integer support, as the iadd64 lowering for "do I need to carry?" was
using ult32...and performing the wrong comparison. We spotted this in
Borderlands 3 on Alchemist once we turned on other optimizations.
Thanks to Lionel Landwerlin for helping spot the problem!
Fixes: c7b312ad45 ("brw: factor out source extraction for rematerialization")
Fixes: 339630ab05 ("brw: enable A64 loads source rematerialization")
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31995>
(cherry picked from commit 5848035443)
The BROADCOM_SAND128 modifier is usually used with an extra parameter
to pass in the stride via a side channel. Quoting from drm_fourcc.h:
> The pitch between the start of each column is set to optimally
> switch between SDRAM banks. This is passed as the number of lines
> of column width in the modifier (we can't use the stride value due
> to various core checks that look at it , so you should set the
> stride to width*cpp).
So apparently this is just a workaround for limitations in some kernel
APIs. DRM modifiers, however, are arguably a bad fit for extra
parameters that aren't known in advance. In the Wayland/KMS ecosystem
many components depend on being able to treat modifiers as opaque, e.g.
for negotiations etc. In practice the current approach requires various
software components to manually use the
`DRM_FORMAT_MOD_BROADCOM_SAND128_COL_HEIGHT()` macro - using the
`DRM_FORMAT_MOD_BROADCOM_SAND128` modifier directly with formats like
`NV12` results in a rejection in the KMS driver and corrupted output
in Mesa (because we'd bail out early in `v3d_sand8_blit()`).
Fortunately the stride check limitations mentioned above don't seem to
apply to Mesa though. Thus we can just add support for the base modifier
and stride (coming from V4L2), allowing various toolkits, Wayland
compositors and V4L2 decoder implementations to support e.g.
`NV12` + `DRM_FORMAT_MOD_BROADCOM_SAND128` (`NC12` in V4L2) in a generic
way.
Notes:
1. Wayland compositors trying to offload composition to KMS will still
fail when doing a test commit.
2. There is another limitation - in the V4L2 MPLANE API - that
requires userspace to know the correct offset of the second plane. That's
a known API limitation though and only affects V4L2 decoder implementations.
Cc: mesa-stable
Signed-off-by: Robert Mader <robert.mader@collabora.com>
Reviewed-by: Jose Maria Casanova Crespo <jmcasanova@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32033>
(cherry picked from commit 758941ab0c)
This fixes a corner case of the LNL sub-dword integer restrictions
that wasn't being detected by has_subdword_integer_region_restriction(),
specifically:
> if(Src.Type==Byte && Dst.Type==Byte && Dst.Stride==1 && W!=2) {
> // ...
> if(Src.Stride == 2) && (Src.UniformStride) && (Dst.SubReg%32 == Src.SubReg/2 ) { Allowed }
> // ...
> }
All the other restrictions that require agreement between the SubReg
number of source and destination only affect sources with a stride
greater than a dword, which is why
has_subdword_integer_region_restriction() was returning false except
when "byte_stride(srcs[i]) >= 4" evaluated to true, but as implied by
the pseudocode above, in the particular case of a packed byte
destination, the restriction applies for source strides as narrow as
2B.
The form of the equation that relates the subreg numbers is consistent
with the existing calculations in brw_fs_lower_regioning (see
required_src_byte_offset()), we just need to enable lowering for this
corner case, and change lower_dst_region() to call lower_instruction()
recursively, since some of the cases where we break this restriction
are copy instructions introduced by brw_fs_lower_regioning() itself
trying to lower other instructions with byte destinations.
This fixes some Vulkan CTS test-cases that were hitting these
restrictions with byte data types.
Fixes: 217d412360 ("intel/fs/gfx20+: Implement sub-dword integer regioning restrictions.")
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30630>
(cherry picked from commit 0ad835a929)
KernelCI jobs have priority 44 and are very long-running jobs (and
there might be an issue with the KernelCI that makes it create hundreds
of jobs, @sergi is looking into that).
While bumping to 45+ would be enough to allow Mesa release staging
pipelines to run despite the KernelCI, during the CI meeting with @sergi
and @mupuf it was determined that the Mesa releases are an important
enough operation to warrant being a higher priority than user forks
pipelines, so priority 70 was picked (still under the 75 of Marge
pipelines).
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32093>
(cherry picked from commit 50f9bec3ce)
Because dyn_start and dyn_end are indices into
nvk_root_descriptor_table->dynamic_buffers, we would need to offset
cbuf->dynamic_idx by
nvk_root_descriptor_table->set_dynamic_buffer_start[cbuf->desc_set]
in order to do those comparisons correctly.
We could do that, but it's simpler and no less precise to sinply
re-use the same comparison that we do in the other cases here.
This fixes a rendering artifact in Baldur's Gate 3 (Vulkan), which
regressed with the commit listed below.
Fixes: 091a945b57 ("nvk: Be much more conservative about rebinding cbufs")
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32086>
(cherry picked from commit dc12c78235)
The Early-Z optimization is disabled when there is a discard
instruction in the shader used in the draw call.
But if discard is the only reason to disable Early-Z, and at
draw call time the updates in the draw call are disabled we
can enable Early-Z using a shader variant.
If there are occlussion queries active we also need to disable
Early-z optimization.
So this patch enables Early-Z in this scenario.
The performance improvement is significant when running gfxbench
benchmark showing an average improvement of 11.15%
fps_avg helped: gl_gfxbench_aztec_high.trace: 3.13 -> 3.73 (19.13%)
fps_avg helped: gl_gfxbench_aztec.trace: 4.82 -> 5.68 (17.88%)
fps_avg helped: gl_gfxbench_manhattan31.trace: 5.10 -> 6.00 (17.59%)
fps_avg helped: gl_gfxbench_manhattan.trace: 7.24 -> 8.36 (15.52%)
fps_avg helped: gl_gfxbench_trex.trace: 19.25 -> 20.17 ( 4.81%)
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32028>
(cherry picked from commit 5b951bcdd7)
We can end up calling vk_multialloc_alloc with 0 size when
`attachment_count` is 0 and `clearValueCount` is 0.
Addressed:
```
Direct leak of 1 byte(s) in 1 object(s) allocated from:
#0 0x7faf033ee0 in __interceptor_malloc
../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145
#1 0x7fada5cc10 in vk_default_alloc ../src/vulkan/util/vk_alloc.c:26
#2 0x7fac50b270 in vk_alloc ../src/vulkan/util/vk_alloc.h:48
#3 0x7fac555040 in vk_multialloc_alloc
../src/vulkan/util/vk_alloc.h:234
#4 0x7fac555040 in void
tu_CmdBeginRenderPass2<(chip)7>(VkCommandBuffer_T*,
VkRenderPassBeginInfo const*, VkSubpassBeginInfo const*)
../src/freedreno/vulkan/tu_cmd_buffer.cc:4634
#5 0x7fac900760 in vk_common_CmdBeginRenderPass
../src/vulkan/runtime/vk_render_pass.c:261
```
seen in:
dEQP-VK.robustness.robustness2.bind.notemplate.r32i.dontunroll.nonvolatile.uniform_texel_buffer.no_fmt_qual.len_252.samples_1.1d.frag
Fixes: 4cfd021e3f ("turnip: Save the renderpass's clear values in the cmdbuf state.")
Signed-off-by: Karmjit Mahil <karmjit.mahil@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32057>
(cherry picked from commit c923eff742)
Non-trivial collects (i.e., ones that will introduce moves because the
sources don't line-up with the destination) may cause source intervals
to get implicitly moved when they are inserted as children of the
destination interval. Since we don't support moving intervals in shared
RA, this may cause illegal register allocations. Prevent this by
creating a new top-level interval for the destination so that the source
intervals will be left alone.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Fixes: fa22b0901a ("ir3/ra: Add specialized shared register RA/spilling")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31978>
(cherry picked from commit b36a7ce0f1)
Otherwise anv_descriptor_set is accessed through an unaligned pointer,
which is undefined behavior in C.
```
anv_descriptor_set.c:1620:17: runtime error: member access within misaligned address 0x61900002c2b5
for type 'struct anv_descriptor_set', which requires 8 byte alignment 0x61900002c2b5
```
Fixes: 2570a58bcd ("anv: Implement descriptor pools")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32070>
(cherry picked from commit a2c4a34303)
Copy propagation would incorrectly occur in this code
mov(16) v4+2.0:UW, u0<0>:UW NoMask
...
mov(8) v6+2.0:UD, v4+2.0:UD NoMask group0
to create
mov(16) v4+2.0:UW, u0<0>:UW NoMask
...
mov(8) v6+2.0:UD, u0<0>:UD NoMask group0
This has different behavior. I think I just made a mistake when I
changed this condition in e3f502e007.
It seems like this condition could be relaxed to cover cases like (note
the change of destination stride)
mov(16) v4+2.0<2>:UW, u0<0>:UW NoMask
...
mov(8) v6+2.0:UD, v4+2.0:UD NoMask group0
I'm not sure it's worth it.
No shader-db or fossil-db changes on any Intel platform. Even the code
for the test case mentioned in the original commit did not change.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Fixes: e3f502e007 ("intel/fs: Allow copy propagation between MOVs of mixed sizes")
Closes: #12116
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32041>
(cherry picked from commit 80a5d158ae)
Having the RGB* formats before the BGR* formats in the table causes
problems where under some circumstances, some applications end up
with the wrong colors.
The repro case for me is: Xvnc + mutter + chromium
There was an existing comment in dri_fill_in_modes() which explained
the problem. This was lost when dril_target.c was created.
Fixes: ec7afd2c24 ("dril: rework config creation")
Fixes: 3de62b2f9a ("gallium/dril: Compatibility stub for the legacy DRI loader interface")
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31950>
(cherry picked from commit e1098310da)
When etna_screen_create(..) is called with gpu != NULL and npu == NULL,
screen->pipe_nn is incorrectly set up. This leads to an unintended
stream configuration for compute-only contexts, as determined by
pipe = (compute_only && screen->pipe_nn) ? screen->pipe_nn : screen->pipe;
To address this, extend the gpu != npu condition by adding a check for
npu != NULL to ensure pipe_nn is only initialized when both gpu and npu
are provided.
Fixes: a4653587cc ("etnaviv: Add a separate NPU pipe")
Signed-off-by: Christian Gmeiner <cgmeiner@igalia.com>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32025>
(cherry picked from commit f4e8849d79)
Also change ifdef's from just `HAVE_LIBDRM` to check for both LIBDRM
and for UDMABUF HEADER. preventing unbalanced guards preventing part of
the code from being included if you just have LIBDRM or just have the
udmabuf headers.
Fixes: 4cfaf10c ("llvmpipe: Only use udmabuf with libdrm")
Reviewed-by: Konstantin Seurer <konstantin.seurer@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31877>
(cherry picked from commit 159fb9691d)
Fixes KHR-GL46.multi_bind.dispatch_bind_image_textures which decides
max_image_samples==1 means that MSAA image load/store is supported.
Switch the condition to > 0, which matches what zink does.
Fixes: e277b13182 ("freedreno: Stop exposing MSAA image load/store on desktop GL.")
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31857>
(cherry picked from commit f8e7c0e2a2)
This change fixes the calculation of the number of cubemap
images which requires a 6x multiplier.
This commit is inspired from nir_lower_robust_access and fixes
at least the following tests on cayman:
spec/arb_shader_image_load_store/layer/imagecubearray/layered binding test: fail pass
spec/arb_shader_image_load_store/max-size/imagecubearray max size test/8x8x2046x1: fail pass
Fixes: 27f5157777 ("r600/sfn: Add lowering pass to legalize image access")
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31626>
(cherry picked from commit 5c63d7a916)
This is a workaround that is still in progress, see HSD 22020521218.
If we don't have these NOPs we may see rendering corruption or even
GPU hangs.
While we still don't fully understand the issue from the hardware
point of view, let's have this workaround so we can pass CTS and move
things forward. If we need to change this later, we can. Besides, the
impact is minimal. Shaderdb/fossilize report no changes for this
patch.
On our Blackops trace, the lack of this patch causes corruption in fog
rendering (rectangles where fog was supposed to be shown don't show
the fog).
On dEQP-VK.graphicsfuzz.cov-array-copies-loops-with-limiters, without
this patch we get a GPU hang.
Backport-to: 24.2
Testcase: dEQP-VK.graphicsfuzz.cov-array-copies-loops-with-limiters
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/11813
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31331>
(cherry picked from commit 5ca883505e)
We may still need to insert a continue block even if there is only one
backedge, in a situation like:
for (...) {
if (...) continue;
foo();
break;
}
We want foo() to be executed before reconverging. This is important for
the BVH encoding kernel, which launches an invocation for each node in
the tree and does a preorder traversal:
while (true) {
if (!ready[node]) continue;
encode();
for (child node)
ready[child] = true;
break;
}
For the first few nodes, which will be in the same wave, we need
encode() for the root node to be called first, then its children spin
until ready, then the children call encode(), and so on. This can only
work if the children that aren't ready yet are parked while the parent
executes encode(), which requires the continue block.
This is also required because divergence analysis will assume that
uniform values written before the continue are still uniform after it,
which isn't the case now and causes an RA validation failure with Godot.
Fixes: 0fa93fb662 ("ir3: Fix convergence behavior for loops with continues")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31905>
(cherry picked from commit d3533716f9)
When the FS is unknown, this can happen with fast-link GPL or unlinked
ESO, rely on the number of VS/TES outputs which should be a good
approximation of the number of PS inputs.
This fixes a (huge?) performance regression from May 2023 because
for depth-only rendering, the FS is NULL and NGG culling wasn't
considered at all.
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31830>
(cherry picked from commit 8e4d1965bd)
The algorithm for adding extra physical edges works by finding edges
that jump over reconvergence points. Since predicated branches don't
introduce reconvergence points, we wouldn't add a physical edge from the
true block to the false block. However, this physical edge is still
needed as control flow does fall though here. This patch fixes this by
manually adding the physical edge so that we don't need to insert a
reconvergence point for it.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Fixes: 39088571f0 ("ir3: add support for predication")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31733>
(cherry picked from commit 19c560da04)
We shouldn't assume the bindings are sparse when we allocate an array
indexed on the binding. See, for example:
dEQP-GLES31.functional.program_interface_query.buffer_variable.random.55
Fixes: 2e833b16bc ("nir/lower_amul: Use num_ubos/ssbos instead of recomputing it.")
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31611>
(cherry picked from commit 7f63fa34da)
Using wayland on s390x has all the colors wrong.
Mesa reports using GBM_FORMAT_XRGB8888 but inside the buffer, the
colors are in GBM_FORMAT_BGRX8888 order.
This patch fixes it for common formats, and also introduced BGRX8888
which is the default on big endian.
Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31707>
(cherry picked from commit b24d4f0c86)
It's possible to enable NGG culling with ESO if shaders are linked, or
if the VS doesn't need a prolog or if TES is used. This wasn't
supposed to be enabled but I think it worked just by luck because the
user SGPR value was probably zero and NGGC was disabled at draw time.
Found by inspection.
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31829>
(cherry picked from commit 62efebfd70)
This very test was working until the commit 4da147a02b
("mesa: remove fallback for GL_DEPTH_STENCIL"). Indeed this
commit lets the driver handles this path and this was
failing on evergreen r600.
The test was processed through r600_blit() which loads the
fragment shader util_make_fs_blit_zs(). This fragment shader
loads two textures the stencil and depth. The texture depth
was processed properly but the other texture was generating
incorrect values. This issue, which seems to be related to
the hardware configuration, disappears when the underlying
surface is allocated using a width multiple of 32.
This change was tested on cayman and palm with the normal test:
"piglit/bin/ext_packed_depth_stencil-getteximage -auto -fb" and
the test was modified to test all the relevant width and height
values. The gpu rv770 was not affected by this issue. Here is
the result:
spec/ext_packed_depth_stencil/getteximage: fail pass
Cc: mesa-stable
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Acked-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31757>
(cherry picked from commit d19e2597ce)
We don't dirty the CS state, so if a 3D blit comes between binding a
compute pipeline and executing a dispatch then we won't re-emit the
pipeline and invalidating CS state causes immediates emitted via
CP_LOAD_STATE to disappear. Fixes
dEQP-VK.binding_model.descriptor_buffer.ycbcr_sampler.compute_comp.
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31764>
(cherry picked from commit 048afdd438)
This GPU seems to have half the compute constlen of other a7xx GPUs,
because there are sporadic hangs in dEQP-VK.robustness.robustness2.* and
other tests unless we limit the constlen. This does *not* happen on
SM8550-HDK, so it does seem to be specific to the GPU in x1e laptops.
Fixes: b0d22461b9 ("freedreno: Enable the X1-85")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31764>
(cherry picked from commit 3c8190e8b2)
When only of the depth/stencil aspects is used, RADV dispatches a
compute shader to initialize the HTILE buffer. But dispatching on SDMA
just hangs and the only way to initialize the HTILE buffer is to clear
both aspects using a memory fill operation.
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31803>
(cherry picked from commit be81c8b8db)
If the stencil clear value was larger than the maximum supported by the hardware
(255) then it would end up corrupting other fields in TA_STATE_ISPA. The Vulkan
1.0.266 spec says for VkClearDepthStencilValue:
"stencil is the clear value for the stencil aspect of the depth/stencil
attachment. It is a 32-bit integer value which is converted to the
attachment’s format by taking the appropriate number of LSBs."
As such, mask the clear value when packing TA_STATE_ISPA.
Fixes a number of GLES tests, including:
dEQP-GLES2.functional.depth_stencil_clear.*stencil_scissored*
dEQP-GLES2.functional.fragment_ops.stencil.*
dEQP-GLES3.functional.depth_stencil_clear.*stencil_scissored*
dEQP-GLES3.functional.fragment_ops.stencil.*
Fixes: 821c6b9342 ("pvr: Implement depth/stencil/depth+stencil attachment...")
Signed-off-by: Frank Binns <frank.binns@imgtec.com>
Acked-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31679>
(cherry picked from commit 1612255de6)
When calculating the size of an image, the driver was always factoring in space
for a full mip chain. However, this isn't necessary when mipLevels is 1 and this
resulted in applications needing to allocate more memory for these images than
is strictly necessary. Fix this by calculating the size of additional mip levels
(those greater than mipLevels) when more than 1 mip level has been requested.
Fixes: 2a3aa6da50 ("pvr: Fix cubemap layer stride")
Signed-off-by: Frank Binns <frank.binns@imgtec.com>
Acked-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31679>
(cherry picked from commit 5ef9c552b2)
pvr_cmd_buffer_end_sub_cmd() sets the current sub-command to NULL. This was
causing list_move_to(), which is called immediately after this, to access a NULL
pointer. Fix this by storing the current sub command before calling
pve_cmd_buffer_end_sub_cmd() so that this can be used instead when modifying the
list.
Fixes: d1b17a5edc ("pvr: Implement ZLS subtile alignment")
Signed-off-by: Matt Coster <matt.coster@imgtec.com>
Acked-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31679>
(cherry picked from commit 6ba3c5263d)
si_set_global_binding is a context function, but it touches the bound
compute program. As radeonsi also advertizes PIPE_CAP_SHAREABLE_SHADERS
this function is supposed to be safe when the same compute state object is
bound to multiple contexts at once.
In order to fix this data race global_buffers is moved to si_context so it
becomes context private data instead.
Cc: mesa-stable
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31672>
(cherry picked from commit 1798597637)
For surfaces without a modifier, the surf_size check wasn't
necessary, but it was also invalid since surf_size is set later
(in gfx12_compute_miptree).
Since it's not required anyway, drop this check.
Fixes: 060d5dacfd ("ac: add gfx12 DCC shared code")
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31683>
(cherry picked from commit 5607c7ee49)
ffs(VRAM, GTT) returns the GTT bit as it's the smaller.
Simplify the code by explicitely selecting VRAM when both
domains are active, otherwise assert that only 1 bit is set.
Fixes: 593f72aa21 ("winsys/amdgpu-radeon: rework how we describe heaps")
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31683>
(cherry picked from commit 19fa5561be)
Helps for the case when max_distance is set to ~0, where the pass would now
only create groups of two loads together due to overflow. Found while
experimenting with this pass on r300, however the only driver currently
affected is i915.
With i915 this change gains around 20 shaders in my small shader-db
(most notably some GLMark2, Unigine Tropics, Tesseract, Amnesia) at
the expense of increased register pressure in few other cases.
I'm assuming this is a good deal for such old HW, and this seems like what
was intended when the pass was introduced to i915, but anyway this
could be tweaked further driver side with a more optimized max_distance
value. Only shader-db tested.
Relevant i915 shader-db stats (lpt):
total tex_indirect in shared programs: 1529 -> 1493 (-2.35%)
tex_indirect in affected programs: 96 -> 60 (-37.50%)
helped: 29
HURT: 2
total temps in shared programs: 3015 -> 3200 (6.14%)
temps in affected programs: 465 -> 650 (39.78%)
helped: 1
HURT: 91
GAINED: 20
Signed-off-by: Pavel Ondračka <pavel.ondracka@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Tested-by: GKraats <vd.kraats@hccnet.nl>
Fixes: 33b4eb149e
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31529>
(cherry picked from commit 33c8dc4f18)
When the VkBuffer is of size 2^32 (which matches maxBufferSize), we
have vm_bind->size set to 2^32, which is fine because it fits in an
uint64_t. What is not fine is the 'i' variable being size_t, because
on 32bit systems it will loop forever since it will always be smaller
than 2^32.
Credits to Iván for not only reporting it, but also coming up with the
solution at the same time as I did, then testing it.
Cc: mesa-stable
Reported-by: Iván Briano <ivan.briano@intel.com>
Reviewed-by: Iván Briano <ivan.briano@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31698>
(cherry picked from commit da396a49a0)
When creating and caching the bo_export object for a given zink_bo, the
screen file descriptor was used. Since no buffer object's file descriptor
would match that, bo_export objects were continuously added to the exports
list and no bo_export was effectively picked from the cache. Using the
buffer object's file descriptor avoids that.
Signed-off-by: Zan Dobersek <zdobersek@igalia.com>
Fixes: b0fe621459 ("zink: add back kms handling")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31715>
(cherry picked from commit b44480e86a)
When flushing the render target cache for future operations, we need a
stall at pixel scoreboard. We likely didn't see any issue until now
because a change in render target added the pb-stall.
When using a 2 compute shaders with the following pattern :
vkCmdDispatch()
vkCmdPipelineBarrier() ImageBarrier with (src|dst)AccessMask=0 & identical layout
vkCmdDispatch()
we should ensure that the first dispatch is completed before executing
the second one, otherwise they can race to on resource accesses. This
fixes failures in some new CTS tests.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: mesa-stable
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31676>
(cherry picked from commit ea2bbe3271)
When we create sparse resources the first thing we do is a NULL bind
on them, as the Vulkan spec mandates certain behavior even for unbound
sparse resources. We do this with the minimal effort possible: if we
can get away with marking an L2 pointer as NULL in the L3 table, we
just do it and return, instead of going all the way to creating L1
tables and marking all the final entries as NULL.
The strategy we were using had a bug that could lead to previously
created NULL entries not being marked as NULL anymore. Let's give an
example:
(before proceeding, keep in mind that a NULL entry in the L3 and L2
tables has bit 1 set, it does *not* have the value 0)
- Create a 64mb buffer that uses an entire L1 table (needs to be
properly aligned), which triggers a NULL bind.
- Our algorithm will just set the L3 entry (pointing to the L2
table) as NULL.
- Create a 64kb buffer that uses the same L2 table (but a different
L1 table).
- The NULL bind triggered won't do anything as the L2 table is
already NULL.
- Bind the first buffer to actual memory. This will end up creating
the L2 table and the L1 table. The only entry we will set in the L2
table will be the one pointing to the L1 table. All the other
values will be 0 (so they won't have neither the NULL or Invalid
bits set: access to them will lead to page faults).
- Try to use the second buffer, which is still unbound. It was
relying on the fact that its L2 table pointer was NULL, but now
it's not anymore, so the page walker will fetch the L1 entries in
the L2 table and they will all be zero instead of having the NULL
bit set.
The fix is pretty simple: whenever we create a new L2 table, set every
entry to NULL (except the one we're about to set to non-NULL). This
preserves behavior for every other NULL resource relying on the L3
entry being set to NULL.
We don't need to do this for the L1 table because its entries are
different and instead of having bits to signal NULL entries we have
a special TR-TT register that we can set that gets compared to check
if an entry is NULL, and we conveniently program it to 0: see
ANV_TRTT_L1_NULL_TILE_VAL.
I am not aware of any real workloads that are triggering this
behavior, I found this issue while investigating something else,
running a custom sparse program in our pre-silicon environment, and it
told us about the page faults.
Cc: mesa-stable
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/30953>
(cherry picked from commit 4c366ef67b)
Xe2 increased the register size from 256-bits to 512-bits. So we can
store 32 16-bit values in a register, rather than 16 values. Prior to
this patch, we hadn't updated the pass, so the second half of each of
our registers was unused.
Backport-to: 24.2
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31499>
(cherry picked from commit 4cb67cb07a)
We were manually allocating 1 REG_SIZE for the barrier payload, which is
only half a register on Xe2. This should eventually get allocated to a
whole register anyway, but it's awkward in the meantime. Also, we were
zero-initializing the header using group(8, 0) which only initialized
half the register. The rest of the fields are Reserved MBZ, so they're
likely unused and unread anyway - but it's better to zero-initialize
them so we don't get random undefined, miserable-to-debug behavior.
Backport-to: 24.2
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31499>
(cherry picked from commit dea61b7399)
Texel buffer could be arbitrary large, so the assumption being made in
the following comment is wrong:
"Zero-extension (u16) and sign-extension (i16) have
the same behavior here - txf returns 0 if bit 15 is set
because it's out of bounds and the higher bits don't matter."
Sign extension should matter for GLSL_SAMPLER_DIM_BUF.
This fixes the case of doing texelFetch with u16 offset:
uniform itextureBuffer s1;
uint16_t offset = some_ssbo.offset;
value = texelFetch(s1, offset).x;
If the offset is higher than s16 optimization incorrectly
left it as 16b.
In spirv the above glsl is translated into:
%22 = OpLoad %ushort %21
%23 = OpUConvert %uint %22
%24 = OpBitcast %int %23
%26 = OpImageFetch %v4int %16 %24
Cc: mesa-stable
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Reviewed-by: Georg Lehmann <dadschoorse@gmail.com>
Reviewed-by: Connor Abbott <cwabbott0@gmail.com>
Reviewed-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31664>
(cherry picked from commit 7b09fc98fb)
We also add an nvk_format_supports_atomics() helper. This helper lives
in NVK for now because it's not just about the format and hardware but
also about whether or not we have compiler support in NAK.
Fixes: 1d10de539c ("nvk: Implement VK_EXT_shader_image_atomic_int64")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31633>
(cherry picked from commit c2684968de)
Correct copy-paste typo of depth_cpp instead of depth and use nullptr
instead of NULL, as GTest suggest in documentation:
When comparing a pointer to NULL, use EXPECT_EQ(ptr, nullptr) instead of EXPECT_EQ(ptr, NULL).
Fixes: ef9362acb8 ("gallium/osmesa: Return cleanly for OSMesaGetDepthBuffer() with no depth.")
Signed-off-by: David Heidelberg <david@ixit.cz>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31606>
(cherry picked from commit 321012b95d)
Otherwise, they aren't applied if shaders are pre-compiled using
builders because the executable name would be fossilize-replay.
Using pApplicationName is the correct way to do because it's replayed
by Fossilize correctly.
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31621>
(cherry picked from commit 56813236f4)
The Vulkan spec says:
"If the buffer was created with a non-zero value of
VkBufferOpaqueCaptureAddressCreateInfo::opaqueCaptureAddress or
VkBufferDeviceAddressCreateInfoEXT::deviceAddress, the return
value will be the same address that was returned at capture time."
My interpretation is that you can get the buffer device address before
binding if you passed a non-zero address during buffer creation. The
returned BDA would be similar if a memory object is bound to the
buffer later.
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31145>
(cherry picked from commit 03b4477c8f)
There is no HW support, but in some cases the shaders mostly work even
if we ignore it, and so far we have just done so. However since the
driver didn't know to what output position in the PVS we should
redirect it, it ended in the first slot. Importantly, if the
CLIP_VERTEX output would be written after position (which actually
belongs in the first slot) it would overwrite it and things blow up.
So just remove it early, and also improve the warning a bit, including
the part that we could use draw module to actually emulate the feature.
Signed-off-by: Pavel Ondračka <pavel.ondracka@gmail.com>
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/11856
Fixes: 5dcef1e7b8
Reviewed-by: Filip Gawin <filip@gawin.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31547>
(cherry picked from commit cc14d40239)
Spec allows calling VkBufferGetDeviceAddressInfo without binding to memory:
VUID-VkBufferDeviceAddressInfo-buffer-02600
If buffer is non-sparse and was not created with the VK_BUFFER_CREATE_DEVICE_ADDRESS_CAPTURE_REPLAY_BIT flag, then it must be bound completely and contiguously to a single VkDeviceMemory object
Which we can only do by making it sparse unconditionally, which feels very wrong to me for a capture & replay extension as that significantly impacts execution.
Current theory is that this was only intended for the EXT and not the core functionality. As such, let's disable capture using the EXT.
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31140>
(cherry picked from commit c8c354d9c3)
When all 16 references are used, this would read pic->ref[16].
Same for HEVC, but HEVC only uses 15 reference frames so it would
never happen there yet is still reported by coverity.
Fixes coverity issues 1497283 and 1465569 Out-of-bounds read
Cc: mesa-stable
Reviewed-by: Leo Liu <leo.liu@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31558>
(cherry picked from commit 20d5020ad7)
Starting with Linux v6.11+, performance counter information is no
longer duplicated in both the kernel and userspace. Instead, an IOCTL
retrieves this information, allowing userspace to maintain a local
array for reuse, thus avoiding redundant kernel queries.
However, support for older kernels without these new IOCTLs remains.
To distinguish between versions, we check `devinfo->max_perfcnt` -
which is non-zero on Linux v6.11+ and zero on older kernels.
Currently, applications using performance queries on platforms with
older kernels encounter a SEGFAULT, as we don't validate
`devinfo->max_perfcnt` before accessing the userspace array for
performance counter information.
This commit makes sure that, if `devinfo->max_perfcnt` is zero,
`screen->perfcnt_names` will be NULL. This way, we can check if
`screen->perfcnt_names` is different than NULL before attempting to use
the userspace array.
Fixes: 017dde0d1c ("v3d: Use DRM_IOCTL_V3D_GET_COUNTER to get perfcnt information")
Signed-off-by: Maíra Canal <mcanal@igalia.com>
Reviewed-by: Juan A. Suarez <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31552>
(cherry picked from commit 47a78614ea)
Check if the block size is bigger then 64. We want to block
e.g. one of the following formats:
- R32G32B32A32_FLOAT
- R32G32B32A32_SINT
- R32G32B32A32_ZINT
Unbreaks e.g. dEQP-GLES3.functional.fbo.completeness.renderable.texture.color0.rgb16i
Fixes: e481c1269c ("etnaviv: disable 64bpp render/sampler formats")
Signed-off-by: Christian Gmeiner <cgmeiner@igalia.com>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27111>
(cherry picked from commit 04521c14b0)
These extensions were experimental and only exposed with radv_dgc=true
for vkd3d-proton. Only two games require DGC (Starfield and Halo
Infinite) and both also require sparse support which GFX6-7 can't
support.
GFX6-7 support is also mostly broken because IB2 can't be used when
indirect draw packets are used and RADV uses that to preprocess IBO.
Also with the EXT, indirect draws are more common and can't be
supported.
Everything could work with a bunch of time and workarounds but I don't
think it's worth the effort given there is no real use.
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31491>
(cherry picked from commit e4f67f2106)
AV1 has no startcode, so the packed header will not contain any
additional data at the beginning of the buffer that we would need
to skip to get to the OBU header.
Also ignore OBU types that we are not parsing.
Fixes assertions with libva-utils/av1encode.
Fixes: 5edbecb856 ("frontends/va: adding va av1 encoding functions")
Reviewed-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31359>
(cherry picked from commit 023277173c)
The error message in the linker that checked
gl_MaxCombinedClipAndCullDistances would never be issued because the
compiler was already doing the check. I think the compiler might have
been done this way in the original commit d656736b as the linker
only sets the size when the clip/cull outputs are written so the
piglit test for this wouldn't have been triggered as it does not
write to the outputs.
Here we move the error to the compiler and fix things up so the
correct messages are triggered.
Fixes: d656736bbf ("glsl: Add arb_cull_distance support (v3)")
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31471>
(cherry picked from commit 1c58f513c4)
Because we map compressed formats to the interchange-formats on V9 and
later, we end up not actually checking for compressed support here, but
instead always checking bit 0, which is reserved in the spec.
So let's instead explicitly check bitfeat_bit here instead, which we
conveniently stored away in the previous commit.
Use 1u instead of 1 for the shifted constant, to avoid undefined
behavior when we're testing bit 31.
Fixes: 0c1fde956b ("panfrost: Add Valhall compressed formats")
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31419>
(cherry picked from commit 23cad7c695)
this extension specifies error checking (which was not implemented)
and also sample count clamping needs to be done since the samples
specified are just min samples and not an exact param
cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31235>
(cherry picked from commit 894b37e060)
this was accidentally duplicated from the conditional below,
except this one didn't have the buffer_stride_unaligned
caps check, which meant any 4-byte attrib which was
unaligned got marked for rewrites even on drivers
supporting unaligned strides
the correct change should have checked the stride against
the component size in the top case
Fixes: 7672545223 ("gallium: move vertex stride to CSO")
Acked-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31425>
(cherry picked from commit 8a1ce9a144)
X11 starts up if Mesa is compiled with legacy-x11=dri2 and shows
the desktop.
It crashes with segfault as soon as an application is started.
At src/egl/drivers/dri2/platform_x11.c function dri2_from_names
(at src/gallium/frontends/dri/dri2.c) should be called
with offset address instead of with offset value.
Signed-off-by: GKraats <vd.kraats@hccnet.nl>
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31406>
(cherry picked from commit 6c84103276)
The per-primitive have their own separate section in the FS thread
payload, and are not considered when setting the mask in
3STATE_SBE's ConstantInterpolationEnable.
This is also consistent with what is done for brw_interp_reg().
Fixes
- dEQP-VK.mesh_shader.ext.misc.clip_geom_provoking_last
- dEQP-VK.mesh_shader.ext.misc.clip_geom_and_task_shader_provoking_last
Backport-to: 24.2
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/11844
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31417>
(cherry picked from commit 93c3780bc1)
At i945_texture_layout_3d() util_next_power_of_two() is called,
which oversizes the npot-blocks for every level to get power of 2
for width and height. Hardware doesnot expect these oversized
npot-blocks. The call is removed.
Code is added to align allocation of npot-blocks correctly.
Also at i915_texture_layout_3d() the util_next_power_of_two() call
is removed. Besides the computation of block-allocation is changed,
because it still was using classic i915-coding.
Cc: mesa-stable
Signed-off-by: GKraats <vd.kraats@hccnet.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31057>
(cherry picked from commit a95bd2dcf0)
If ftrunc@64 is lowered by nir_lower_doubles it is turned into a
comparable long series of 32 bit operations. If the hardware
supports ffract@64 then nir_opt_algebraic can first lower ftrunc@64
to use some combinations with ffloor@64. They can then be turned
into a combination of fsub@64 and ffract@64 resulting in less
all-over instructions.
Fixes: 5218cff34b
nir/algebraic: avoid double lowering of some fp64 operations
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29281>
(cherry picked from commit f19f1ec17b)
We were unlocking the bo handles hash table right after removing the bo handle
and afterward closing it. This leads to race conditions where the handle could
have been re-acquired on another thread. As the kernel would return the same
bo handle and do not reference count them, this leads to it being used after
being closed.
Signed-off-by: Corentin Noël <corentin.noel@collabora.com>
Reviewed-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31421>
(cherry picked from commit bef454f227)
When allocating a buffer normally, this flag gets to the allocator from
the memory requirements, but when sparse bindings are created we were
checking for them but never setting them.
Fixes sparse descriptor buffers on Xe2.
Makes the failure on TRTT more obvious.
Fixes: c6a91f1695 ("anv: add new heap/pool for descriptor buffers")
Fixes: 692e1ab2c1 ("anv: get rid of the second dynamic state heap")
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31372>
(cherry picked from commit a4cbc903a8)
Importing an opaque fd no longer returns the mapped pointer but
a pointer to llvmpipe_memory_allocation to support both memfds and
dma bufs. This saves the pointer with the correct type and we can
unwrap the mapped data in a correct way.
Fixes: d74ea2c117 ("llvmpipe: Implement dmabuf handling")
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31022>
(cherry picked from commit 3e01c15fa7)
If the buffer is not unmapped then a reference to the DMA buffer
is still kept. The DRM device is then not properly cleaned up.
This can cause the application to keep a DRM device open which is
still DRM master without any visible open file descriptors.
Fixes: d74ea2c117 ("llvmpipe: Implement dmabuf handling")
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31022>
(cherry picked from commit 39156b6cd4)
Make the external memory object a reference counted object. Without
that deleting the memory object in OpenGL would also delete and unmap
the memfd, which causes any operation on a texture or buffer that is
bound to that memory object to access invalid memory.
Fixes: 1608a815e3 ("llvmpipe: add support for EXT_memory_object(_fd)")
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31022>
(cherry picked from commit af16ec6e0c)
If the pipeline is created with no
VkPipelineSampleLocationsStateCreateInfoEXT, but
VK_DYNAMIC_STATE_SAMPLE_LOCATIONS_ENABLE_EXT is set, we end up
dereferencing a NULL pointer.
Fixes future dEQP-VK.pipeline.*.extended_dynamic_state.*.sample_locations_enable_no_create_info
Fixes: 1deb83fb86 ("vulkan: Add more dynamic multisample states")
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31377>
(cherry picked from commit 101a803858)
Based on a patch by weab chan.
The chip_id wasn't getting picked up with the capital B, so use lowercase hex values
like everywhere else.
Move it as a separate entry and turn on enable_tp_ubwc_flag_hint as the Quest 3 ships
with blob version 7xx, and expose the name as FD740v3 for clarity.
Unify the raw_magic_regs with a740, but as noted by Danylo in the initial enablement, set
RB_DBG_ECO_CNTL to 1 on a740v3 in magic_regs.
Fixes image corruption issues on this device.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/10316
Fixes: 0b5097081a ("freedreno/devices: Add A740v3 from Quest 3")
Signed-off-by: Valentine Burley <valentine.burley@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31328>
(cherry picked from commit 7968b356f8)
Kernel does VCN instance scheduling per context, so when we have
multiple instances we should use new context to be able to utilize
all of them.
Another issue is with AV1, VCN 3 and VCN 4 only support AV1 on
first instance. Kernel parses IBs and switches to first instance when
it detects AV1, but this only works for first submitted IB in context.
The CS would be rejected if we first decode/encode other codecs, kernel
schedules on second instance (default) and then we try to decode/encode AV1.
Cc: mesa-stable
Reviewed-by: Leo Liu <leo.liu@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31249>
(cherry picked from commit 712e49f137)
In an earlier commit, I made us stop counting sync.nops in the shader
statistics we use for shader-db (brw_debug_log_message) and fossil-db
(stats->instructions = ...). However, I missed adjusting the printout
for INTEL_DEBUG.
Fixes: 1497f4e0c2 ("intel/fs: Don't include sync.nop in instruction count statistics")
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31311>
(cherry picked from commit 878ae9708a)
When no pipeline cache is provided by the application and we rely on the
internal one, cache hits are not counted as such.
This was causing us to return COMPILE_REQUIRED on some cases where all
shaders had been found in the cache, as well as some unnecessary extra
processing in the case that we did have to compile the pipeline.
Fixes: 1dacea10f3 ("anv: implement caching for ray tracing pipelines")
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31298>
(cherry picked from commit 2e1c278e3d)
We have not yet added the shaders to the pipeline->shaders array at
this point. If we couldn't compile (or were asked not to) the
pipeline, we were leaking references to any shaders found in the cache.
This would manifest as an assert on device destruction:
vk_pipeline_cache_destroy: Assertion `cache->object_cache->entries == 0' failed.
Fixes: 58c9f817cb ("anv: fix pipeline executable properties with graphics libraries")
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31298>
(cherry picked from commit 1a45c8827b)
We found out that some HW changes on Xe2 make the HW avoid reading the
blend state if we're using the null_rt bit in the extended descriptor.
Since the alpha_to_coverage bit resides in the blend state, that state
is ignored and writes are going through to the depth/stencil buffers.
Disable null_rt in the color outputs if the color outputs can affect
other outputs (through alpha_to_coverage & omask).
Fixes tests in this pattern on Xe2 :
dEQP-VK.pipeline.*.multisample.alpha_to_coverage_no_color_attachment.*
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Backport-to: 24.2
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31196>
(cherry picked from commit 35ea8b6cd2)
We setup an empty render target when there are no color attachments,
which effectively makes it a different surface state. In most cases
the compiler will insert a null-rt bit in the extended descriptor
which means the RT isn't even accessed. But in some cases like
alpha-to-coverage output + depth/stencil write, we will access the
render target because using the null-rt will prevent alpha-to-coverage
from happening.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: 2bd304bc8f ("anv: Skip the RT flush when doing depth-only rendering.")
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31196>
(cherry picked from commit badb3f6301)
This is a regression happening with the commit 87b99d5797 ("nir: use copysign for atan").
Indeed, the opcode "copysign" was generating an incompatible i915 sequence.
For instance, this issue is triggered with
"deqp-gles2 --deqp-case=dEQP-GLES2.functional.shaders.operator.angle_and_trigonometry.atan2.highp_float_vertex":
deqp-gles2: ../src/compiler/nir/nir_lower_int_to_float.c:239: lower_alu_instr: Assertion `nir_alu_type_get_base_type(info->output_type) != nir_type_int && nir_alu_type_get_base_type(info->output_type) != nir_type_uint' failed.
Fixes: c4cec84231 ("nir/i915g/r300/nv30: skip marking varyings as flat in some drivers")
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Reviewed-by: Georg Lehmann <dadschoorse@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31315>
(cherry picked from commit 6e994fdb6e)
It was always using device->context_id what is not valid in i915 when
has_vm_control is true or when running with Xe KMD.
But anv_AcquireProfilingLockKHR() don't have the queue information so
at least for now we will only support queries in a single queue.
And for consistency doing the same in
anv_QueueSetPerformanceConfigurationINTEL() although here we have the
queue parameter but queries are only supported in render engine
so it would only expose other queues if user set some parameters.
Cc: 24.2 <mesa-stable>
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/30652>
(cherry picked from commit c5d79d533a)
This change ensures that all these allocations are using
the same memory context.
For instance, this issue is triggered with:
"piglit/bin/arb_shader_image_load_store-host-mem-barrier -auto -fbo":
Indirect leak of 32816 byte(s) in 1 object(s) allocated from:
#0 0x7f49a35447ef in __interceptor_malloc (/usr/lib64/libasan.so.6+0xb17ef)
#1 0x7f49998e4b4f in ralloc_size ../src/util/ralloc.c:118
#2 0x7f49998e7521 in create_slab ../src/util/ralloc.c:801
#3 0x7f49998e7521 in gc_alloc_size ../src/util/ralloc.c:840
#4 0x7f49998e7d11 in gc_zalloc_size ../src/util/ralloc.c:868
#5 0x7f49999a6126 in nir_alu_instr_create ../src/compiler/nir/nir.c:682
#6 0x7f49999cba48 in clone_alu ../src/compiler/nir/nir_clone.c:217
#7 0x7f49999cc85a in clone_instr ../src/compiler/nir/nir_clone.c:456
#8 0x7f49999cee3a in clone_block ../src/compiler/nir/nir_clone.c:529
#9 0x7f49999cee3a in clone_cf_list ../src/compiler/nir/nir_clone.c:583
#10 0x7f49999d03be in clone_function_impl ../src/compiler/nir/nir_clone.c:660
#11 0x7f49999d13f7 in nir_function_impl_clone ../src/compiler/nir/nir_clone.c:678
#12 0x7f4999a0e2c5 in lower_call_function_impl ../src/compiler/nir/nir_functions.c:397
#13 0x7f4999a0e2c5 in function_link_pass ../src/compiler/nir/nir_functions.c:430
#14 0x7f4999a0e2c5 in function_link_pass ../src/compiler/nir/nir_functions.c:408
#15 0x7f4999a0e2c5 in nir_function_instructions_pass ../src/compiler/nir/nir_builder.h:108
#16 0x7f4999a0e2c5 in nir_link_shader_functions ../src/compiler/nir/nir_functions.c:452
#17 0x7f499ca30b8f in link_libintel_shaders ../src/gallium/drivers/iris/iris_program_cache.c:329
#18 0x7f499ca30b8f in iris_ensure_indirect_generation_shader ../src/gallium/drivers/iris/iris_program_cache.c:374
#19 0x7f499d185267 in gfx9_emit_indirect_generate ../src/gallium/drivers/iris/iris_indirect_gen.c:593
#20 0x7f499d119c79 in iris_upload_indirect_shader_render_state ../src/gallium/drivers/iris/iris_state.c:8744
#21 0x7f499fe86b01 in iris_indirect_draw_vbo ../src/gallium/drivers/iris/iris_draw.c:233
#22 0x7f499fe86b01 in iris_draw_vbo ../src/gallium/drivers/iris/iris_draw.c:343
#23 0x7f499a174e43 in tc_call_draw_indirect ../src/gallium/auxiliary/util/u_threaded_context.c:3828
#24 0x7f499a1557fe in batch_execute ../src/gallium/auxiliary/util/u_threaded_context.c:453
#25 0x7f499a1557fe in tc_batch_execute ../src/gallium/auxiliary/util/u_threaded_context.c:504
#26 0x7f499a167f26 in _tc_sync ../src/gallium/auxiliary/util/u_threaded_context.c:761
#27 0x7f499a168888 in tc_texture_map ../src/gallium/auxiliary/util/u_threaded_context.c:2783
#28 0x7f49986f2631 in pipe_texture_map ../src/gallium/auxiliary/util/u_inlines.h:556
#29 0x7f49986f2631 in _mesa_map_renderbuffer ../src/mesa/main/renderbuffer.c:494
#30 0x7f49991af7ca in readpixels_memcpy ../src/mesa/main/readpix.c:260
#31 0x7f49991af7ca in _mesa_readpixels ../src/mesa/main/readpix.c:898
#32 0x7f499931ee23 in st_ReadPixels ../src/mesa/state_tracker/st_cb_readpixels.c:575
#33 0x7f49991b40b5 in read_pixels ../src/mesa/main/readpix.c:1199
#34 0x7f49991b40b5 in _mesa_ReadnPixelsARB ../src/mesa/main/readpix.c:1216
#35 0x7f49991b4a20 in _mesa_ReadPixels ../src/mesa/main/readpix.c:1231
...
SUMMARY: AddressSanitizer: 323648 byte(s) leaked in 201 allocation(s).
Fixes: 5438b19104 ("iris: enable generated indirect draws")
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31313>
(cherry picked from commit b6b363c478)
Otherwise we can end up generating invalid assembly not following
destination/source alignments requirements.
Fixes the following tests:
dEQP-VK.spirv_assembly.instruction.graphics.float16.arithmetic_4.tan_frag
dEQP-VK.spirv_assembly.instruction.graphics.float16.arithmetic_2.tan_frag
dEQP-VK.spirv_assembly.instruction.graphics.float16.arithmetic_1.tan_frag
dEQP-VK.spirv_assembly.instruction.graphics.float16.arithmetic_3.tan_frag
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Backport-to: 24.2
Reviewed-by: Rohan Garg <rohan.garg@intel.com>
Reviewed-by: Sagar Ghuge <sagar.ghuge@intel.com>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31206>
(cherry picked from commit ed64eccab0)
The indexing needs to be adjusted and the best solution seems to
use soffset instead of const_offset, it's simpler and generate less
prologs than passing the vertex binding strides to the prolog.
Fixes dEQP-VK.pipeline.*.vertex_input.legacy_vertex_attributes.*stride_1*.
Fixes: 38cbc3c605 ("radv: advertise VK_EXT_legacy_vertex_attributes")
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31209>
(cherry picked from commit 15b1790a1e)
When multiview is used and the FS is compiled separately with GPL, the
view index still needs to be lowered, otherwise it's crashing later.
The lowering doesn't need to know the previous stage because ViewIndex
is a global thing (ie. it's neither a per-vertex or a per-primitive
varying).
This fixes recent
dEQP-VK.pipeline.pipeline_library.graphics_library.misc.other.view_index_from_device_index_*_pre_rasterization
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31192>
(cherry picked from commit 656d7e887a)
In the error handling path we end up creating a vk_sync and then later
we vk_sync_wait() on it. If that wait fails somehow we'll end up calling
vk_queue_set_lost(&queue->vk, ...) which would segfault if queue is
NULL.
If we end up in this situation (no queue), return directly whatever the
backend's vm_bind function returned, propagating the error up if
necessary.
Fixes: dd5362c78a ("anv/xe: try harder when the vm_bind ioctl fails")
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31048>
(cherry picked from commit ed8d1d3c9b)
While the rnndb fix increased the size of the driver internal
structures to be able to hold all data for the currently supported
number of varyings, it didn't change the state emission, so only
a subset of the PA shader attribute states was emitted.
Use the define from rnndb to avoid such inconsistencies.
Fixes: 11ffb20b70 ("etnaviv: Update headers from rnndb")
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31032>
(cherry picked from commit a71003b1b8)
The intention here is to detect ALU hardware instructions, but not
virtual instructions that haven't been explicitly whitelisted.
For some reason we had arbitrarily hardcoded 128 here, but our virtual
opcodes don't start at 128. They start at NUM_BRW_OPCODES. So, use
that instead.
This prevents regressions later when we delete some opcodes, shifting
some virtual opcodes into the 72-128 range.
Cc: mesa-stable
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Reviewed-by: Rohan Garg <rohan.garg@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30828>
(cherry picked from commit ab0b9b6792)
Currently vdpau driver and dri driver are two separate libraries, when
radeonsi is enabled both libraries contain amdgpu winsys. radeonsi
needs shared winsys to ensure sync between OpenGL and VDPAU works.
Build vdpau driver into libgallium to avoid having two instances of amdgpu
winsys.
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31079>
(cherry picked from commit b6faf586e6)
In c1a7d520f3, we disabled AUX usage for imported images when they are
using an explicit modifier that doesn't support it.
We need to do the same when the modifier is picked by the driver,
otherwise the memory requirements reported for an exported image don't
match those we report for import.
Fixes: c1a7d520f3 ("anv: Disable aux if the explicit modifier lacks it")
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31051>
(cherry picked from commit e4ee0a2ce1)
Although we don't want to rely on hwconfig for devinfo->verx10 == 120,
due to the dependence on closed source software, we do check to see if
hwconfig reports different values in the DEVINFO_HWCONFIG macro.
Matt was seeing this warning on 8086:a7a0:
> MESA: warning: INTEL_HWCONFIG_TOTAL_PS_THREADS (128) != devinfo->max_threads_per_psd (64)
Reported-by: Matt Turner <mattst88@gmail.com>
Fixes: 3e4f73b3a0 ("intel/dev: Update hwconfig => max_threads_per_psd for Xe2")
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31077>
(cherry picked from commit c5c349a690)
This reverts commit 0b85476d86.
When mapping a BO in v3d, the map keeps forever until freeing the BO. If
later the map is required again, we reuse the map instead of doing the
map from scratch.
This saves calling map/unmap continuously, as well as a mechanism to
keep control of the map usage, like a reference count.
Thus, when reallocating a BO, if it is mapped it just means the map was
used in the past, but not necessarily it is in use right now.
The reverted commit was causing performance regressions in multiple
applications, reducing from 60fps to 5fps.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/11783
Backport-to: 24.2
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31049>
(cherry picked from commit c84be162a1)
The following things needed to be fixed:
- lp_build_tiled_sample_offset has to use the block size of the
underlying 3D texture. Remaining calculations use the dimensions of
the view since the z-coordinate is undefined and has to be ignored.
- The layer offset must be calculated using llvmpipe_get_texel_offset.
Fixes: d747c4a ("lavapipe: Implement sparse buffers and images")
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31038>
(cherry picked from commit 1ad1b356fc)
For example, if the application wants to create linked shaders with
VS/TCS/TES but the next stage of TES isn't present, the driver would
have to compile shader variants (ie. nextStage could be NONE,TES,GS).
This isn't supported by RADV without re-compiling all shaders twice,
and it's also likely less optimal than compiling unlinked shaders.
This fixes recent CTS
dEQP-VK.shader_object.link.linked_linked_linked_unlinked_unlinked.*
Fixes: 37d7c2172b ("radv: add support for creating/destroying shader objects")
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31062>
(cherry picked from commit 868272c2e9)
There are two bugs:
- VK_KHR_maintenance5 added VkBufferUsageFlags2CreateInfoKHR, so
checking for pCreateInfo->usage is incomplete
- this was also missing the usage flag for descriptor buffer with samplers
This fixes recent VKCTS coverage in
dEQP-VK.binding_model.descriptor_buffer.*.
Fixes: 059391b631 ("radv: use 32bit va range for sparse descriptor buffers")
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31054>
(cherry picked from commit eab5b453cd)
v3d_resource_from_handle when importing a DRM_FORMAT_MOD_INVALID
considered that if we had a render-only device the resource layout was
linear and if we didn't have render-only the resource layout was tiled.
This change honors the resource creation with the SCANOUT flag
independently of the availability of the render-only for the
DRM_FORMAT_MOD_INVALID modifier.
It also fixes most of the failing piglit text for:
spec@ext_image_dma_buf_import@ext_image_dma_buf_import.*
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/11594
Cc: mesa-stable
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30946>
(cherry picked from commit 5fed6bee19)
Until now the RD dumps were stored in files on a per-device basis, using
the device index but assuming only one Vulkan instance is active. With
multiple active instances, different devices separated across those
instances could end up storing RD dumps into files with the same name.
tu_instance struct now has an index member variable that's assigned upon
creation with an incrementally-increasing global counter value. RD dump
output name now also contains this instance index, avoiding the described
naming collisions.
Signed-off-by: Zan Dobersek <zdobersek@igalia.com>
Fixes: f9c4e25483 ("freedreno: add fd_rd_output facilities for gzip-compressed RD dumps")
Reviewed-by: Karmjit Mahil <karmjit.mahil@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30977>
(cherry picked from commit 4c359eae01)
In commit fe3d90aedf ("intel/fs/xe2+: Fix calculation of spill message
width for Xe2 regs.") we aligned the width of scratch messages to
physical register sizes (32B prior to Xe2, 64B for Xe2+).
But our spilling offsets are computed using the register allocations
sizes which are in units of 32B. That means on Xe2, you can end up
spilling a virtual register allocated at 32B (which we use for surface
state computations with exec_all) and then the spilling of that
register will be emitted in SIMD16, having the upper 8 lanes
overwriting the next spilled register.
We could potentially limit spills to SIMD8 messages on Xe2 (only
writing 32B of data), but we're also unlikely to have all 32B virtual
register spilled next to one another. And if not tightly packed, we
would have 64B registers stored on 2 different cachelines which sounds
inefficient.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: fe3d90aedf ("intel/fs/xe2+: Fix calculation of spill message width for Xe2 regs.")
Backport-to: 24.2
Reviewed-by: Rohan Garg <rohan.garg@intel.com>
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30983>
(cherry picked from commit aa494cbacf)
The mutex needs to be locked before accessing the handle table.
After 64ca0fd2f2 ("frontends/va: Allocate surface buffers on demand")
the issue is now much more likely to happen and can be reproduced when
transcoding using ffmpeg.
Cc: mesa-stable
Reviewed-By: Sil Vilerino <sivileri@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30935>
(cherry picked from commit fccf31c231)
Conflicts:
src/gallium/frontends/va/image.c
The bug report has a sequence that looks like this:
* set tex as framebuffer
* dispatch a compute shader that doesn't use tex
* dispatch a compute shader that uses it
Since we were updating the counters at step 2, step 3 failed to realize
that calling si_make_CB_shader_coherent was needed.
While at it, this commit splits the draw call tracking counter in 2: one
for CB, one for DB.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/11638
Cc: mesa-stable
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30591>
(cherry picked from commit bfcee149ed)
This reverts 2fc396ae75 ("intel/dev: Disable LNL PCI IDs on Mesa 24.2
(require INTEL_FORCE_PROBE)") from the 24.2 branch.
Mesa's 2fc396ae75 was needed because, although we were compatible
with Linux 6.11, this kernel change which will appear in Linux 6.12
would break our previous LNL support, causing the driver to fail to
load:
7108b4a589cd ("drm/xe/uapi: Expose SIMD16 EU mask in topology query")
Since d8b5ee8d65 ("intel/dev: Support new topology type with SIMD16
EUs"), this issue was resolved, but we were told we had to wait for
the kernel to remove force_probe before they would guarantee backwards
compatibility with uapi changes.
Since drm-next 6d0ebb390485 ("Merge tag 'drm-intel-next-2024-08-29' of
https://gitlab.freedesktop.org/drm/i915/kernel into drm-next"), the
upstream drm kernel has now removed force_probe for LNL. Ref:
9c57bc08652a ("drm/xe/lnl: Drop force_probe requirement")
Tested with upstream drm kernel:
commit 6d0ebb3904853d18eeec7af5e8b4ca351b6f9025
Merge: 8bdb468dd7a5 b5d4657e192b
Author: Dave Airlie <airlied@redhat.com>
Merge tag 'drm-intel-next-2024-08-29' of https://gitlab.freedesktop.org/drm/i915/kernel into drm-next
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30959>
Don't claim to support extendedDynamicState3SampleLocationsEnable on pre-A650 GPUs,
which can't advertise VK_EXT_sample_locations.
Fixes dEQP-VK.info.device_mandatory_features on A6xx Gen 1 and Gen 2.
Fixes: 84726da2f4 ("tu: Implement extendedDynamicState3SampleLocationsEnable")
Signed-off-by: Valentine Burley <valentine.burley@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30730>
(cherry picked from commit 98d52cf292)
The storage allocated was always the same for both the ordinary texture
result data as well as the residency info. However, the former can be
float vector, whereas the latter is always int vector.
At least some llvm versions/builds will assert on this mismatch when
storing the data.
While here, also cut unnecessary zero initialization (lp_build_alloca()
already explicitly does this).
Fixes: 6168317b84 (lavapipe: Implement shaderResourceResidency)
Reviewed-by: Konstantin Seurer <konstantin.seurer@gmail.com>
Reviewed-by: Brian Paul <brian.paul@broadcom.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30878>
(cherry picked from commit 9b717596b2)
We put minSampleShading in the nvk_shader and [de]serialize that to/from
the binary so it also needs to go in the hash. We could also plumb the
pipeline state through to the deserialize callback but that's quite a
stretch and this literally only affects minSampleShading which is a
rarely used feature.
Fixes: 813b253939 ("nvk: Switch to shader objects")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30914>
(cherry picked from commit 5f402f3aae)
Setting it to the same value as (or higher than) the job timeout
effectively bypasses the safety mechanism.
Let's change it to `job timeout - 5min`.
Fixes: f39ffc6911 ("ci/etnaviv: Get the gc2000_piglit manual job mostly working.")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30800>
(cherry picked from commit b978d3eb54)
It was set to 170min, which made sense when the job timeout was 3h, but
then 4bb564f40d ("broadcom/ci: add more jobs to test with rpi5")
lowered the job timeout to 2h without lowering the test timeout to match.
Fixes: 4bb564f40d ("broadcom/ci: add more jobs to test with rpi5")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30800>
(cherry picked from commit aac9c74a83)
This function never expands a type - it only narrows it. As such, we
don't need to ever sign extend to fill additional new bits. I think
this code was left over from earlier versions of my optimization pass
that was buggy and trying to handle cases it should not have.
Fixes: 580e1c592d ("intel/brw: Introduce a new SSA-based copy propagation pass")
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30884>
(cherry picked from commit 51c85e0363)
This should be done after reads are checked and
sgpr_read_by_valu_as_lanemask_then_wr_by_salu is reset. The old version
also skipped checking the reads if the write check passed.
fossil-db (navi31):
Totals from 193 (0.24% of 79395) affected shaders:
Instrs: 3212435 -> 3212735 (+0.01%)
CodeSize: 16462868 -> 16463848 (+0.01%); split: -0.00%, +0.01%
Latency: 19492377 -> 19492462 (+0.00%); split: -0.00%, +0.00%
InvThroughput: 4419705 -> 4419718 (+0.00%); split: -0.00%, +0.00%
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Backport-to: 24.1
Backport-to: 24.2
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30818>
(cherry picked from commit 61e73c2323)
We observed that Venus on ANV on JSL platform has some cacheline flush
issue. The overflush shows up as:
1. There're 2 threads venus bliting the feedback buffers suballocated
from the same backing device memory, back to back.
2. On thread A, flushing the feedback buffer for cpu read is placed
behind flushing a shader storage buffer for cpu read.
3. On thread B, flushing a different feedback buffer with the same
backing device memory (different offset bound to) can kick the
feedback buffer flush in (2) earlier than it should be flushed.
4. As a result, CPU polling thread for thread B results would see venus
feedback buffer update earlier than shader storage buffer results
being updated, breaking Venus sync primitives optimization.
During investigation, a solid workaround for JSL platform is to force
Venus to align up to 128 bytes for feedback buffer suballocation while
the default is at 64 bytes.
Cc: mesa-stable
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30879>
(cherry picked from commit 7941d705c3)
If p_atomic_cmpxchg doesn't set the ray_query_shadow_bos[bucket] to new_bo
allocated by this thread, it returns the bucket BO allocated by the other
thread and we use it. But due to a mistake, we also release that BO, not
the candidate just allocated by this thread and never used again.
Fixes: 5d3e4193 ("anv: enable ray queries")
Signed-off-by: Sviatoslav Peleshko <sviatoslav.peleshko@globallogic.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30581>
(cherry picked from commit 1904fe1186)
We can't exceed c_int::MAX, because the CTS casts to ints in a few places.
We also need to take into account max pixel size when restricting to
max_mem_alloc as this cap is pixel based, not byte based.
Cc: mesa-stable
Reviewed-by: @LingMan
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30739>
(cherry picked from commit eef1af8128)
vkcube, vkgears and vkmark are crashing with the following error/segfault:
$ NVK_I_WANT_A_BROKEN_VULKAN_DRIVER=1 vkcube
WARNING: NVK is not a conformant Vulkan implementation, testing use only.
Selected GPU 0: GeForce GT 640 (NVK GK107), type: DiscreteGpu
ERROR: couldn't get DataFile for op ldc_nv
Segmentation fault (core dumped)
Handling nir_intrinsic_ldc_nv as per nir_intrinsic_load_ubo in Converter::getFile()
allows to run vkcube, vkgears and vkmark on Nvidia GT640
Fixes: dc99d9b2 ("nvk,nak: Switch to nir_intrinsic_ldc_nv")
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30832>
(cherry picked from commit 7b32df696e)
Make sure to preserve the depth or stencil components of D24S8 using the
fixed codepath just added. While we're here, fix the detection of
whether an attachment is bound.
Fixes: cb0f414b ("tu: Add support for suspending and resuming renderpasses")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26154>
(cherry picked from commit 812c8f6abe)
We need to make sure that we don't trash a passthrough depth/stencil
aspect if we need to store the whole attachment by loading it
beforehand.
Fixes: cb0f414b ("tu: Add support for suspending and resuming renderpasses")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26154>
(cherry picked from commit 5377219ca0)
At least one ray tracing shader in cp2077 is over 4MB on Xe2. There
isn't a memory pool large enough for the allocation, so the driver
crashes instead. This commit adds 8MB and 16MB pools.
I intend this as a stop gap fix. I would prefer to figure out why this
shader is so much larger than on previous platforms. The shader in
question has 3824 spills and 8625 fills. That is not good. I suspect
dealing with that will also solve the problem, but that will require a
bit more time.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/11739
Suggested-by: Lionel Landwerlin
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30751>
(cherry picked from commit 09cf9fe8ab)
We were currently emitting logical atomic instructions with a packed
destination region for sub-dword LSC atomics, along the lines of:
> untyped_atomic_logical(32) dst<1>:HF, ...
However, these instructions use an LSC data size D16U32, which means
that the 16b data on the return payload is expanded to 32b by the LSC
shared function, so we were lying to the compiler about the location
of the individual channels on the return payload, its execution
masking, etc. This is why the hacks that manually set the
'inst->size_written' of the instruction were required.
In some cases this worked, but any non-trivial manipulation of the
instruction destination by lowering or optimization passes could have
led to corruption, as has been reproduced in deqp-vk during
lower_simd_width() for shaders that use 16-bit atomics in SIMD32
dispatch mode.
Note that LSC sub-dword reads aren't affected by this because they use
raw UD destinations and specify the actual bit size of the operation
datatype as the immediate SURFACE_LOGICAL_SRC_IMM_ARG, which doesn't
work for atomic operations since that immediate specifies the atomic
opcode.
Instead, have the logical operation implement the behavior of 16-bit
destinations correctly instead of silently replacing the 16-bit region
with an inconsistent 32-bit region -- This is done by emitting the MOV
instructions used to pack the data from the UD temporary into the
packed destination from the lower_logical_sends() pass instead of from
the NIR translation pass.
Fixes: 43169dbbe5 ("intel/compiler: Support 16 bit float ops")
Reviewed-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/30683>
(cherry picked from commit 71ca8529c5)
this pbo shader works by iterating over the framebuffer size
and storing a value to an offset for each source pixel. if the
number of pixels being written out does not correspond to fragcoord
to the extent that certain source pixels are not written at all, however,
then this method should not be used in order to avoid giving broken results
cc: mesa-stable
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30689>
(cherry picked from commit c2dcecffc5)
SBID SET can only be used on SEND, SENDC, or DPAS instructions. The
existing code was handling SET for SEND/SENDC, but was using the wrong
encoding for DPAS. Add a new case to handle that and make it clear that
the existing code is only for SEND/SENDC.
While here, rewrite the encoder to use 2-bit binary immediates shifted
up into the mode [9:8] field, rather than pre-shifted hex values. This
matches the documentation better and is a little easier to follow.
On the decode side, we were incorrectly decoding MATH instructions.
Because they're marked is_unordered, we were hitting the SEND/SENDC
decoding, which is incorrect for MATH.
Fixes 22 cooperative matrix tests on Lunar Lake.
Huge thanks to Paulo Zanoni for bisecting failures to one of my commits,
then analyzing shaders and experimenting to discover that the failure
was really an unrelated bug, just being provoked by different choices of
registers. His work narrowing the problem down made it much easier to
discover and fix this bug.
Backport-to: 24.2
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30705>
(cherry picked from commit d22d6d814d)
This commit solves the shortage-problem at the blit-functions by
checking the number of fence-registers after updating the batch.
If too many registers are used,
the batch-entries and relocs for the current blit function are
removed by setting batch->ptr and reloc_count to value before
the blit call and calling drm_intel_gem_bo_clear_relocs.
This truncated batch is flushed,
and the batch is updated again for the current blit function.
Cc: mesa-stable
Signed-off-by: GKraats <vd.kraats@hccnet.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26769>
(cherry picked from commit ed2123158d)
out_args->scratch_offset and in_wg_id_x will alias on <gfx9.
To avoid the conversion code reading a garbage WG ID, move the
scratch/ring offset writing to the very end.
Fixes: 1e354172 ("radv,aco: Convert 1D ray launches to 2D")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30707>
(cherry picked from commit bd525f4282)
Make sure to take new GRF size into consideration and adjust the
indirect offset according to new size so that when we do the indirect
load with address register, we load right values.
This helps pass the following tests:
- dEQP-VK.binding_model.descriptor_buffer.mutable_descriptor.*geom*
- dEQP-VK.ray_query.*geometry_shader.*
Backport-to: 24.2
Signed-off-by: Sagar Ghuge <sagar.ghuge@intel.com>
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30679>
(cherry picked from commit c4f2a8d984)
Similar to commit 6cef804067 ("nir/opt_if: fix opt_if_merge when
destination branch has a jump"), we shouldn't combine if statements when
the second if-then-else has a block that ends in a jump.
This fixes a case where opt_if_merge combines
if (cond) {
[then-block-1]
} else {
[else-block-1]
}
if (cond) {
[then-block-2]
} else {
[else-block-2]
}
where `then-block-2` or `else-block-2` ends in a jump. The phi nodes
following the control flow will be incorrectly updated to have an input
from a block that is not a predecessor.
Fixes: 4d3f6cb973 ("nir: merge some basic consecutive ifs")
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30629>
(cherry picked from commit d2e6be94ae)
Before we were using direct CP_LOAD_STATE, which is broken with multiple
back-to-back draws. This caused regressions in some DX11 traces when
enabling early preamble. We still need to use indirect CP_LOAD_STATE for
VS params, which are sometimes written by the CP, however for everything
else we should use the new UBO path instead.
Fixes: 76e417ca59 ("turnip,ir3/a750: Implement consts loading via preamble")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30675>
(cherry picked from commit 850f2aab03)
It's one header dword and 5 payload dwords. This was papered over by us
not actually using the UBO path for one of the loads, but that's changed
in the next commit.
Fixes: 76e417ca59 ("turnip,ir3/a750: Implement consts loading via preamble")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30675>
(cherry picked from commit 4f2b5442a6)
After spilling during regular RA, merge sets need to be fixed up. To
find all merge sets, fixup_merge_sets used ra_foreach_dst. However,
after shared RA has run, shared dsts wouldn't have the IR3_REG_SSA flag
set anymore leaving their merge sets lingering. This patch fixes this by
using foreach_dst instead.
Fixes: fa22b0901a ("ir3/ra: Add specialized shared register RA/spilling")
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28341>
(cherry picked from commit 28d2a27030)
The preferred register for merge sets was not updated after allocating
one. This caused a new merge set to be allocated for every register it
contains. This patch fixes this by reusing the update function from the
standard RA.
Fixes: fa22b0901a ("ir3/ra: Add specialized shared register RA/spilling")
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28341>
(cherry picked from commit 9013e11d8c)
Bspec 57508: Structure_SIMD16TraceRayMessage:: RayQuery Enable
"When this bit is set in the header, Trace Ray Message behaves like a
Ray Query. This message requires a write-back message indicating
RayQuery for all valid Rays (SIMD lanes) have completed."
If we don't pass the write-back register, somehow it was stepping on
over R0 register and can mess up the scratch space accesses which could
potentially lead to GPU hang. It can be noticed while running it under
simulator trace.
send.rta (16|M0) null r124 r126:1 0x0 0x02000100 {$15} // wr:1+1, rd:0; simd16 trace ray
R0 = 00000001 00000000 00000000 00000001 00000000 00000000 00000001 00000000 00000000 00000001 00000000 00000000 00000001 00000000 00000000 00000001
Signed-off-by: Sagar Ghuge <sagar.ghuge@intel.com>
Suggested-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30600>
(cherry picked from commit c3c62e493f)
Previously only `-mtls-dialect=gnu2` was probed, which was appropriate
for arm, x86 and x86_64, but not for newer architectures such as
aarch64, loongarch64 and riscv64 which all use `-mtls-dialect=desc`
instead. Because the driver option is not consistent across
architectures (and probably will not), try both variants and choose the
first one working.
While at it, rename "gnu2_*" variables to "tlsdesc_*" respectively, for
clarity.
Cc: mesa-stable
Reviewed-by: Icenowy Zheng <uwu@icenowy.me>
Reviewed-by: Yukari Chiba <i@0x7f.cc>
Reviewed-by: David Heidelberg <david@ixit.cz>
Signed-off-by: WANG Xuerui <git@xen0n.name>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30599>
(cherry picked from commit cc2dbb8ea5)
Although the ORCJIT codepath is fresh and relatively less tested, this
is still better than no llvmpipe at all for those newer architectures
that will not gain MCJIT support, such as LoongArch or RISC-V.
Fixes: 6f02ec5ed1 ("llvmpipe: add an implementation with llvm orcjit")
Reviewed-by: Icenowy Zheng <uwu@icenowy.me>
Reviewed-by: Yukari Chiba <i@0x7f.cc>
Reviewed-by: David Heidelberg <david@ixit.cz>
Signed-off-by: WANG Xuerui <git@xen0n.name>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30599>
(cherry picked from commit 56f38672a2)
This is unneeded in some environments, like ChromeOS and Android. And
for CrOS it specifically causes problems with the gpu sandbox rules.. we
don't want to have to update the sandbox rules for each new mesa
version.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30579>
(cherry picked from commit 19ff16387a)
The ownership of the TargetMachine object is released when LPJit
singleton is constructed, leads to a slight memory loss detectable.
Keep the ownership by saving the unique pointer as another class member
named tm_unique.
Signed-off-by: Icenowy Zheng <uwu@icenowy.me>
Reviewed-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit 3423e73cec)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30645>
The `capture_not_overwritten` unit test captures and compares two
backtraces -- one from inside a call to `func_c` and one outside -- and
confirms that they are not identical. That is, that `func_c` is in the
backtrace.
On 32-bit x86, without `-fno-omit-frame-pointer`, the function will not
emit a stack frame. As a result, the unit test fails.
The fix is to compile `func_c` with the flag `-fno-omit-frame-pointer`
to prevent the compiler from optimizing out the stack frame which is
otherwise unneeded.
Bug: https://bugs.gentoo.org/823774
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4091
Fixes: d0d14f3f64 ("util: Add unit test for stack backtrace caputure")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30622>
(cherry picked from commit 05dc4eb536)
the CL CTS added a new test being printf("\n", "foo"), but we ended up
printing the new line twice. If we can't find a specifier anymore, ignore
the argument as after the loop processing all arguments we'll print the
remaining format string anyway.
Cc: mesa-stable
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30574>
(cherry picked from commit 4080269845)
Instead of aligning offsets, we just align the size every time we query
it. This simplifies our offset and size calculations later since we can
always just add up descriptor buffer sizes and know that we'll be okay.
Acked-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Fixes: 7ab5c5d36d ("zink: use EXT_descriptor_buffer with ZINK_DESCRIPTORS=db")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30580>
(cherry picked from commit 0f8f407e57)
There are two problems.
1. This is not NaN safe. 'add.le.sat dst F, Inf F, -Inf F' has a
different result than 'add dst F, Inf F, -Inf F; cmp.le null, dst F, 0F'.
2. Ignoring the first problem, this only produces the desired flags
for LE and G. All other cases can produce the wrong result.
shader-db:
All Intel platforms had similar results. (Broadwell shown)
total instructions in shared programs: 18282314 -> 18282316 (<.01%)
instructions in affected programs: 78 -> 80 (2.56%)
helped: 0
HURT: 2
total cycles in shared programs: 952924234 -> 952924252 (<.01%)
cycles in affected programs: 584 -> 602 (3.08%)
helped: 0
HURT: 2
Fixes: e6022281f2 ("intel/elk: Rename files to use elk prefix")
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29774>
(cherry picked from commit 9125b7c1b4)
There are two problems.
1. This is not NaN safe. 'add.le.sat dst F, Inf F, -Inf F' has a
different result than 'add dst F, Inf F, -Inf F; cmp.le null, dst F, 0F'.
2. Ignoring the first problem, this only produces the desired flags
for LE and G. All other cases can produce the wrong result.
For example, batman_arkham_city_goty.foz 6a63c4caacaa0dae has the
following code:
mad.ge.f0.0(8) g51<1>F g50<8,8,1>F g46<8,8,1>F g11<1,1,1>F
mov.sat(8) g52<1>F g51<1,1,0>F
...
(+f0.0) sel(8) g54<1>UD g53<8,8,1>UD 0x3f000000UD
Without this commit, the saturate is incorrectly propagated to the MAD.
A similar case exists in witcher_3_dxvk_g2.foz 5b03243be667a275.
There are even worse cases like total_war_warhammer3.dx12vk-g6.foz
78328466761ef7ab and ee920491573860fc. The former has the following
code (and the latter has very similar code):
mad.l.f0.0(16) g95<1>F g93<8,8,1>F g62<8,8,1>F g68<1,1,1>F
...
mov.sat(16) g109<1>F -g95<1,1,0>F
...
(+f0.0) sel(16) g68<1>UD g111<1,1,0>UD g54<1,1,0>UD
(+f0.0) sel(16) g70<1>UD g113<1,1,0>UD g56<1,1,0>UD
(+f0.0) sel(16) g72<1>UD g115<1,1,0>UD g58<1,1,0>UD
Saturate propagation makes a hash of this code:
mad.sat.l.f0.0(16) g106<1>F -g93<8,8,1>F -g62<8,8,1>F g68<1,1,1>F
...
(+f0.0) sel(16) g70<1>UD g110<1,1,0>UD g56<1,1,0>UD
(+f0.0) sel(16) g72<1>UD g112<1,1,0>UD g58<1,1,0>UD
(+f0.0) sel(16) g68<1>UD g108<1,1,0>UD g54<1,1,0>UD
Not only is the saturate incorrectly applied to the MAD, but the MAD
result is negated without changing the conditional modifier to G!
NOTE: Backports of this commit to stable branches may need to be more
like the following commit to elk.
shader-db:
All Intel platforms had similar results. (Meteor Lake shown)
total instructions in shared programs: 19729375 -> 19729377 (<.01%)
instructions in affected programs: 112 -> 114 (1.79%)
helped: 0
HURT: 2
total cycles in shared programs: 916234266 -> 916234288 (<.01%)
cycles in affected programs: 636 -> 658 (3.46%)
helped: 0
HURT: 2
fossil-db:
All Intel platforms had similar results. (Meteor Lake shown)
Totals:
Instrs: 151531594 -> 151531601 (+0.00%)
Cycle count: 17209107419 -> 17209107474 (+0.00%); split: -0.00%, +0.00%
Totals from 6 (0.00% of 630198) affected shaders:
Instrs: 4550 -> 4557 (+0.15%)
Cycle count: 194629 -> 194684 (+0.03%); split: -0.00%, +0.03%
Fixes: 947c828d5c ("i965/fs: Add a saturation propagation optimization pass.")
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29774>
(cherry picked from commit 3d8fea0e09)
Using ior here is equivalent to using uadd_sat, but works for every driver
and shouldn't hurt anywhere.
I forgot to fix this up when fixing up some vvl errors with zink.
Fixes crashes with the integer_ctz CL CTS tests in zink.
Fixes: 39ec184db6 ("zink: lower 64 bit find_lsb, ufind_msb and bit_count")
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30535>
(cherry picked from commit 48acf9d358)
* close(fd) requires also resetting the fd=-1 or else boom
* checking just driver_name is broken because loader_get_driver_for_fd()
uses MESA_LOADER_DRIVER_OVERRIDE, so there's no way to differentiate
an inferred load
Fixes: b907eb4750 ("egl: don't bind zink under dri2/3")
Acked-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30556>
(cherry picked from commit 1a579552af)
The CL CTS started to call this API, luckily we don't have to actually
implement it, because we don't intent to support CL 1.0 only devices in
the first place (probably).
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30575>
(cherry picked from commit cd2dc4f70c)
For some purposes (e.g. advanced blending) we need a non-zero alpha
value returned from reads. This is only guaranteed on Bifrost if
we explicitly request RGB1 component ordering. The default is to use
RGBA component ordering, which for R5G6B5 causes 0 to be read for
alpha.
A complication is that the Mali fixed function hardware requires
four components (which implies RGBA rather than RGB1). If fixed
function blending is in use, we modify the pixel format back to
RGBA when building the blend descriptor.
Cc: mesa-stable
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29606>
(cherry picked from commit 004e0eb3ab)
We have to swizzle the border color in order to offset the
automatic swizzling introduced to compensate for limited
component order support in AFBC/AFRC. However, the border color
format is only available if the `TEXTURE_BORDER_COLOR_QUIRK` is
enabled, so set that for v10 (it was already set for v7).
While testing, we uncovered another issue: valhall introduces a
swizzle for depth+stencil formats that isn't present for bifrost, and
also isn't needed (or wanted) for the border color. So ignore the
border color swizzle for depth+stencil on valhall (on bifrost the
swizzle is a no-op anyway).
Fixes: 87aad0a5e4 ("panfrost: encode component order as an inverted swizzle (v10)")
Reviewed-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30542>
(cherry picked from commit 3135f76331)
Before the patch, intel_device_info_get_max_preferred_slm_size()
returns values in kilobytes, but then
intel_device_info_get_max_slm_size() is multiplying it by 1024.
As a result, LNL is reporting maxComputeSharedMemorySize to be
134217728, which is 128mb.
Fix this by making intel_device_info_get_max_slm_size() not multiply
it by 1024.
This should fix at least the following dEQP tests:
dEQP-VK.compute.pipeline.zero_initialize_workgroup_memory.max_workgroup_memory.1
dEQP-VK.compute.pipeline.zero_initialize_workgroup_memory.max_workgroup_memory.128
dEQP-VK.compute.pipeline.zero_initialize_workgroup_memory.max_workgroup_memory.16
dEQP-VK.compute.pipeline.zero_initialize_workgroup_memory.max_workgroup_memory.2
dEQP-VK.compute.pipeline.zero_initialize_workgroup_memory.max_workgroup_memory.4
dEQP-VK.compute.pipeline.zero_initialize_workgroup_memory.max_workgroup_memory.64
Some tests were failing with:
deqp-vk: ../../src/intel/common/intel_compute_slm.c:24: slm_encode_lookup: Assertion `kbytes <= table[table_len - 1].size_in_kb' failed.
while other tests were triggering the OOM.
v2:
- Make everybody return sizes in bytes (José).
v3:
- Rename variable to bytes (José, Jordan).
Fixes: fd368f5521 ("anv: Set maxComputeSharedMemorySize value for Xe2 platforms")
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30541>
(cherry picked from commit 0e38b794e2)
This reverts commit d6bb4ddc63.
Fixes: d6bb4ddc63 ("d3d12: Video Encode - Remove PIPE_VIDEO_PROFILE_MPEG4_AVC_BASELINE as not supported")
PIPE_VIDEO_PROFILE_MPEG4_AVC_BASELINE is necessary for some scenarios like the example below
described in https://github.com/microsoft/WSL/issues/11838
gst-launch-1.0 -v videotestsrc num-buffers=250 !
video/x-raw,width=1920,height=1200 !
vaapipostproc !
vaapih264enc !
filesink location=~/wsl_test.h264
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30548>
(cherry picked from commit a0f1a708c4)
This is more correct than the previous code and the CL CTS relies on edge
case behavior here, e.g. for 1Dbuffer images.
I think part of that is not actually required by the spec, but whatever.
Fixes: 7b22bc617b ("rusticl/memory: complete rework on how mapping is implemented")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30528>
(cherry picked from commit 2484331e82)
An application could map and unmap a host ptr allocation multiple times,
but because how the refcounting works, we might never ended up syncing the
written data to the mapped region.
This moves the refcounting out of the event processing.
Fixes: 7b22bc617b ("rusticl/memory: complete rework on how mapping is implemented")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30528>
(cherry picked from commit 1fa288b224)
If TraceRay() is called with the TerminateOnFirstHit flag, we need to
terminate the ray on the first confirmed intersection. This is handled
by the lowering of accept_ray_intersection and it's working fine for the
case of multiple instances of the intersection shader being called.
But if the shader calls reportIntersection() more than once, we were
handling them all and accepting the closest one regardless of the flag.
Check for the flag on every confirmed intersection and, if set, accept
it right there. The subsequent lowering will take care of terminating
handling the ray termination if necessary.
Fixes new test dEQP-VK.ray_tracing_pipeline.amber.flags-accept-first
Cc: mesa-stable
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30418>
(cherry picked from commit f8553f56ac)
this had a number of issues:
* pipe_loader_get_driinfo_xml() frees driver_driconf immediately,
except the driOptionCache struct string pointers are all just copied
in merge_driconf instead of having the strings copied, which means any
subsequent access of driver_driconf strings is invalid access
* pipe_loader_drm_get_driconf_by_name() is a disaster that only happened
to work because the dlopen here is the same lib that gets opened elsewhere
by mesa and not closed. if the lib here is actually closed, then all
the statically allocated strings become invalid, which means they need to
be manually copied
cc: mesa-stable
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30494>
(cherry picked from commit 0c220741e6)
Consolidate the various uses of CP_EVENT_WRITE into helpers, and use use
fd_gpu_event to manage the differences between a6xx and a7xx. This is a
bit churny as it spreading a fair bit of the CHIP template param around.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30304>
(cherry picked from commit 1f41d59059)
Previously this check would create a mask of the bytes used in the
grf, and then shift the mask. This worked well when there was 32 bytes
in the register because a 64-bit uint64_t could easily detect that
bytes were used in the next regiter. (The next register was the high
32-bits of the `access_mask` variable.)
With Xe2, the register size becomes 64 bytes, meaning this strategy
doesn't work. Instead of a mask, we can just check to see if more than
1 grfs are used during each loop iteration. (Suggested by Ken.) This
will make it easier to extend for Xe2 in a follow on commit.
Verified this with
dEQP-VK.subgroups.arithmetic.compute.subgroupexclusivemul_u64vec4_requiredsubgroupsize
on Xe2, which otherwise would cause the program to fail to validate
because it assumed a grf was 32 bytes.
Backport-to: 24.2
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28479>
(cherry picked from commit f2800deacb)
previously the size was checked at the top of the function, but this
ignored cases where the loader might end up resizing the drawable,
resulting in an attempted 0x0 swapchain creation based on stale
geometry
cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30487>
(cherry picked from commit a6d97b0afe)
The user is allowed to pass a list of modifiers including
DRM_FORMAT_MOD_INVALID, meaning that the user is OK with implicit
modifiers. Since merging the DRI interfaces, this assert that we are
never returning an implicit modifier is unnecessary and also wrong. It
was originally added to be super-safe, but we now know that our drivers
work very well with modifiers, so don't need it.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Fixes: 0b16d7ebb9 ("dri: Allow INVALID for modifier-less drivers")
Closes: mesa/mesa#11591
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30464>
(cherry picked from commit cd961a7e3f)
The iova allocations need to be CPU page aligned. (The GPU itself
always supports 4k mappings regardless of the smallest CPU page size,
but GEM buffer allocations must be an integer number of CPU pages.)
Signed-off-by: Rob Clark <robdclark@chromium.org>
Fixes: 63904240f2 ("tu: Re-enable bufferDeviceAddressCaptureReplay")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30431>
(cherry picked from commit 7fe3529715)
The condition of flat ccs and vram_only checker causes different
aux usage at binding stage. The current design is reusing CCS_E
on Xe2, so we want both Xe2 integrated and discreted GPUs behave
the same way.
Xe2 shouldn't need any special setup of CCS in the loop.
Backport-to: 24.2
Signed-off-by: Jianxun Zhang <jianxun.zhang@intel.com>
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30111>
(cherry picked from commit c5ee7e9bdc)
On pre-Xe2 platforms, the compression on these modifiers that
don't support compression are enabled. The compressed will be
resolved when needed. On Xe2+ we haven't support explicit
resolve, so all the paths to resolves are prohibited now. But
the code is still doing it, causing an assertion failure:
Fixes: vkcube
src/intel/vulkan/anv_private.h:5467:
anv_image_get_fast_clear_type_addr: Assertion
`device->info->ver < 20' failed.
Backport-to: 24.2
Signed-off-by: Jianxun Zhang <jianxun.zhang@intel.com>
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30111>
(cherry picked from commit e054068787)
Users get the deprecation warning but didn't do anything, they left
things to `auto` and we pick the deprecated `swrast`? Hardly seems fair!
(I forgot to do this when I added the deprecation warning to ajax's commit)
Fixes: 010b2f9497 ("gallium/meson: Deconflate swrast/softpipe/llvmpipe")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30366>
(cherry picked from commit 77b69cdbc3)
`st_context_invalidate_state` call is required when changing buffer attachments.
Including header with BBitmap class definition is required to properly
call C++ destructor.
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30372>
(cherry picked from commit 828c3cf002)
If the user passes in DRM_FORMAT_MOD_INVALID as an acceptable modifier,
we can progress with implicit modifiers. Add this to a more
comprehensive special case along with linear to make sure that we can
still allocate when users pass in a modifier list to a driver which
doesn't support modifiers.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Fixes: 361f362258 ("dri: Unify createImage and createImageWithModifiers")
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30383>
(cherry picked from commit 0b16d7ebb9)
Contrary to what the original commit said, this is actually still used
(see .gitlab-ci/bare-metal/poe-powered.sh:205), and the boot retry logic
has been broken ever since, exacerbating the rpi farm boot problems.
Fixes: 97b2afa16a ("ci/bare-metal: Drop the 2 vs 1 exit code from poe_run.")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30340>
(cherry picked from commit 2bc82b7147)
At update_map at i915_state_sampler.c max_lod is no longer set to 1
for npots. This almost totally disabled mipmapping.
Max_lod should still be set to 1, but only if it is still 0,
because no mipmap-levels are present.
According to existing comment at update_map this is needed, to
avoid problems at sampling,
if MIN_FILTER and MAX_FILTER differ.
Cc: mesa-stable
Signed-off-by: GKraats <vd.kraats@hccnet.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28638>
(cherry picked from commit ad02bfe41d)
Remove at i945_texture_layout_2d() call of util_next_power_of_two(),
which oversized the npot-blocks for every level to get power of 2
for width and height. Hardware doesnot expect these oversized
npot-blocks, causing mangled mipmapping.
This also is done at i915_texture_layout_2d(), which is
used by older gen3-gpus.
Cc: mesa-stable
Signed-off-by: GKraats <vd.kraats@hccnet.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28638>
(cherry picked from commit bb95d744ca)
After using sparse array to manager virtgpu bo, we set gem_handle to 0
to indicate that the bo is invalid. However, the gem handle gets closed
before that and can be reused by another newly created bo, leading to
the tracked gem handle being unexpectedly zero'ed out.
Fixes: 88f481dd74 ("venus: make sure gem_handle and vn_renderer_bo are 1:1")
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30362>
(cherry picked from commit f788c87d02)
the original implementation of config selection had a number of flaws:
* using eglChooseConfigs with lots of loops, which was okay for filtering but
also added considerable complexity and made it difficult to correctly
get all the configs
* not adding enough configs; there were a lot more color and zs formats
which weren't in the base config list
* double buffer configs were never created
* srgb configs were also never created
there will now be fewer configs than there were pre-DRIL, but this is only
because accum buffers are now gone and not because anything of value is
missing
Fixes: 3de62b2f9a ("gallium/dril: Compatibility stub for the legacy DRI loader interface")
Acked-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30311>
(cherry picked from commit ec7afd2c24)
From all the many possible errors returned by the vm_bind ioctl, some
can actually happen in the wild when the system is under memory
pressure. Thomas Hellström pointed to us that, due to its asynchronous
nature, the vm_bind ioctl itself has to pin some memory, so if the
number of bind operations passed is too big, there is a probability
that it may run out of memory.
Previously the Kernel would return ENOMEM when this condition
happened. Since commit e8babb280b5e ("drm/xe: Convert multiple bind
ops into single job") the Kernel has started returning ENOBUFS when it
doesn't have enough memory to do what it wants but thinks we'd succeed
if we tried to do one bind operation at a time (instead of doing
multiple operations in the same ioctl), and ENOMEM in some other
situations. Still-uncommitted commit "drm/xe: Return -ENOBUFS if a
kmalloc fails which is tied to an array of binds" proposes converting
a few more ENOMEM cases no ENOBUFS.
Still, even ENOMEM situations could in theory be possible to recover
from, because if we wait some amount of time, resources that may have
been consuming memory could end up being freed by other threads or
processes, allowing the operations to succeed. So our main idea in
this patch is that we treat both ENOMEM and ENOBUFS in the same way,
so our implementation can work with any xe.ko driver regardless of
having or not having the commits mentioned above.
So in this patch, when we detect the system is under memory pressure
(i.e., the vm_bind() function returns VK_ERROR_OUT_OF_HOST_MEMORY), we
throw away our performance expectations and try to go slowly and
steady. First we wait everything we're supposed to wait (hoping that
this alone could also help to alleviate the memory pressure), and then
we synchronously bind one piece at a time (as this will ensure ENOBUFS
can't be returned), hoping that this won't cause the Kernel to try to
reserve too much memory. All this while also hoping that whatever
thing that may be eating all the memory goes away in the meantime. If
even this fails, we give up and hope the upper layer will be able to
figure out what to do.
This fixes a bunch of LNL failures and flaky tests (as LNL is our
first officially supported xe.ko platform). This can be seen in dEQP
but only if multiple tests are being run parallel. Happens in multiple
tests, some of which may include:
- dEQP-VK.sparse_resources.image_sparse_binding.2d_array.rgba8_snorm.1024_128_8
- dEQP-VK.sparse_resources.image_sparse_binding.3d.rgba16_snorm.1024_128_8
- dEQP-VK.sparse_resources.image_sparse_binding.3d.rgba16ui.512_256_6
I don't ever see these errors when running Alchemist/DG2 with xe.ko.
Fixes: e9f63df2f2 ("intel/dev: Enable LNL PCI IDs without INTEL_FORCE_PROBE")
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30276>
(cherry picked from commit dd5362c78a)
We cannot always use /dev/dri/card0.
As a matter of fact, on systems with SimpleDRM enabled /dev/dri/card0
will be created by it and removed once a GPU driver has loaded.
In any case we shouldn't hard-code the device number and instead walk
the device list to find the first suitable device.
This issue is trivially reproducible with `eglinfo -B -p gbm` on
Ubuntu 24.04 or Fedora 40
Fixes: 32f4cf3808 ("egl/gbm: Fix EGL_DEFAULT_DISPLAY")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30325>
(cherry picked from commit 7949471716)
Installing this private library into the default library
search path avoids needing to rely on -Wl,-rpath,
which is inconsistently implemented as either DT_RUNPATH
or DT_RPATH on different distributions; in particular,
on distributions that implement it as DT_RPATH,
it interferes with use of LD_LIBRARY_PATH and has semantics
that are difficult to reason about, and is incompatible with
Steam's container runtime (which has the known limitation that
it only implements DT_RUNPATH and not DT_RPATH).
To avoid third-party developers being tempted to link to the
unstable libgallium, give it a name that varies with each Mesa release,
so that there is no obvious way for third-party software to link to it.
This is similar to the way the proprietary Nvidia driver sets up its similar
implementation-detail libraries such as libnvidia-glcore.so.535.183.01.
Fixes: 50fc7cc2 ("glx: directly link to gallium")
Acked-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30328>
(cherry picked from commit 9b7bb6cc9f)
Thanks to LCSSA, we can absolutely have phis with only one source and we
need to handle those in spilling. Fortunately, there's nothing really
special about that case. I was just prematurely optimizing.
Fixes: bcad2add47 ("nak: Add a spilling pass")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28084>
(cherry picked from commit 8bf3213a54)
So that the depfile contains a reference to the original source rather
than the copied one. This is necessary to avoid ninja not finding the
copy and causing spurious rebuilds when the copy has been removed, as
well as correctly tracking changes to the input files.
fixes: 46644ba371
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30132>
(cherry picked from commit 36160c967c)
Fix to call vn_image_bind_wsi_memory as long as the image is a wsi
image. This is needed so that we track the wsi memory in the wsi image
so that creating from swapchain info works normally on x11/wayland
platforms. This change also make it clear that ANB image owns the wsi
memory
Fixes: c4b30b604f ("venus: support VK_ANDROID_NATIVE_BUFFER_SPEC_VERSION 8")
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30278>
(cherry picked from commit a27e3c5078)
Even though we don't advertise the sparseResidency feature, a bunch of
CTS tests just call GetPhysicalDeviceImageFormatProperties2() with
SPARSE_RESIDENCY_BIT and see if that fails.
Fixes: d2177f4764 ("nvk: Don't advertise sparse residency on Maxwell A")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30303>
(cherry picked from commit 68d6cdfbc5)
This fixes sporadic rendering corruption reported on MTL with ChromeOS
in cases where multiple processes including Chrome were utilizing the
GPU concurrently, and one of the processes happened to submit a
BLORP-only batch buffer right after a switch from a different context.
In such a scenario we would fail to add the BO that holds the pixel
hashing tables to the execbuf IOCTL for the BLORP batch, because it
was being pinned from iris_restore_render_saved_bos() which isn't
called for BLORP operations, potentially causing it to use garbage as
pixel pipe hashing tables, which led to corruption of the BLORP
rendering.
Technically this could have affected DG2 as well, but it has only been
reported on MTL so far.
Cc: mesa-stable
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Tested-by: Sushma Venkatesh Reddy <sushma.venkatesh.reddy@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30274>
(cherry picked from commit 49b433d5e7)
It doesn't do anything substantial yet, but it ignores enough so internal
shaders won't generate warnings.
I've also added ByVal parsing, because I need this one to actually fix a
correctness issue in a later patch.
Cc: mesa-stable
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29896>
(cherry picked from commit 9b55dcca54)
We want to use actual sparse-capable queues as the default
trtt->queue, not copy queues that may have a companion_rcs_batch.
Before this patch, if we expose more than one queue *and* the
application creates a copy queue first, we'll end up setting
trtt->queue as the copy queue, which will GPU hang when we submit the
TR-TT batches as they don't support the pipe_control commands we
issue.
The trtt->queue queue is used for binding/unbinding buffers in code
paths where there's no specific queue coming from user space, such as
when we're creating or destroying a sparse resource.
This is not a problem yet on i915.ko since we are exposing
only a single queue, and it is not a problem for xe.ko since TR-TT is
not the default there. This is also not a problem in applications
that create the render or compute queue first. We plan to expose more
queues when using TR-TT, so this would become a problem without this
patch.
None of VK-GL-CTS seems to exercise that, and none of the Steam games
I tested exercise that as well. I was able to reproduce this issue
using our internal tracing tool.
v2: New implementation that doesn't break when we only have a compute
queue (Lionel).
Fixes: 04bfe828db ("anv/sparse: allow sparse resouces to use TR-TT as its backend")
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30252>
(cherry picked from commit 3ab8ff99fa)
On MTL ChromeOS boards, during AI based video conference, we were
observing a lot of overhead from invalidations. Upon debug, it was found
that we were using clflush in this function and that isn't efficient.
With this change, while executing compute workloads like zoo models, we
are getting ~25% performance improvements in a best case scenario.
Rework:
* Jordan: Call intel_clflushopt_range() rather than
__builtin_ia32_clflushopt() because intel_mem.c is not compiled
with -mclflushopt.
Backport-to: 24.1 24.2
Signed-off-by: Sushma Venkatesh Reddy <sushma.venkatesh.reddy@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30238>
(cherry picked from commit 2f6919e6c2)
Despite its name, egl_dri2 works under plain DRI without DRI2, and the
old autotools build system built it when $enable_dri = yes, with no
check for DRI2. This fixes the build for GNU/Hurd, which supports DRI,
but doesn't have DRM and thus no DRI2 support.
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/587>
(cherry picked from commit 149e8bff52)
This reverts commit ad862c36e5.
This change does not work, because libdrm is required if with_dri2 is
true. Moreover, we don't want all of DRI2 on Hurd, we just want the
egl_dri2 driver, as done by autotools. So first revert this to stop
trying to build all of DRI2.
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/587>
(cherry picked from commit ec55a6c329)
This reverts commit 2fd85105c6.
Despite its name, egl_dri2 works under plain DRI without DRI2, and the
old autotools build system built it when $enable_dri = yes, with no
check for DRI2. A future commit will adapt meson.build to follow that
approach rather than this hackier one.
Note that the case removed in the second hunk is already dead code,
since system_has_kms_drm is false on GNU/Hurd, and could have been
dropped as part of 66d2ae0386 ("meson: forcefully disable libdrm when
host doesn't have it").
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/587>
(cherry picked from commit 8461776a09)
This implements an undocumented workaround for a hardware bug that
affects draw calls with a pixel shader that has 0 push constant cycles
when TBIMR is enabled, which has been seen to lead to a hang with
Fallout 3 and Metal Gear Rising Revengeance. This hardware bug has
been reported as HSDES#22020184996 which is still pending a resolution
by the hardware team. However since this workaround found empirically
has been confirmed to fix the issue reliably and it's relatively
harmless it seems worth checking in already even though no final W/A
number is available nor has the W/A json file been updated.
To avoid the issue we simply pad the push constant payload to be at
least 1 register. This is enabled via a brw_wm_prog_key since the
driver needs to be in agreement with the compiler on whether the dummy
push constant cycle is present, and it can be avoided in cases where
the driver knows that TBIMR will be disabled (e.g. for BLORP).
Related: https://gitlab.freedesktop.org/mesa/mesa/-/issues/10728
Related: https://gitlab.freedesktop.org/mesa/mesa/-/issues/11399
Fixes: 57decad976 ("intel/xehp: Enable TBIMR by default.")
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30031>
(cherry picked from commit b98eebbcb2)
Sporadically a6xx gpu will fail to recover causing the lava job
a660_vk_full to loop on error messages for three hours before timing
out.
A few sporadic error messages may still be recoverable, but when multiple
errors occur over a short period, successful recovery is unlikely. Parse
the logs to look for repeated error messages within a short time period.
If found, cancel the lava job and rerun it.
Also add unit tests for this behaviour.
cc: mesa-stable
Reported-by: Valentine Burley <valentine.burley@gmail.com>
Acked-by: Daniel Stone <daniel.stone@collabora.com>
Reviewed-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Signed-off-by: Deborah Brouwer <deborah.brouwer@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30032>
(cherry picked from commit 72c182f873)
# Bring artifacts back from the NFS dir to the build dir where gitlab-runner
# will look for them.
cp -Rp /nfs/results/. results/
section_end dut_cleanup
if[ -f "${STRUCTURED_LOG_FILE}"];then
cp -p ${STRUCTURED_LOG_FILE} results/
echo"Structured log file is available at https://${CI_PROJECT_ROOT_NAMESPACE}.pages.freedesktop.org/-/${CI_PROJECT_NAME}/-/jobs/${CI_JOB_ID}/artifacts/results/${STRUCTURED_LOG_FILE}"
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
