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)
This reverts commit 032d4a20f9.
The `if not to_cancel: return` was a red herring as what actually matters
is the job status, which is checked in each cancel_job() call, so we
can't know in advance whether anything will be cancelled, so let's just
drop this text explanation.
In the meantime we've also improved the emoji next to cancelled jobs, so
let's hope there is no longer any need to explain what this long list of
job names means.
Fixes: 032d4a20f9 ("bin/ci_run_n_monitor: explain that the 'Universal Recycling symbol' ♲ emoji means these jobs were cancelled")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30265>
Instead of having a hardcoded table to convert between sRGB formats and
their linear-gamma equivalents (and vice-versa), generate this from the
information in the format table.
This requires adding a 'sublayout' attribute to differentiate between,
e.g. DXT1 and DXT3, which otherwise appear to be equivalent but for
their name prefix.
As an anonymous union is being used, we also need named initialisers for
the util_format_description entries.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29649>
u_format has always had its format table in CSV. This is kind of nice
for some things, but is a serious pain to extend, especially with
optional fields.
In going through our many (many, many) duplicated tables of format
mappings, it would've been nice to add some descriptions to our central
u_format table, such as mapping to DRM FourCC, to EGLImage mappings, and
to GL internalformats for EGLImage imports. Unfortunately, doing so with
more additional fields would just make the CSV totally unreadable.
Move the CSV table to a YAML-based table and adjust the Python parsers
to suit. The resulting generated files are identical before and after
the transition.
The new parser also has a significant amount of format validation to
make it easier to catch common errors.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29649>
Pretty big change... Sorry for that.
I can't exactly remember why I created 2 heaps. I think it's because I
mistakenly thought the samplers in the binding sampler pointers needed
to be indexed from the binding table. But that's not the case, they
just need to be in the dynamic state heap.
In the future, this change will allow to also allocate buffers for
push constant data in the newly created dynamic_visible_pool which
will be useful on < Gfx12.0 where this is the only place push constant
data can live for compute shaders.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30047>
Indirect pipeline binds force indirect descriptor sets and this needs
to be in the shader stage key, otherwise two shaders might result in
the same pipeline cache key.
Fixes: b1ba02e707 ("radv: force using indirect descriptor sets for indirect compute pipelines")
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30209>
The wording in the script has always (3218056e0e) been about symlinks,
and it feels like the use of `link()` instead of `symlink()` was
a typo that became fact.
These hardlinks make packaging harder (many distros have some variant of
this patch locally) especially when it comes to debug packages where gdb
expects the symbols file to have the same name as the lib the symbols
come from, and I don't think they make anything better, so let's change
to code to match the documentation :)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29731>
If you have something like this :
con 32 %66 = @load_reg (%62) (base=0, legacy_fabs=0, legacy_fneg=0)
con 32 %27 = @resource_intel (%22 (0xdeaddead), %66, %67, %17 (0x0)) (desc_set=2, binding=96, resource_intel=0, resource_block_intel=-1)
Just copying the brw_reg in ssa_values[] is not enough for the
load_reg intrinsic. We need to call get_nir_src() to force some logic
to create the register correct.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: b8209d69ff ("intel/fs: Add support for new-style registers")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30050>
IMO emojis are nice to add next to the information to recognize things
easily in cases where they are visible, but they should not *replace*
the information.
This adds a readable text next to all emojis (some already had one,
like the "job duration" ones).
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30223>
When I915_PARAM_HAS_CONTEXT_FREQ_HINT is not supported the
intel_ioctl(fd, DRM_IOCTL_I915_GETPARAM, &gp) will return -1 and that
will cause i915_gem_get_param() to return false.
val will be different than 1 when not using GuC submission, so we are
forcing val check to ensure this holds good in platforms that doesn't
support GuC submission.
Fixes: d52dd5a9 ("anv/drirc: add option to provide low latency hint")
Signed-off-by: Sushma Venkatesh Reddy <sushma.venkatesh.reddy@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30234>
This adds explicit names for softpipe and llvmpipe to the gallium driver
list. "swrast" is treated as a compatibility name that selects both. We
clarify how lavapipe depends on (just) llvmpipe, and we make it possible
to build llvmpipe without softpipe.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27607>
They're calling the same thing in the backend, so reduce the proliferation
of interfaces consumed within our implementation.
driVkImageExtensionSw now sets dri2_from_dma_bufs, which means that
egl_dri2 will now expose EXT_image_dma_buf_import. Given that it
previously set dri2_from_fds suggesting that it can import dmabufs, this
is presumably OK.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30245>
We were generating odd instructions like:
math inv(8) g93<1>HF g85<8,8,1>HF null<8,8,1>F { align1 1Q @7 $4 };
It's unclear whether the type of the null operand matters, but sometimes
these things don't get ignored properly. Out of caution, retype the
null source to match the actual operand's type. It'll at least look
less surprising in assembly dumps.
Reviewed-by: Sagar Ghuge <sagar.ghuge@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30193>
We had some helpers for this at one point but the old ones were super
clunky and didn't really do what we wanted so they were removed.
However, we have a lot of manual banging in opt_copy_prop and we're
about to add more. These new helpers will make it all a lot safer.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30230>
When a symbol is looked up for the first time, the associated function
is built, and the building process seems to be not thread-safe.
Use a mutex to protect the symbol looking up process, which should be
serialized when the function is not built, and fast when the function is
built.
Signed-off-by: Icenowy Zheng <uwu@icenowy.me>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30217>
Move it into src/gallium/include/ to make it absolutely clear this is a Mesa detail.
While we're at it, clean up its include sites, including some places
where we can just include kopper_interface.h instead since it includes
mesa_interface.h as its first act.
Acked-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28378>
Event::set_status only called the cbs for the passed in status, but we
need it to call all cbs up to the passed in status. This simplifies error
handling.
Cc: mesa-stable
Reviewed-by: @LingMan
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30215>
So for this entry we want the CPU mapping to be WC but GPU caches
can be WB.
This way GPU don't need to snoop to CPU caches and at the end of
workloads L3 cache is flushed, so CPU access is coherent after get
the signal that workload was finished.
With this the transient(XD) L3 flushes will only affect displayable
buffers.
Ref: Bspec 71582 (r59285)
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Jianxun Zhang <jianxun.zhang@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29950>
My initial understating was that L3_CACHE_POLICY would be the CPU
caching mode but that has nothing to do with CPU caching, it is the
GPU caching mode.
Due this miss understating we were using a not optimal PAT index that
will be fixed in the next patches, so to avoid such issues in future
adding comments to intel_device_info_pat_entry struct.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Jianxun Zhang <jianxun.zhang@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29950>
This pass uses constant folding to determine which invocation is read by shuffle
for each invocation. Then, it detects patterns in the result and uses more
a specialized intrinsic if possible.
For booleans it creates inverse_ballot.
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24650>
A single ldc is probably more efficient than a 64-bit load and the pile
of math we were generating before. The only reason for the old method
was that it let us avoid indirect cbuf loads because we didn't support
them for a while. Now that we can support all cbuf loads, we can just
do an indirect 1B load and call it good.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30218>
initializing the winsys from a /dev/dri/cardX node (as discovered by
gbm) doesn't work, as the kernel abi expects a render node
thus, the winsys needs to open the card's rendernode and use that
everywhere except when importing buffers, where it has to explicitly
export from the card node and import to the rendernode
Acked-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30224>
nouveau uses the OS page size which is almost always 4096. The next
patch will make this properly queried but this version is back-portable.
Fixes: 58181b7bbc ("nvk: Bump the sparse alignment requirement on buffers to 64K")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30138>
We skip loading the tile buffer from memory if the job has flagged
a clear (job->clears) for the buffer, however, this only tracks
clears emitted via the TLB. In some cases we may need to fallback
to clearing with a draw call, in which case we also want to skip
the load.
Reviewed-by: Jose Maria Casanova Crespo <jmcasanova@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30205>
We need to call iris_wait_syncobj() on both release and debug builds,
so take it out of the assert() call. Only assert the result.
With this patch, gnome-session finally works for me. Also steam.
Fixes: 665d30b544 ("iris: Wait for drm_xe_exec_queue to be idle before destroying it")
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/30195>
Xe KMD renamed XE_PERF to XE_OBSERVATION to better match with Intel
specification and avoid confusion.
This uAPI rename will land in the same kernel version that added
the uAPI being renamed.
There is no uAPI change, just renames.
Sync xe_drm.h with 63347fe031e3 ("drm/xe/uapi: Rename xe perf layer as xe observation layer").
Acked-by: Caio Oliveira <caio.oliveira@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30027>
* swrast allocates images aligned to 64x64 tiles, which results in images
that are larger than the window. PutImage requests must be clamped on
the y-axis to avoid uploading/damaging out-of-bounds regions
* winsys coords are y-inverted
cc: mesa-stable
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29910>
this way we can use shader-db report.py to analyze shader-db changes for zink
with the vk driver of our choosing. requires corresponding report.py relaxations
to be useful, the idea was to change zink a bit and change report.py a bit and
meet in the middle with something useful for arbitrary vulkan drivers.
the output isn't too pretty but it works,
synthetic example on nvk:
Instruction count HURT: shaders/glmark/1-1.shader_test vertex: 42 -> 43 (2.38%)
total Instruction count in shared programs: 7135 -> 7136 (0.01%)
Instruction count in affected programs: 42 -> 43 (2.38%)
helped: 0
HURT: 1
total Code Size in shared programs: 114160 -> 114160 (0.00%)
Code Size in affected programs: 0 -> 0
helped: 0
HURT: 0
total Number of GPRs in shared programs: 2677 -> 2677 (0.00%)
Number of GPRs in affected programs: 0 -> 0
helped: 0
HURT: 0
total SLM Size in shared programs: 0 -> 0
SLM Size in affected programs: 0 -> 0
helped: 0
HURT: 0
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30194>
Use common db_alignment to calculate dpb_size for DPB_MAX_RES,
DPB_DYNAMIC_TIER_1 and DPB_DYNAMIC_TIER_2. This makes the db_pitch
in sync with all DPB types.
Remove the VCN5 hack of using 256 for H264 as 64 works.
Remove redundant codes for width and height as they were calculated
at the beginning in calc_dpb_size().
Reviewed-by: Leo Liu <leo.liu@amd.com>
Signed-off-by: David (Ming Qiang) Wu <David.Wu3@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30186>
spirv_info_h was added to idep_vulkan_lite_runtime_headers but it's also
needed for building libvulkan_lite_runtime. Without this patch, from
a clean meson setup (tested with: -Dvulkan-drivers=freedreno -Dgallium-drivers= -Dplatforms=wayland)
ninja -C build src/vulkan/runtime/libvulkan_lite_runtime.a
In file included from ../src/vulkan/runtime/vk_physical_device.c:24:
../src/vulkan/runtime/vk_physical_device.h:32:10: fatal error: compiler/spirv/spirv_info.h: No such file or directory
Fixes: 1759c0eba7 ("vulkan: add helper to fill out spirv caps automatically")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30189>
Commit 94989b45a5 ("anv,driconf: Add fake non device local memory WA
for Total War: Warhammer 3") implemented a workaround to make
Warhammer 3 work on ADL, but the game still doesn't work on LNL, which
uses xe.ko, and MTL, which uses i915.ko: it still fails at launch
claiming it couldn't allocate memory.
So in this implementation, instead of clearing DEVICE_LOCAL_BIT we
just duplicate our memory types, one having the bit and one not
having.
v2:
- Check for VK_MAX_MEMORY_TYPES (José)
- Invert the order of the memory types (José)
- Fix white space issue (José)
v3:
- Comment our non-spec-compliance (José)
- Remove useless lines (José)
Link: https://gitlab.freedesktop.org/mesa/mesa/-/issues/8721
Fixes: 94989b45a5 ("anv,driconf: Add fake non device local memory WA for Total War: Warhammer 3")
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/30162>
Some apps (like firefox and chromium) seem to like to create textures
with internal format GL_RGBA8 but then upload GL_BGRA to them. If the
app were a bit more clever it could hit the memcpy path. But fallback
sw conversion (convert_ubytes()) is slow. If we are going to have to
make this extra copy, do it on the gpu.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30064>
A sequence like:
1) set_framebuffer_state(A)
2) clears and/or draws
3) set_framebuffer_state(B)
4) context_flush(ASYNC)
would result in the fence for batch B being returned, instead of batch A.
Resulting in a fence that signals too early.
Instead, in context_flush() find the most recently modified batch, so
that in the example above batch A would be flushed.
There is one wrinkle, that we want to avoid a dependency loop. So the
'last_batch' can actually be a batch that depends on the most recently
modified batch. But in either case, the batch that is used for the
returned fence is one that directly or indirectly depends on all other
batches associated with the context.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30064>
The other callers were already doing the prepatory stencil clear before
calling util_blitter_stencil_fallback(). Doing the clear in the driver
avoids recursively entering u_blitter if the driver uses
util_blitter_clear_depth_stencil() to implement ->clear_depth_stencil().
Signed-off-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30064>
this is required for nvk to create a heap. fixes zink+nvk+drm-shim:
run: ../src/gallium/drivers/zink/zink_screen.c:3371: zink_internal_create_screen: Assertion `i == ZINK_HEAP_HOST_VISIBLE_COHERENT_CACHED || i == ZINK_HEAP_DEVICE_LOCAL_LAZY || i == ZINK_HEAP_DEVICE_LOCAL_VISIBLE' failed.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: M Henning <drawoc@darkrefraction.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30136>
Add OpenCL kernels implementing the tessellation algorithm on device. This is an
OpenCL C port of the D3D11 reference tessellator, originally written by
Microsoft in C++. There are significant differences compared to the CPU based
reference implementation:
* significant simplifications and clean up. The reference code did a lot of
things in weird ways that would be inefficient on the GPU. I did a *lot* of
work here to get good AGX assembly generated for the tessellation kernels ...
the first attempts were quite bad! Notably, everything is carefully written to
ensure that all private memory access is optimized out in NIR; the resulting
kernels do not use scratch and do not spill on G13.
* prefix sum variants. To implement geom+tess efficiently, we need to first
calculate the count of indices generated by the tessellator, then prefix sum
that, then tessellate using the prefix sum results writing into 1 large index
buffer for a single indirect draw. This isn't too bad, we already have most of
the logic and the guts of the prefix sum kernel is shared with geometry
shaders.
* VDM generation variant. To implement tess alone, it's fastest to generate a
hardware Index List word for each patch, adding an appropriate 32-bit index
bias to the dynamically allocated U16 index buffers. Then from the CPU, we
have the illusion of a single draw to Stream Link with Return to. This
requires packing hardware control words from the tessellator kernel.
Fortunately, we have GenXML available so we just use agx_pack like we would in
the driver.
Along the way, we pick up indirect tess support (this follows on naturally),
which gets rid of the other bit of tessellation-related cheating. Implementing
this requires reworking our internal agx_launch data structures, but that has
the nice side effect of speeding up GS invocations too (by fixing the workgroup
size).
Don't get me wrong. tessellator.cl is the single most unhinged file of my
career, featuring GenXML-based pack macros fed by dynamic memory allocation fed
by the inscrutable tessellation algorithm.
But it works *really* well.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30051>
Ensure the following identities hold to match IEEE-754-2019 and upcoming NIR:
min(-0, +0) = -0
min(+0, -0) = -0
max(-0, +0) = +0
max(+0, -0) = +0
NVK uses this lowering. In a simple compute shader using fmin64 on an SSBO with
signed zero preserve required, testing the effect of this patch, the instruction
count goes from 47->52. Obviously I'm not thrilled by that but I also couldn't
find any obvious way of mitigating the issue. (Maybe NVIDIA has special hardware
support here. By instruction count, lowering all the way to int64 is a loss,
though I don't know how to count cycles on NVIDIA.)
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Konstantin Seurer <konstantin.seurer@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30075>
Ensure the following identities hold to match IEEE-754-2019 and upcoming NIR:
min(-0, +0) = -0
min(+0, -0) = -0
max(-0, +0) = +0
max(+0, -0) = +0
To implement, we specialize a version of flt64_nonnan. The regular flt64 has
extra logic to handle signed zero, so this version is actually simpler. So in
addition to the bug fix, this is an optimization. Compute shaders from
KHR-GL46.gpu_shader_fp64.builtin.max_dvec4 before and after:
before: 136 inst, 122 alu, 122 fscib, 4 ic, 1006 bytes, 39 regs, 28 uniforms
after: 104 inst, 90 alu, 90 fscib, 4 ic, 766 bytes, 39 regs, 28 uniforms
I will happy take a 24% reduction in instruction count as the cost of standards
conformance ^_^
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Konstantin Seurer <konstantin.seurer@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30075>
SPIR-V strengthened the semantics around signed zero, requiring fmin(-0, +0) =
-0. Since nir_op_fmin is commutative, we must also require fmin(+0, -0) = -0 to
match, although it's unclear if SPIR-V requires that. We must strengthen NIR's
definitions accordingly.
This strengthening is additionally motivated by the existing nir_opt_algebraic
rule like:
(('fmin', a, ('fneg', a)), ('fneg', ('fabs', a))),
With the strengthened new definition, this transform is clearly exact. With the
weaker definition, the transform could change the sign of zero based on
implementation-defined behaviours which ... while, not exactly unsound, is
undesireable semantically.
...
This is probably technically a bug fix, but I'm not convinced it's worth it's
weight in backporting.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Konstantin Seurer <konstantin.seurer@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30075>
These events were silently truncated in get_counters_for_event.
The integer types in this pass are a bit all over the place, maybe we should
consider using typedefs for clarity or a different solution with type safety.
Fixes: 9e9cabd2fa ("aco/waitcnt: support GFX12 in waitcnt pass")
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30163>
KGSL writes the profiling values asynchronously while we read them
immediately after the IOCTL returns which can result in the struct
not being filled in by the time we read it, this results in AGI not
correctly processing any timestamps from larger submits which take
longer to queue. To fix this, we now busy-wait on until the value
has been written out by KGSL.
Signed-off-by: Mark Collins <mark@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30147>
This fixes a leak that happens when copying a image using blit, and the
image is a compressed one.
In this case a new image view is created that can be re-interpreted to
perform the copy, but was not properly free.
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/30161>
maint7 provides the ability for virtualized drivers to pass along the
real driver's info, which allows for the enablement of per-driver workarounds
based on the underlying hardware
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29964>
if the src for a replace_buffer call is mapped after replacement:
* avoid clearing access flags
* update valid range
the pointer access here is always safe because the only case in which
this scenario can occur is if tc is forced to sync immediately after
creating a replaceent buffer, and the replacement buffer's lifetime
will always be exceeded by the lifetime of the real buffer
cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30107>
when tc replaces a buffer in subdata, it may subsequently perform subdata calls
on the replacement if it is forced to sync during map, e.g.,
* bind_vbo(dst)
* draw
* subdata(src)
* buffer replacement
* map
* tc sync
* replace_buffer(dst, src)
* memcpy <- broken
* draw
in this scenario, src may not have data at the time of replacement,
but it will get data soon after, and this buffer range is the real one
cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30107>
This puts the legalize routine and the encoder right next to each other
in the code, making it much easier to verify that legalize() enforces
all of the constraints reqauired by encode().
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30141>
This pulls them out of the per-SM flow. They're also all no-ops to
legalize since they don't take vectors and are handled directly by RA.
This also means these instructions are now getting properly handled on
Maxwell where we previously trusted in the (probably broken) maxwell
legalizing code.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30141>
This lets us stop passing liveness information into the per-op
legalization code. Long-term, I want to add a more general core
concept of destinations which are also reads but I haven't gotten
around to that yet.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30141>
Instead of scattering number checks everywhere, this lets us actually
start splitting code paths. This commit just adds the shader model
trait. Later commits will add more methods.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30141>
It's only needed for one Kepler+ check which is unlikely to ever be
relevant for NAK. Also, that should probably be based on the SPH
version or something, not an arbitrary shader model.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30141>
Handle '\n' when inside the MSGDESC start condition,
otherwise the lexer would apply its default rule (write
to stdout).
Without that, newlines were "leaking" to the output when
parsing a multiple line "MsgDesc". E.g. given the file
example.asm below
```
send(8) nullUD g126UD nullUD 0x02000000 0x00000000
thread_spawner MsgDesc: mlen 1 ex_mlen 0 rlen 0
{ align1 WE_all 1Q @1 EOT };
```
the assembler would produce one extra newline
```
$ brw_asm -t hex -g tgl example.asm
31 01 03 80 04 00 00 00 0c 7e 00 70 00 00 00 00
```
Reviewed-by: Sagar Ghuge <sagar.ghuge@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30100>
this is useful for evaluating compute shaders with zink. the open shader-db
doesn't have any compute shaders in it, but shader-db runner is capable of
compute and we need to handle it. (Rob's shaderdb definitely has some compute
shaders in it, at least.)
this gets us pipeline stats printing on zink+nvk for a simple compute shader I wrote when working on common NIR stuff:
b.shader_test - type: compute, Code Size: 752, Number of GPRs: 19, SLM Size: 0
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30135>
Commit f695a9fed2 moved the 64-bit float <-> 16-bit float conversion
splitting into a core NIR pass, so the code remaining here is only
needed for 64-bit integer types.
Presumably in an attempt to remove the float handling, it replaced
simple bit_size == 64 checks with this expression:
(full_type & (nir_type_int64 | nir_type_uint64))
I believe that the intended expression was:
(full_type == nir_type_int64 || full_type == nir_type_uint64)
Unfortunately, the former is incorrect. Any integer or unsigned
NIR type would trigger the former expression. For example:
nir_type_uint32 & (nir_type_int64 | nir_type_uint64) => nir_type_uint
This meant that we were splitting e.g. u2f16 on 32-bit unsigned types
into u2f32 and f2f16, when we can easily natively handle that case.
To fix this, we go back to simple bit_size == 64 checks. This pass is
already run after nir_lower_fp16_casts which will split the float case,
so we will never see it here.
fossil-db on Alchemist shows a -1.14% reduction in affected shaders for
google-meet-clvk shaders. In another ChromeOS workload, it improves
performance by around 8% on Meteorlake.
Thanks to Sushma Venkatesh Reddy for finding this performance issue!
Fixes: f695a9fed2 ("intel/compiler: use nir_lower_fp16_casts")
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30091>
Venus implements guest WSI on host external memory and thus cannot
transition guest wsi images to/from VK_IMAGE_LAYOUT_PRESENT_SRC_KHR.
Thus, when a client would attempt to transition a Venus wsi image
to/from VK_IMAGE_LAYOUT_PRESENT_SRC_KHR, Venus instead transitions
to/from VK_IMAGE_LAYOUT_GENERAL and performs an explicit ownership
transfer to/from VK_QUEUE_FAMILY_FOREIGN_EXT. Unfortunately, the
read-only guarantee of VK_IMAGE_LAYOUT_PRESENT_SRC_KHR is lost.
Upon the "acquire from foreign queue" side of that symmetry, when a
client would attempt to retain the contents of the image (i.e.
transition from VK_IMAGE_LAYOUT_PRESENT_SRC_KHR instead of
VK_IMAGE_LAYOUT_UNDEFINED), Venus knows that the image's backing memory
has not been modified. Thus, when those "acquire from FOREIGN queue"
ownership transfers flow to the native driver, Venus can signal it to
skip any acquisition-time validation of an image's internal data,
obtaining the same optimization as native WSI.
This is useful for drivers such as ARM's Mali (with Transaction
Elimination) that would otherwise need to recompute costly per-tile
checksums (CRCs) to ensure that they haven't gone stale during FOREIGN
ownership of the image's memory.
Signed-off-by: Ryan Neph <ryanneph@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29777>
Image memory barriers don't need to be fixed when Venus' internal
"presentable" layout is PRESENT_SRC (generally only in specific types of
debugging). In that case, skip barrier fixes as early as possible and
remove early returns from procedures deeper in the call stack.
Signed-off-by: Ryan Neph <ryanneph@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29777>
Prepare to allocate VkExternalMemoryAcquireUnmodifiedEXT structs from
command pool cached storage with the same lifetime as
VkImageMemoryBarrier(2) structs.
Also use common parameter naming and function call signatures for the
both the barrier and barrier2 variants.
Signed-off-by: Ryan Neph <ryanneph@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29777>
lower_fdot outputs fsum ops like fsum3, which in this stage may
go through nir_to_tgsi paths and tgsi doesn't implement them.
This hits an assert in ntt_emit_alu:
feedback: ../src/gallium/auxiliary/nir/nir_to_tgsi.c:1804:
ntt_emit_alu: Assertion `!"" "Unknown NIR opcode"' failed.
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30079>
This removes the unrequired dependance on _mesa_init_debug() and moves
all log code to the util file so that _mesa_log* can now be used without
creating a dependance on mesa/main. Since the code we are moving depends
on the code already in the util (as it was moved here previously) this is
also a much better spot for the code.
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30012>
`with_platform_windows` depends on the `platforms` option,
and is an inaccurate proxy check for `host_machine.system() == 'windows'`.
The ICD path and shared library name are dependent on the host system,
not whether or not Lavapipe is built with `WIN32` platform support.
In fact Lavapipe can be built with no platforms (`-Dplatforms=`)
if you only need headless (then this check would be incorrect)
fixes: e030ab5163
Acked-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Eric Engestrom <eric@igalia.com>
Reviewed-by: Dylan Baker <dylan@pnwbakers.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29900>
Previously we tried to map GPU resources directly wherever we could,
however this was always causing random issues and was overall not very
robust.
Now we just allocate a staging buffer on the host to copy into, with some
short-cut for host_ptr allocations.
Fixes the following tests across various drivers:
1Dbuffer tests (radeonsi, zink)
buffers map_read_* (zink)
multiple_device_context context_* (zink)
thread_dimensions quick_* (zink)
math_brute_force (zink)
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30082>
The linear_phi changes are already reflected in the live-in demand
of the successor. The logical_phi_sgpr_ops can only reduce the
register demand at the predecessor. Although this might slightly
overestimate the register-demand, no differences in code quality
were found.
Totals from 1610 (2.03% of 79395) affected shaders: (GFX11)
PreSGPRs: 54002 -> 56954 (+5.47%)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29962>
Add the ability to deduplicate hoisted expressions, which will be
necessary to avoid repeatedly hoisting the same descriptors and blowing
our budget. The offset calculation may have itself been hoisted into the
preamble, so we also have to be able to hoist a bindless_resource_ir3
referencing a load_preamble and connect it to the source of the
corresponding store_preamble.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29873>
We have to be careful here because r63.x is also used to mean "register
not assigned yet," but dummy destinations for prefetches will use r63.x
and we don't want them to count as GPRs when determining whether to
enable early preamble.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29873>
We currently assume that the instruction is already inserted and we are
optimizing it away, but in the use case I have where we are hoisting
instructions into a preamble and deduplicating as we go along, that
isn't the case. Move this responsibility onto the caller, which also
makes it a bit clearer what's going on and turns this into something
more similar to an actual set.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29873>
We are about to make a change that will make compiler options
depend on v3d version, so helpers would usually need additional
parameters to retrieve them. Isntead of doing this, we will make
the callers get the options instead and provide them to the
helpers.
Reviewed-by: Juan A. Suarez <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30086>
This requires that our nir compiler options are different between V3D versions
so we can't use a static global any more.
total instructions in shared programs: 11241106 -> 11047872 (-1.72%)
instructions in affected programs: 4634458 -> 4441224 (-4.17%)
helped: 25119
HURT: 1717
Instructions are helped.
total threads in shared programs: 425238 -> 425036 (-0.05%)
threads in affected programs: 878 -> 676 (-23.01%)
helped: 79
HURT: 180
Inconclusive result (%-change mean confidence interval includes 0).
total loops in shared programs: 1968 -> 1933 (-1.78%)
loops in affected programs: 35 -> 0
helped: 35
HURT: 0
Loops are helped.
total uniforms in shared programs: 3845314 -> 3845219 (<.01%)
uniforms in affected programs: 213615 -> 213520 (-0.04%)
helped: 1338
HURT: 1059
Inconclusive result (value mean confidence interval includes 0).
total max-temps in shared programs: 2224313 -> 2221507 (-0.13%)
max-temps in affected programs: 236054 -> 233248 (-1.19%)
helped: 4863
HURT: 3357
Max-temps are helped.
total spills in shared programs: 4264 -> 4294 (0.70%)
spills in affected programs: 274 -> 304 (10.95%)
helped: 8
HURT: 16
total fills in shared programs: 6638 -> 6497 (-2.12%)
fills in affected programs: 2240 -> 2099 (-6.29%)
helped: 55
HURT: 17
total sfu-stalls in shared programs: 14942 -> 14353 (-3.94%)
sfu-stalls in affected programs: 4863 -> 4274 (-12.11%)
helped: 1287
HURT: 1165
Sfu-stalls are helped.
total inst-and-stalls in shared programs: 11256048 -> 11062225 (-1.72%)
inst-and-stalls in affected programs: 4635701 -> 4441878 (-4.18%)
helped: 25074
HURT: 1728
Inst-and-stalls are helped.
total nops in shared programs: 270482 -> 270621 (0.05%)
nops in affected programs: 27579 -> 27718 (0.50%)
helped: 1583
HURT: 1967
Inconclusive result (value mean confidence interval includes 0).
Reviewed-by: Juan A. Suarez <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30086>
Introduce unary and binary versions of the branch instruction. This will
give more ISA_OPC_BRANCH_XXX opcodes to work with. This helps to get rid
of these 'maybe' bitsets and is needed for the assembler.
Signed-off-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30030>
Don't multiply by 4 twice. While we're here, fix the in-bounds check on
a6xx, since we need to account for the multiplying by 4. This was done
correctly on a7xx but the commit below didn't correctly port it to a6xx
when adding the multiply on a6xx.
Fixes: 01bac643f6 ("freedreno/ir3: Fix ldg/stg offset")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30046>
si_set_patch_vertices was only called if tcs.current was non-NULL but
this condition is not enough for GFX9+ since vs is used as ls.
Add a check in si_update_tess_io_layout_state instead, and set
sctx->do_update_shaders for case where the ls_current is not yet
available.
This fix crashes on GFX6.
Cc: mesa-stable
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29876>
buffer_size is not the full buffer size, but the part of the
buffer that is accessed by the compute shader.
This fixes the assert hit in si_set_shader_buffer.
Fixes: 1a99f50c7f ("radeonsi: use a compute shader to convert unsupported indices format")
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29876>
We use the method used by the blob, which sets the USE_CPU_MAP flag,
originally intended for SVM, to allocate from a separate address range
and to control the address by passing a preferred address to mmap().
With this we can capture and replay gfxreconstruct traces on kgsl for
apps that use BDA, and we can replay them on msm with a small hack to
increase the address space size:
echo 274877906944 > /sys/module/msm/parameters/address_space_size
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29251>
We select the feedback tranche according to the image format but not the
actual format that we will use for presentation. This breaks direct
scanout in cases where the application selected a visual with an alpha
channel but using EGL_EXT_present_opaque which previously worked as
expected.
Fix this by selecting the feedback tranche according to the actual
presentation format.
Fixes: 9ea9a963aa ("egl/wayland: Fix EGL_EXT_present_opaque")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28153>
When using the EGL_EXT_present_opaque extension we create wayland
buffers with the opaque variant of the surface format, while the
underlying image is created with the normal surface format. However,
there is no guarantee that the compositor supports that opaque format,
or that we can use that format with all the modifiers of the surface
format.
Since this is completely out of the control of the application, and the
compositor will disconnect the client with an error if the format is not
supported, this commit:
1. Fails EGL surface creation if it determines that the opaque format
cannot be used, either because it's not present at all, or because
it shares no modifier with the non-opaque format.
2. When creating the DRI image ensures that we use a modifier that's
also supported by the opaque format.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28153>
The VA alignment now has two pieces: The bind alignment and the base
address alignment. The caller gets to request the later but not the
former. The bind alignment is based entirely on whether or not we know
a priori that the given VA will only ever be used for GART.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30033>
It's a positive flag in the kernel interface because it enables an
optimization and adds restrictions to the BO. But from a userspace PoV,
NO_SHARE shoudd be the default with import/export being something we
expressly have to ask for. This also reduces the number of flags we're
setting everywhere.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30033>
We may want to move this even higher, into NVK at some point. However
the wrappers in the winsys layer really aren't doing us much. If
anything, now that nvkdm_mem::va is an nvkmd_va *, this actually makes
everything simpler because it's allocated through exactly the same paths
as sparse VA.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30033>
Instead of trusting in nil::Image::align_B, force it to the sparse
binding size because we know we're going to try and sparse bind it.
Otherwise, small sparse images could fail to bind at the bind step.
Fixes: 7321d151a9 ("nvk: Add support for sparse images")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30033>
This is an issue happening on radeonsi after the commit
6f8e6fb99c "mesa/st: use compute pbo download for readpixels".
This commit enables a new code path which has this memory leak.
For instance, this issue is triggered on radeonsi with
"piglit/bin/glsl-fs-raytrace-bug27060 -auto -fbo":
Too many leaks! Only the first 5000 leaks encountered will be reported.
Indirect leak of 327424 byte(s) in 5582 object(s) allocated from:
#0 0x7fe27fa4d7ef in __interceptor_malloc (/usr/lib64/libasan.so.6+0xb17ef)
#1 0x7fe2717fd4df in ralloc_size ../src/util/ralloc.c:118
#2 0x7fe272dbbae4 in calc_dom_children ../src/compiler/nir/nir_dominance.c:138
#3 0x7fe272dbbae4 in nir_calc_dominance_impl ../src/compiler/nir/nir_dominance.c:192
#4 0x7fe272b7f4a2 in nir_metadata_require ../src/compiler/nir/nir_metadata.c:40
#5 0x7fe272ba0d50 in nir_opt_cse_impl ../src/compiler/nir/nir_opt_cse.c:43
#6 0x7fe272ba0d50 in nir_opt_cse ../src/compiler/nir/nir_opt_cse.c:67
#7 0x7fe272686f83 in gl_nir_opts ../src/compiler/glsl/gl_nir_linker.c:92
#8 0x7fe271a31e69 in create_conversion_shader ../src/mesa/state_tracker/st_pbo_compute.c:701
#9 0x7fe271a353fa in create_conversion_shader_async ../src/mesa/state_tracker/st_pbo_compute.c:810
#10 0x7fe271806ea8 in util_queue_thread_func ../src/util/u_queue.c:309
#11 0x7fe27186379a in impl_thrd_routine ../src/c11/impl/threads_posix.c:67
#12 0x7fe27ea9a7c3 (/lib64/libc.so.6+0x867c3)
...
SUMMARY: AddressSanitizer: 1384704 byte(s) leaked in 17291 allocation(s).
Fixes: 5dab7673e1 ("mesa/st: add specialized pbo download shaders")
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30068>
These flags are set at the end of the job based on its buffer usage and
then checked by following jobs.
If an application toggles stencil and depth tests alternatigly in
a sequence of jobs while also relying on previous contents to render,
with the current assignment the reload flags for depth or stencil may
be cleared incorrectly and a depth/stencil buffer may not be properly
reloaded.
Cc: mesa-stable
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
Reviewed-by: Vasily Khoruzhick <anarsoul@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30065>
This is basically a port from commit 591a3c738d ("freedreno: Be more
strict about QUERY_AVAILABLE to simplify the code.") to etnaviv.
perfmon queries already forced such a flush by setting no_wait_cnt
to a value above the flush threshold, now we unify the behavior between
occlusion and perfmon queries.
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/30055>
When there are active PMRs attached to the command buffer we can
not optimize the flush away, as that results in the queries never
reaching their expected sequence number, livelocking readers
waiting for the query result.
Fixes: 148658638e7f ("etnaviv: drm: Be able to mark end of context init")
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/30055>
The NVIDIA proprietary driver exposes a DRM device these days and this
can trip up NVK as it advertises an NVIDIA device id. We fail to
enumerate but the check for nouveau happens too late and we throw a
warning. This means tha if NVK is even installed side-by-side with the
proprietary driver, we spam warnings on every device enumeration. It's
better to fail silently.
Fixes: 83786bf1c9 ("nvk: add vulkan skeleton")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/11441
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30035>
An extended instruction uses 0x7f as opcode and stores the extended
opcode in the IMMED of src2.
Reverse engineered with the following dEQPs:
- dEQP-GLES31.functional.shaders.builtin_functions.integer.findmsb.int_lowp_vertex
- dEQP-GLES31.functional.shaders.builtin_functions.integer.findlsb.uvec3_lowp_fragment
Signed-off-by: Christian Gmeiner <cgmeiner@igalia.com>
Acked-by: Lucas Stach <l.stach@pengutronix.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30010>
The way ATTR_WEAK works is changed to eliminate the "don't declare as
weak on MinGW" weirdness. When a weak is not undefined, MinGW requires
the definition to be a regular symbol. Instead of declaring as weak
everywhere, we now declare the symbol as a regular by default, and only
make it weak when it needs to fallback to NULL when undefined, which is
only needed for the dispatch table. This unifies the approach for Unix
and MinGW.
The name ATTR_WEAK is changed to VK_ENTRY_WEAK since it's now controlled
by the entrypoint specific VK_ENTRY_USE_WEAK flag.
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29986>
This adds a magic number and the device name to the binary in order to
verify we indeed have a binary we can parse and matches the device.
Also save the binary header explicitly in little-endian order, so that we
at least make sure that's always the same.
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29946>
A couple of these were trivially missing the `created` status which
usually doesn't stay for long enough for this very slow script to notice.
The `cancel_job()` function will no longer cancel manual jobs waiting to
be started.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29917>
The OFFSET_LO in #instruction-cat6-a6xx-ibo-load-store aliased with
opcode of other instructions, resolve this by being less lax in some
instruction definitions.
A proper way to solve this would probably be to reconstruct instructions
hierarchy, but it's a much more complex task.
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30018>
With LLVM-19, Module.h header is not being pulled, which results in
compile errors e.g.
src/amd/llvm/ac_llvm_helper.cpp:102:10: error: no matching function for call to ‘unwrap(LLVMOpaqueModule*&)’
102 | unwrap(module)->setTargetTriple(TM->getTargetTriple().getTriple());
| ~~~~~~^~~~~~~~
In file included from /mnt/b/yoe/master/build/tmp/work/x86_64-linux/mesa-native/24.0.7/recipe-sysroot-native/usr/include/llvm/IR/Type.h:18,
from /mnt/b/yoe/master/build/tmp/work/x86_64-linux/mesa-native/24.0.7/recipe-sysroot-native/usr/include/llvm/IR/DerivedTypes.h:23,
from /mnt/b/yoe/master/build/tmp/work/x86_64-linux/mesa-native/24.0.7/recipe-sysroot-native/usr/include/llvm/IR/InstrTypes.h:26,
from /mnt/b/yoe/master/build/tmp/work/x86_64-linux/mesa-native/24.0.7/recipe-sysroot-native/usr/include/llvm/Analysis/TargetLibraryInfo.h:14,
from ../mesa-24.0.7/src/amd/llvm/ac_llvm_helper.cpp:8:
Its getting the definition from llvm/IR/Type.h instead of Module.h and caused
confusion to compiler
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/11424
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29993>
This is mainly to reject buffers allocated with modifiers not supported
for given entrypoint. There is no interface to query supported modifiers
for different formats and entrypoints in libva, so applications can
import externally allocated buffers that may be unsupported with some
entrypoints.
Reviewed-by: Thong Thai <thong.thai@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29932>
Currently EFC would be used for every RGB->NV12 conversion, even if the
target surface wasn't going to be used as encode input. Also another
issue is that there may be multiple conversions from the same source
surface before the encode operation (this is the case with B-frames
when using one source surface).
EFC is now used only if the postproc conversion is the last postproc
operation immediately before encoding.
Until it's been observed that this is the case, the shader conversion is
also applied as a fallback in case EFC could not be used.
Tested with (fixes EFC + H264 with B-frames on radeonsi):
ffmpeg -vaapi_device /dev/dri/renderD128 -f lavfi -i testsrc \
-vf hwupload,scale_vaapi=format=nv12 -c:v h264_vaapi -bf 3 \
-vframes 200 out.mp4
Reviewed-by: Thong Thai <thong.thai@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29932>
MI_REPORT_PERF_COUNT reports all 64 PEC counters, so there is no
need to read individual registers.
Also the individual registers reads privileged and UMDs can't access
it, causing it to always read as always zero and overwritting valid
data read with MI_REPORT_PERF_COUNT.
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/29529>
In tu_get_image_format_properties(), image usage flags are matched against
sets of required format feature flags for the specified image format.
These mappings are defined in the Vulkan 1.3 spec in section 49.3.3.,
"Format Feature Dependent Usage Flags".
Handling for the VK_IMAGE_USAGE_INPUT_ATTACHMENT_BIT flag was missing. When
specified, at least one of color attachment or depth-stencil attachment
format feature flags should be present for the given format.
Fixes 110 new Vulkan CTS tests:
- dEQP-VK.api.info.unsupported_image_usage.linear.*
- dEQP-VK.api.info.unsupported_image_usage.optimal.*
Signed-off-by: Zan Dobersek <zdobersek@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30013>
While Raspberry PI OS 64-bit is the suggested version for rpi3 devices
and newers, for older devices like rpi1 to rpi2, which uses the same
GPU, the recommended flavour is 32-bit.
Also, while 64-bit is the recommended version, users can still decide to
use the 32-bit flavour.
Hence, spend a bit of nightly time to run a subset of the OpenGL/ES
tests.
Reviewed-by: Eric Engestrom <eric@igalia.com>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30003>
Add basic KHR_8bit_storage support for Adreno 750 devices, for now enabling
the storageBuffer8BitAccess feature. A separate descriptor is provided for
8-bit storage access. The descriptor index is adjusted appropriately for
8-bit SSBO loads and stores.
The 8-bit SSBO loads cannot go through isam since that instruction isn't
able to handle those. The ldib and stib instruction encodings are a bit
peculiar but they match the blob's image buffer access through VK_FORMAT_R8
and the dedicated descriptor. These loads and stores do not work in
vectorized form, so they have to be scalarized. Additionally stores of
8-bit values have to clear up higher bits of those values.
8-bit truncation can leave higher bits as undefined. Zero-extension of
8-bit values has to use masking since the corresponding cov instruction
doesn't function as intended. 8-bit sign extension through cov from a
non-shared to a shared register also doesn't work, so an exception is
applied to avoid it.
Conversion of 8-bit values to and from floating-point values also doesn't
work with a straightforward cov instruction, instead the conversion has
to go through a 16-bit value.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/9979
Signed-off-by: Zan Dobersek <zdobersek@igalia.com>
Reviewed-by: Connor Abbott <cwabbott0@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28254>
ir3's TYPE_S8 isn't actually a signed 8-bit type in a half-register, it's
in fact an unsigned 8-bit type in a full register. Only actual uses of
TYPE_S8 are in conversion operations, but those can be trivially replaced
with TYPE_U8, either truncating down to 8 bits or zero-extending or
sign-extending from 8 bits upward.
Signed-off-by: Zan Dobersek <zdobersek@igalia.com>
Reviewed-by: Connor Abbott <cwabbott0@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28254>
Until now, if the 16-bit storage functionality is supported by the
hardware, two separate descriptors were set up, with isam loads and stores
piping through the descriptor of the corresponding size and other storage
access using the 16-bit descriptor.
These changes keep separate descriptors on a650, but leverage post-a650
isam.v functionality that enables use of 16-bit descriptors for 32-bit
loads, removing the need for the separate 32-bit descriptor.
Storage buffer descriptors are set up according to 16-bit storage support
and the indicated isam.v support, using those descriptors for 32-bit isam
loads as well if the latter is present.
Dynamic offset application in tu_CmdBindDescriptorSets is modified to
determine the offset shift value based on the descriptor's format and not
on the descriptor's position in the layout binding.
Signed-off-by: Zan Dobersek <zdobersek@igalia.com>
Reviewed-by: Connor Abbott <cwabbott0@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28254>
Driver with compact_arrays=false (i.e. radeonsi) is broken when
tess factor is accessed indirectly, for example:
gl_TessLevelOuter[gl_InvocationID] = xxx;
This fix use nir_vectorize_tess_levels to lower array tess factor
access into direct vector access before nir_lower_io() like clip
and cull distance way.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Signed-off-by: Qiang Yu <yuq825@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29799>
The standalone compiler previously ran these tests through a hacked up
partial linker. When this partial linker was recently removed from the
standalone compiler the --link option was turned on because some tests
are testing linking not just compilation. However in a future patchset
we will switch the standalone linker to use the nir linking code and
when this is done all of these shaders will need to pass full linking,
so here we update them to do so.
Acked-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29991>
Xe2+ platforms don't use fast-type buffer for its new design.
We don't have to track different fast-clear types, so we just
return the highest level of support.
Fixes: Vulkan CTS
dEQP-VK.api.copy_and_blit.core.resolve_image.whole_array_image
_one_region.8_bit_not_all_remaining_layers
src/intel/vulkan/anv_private.h:5439: anv_image_get_fast_clear_type_addr:
Assertion `device->info->ver < 20' failed.
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/29966>
With libetnaviv_parser we are able to parse the resulting string
representation into an etna_inst and assemble that to binary.
As we are not able to parse and/or assemble we need to mark some test
cases with special flags.
This allows us to test: bin -> disasm -> parsing -> assemble
If isa_parse_str(..) is not available we skip this part of the unit
test.
Signed-off-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28869>
This commit adds the actual parser, which makes use of the IsaParser
derive proc macro.
It provides two public functions:
- asm_process_str(..)
Parse the provided isa representation and return an etna_asm_result.
This will be used by our unit tests.
- asm_process_file(..)
Parse a whole file full of isa and return an etna_asm_result. This
will be used by our cli assembler.
Signed-off-by: Christian Gmeiner <cgmeiner@igalia.com>
Reviewed-by: @LingMan
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28869>
This proc derive macro does the following magic:
- read static rules file
- parse isaspec xml file
- generate valid pest PEG grammar and attaches it as grammar_inline to
the ast
- calls pest_generator::derive_parser(..) to generate the parser
- creates FromPestRule trait
- creates FromPestRule impl for enums and opcodes
This is the fundation of our assembler.
Signed-off-by: Christian Gmeiner <cgmeiner@igalia.com>
Reviewed-by: @LingMan
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28869>
This commits adds a meta elements with the following attributes:
- has_dest: does the instruction has a dest register?
- valid_srcs: which sources need to be valid?
Is used to generate PEST grammar and defines which of the three source
registers needs to be != void.
- type: which <template> shall be used?
Must match a known template name by the last part.
E.g.: <meta type=tex"/> --> <template name="INSTR_TEX">
Signed-off-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28869>
Fixes the following building error:
../out_src/src/intel/common/intel_common.c:29:4: error: implicit declaration of function 'free' is invalid in C99 [-Werror,-Wimplicit-function-declarat
ion]
free(engine_info);
^
1 error generated.
Fixes: 5b8b4f78 ("intel/dev: Add engine_class_supported_count to intel_device_info")
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29975>
The CMF values of these formats are not explicitly defined in the
spec. Refer to the added comment for more details.
Fixed Piglit tests:
[ISL_FORMAT_L8A8_UNORM_SRGB]
getteximage-formats -auto -fbo
[ISL_FORMAT_L8_UNORM_SRGB]
teximage-colors GL_SLUMINANCE8 -auto -fbo
[ISL_FORMAT_R9G9B9E5_SHAREDEXP]
fbo-generatemipmap-3d RGB9_E5 -auto -fbo
src/intel/isl/isl_genX_helpers.h:322: isl_get_render_compression_format:
Assertion `!"" "Unsupported render compression format!"' failed.
Also bump up Bspec revision in comments.
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/28620>
If ring is already current when creating bo, we skip the ring wait but
miss to invalidate bo ring seqno. There's a false-positive for sending a
ring wait upon free memory if the ring has consumed about UINT32_MAX
bytes of traffic (unrelated to ring size).
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29988>
sysmacros.h defines macros `minor()` and `major()`. These macros conflict
with a definition of `minor()` in the Perfetto SDK header. Move the
sysmacros.h include to intel_perf.c because the Perfetto header is only
included at the same time as intel_perf.h not *.c (in intel_driver_ds.cc).
Unbeknown to anyone, the definition of `minor()` in the Perfetto header is
being replaced with the macro. See the MR attachment for an example.
Signed-off-by: Renato Pereyra <renatopereyra@chromium.org>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29974>
Indirect addressing(vx1 and vxh) not supported with UB/B datatype for
src0, so we need to change the data type for both dest and src0.
This fixes following tests cases on Xe2+
- dEQP-VK.spirv_assembly.instruction.compute.8bit_storage.push_constant_8_to_16*
- dEQP-VK.spirv_assembly.instruction.compute.8bit_storage.push_constant_8_to_32*
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/29316>
We can do CSEL on F, HF, *W, and *D on Gfx11+. Gfx9 can only do F.
We can lower unsupported types to CMP+CSEL, allowing us to use CSEL
in the IR and not worry about the limitations.
Rework: (Sagar)
- Update validation pass for CSEL
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29316>
Coverity has spotted a place where we could in theory overflow. In
reality it wont happen as the potential overflow is a bitfield with a
maximum of two values. Add an `assume()` statement to help out the
compiler and document our assumption.
fixes: dc1aedef2b
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29825>
This opcode doesn't write SCC, which gives later passes more freedom to
move instructions.
fossil-db (navi21):
Totals from 727 (0.92% of 79395) affected shaders:
Latency: 14943483 -> 14942704 (-0.01%); split: -0.01%, +0.00%
InvThroughput: 3225790 -> 3225766 (-0.00%); split: -0.00%, +0.00%
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Georg Lehmann <dadschoorse@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29912>
Gallium/tests/trivial requires dynamic pipe loader at runtime, that is,
$prefix/$libdir/gallium-pipe/pipe_*.so must get built and installed.
so let's build it if build-tests is enabled.
v2:
- Fix error of meson when both of clover and tests are enabled (dbaker)
Signed-off-by: Luc Ma <luc@sietium.com>
Acked-by: Marek Olšák <marek.olsak@amd.com>
Acked-by: Dylan Baker <dylan@pnwbakers.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27180>
This is the same config as intel.cfg only changing:
data_sources {
config {
name: "gpu.counters.i915"
gpu_counter_config {
counter_period_ns: 100000
}
}
}
to:
data_sources {
config {
name: "gpu.counters.xe"
gpu_counter_config {
counter_period_ns: 100000
}
}
}
Otherwise pps would not accept due to different KMD names.
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/29312>
812b3415 added rules for upcasts with comparisons with a variety of
types. The float & unsigned rules should be ok, but the signed integer rules are
unsound as currently implemented. This can cause end-to-end miscompiles.
I originally hit this issue while debugging a large real world OpenCL kernel. I
found the bug symptoms changed when disabling loop unrolling, which tipped me
off to a compiler bug. I've reduced it to a minimal test case. Imagine my
surprise when I find out the NIR my backend ingested was already constant folded
to be wrong.
In the minimal test case, during optimization we have NIR:
32 %6 = ....
64 %9 = i2i64 %6
64 %44 = load_const (0x0000000000000001)
1 %45 = ilt %9, %44 (0x1)
This is a simple check (int64_t)%6 < 1.
nir_opt_algebraic turns this into:
32 %6 = ...
64 %9 = i2i64 %6
64 %44 = load_const (0x0000000000000001)
64 %55 = load_const (0x0000000080000000 = 2147483648)
1 %56 = ilt %55 (0x80000000), %44 (0x1)
64 %57 = load_const (0x000000007fffffff = 2147483647)
1 %58 = ilt %57 (0x7fffffff), %44 (0x1)
32 %59 = i2i32 %44 (0x1)
1 %60 = ilt %6, %59
1 %61 = ior %58, %60
1 %62 = iand %56, %61
This pile of math constant-folds to an unconditional "false"! The problem is
%56. At first glance, INT32_MIN < 1 is true so %56 should be true. Indeed, it
should. But here's the kicker: both constants are 64-bit here, so the ilt
operation is a 64-bit comparison -- that left-hand side is INT32_MIN
zero-extended to 64-bit for the signed comparison at 64-bit. So in fact, it
evaluates to false, causing the whole expression to go false. If we're going to
do a 64-bit comparison for %56, then we need to sign-extend the bound. So we'll
just adjust the Python and be on our way, right?
Unfortunately the issue is deeper. According to the comment in the generated
nir_opt_algebraic.c file, the guilty algebraic rule is:
('ilt', ('i2i64', 'a@32'), '#b') =>
('iand', ('ilt', -2147483648, 'b'), ('ior', ('ilt', 2147483647, 'b'), ('ilt', 'a', ('i2i32', 'b'))))
From a Python perspective? That rule is correct. -2147483648 < 1 is a true
statement. Adjusting the Python rule is not the appropriate solution here, since
the issue is more fundamental and might affect other rules. The real problem is
the translation of that Python replacement tree into C, incorrectly
zero-extending -2147483648 into 0x0000000080000000 instead of sign-extending to
0xffffffff80000000.
Crawling down the rabbit hole of the generated algebraic file, we see the
constant encoded as:
{ .constant = {
{ nir_search_value_constant, 64 },
nir_type_int, { -0x80000000 /* -2147483648 */ },
} },
NIR correctly translates the negative constant to a C level negate operation of
its absolute value. This maps to the correct sign-extension...
...for all constants except for INT_MIN. Because that constant lacks a ULL
suffix, it is a 32-bit integer. And for this integer (only), negating it hits
signed integer overflow (UB!) and then we end up with an effective
zero-extension when going to 64-bit.
This patch fixes the end-to-end miscompile.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Closes: #11402
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29952>
Reorganize the code to make clearer all the lowering cases:
(a) Single invocation workgroup. Index and IDs are all zero.
(b) Local ID provided by hardware.
(c) Local Index provided by the hardware. Depending on the case this
might not be the final local index, e.g. heuristics for tile.
(d) Neither provided by the hardware.
Case (c) is new and supported by Mesh/Task shaders. At the moment the
nir_lower_compute_system_values handle lowering of LocalID for
Task/Mesh, but a later patch will flip that on ANV.
This will make the Task/Mesh use the same lowering as Compute shaders.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29828>
It takes significant amount of time at va context creation, and most
of the time the postproc pipelines are not used anyway.
This reduces total time it takes to run all libva-utils tests on my machine
from 38s to 28s.
Reviewed-by: Leo Liu <leo.liu@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29936>
When the DGC prepare shader is conditionally executed on the graphics
queue, the generated IBs might be uninitialized. It's fine for the
DGC GFX IB because the INDIRECT_PACKET would also be conditionally
skipped but it's not possible to do that for the DGC ACE IB
(ie. no IB2 on compute).
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29935>
Looks like some of the tests uses the bias which does not fit into half
float parameter, so it's better to use float param for sample_b.
If we have cube arrays, we anyway combine BIAS and array index properly
so we don't have to worry about the first parameter.
This fixes: GTF-GL46.gtf21.GL3Tests.texture_lod_bias.texture_lod_bias_clamp_m_g_M
Signed-off-by: Sagar Ghuge <sagar.ghuge@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29533>
Function anv_physical_device_try_create() creates the devinfo variable
and then at some point it copies its contents to device->info:
device->info = devinfo;
Much much later we're calling:
intel_common_update_device_info(fd, &devinfo);
... which is updating devinfo but not device->info. As a consequence,
we're only creating one queue, as engine_class_supported_count[klass]
is zero for everybody.
Fixes: 5b8b4f7878 ("intel/dev: Add engine_class_supported_count to intel_device_info")
Reviewed-by: Tapani Pälli <tapani.palli@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/29927>
When the destination of both instructions is NULL and the conditional
modifier matches, operands_match (by way of instructions_match) will
only test the first two operands. This can result in bad CSE
happening.
This is a very, very narrow edge case.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29848>
This one is a bit more complex in that we need to handle 3-source
commutative opcodes. But it's also quite useful:
fossil-db results on Alchemist (A770):
Instrs: 151659750 -> 150164959 (-0.99%); split: -0.99%, +0.01%
Cycles: 12822686329 -> 12574996669 (-1.93%); split: -2.05%, +0.12%
Subgroup size: 7589608 -> 7589592 (-0.00%)
Send messages: 7375047 -> 7375053 (+0.00%); split: -0.00%, +0.00%
Loop count: 46313 -> 46315 (+0.00%); split: -0.01%, +0.01%
Spill count: 110184 -> 54670 (-50.38%); split: -50.79%, +0.41%
Fill count: 213724 -> 104802 (-50.96%); split: -51.43%, +0.47%
Scratch Memory Size: 9406464 -> 3375104 (-64.12%); split: -64.35%, +0.23%
Our older Shadow of the Tomb Raider fossil is particularly helped with
over a 90% reduction in scratch access (spills, fills, and scratch
size). However, benchmarking in the actual game shows no change in
performance. We're thinking the game's shaders have been updated since
our capture.
Ian noted that there was a bug here where we'd accidentally CSE two ADD3
instructions with null destinations and different src[2] that couldn't
be dead code eliminated due to conditional mods. However, this is only
a bug in the new cse_defs pass so we don't need to nominate this for
stable branches.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29848>
Fix defect reported by Coverity Scan.
Evaluation order violation (EVALUATION_ORDER)
write_write_typo: In src_idx = src_idx = binding_layout->desc_idx + i * desc_stride + subdesc_idx,
src_idx is written twice with the same value.
Fixes: 7bea6f8612 ("panvk: Overhaul the Bifrost descriptor set implementation")
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29865>
This optimizes things by splitting the position and vertex
processing in two, allowing primitives to be discarded before
the varying shader is executed.
This optimization is even more important if we throw
layered rendering into the mix, because layered rendering on
Bifrost is implemented with N IDVS/fragment jobs (N being the
number of layers), with primitives not targetting a given
layer being artificially culled in the vertex shader by
issuing a position outside the render area.
Signed-off-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/29450>
This fixes corruption of push constants on Xe2 due to a mismatch in
the uniform layout implemented by the compiler and assumed by the
driver. To fix it we need to align the push constant ranges computed
by the Vulkan driver to a multiple of the GRF size of the platform.
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29926>
This is not safe when we have conditional spills since we could be
spilling disabled lanes with undefined values that could overwrite
valid data for those lanes from a previous spill of the same temp
that was unconditional (or that condionally enabled those same
lanes).
Fixes some Piglit OpenCL tests as well as the following OpenCL tests:
integer_divideAssign
integer_moduloAssign
integer_mad_sat
integer_ops integer_divideAssign
integer_ops integer_mad_sat
integer_ops integer_moduloAssign
integer_ops quick_char_math
integer_ops quick_short_math
math_brute_force half_powr
math_brute_force pow
math_brute_force pown
math_brute_force powr
math_brute_force rootn
Fixes: 597560e27c ('broadcom/compiler: always enable per-quad on spill operations')
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29909>
The multop instruction implicitly writes rtop which is not preserved
acrosss thread switches. We can spill the sources of the multop
(since these would happen before multop) and the destination of
umul24 (since that would happen after umul24).
Fixes some OpenCL tests when V3D_DEBUG=opt_compile_time is used to
choose a different compile configuration.
cc: mesa-stable
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29909>
This implements a replacement for the previous implementation of
nir_intrinsic_load_barycentric_at_sample that relied on the Pixel
Interpolator shared function, since it's going to be removed from the
hardware from Xe2 onwards.
This implementation simply looks up the X/Y offsets of each sample
index on the table provided in the PS thread payload by using indirect
addressing, then does the actual interpolation by recursing into
emit_pixel_interpolater_alu_at_offset() introduced in the previous
commit.
Note that even though this is only immediately useful on Xe2+
platforms there's no reason why it shouldn't work on earlier
platforms, as long as we have the sample X/Y offsets available in the
thread payload.
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29847>
This implements a replacement for the previous implementation of
nir_intrinsic_load_barycentric_at_offset that relied on the Pixel
Interpolator shared function, since it's going to be removed from the
hardware from Xe2 onwards.
That's okay since we can get all the primitive setup information
needed for interpolation at an arbitrary coordinate: We use the X/Y
offset relative to the "X/Y Start" coordinates from the thread payload
order to evaluate the plane equations also provided in the thread
payload for each barycentric coordinate of each polygon. The
evaluation of the barycentric plane equations (and the RHW plane
equation for perspective-correct interpolation) uses the accumulator
and MAD/MAC for ALU efficiency, but that means we need to manually
split instructions to fit the width of the accumulator. The division
and scaling for perspective-correct interpolation is also now done in
the shader if necessary.
Note that even though this is only immediately useful on Xe2+, the
thread payload numbers are filled out for older platforms, and the EU
restrictions of previous Xe platforms are taken into account, mostly
for the purposes of testing and performance evaluation.
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29847>
Floating-point offsets work fine in combination with the
floating-point arithmetic we're about to lower these intrinsics into,
and they require less instructions than converting to fixed-point and
then back. No reason to take the precision/range hit nor the extra
instructions.
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29847>
Plumb the prog_data bits recently introduced for ALU-based
interpolation down to 3DSTATE_PS_EXTRA emission in the Vulkan driver.
Even though this is only going to be used on Xe2+ for now there seems
to be no reason not to plumb the bits on all platforms back to gfx11,
since the 3DSTATE_PS_EXTRA enables already existed on ICL.
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29847>
Plumb the prog_data bits recently introduced for ALU-based
interpolation down to 3DSTATE_PS_EXTRA emission in the GL driver, as
well as the uses_depth_w_coefficients bit that was already in use by
the Vulkan driver for CPS shaders. Even though this is only going to
be used on Xe2+ for now there seems to be no reason not to plumb the
bits on all platforms back to gfx11, since the 3DSTATE_PS_EXTRA
enables already existed on ICL.
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29847>
The ALU-based implementation of the barycentric interpolation
intrinsics introduced by a subsequent commit will require some
primitive setup information not delivered in the PS thread payload
unless explicitly requested:
- "Source Depth and/or W Attribute Vertex Deltas" if a
perspective-correct interpolation mode is used -- Note that this is
already requested for CPS interpolation, we just need to enable it
in more cases.
- "Perspective Bary Planes" if a perspective-correct interpolation
mode is used.
- "Non-Perspective Bary Planes" if a non-perspective-corrected
interpolation mode is used.
- "Sample offsets" if any at_sample interpolation is used so the
coordinate offsets of the sample can be calculated.
This ALU implementation of barycentric interpolation will only be
needed for *_at_offset and *_at_sample interpolation, since the fixed
function hardware still computes barycentrics for us at the current
sample coordinates, only the cases that previously relied on the Pixel
Interpolator shared function need to be re-implemented with ALU
instructions, since that shared function will no longer exist on Xe2
hardware.
Thanks to Rohan for a bugfix of the uses_sample_offsets calculation,
this patch includes his fix squashed in.
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29847>
This has been required from the kernel for quite some time, but it
wasn't (and technically still isn't) explicitly checked. Commit
7da5b1caef changed the code paths such that an assertion is hit when
I915_PARAM_HAS_EXEC_TIMELINE_FENCES is not available.
Fixes: 7da5b1caef ("anv: move trtt submissions over to the anv_async_submit")
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29920>
For preambles, we don't actually care which invocation we get, so we
don't have to enable helper invocations when the preamble uses "getone."
Introduce a new intrinsic with the right semantics and plumb it through.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29914>
In a scenario where two non-concurrent cmdbufs are submitted to the
compute queue and with the second one using DGCC, the driver would have
chained the CS of the first cmdbuf to the new IB created right after
the DGC IB is executed.
Found while working on DGC task shader with vkd3d-proton.
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29913>
We cannot report a workgroup invocation and size bigger than
MAX_THREADS_PER_WG as splitting into serveral jobs has many limitations
that cannot be overlooked.
As such we limit to the MAX_THREADS_PER_WG property reported by kmod.
Fix "dEQP-VK.compute.pipeline.basic.max_local_size_*" failures.
Signed-off-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29872>
(Same as in Turnip)
We set LRZ_FEEDBACK_EARLY_LRZ_LATE_Z mask for rendering pass after
HW binning because:
- Draws with EARLY_Z contributed to depth buffer in BINNING stage;
- Draws with LATE_Z is what usually disables LRZ.
- Draws with EARLY_LRZ_LATE_Z are the ones we want because they
represent the common case of FS with "discard".
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25345>
We set LRZ_FEEDBACK_EARLY_LRZ_LATE_Z mask for rendering pass after
HW binning because:
- Draws with EARLY_Z contributed to depth buffer in BINNING stage;
- Draws with LATE_Z is what usually disables LRZ.
- Draws with EARLY_LRZ_LATE_Z are the ones we want because they
represent the common case of FS with "discard".
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25345>
Some draws do write depth but cannot contribute to LRZ during the BINNING pass
e.g. when fragment shader has "discard" in it, however they can contribute to
LRZ during the RENDERING pass via LRZ feedback meachanism. This may allow the
draws that follow to depth test against the updated LRZ, this is especially
important if such "bad" draws were at the start of the renderpass.
LRZ feedback happens during the RENDERING pass when LRZ_FEEDBACK_ZMODE_MASK
is set, if draw has a6xx_ztest_mode that has corresponding flag set in
LRZ_FEEDBACK_ZMODE_MASK - its depth values would be used for feedback.
LRZ feedback alongside with LRZ testing also works during sysmem rendering.
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25345>
The ir3_info is reset by ir3_collect_shader_info() on the expectation
that all info is collected inside that function. This meant that we were
accidentally disabling early preamble. Re-enable it.
We keep a copy in ir3_info for shader statistics in the next commit.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29903>
nir_opt_preamble sometimes adds useless expressions, in which case we
may have stc instructions and no corresponding use of the constant.
Things can go sideways when these aren't included in the constlen, so
far only observed when earlypreamble is enabled.
Fixes: ccc64b7e00 ("ir3: Plumb through store_uniform_ir3 intrinsic")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29903>
For unknown reasons, this is needed to avoid breaking
a bunch of tests:
.*tex-miplevel-selection.*
KHR-GL46.direct_state_access.framebuffers_texture_attachment,Fail
KHR-GL46.direct_state_access.framebuffers_texture_layer_attachment,Fail
.*.core.texture_cube_map_array.sampling
These failures were previously hidden by extra flushes in the
blitter that were removed in 969ed851.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29612>
radv has a comment in radv_meta_dcc_retile.c:
* BPE is always 4 at the moment and the rest is derived from the tilemode.
radeonsi has in si_retile_dcc:
/* We have only 1 variant per bpp for now, so expect 32 bpp. */
assert(tex->surface.bpe == 4);
This fixes ext_image_dma_buf_import-modifiers for radeonsi.
Cc: mesa-stable
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29612>
We shouldn't use this extension at all if we're not using the HTML
builder. This should hopefully fix this issue a bit more fundamentally.
This caused issues when using the spelling extension, something I do
locally from time to time.
Fixes: f72033bb70 ("docs: add bootstrap extension")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29888>
Previously, the register demand per instruction was calculated as the number of
live variables in the register file after executing an instruction plus additional
temporary registers, necessary during the execution of the instruction.
With this change, now it also includes all variables which are live right before
executing an instruction, i.e. killed Operands.
Care has been taken so that the invariant
register_demand[idx] = register_demand[idx - 1] - get_temp_registers(prev_instr)
+ get_live_changes(instr) + get_temp_registers(instr)
still holds.
Slight changes in scheduling:
Totals from 316 (0.40% of 79395) affected shaders: (GFX11)
Instrs: 301329 -> 300777 (-0.18%); split: -0.31%, +0.12%
CodeSize: 1577976 -> 1576204 (-0.11%); split: -0.21%, +0.10%
SpillSGPRs: 448 -> 447 (-0.22%)
Latency: 1736349 -> 1726182 (-0.59%); split: -2.01%, +1.42%
InvThroughput: 243894 -> 243883 (-0.00%); split: -0.03%, +0.03%
VClause: 6134 -> 6280 (+2.38%); split: -1.04%, +3.42%
SClause: 6142 -> 6137 (-0.08%); split: -0.13%, +0.05%
Copies: 14037 -> 14032 (-0.04%); split: -0.56%, +0.52%
Branches: 3284 -> 3283 (-0.03%)
VALU: 182750 -> 182718 (-0.02%); split: -0.04%, +0.03%
SALU: 18522 -> 18538 (+0.09%)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29804>
There should be some deeper causes to dig out. The bo-caching
system shouldn't affect the compression by design.
Fixes:
dEQP-GLES3.functional.texture.filtering.3d.formats.rgb9_e5_linear
dEQP-GLES3.functional.texture.filtering.3d.formats.rgb9_e5_linear_mipmap_linear
The two cases can pass if we run them respectively. But once they
are fed to glcts in a test case list file (test.list) to run together,
the second test case hangs for a while and eventually fails, regardless
which of them is the second.
./glcts --deqp-caselist-file=test.list
Signed-off-by: Jianxun Zhang <jianxun.zhang@intel.com>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29906>
The texturing and rendering preparation functions restrict
fast clear support in some cases to account for limitations
on prior platforms. Instead of updating those checks to avoid
resolves on Xe2, we can bypass them by representing the aux
state of a fast-cleared surface as compressed-no-clear. This
is valid because there is no longer a bit pattern which
references a clear value stored outside of the aux surface.
Suggested by Nanley Chery <nanley.g.chery@intel.com>
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/29906>
It turns out the problem I was trying to catch in be4fa59a72
("intel/brw: Clear write_accumulator flag when changing the
destination") also came from the DPAS lowering pass itself. Checking for
invalid uses of the feature in fs_validate helped detect the problem.
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28834>
The original goal was to get rid of a bunch of the magic constants
sprinkled through the function. Once I did that, I realized that there
was a lot my symmertry between the row-major and column-major paths
possible.
It's +6 lines of code, but about 15 of those lines are comments
explaining things that were not obvious in the original code.
v2: Save duplicated condition in a variable with a meaningful
name. Suggested by Caio.
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28834>
Even though the hardware does not naively support these configurations,
there are many potential benefits to advertising them. These
configurations can theoretically use half the memory bandwidth for loads
and stores. For large matrices, that can be the limiting in performance.
The current implementation, however, has a number of significant
problems.
The conversion from float16 to float32 is performed in the driver during
conversion from NIR. As a result, many common usage patterns end up
doing back-to-back conversions to and from float16 between matrix
multiplications (when the result of one multiplication is used as the
accumulator for the next).
The float16 version of the matrix waste half the possible register
space. Each float16 value sits alone in a dword. This is done so that
the per-invocation slice of an 8x8 float16 result matrix and an 8x8
float32 result matrix will have the same number of elements. This makes
it possible to do straightforward implementations of all the unary_op
type conversions in NIR.
It would be possible to perform N:M element type conversions in the
backend using specialized NIR intrinsics. However, per #10961, this
would be very, very painful. My hope is that, once a suitable resolution
for that issue can be found, support for these configs can be restored.
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28834>
Next patch will need to frequently get the count of supported engine
for compute and copy engines, so to reduce the overhead of doing
KMD queries at every call here caching this information into
intel_device_info struct.
With that ANV and Iris would need to set this information as intel/dev
can't depend on intel/common, so here adding a single function
to update intel_device_info with all fields filled by intel/common
functions.
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/29899>
Hawkmoth runs from the build-directory, which makes sense. However, we
set up a bunch of source-relative include paths, which will break if we
don't build in-tree.
Let's make these relative to the source-tree instead. We can deduce the
source-root from the parent directory of the current file.
Reviewed-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Eric Engestrom <eric@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11494>
The aliased WSI image creation path is very much like the AHB case. It's
also the same with the deferred ANB binding path to support
VK_EXT_swapchain_maintenance1. Drop the cap as mesa currently only
supports up to spec version 8 because the later versions haven't been
upstreamed to the Vulkan registry yet.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29864>
Wait and see if we actually have a candidate for saturate propagation
before requesting liveness info. Saves the calculation in the case
where we have nothing to do.
Cuts compile time in Borderlands 3 by -0.304754% +/- 0.194162% (n=25).
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29849>
When I wrote sparse resources support for Anv we didn't have TileYs
support so I made non-opaque binds work even for non-standard block
shapes, which meant the block size could be either 64k or 4k. Since
then we merged TileYs support and changed our sparse resources
implementation to treat all the non-standard block shape cases as
"everything is the miptail", which means non-opaque binds are not
possible. So here we adjust the code to more explicitly represent
that.
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/29337>
There are 3 different places in our code where we calculate the tile
size and until recently the 3 implementations were different and with
slight bugs. Unify everything and also change the calculation to use
tile_info->phys_extent_B.
While doing this we move the isl_surf_get_tile_info() calls from
anv_sparse_calc_block_shape() to its callers so we total amount of
times we call it doesn't change.
v2: Adjust the patch now that tile_info is not part of isl_surf
anymore.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> (v1)
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29337>
The code that tries to create a "pretend block shape" for linear
tiling surfaces was necessary back when we were going to support
sparse residency (non-opaque binds) for non-standard block shapes
(since there was uncertainty about TileYs support). That hasn't been
the case since before we merged sparse resources upstream, so remove
the code and leave an assertion instead, just in case.
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/29337>
Pass struct isl_tile_info to isl_choose_image_alignment_el() and its
subfunctions. We already compute isl_tile_info at isl_surf_init_s(),
don't make the subfunctions compute it again, just reuse the results.
Other subfunctions of isl_surf_init_s() also take the tile info as an
argument instead of recomputing it.
v2: Rebase after the gen20 version was added.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> (v1)
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com> (v2)
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29337>
This calculation was wrong for both compressed formats and
multi-sampled images. As a result, we misreported the image as having
a single miptail.
No Vulkan or GL CTS tests were tripping on this bug. I found this
while looking for tile size calculations after fixing a similar bug
elsewhere in the code.
The calculation should now match what we have in
anv_sparse_bind_image_memory(), which is widely tested.
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/29337>
We have to take the number of samples into account when calculating
the tile size. If we don't do this, multi-sampled images may end up
falling in the "goto out_everything_is_miptail" case, while in reality
multi-sampled images don't even have miptails.
Also assert that the value is one of the only two values we expect
this to be. This assert would have been useful to catch this issue,
since with multi-sampled images we were getting values like 16k or 32k
depending on the number of samples.
This helps move forward progress in some Zink tests, but does not
make them fully pass yet, as those tests are full of sub-cases and
this only helps some of them:
KHR-GL46.sparse_texture2_tests.UncommittedRegionsAccess
KHR-GL46.sparse_texture2_tests.SparseTexture2Commitment
KHR-GL46.sparse_texture2_tests.SparseTexture2Lookup
Fixes: 7ef3d652b2 ("anv/sparse: enable MSAA for Sparse when applicable")
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/29337>
The Vulkan spec splits sparse resources in two different features:
sparse binding and sparse residency.
Sparse binding is much simpler. It requires the resources to be fully
bound before being used and it treats them as a black box. We're
required to support sparse binding for all the formats that are
supported by non-sparse, but that's easy beacause this feature is
simpler.
Now sparse residency is the one where we're allowed to partially bind
resources, and the one that comes with more complicated features such
as block shapes and non-opaque binding of images. This feature is
subdivided into:
- sparseResidencyBuffer
- sparseResidencyImage2D
- sparseResidencyImage3D
- sparseResidency{2,4,8,16}Samples (which refers to 2D images)
Notice that there's no sparseResidencyImage1D. And if you read the
specs it's clear that sparse residency is meant for non-1D images.
Still, supporting it didn't require any extra effort in Anv so we just
did it.
That's until we started running GL CTS tests on Zink. There's a CTS
test that checks for the standard block shapes. It creates 1D images
and expects the block shapes for them to be the standard 2D block
shapes. While we could very well just patch
anv_sparse_calc_image_format_properties() to return the standard 2D
block shapes for 1D images, that's just wrong (block shapes for 1D
images are just line segments, not rectangles!) so let's just reject
this all until maybe one day Vulkan defines sparseResidencyImage1D and
we get GL_ARB_sparse_texture3 to match it, or somebody decides to
change the GL CTS test.
Testcase: KHR-GL46.sparse_texture2_tests.StandardPageSizesTestCase
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/29337>
I got the image alignment requirements for CPCB surfaces from Bspec
authors. The vertical alignment value of 8 was confirmed through the
Vulkan CTS test group, dEQP-VK.fragment_shading_rate*layered*. It also
happens to match the QPitch alignment requirement documented in the
Bspec. Hopefully the CTS will add tests for LOD2+ in order to exercise
the horizontal alignment value.
With this in place, we can start using Tile4.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/10784
Reviewed-by: Rohan Garg <rohan.garg@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29355>
This will prevent the dynamic loader to pick the wrong function once we
rename things to the proper API names.
In any case, this should have been done all along anyway.
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29855>
Compiler can't know that array_size() of the offsets parameter in
textureGatherOffsets is (at most) 4, so use a MIN2() to make the limit
visible. Just adding an assert() gets ignored in Release builds.
This fixes the following warning in Release compilation:
```
../src/compiler/glsl/glsl_to_nir.cpp: In member function ‘virtual void {anonymous}::nir_visitor::visit(ir_texture*)’:
../src/compiler/glsl/glsl_to_nir.cpp:2453:41: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
2453 | instr->tg4_offsets[i][j] = val;
| ~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~
In file included from ../src/compiler/glsl/glsl_to_nir.h:31,
from ../src/compiler/glsl/glsl_to_nir.cpp:29:
../src/compiler/nir/nir.h:2470:11: note: at offset 8 into destination object ‘nir_tex_instr::tg4_offsets’ of size 8
2470 | int8_t tg4_offsets[4][2];
| ^~~~~~~~~~~
../src/compiler/glsl/glsl_to_nir.cpp:2453:41: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
2453 | instr->tg4_offsets[i][j] = val;
| ~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~
../src/compiler/nir/nir.h:2470:11: note: at offset 9 into destination object ‘nir_tex_instr::tg4_offsets’ of size 8
2470 | int8_t tg4_offsets[4][2];
| ^~~~~~~~~~~
```
This is from: `gcc (GCC) 14.1.1 20240522 (Red Hat 14.1.1-4)`.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29508>
This fixes several downcasting of address to object types when the
original object types were either different or invalid.
This has been detected throught Undefined Behaviour Sanitizer (UBSan).
An example of such issue were:
`downcast of address 0x55559c0cbcc0 which does not point to an object of
type 'ir_variable' 0x55559c0cbcc0: note: object is of type 'ir_constant'
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29772>
Undefined Behaviour Sanitizer (UBSan) detected the following when
running testing `dEQP-VK.graphicsfuzz.cov-fold-negate-min-int-value`:
`negation of -2147483648 cannot be represented in type 'int'; cast to an unsigned type to negate this value to itself`
SPIR-V spec states that OpSNegate(0x80000000) has to return 0x80000000;
in our case, -2147483648 should be -2147483648.
While this is not causing any issue because compilers seem to be
behaving like that, it is still undefined behaviour, so it expects to be
this handled explicitly, which is the purpose of this commit.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29772>
Drop tu_sampler_ycbcr_conversion in favor of the common vk_ycbcr_conversion.
This allows using CreateSamplerYcbcrConversion and DestroySamplerYcbcrConversion
from the common runtime and will be required for vk_sampler and for using the
common ycbcr lowering later.
Signed-off-by: Valentine Burley <valentine.burley@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29808>
vkd3d-proton always sets the acceleration structure size to be the
whole buffer size. Because of that, allocating read back buffers
for all acceleration structures causes a system with a finite amount
of RAM to OOM.
This is solved by allocating read back buffers on build where the
required size is known.
Reviewed-by: Friedrich Vock <friedrich.vock@gmx.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29537>
"Rewrite and remove" is a super common idiom in NIR passes. Let's add a helper
to make it more ergonomic.
More the point, I expect that /most/ of the time when a pass rewrites uses, they
also want to remove the parent instruction. The principle reason not to is
because it takes extra effort to add in the nir_instr_remove and nir_opt_dce
will clean up after you eventually, right? From a compile time perspective, it's
better to remove earlier to reduce the redundant processing between the pass and
the next DCE run. So ... we want to be doing *more* removes. From a UX
perspective - the way to nudge devs towards that is to make the
preferred "rewrite-and-remove" pattern more ergonomic than the "rewrite but
keep". That justifies the simple "replace" name rather than something silly like
"rewrite_uses_and_remove".
---
Something else I've wanted for a while.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29817>
Yes, we're losing precision if this assert fails and it's wrong. It's also
necessary to implement GL in a reasonable way on Asahi. Remove the assert that
was recently added and add more comment context on the mess.
Fixes debug build regression on asahi:
dEQP-GLES3.functional.vertex_arrays.single_attribute.normalize.int.components4_quads1
Fixes: 22f1b04a99 ("nir/format_convert: Assert that UNORM formats are <= 16 bits")
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Suggested-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29820>
a7xx renamed events around flushing:
a6xx a7xx
FLUSH CLEAN
INVALIDATE INVALIDATE
FLUSH+INVALIDATE FLUSH
The FLUSH events stayed the same but now they also invalidate. By not
adopting the new CLEAN events, we're inadvertantly invalidating too
much.
This change is just a refactor, that makes generic code consistently use
the a7xx terminology. The next commit will actually make us use CLEAN.
Note that LRZ_FLUSH is deliberately not changed because it actually
also invalidates (and the real name on a6xx was FLUSH_AND_INVALIDATE).
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29824>
With the introduction of the orc jit and looking at the mess that
is integrating with LLVM pass mgmt, encapsulate the passmgr
interactions in an internal abstraction so it can be shared,
and the compiler code isn't so messy to read.
Acked-by: Konstantin Seurer <konstantin.seurer@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29796>
The static inline wrapper includes the header file relatively from where
`bindgen` gets executed, or so it seems.
And because meson doesn't allow us to add absolute paths, fs.relative_to
needs to be used. I'm sure we can come up with a better solution, but this
unbreaks builds.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/11178
Fixes: 53629b0a2d ("rusticl: make use of new `output_inline_wrapper` meson.rust.bindgen feature")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29275>
The original code has a private helper called in one place doing a
lookup that it's parent has already done, which could be null, except
that the parent verified that it isn't. Instead, let's pass the pointer
from the parent and assert it's non-null in the child for good
measure/documentation.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29666>
In this assert we want to enforce that if a cached buffer is created
it is a cached+coherent as Xe KMD don't support cached+incoherent.
Did not caught this issue because it only reproduces in platforms with
GPU outside of LLC.
Fixes: 9d8d5cf8c9 ("anv: Remove block promoting non CPU mapped bos to coherent")
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29826>
The r0.5 thread payload register contains Surface State Offset bits
[27:6] as bits [31:10], so we need to shift the register right by 4 in
order to get the surface state offset expected in ExBSO mode, which is
the only extended descriptor encoding supported by the UGM shared
function for SS addressing on Xe2+.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29543>
This field encodes bits [27:6] of the scratch surface state offset
according to the hardware spec, already on XeHP platforms. However,
on previous platforms we were passing bits [25:4] instead, which was
apparently okay for two reasons:
1/ We never used more than 8 MB of scratch surface states apparently.
2/ A shift right by 2 was implicitly happening while copying the
value of r0.5 into the address register holding the extended
descriptor, which with the ExBSO addressing mode disabled
considered bits [31:12] as the surface state index within the
pool.
However on Xe2 ExBSO addressing mode is always enabled for the UGM
shared function, so we have to add an extra SHR instruction to format
the extended descriptor regardless, and there is no point in
disobeying the hardware spec passing a left-shifted offset.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29543>
This field encodes bits [27:6] of the scratch surface state offset
according to the hardware spec, already on XeHP platforms. However,
on previous platforms we were passing bits [25:4] instead, which was
apparently okay for two reasons:
1/ We never used more than 8 MB of scratch surface states apparently.
2/ A shift right by 2 was implicitly happening while copying the
value of r0.5 into the address register holding the extended
descriptor, which with the ExBSO addressing mode disabled
considered bits [31:12] as the surface state index within the
pool.
However on Xe2 ExBSO addressing mode is always enabled for the UGM
shared function, so we have to add an extra SHR instruction to format
the extended descriptor regardless, and there is no point in
disobeying the hardware spec passing a left-shifted offset.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29543>
Xe2 replaces auxiliary surface mapping by software to compress buffers
with reserving part of the memory for the compression purpose.
To enable compression in Xe2 it is necessary to bind memory with one of
the PAT indexes that has compression enabled.
We're introducing 2 new iris_heaps to allocate compressed BO's out of
on Xe2, one for integrated and another for discrete platforms.
With these new iris_heaps we gain cache and sub-allocation for free.
If the compression requirements are met
iris_resource_image_is_pat_compressible() returns true so
BO_ALLOC_COMPRESSED is set and the the BO is allocated out of
the correct heap.
At this moment iris_resource_image_is_pat_compressible()
defaults to returning false as more work needs to be done but
the foundation for the compressed allocation is here.
Reviewed-by: Rohan Garg <rohan.garg@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28833>
Compressed memory types are not CPU visible and Vulkan specification
don't have any requirement about that but some applications like
vkcube fails to run without a host visible option, so here appending
default_buffer_mem_types and compressed_mem_types.
Reviewed-by: Rohan Garg <rohan.garg@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28833>
Xe2 replaces auxiliary surface mapping by software to compress buffers,
instead it reserves part of the memory for the compression purpose.
To enable compression in Xe2 it is necessary bind memory with one of
the PAT indexes that has compression enabled.
It is still always returning false in anv_image_is_pat_compressible()
as it still needs more work before compression can be enabled but the
foundation for the compressed allocation is here.
Reviewed-by: Rohan Garg <rohan.garg@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28833>
We'll reduce pitch alignment in a following patch. However, CCS
fast-clears don't seem to work unless the pitch is 512B aligned.
Disable fast clears for unaligned pitches.
Prevents the next patch from failing the following piglit tests:
* fbo-attachments-blit-scaled-linear
* hiz-stencil-test-fbo-d24s8
* hiz
* polygon-mode-facing
* clearbuffer-mixed-format
* glsl-lod-bias (transient failure)
No failures have been observed in anv, but there are more restrictions
for fast-clears in that driver compared to iris.
Note:
* The -fbo flag is necessary to make these fail. Otherwise, they end up
with aligned render targets.
* Each of these tests allocate an image that has a pitch greater than
512B and they collectively cover all the misalignment options - 128B,
256B and 384B.
Reviewed-by: Jianxun Zhang <jianxun.zhang@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29659>
Intel modifiers supporting compression are specified to be compatible
with the display engine, even if they won't actually be used for
scanout.
Attempting to capture a wider scope of modifiers resulted in test
errors. I chose to narrow the scope instead of digging into them.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Jianxun Zhang <jianxun.zhang@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29659>
Avoid using an isl_surf for the compression control surface on gfx12.
Instead, store the offset of this surface in the iris_resource struct.
The size of the surface is no longer stored, but it can be computed
on-demand with the aux-map helper functions.
This change enables us to get rid of the GFX12 CCS abstractions in ISL
that required all main surfaces to have a 512B-aligned pitch. This
requirement is seemingly only for display surfaces.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Jianxun Zhang <jianxun.zhang@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29659>
As each anv_device has its own address space it was necessary create
one dummy_aux_bo per anv_device.
Also this workaround requires us to disable the
buffer_length_in_aux_addr optimization, that is done in the physical
device creating because isl_dev of physical device is copied
to isl_dev in anv_device.
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/29619>
This workaround ask us to set a dummy aux address to all
SURFTYPE_BUFFERs with AuxiliarySurfaceMode == AUX_NONE.
It also says that the same dummy aux address can be reused acrsoss all
buffers.
So here adding dummy_aux_address to isl_device, ANV and Iris will
set a value to when running a in a GPU affected.
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/29619>
This job actually takes just under 5 minutes[*] without any fraction, so
there is no need for this, we can have full coverage and stay below the
10min-per-job limit.
[*] I've seen up to 10min when the CI is busy, so let's put the timeout
at 3x the normal run time.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29809>
I just saw more of these in other glsl versions, and it's likely that it
doesn't matter which version is active from our point of view, so let's
just put all of them in the same "flaky" bag.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29813>
Now that I got a hands on access to this GPU and could run deqp-vk, it uses
blob v676.0 and the values are different from v744.19. Not only they
are different, with the values from v744 there are CTS test faulures.
Fixes at least ASTC tests.
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29786>
We need some manual logic to work out the size of pData, so we handroll this
one. This fixes push DUT with emulated secondaries.
Affects dEQP-VK.binding_model.shader_access.secondary_cmd_buf.*push*templ* if
emulated secondaries are used.
Neither panvk nor dozen support push DUT yet, so this isn't hurting anyone and
doesn't need to be cc'd stable. But hopefully panvk & dozen get on that :}
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Konstantin Seurer <konstantin.seurer@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28682>
On a740 TPL1_DBG_ECO_CNTL1.TP_UBWC_FLAG_HINT must be the same between
all drivers in the system, somehow having different values affects
BLIT_OP_SCALE. We cannot automatically match blob's value, so the
best thing we could do is a toggle.
Example:
FD_DEV_FEATURES=enable_tp_ubwc_flag_hint=0
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29754>
si_get_shader_prefetch_size is called each time a shader is changed.
Since the size of a given variant never changes, we can compute the
value once and store the result.
This has to be done in 2 places:
* si_create_shader_variant for all types of shaders
* si_create_compute_state_async for compute shader, when a shader
is loaded from the cache.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29304>
We no longer need to reserve registers for constructing spill/fill
messages. We have split sends and construct message headers in new
temporary registers with a very short lifespan which are simply added
to the existing interference graph as new nodes and allocated via the
normal mechanism.
This means that when we need to spill for the first time, we can avoid
discarding and recomputing the entire interference graph. We also avoid
needing to recreate all spill candidate information once ra_allocate()
fails, because the graph remains valid, and none of the existing nodes
had any changes to their interference. The existing spill candidates
remain valid.
This will slightly help improve compile time when needing to spill.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25811>
Instead of reserving a register to contain the spill header, which
gets marked live for the entire program, we can just emit the ALU
instructions to build it on the fly. (This is similar to the way
we handle scratch on Alchemist with the newer LSC data port.)
There are a couple of downsides that make this not obviously a win.
First, in order to construct the scratch header on Gfx9-12, we have
to use fields from g0, which will have to remain live anywhere that
scratch access is required. This could negate the register pressure
benefits of creating the header on the fly. However, g0 is oft used
in other places anyway, so it may already be there. Another is that
it's a non-trivial number of ALU instructions to construct the value.
Still, trading lower pressure (so fewer spills, less memory access
and stalls) for more cheap ALU seems like it ought to be a win.
There is another valuable benefit: by not reserving a register, we
eliminate the need to reconstruct the interference graph. (The next
patch will actually do so.)
shader-db on Icelake shows spills/fills at 54/53 helped, 4/10 hurt,
and an 8% increase in ALU on affected shaders. Synmark's OglCSDof
(a benchmark that spills) performance remains the same on Alderlake.
fossil-db on Icelake shows a 5.6%/5.1% reduction in spills/fills and a
4% reduction in scratch memory size on affected shaders. Instruction
counts go up by 11.07%, but cycle estimates only increase by 0.57%.
Assassin's Creed Odyssey and Wolfenstein Youngblood both see 20-30%
reductions in spills/fills, a significant improvement.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25811>
When calculating the height for multi line uploads we should ensure that
we do not exceed max_dim rather than using at least max_dim.
The assert is also changed to ensure that we do not upload more than the
source size.
Fixes: 22e44d54fd
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29784>
Steps for uprev:
- copy files from BLAKE3/c src/util/blake3/
- edit README
- `for file in *.asm; do mv "$file" "${file%.asm}.masm"; done`
- keep
- blake3.h (no relevant changes), only change BLAKE3_VERSION_STRING
- blake3_sse2_x86-64_unix.S (no changes)
- blake3_avx512_x86-64_unix.S (no changes)
- blake3_sse41_x86-64_unix.S (no changes)
Acked-by: Marek Olšák <marek.olsak@amd.com>
Signed-off-by: David Heidelberg <david@ixit.cz>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29687>
The intention of this block was to set one of the flags that is used
to select a PAT index but this was doing more than that.
It was promoting WB+0 way coherency BOs to WC+1 way coherency possibly
causing regression in platforms without LLC.
anv_device_get_pat_entry() return WC/writecombining if no flags is
set so we don't need this block after all.
Reported-by: Sushma Venkatesh Reddy <sushma.venkatesh.reddy@intel.com>
Fixes: a65e982b44 ("anv: Split ANV_BO_ALLOC_HOST_CACHED_COHERENT into two actual flags")
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29769>
cmd->state.attachments was accessed out of bounds, which somehow instead
of crash caused the tracepoint to be skipped.
drawcall_bandwidth_per_sample_sum was divided by 0 when there were no
draw calls in a renderpass.
Fixes: 1aab0fc4f5
("tu: Add attachments' UBWC info to renderpass tracepoint")
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29752>
CTS tests both layered and separate DPB, but radv wasn't handling
layered properly when used with the tier 2 dpb handling.
This adjusts the addresses to use the layer index for tier2.
Fixes dEQP-VK.video.decode.*layered*
Cc: mesa-stable
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29758>
Previously, [SU]SCALED formats would hit the integer path and we would
generate:
((uint32_t)CLAMP(src[i], min, max)) & MASK
This is fine for unsigned scaled formats. However, for signed formats,
a negative float value cast to an unsigned integer yields undefined
results. On x86, it implicitly clamps to 0. This change makes us
generate:
((uint32_t)(int32_t)CLAMP(src[i], min, max)) & MASK
hich gets us correct casting.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28793>
It prevents the hazard when in the following case:
ldc.1.k.imm c[a1.x], 0, 1
(ss)mova1 a1.x, 8
The correct way is:
ldc.1.k.imm c[a1.x], 0, 1
(ss)mova1 a1.x, (r)8
Without it ldc may use a1.x which is set after ldc.
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27462>
This used to work by luck because the current DGC prepare shader
is using one descriptor set and it was the currently bound compute
shader... Using two descriptor sets or starting from 1 would just fail.
For indirect compute pipelines, descriptors must be emitted from the
DGC shader because there is no bound compute pipeline at all. This
solution is using indirect descriptor sets because it's much shorter
and easier to implement. This could be improved but nothing uses
indirect compute pipelines and this is like experimental stuff.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29700>
On newer devices where ZPASS_DONE events have sample count writing
abilities the firmware expects these events to come in begin-end pairs,
essentially corresponding to a typical occlusion query usage. Since this
event is also used in the autotuner we have to avoid event pairs to be
emitted in an interleaved fashion.
Additional renderpass state now tracks whether a given renderpass contains
an occlusion query. If so, autotuner will emit miscellaneous ZPASS_DONE
events in order to form its own begin-end pairs before and after the
renderpass commands.
Occlusion query behavior inside a renderpass doesn't change. But when used
outside of a renderpass, possible autotuner usage requires to again emit
ZPASS_DONE events that end up forming begin-end pairs of these events both
at the start and the end of the query.
Signed-off-by: Zan Dobersek <zdobersek@igalia.com>
Fixes: 4e6a1f8852 ("tu/autotune: Use `CP_EVENT_WRITE7::ZPASS_DONE` on A7XX")
Tested-by: Mike Lothian <mike@fireburn.co.uk>
Reviewed-by: Connor Abbott <cwabbott0@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29403>
When both an interval and some of its children would be live-in, we used
to add phis for all of them. This could lead to cases where the pressure
after spilling was higher than before.
This happens, for example, when both a split and its parent are live-in.
Before spilling, the split wouldn't add to the pressure because its
parent had already been inserted. After spilling, since we created a phi
for the split, the link with its parent would be lost and it would add
to the pressure.
Fix this by only adding phis for top-level intervals and adding splits
after them.
Fixes: 613eaac7b5 ("ir3: Initial support for spilling non-shared registers")
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29497>
There were a few places that used an instruction pointer to decide where
new instructions should be created. NULL was used to add them at the end
of the block. While fixing a spilling bug, a new option was needed to
add instructions at the beginning of the block. This will be much easier
to implement using cursors.
Fixes: 613eaac7b5 ("ir3: Initial support for spilling non-shared registers")
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29497>
Whenever instructions need to be created at specific locations, ir3
often passes around an instruction pointer. When set, new instructions
are added before or after it (depending on the context). When NULL, new
instructions are added at the end of the block. This whole scheme is
confusing.
This patch adds ir3_cursor and ir3_builder structs and the associated
helper functions. The API mirrors the one from nir_cursor/nir_builder.
This patch does not refactor existing code to use the new API. This will
happen in future patches.
Fixes: 613eaac7b5 ("ir3: Initial support for spilling non-shared registers")
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29497>
ir3_force_merge (through merge_merge_sets) expects instructions to be
indexed. However, the instructions created during spilling would not be
automatically indexed at this point.
Fixes: 613eaac7b5 ("ir3: Initial support for spilling non-shared registers")
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29497>
It might happen that a collect that cannot be coalesced with one of its
sources while spilling can be coalesced with it afterwards. In this
case, we might be able to remove it in remove_src_early during spilling
but not afterwards (because it may have a child interval). If this
happens, we could end up with a register pressure that is higher after
spilling than before. Prevent this by never removing collects early
while spilling.
Fixes: 613eaac7b5 ("ir3: Initial support for spilling non-shared registers")
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29497>
I might be wrong about this one, but I don't see what it could be for.
We don't want to delete too much either, in case this script gets called
in the same job as another test suite.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29749>
Copy propagation often eliminates all uses of an instruction. If we
detect that we've done so, we can eliminate the instruction ourselves
rather than leaving it hanging until the next DCE pass.
This saves some CPU time as other passes don't see dead code.
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28666>
The new def-based pass works better in many cases, and should be less
resource intensive. However, the limited visibility of the defs-based
pass due to many values not being SSA yet makes it unable to fully
replace the old pass. Try the new one, and if it can't make progress,
then try the old one. That way, things will mostly be handled by the
new pass, but everything that was being cleaned up still will be.
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28666>
While the limited visibility due to partial SSA is a downside to the new
pass, it has a huge number of advantages that make it worth switching
over even now. It's much more efficient, can eliminate redundant memory
loads across blocks, and doesn't generate loads of unnecessary copies
that other passes have to clean up. This means we also eliminate the
infighting between the old CSE, coalescing, and copy propagation passes.
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28666>
This has a number of advantages compared to the pass I wrote years ago:
- It can easily perform either Global CSE or block-local CSE, without
needing to roll any dataflow analysis, thanks to SSA def analysis.
This global CSE is able to detect and coalesce memory loads across
blocks. Although it may increase spilling a little, the reduction
in memory loads seems to more than compensate.
- Because SSA guarantees that values are never written more than once,
the new CSE pass can directly reuse an existing value. The old pass
emitted copies at the point where it discovered a value because it
had no idea whether it'd be mutated later. This led it to generate
a ton of trash for copy propagation to clean up later, and also a
nasty fragility where CSE, register coalescing, and copy propagation
could all fight one another by generating and cleaning up copies,
leading to infinite optimization loops unless we were really careful.
Generating less trash improves our CPU efficiency.
- It uses hash tables like nir_instr_set and nir_opt_cse, instead of
linearly walking lists and comparing each element. This is much more
CPU efficient.
- It doesn't use liveness analysis, which is one of the most expensive
analysis passes that we have. Def analysis is cheaper.
In addition to CSE'ing SSA values, we continue to handle flag writes,
as this is a huge source of CSE'able values. These remain block local.
However, we can simply track the last flag write, rather than creating
entire sets of instruction entries like the old pass. Much simpler.
The only real downside to this pass is that, because the backend is
currently only partially SSA, it has limited visibility and isn't able
to see all values. However, the results appear to be good enough that
the new pass can effectively replace the old pass in almost all cases.
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28666>
Like NIR, we print SSA defs as %1, %2, and so on. The number here is
the VGRF number. VGRFs that don't correspond to a SSA def remain
printed as vgrf1, vgrf2, and so on.
This makes it much easier to see what values are SSA and which aren't.
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28666>
Even without a full use list, simply tracking the number of uses will
let us tell "this is the only use of the def" or "we've just replaced
all uses of a def". It's inexpensive to calculate and will be useful.
(rebased by Kenneth Graunke)
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28666>
Our code to initialize gl_SubgroupInvocation uses multiple instructions
some of which are partial writes. This makes it difficult to analyze
expressions involving gl_SubgroupInvocation, which appear very
frequently in compute shaders.
To make this easier, we add a new virtual opcode which initializes
a full VGRF to the value of gl_SubgroupInvocation. (We also expand
it to UD for SIMD8 so there are not partial write issues.) We then
lower it to the original code later on in compilation, after we've
done the bulk of our optimizations.
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28666>
The support is incomplete and largely untested, but more importantly
glsl ir is depreciated at this point. This feature was added to support
building additional passes but that shouldn't ever be needed from here
on.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29469>
for drivers that don't support PIPE_CAP_SHAREABLE_SHADERS,
the zombie shader mechanism is used, storing shaders to delete after
the next flush
the zombie mechanism also calls bind_*_state(pipe, NULL) during deletion,
however, which breaks drivers in the following scenario:
* create_all_shaders(pipe_A)
* bind_vs(pipe_A, vs_A)
* bind_fs(pipe_A, fs_A)
* draw(pipe_A)
* makeCurrent(pipe_B)
* delete_vs(pipe_B, vs_B)
* vs_B must only be deleted on pipe_A
* zombie_shader_add(pipe_A, vs_B)
* makeCurrent(pipe_A)
* free_zombie_shaders(pipe_A)
* bind_vs(pipe_A, NULL)
* delete_vs(pipe_A, vs_B)
* draw(pipe_A)
* boom
the problem being that bind_vs(pipe_A, NULL) was called when deleting
vs_B, but it was actually vs_A which was bound
to solve this, just flag the shader state for updating and let st figure it out
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/11122
cc: mesa-stable
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29680>
Most passes want to preserve this specific combination of metadata, so let's add
an alias for the combination. The alias communicates that the control flow graph
is preserved, rather than a particular statement about e.g. dominance
preservation.
You don't need to understand dominance to write a simple
nir_shader_instructions_pass. And since you were going to cargo cult the
metadata anyway, this way you'll cargo cult a version you're more likely to
understand.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Acked-by: Karol Herbst <kherbst@redhat.com>
Reviewed-by: Konstantin Seurer <konstantin.seurer@gmail.com>
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29745>
The semantics of discard differ between GLSL and HLSL and
their various implementations. Subsequently, numerous application
bugs occurred and SPV_EXT_demote_to_helper_invocation was written
in order to clarify the behavior. In NIR, we now have 3 different
intrinsics for 2 things, and while demote and terminate have clear
semantics, discard still doesn't and can mean either of the two.
This patch entirely removes nir_intrinsic_discard and
nir_intrinsic_discard_if and replaces all occurences either with
nir_intrinsic_terminate{_if} or nir_intrinsic_demote{_if} in the
case that the NIR option 'discard_is_demote' is being set.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27617>
Vectorization can make the constant layout worse and increase
the constant register usage. The worst scenario is vectorization
lowered indirect register access, where we access i-th element
and later we access i-1 or i+1 (most notably glamor and gsk shaders).
In this case we already added constants 1..n where n is the array
size, however we can reuse them unless the lowered ladder gets
vectorized later.
Thus prevent vectorization of the specific patterns from lowered
indirect access.
This is quite a heavy hammer, we could in theory estimate how many
slots will the current ubos and constants need and only disable
vectorization when we are close to the limit. However, this would
likely need a global shader analysis each time r300_should_vectorize_inst
is called, which we want to avoid.
So for now just don't vectorize anything that loads constants if we
already have lot of uniforms.
This is the final missing piece to make glamor work on R400.
shader-db R420:
total instructions in shared programs: 107288 -> 107290 (<.01%)
instructions in affected programs: 236 -> 238 (0.85%)
helped: 2
HURT: 3
total temps in shared programs: 17730 -> 17726 (-0.02%)
temps in affected programs: 41 -> 37 (-9.76%)
helped: 4
HURT: 0
total cycles in shared programs: 163251 -> 163251 (0.00%)
cycles in affected programs: 478 -> 478 (0.00%)
helped: 2
HURT: 3
GAINED: 7 (2 glamor and 5 GSK shaders)
RV370 is quite similar instruction/temp-wise, but we don't gain any
shader there, because they are all over the 64 instructions limit...
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/10787
Signed-off-by: Pavel Ondračka <pavel.ondracka@gmail.com>
Reviewed-by: Filip Gawin <filip.gawin@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29734>
The commit 973e6f3b implemented compaction of the stream-number space. The
functions `update_vertex_elements(_sw)` began using the post-compacted
stream-numbers/indices when maintaining the `stream_usage_mask` and
when reading from the arrays `vtxstride` and `stream_freq`.
But, the `stream_instancedata_mask`, with which the `stream_usage_mask`
is compared/bitwise-anded, maintains bits for the pre-compacted indices.
Additionally, the information within the arrays is stored using the
pre-compacted indices.
The functions have a disagreement, regarding the type (pre- vs post-
compacted) of indices, with the rest of the relevant source. This change
removes the disagreement by having them use pre-compacted indices when
maintaining the `stream_usage_mask` and when reading from the arrays.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/11283
Fixes: 973e6f3b ("gallium: remove start_slot parameter from pipe_context::set_vertex_buffers")
Reviewed-by: Axel Davy <davyaxel0@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29704>
If the application binds graphics shaders and that RADV performs an
internal operation with a compute pipeline, no shader objects would be
restored because binding the internal compute pipeline resets the ESO
state.
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29678>
`src/asahi/lib/agx_device.c` includes `git_sha1.h` since
0be124b77e ("asahi: Deserialize libagx when opening device"),
although it only started making use of it once ece3896d5b
("asahi: add broken bits of unstable Linux UAPI") was merged.
Regardless, without this meson change, this leads to a race condition in
builds, where `git_sha1.h` might be built (if ever) after `agx_device.c`.
Fixes: 0be124b77e ("asahi: Deserialize libagx when opening device")
Fixes: ece3896d5b ("asahi: add broken bits of unstable Linux UAPI")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29750>
We compute and store pipeline flags in the pipeline object but
we may need to access flags even in the case where the pipeline
init fails.
Fixes: 3f3c83a6b7 ('v3dv: handle VkPipelineCreateFlags2CreateInfoKHR')
Fixes: dEQP-VK.pipeline.monolithic.creation_cache_control.graphics_pipelines.batch_pipelines_early_return_maintenance5
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29669>
We need a heuristic for handling GS side effects in the least surprising way
possible. Upgrade our previous heuristic to a better one, moving more side
effects into the prepass from the rast shader. This is technically an optimization but mitigates VDM timeouts in absurd Vulkan CTS cases.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29742>
It's possible if nouveau_ws_bo_destroy() races with
nouveau_ws_bo_from_dma_buf() for the BO to be found in the cache and
referenced between dropping the final reference and actually invoking
GEM_CLOSE. This would result in us having a closed BO somewhere in our
cache.
Fixes: c370260a8f ("nouveau/winsys: Add dma-buf import support")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29737>
I've been seeing a bunch of read page faults at the end of the
shader allocation, nvk uses a full page at the end to overallocate
so align with that and see if it goes away.
ahulliet and skeggsb both said 2k was used.
Cc: mesa-stable
Reviewed-by: Arthur Huillet <ahuillet@nvidia.com>
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29722>
MOV_INDIRECT picks one lane from the src[0] and moves it to all lanes
in the destination. Even if we split the instruction, src[0] should
remain identical.
Noticed this while trying to use this instruction in SIMD32. All
current use cases are limited to SIMD8 shaders (or SIMD16 on Xe2). Or
maybe in SIMD32 but with a uniform src[0]. That's we think we've never
seen the issue so far.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: mesa-stable
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28036>
if mesh and task shaders are bound separately, and if they have different
workgroup sizes, the setting of workgroup size will be broken if
set during shader bind
this must be deferred to draw time to pull the correct values
cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29733>
Turns out the current approach makes implementation of advanced features
like update-after-bind or shader modules quite challenging. Instead of
adding hacks all over the place to support these features, let's use
the Valhall descriptor model.
Each shader now gets its own descriptor tables, which are fed by pilot
shaders copying the descriptors used by the shader from the descriptor
sets currently bound the command buffer.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Co-developped-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29654>
The Bifrost descriptor model is a dead end for advanced features like
shader modules, pipeline libraries or update-after-bind. Let's prepare
the Valhall implementation so we can re-use it on Bifrost.
The implementation itself was pretty generic already. We just need to
map image descriptors to AttributeBuffer instead Texture descriptors,
and the Buffer object had no equivalent on Bifrost, so we just use a
software-defined panvk_ssbo_addr object containing the SSBO address and
size, and make sure this object is padded to 32-bytes.
Signed-off-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/29654>
The shifted offsets generated by ir3_nir_lower_io_offsets are not always
optimized well by nir_opt_offsets. If the offset to be shifted has the
form "iadd constant, foo" don't shift the result but transform it to
"iadd constant>>shift, (ushr foo, shift)". This ensures nir_opt_offsets
(which only looks for iadds) can fold the constant into the immediate
offset.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28664>
Add the BASE index to the load/store_ssbo_ir3 intrinsic to store an
immediate offset. This offset is encoded in the corresponding fields of
isam.v/ldib.b/stib.b.
One extra optimization is implemented: whenever the regular offset is
also a constant, the total offset (regular plus immediate) is aligned
down to a multiple of the max immediate offset and this is used as the
regular offset while the immediate is set to the remainder. This ensures
that the register used for the regular offset can often be reused among
multiple contiguous accesses.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28664>
Since a7xx, isam.v can be used to perform multi-component SSBO loads.
Use this whenever possible to prevent excessive scalarization. isam.v
also uses only a single coordinate (as opposed to a 2-dimensional
coordinate for isam) so this reduces register pressure as well.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28664>
isam.v is a version of isam that can load multiple components from IBOs.
It uses some bits that are used for different purposes in other tex
instructions:
- bit 50 (.v): .s elsewhere
- bit 53 (indicates whether an immediate offset is used): .p elsewhere
- bit 18 (.1d when not set, has to be set for .v): 0 elsewhere
For this reason, the bitset hierarchy for cat5 had to be reordered a
bit.
The immediate offset is encoded as an extra (immed) source register and
an instruction flag (to be able to make the distinction between offset
zero and no offset, although this might not be useful).
This also adds a flag for the .1d field. Since this bit is active-low,
this flag has inverted semantics: setting it will make .1d inactive.
Note that some existing disassembler tests for isam had to be updated
because the bit is never set and this is now disassembled as .1d. This
matches the blob's disassembler.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28664>
Rebasing around this patch has been a significant burden for development.
Staging patches to asahi/mesa helps somewhat but 1. it's still really
frustrating to have this much divergence with upstream, and 2. ideally we
wouldn't have to do that.
The kernel upstreaming is stalled for various reasons. This patch adds
compile-only code to speak the unstable Linux UAPI for the SOLE purpose of
reducing my rebase pain... NOT to actually work.
It is NOT for users OR distro maintainers. asahi will refuse to probe on
upstream Mesa to protect against regressions. The uapi is NOT STABLE and
upstream Mesa CANNOT be used with it. Attempting to bypass this WILL give you a
broken system.
This patch employs several layers of deterrents against system-breaking
enablement. With a lot of warning text at the relevant sites. Hopefully that is
good enough to prevent people from breaking systems. And if people brazenly
ignore all of the above ... they get to pick up the pieces.
You have been warned.
---
There is significant prior art for Mesa including downstream kernel uapi
supports in-tree:
* powervr (downstream android driver)
* turnip (downstream kgsl android driver)
* asahi ... ironically (prop macOS kernel driver)
* maybe vc4?
Linux is only special because of distros shipping tagged Mesa releases. The
several layers of guards here guarantee that no tagged Mesa release would
possibly probe even on an asahi downstream kernel. A distro would need a
significant scary patch to make it probe. If/when it breaks, that's on them
and they pick up the pieces.
I make a stability guarantee ONLY for Fedora Asahi Remix -- where we push
packages for both a downstream kernel and Mesa in tandem, while we patiently
wait for upstreaming -- and that is *it*. It will be a nice future when this all
works upstream, but unfortunately we're not there yet.
Acked by Dave [1] and Sima [2]
[1] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29620#note_2444189
[2] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29620#note_2445155
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Co-developed-by: Asahi Lina <lina@asahilina.net>
Signed-off-by: Asahi Lina <lina@asahilina.net>
Co-developed-by: Sergio Lopez <slp@sinrega.org>
Signed-off-by: Sergio Lopez <slp@sinrega.org>
Co-developed-by: i509VCB <git@i509.me>
Signed-off-by: i509VCB <git@i509.me>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29620>
Having zero consts in one FS may corrupt consts in follow up FSs,
on such GPUs blob never has zero consts in FS. The mechanism of
corruption is unknown.
Fixes geometry flickering in a number of games, including:
Baldur's Gate 3
Assasin's Creed Rogue
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29357>
Copying UBWC image via BLIT_OP_SCALE may be corrupted if previously
someone copied image with bit 18 set in TPL1_DBG_ECO_CNTL1.
Found by replaying blob's cmdstream on a740, but somehow this issue
doesn't happen on Android.
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29358>
If we have an array of multi-planar descriptors, buffer_list was
incorrectly incremented and this could have overwritten some BO entries.
In practice, this situation should be very rare because most of the
applications enable the global BO list.
Cc: mesa-stable
Closes: #10559
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28816>
Fix compilation failure when image is embedded in struct when
GL_EXT_shader_image_load_formatted is enabled:
struct GpuPointShadow {
image2D RayTracedShadowMapImage;
};
layout(std140, binding = 2) uniform ShadowsUBO {
GpuPointShadow PointShadows[1];
} shadowsUBO;
Compile log:
error: image not qualified with `writeonly' must have a format layout qualifier
Fixes: 082d180a22 ("mesa, glsl: add support for EXT_shader_image_load_formatted")
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Signed-off-by: Qiang Yu <yuq825@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29693>
This is what the old GL driver did and appears to be what the blob does
as well. They should pipeline much better than full buffer re-binds
which appear to be causing stalling issues inside the GPU.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29591>
We want everything that touches the root table to go through ldc path
and not to use global loads. This means that we need to do some
juggling to handle dynamic SSBO descriptors in the variable pointers
case.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29591>
Looking at binding_layout->desc_type is sketchy in the face of mutable
descriptors. It's safer for load_descriptor() to just return the
descriptor. load_descriptor_for_idx_intrin() knows about the
descriptor's actual shader usage and we can do the optimization there.
This isn't actually a bug fix. The optimization just didn't happen in
the presence of mutable descriptors.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29591>
The ldc_nv and ldcx_nv intrinsics correspond to the index and bindless
forms of NVIDIA's LDC instruction, respectively. ldc_nv is pretty much
load_ubo without some of the unnecessary constant bits while ldcx_nv
takes a 64-bit bindless handle instead of an index. The other two give
us a little control over register allocation at the NIR level to ensure
that LDCX handles are placed in uniform registers.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29591>
We can propagate within a non-uniform block just fine but not across
them because that might change live registers in unpredictable ways.
The real boundary here is that we can't propagate across an OpPin but
that's a lot harder to express.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29591>
These act as a vector OpCopy, except that copy-prop can't see through
them and the destination of OpPin gets pinned in the register file and
is unallowed to move. Of course, we have to be careful with these
because spilling can't spill them, either. If we have too many live
pinned values at the same time, spilling or RA may fail.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29591>
Unlike the pinned set in VecRegAllocator which exists for the duration
of an instruction, registers which are pinned in the main allocator are
pinned until the register is freed. The pinned set in VecRegAllocator
is initialized to a copy of the one in the main register allocator.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29591>
The really tricky case here is phis, which may have a uniform def even
though some of the srcs are non-uniform. This happens because of the
restriction elsewhere that requires UGPRs and UPreds to only ever be
written in uniform control-flow.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29591>
Because we go in and out of SSA, all the phis get re-created and the new
phis will default to divergent. This little pass attempts to prove as
many of the phis convergent as possible.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29591>
We know this is wrong. In many cases, they're faster than warp
instructions, sometimes with a latency as low as 2. However, there seem
to be a bunch of exceptions we don't understand and it's better to be
more concervative and have correct shaders.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29591>
This time we take into account WaR and WaW dependencies and not just RaW
dependencies. The NVIDIA ISA is actually quite dynamic and the not
everything is nicely pipelined such that writes always happen at
consistent cycles. There are exact rules, of course, but we don't know
what those are so we need to make some worst-case assumptions.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29591>
UGPRs in warp instructions are treated more like cbufs than GPRs.
You're only allowed to have one and it has to share space with the
possible cbuf or immediate. This means we need to treat them as a "not
a register" case for warp instructions but as a register for uniform
instructions.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29591>
This requires a pretty significant rework of encode_alu_base(). In
particular, we can't know the register file that's going to be used
until we get into encode_alu_base() so ALUSrc::from_src() can't handle
Zero itself. Instead, we defer to a new ALUSrc::with_op_uniformity()
helper which does a postprocess step.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29591>
This makes encode_alu() take Option<&Src> and call ALUSrc::from_src()
itself. This is necessary for handling uniform ALU correctly as we
can't actually separate Reg from UReg without knowing what kind of ALU
op we are. While we're here, take an Option<&Dst> instead of
Option<Dst>.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29591>
Once we start using UGPRs, it's possible to have a vector with a mix of
GPRs and UGPRs. This isn't actually allowed by the hardware but it's
possible as an intermediate state thanks to copy-propagation.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29591>
We're allocating one register file at a time and our invariants are
per-file so we don't want to check the components assumption until we've
checked that it uses the active file.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29591>
Instead, do the same thing we do for float modifiers and use OpIAdd2 or
OpIAdd3. This makes for a little more work in copy-prop but the extra
opcode and lowering pass just isn't worth it.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29591>
Remove a legacy workaround where presence of modifiers in framebuffer
state results in `needs_present` to be set without a good reason.
This prevents hitting an assertion for framebuffers that use DRM
modifiers, e.g. via GBM BO alloc -> EGLImage import -> GL FBO bind.
Co-authored-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Heinrich Fink <hfink@snap.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29715>
When the namespace have a dash, this method cannot recogniza properly
the fields in a url. Better to use a regular expression quickly defining
the fields. The exception raised, when the pattern is not recognized
would help more the handler.
Signed-off-by: Sergi Blanch Torne <sergi.blanch.torne@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29683>
All the MI_SDI currently have forced write checks (meaning the command
streamer will stall until completion) on Gfx12.0+.
Now on Gfx12.0/12.5, the read commands have implicit waits on previous
writes (BSpec ). So if we're only dealing with CS writes & reads, we
don't need forced write checks.
In the few cases where CS is writing data for other bits of HW, we
need the forced write checks. This change adds an API that will let
the driver decide when to enable forced write checks.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29571>
With this change, the engine initialization batches are build and
submitted at vkCreateDevice() but the function doesn't wait for them
to complete. Instead we wait at vkDestroyDevice() or whenever another
submission happens on the queue, we check whether the initialization
batch has completed (without waiting) and free it if completed.
Seems to be about 25% reduction time of vkCreateDevice()
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28975>
The array pool does a single allocation and then splits it out. The
downside is that the pool is not lockless, but for border colors it
likely doesn't matter much as there is a max border colors for 4k.
Seems to be a 30% time reduction for vkCreateDevice()
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28975>
The Vulkan spec says:
"If pColorAttachmentInputIndices is NULL, it is equivalent to setting
each element to its index within the array."
Fix updated dEQP-VK.dynamic_rendering.primary_cmd_buff.local_read.*.
v2: Fix it correctly (Samuel)
Fixes: 03490ec019 ("vulkan/runtime: rework VK_KHR_dynamic_rendering_local_read state tracking")
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29703>
Add the fixed-rate compression ratios exposed by GL and Vulkan to the
flags for gbm_bo and gbm_surface creation, and intersect these with the
list of supplied modifiers to add another filter.
Although gbm_surface could support this by the EGLSurface flags in
EGL_EXT_surface_compression, gbm_bo cannot: it allocates a buffer first
and then imports it into the consuming API post-hoc, after the modifier
is already (must be) known. It seems more important to keep the
gbm_surface and gbm_bo APIs in sync, so keep the responsibility for
filtering on the GBM side.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27109>
This adds two new methods for the image extension (version 22):
- Query the supported compression bitrates for a given format
- Query the modifiers associated with a given format and bitrate
The interface user can then use createImageWithModifiers to
actually allocate the fixed-rate compressed image. When the default
bitrate is requested, one can query the image for the
__DRI_IMAGE_ATTRIB_COMPRESSION_RATE attribute to determine the
compression rate that was actually used.
Signed-off-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27109>
According to PRMs:
"All parameters are of type IEEE_Float, except those in the The ld*,
resinfo, and the offu, offv of the gather4_po[_c] instruction message
types, which are of type signed integer."
Currently, we load parameters with the correct types, but use them as send
sources with the default float type, which may confuse passes downstream.
Fix this by actually storing the retyped sources.
Cc: mesa-stable
Signed-off-by: Sviatoslav Peleshko <sviatoslav.peleshko@globallogic.com>
Reviewed-by: Sagar Ghuge <sagar.ghuge@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29581>
For A6XX it's a no-op, but A7XX+ doesn't clamp to [0,1] with disabled
depth clamp, to support VK_EXT_depth_clamp_zero_one we have to always
enable clamp and manually set depth range to [0,1] when rs->depth_clamp_enable
is false.
Passes:
dEQP-VK.depth.*
dEQP-GLES3.functional.fbo.depth.depth_test_clamp.* (zink)
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29387>
This AUX-TT is only updated on the CPU since ee6e2bc4a3 ("anv: Place
images into the aux-map when safe to do so"). So the only really
important invalidation that needs to happens is on the beginning of a
primary command buffer.
We are required to idle the pipes prior invalidation the AUX-TT. This
might not be happening when the invalidation is put at the beginning
of the secondary command buffers.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: mesa-stable
Reviewed-by: Rohan Garg <rohan.garg@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29671>
nightly_compare.
Compare the two latest scheduled pipelines and provide information
about the jobs you're interested in.
The job part reports:
- RED previously passing jobs
- YELLOW jobs which failed before, but continue to fail
here is also available link to the previous failed run
- If no job failing, program exits.
The test part reports:
- everything in lovely table
If any failing job is found, after this phase, commit list between these
two scheduled run is printed (you can also use the WebUI link).
Example: I care about all Adreno jobs passing and one Radeon (r300)
with gallium-nine tests.
```
./bin/ci/nightly_compare.py --target "a[3-7][0-9][0-9].*|r300-rv530-nine"
```
Co-authored-by: Sergi Blanch Torne <sergi.blanch.torne@collabora.com>
Signed-off-by: David Heidelberg <david@ixit.cz>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29392>
This change updates the affected calls to the proper function
which is radeon_set_config_reg().
For instance, this issue is triggered with
"piglit/bin/textureSize tes isampler2DMSArray -auto -fbo":
vertex-program-two-side: ../src/gallium/drivers/radeonsi/si_state_shaders.cpp:4981: void si_emit_spi_ge_ring_state(si_context*, unsigned int): Assertion `(0x008988) >= CIK_UCONFIG_REG_OFFSET && (0x008988) < CIK_UCONFIG_REG_END' failed.
Fixes: bd71d62b8f ("radeonsi: program tessellation rings right before draws")
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29645>
a93932daf0 ("ci/meson: reuse meson installation") forgot to
bump the image tags, and as a result this was merged untested and turned
out to be broken, as the fedora image.
The issue is that python in the Fedora image is not flagged as
EXTERNALLY-MANAGED, unlike what Debian does, so the
`--break-system-packages` is invalid.
Instead, remove this flag from the debian image as it makes very little
sense in a docker image.
Fixes: a93932daf0 ("ci/meson: reuse meson installation")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29673>
When the tool is used to stress test a pipeline, if there are jobs already ran,
use their information like it does when the stress flag is not set.
This provides consistency between the behavior when stress argument is not set,
to when it is set. When it is not set, it uses the information about jobs that
are already done. When it is set, it has to use the information about the
already ran jobs. Also, it saves resources by triggering the minimum required.
Signed-off-by: Sergi Blanch Torne <sergi.blanch.torne@collabora.com>
Reviewed-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29432>
VK_KHR_maintenance5 adds two new optional formats:
- VK_FORMAT_A1B5G5R5_UNORM_PACK16_KHR
- VK_FORMAT_A8_UNORM_KHR
The former we support natively, the latter we don't. We could
try to implement A8 with some effort by mapping it to R8 with
a 000X swizzle but that alone won't be enough, some issues we
would have to solve include:
- Border colors won't work because the texture shader state
swizzle also applies to these, so our 000X swizzle would mess
things up for them and since we don't know the format used with
the sampler in the general case, we would have always have to
create two samplers internally, one adequate for A8 and one for
the rest of formats and choose one or the other at run time.
- We would have to convert the A8 format to a compatible
R8 format but most of the transfer operations. This should be
fairly trivial since we already have infrastructure for this.
- At rendering time we would need to ensure we make our writes
from the alpha channel. This would probably require that we
use the color_fmt from the fs_key to swizzle color writes in
shaders.
- We would probably also need to special case the format for
color clears, etc
So for now, we don't support it.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29643>
This value is intended to be used to remove out of bounds array
access when unrolling loops so it should contain the comparison
that contains the the induction variable not the overall
condition of the loop terminator. So here we update the instruction
when dealing with iand/ior loop terminator conditions.
Acked-by: Pavel Ondračka <pavel.ondracka@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28998>
nir_lower_frag_coord_to_pixel_coord was adding .5 to work around that the
drivers were mistakenly setting PIXEL_COORD_HALF_INTEGER. With the
setting corrected, the GL frontend handles it appropriately (instead of
subtracting half in the frontend for ARB_fragment_coord_conventions
integer setting and then adding the half back here), and makes the pass
reusable from Intel.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29585>
GFX versions older than GFX 20 have 'Thread Preemption disable' while
GFX 20 has 'Thread Preemption' with value flipped in compute walker
instruction.
So here by default enabling thread preemption, only disabling it
when BTD mode is enabled as instructed in Wa_14017794102.
Similar for 3DSTATE_BTD, enabling preemption by default and
only disabling when platform is affected by Wa_14017794102.
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/29616>
Right now we have a statically allocated vk_graphics_pipeline_state,
that we declare at pipeline_init, and fill at
pipeline_init_dynamic_state. This one can be static as right now it is
only needed during pipeline_init lifetime.
But to fill it, we need a vk_graphics_pipeline_all_state structure,
that right now we declare at pipeline_init_dynamic_state. But that one
become part of that vk_graphics_pipeline_state, so still needed at
pipeline_init.
This was detected when trying to refactor the code to use the
pipeline_state later on, but it raises an "invalid read" error using
valgrind with the current code. It is surprising that didn't cause any
problem.
Fixes: f2236065b7 ("v3dv: port dynamic state tracking to use Mesa Vulkan")
Cc: mesa-stable
Reviewed-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Reviewed-by: Jose Maria Casanova Crespo <jmcasanova@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29603>
Vcn4 tile number calculation doesn't consider
some input case, which could result in output
bitstream corruption, this fixed the issue.
Not using the number_of_tiles directly but from
calculation. Also change to re-use some macros
from local vcn_5_0.c to ac_vcn_enc.h header file.
Updated vcn4 spec_misc_av1 ip package.
Reviewed-by: Boyuan Zhang <Boyuan.Zhang@amd.com>
Signed-off-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29556>
Android is almost never compiled at the same time as another platform so
it doesn't change anything, but having that android branch is desirable
by the end of this series anyway, so let's do this :P
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29459>
The GL_HALF_FLOAT_OES-enum is about OES_texture_float, not e.g
ARB_texture_float. EXT_texture_rg does have an interaction that allows
this, but the other specs doesn't.
So let's tighten this. In reality, this shouldn't change any real
behavior, because we only support OES_texture_float in GLES contexts,
and in those we'd support EXT_texture_rg if we support RG textures in
the first place. But it makes the logic a bit clearer.
And just to be clear, the non-GLES version of the half-float enum does
not need the same check, because desktop GL supports all converions
here, and GLES 3 and later also requires RG-texture support in the first
place.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29528>
Checking if the format and type enums are valid while checking that the
combinations are valid makes the code hard to modify when there's
complex conditions at play. Let's factor these checks out so we can
stricten up this code in a more maintainable way.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29528>
Since we now use the common vulkan runtime to handle pipeline state and
this sets a limit for this at MESA_VK_MAX_VERTEX_BINDING_STRIDE we should
do the same, or else we can run into an assert-fail in the runtime code.
Basically the same as !29454, but for Panfrost.
Fixes: 214761bdfe ("panvk: Fully transition to vk_vertex_binding_state")
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29461>
In the case of buffer to image stores, we work around the limitation
for linear images by loading D/S data into a the color tile buffer
using a compatible format, however, this only works for formats with
a single aspect, for combined depth/stencil formats, since the copies
are specified to only copy a single aspect, we need to be able to
preserve the contents of the other aspect in the destination image,
and for that we still use the depth/stencil buffer, so we are affected
by the restriction.
Fixes some VK_KHR_maintenance5 CTS tests that hit this scenario,
such as some tests in:
dEQP-VK.api.copy_and_blit.core.image_to_image.all_formats.depth_stencil.2d_to_1d.*
In the case of image to image copies, we don't have any workarounds for
linear depth/stencil so we always want to skip the TLB path. I have not
seen any tests hit this scenario.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29597>
Backend only recognizes the MUL a*0.5 pattern if there is an immediate
as one of the sources, however by then the source would we already
coverted to RC_FILE_NONE with constant half swizzles. So teach
peephole_omod to recognize this pattern as well.
RV530:
total instructions in shared programs: 128860 -> 128750 (-0.09%)
instructions in affected programs: 11942 -> 11832 (-0.92%)
helped: 106
HURT: 17
total presub in shared programs: 8739 -> 8736 (-0.03%)
presub in affected programs: 32 -> 29 (-9.38%)
helped: 3
HURT: 0
total omod in shared programs: 427 -> 1212 (183.84%)
omod in affected programs: 38 -> 823 (2065.79%)
helped: 0
HURT: 160
total temps in shared programs: 17544 -> 17554 (0.06%)
temps in affected programs: 70 -> 80 (14.29%)
helped: 0
HURT: 10
total lits in shared programs: 3153 -> 3159 (0.19%)
lits in affected programs: 9 -> 15 (66.67%)
helped: 0
HURT: 6
total cycles in shared programs: 191334 -> 191253 (-0.04%)
cycles in affected programs: 21240 -> 21159 (-0.38%)
helped: 101
HURT: 27
Signed-off-by: Pavel Ondračka <pavel.ondracka@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28784>
Consider the following case:
0: MUL temp[1].y, input[0]._x__, input[1]._y__;
1: MOV temp[1].x, input[0].x___;
2: MOV temp[1].z, const[0].__x_;
3: MUL temp[2].xyz, const[1].xxx_, temp[1].yxz_;
...
We correctly recognize that we can convert mul into omod for all three
instructions, however the mul swizzle was not handled correctly:
0: MUL temp[2].y / 2, input[0]._x__, input[1]._y__;
1: MOV temp[2].x / 2, input[0].x___;
2: MOV temp[2].z / 2, const[0].__x_;
...
Just create the conversion swizzle from the initial mul swizzle when rewriting
the original instruction writemasks.
Signed-off-by: Pavel Ondračka <pavel.ondracka@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28784>
We add a cycles penalty when we see a begin tex and than subtract from
it based on when first alu comes that needs the results. However if the
only instruction in the TEX block is just KIL, we don't have to add any
penalty as nothing waits for it.
Signed-off-by: Pavel Ondračka <pavel.ondracka@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28784>
We were missing the following "newer" fields:
- ex_desc
- predicate_trivial
- sdepth
- rcount
- writes_accumulator
- no_dd_clear
- no_dd_check
- check_tdr
- send_is_volatile
- send_ex_desc_scratch
- send_ex_bso
- last_rt
- keep_payload_trailing_zeroes
- has_packed_lod_ai_src
We can actually just check ex_desc and the new "bits" union to handle
most of them with fewer checks.
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29624>
I want to be able to hash an fs_reg, including all the brw_reg fields.
It's easiest to do this if I can use the "bits" union field that
incorporates many of the other ones.
We also move the using declaration for "nr" down because that field was
moved to the second section a while back.
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29624>
Pass in the nir_src and check if it's constant, handling it via CPU-side
arithmetic instead of emitting instructions. While we can constant fold
these via our optimization passes, we have to do opt_algebraic to fold
the binary operation with constant sources into a MOV of an immediate,
then opt_copy_propagation to put it in the next expression, and so on,
until the entire expression is folded. This can take several iterations
of the optimization loop, which is inefficient.
For example, gfxbench5/aztec-ruins/normal/7 has load/store_scratch
intrinsics with constant sources, and this patch removes a number of
optimization passes according to INTEL_DEBUG=optimizer.
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29624>
Geometry shaders write outputs multiple times, with EmitVertex()
between them. The value of output variables becomes undefined after
calling EmitVertex(), so we don't need to preserve those. This lets
us recreate new registers after each EmitVertex(), assuming we aren't
in control flow, allowing them to have separate live ranges. It also
means that those registers are more likely to be written once, rather
than having multiple writes, which can make optimization easier.
This is pretty much a total hack, but it's helpful.
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29624>
This merges the separate MSAA, downsampling, upsampling, and non-MSAA blocks.
It's not meant to change behavior, but some change are necessary:
- disallow 16 samples
- loads only load the number of components that we need
- optimizations barriers are placed optimally and include the sample index
in the same vector as the coordinates, so that LLVM is forced to form VMEM
clauses for loads and stores
- the shader queries the descriptor for the dst image manually and passes
it to the image store instead of the image variable (this is needed to get
latency hiding for scalar loads in the presence of optimization barriers)
This is a prerequisite for blitting multiple pixels per lane.
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28917>
It had no effect on correctness and it was very inefficient because all
formats without alpha have SWIZZLE_1 in the last channel.
util_format_get_last_component is the same, but ignores PIPE_SWIZZLE_1.
It improves MSAA compute blit performance.
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28917>
Fastboot devices need an indirection for creating a boot image via
`mkbootimg`, so we need to propagate the cmdline from LAVA and our extra
arguments to it properly.
This commit fixes it by retrieving the default cmdline from LAVA and
sending it, together with the `extra_nfsroot_args` to the `mkbootimg`
command.
Signed-off-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29611>
7278 is the chip on the rpi3, while the rpi4 that made it to market has
the 2711 chip.
When this was introduced (82bf1979), the rpi4 was probably still in
flux, which is why the rpi3 chip was put there (and v3d doesn't care
about that, but v3dv does).
cc: mesa-stable
Reviewed-by: Juan A. Suarez <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29584>
Fuchsia is a microkernel-like OS. It strategically implements
some POSIX and Unix APIs to promote software re-use.
It considers itself POSIX lite.
"In order to reduce the amount of source modification needed to
run on Fuchsia, Fuchsia offers a POSIX compatibility layer, POSIX
Lite, that this software can target. POSIX Lite is layered on
top of the underlying Fuchsia System ABI as a client library.
However, POSIX Lite is not a complete implementation of POSIX."
In the case of Fuchsia + src/util, these heavy-weight POSIX
functions shouldn't be used:
- file descriptors
- syslog.h
- signals
- process creation
To differentiate POSIX Lite, which Fuchsia and all heavy-weight
POSIX implementations support, add DETECT_OS_POSIX_LITE.
The use case is incrementally upstreaming functionality used in
downstream drivers (lavapipe, ..). Being in-tree for obvious
patches helps until the full driver can be merged.
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Eric Engestrom <eric@igalia.com>
Acked-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29539>
This register stores the depth format of the underlying depth
buffer, it seemingly doesn't change anything about the LRZ buffer
itself and has no behavioral changes over setting it to 0.
However, it's possible that there's some case where it does matter
so matching the proprietary driver's behavior is safer.
Signed-off-by: Mark Collins <mark@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29453>
This tests usually takes around 15 seconds on CI, according to logs. It
recently timed out under load, causing a job to fail spuriously.
Let's bump the timeout here to 60. That's in line with the glsl compiler
warnings test, which usually takes around the same time.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29547>
Prevents the next patch from causing the following assert failure:
Test case 'dEQP-VK.ycbcr.copy.g8_b8_r8_3plane_420_unorm.g8_b8_r8_3plane_444_unorm.linear_linear_disjoint'..
deqp-vk: ../../src/intel/vulkan/anv_private.h:4962: anv_aspect_to_plane: Assertion `!(aspect & ~all_aspects)' failed.
We still disable CCS for multiplane formats elsewhere. I've attempted
enabling CCS for those cases but end up with failures in CI that I
cannot reproduce locally. Hopefully this change gets the next person a
step closer towards enabling this feature.
Reviewed-by: Rohan Garg <rohan.garg@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29094>
In the import paths in iris, there are several cases where surface VMAs
are created without relying on the calculated surface alignment.
Asserting the alignments of surface addresses, should help catch any
cases where we end up with the wrong alignment.
This found a couple issues during development. One which required a
change to existing code is that when creating uncompressed surfaces from
compressed ones, ISL will sometimes increase the image alignment as a
result of the new format supporting CCS. This patch adds the usage flag
to disable that behavior.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29094>
Add and use two new surf usage bits:
* ISL_SURF_USAGE_MULTI_ENGINE_SEQ_BIT: the surface may be accessed by
multiple engines, but not in parallel.
* ISL_SURF_USAGE_MULTI_ENGINE_PAR_BIT: the surface may be accessed by
multiple engines in parallel.
Both usages are not concerned with read-after-read access patterns.
Using these bits allows ISL to conditionally use Tile64 or a 64KB
alignment to account for the gfx12.5 CCS WA from HSD 22015614752. Apart
from the potential space savings, there are three benefits of this
approach:
1) CCS can now be used with miptails (though nothing makes use of this
today).
2) CCS can now be used with 3D depth/stencil surfaces in GL.
3) CCS can now be used with 3D depth/stencil surfaces in Vulkan when
apps only use a single queue.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/11111
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/11117
Tested-by: Mark Janes <markjanes@swizzler.org>
Reviewed-by: Rohan Garg <rohan.garg@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29094>
In iris, use the CCS scale down factor to calculate the impact of CCS on
TBIMR tile sizes. Even though we fall back to a seemingly less accurate
method to calculate the impact of CCS, it ends up giving the same
answer, 1bpp. Anv already uses this factor, so this patch replaces the
constant with this macro.
There are two benefits to doing this:
1) Consistency between anv and iris.
2) Preparation for a future where we no longer use ISL surfaces to
describe CCS on Xe+. In fact, in iris, we already don't create such
surfaces on ACM.
I considered using INTEL_AUX_MAP_MAIN_SIZE_SCALEDOWN for the calculation
in both drivers, but the naming is aux-map specific and the scaledown
actually exists on flat-ccs platforms as well.
So, we introduce a new macro for all Xe platforms, currently only used
for the specific use case of TBIMR calculations. We can add more such
macros for future platforms, as needed.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Rohan Garg <rohan.garg@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28942>
Introduce a macro defining the alignment which aux data start addresses
should have. This alignment is for the worst case of the CCS buffer
being included in a dmabuf. Although a smaller alignment is possible for
non-dmabuf cases on TGL, no drivers would make use of that today as they
place CCS surfaces directly after tiled surfaces.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28942>
Before this patch, we special-cased the clear color plane for layout
queries. This was because that plane lacks an ISL surface whereas all
others have one. We plan to drop the ISL surface for CCS buffers on
gfx12 in a future commit. So, in preparation, generalize the clear color
plane code to work for every plane queried on a surface that uses
modifiers.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Rohan Garg <rohan.garg@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28942>
At the interfaces which query the pitch of the clear color plane in GL
and Vulkan, we've been returning 64B for various reasons. Unify the
rationale under a macro.
The documentation for the macro is picked from anv, which reflects the
most recently synchronized copy of drm_fourcc.h. See the notable changes
at 8cd8f3d697.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28942>
Our implementation is a no-op for the following reasons :
- ISL always tries to go for the smallest tiling mode (see
isl_surf_choose_tiling())
- In the few cases where we need to use Tile64 for compression
workarounds, VK_MESA_image_alignment_control doesn't require use
to disable compression
- vkd3d-proton has the ability to disable compression using
VK_EXT_image_compression_control, disabling Tile64 requirements
and ensuring ISL can select a 4k tiling mode
So vkd3d-proton should always be able to get a 4k tiling mode if it
wants to.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Rohan Garg <rohan.garg@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29175>
This patch is to avoid the high overhead that exists when trying to
kick ever single draw during multidraw.
glMultiDrawArrays performance profiling:
342.5 thousand draws/second -> 40 million draws/second
Special thanks to Arthur Huillet for helping getting this profiled
in irc.
Signed-off-by: Yusuf Khan <yusisamerican@gmail.com>
Reviewed-by: Karol Herbst <kherbst@redhat.com>
---
v2: fix typos pointed out by Arthur
v3: nvc0_draw_vbo -> nvc0_draw_single_vbo, intialize count
v4: remove num_draws from wrapped function and add mutex assert
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28641>
On newer hardware, the hi operation reads the lo half of the inline constant.
On older hardware, it reads the hi half (zero).
I tested this on Navi31 for gfx11 and Raphael for gfx10.
Foz-DB Navi31:
Totals from 4 (0.01% of 79395) affected shaders:
CodeSize: 36832 -> 36448 (-1.04%)
Latency: 20362 -> 20334 (-0.14%)
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29512>
Indeed, the access to the array is done with a 4x multiplier.
The size of the array should be calculated accordingly.
For instance, this issue is triggered on radeonsi with
"piglit/bin/arb_direct_state_access-gettextureimage-formats -auto -fbo":
==3419==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffc31f804b0 at pc 0x7fac7ef81b2d bp 0x7ffc31f803d0 sp 0x7ffc31f803c8
WRITE of size 1 at 0x7ffc31f804b0 thread T0
#0 0x7fac7ef81b2c in do_span_rgba_unorm8 ../src/mesa/main/mipmap.c:160
#1 0x7fac7ef83549 in do_row ../src/mesa/main/mipmap.c:258
#2 0x7fac7ef83986 in make_2d_mipmap ../src/mesa/main/mipmap.c:371
#3 0x7fac7ef8670b in generate_mipmap_compressed ../src/mesa/main/mipmap.c:1062
#4 0x7fac7ef8670b in _mesa_generate_mipmap ../src/mesa/main/mipmap.c:1119
#5 0x7fac7e5472aa in check_gen_mipmap ../src/mesa/main/teximage.c:2910
#6 0x7fac7e5472aa in check_gen_mipmap ../src/mesa/main/teximage.c:2904
#7 0x7fac7e5472aa in teximage ../src/mesa/main/teximage.c:3315
#8 0x7fac7e5472aa in teximage_err ../src/mesa/main/teximage.c:3342
#9 0x7fac7e550cfa in _mesa_TexImage2D ../src/mesa/main/teximage.c:3413
Address 0x7ffc31f804b0 is located in stack of thread T0 at offset 96 in frame
#0 0x7fac7ef814ff in do_span_rgba_unorm8 ../src/mesa/main/mipmap.c:132
This frame has 3 object(s):
[32, 96) 'result' (line 145) <== Memory access at offset 96 overflows this variable
[128, 384) 'rowA' (line 144)
[448, 704) 'rowB' (line 144)
Fixes: dd8fb7139d ("mesa/main: rewrite mipmap generation code")
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29572>
It was set to "always run" for amd common files changes when I obviously
meant for it to be manual and messed up my copy/paste when I wrote that.
Fixes: ebaede788e ("amd/ci: limit radv jobs to radv + aco files changes")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29550>
If the cache is disabled then we need to destroy the pipelines
manually when they are no longer needed. Do that by adding them
as private objects to the command buffer.
Fixes: 4f26303dbb ('v3dv: add debug option to disable custom pipeline caches for meta operations')
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29544>
Since a42a5bf87e, we've been closing the file descriptor immediately
after loading the devinfo struct.
intel_get_and_print_hwconfig_table() re-queries the hwconfig info from
the device to print out all the entries, so we need to leave the fd
open for this use. I moved the close() call to all paths which exit
the for loop's current iteration.
Ref: a42a5bf87e ("intel/devinfo: add an option to pick platform to print")
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Sagar Ghuge <sagar.ghuge@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29549>
I incorrectly assumed the API side defines how those values are sized, but
it's actually the GPU's pointer size. The API is simply reduced to 32 bit
ranges in 32 bit mode, but has to still pass in 64 bit values to the GPU.
Also use explicit types in a couple of places to prevent such mistakes in
the future.
Fixes: 204c287327 ("rusticl/kernel: properly handle grid and offsets being usize")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29527>
Right now we have some HW-dependant constants that we are accessing
using the same mechanism that some hw-dependant functions, through a
macro (V3DV_X macro).
But this means that each time that we need to get those constant
values, we need to do a hw version check. Also, right now both the
macro and the defines with each HW value are duplicated on v3d and
v3dv. Also that macro is ugly and has a ugly name.
This commit moves those values to the already common v3d_device_info
structure.
Reviewed-by: Jose Maria Casanova Crespo <jmcasanova@igalia.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29535>
For extensions in the official CL headers this isn't all that important as
those are quite stable, but once we implement ext extensions it's better
to catch changes at compile time.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29526>
Static analyzer is complaning that tex_src could be not initialized
and then used, this should not happen as an instruction with type of
'tex' type needs to have source a texture handle.
But to make static analyzer happy here just initializing it to zero.
Reviewed-by: Sagar Ghuge <sagar.ghuge@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29530>
Since VkQueryPipelineStatisticFlagBits is extended by two bits for
task/mesh shader invocations, ANV_PIPELINE_STATISTICS_MASK should be
defined conditionally based on GFX_VER.
This commit modifies the mask and updates the vk_pipeline_stat_to_reg
array accordingly.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29523>
This was added in 6e0089307e without a
dependency on libdrm_nouveau. If libdrm is not compiled with nouveau
enabled, the build errors here.
This is currently unused and since
821f4c8d99 removed dependency on
libdrm_nouveau, this should be gone too.
Fixes: 821f4c8d99 ("nouveau: import libdrm_nouveau")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29517>
Iris calls iris_resource_get_param with PIPE_RESOURCE_PARAM_STRIDE
internally now when exporting memory objects. OpenCL's gl_sharing allows
to export buffers as well, which do not have strides.
This fixes the assert being hit there for buffers.
Fixes: 831703157e ("iris: Use resource_get_param in resource_get_handle")
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29501>
In 2c65d90bc8 I forgot to add the new SHADER_OPCODE_READ_MASK_REG
opcode to the list of barrier instruction in the scheduler. Let's just
use a single opcode for all ARF registers that need special
scoreboarding and put the register as source (nicer for the debug
output).
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: 2c65d90bc8 ("intel/brw: ensure find_live_channel don't access arch register without sync")
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29446>
v2: Add some comments explaining some of the nuance of the shift
optimizations. Fix a bug in the shift count calculation of the upper
32-bits. Move the @64 from the variable to the opcode. All suggested
by Jordan.
No shader-db changes on any Intel platform.
fossil-db:
Meteor Lake and DG2 had similar results. (Meteor Lake shown)
Totals:
Instrs: 154507026 -> 154506576 (-0.00%)
Cycle count: 17436298868 -> 17436295016 (-0.00%)
Max live registers: 32635309 -> 32635297 (-0.00%)
Totals from 42 (0.01% of 632575) affected shaders:
Instrs: 5616 -> 5166 (-8.01%)
Cycle count: 133680 -> 129828 (-2.88%)
Max live registers: 1158 -> 1146 (-1.04%)
No fossil-db changes on any other Intel platform.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29148>
I noticed some shaders with patterns similar to these while working on
cooperative matrix lowering.
Meteor Lake and DG2 are the only platforms that support iadd3, so there
were no shader-db or fossil-db changes on any other platforms.
shader-db:
Meteor Lake and DG2 had similar results. (Meteor Lake shown)
total instructions in shared programs: 19869445 -> 19868343 (<.01%)
instructions in affected programs: 419426 -> 418324 (-0.26%)
helped: 913 / HURT: 2
total cycles in shared programs: 936010029 -> 935909811 (-0.01%)
cycles in affected programs: 31746523 -> 31646305 (-0.32%)
helped: 495 / HURT: 356
LOST: 10
GAINED: 12
fossil-db:
Meteor Lake and DG2 had similar results. (Meteor Lake shown)
Totals:
Instrs: 154514596 -> 154505466 (-0.01%); split: -0.01%, +0.00%
Cycle count: 17540226067 -> 17436266198 (-0.59%); split: -0.63%, +0.04%
Spill count: 146887 -> 146886 (-0.00%)
Fill count: 272499 -> 272489 (-0.00%); split: -0.01%, +0.00%
Max live registers: 32634290 -> 32634739 (+0.00%); split: -0.00%, +0.00%
Max dispatch width: 5550128 -> 5550368 (+0.00%)
Totals from 4401 (0.70% of 632560) affected shaders:
Instrs: 3095239 -> 3086109 (-0.29%); split: -0.30%, +0.00%
Cycle count: 7327352564 -> 7223392695 (-1.42%); split: -1.51%, +0.10%
Spill count: 28105 -> 28104 (-0.00%)
Fill count: 45830 -> 45820 (-0.02%); split: -0.04%, +0.02%
Max live registers: 264376 -> 264825 (+0.17%); split: -0.05%, +0.22%
Max dispatch width: 43768 -> 44008 (+0.55%)
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29148>
This allows us to not generate 64-bit iadd3 on Intel but continue
generating it for NVIDIA.
No shader-db or fossil-db changes.
v2: Add nir_lower_iadd3_64 flag so we can continue to generate 64-bit
iadd3 on NVIDIA platforms.
v3: s/bit_size == 64/s == 64/. This cut-and-paste bug prevented any of
the optimizations from ever occuring.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29148>
The size parameter can only take certain values. Make this visible to
the compiler to encourage it to inline the memcpy.
This improves descriptor_16combined_sampler from vkoverhead
considerably.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27191>
Macro values that define values for different HW generations should
use the V3DV_X helper instead of being defined under a V3D_VERSION #if
condition.
Without this change, the original V3D_CLE_READAHEAD and
V3D_CLE_BUFFER_MIN_SIZE definitions used were only working for 4.2 HW.
For the 7.1 HW (RPi5) the 4.2 definitions were applied.
The CLE MMU errors were hidden as they were reported at dmesg as
"MMU error from client PTB (1) at 0x1884200, pte invalid" instead of
client CLE. So fixes all v3d dmesg warnings for PTB MMU errors on RPi5.
With this change we really don't need different functions per HW generation,
so we rename back file v3dx_cl.c to v3d_cl.c. As before, we can use
only the packets definitions for 4.2 HW as they use the same opcode as 7.1 HW.
Fixes: 11dce2ac81 ("v3d: fix CLE MMU errors avoiding using last bytes of CL BOs.")
Fixes: e2c624e74e ("v3d: Increase alignment to 16k on CL BO on RPi5")
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29496>
Macro values that define values for different HW generations should
use the V3DV_X helper instead of being defined under a V3D_VERSION #if
condition.
Without this change, the original V3D_CLE_READAHEAD and
V3D_CLE_BUFFER_MIN_SIZE definitions used were only working for 4.2 HW.
For the 7.1 HW (RPi5) the 4.2 definitions were applied.
The CLE MMU errors were hidden as they were reported at dmesg as
"MMU error from client PTB (1) at 0x1884200, pte invalid" instead of
client CLE. So fixes all v3dv dmesg warnings for PTB MMU errors on RPi5.
With this change we really don't need different functions per HW generation,
so we rename back file v3dvx_cl.c to v3dv_cl.c. As before, we can use
only the packets definitions for 4.2 HW as they use the same opcode as 7.1 HW.
It fixes also an indentation error introduced with 26c8a5cd72.
Fixes: bb77ac983e ("v3dv: Increase alignment to 16k on CL BO on RPi5")
Fixes: 26c8a5cd72 ("v3dv: fix CLE MMU errors avoiding using last bytes of CL BOs.")
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29496>
Gfx11-12 can support SLM block loads via OWord Block Load messages
(notably, the aligned version, not the unaligned version).
A while back we deleted the SHADER_OPCODE_OWORD_BLOCK_READ opcode.
Rather than bring it back, we continue using UNALIGNED_OWORD_BLOCK_READ
for SLM block access (like we do for SSBOs) but switch it over to the
aligned variant when lowering logical sends. We do ensure the alignment
is at least 16B, however. This is ugly, but it's probably not worth
bringing back a whole extra opcode for a legacy HDC block load quirk.
References: BSpec 47652 and 1689
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/9960
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29429>
With AHB + external format, we might get VK_FORMAT_UNDEFINED. And at
least with skiavk we might not get a chained VkExternalFormatANDROID.
In this case, just take the format from the image, which will have
already been resolved via VkExternalFormatANDROID when the image was
created.
See VUID-VkImageViewCreateInfo-image-02399
Also see commit 4f7de83110 ("venus: fix view format for ahb image")
for a similar fix.
Fixes the following cts tests:
CtsViewTestCases:
- android.view.cts.PixelCopyTest#testVideoProducer
CtsMediaDecoderTestCases:
- android.media.decoder.cts.DecodeAccuracyTest#testSurfaceViewLargerWidthDecodeAccuracy[50(c2.v4l2.avc.decoder_h264_520x360)]
- android.media.decoder.cts.DecodeAccuracyTest#testSurfaceViewLargerWidthDecodeAccuracy[50(c2.v4l2.avc.decoder_h264_520x360)]
CtsCameraTestCases:
- android.hardware.camera2.cts.MultiViewTest#testTextureImageWriterReaderOperation[1]
Signed-off-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29490>
This small patch fixes an issue where 'addr' is used uninitialized if
the assert gets removed due to compiling release code and thus
returning uninitialized 'addr'
v2: Modified based on initial review:
a) No need to initialize the 'addr' and 'ret' variables
b) Fix 'ret' variable to be proper type based on hw->get_mem return value
v3: Modified based on additional review:
a) Since both the simulator and mesa have their own version of
'unreachable()' and we cannot use ASSERT for the 'ret' value here,
just use a (void) ret after the assert
Reviewed-by: Eric Engestrom <eric@igalia.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Reviewed-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29434>
Have logic to handle tile allocation
according to vcn5's capability, if the
tile allocation is out of the limit, will
re-adjust the tile parameters.
re-construct frame header and obu instruction
logic. And add av1 encode params requried
for vcn5.
Acked-by: Leo Liu <leo.liu@amd.com>
Signed-off-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29423>
Up to now preferred SLM size was being set to maximum preferred SLM
size for GFX 12.5 platforms and to workgroup SLM size for Xe2 but
neither of those values are the optimal.
The optimal value is:
<number of workgroups that can run per subslice> * <workgroup SLM size>
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/28910>
Xe2 has 2 requirements for preferred SLM size:
- this value needs to be >= then SLM size
- this value must be less than shared SLM/L1$ RAM in the sub-slice of platform
Also Xe2 don't have the special '0' encode that sets preferred SLM
allocation size to the maximum supported.
So here setting a value that is equal or larger than SLM size.
It was always setting SLM_ENCODES_128K for LNL A0 stepping probably
because of Wa_16018610683 but this restriction applies to all Xe2
platforms, also because of the first restriction mentioned here
this workaround is not being properly implemented, will fix that
in the next patch.
We should have a formula to calculate a preferred SLM allocation size
for gfx125 and Xe2 platfoms but until that this is enough to fix at
least the applications and tests below on LNL:
- GFXBench Aztec Ruins VK
- GravityMark VK
- Wildlife Extreme VK
- 5 crucible tests
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/28910>
This functions were inlined in a header and duplicated between brw and
elk.
That would be enough reasons to move to a C file but next patches
will add more code to support Xe2 platforms, what would cause more
code to be inlined, duplicating even more code and increasing lib
size.
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/28910>
The SamplerDescriptor structure has a field which describes how
floating point coordinates should be converted to fixed point.
Setting this to "true" (which causes round to nearest even) fixes
a failing CTS test.
The CTS test in question is:
dEQP-GLES31.functional.texture.border_clamp.range_clamp.linear_float_color
The OpenGL spec is somewhat vague about how rounding is to be
performed, so it appears both settings should be legal; this may
indicate a problem with the CTS. Nevertheless "round to nearest even"
is probably a better default and since it fixes the failing test we
may as well use it.
Cc: mesa-stable
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29464>
We ran into an issue with Intel drivers where it became tricky to tell
whether a timestamp must be recorded with a special end-of-pipe
compute instruction or something else.
We initially tried to deal with that internally by checking some state
in the command buffers but turns out it doesn't work.
This change adds a flag field to the tracepoint to have that
information there and the flags are passed to the record_ts vfunc.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29438>
Currently for an "unavailable" query, if VK_QUERY_RESULT_PARTIAL_BIT is
set, anv will return (slot.end - slot.begin). This can cause underflow
because slot.end might still be at the initial value of 0.
This commit fixes the issue by returning 0 in that situation.
Cc: mesa-stable
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29447>
When running .gitlab-ci/container/debian/android_build.sh using the
cross files created by .gitlab-ci/container/create-android-cross-file.sh
meson prints out the following warning:
-----------------------------------------------------------------------
DEPRECATION: "pkgconfig" entry is deprecated and should be replaced by "pkg-config"
-----------------------------------------------------------------------
Use the suggested name `pkg-config` in the cross files to silence the
warning.
Apply the same change also to the example meson cross file in
docs/android.rst
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29431>
Since we now use the common vulkan runtime to handle pipeline state and
this sets a limit for this at MESA_VK_MAX_VERTEX_BINDING_STRIDE we should
do the same, or else we can run into an assert-fail in the runtime code.
Fixes:
dEQP-VK.pipeline.monolithic.bind_buffers_2.maintenance5.triangle_list.buffers5.stride_offset_rnd321.whole_size
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29454>
We were exposing them as zero, as based on just the name, we assumed
that it was about the descriptors using the
VK_DESCRIPTOR_SET_LAYOUT_CREATE_UPDATE_AFTER_BIND_POOL_BIT bit.
But from spec, that limit takes into account descriptors created *with
or without*, so for example:
"maxPerStageDescriptorUpdateAfterBindUniformBuffers is similar to
maxPerStageDescriptorUniformBuffers but counts descriptors from
descriptor sets created with or without the
VK_DESCRIPTOR_SET_LAYOUT_CREATE_UPDATE_AFTER_BIND_POOL_BIT bit
set."
As we don't support the feature, those limits are the same of the
existing without the DescriptorUpdateAfterBind.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29430>
We were multiplying it by 6, that is the number of possible shader
stages, but from spec it points that we need to multiply by the number
of supported shader stages.
From Vulkan 1.3 spec, chapter 33, "Limits", note 8 on Table 33
"Required Limits":
"The minimum maxDescriptorSet* limit is n times the corresponding
specification minimum maxPerStageDescriptor* limit, where n is the
number of shader stages supported by the VkPhysicalDevice. If all
shader stages are supported, n = 6 (vertex, tessellation control,
tessellation evaluation, geometry, fragment, compute)."
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29430>
This is added with VK_KHR_maintenance5 to allow 64-bit
for pipeline creation flags.
The flags are backwards compatible so we don't need to
change the flag enum values by the new ones.
This patch also addresses a small issue where compute pipelines
where not initializing the flags field in the pipeline object.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29449>
This used to depend on both _mesa_get_shader_image_format() and
_mesa_uncompressed_format_to_type_and_comps() doing a specific mapping
to behave like the spec requires. But only a small subset of what the
latter function does is needed, and that function is used for other
purposes where the needs are dictated by other means.
It's going to be easier to maintain this code if we use different
implementations for these two things.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29386>
In order to build grl, we need to get the device_info struct from the
PCI ID, but for pre-production platforms we don't want to enable them
unless INTEL_FORCE_PROBE is set.
Setting it when running intel_clc allows us to get the device_info
struct when the pre-production hardware is not ready to be enabled by
default.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29273>
The queueFlags of the associated queue may have more flags than just the
type of queue it is, based on what that queue supports, like sparse or
protected content. Check that the queue is a blitter engine instead.
Fixes a bunch of dEQP-VK.api.copy_and_blit.core.*_transfer on MTL with
ANV_SPARSE=0
Fixes: 17b8b2cffd ("anv: Add support for a transfer queue on Alchemist")
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/29336>
The old mipmap generation code has a few problems:
1. It open-codes the format conversion, which is error prone, and it's
hard to know if we're missing some formats. Manual inspection shows
that we're indeed missing some less commonly used formats.
2. When downsampling between two miplevels with the same width (e.g a
width of one), the code would read from outside the image.
3. It averages sRGB textures in gamma space. Whilte that's legal in GL
(the filtering algorithm is undefined), it doesn't produce very good
results. And it's not the same thing as util_gen_mipmap() does.
4. Similarly, it uses a box-filter for the stencil values. And while
that's actually what the spec recomments (regardless of format), it's
absolutely *not* what most applications would want. Using nearest
sampling would make more sense.
5. It has requirements about the type and format returned by
_mesa_uncompressed_format_to_type_and_comps() which other call-sites
in mesa doesn't have. This is the real reason I want to get rid of
it, because it ends up complicating the GLES read formats / types.
So, let's rewrite all of this, fixing all of the above. The result is
quite a bit shorter, and if this ends up being less performant, it's
unlikely that this matters, because we almost always use the GPU
accelerated code-path provided by util_gen_mipmap() anyway.
The new code works by a few identities: It uses the pack / unpack
helpers to convert the texture to a few reasonable intermediate formats,
so we keep the amount of open-coded averaging to a minimum. To do this
without heap-allocations, we introduce a concept of a "span", which has
a max fixed size, that can trivially be allocated on the stack.
We also add some more requirements to keep things sane; the higher level
do_row functions only allow the dest image to be half of the source
width or one (whichever is larger). This matches the high-level needs of
mipmap generation. The lower level do_span() function is a bit more
flexible, because that turns out to be helpful when implementing
do_span_3D(), where we want to avoid collapsing the inner dimension
twice.
Tested-by: Eric R. Smith <eric.smith@collabora.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29380>
The code for checking flow control did not realize that
`LD_TEX` and `LD_TEX_IMM` were memory accesses, and hence was
not inserting waits where these were necessary. This showed up
as flakes in KHR-GLES31.core.shader_image_load_store.basic-glsl-misc-fs
Cc: mesa-stable
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29363>
LLVMContextr is not thread safe. There are many code paths that use
llvmpipe_context::context and adding locking to all of them is
difficult and adds unnecessary overhead. This approach restricts locking
to lp_sampler_matrix, which makes covering all uses of the LLVMContext
easy and only adds overhead when running lavapipe.
Fixes: 7ebf7f4 ("llvmpipe: Compile sample functioins on demand")
Reviewed-by: Roland Scheidegger <roland.scheidegger@broadcom.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29397>
Before VK_KHR_maintenance5 point size is undefined unless the
shader explicitly writes it, but this extension changes this and
expects a default point size of 1.0 if none has been written.
We accomplish this by emitting a POINT_SIZE packet with the
default point size the first time we draw with a POINT primitive
in the job. If the shaders used in the draw call doesn't write
point size then the hardware will take the point size from the
state set by the packet. If the shader does write to point size
then the value written in the shader will be used instead.
Passes all tests we support in:
dEQP-VK.rasterization.primitive_size.default_size.points.*
when forcing maintenance5 enabled.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29413>
If the shader writes point size, then the compiler needs to ensure it
writes it in the appropriate vpm output slot and also clamp its value to
expected limits. This is why we have the per_vertex_point_size in the
shader key, so it doesn't really make sense to set this if the shader
doesn't write point size.
If the shader record flags that the shader writes point size then the
hardware will use the shader written value to override point size state
(set with the POINT_SIZE packet), so again, we really only want to set
this in the shader state record if the shader actually writes its value.
While we could also limit this to point primitives, since these are the
only primitives where point size has an effect, this is not really
required, and skipping this allows us to use the same shader with any
primitive type (otherwise we would have to compile 2 different shaders).
Finally, this change makes the vertex shader setup for point size match the
one we had been doing for geometry shaders, so it makes both stages behave
consistently regarding point size behavior.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29413>
read_oa_samples_until() was returning OA_READ_STATUS_ERROR even
if already read samples, then it tried again and KMD returned 0/empty
or EAGAIN(as the read would block).
This is not causing any issue because read_oa_samples_for_query()
FALLTHROUGH OA_READ_STATUS_ERROR to OA_READ_STATUS_FINISHED
but that I think it is worthy to fix it.
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/29421>
The copy from old buffer is only needed when appending (when
decode_bitstream is called more than once in one frame).
This avoids map old buffer -> memcpy to new buffer which can get
expensive with large buffers.
Reviewed-by: David (Ming Qiang) Wu <David.Wu3@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29318>
Only mapper4 supports u_gralloc_get_buffer_color_info(), other gralloc
implementations do not. So add a fallback, so that we aren't telling
the app that the suggestedYcbcrModel is RGB_IDENTITY. We only go down
this path for YUV formats.
Fixes android.graphics.cts.BasicVulkanGpuTest#testBasicBufferImportAndRenderingExternalFormat
Fixes: 8732a619f1 ("vulkan/android: Add common vkGetAndroidHardwareBufferPropertiesANDROID")
Signed-off-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Roman Stratiienko <r.stratiienko@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29391>
This instruction is so restricted that encode_alu() really isn't gaining
us much so we may as well just type it out. Also, the bindless version
is quite a bit different and doesn't follow the ALU patterns so it'll
make more sense to do it this way long-term.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29393>
Adding with +0 is technically fine because the other source has abs()
applied and a non-negative value added to +0 is a no-op. However, copy
propagation won't detect that properly as of a43e6addca ("nak: Fix
fneg to do fadd(-0, x)")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29393>
In the sort functions used to sort varyings in gl_nir_link_varyings,
we were only checking the first input for whether or not it is xfb.
Check both inputs, and also provide a definite order for the xfb vs.
non-xfb varyings (the xfb come last, as the initial sort established).
This fixes a problem encountered on panfrost, where qsort could
mix xfb and non-xfb varyings which started out separate.
Note that the sort is still not stable. We probably should make it
stable, but that is a more extensive change that's handled in a later
commit.
Cc: mesa-stable
Signed-off-by: Eric R. Smith <eric.smith@collabora.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29178>
We can emit spill setup before RA if we use scratch. In that case
we have the same situation as during spilling, with the caveat that
we have already emitted the instructions so we need to find them
(they should be the only instructions ones before the instructions
accessing payload registers) and flag them as such.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29343>
We read our payload registers first in the shader so we generally don't have
to care about temps being allocated to them and stomping their value before
we can read them. Hoewer, spilling setup instructions are an exception since
these will be inserted first when there is any spilling in the program.
To fix this, we flag RA nodes involved with these instructions so we can
then try to avoid assiging these registers to them.
Fixes CTS failures with V3D_DEBUG=opt_compile_time, particularly:
dEQP-VK.binding_model.buffer_device_address.set0.depth2.basessbo.convertcheckuv2.nostore.single.std140.comp_offset_nonzero
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29343>
This exists due to historical limitations which have long gone obsolete.
This persists longer due to hostorical perf issues that have recently
gone obsolete on the platforms shipping Venus. Meanwhile, clients like
skiavk and ANGLE nowadays do a better job managing suballocations. The
tiny perf win from having this giant internal pool has been beaten by
the memory waste, longer one-shot jank due to largier alloc, allocations
no need to be mapped but only because host-visible is advertised across
mem types and varies workarounds and markups needed to make alignment
work and make VVL happy. Dropping it also reduces the maintenance cost.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29362>
In the case of virtio_gpu, if the drm native context capset is
supported, we should try loading the native driver before falling back
to virgl.
Previously this was done with hacks in pipe_virtio_gpu_create_screen(),
but this also requires virgl's driconf to be the superset of virgl and
all the nctx drivers.
Instead add an optional loader callback to probe for nctx support. This
is called with the drm capset, if the host supports the drm context
type, to allow driver specific code to determine if the specific GPU is
supported, so we can cleanly fall back to virgl if it does not (for ex,
an old VM guest with a newer host, where mesa in the guest does not
support the new GPU, but mesa in the host does).
TODO: How to handle the dynamic loader case?
Signed-off-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28777>
When compilation is required, we should return
VK_PIPELINE_COMPILE_REQUIRED. The spec prevents the application from
passing a module or SPIR-V code so we have nothing to compile if the
cache lookup fails :
VUID-VkPipelineShaderStageCreateInfo-stage-06844:
If a shader module identifier is specified for this stage, a
VkShaderModuleCreateInfo structure must not be present in the pNext
chain
VUID-VkPipelineShaderStageCreateInfo-stage-06848:
If a shader module identifier is specified for this stage, module
must be VK_NULL_HANDLE
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: mesa-stable
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/11208
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29340>
Dumps the value associated with each SPIR-V ID after parsing the module.
This will show the intermediate vtn_* values that spirv_to_nir uses.
Only a subset of detailed information is printed at the moment (focus on
pointers and pointer types), but it is easy to add for other value types
later.
Example output when running crucible with the debug option enabled.
```
crucible: start : func.compute.num-workgroups.basic.q0
=== SPIR-V values
1 = extension
2 = type void glsl_type=void
3 = type function
4 = function
5 = block
6 = type scalar glsl_type=uint
7 = type vector glsl_type=uvec3
8 = type array glsl_type=uvec3[]
9 = type struct glsl_type=Storage
10 = type pointer deref=9 SpvStorageClassUniform glsl_type=uvec4
11 = pointer ptr_type=10 (pointed-)type=9
12 = type scalar glsl_type=int
13 = constant type=12
14 = type pointer deref=7 SpvStorageClassInput glsl_type=uint
15 = pointer ptr_type=14 (pointed-)type=7
16 = constant type=6
17 = type pointer deref=6 SpvStorageClassInput glsl_type=uint
18 = pointer ptr_type=17 (pointed-)type=6
NIR: 32 %2 = deref_array &(*%0)[0] (system uint) // &gl_LocalInvocationID[0]
19 = ssa glsl_type=uint
20 = pointer ptr_type=14 (pointed-)type=7
21 = ssa glsl_type=uvec3
22 = type pointer deref=7 SpvStorageClassUniform glsl_type=uint
23 = pointer ptr_type=22 (pointed-)type=7
NIR: 32x4 %12 = deref_array &(*%11)[%4] (ssbo uvec3) // &((Storage *)%9)->uv3a[%4]
24 = constant type=6
25 = constant type=6
26 = constant type=7
===
crucible: pass : func.compute.num-workgroups.basic.q0
```
When the environment variable is set, this dump will also be printed
during vtn_fail and its helpers.
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29295>
The GLES spec limits the valid combinations of format and type that
may be returned by queries and/or used by ReadPixel. The list of valid
combinations appears in table 8.2 of the GLES 3.2 spec. Our code for
reporting the type and format of the current framebuffer, however,
does not verify that the combination is legal for GLES. For example,
RGBA and UNSIGNED_SHORT_1_5_5_5_REV is not a valid GLES combination,
but it's what we were returning for a panthor 16 bit frame buffer.
We can fix this either by changing the format or type that we return
(internally we can handle any format/type combination). We advertise the
read_format_bgra extension, so we could return GL_BGRA for the format.
However, very few applications (including notably the Khronos CTS for GLES)
cope well with BGRA. So instead we change the type to a non-_REV one
so that the combination appears in the GLES spec table of legal values.
Cc: mesa-stable
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29144>
The hardware doesn't prevent us from mapping random 2DArray layers
as cube/cube arrays. The only restriction we have is on the number
of layers we pass (must be a multiple of 6 for cube arrays).
This patch makes the surface emission logic cube-agnostic, and
moves the cube face -> surface index conversion logic one layer
up to simplify things.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28909>
The surface iterator here doesn't really help much. It seems much more
to the point to explicitly iterate over the surfaces in the order the HW
descriptors expects it.
This will make it easier to change how things works in the future,
especially for V9 and later. More on that in a later commit.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28909>
Adjusting the cube-dimensions to account for layers and faces does
nothing to change the number of elements, it just shifts the number
between the two.
This means we can simplify things a bit, and avoid a questionable assert
in the process.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28909>
We are skipping additional 357684 tests for the following subgroups
where all tests results are skip to reduce CI usage testing skipped
tests. It reduces the CI time execution by a 2%.
14304 dEQP-VK.binding_model.mutable_descriptor.*
22948 dEQP-VK.binding_model.shader_access.primary_cmd_buf.bind2.*
20258 dEQP-VK.binding_model.shader_access.secondary_cmd_buf.bind2.*
11662 dEQP-VK.compute.shader_object_binary.*
11662 dEQP-VK.compute.shader_object_spirv.*
196299 dEQP-VK.image.host_image_copy.*
14043 dEQP-VK.query_pool.statistics_query.*
54656 dEQP-VK.robustness.robustness2.*
11852 dEQP-VK.sparse_resources.*
We are also using alphabetical order these subgroups.
Reviewed-by: Juan A. Suarez <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29328>
As we are marking the last V3D_CLE_READAHEAD bytes as unusable we don't
need to reserve V3D_CL_MAX_INSTR_SIZE bytes for the CLE packet.
This reverts c2601f0690 ("v3dv: ensure at least V3D_CL_MAX_INSTR_SIZE
bytes in last CL instruction")
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29023>
We increase the alignment to 16k for BOs allocated for the CL on RPi5 HW.
So we have the same ratio of usable space because of HW readahead as
than on RPi4, as readahead has been increased from 256 to 1024 bytes on
RPi5.
We have also concluded that when the kernel is running with 16k pages
that is the default on Raspberry Pi 5 HW, BO allocations are aligned to
16k so this increase has no cost and we would be using memory more
efficiently.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29023>
We increase the alignment to 16k for BOs allocated for the CL on RPi5 HW.
So we have the same ratio of usable space because of HW readahead as
than on RPi4, as readahead has been increased from 256 to 1024 bytes on
RPi5.
We have also concluded that when the kernel is running with 16k pages
that is the default on Raspberry Pi 5 HW, BO allocations are aligned to
16k so this increase has no cost and we would be using memory more
efficiently.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29023>
The last V3D_CLE_READAHEAD bytes of the CLE buffer are unusable because
using them would prefetch the next readahead bytes of the CL that would
be outside the allocated BO. To guarantee that we can chain a BO to the
current CL we always reserve space for the BRANCH or
RETURN_FROM_SUB_LIST packets.
Not taking this into account has been generating kernel dmesg errors like
"MMU error from client CLE".
As V3D_CLE_READAHEAD is different from RPi4 (256 bytes) to RPi5 (1024 bytes).
So we needed to rename v3dv_cl.c to v3dvX_cl.c to have different objects per
V3D_VERSION.
Extra assertions have been included to validate that we don't write
packets over the usable size of the CL silently.
v2: - Do not declare unusable the space needed for the BRANCH packet,
but take it into account for all space reservations.
v3: - Squash here ("v3dv: Secondary CL needs also to handle CLE readahead")
- Remove spureous parenthesis (Iago Toral)
- Refactor to avoid checking for needs_return_from_sub_list inside
cl_alloc_bo adding unusable_space as new parameter.
v4: - Improved logic for chaining BOs moving it to cl_alloc_bo using
a new enum v3dv_cl_chain_type to identify the different kinds
of BO chaining. Now we increase the size of the BO just before
submitting the BRACH/RETURN_FROM_SUB_LIST packages.
v5: - Assert on BO size updates that we are within the BO size.
(Iago Toral)
v6: - Remove changes at cmd_buffer_end_render_pass_secondary as we
assumed that cl->bo was already allocated when ending the
secondary CL, but it can be NULL. And this was already handle
by current code.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29023>
The last V3D_CLE_READAHEAD bytes of the CLE buffer are unusable because
using them would prefetch the next readahead bytes of the CL that would
be outside the allocated BO. To guarantee that we can chain a BO to the
current CL we always reserve space for the BRANCH packet.
Not taking this into account has been generating kernel dmesg errors like
"MMU error from client CLE".
As V3D_CLE_READAHEAD is different from RPi4 (256 bytes) to RPi5 (1024 bytes).
So we needed to rename v3d_cl.c to v3dX_cl.c to have different objects per
V3D_VERSION.
Extra assertions have been included to validate that we don't write
packets over the usable size of the CL silently.
v2: - Remove spurious blank line (Iago Toral)
- Do not declare unusable the space needed for the BRANCH packet,
and take it into account for all reservations.
v3: - Handle BRANCH packet reserve only when CLE BO allocation is done.
v4: - Assert on BO size updates that we are within the BO size.
(Iago Toral)
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29023>
This is the final step of the dynamic graphics state transition,
making the panvk_pipeline logic a dumb layer on top of panvk_shader
whose sole responsibility is to compile+link shaders, and call some
vk_graphics_pipeline helpers to store the static state in a
vk_dynamic_graphics_state object that can be copied to the command
buffer dynamic graphics state at pipeline bind time.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Acked-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28927>
Stop passing panvk_varyings_info around and emit varying attributes
when building the pipeline. All the command buffer logic has to do is
allocate varying memory, and emit the attribute buffer descriptors
pointing to these buffers. We also keep the buffer index fixed to keep
things simple, when a buffer is missing, it will simply be filled with
a zero-sized/NULL entry.
Note that we store the buffer stride information in panvk_pipeline_shader
to prepare the transition to vk_shader.
As a bonus, this simplification seems to fix a few CTS failures.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Acked-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28927>
The multi-step compilation is not needed since we don't have clever
linking optimization tricks just yet. Let's handle compilation, shader
upload and renderer state descriptor emission in one step and make as
much as we can stage agnostic. The remaining FS-specific stuff are moved
to init_fs_state().
While at it, move as much information as we can to the
panvk_pipeline_shader object we created, to make the transition to
vk_shader easier.
We also stop using MESA_SHADER_STAGES-sized arrays everywhere, since
we only support vertex and fragment shaders.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Acked-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28927>
In order to turn on/off through SNMP DuT under PoE switch, the SNMP key
in some vendors don't directly use the interface number, but a number
shifted a base number.
Define this base number as BM_POE_BASE environment in the runner.
Reviewed-by: Jose Maria Casanova Crespo <jmcasanova@igalia.com>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29306>
Currently, the information about the performance counters is duplicated
both in the kernel and in user space. Naturally, this leads to
inconsistency, as the user space might be updated and while the kernel
isn't.
Aiming to turn the kernel as the "single source of truth", use
DRM_IOCTL_V3D_GET_COUNTER, when available, to get performance counter
information.
Signed-off-by: Maíra Canal <mcanal@igalia.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29154>
Currently, the information about the performance counters is duplicated
both in the kernel and in user space. Naturally, this leads to
inconsistency, as the user space might be updated and the kernel isn't.
Aiming to turn the kernel as the "single source of truth", use
DRM_IOCTL_V3D_GET_COUNTER, when available, to get the performance
counter information.
Signed-off-by: Maíra Canal <mcanal@igalia.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29154>
Now, the kernel has the ability to inform about the maximum number of
performance counters of a V3D device. Let's add this information to the
`struct v3d_device_info` to use it when performing performance queries.
From now on, V3D_PERFCNT_NUM must not be used to retrieve the maximum
number of performance counters. We must use `devinfo->max_perfcnt`,
except on the case that the kernel doesn't support DRM_V3D_PARAM_MAX_PERF_COUNTERS.
Signed-off-by: Maíra Canal <mcanal@igalia.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29154>
The contents were previously copied with vk_copy_struct_guts(),
now that we use vk_set_physical_device_properties_struct, the sType
is needed.
Fixes: ("3c152a6e5dd venus: Use common physical device properties")
Signed-off-by: Juston Li <justonli@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29314>
These might be necessary if continue_or_break and divergent breaks are both used:
loop {
if (divergent) {
a = loop_invariant_sgpr
break
}
discard_if
}
b = phi a
If we break because discard_if makes exec empty but only did so in
previous iterations, then the phi should use "a" from those previous
iterations.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29121>
New pass that shares code with nir_opt_load_store_vectorize but
it only updates the alignment of load/store instructions.
It is useful before running other passes which may
potentially destroy that information (eg. by removing some
instructions from which the alignment may be deduced).
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29210>
When we start writing to an XFB buffer we need to synchronize with
any batches reading from it (because the data they need is about
to be overwritten). Do this by introducing a barrier in csf_launch_xfb.
This patch fixes a valhall failure in
KHR-GLES31.core.vertex_attrib_binding.advanced-iterations
Cc: mesa-stable
Signed-off-by: Eric R. Smith <eric.smith@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29092>
So far we were using raw uint32_t for handling masks. But this has the
issue that it only allows to handle up to 32 elements; if we need to
handle more elements, the we need to upgrade to uint64_t.
And this happened inadvertently with commit 370f02bf02 ("gallium: Bump
PIPE_MAX_SHADER_IMAGES to 64"), where the number of elements to handled
were increased from 32 to 64, but we didn't upgrade the mask type.
To fix this, and avoid this happening again in the future, let's use
BITSET, which is designed to handle bitmasks, and can able to handle as
many elements as desired.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29299>
See 8af8dc97bc ("tc: do a GPU->CPU copy to initialize cpu_storage")
On zink, initializing cpu_storage that requires a GPU->CPU copy is
particularly expensive; in addition to a sync, the buffer_map call to
copy the GPU data submits a batch and has to wait for that batch.
Take the PIPE_USAGE_STREAM hint and disable using cpu_storage on
resources that "will be modified once and used at most a few times"
where the benefit of cpu_storage is outweighed by the heavy init time.
Signed-off-by: Juston Li <justonli@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29294>
This reduces the amount of manual dependency tracking developers need to
do. This is turned on if glslang >= 11.3.0 is used, or 11.9.0 on
Windows, but otherwise the status quo is maintained. This means I have
not removed any use of `depend_files`. We could make make these hard
requirements and remove the use of `depend_files` too.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28329>
emit_subpass_color_clear_rects and emit_subpass_ds_clear_rects is
receiving a v3dv_render_pass parameter pass, but then using
cmd_buffer->state.pass to access the current pass. All calls to those
methods are already initializing that parameter to that value.
This commit just uses the parameter. An alternative would be to remove
one of the parameters of the function call. I find this option
slightly more readable.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29218>
The resulting pipeline/shaders are different when we are using
multiview (for example, a geometry shader is injected in order to
support multiview).
Doesn't fix any CTS test run individually, but fixes some
dEQP-VK.draw.dynamic_rendering.primary_cmd_buff.multi_draw.overlapping*
CTS tests when run in a batch (using deqp-vk --deqp-caselist-file),
like:
dEQP-VK.draw.dynamic_rendering.primary_cmd_buff.multi_draw.mosaic.indexed_mixed.16_draws.stride_zero.10_instances.vert_only.single_view.offset_6_no_draw_id
dEQP-VK.draw.dynamic_rendering.primary_cmd_buff.multi_draw.overlapping.normal.one_draw.stride_zero.1_instance.vert_only.multiview.no_offset_no_draw_id
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29218>
The EGL_WL_create_wayland_buffer_from_image is still used in WPE WebKit.
There is work in progress to continue adoption of DMA-BUF usage inside
WebKit which will eventually render the extension unneeded; but in the
meantime an update to a version of Mesa without the extension would
render applications using WPE WebKit unusable.
This reverts commit a3418105b9.
Signed-off-by: Adrian Perez de Castro <aperez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29266>
This introduces ac_sampler_state which contains all information to
build a sampler descriptor for AMD hardware instead of duplicating
code between RADV and RadeonSI. Both drivers just need to fill this
new struct to get a descriptor.
This allows RADV to get GFX12 support for free. I think we should
introduce helpers for other type of descriptors.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29221>
meta is for making meta gallium calls, we already have something else
appropriately named meta. bg/eot programs are not meta, they're their own
hardware mechanism. use the appropiate powervr name instead.
nfc
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29247>
The original fix from
0f3370eede ("raseonsi/vcn: fix a h264 decoding issue")
would in some cases also trigger for I frames with interlaced streams.
Instead of checking used_for_reference_flags, use slice type and
only add one reference for P/B frames if needed.
This change still fixes playback of the sample from the original issue,
avoids the issue with interlaced streams and also fixes the case where
application provides no references at all.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/11060
Cc: mesa-stable
Reviewed-by: Leo Liu <leo.liu@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29055>
This change handles the case when "vertex_fetch_shader.cso" is null,
it implements the previous behavior in this specific case. This
situation is happening with clover.
For instance, this issue is triggered with "piglit/bin/cl-custom-buffer-flags":
==6467==ERROR: AddressSanitizer: SEGV on unknown address 0x00000000000c (pc 0x7ff92908fe6e bp 0x7ffe86ae5ad0 sp 0x7ffe86ae5a30 T0)
==6467==The signal is caused by a READ memory access.
==6467==Hint: address points to the zero page.
#0 0x7ff92908fe6e in evergreen_emit_vertex_buffers ../src/gallium/drivers/r600/evergreen_state.c:2123
#1 0x7ff92908444b in r600_emit_atom ../src/gallium/drivers/r600/r600_pipe.h:627
#2 0x7ff92908444b in compute_emit_cs ../src/gallium/drivers/r600/evergreen_compute.c:798
#3 0x7ff92908444b in evergreen_launch_grid ../src/gallium/drivers/r600/evergreen_compute.c:927
#4 0x7ff9349f9350 in clover::kernel::launch(clover::command_queue&, std::vector<unsigned long, std::allocator<unsigned long> > const&, std::vector<unsigned long, std::allocator<unsigned long> > const&, std::vector<unsigned long, std::allocator<unsigned long> > const&) ../src/gallium/frontends/clover/core/kernel.cpp:105
#5 0x7ff9349c331d in std::function<void (clover::event&)>::operator()(clover::event&) const /usr/include/c++/11.4.0/bits/std_function.h:590
#6 0x7ff9349c331d in clover::event::trigger() ../src/gallium/frontends/clover/core/event.cpp:54
#7 0x7ff9349c82f1 in clover::hard_event::hard_event(clover::command_queue&, unsigned int, clover::ref_vector<clover::event> const&, std::function<void (clover::event&)>) ../src/gallium/frontends/clover/core/event.cpp:138
#8 0x7ff9348daa47 in create<clover::hard_event, clover::command_queue&, int, clover::ref_vector<clover::event>&, clEnqueueNDRangeKernel(cl_command_queue, cl_kernel, cl_uint, const size_t*, const size_t*, const size_t*, cl_uint, _cl_event* const*, _cl_event**)::<lambda(clover::event&)> > ../src/gallium/frontends/clover/util/pointer.hpp:241
#9 0x7ff9348daa47 in clEnqueueNDRangeKernel ../src/gallium/frontends/clover/api/kernel.cpp:334
Fixes: 659b7eb2 ("r600: better tracking for vertex buffer emission")
Related: https://gitlab.freedesktop.org/mesa/mesa/-/issues/10079
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29163>
Since libdrm commit 3bc3cca2 ("xf86drm: use drm device name to identify
drm node type"), drmGetMinorType uses access to get the node type and
causes amdgpu_device_initialize to fail with
DRM_SHIM: unhandled core DRM ioctl 0x5 (0xc0286405)
_amdgpu_device_initialize: amdgpu_get_auth (1) failed (-22)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29096>
This lets us delegate the GPDP2 entrypoint to common code.
This also lets us delete struct vn_physical_device_properties,
as it is redundant with struct vk_properties present in the runtime.
Move the properties present in vn_physical_device_properties to the
local_devices struct used to query the host device properties, so we can
still get and fill those properties.
Replace accesses to struct vn_physical_device with accesses to
struct vk_properties filled in at device initialization time.
v2: rebase and a few fixups (zzyiwei)
- rely solely on vk props for final props sanitizations
- set vk11 props behind vk 1.2 condition
- set default pci props if forwarded
- set extension props based on extension support
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Tested-by: Oskar Viljasaar <oskar.viljasaar@gmail.com>
Reviewed-by: Oskar Viljasaar <oskar.viljasaar@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29180>
This takes in a (VkBaseInStructure *), checks for its type, casts it
into the right property struct and then copies its fields over the right
way to `struct vk_properties`.
v2: a few fixups (zzyiwei)
- add missing brackets required by clang
- fix some indents
- optimize to aovid deep-copying VkPhysicalDeviceProperties
- update to use DETECT_OS_ANDROID as suggested
- cast to avoid -Wswitch for Android struct beyond VkStructureType
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Tested-by: Oskar Viljasaar <oskar.viljasaar@gmail.com>
Reviewed-by: Konstantin Seurer <konstantin.seurer@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29180>
There's no reason why we're doing a single invocation and a loop in the
shader. We may as well let it parallelize on the off chance that
there's more than a few queries to copy.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29231>
According to the simulator a cacheline of the blend state cache
corresponds to 3 cachelines of L3 that are always filled regardless of
the number of render targets in use. Allocate enough space to avoid
pagefaults under simulation, since a scratch page isn't bound by
default.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28283>
According to the simulator a cacheline of the blend state cache
corresponds to 3 cachelines of L3 that are always filled regardless of
the number of render targets in use. Allocate enough space to avoid
pagefaults under simulation, since a scratch page isn't bound by
default.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28283>
Unused since 1eca809680 ("ci/v3dv: test v3dv in arm64
environment"), and in the meantime other code paths have been added and
do not support this (`.gitlab-ci/common/init-stage2.sh` when starting
xorg & wayland for instance), so instead of fixing dead code, let's
remove it.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29201>
2712D0 has V3D 7.1.10 which included draw index and
base vertex in the shader state record packet, shuffling
the locations of most of its fields. Handle this at run
time by emitting the appropriate packet based on the
V3D version since our current versioning framework doesn't
support changes based on revision number alone.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29189>
2710D0 has V3D 7.1.10 which included draw index and
base vertex in the shader state record packet, shuffling
the locations of most of its fields. Handle this at run
time by emitting the appropriate packet based on the
V3D version since our current versoning framework doesn't
support changes based on revision number alone.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29189>
We do query caps quite a lot and this struct should be used to cache
results and to make it easier to express more complex dependencies between
features (e.g. images being supported or not).
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29205>
A format can't be standard and non-standard at the same time. If we
ever hit this assertion, it's because something behind the scenes has
evolved (such as the tiling formats) so something that was marked as
non-standard became standard. Add an assertion so we can quickly catch
these issues in the future and adjust the code.
I don't want to mix this assertion with the one in the line above
since that one is the most useful assertion we have in all the sparse
code, so it's good to know which one we're hitting.
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/27306>
After enabling multi-sampled sparse binding in Anv, we get these
failures. I've investigated them and none are trivial, it's not clear
if they're Anv's fault or not, especially considering how many other
texture-related failures we already have in this fails.txt file.
Since both deqp-vk and Vulkan native apps seem to be working with pure
Anv (no Zink), I don't think it's worth blocking multi-sampled sparse
on Anv just because of Zink.
From what I have investigated, the problems seem related to the
following:
- glcts is expecting 1D images to have 2D block shapes (this is
definitely the case for StandardPageSizesTestCase, we get rid of
the failure by either removing sparse support for 1D images or
telling their block shapes are the same as the 2D images)
- glcts/zink may be trying to use formats that are unsupported by Anv
as if they were supported
- there's probably something funny going on with the GL_R8 format
v2: Adjust test results after merging merging MR 29118.
v3: Zink test results are a moving target...
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> (v1)
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27306>
Consider the following program:
- Uses a multi-sampled image as the color attachment.
- Draws simple geometry at the color attachment.
- Uses the (non-multi-sampled) swapchain image as the resolve image.
- Presents the result.
If the color attachment image (the multi-sampled one) is a sparse
image and it's fully bound, everything works and this patch is not
required.
If the image is partially bound (or just completely unbound), without
this patch the unbound area of the image that ends up being displayed
on the screen is not completely black, and it should be completely
black due to the fact that we claim to support
residencyNonResidentStrict (which is required by vkd3d for DX12).
On DG2, what ends up being displayed in the swapchain image is
actually the whole image as if it was completely bound. On TGL the
unbound area partially displays the geometry that was supposed to be
drawn, but the background is a different color: it's a weird corrupted
image. On both platforms the unbound areas should all be fully black.
This patch applies the proper flushing so that we get the results we
should have.
The bug fixed by this patch is not caught by dEQP or anything our CI
runs (dEQP does have some checks for residencynonResidentStrict
correctness, but none that catch this issue in particular). I was able
to catch this with my own sample program. Using INTEL_DEBUG=stall also
makes the problem go away.
If we had a way to track which images are fully bound we would be able
to avoid this flush. I had code for that in the earliest versions of
sparse before xe.ko had support for gpuva, but it requires maintaining
a bunch of lists, so I'm not sure that's actually worth it.
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/27306>
The Tile64 format from Xe2 is weird and some of its MSAA shapes are
non-standard. Reject them. Otherwise, we'll get dEQP failures such as:
deqp-vk: ../../src/intel/vulkan/anv_sparse.c:829: anv_sparse_calc_image_format_properties: Assertion `is_standard || is_known_nonstandard_format' failed.
Many tests can reproduce this issue, including:
dEQP-VK.memory.requirements.extended.image.sparse_tiling_optimal
Testcase: dEQP-VK.memory.requirements.extended.image.sparse_tiling_optimal
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/27306>
This is all that's needed to make anv_sparse_bind_image_memory() work
with multi-sampled images.
The assert() we just added would have been really helpful when
debugging this.
All the dEQP tests with "sparse" in their names are passing *even*
without this patch. Real-world applications show very clear visual
corruption for sparse MSAA images bound through non-opaque binds since
only a fraction of the the actual image ends up being bound.
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27306>
We call anv_get_image_format_properties() from
anv_GetPhysicalDeviceSparseImageFormatProperties2() because we want to
reject all images that we don't support for the non-sparse case. That
function does not take sample counts as its input, it outputs a list
of possible sample counts. In this patch we check the sample counts it
outputs: if what the user is querying isn't even supported by
non-sparse, reject it right away.
That saves us from having to code in anv_sparse_image_check_support()
cases that are coded elsewhere. Examples include: 1D images and
compressed formats.
This change affects a number of dEQP tests, including:
- dEQP-VK.api.info.sparse_image_format_properties2.1d.optimal.r4g4b4a4_unorm_pack16
- dEQP-VK.api.info.sparse_image_format_properties2.2d.optimal.bc2_srgb_block
Without this patch, and with sparse multi-sampling enabled, this would
hit the following assertion:
anv_formats.c:1903: anv_GetPhysicalDeviceSparseImageFormatProperties2: Assertion `false' failed.
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/27306>
Yes, I understand that this looks like the kind of check that the
applications should be doing instead of us, but if we don't that, dEQP
will have failures. If we claim support for any multi-sampled sparse
feature, dEQP will try to create multi-sampled sparse images with all
possible sample counts, including the ones supported by non-sparse but
not supported by sparse (x8 and x16 on Tile64 platforms) and also the
ones not supported at all, like x32 and x64.
This change affects a number of dEQP tests, including:
- dEQP-VK.api.info.sparse_image_format_properties2.2d.optimal.r32g32_sfloat
Without this patch, and with sparse multi-sampling enabled, this would
hit the following assertion:
anv_sparse.c:866: anv_sparse_calc_image_format_properties: Assertion `is_standard || is_known_nonstandard_format' failed.
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/27306>
Our hardware has more than one layout for multi-sampled images that
use the tiling formats that give us the sparse standard block shapes:
see enum isl_msaa_layout. Only the layout we use for colored images is
compatible with the standard block shapes, so it's the only one we can
expose for multi-sampled sparse.
This change affects a number of dEQP tests, including:
- dEQP-VK.memory.requirements.create_info.image.sparse_residency_aliased_tiling_optimal
Without this patch, and with sparse multi-sampling enabled, this test
would hit the following assertion:
anv_sparse.c:866: anv_sparse_calc_image_format_properties: Assertion `is_standard || is_known_nonstandard_format' failed.
Acked-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/27306>
We're not enabling sparse on multi-sampled images yet, but having the
table here is a first step. The current approach should make the code
a little more compact.
These tables are in section 33.4.3: Standard Sparse Image Block Shapes
of the Vulkan 1.3 spec.
PS: I know we've questioned the need for us to have these tables here
as they are something dEQP should check, but I've hit the "this shape
is not standard" assertion multiple times during development of the
various sparse features, and that really helps narrowing down the
problems. For example, see the next 2 patches in this MR.
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/27306>
Remove the logic that we don't need. In a future commit, it will be
extended to optimize aspects of buffer clears and copies that need to be
optimized.
Changes:
- remove the logic that generated multiple loads/stores per thread,
only 1 load and store can occur in the shader now, allowing clearing/
copying max 4 dwords per thread
- put the src buffer in SSBO slot 0, and the dst buffer in SSBO slot 1
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29053>
Effects:
- multi-component subdword handling removed because it's lowered
- 3-dword loads selected correctly instead of 4-dword loads
- the failure of dEQP-GLES3.functional.buffer.copy.subrange.large_to_small
due to LLVM exposed by a future commit is mysteriously fixed by this
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29053>
Don't bother even trying to test legacy gl features that the hw does not
support and cannot be emulated (or at least not reasonably).
Some of this could in theory be emulated with GS shader on a6xx+, at the
cost of extra draw time overhead. But unless someone shows up with a
real world need for these features (ie. something other than piglit/cts)
I don't think we should penalize every other gl app with the extra
overhead. If you want a slow-but-implements-gl-rusty-sharp-edges driver,
zink already exists to fill that niche. (And if someone does find some
app that needs these features, the right answer is probably driconf to
trigger a transparent fallback to zink.)
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/8850
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28323>
There's a success path on found dmabuf while the iova won't be cleaned
up. This change defers iova alloc till lookup miss and also to prepare
for later racy dmabuf re-import fix.
Also documented a potential leak on error path due to unable to tell
whether a gem handle should be closed or not without refcounting.
Fixes: f17c5297d7 ("tu: Add virtgpu support")
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29093>
This allows us to unify emitting monolithic graphics pipelines and
shader objects.
Though, this temporarily reduces performance in some games due to more
context rolls. But this will be fixed in the following commits by
using the recent mechanism to track context register writes.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28983>
If p_start_linear_vgpr allocates a VGPR that is already blocked, RA
will try moving the blocking VGPR somewhere else. If
p_start_linear_vgpr is inserted right before the branch, that move will
be inserted after exec has been overwritten, which might cause the move
to be skipped for some threads.
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28041>
This matches anv and specification behavior, change makes us toggle the
field in tests/application that may use layered framebuffer but do not
assign any value to gl_Layer.
Example of such a test:
KHR-GL46.geometry_shader.layered_rendering_boundary_condition.layered_rendering_boundary_condition_no_default_layer
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29064>
Trying to spill/fill a temp on the fly has pathologically bad performance in bad
cases, reserving a scratch reg is much more well-behaved. Fixes a fragment
shader timeout in dEQP-VK.graphicsfuzz.spv-stable-maze-flatten-copy-composite
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29179>
Beneficial so we can fuse the comparison.
total instructions in shared programs: 2188179 -> 2185535 (-0.12%)
instructions in affected programs: 392512 -> 389868 (-0.67%)
helped: 894
HURT: 9
Instructions are helped.
total alu in shared programs: 1706063 -> 1703445 (-0.15%)
alu in affected programs: 275063 -> 272445 (-0.95%)
helped: 880
HURT: 9
Alu are helped.
total fscib in shared programs: 1702385 -> 1699743 (-0.16%)
fscib in affected programs: 276199 -> 273557 (-0.96%)
helped: 894
HURT: 9
Fscib are helped.
total ic in shared programs: 462494 -> 462490 (<.01%)
ic in affected programs: 124 -> 120 (-3.23%)
helped: 1
HURT: 0
total bytes in shared programs: 14476964 -> 14464512 (-0.09%)
bytes in affected programs: 2870824 -> 2858372 (-0.43%)
helped: 888
HURT: 155
Bytes are helped.
total regs in shared programs: 662444 -> 662461 (<.01%)
regs in affected programs: 1025 -> 1042 (1.66%)
helped: 14
HURT: 12
Inconclusive result (value mean confidence interval includes 0).
total uniforms in shared programs: 1638301 -> 1638374 (<.01%)
uniforms in affected programs: 17778 -> 17851 (0.41%)
helped: 22
HURT: 54
Uniforms are HURT.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29179>
AGX has limited border colour hardware. To support full
customBorderColorWithoutFormat semantics, we're forced to emulate in shaders at
a substantial performance penalty. Actually, that's needed just to pass CTS
because of other hardware issues stacking on top of each others... Hooray!
Add the texops we need to facilitate efficient custom border colour lowering.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Acked-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29179>
This is our compromise to make NVK and nouveau GL play nice when it
comes to modifiers. The old GL driver depends heavily on the PTE kind
and tile mode, even for images with modifiers. While it correctly
encodes the PTE kind and tile mode in the modifiers it advertises, it
may ignore the modifier and just trust what's set on the BO when it
imports a dma-buf image. This is partly because it doesn't support
VM_BIND and partly because of preexisting bugs in the modifiers
implementation. In either case, we can't fix it retroactively.
To work around this, NVK also sets the PTE kind and tile mode on the BO
when it's a dedicated allocation created for a DRM format modifiers
image. If DRM format modifiers are used without dedicated allocations,
things may still break but that's getting into vanishingly unlikely
scenarios.
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24795>
No shader-db or fossil-db changes on any Intel platform. In this MR, the
only benefit of these changes is to convert some "-a > 0" CSEL
comparisons to "a < 0" for improved readability.
v2: Add integer CSEL support
v3: Use fs_inst::resize_sources and brw_type_is_sint. Both suggested by
Ken.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29095>
No shader-db or fossil-db changes on any Intel platform. This ends up
begin helpful in "intel/brw: Use range analysis to optimize fsign."
v2: Add integer CSEL support
v3: Massive simplification (-20 lines!) of constant propagation
logic. Suggested by Ken. Add missing CSEL case in supports_src_as_imm.
Noticed by Ken.
v4: While MAD can mix F and HF sources on some platforms, CSEL
cannot. Found by skqp on TGL.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> [v3]
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29095>
This bit from the comment should have been a big red flag:
There are currently zero instances of fsign(double(x))*IMM in
shader-db or any test suite, so it is hard to care at this time.
The implementation of that path was incorrect. The XOR instructions
should be predicated like the OR instruction in the non-multiplication
path. As a result, dsign(zero_value) * x will not produce the correct
result.
Instead of fixing this code that is never exercised by anything, replace
it with the simple lowering in NIR.
Ironically, the vec4 implementation is correct. The odds of encountering
an application that is performace limited by dsign performance in vertex
processing stages on Ivy Bridge or Haswell is infinitesimal.
No shader-db changes on any Intel platform.
v2: Delete 's' in emit_fsign as it is now unused.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> [v1]
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29095>
This bit from the comment should have been a big red flag:
There are currently zero instances of fsign(double(x))*IMM in
shader-db or any test suite, so it is hard to care at this time.
The implementation of that path was incorrect. The XOR instructions
should be predicated like the OR instruction in the non-multiplication
path. As a result, dsign(zero_value) * x will not produce the correct
result.
Instead of fixing this code that is never exercised by anything, replace
it with the simple lowering in NIR.
No shader-db or fossil-db changes on any Intel platform.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29095>
For dma-buf, if the import and finish occur back-2-back for the same
dma-buf, zombie vma cleanup will unexpectedly close the re-imported
dma-buf gem handle. This change fixes it by trying to resurrect from
zombie vmas on the dma-buf import path.
Fixes: 63904240f2 ("tu: Re-enable bufferDeviceAddressCaptureReplay")
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29173>
I tested that v_swap_b16 can be encoded as VOP3, because the ISA doc doesn't list
it as a possible VOP3 opcode. VOP3 is nessecary to access v128+.
Foz-DB Navi31:
Totals from 32 (0.04% of 79395) affected shaders:
Instrs: 201865 -> 195168 (-3.32%)
CodeSize: 1082220 -> 1031228 (-4.71%); split: -4.71%, +0.00%
Latency: 2258198 -> 2238586 (-0.87%)
InvThroughput: 796731 -> 788934 (-0.98%)
Copies: 34514 -> 29220 (-15.34%)
VALU: 122457 -> 117163 (-4.32%)
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29143>
Indeed, the object returned by LLVMCreatePassBuilderOptions()
was not freed.
For instance, this issue is triggered with "piglit/bin/cl-api-build-program":
Direct leak of 32 byte(s) in 1 object(s) allocated from:
#0 0x7f6b15abdf57 in operator new(unsigned long) (/usr/lib64/libasan.so.6+0xb2f57)
#1 0x7f6afff6529e in LLVMCreatePassBuilderOptions llvm-18.1.5/lib/Passes/PassBuilderBindings.cpp:83
#2 0x7f6b1186ee41 in optimize ../src/gallium/frontends/clover/llvm/invocation.cpp:521
#3 0x7f6b1186ee41 in clover::llvm::link_program(std::vector<clover::binary, std::allocator<clover::binary> > const&, clover::device const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&) ../src/gallium/frontends/clover/llvm/invocation.cpp:554
#4 0x7f6b1150ce67 in link_program ../src/gallium/frontends/clover/core/compiler.hpp:78
#5 0x7f6b1150ce67 in clover::program::link(clover::ref_vector<clover::device> const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, clover::ref_vector<clover::program> const&) ../src/gallium/frontends/clover/core/program.cpp:78
#6 0x7f6b11401a2b in clBuildProgram ../src/gallium/frontends/clover/api/program.cpp:283
Fixes: 2d4fe5f229 ("clover/llvm: move to modern pass manager.")
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29164>
Blob doesn't use hw binning with GS on all a6xx and a7xx, however
in Turnip it worked without issues until a750. On a750 there are CTS
failures when e.g. dEQP-VK.subgroups.arithmetic.framebuffer.* in
parallel with "forcebin". It is exacerbated by using "syncdraw".
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29074>
Commit 7d9ea77b45 ("glx: add automatic zink fallback loading between hw and sw drivers")
added an automatic zink fallback even when the zink gallium is not
enabled at build time.
It leads to unexpected error log while loading drisw driver and
zink is not installed on the rootfs:
MESA-LOADER: failed to open zink: /usr/lib/dri/zink_dri.so
Fixes: 7d9ea77b45 ("glx: add automatic zink fallback loading between hw and sw drivers")
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Reviewed-by: Antoine Coutant <antoine.coutant@smile.fr>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27478>
commit 1887368df4 ("glx/sw: check for modifier support in the kopper path")
added dri3_priv.h header and dri3_check_multibuffer() function in drisw that
can be build without dri3.
Commit 4477139ec2 added a guard around dri3_check_multibuffer()
function but not around dri3_priv.h header.
Add HAVE_DRI3 guard around dri3_priv.h header.
Fixes: 1887368df4 ("glx/sw: check for modifier support in the kopper path")
v2: Remove the guard around dri3_check_multibuffer() function.
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Antoine Coutant <antoine.coutant@smile.fr>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27478>
previously this reused the swapchain acquire array to add wait
semaphores, but doing so failed to synchronize between successive
API commits
instead, track a single wait semaphore on the batch which can be
updated/reused across all sparse operations, though this has the
unfortunate side effect of synchronizing sparse binds for unrelated
resources
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/10137
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29152>
while the non-SINGLE_MIPTAIL case allows commiting separate layers for
a miptail, the GL spec always treats the miptail as a single unit, so
utilizing this functionality just leads to desync when trying to follow
the GL spec
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29152>
EGL 1.5 specification requires to not match on EGL_NATIVE_VISUAL_ID.
EGL_MESA_x11_native_visual_id extension allows us to remove this
restriction for X11, where we need to match EGL_NATIVE_VISUAL_ID to find
visuals which allow blending.
The reasoning is that on X11, compositors use the visual as "magic bit"
to decide whether to alpha-blend surface contents.
Unlike on most (all?) other windowing systems, requesting an alpha channel
for the config alone does not already imply blending on the compositor
level.
Thus, in order to allow clients to explicitly request configs with
"magic bit" and, similar to GLX, to order configs in a way so clients
not requesting alpha-blending do not get it by accident, do match
visual ids.
Note that one consequence of this is that more configs get
reported to clients.
Based on a patch by Freya Gentz <zegentzy@protonmail.com>, see
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/2376
Signed-off-by: Robert Mader <robert.mader@posteo.de>
Signed-off-by: David Heidelberg <david.heidelberg@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9989>
vk/wsi: Remove unused struct 'wsi_headless_format'
'wsi_headless_format' appears unused, and seems
to have been since initial commit.
radv: Remove unused struct 'blit_region'
'blit_region' appears unused, I think since initial commit.
r600: Remove unused structs
'eg_interp' and 'r600_shader_src' are unused.
I think they are just leftovers from the cleanup
in 20e6c31ba6.
i915: Remove unused struct 'i915_tracked_hw_state'
'i915_tracked_hw_state' appears unused. I think it's just
a leftover from 179cb58795.
llvmpipe: Remove unused struct 'linear_interp'
'linear_interp' doesn't ever seem to have been used.
radeonsi: Remove unused struct 'texture_orig_info'
'texture_orig_info' seems unused, I think since 46b2b3bda8.
svga: Remove unused struct 'svga_3d_invalidate_gb_image'
'svga_3d_invalidate_gb_image' appears unused since 1942c06f9c.
Remove it.
nir: Remove unused struct 'split_struct_state'
'split_struct_state' looks unused since the original commit.
Signed-off-by: Dr. David Alan Gilbert <dave@treblig.org>
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29105>
We need them for the case where explicit sample locations are not
enabled. While we're at it, fix the case where rasterization_samples=0.
This can happen when rasterizer discard is enabled. This fixes MSAA
resolves with NVK+Zink. In particular, it fixes MSAA for the Unigine
Heaven and Valley benchmark.
This also fixes all of the spec@arb_texture_float@multisample-formats
piglit tests.
Fixes: 41d094c2cc ("nvk: Support dynamic state for enabling sample locations")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/10786
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29147>
this otherwise leads to a mismatch where some types of screen may have
the mutex initialized while others don't, in which case dri_release_screen()
will attempt to destroy an uninitialized mutex
cc: mesa-stable
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29021>
Some commas were being skipped, according to history as an attempt
to elide BAD_FILEs, but we still print them, so be consistent. Also
for instructions without any sources, the trailing comma was always
being printed. Fix that too.
Example of instruction output before the change
halt_target(8) (null):UD,
send(8) (mlen: 1) (EOT) (null):UD, 0u, 0u, g126:UD(null):UD NoMask
and after it
halt_target(8) (null):UD
send(8) (mlen: 1) (EOT) (null):UD, 0u, 0u, g126:UD, (null):UD NoMask
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29114>
The debug identifier is put into the captured buffers for error
capture. This helps us figure out what version of the driver people
are running when encountering a GPU hang. This identifier has the
git-sha1 + driver name.
libintel_dev is also a dependency of the compiler so any change to the
git-sha1 also triggers recompile which we want to avoid.
This changes moves the debug identifier to src/intel/common which
drivers already depend on, so the compiler is not affected anymore.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/11136
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29128>
Running
KHR-GL46.sparse_texture_clamp_tests.SparseTextureClampLookupColor test
with Zink on Anv we run into an assert :
assert(inst->mlen <= MAX_SAMPLER_MESSAGE_SIZE * reg_unit(devinfo));
Turns out we've not covered all the cases in the SIMD lowering.
It's a bit of a shame to have both files reproduce the same logic.
Will try to think of a better way to extract the layout of the a send
message but that'll be a much bigger rework.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: mesa-stable
Reviewed-by: Sagar Ghuge <sagar.ghuge@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29118>
Since commit 7d9ea77b45 ("glx: add automatic zink fallback loading between hw
and sw drivers"), zink could be tried as a fallback. It'd better silence
if the zink loading is implicit and on fail as what commit 4cc975c6e9 ("glx: silence
more implicit-load zink errors") has done. But there seems to be one
left bebind, which is spit when building swrast but no zink with -Dglx=dri.
v2: plumb the flag through from egl/glx to the loader (zmike)
Signed-off-by: Luc Ma <luc@sietium.com>
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28970>
I have no idea why I've added it in the first place, but it's causing dead
code warnings to appear with newer rustc versions, so remove it.
Fixes: 7f77f91929 ("rusticl/icd: split Arc part out of CLObject into new trait")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29120>
In the past where backends had to deal with nir_register we needed
a specific path for them here because nir_def_components_read only
worked on ssa defs, but now that we got rid of nir_register we
only have nir_def and we don't need to go out of our way to do this
and we can just always use nir_def_components_read.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28978>
This is similar to what we do for textures where we program a number
of channels matching the number of componentes actually read by the
shader.
Makes tests like dEQP-VK.image.load_store.with_format.2d.r32_uint
drop from 18 instructions to 14 by emitting a single ldtmu instead
of 4.
From dEQP-VK.image.load_store.*:
total instructions in shared programs: 12681 -> 12093 (-4.64%)
instructions in affected programs: 4866 -> 4278 (-12.08%)
helped: 256
HURT: 0
helped stats (abs) min: 1 max: 4 x̄: 2.30 x̃: 2
helped stats (rel) min: 4.76% max: 25.00% x̄: 12.35% x̃: 11.11%
95% mean confidence interval for instructions value: -2.40 -2.19
95% mean confidence interval for instructions %-change: -12.99% -11.71%
Instructions are helped.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28978>
Some shaders use N textures but not bind these in consecutive
slots, so then we find texture accesses to indices that exceed the
number of textures and we assert crash. This happens with various
shaders from shader-db.
Fix that by looking at the largest binding used in the shader
and using that as the number of textures used.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28978>
Instead of populating SPIR-V capabilities from st_extensions.c and then
deriving extensios from caps, we populate SPIR-V extensions from
st_extensions.c and populate caps from a combination of GL extensions,
SPIR-V extensions, and GL limits. This means that the stuff we store in
the context is the actual stuff exposed to the client. This is also
more like how we do things in Vulkan.
Most importantly, however, this means we're no longer storing a struct
spirv_supported_capabilities in the context. Since we're about to
replace it with the auto-generated spirv_capabilities struct, that would
mean mtypes.h is dependent on codegen and mtypes.h is included
everywhere.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28905>
Was triggering a stack overflow in android CTS with
dEQP-VK.spirv_assembly.instruction.compute.spirv_ids_abuse.lots_ids and
friends, presumably due to smaller stack size with bionic. But there
isn't really any point to doing this validation in release builds so
lets limit it to debug builds (which will cover mesa-CI).
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29088>
Note that we don't support (and clarify on code why) two of the
features of this extension:
* extendedDynamicState2PatchControlPoints: as we don't support
Tessellation Shaders
* extendedDynamicState2LogicOp: as supporting it would need to allow
compile shader variants after pipeline creation, that we try to
avoid as much as possible (and it is not supported right now)
Note that those two features are not mandatory for Vulkan 1.3. From
spec:
"Promotion to Vulkan 1.3
This extension has been partially promoted. The dynamic state
enumerants VK_DYNAMIC_STATE_DEPTH_BIAS_ENABLE_EXT,
VK_DYNAMIC_STATE_PRIMITIVE_RESTART_ENABLE_EXT, and
VK_DYNAMIC_STATE_RASTERIZER_DISCARD_ENABLE_EXT; and the
corresponding entry points in this extension are included in core
Vulkan 1.3, with the EXT suffix omitted. The enumerants and entry
points for dynamic logic operation and patch control points are not
promoted, nor is the feature structure. Extension interfaces that
were promoted remain available as aliases of the core functionality."
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28980>
Note that when it is dynamic, it goes to the codepath of having
enabled raster_enabled at the pipeline, even if at the end it will be
disabled. The fragment shader compilation, and the stage keys, depends
on rasterization being enabled or not. As mentioned, if the state is
dynamic, it assumes that the rasterization is enabled.
That would work, as then the rasterization could be discarded at the
CFG_BITS package, by the command buffer at draw time. We just have a
(discarded) shader slightly more complex that it would have been with
rasterization enabled.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28980>
While working on VK_EXT_extended_dynamic_state2 we found two issues
the stencil emission code, after the update for StencilTestEnable
being dynamic.
Specifically:
* pack_stencil_cfg: if we don't have a ds_info, we need to return,
as pack_single_stencil_cfg uses it to fill it up. Also the check
for MESA_VK_DYNAMIC_DS_STENCIL_TEST_ENABLE was not needed. That
state doesn't affect the content of the STENCIL_CFG
packet. Stencil is enabled/disabled at the CFG_BITS packet.
* cmd_buffer_emit_stencil: we can't use pipeline->emit_stencil_cfg
to filter if it is needed to emit that as since
stencil_test_enable and stencil_op become dynamic.
We also update which states we check that are dynamic. As
mentioned STENCIL_TEST_ENABLE doesn't affect here.
Fixes: 60e9237e81 ("v3dv: StencilOp and StencilTestEnable are now dynamic")
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28980>
There were some pending places to update after PrimitiveTopology
become dynamic. FWIW, this was not catched by any CTS test.
As we are here we add a comment to explain why we still use the
topology on the pipeline.
Fixes: 2526f74ade ("v3dv: PrimitiveTopology is now dynamic")
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28980>
Using the same buffer without a barrier actually can lead to data races as
drivers might not properly synchronize the content. Using the stream
uploader is a neat fix which prevents us from having to use a barrier but
still keep high throughput when launching kernels back-to-back.
Fixes: 5ff33f9905 ("rusticl: use real buffer for cb0 for drivers prefering")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27666>
When logging a failed IOCTL, an errno is more useful than the output of
`drmIoctl()`. When the IOCTL fails, the return is usually -1 and this
value isn't very useful. On the other hand, the errno can help us to
debug the reason why the IOCTL failed.
Signed-off-by: Maíra Canal <mcanal@igalia.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29067>
zink_shader_init is a long function, and making it async unblocks
the main app thread to improve startup/load times
this also eliminates a deserialize from separate shader compile by
linking up the lifetime of the nir_shader with the shader compilation
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28955>
A7XX doesn't have the same issue with UBWC flag buffer coherency
as A6XX has.
Though for VK_EXT_rasterization_order_attachment_access we still have
to set prim mode to flushing since it allows not to explicitly synchronize
between writes and reads. Though we could use FLUSH_PER_OVERLAP in sysmem.
Passes:
dEQP-VK.pipeline.*feedback_loop*
dEQP-GLES31.functional.blend_equation_advanced.* (with Zink)
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28597>
Copies/fills/updates for buffers are happening through CCU but need
additional synchronization when write range is not aligned to 64 bytes.
Because dst buffer access uses either R8_UNORM or R32_UINT and they are not
coherent between each other in CCU since format seem to be a part of a
cache key.
See: https://gitlab.khronos.org/vulkan/vulkan/-/issues/3306
The synchronization with writes from UCHE (e.g. with SSBO stores) are
solved by the fact that UCHE has byte level dirtiness tracking and that CCU
flush would happen always before UCHE flush for such case (e.g. both
renderpass and dispatch would flush pending CCU write).
Additionally see:
https://gitlab.khronos.org/vulkan/vulkan/-/issues/3398#note_400111
Fixes geometry corruption and potentially hangs in Resident Evil 3.
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28469>
There are more things to do, e.g. BV mempool dumping and estimating the
BV location. However this is a good start.
The expanded register size is because the reglist includes registers
from other cores and these are read the same as any other GPU register.
Note that this is also the actual range of type4 packets, even though
registers higher than 0xffff are all protected. Right now these are
skipped on page faults but still read with the crashdumper for hangs.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27266>
On pre-Valhall HW, the fragment shader metadata was part of the RSD
(renderer state descriptor), which was emitted at draw time, but
Valhall introduces a shader program descriptor containing only the
shader information, and this one is emitted at shader preparation
time.
If we don't add the FS state BO to batch, we might end up with a batch
being executed after the shader object has been destroyed, leading to
page faults when the GPU tries to access the shader program descriptor.
We make the panfrost_batch_add_bo() unconditional since it gracefully
handles the NULL case (which will happen on v7-).
Fixes: 087b63cb07 ("panfrost: Allow uploading fragment SPDs")
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Antonino Maniscalco <antonino.maniscalco@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28926>
During etna_assemble(..) we check if the uniform usage is valid for
the target GPU. As we do not fully init the srcs, it can happen that
we look at random data during the uniform check. This generates
false positive "generating instruction that accesses two different uniforms"
errors.
Fixes: 5aede1a157 ("etnaviv: isa: Do src swizzle with isaspec")
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/29048>
Add performance counting support for a7xx in Freedreno, providing the
available performance counter groups along with the lists of countables
that can be counted through related counters.
All the collected countable names and values are provided in enum
definitions, even when the names indicate some countables being reserved.
The perfcounter groups don't include those reserved values.
The countable selection command stream in fdperf is enabled for a7xx,
sharing the same command stream created for 5th- and 6th-gen devices.
Signed-off-by: Zan Dobersek <zdobersek@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27483>
Instead of the ratio of counter value change in a certain sampling window,
display the raw integer change of that counter value. Counters counting
countables with names indicating cycle values still have that ratio
computed and printed alongside the raw value.
Signed-off-by: Zan Dobersek <zdobersek@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27483>
The counter values on Adreno are 64-bit values, but only their lower
32 bits have been read until now.
This change switches to reading the complete 64-bit value, storing that
value and the delta against the previous value for each counter. Similar is
done for time values, namely storing the time value and the delta against
the previous value (in microseconds) for each counter. The deltas are then
used to compute the counter change per second, as was done before.
In curses UI, an early sampling is done during setup in order to avoid
artificially-large values popping up in the first update due to the deltas
being calculated to initially-zero values.
Signed-off-by: Zan Dobersek <zdobersek@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27483>
fdperf reserves the first CP counter for measuring the GPU frequency.
A new flag is added to the fdperf's counter struct type, the flag being
enabled for the first CP counter during counter setup.
Different tests on group and counter indices are replaced by testing for
this flag's value. Only exception is the restore_counter_groups()
functionality, where now this reserved CP counter is also reselected with
the persistent CP_ALWAYS_COUNT countable value, in case some other program
overrides it.
Signed-off-by: Zan Dobersek <zdobersek@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27483>
Right now select_counter() is called with values of specific countables
that should be tracked in the given counter, but it treats those values
as indices into the array of all available countables for a given counter
group. This works right now since all countable values for any counter
group are sequential, but that won't be the case on a7xx.
To address that, select_counter() is adjusted to find the index of the
specified countable value, and use that to store the label pointer that
should be displayed for the desired counter.
Signed-off-by: Zan Dobersek <zdobersek@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27483>
Currently ffmpeg has a bug in VAAPI AV1 decode that in some cases
it submits the same slice data buffer as many times as there is tiles.
However, in other cases it behaves correctly and all slice data buffers
contain different parts of bitstream to decode which this change breaks.
Now that the va frontend is passing correct offsets, this fixes decoding
AV1-TEST-VECTORS/av1-1-b8-22-svc-L1T2 with ffmpeg.
This reverts commit e6701f7231.
Cc: mesa-stable
Reviewed-by: Leo Liu <leo.liu@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28960>
The slice parameter data offset refers to offset in the submitted data buffer.
When multiple slice data buffers are submitted, the offsets of all slices needs
to be adjusted to be based from the start of the first data buffer.
Cc: mesa-stable
Reviewed-by: Leo Liu <leo.liu@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28960>
Remove the v3dv_GetPhysicalDeviceProperties and the
v3dv_GetPhysicalDeviceProperties2 functions, replace them
by a private get_device_properties() called at device initialization
time.
(given the diff, the change is best viewed with --diff-algorithm=histogram)
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Tested-by: Roman Stratiienko <r.stratiienko@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26386>
get_property_structs() now checks if a property struct is
in ANDROID_PROPERTIES and marks it as such.
The header file now includes vk_android_native_buffer.h and the
Android properties in vk_properties..
For the C file, also generate case statements for respective Android
property structs.
All of the Android-specific code is #ifdeffed behind ANDROID.
That being said, we only support PresentationPropertiesANDROID for now.
Reviewed-by: Konstantin Seurer <konstantin.seurer@gmail.com>
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Tested-by: Roman Stratiienko <r.stratiienko@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26386>
We want to move more Android-related functions into common code.
Many of which require interactions with the gralloc. Therefore,
struct u_gralloc must be kept in a common code.
vk_android_get_ugralloc() must be used for gralloc API calls.
vk_android_{init|destroy}_ugralloc() must be used in Vulkan HAL
initialization code, e.g.:
- In XXXX_hal_open() to initialize the gralloc
- In XXXX_hal_close() to destroy the gralloc
We do not put gralloc initialization into the generic code because we want
it to be initialized by Zygote's Vulkan preloader, which may sometimes
preload gralloc shared libraries, thus speeding up the initialization
of user applications.
Change-Id: I2af643bd132e6cdbfed043c8c18836501764952f
Signed-off-by: Roman Stratiienko <r.stratiienko@gmail.com>
Tested-by: tarsin <yuanqingxiang233@163.com>
Acked-by: David Heidelberg <david.heidelberg@collabora.com>
Reviewed-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25360>
Unmapping the BO associated with a VkDeviceMemory object was
previously handled when destroying the object, this behavior
isn't problematic when the mapping is driver-controlled but
with VK_EXT_map_memory_placed, the user may want control over
the allocation and reuse the mapping after calling unmap.
Signed-off-by: Mark Collins <mark@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28928>
D16 rounds towards zero for fp32 -> fp16, but for fixed point it rounds to
nearest even in fp16. MIMG without D16 also rounds to nearest even, but in fp32.
This means D16 and f2f16_rtz(tex@32) can produce different results.
Sadly this also means we can never use d16 if fp16 rounding isn't undefined.
Cc: mesa-stable
Acked-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28730>
Fixes fs-uint-to-float-of-extract-int8.shader_test and
fs-uint-to-float-of-extract-int16.shader_test added by piglit!883.
v2: Expand the comment explaining the potential problem. Suggested by
Caio.
Fixes: e6022281f2 ("intel/elk: Rename files to use elk prefix")
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27891>
Fixes fs-uint-to-float-of-extract-int8.shader_test and
fs-uint-to-float-of-extract-int16.shader_test added by piglit!883.
No shader-db or fossil-db changes on any Intel platform.
v2: Expand the comment explaining the potential problem. Suggested by
Caio.
Fixes: 29ce110be6 ("i965/fs: Remove extract virtual opcodes.")
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27891>
When loading the base shader serialization there is a discrepancy
between the state parameters that may already have been optimized,
because after storing the serialization the shader went through
st_finalize_nir, and _mesa_optimize_state_parameters was run, so
that original state parameters may have been optimized and replaced
by new parameters.
After get_nir_shader is called, the original state parameters are
re-added - in addition to the optimized parameters. This lead to
an bug with the uniform offsets when lowering uniforms to UBOs.
Therefore, as a hotfix for drivers that don't support packed
uniforms, ignore the base serialization and use the
serialization obtained after st_finalize_nir was run. With that
the problem can be avoided.
Fixes: 5eb0136a3c
mesa/st: when creating draw shader variants,
use the base nir and skip driver opts
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/10881
v2: reorder conditional evaluation for better readability (zmike)
v3: revert c72bb8de7 ("r300: mark new fails") (Pavel Ondračka)
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28994>
Cross-device is a virtio-gpu feature that enables sharing host blob
dma-bufs with other virtio devices, like virtio-wl or virtio-video.
This feature is mainly used by ChromeOS and not required if there is
no dma-buf sharing. Venus has a hard requirement for the cross-device
feature.
Qemu doesn't support cross-device. Relax cross-device feature requirement
by making it optional, allowing Venus to work on Qemu.
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29040>
When a job is submitted to the flush_queue the resource dt_idx is reset,
and if a readback is requested then we have to make sure that the
corresponding kopper_preset has finished before we can acquire the image
for readback, so wait for the according fence in this case.
This fixes the validation error UNASSIGNED-Threading-MultipleThreads-Write
triggered by piglit "read-front" lavapipe.
Fixes: 8ade5588e3
zink: add kopper api
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28127>
How this works? First we check which immediates are used as vectors,
i.e., have any reads that are using 2 or more channels. Such immdeiates
will be places in a free slots (but only the specific channels that are
used in the vector). This way we don't have to worry about swizzling
restrictions. The remaining scalar immediates will be checked for
duplicates and placed in free slots, including any empty slots in
previously places vector immediates (any swizzle is valid for scalars).
RV410:
total instructions in shared programs: 98883 -> 98905 (0.02%)
instructions in affected programs: 15414 -> 15436 (0.14%)
helped: 100
HURT: 102
total presub in shared programs: 2235 -> 2235 (0.00%)
presub in affected programs: 608 -> 608 (0.00%)
helped: 51
HURT: 72
total omod in shared programs: 419 -> 418 (-0.24%)
omod in affected programs: 15 -> 14 (-6.67%)
helped: 3
HURT: 3
total temps in shared programs: 15698 -> 15692 (-0.04%)
temps in affected programs: 952 -> 946 (-0.63%)
helped: 46
HURT: 37
total consts in shared programs: 84458 -> 83856 (-0.71%)
consts in affected programs: 14648 -> 14046 (-4.11%)
helped: 499
HURT: 0
total cycles in shared programs: 156476 -> 156493 (0.01%)
cycles in affected programs: 22532 -> 22549 (0.08%)
helped: 100
HURT: 102
LOST: shaders/ck2/157.shader_test FS
GAINED: shaders/ck2/160.shader_test FS
GAINED: shaders/tesseract/395.shader_test FS
RV530:
total instructions in shared programs: 119543 -> 119612 (0.06%)
instructions in affected programs: 27435 -> 27504 (0.25%)
helped: 118
HURT: 183
total presub in shared programs: 7257 -> 7111 (-2.01%)
presub in affected programs: 1856 -> 1710 (-7.87%)
helped: 121
HURT: 48
total omod in shared programs: 426 -> 427 (0.23%)
omod in affected programs: 5 -> 6 (20.00%)
helped: 1
HURT: 2
total temps in shared programs: 16784 -> 16779 (-0.03%)
temps in affected programs: 392 -> 387 (-1.28%)
helped: 29
HURT: 17
total consts in shared programs: 93198 -> 92667 (-0.57%)
consts in affected programs: 14577 -> 14046 (-3.64%)
helped: 451
HURT: 0
total cycles in shared programs: 186649 -> 186590 (-0.03%)
cycles in affected programs: 26306 -> 26247 (-0.22%)
helped: 125
HURT: 111
Signed-off-by: Pavel Ondračka <pavel.ondracka@gmail.com>
Reviewed-by: Filip Gawin <filip.gawin@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28630>
We are not doing this on R5xx unless we have more than 200 constants,
because emitting constants one by one will add extra overhead at emit
time which we want to avoid if possible.
RV410:
total instructions in shared programs: 98778 -> 98703 (-0.08%)
instructions in affected programs: 7106 -> 7031 (-1.06%)
helped: 80
HURT: 25
total presub in shared programs: 2266 -> 2227 (-1.72%)
presub in affected programs: 134 -> 95 (-29.10%)
helped: 22
HURT: 10
total temps in shared programs: 15662 -> 15660 (-0.01%)
temps in affected programs: 330 -> 328 (-0.61%)
helped: 16
HURT: 13
total consts in shared programs: 85632 -> 84400 (-1.44%)
consts in affected programs: 6646 -> 5414 (-18.54%)
helped: 617
HURT: 0
total cycles in shared programs: 156305 -> 156234 (-0.05%)
cycles in affected programs: 14167 -> 14096 (-0.50%)
helped: 79
HURT: 28
LOST: shaders/ck2/160.shader_test FS
GAINED: shaders/ck2/157.shader_test FS
GAINED: shaders/tropics/249.shader_test FS
GAINED: shaders/tropics/252.shader_test FS
RV530:
total consts in shared programs: 93209 -> 93198 (-0.01%)
consts in affected programs: 72 -> 61 (-15.28%)
helped: 6
HURT: 0
Signed-off-by: Pavel Ondračka <pavel.ondracka@gmail.comm>
Reviewed-by: Filip Gawin <filip.gawin@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28630>
Instead of just moving around constants as full vec4, we will now have
the flexibility to shuffle scalars around. However, this commit just
prepares the infrestructure and converts to it, while the constant
elimination logiic reamins the same, i.e., we only remove constant if it
is fully unused and there is no constant compaction whatsoever.
Signed-off-by: Pavel Ondračka <pavel.ondracka@gmail.com>
Reviewed-by: Filip Gawin <filip.gawin@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28630>
SPI_SHADER_COL_FORMAT/CB_SHADER_MASK are used slightly differently
for PS epilogs, shader objects and monolithic graphics pipelines.
This introduces a new state that will allow us to emit these two
registers in only place. The main motivation is for depth-only RB+
support and for tracking context registers in the cmdbuf.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28976>
Per section 7.7.3, the structure includes additional optional layer-specific
information, which is padded if left unset, based on the value of
max_sub_layers_minus1. The vulkan input structs have no way to specify this
per-layer information, so we just need the padding.
Reviewed-by: Hyunjun Ko <zzoon@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29001>
This enables EXT_depth_range_unrestricted from VOLTA_A
Test of dEQP-VK.*depth_range_unrestricted* on TU104 shows:
Test run totals:
Passed: 14212/14212 (100.0%)
Failed: 0/14212 (0.0%)
Not supported: 0/14212 (0.0%)
Warnings: 0/14212 (0.0%)
Waived: 0/14212 (0.0%)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28958>
Now that we have flows, custom tracks, and timestamps, we can have a track
for wayland buffer presentation times, tagged with appropriate flow ids
so we can follow when a buffer was acquired through to the time it was
displayed.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28634>
This can be useful if we know when an event happened, but our code isn't
running at that time (such as reporting when an image was presented in
the wayland wsi).
We can't really mix these with events that we log at the current time,
because there could be overlap, so also add a function for creating
custom tracks.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28634>
The depth and stencil tests should be disabled in case the respective
attachments are null in VkRenderingInfo or their format is undefined in
VkPipelineRenderingCreateInfo, additionally the stencil test should be
disabled in case the depth/stencil attachment has no stencil component.
Fixes:
dEQP-VK.pipeline.*.stencil.no_stencil_att.*.d24_unorm_s8_uint
dEQP-VK.pipeline.*.stencil.no_stencil_att.*.x8_d24_unorm_pack32
Signed-off-by: Amber Harmonia <amber@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28556>
Xe KMD will not provide a enum with formats, instead UMD needs set
a uint64_t with type, counter_sel, counter_size and bc_report for the
format.
So here changing from int to uint64_t, it do not causes any issues for
i915 and makes it ready for Xe KMD.
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/28997>
I noticed some unnecessary 64-bit ints in shaders that were using doubles.
Perhaps there's a different missing optimization that should run on the
actual pack/unpack instructions before they're lowered, or maybe I'm just
lowering them too early, but these seem simple enough that we might want
them even for hand-rolled pack/unpack pairs.
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27314>
This gathers a number of sources into a contiguous vector register.
Eventually, the plan is that it will use a MOV for a single source,
or LOAD_PAYLOAD for multiple sources. For now, it emits a series of
MOVs to allow us to rewrite a bunch of existing code to use the new
helper, then change them all over at once later.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28971>
When emitting a sampler message, we allocate a temporary destination
large enough to hold 4 values (or 5 for sparse). This is the maximum
size needed to hold any result. However, we shrink the size written by
the sampler message to skip writing any trailing components that NIR
tells us are never read. So we may not write the entire temporary.
The NIR texture instruction has a destination VGRF which is sized
assuming that all components are present. We issue a LOAD_PAYLOAD
instruction to copy our sampler result temporary to the NIR destination.
When we reduce the response length of the sampler messages, then some of
these temporary components have undefined values. The correct way to
indicate that is by using a BAD_FILE source. Unfortunately, we were
naively reading offsets of the temporary that were never written, but
are still part of a larger VGRF. This complicates things.
For example, sampling and only using RGB (not RGBA) was producing this:
txl_logical(8) (written: 3) vgrf3+0.0:F, ...
undef(8) (written: 4) vgrf4:UD
load_payload(8) (written: 4) vgrf4:F, vgrf3+0.0:F, vgrf3+1.0:F, vgrf3+2.0:F, vgrf3+3.0:F
The last source, vgrf3+3.0:F, is undefined, and should be BAD_FILE.
Doing so allows VGRF splitting and other optimizations to work better.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28971>
If there's only a single instruction in a basic block, then removing it
would create an empty block. We seem to have trouble representing those
as there are no instructions with an IP inside the block; several places
mess up connections. While most blocks end in control flow instructions
(which are rarely eliminated), ones preceding a DO instruction may end
in an ordinary instruction. This makes such blocks tricky to merge with
adjacent blocks - they may be between loops. Any optimization pass may
may find such an instruction and want to eliminate it, and most of them
are unprepared to perform such CFG link surgery. Nor do we want to make
every pass aware of this issue.
To work around this, we simply replace an instruction with a NOP when
removing it from a block containing only that instruction, leaving the
block in place.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28971>
When internal compute shaders are used, existing shader images are not
fully unbound, which means any image can be bound, even if the internal
shader doesn't use images.
This strengthens the code by applying it only to images used by internal
compute shaders.
Acked-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28846>
When this was promoted to EXT it expanded its properties struct to add a new
supportsNonZeroFirstInstance field.
Fixes: d38ff02c03 ("v3dv: mark some promoted extensions as supported")
Fixes: dEQP-VK.api.info.vulkan1p2_limits_validation.khr_vertex_attribute_divisor
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28964>
if swapchain creation fails (e.g., insane cts swapchain configs), the
swapchain gets demoted to a non-window image that is still accessed by
the frontend. this image should not ever hit corresponding zink entrypoints
for swapchain-only images, which requires a flag to test swapchain-edness
cc: mesa-stable
Acked-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28904>
The front-page of the docs is currently fairly intimidating, by diving
into details rather abruptly. Let's try to make it a bit easier to
navigate t by moving the details to their own articles, but linking them
from the front-page.
Acked-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28953>
This was a leftover. Flags can be different than 0, like for required
subgroup size and it should already be correctly supported.
Fixes recent dEQP-VK.shader_object.performance.dispatch_base.
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/28946>
According to PAL, the hw uses the smaller value of
DB_Z_INFO.NUM_SAMPLES and PA_SC_AA_CONFIG.MSAA_EXPOSED_SAMPLES when
there is no bound depth/stencil buffer, and it uses 8x to make sure
the used value is MSAA_EXPOSED_SAMPLES.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28952>
With the previous commit, we now have new builder helpers that will
allocate a temporary destination for us. So we can eliminate a lot
of the temporary naming and declarations, and build up expressions.
In a number of cases here, the code was confusingly mixing D-type
addresses with UD-immediates, or expecting a UD destination. But the
underlying values should always be positive anyway. To accomodate the
type inference restriction that the base types much match, we switch
these over to be purely UD calculations. It's cleaner to do so anyway.
Compared to the old code, this may in some cases allocate additional
temporary registers for subexpressions.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28957>
In many cases, we calculate an expression by generating a series of
instructions. We'd either overwrite the same register repeatedly,
or call vgrf(BRW_TYPE_X) repeatedly to allocate temporaries for each
intermediate step. In many cases, we overwrote the same register simply
because allocating and naming temporaries for each step was annoying.
This commit adds new builder helpers that will allocate a temporary
destination for you, using simple type interference: unary operations
use the source type, and binary operations require a matching base type
and return the largest of the two types.
The helpers return the destination register, allowing us to write in an
expression-tree style, chaining together builder operations to produce
whole values. Sort of like nir_builder. We still optionally will write
out the fs_inst pointer in case the caller wants to do things like set
predicates or saturation.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28957>
Some instructions can operate on mixed types. Typically this is
something like a binary operation with UD and UW sources resulting
in a UD destination. In order to make it easier to find the result
type of such operations, let's make a type helper that returns the
larger of the two types (but requires the base type to match).
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28957>
This way we don't have to constantly copy the full thing at kernel
creation time lowering CPU overhead significantly.
With the previous changes clCreateKernel is basically for free.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28872>
We do not support it at runtime anyway and assert on them to be unique
across devices at build time. This significantly reduces overhead of
clCreateKernel as this is something applications actually rely on being
fast.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28872>
Add a separate pipe for the NPU device when the primary device is a GPU.
In case of compute-only contexts, prefer to use the separate NPU pipe.
This allows to create a compute-only context that uses the NPU pipe on
a screen that has a 3D GPU as primary device.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28921>
Allow to pass both gpu and npu to etna_screen_create() separately,
in preparetion for devices with both 3D GPU and NPU.
Iterate over all cores or until both GPU and NPU are found.
If no 3D GPU was found, screen->gpu will be set to the npu as well,
so nothing changes for NPU-only devices.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28921>
With explicit sync, only if it wasn't done earlier for FIFO.
Prevents potentially unbounded memory usage for (wl_buffer.release
events in) the queue, since we don't dispatch the queue anywhere else
with explicit sync.
v2:
* Use wl_display_dispatch_queue_pending instead of
wl_display_dispatch_queue_timeout. (Sebastian Wick)
* Call it from wsi_wl_swapchain_queue_present instead of
wsi_wl_swapchain_acquire_next_image_explicit. (Joshua Ashton)
Fixes: 5f7a5a27ef ("wsi: Implement linux-drm-syncobj-v1")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28874>
The constant-folding definition and comments say that it takes the high
16 bits of the first source and low 16 bits of the second source, but
actually it's the opposite. The algebraic optimization, which actually
happens and needs to be correct, was correct but the comment above it
was wrong.
Note that in the way we use it when lowering multiplications, the
ordering doesn't matter.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22075>
In the future we will have many ALU instructions passing shared
registers to each other, and surrounding them each with moves to/from
shared registers will severely bloat the IR size coming out of NIR and
make more pointless work for copy propagation. Instead, do something
more like the ACO approach and allow values stored in the hash table to
be shared, and move the burden of emitting a mov to non-shared to
ir3_get_src(). We will then use ir3_get_src_shared() or
ir3_get_src_maybe_shared() as appropriate in cases where we can handle
shared registers or where we can handle both.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22075>
Propagate shared-ness to the the source, and when creating an ALU
instruction with all scalar sources and the instruction is supported on
the scalar ALU, automatically make the destination scalar. This includes
MOV/COV.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22075>
In addition to replacing existing no-longer-needed usage of the
readfirst macro, we will use this for other NIR ALU instructions that
need to materialize constants when they use the shared ALU.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22075>
When we use the scalar ALU we will start inserting moves with different
API-level semantics from readInvocation() or readFirstInvocation(). We
need to distinguish between these moves and lowered readInvocation()
moves, to avoid unnecessarily keeping helper invocations alive when
inserting (eq).
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22075>
cat1-cat4 instructions executed on the shared ALU can use shared
registers in an unlimited capacity, as opposed to the vector ALU which
apparently treats shared registers and consts the same. However they
cannot use "normal" sources (which must be "uniformized" via a mov).
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22075>
On a650 and later, there is a "scalar ALU" capable of executing cat2
instructions, a subset of cat3 instructions (csel but *not* mad), and
cat4 instructions. There is also another copy of the scalar ALU embedded
in HLSQ, which is responsible for executing preambles with the "early
preamble" bit set. The two new features are closely intertwined, because
the scalar ALU makes it possible to make most preambles only use shared
registers, letting us optimistically use shared registers and only fall
back to normal preambles if we ran out of shared registers. But the
scalar ALU is also generally useful for moving calculations of uniform
values like loop indices to the scalar ALU to reduce normal register
pressure and increase parallelism, because like SFU/EFU and texture
units different waves can execute ALU and scalar ALU instructions in
parallel.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22075>
I got this wrong before because I missed the need for (ss), once that
was fixed then a move from anything to a shared register is legal,
include non-shared registers, as long as all active channels have the
same value.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22075>
Copies from normal to shared registers are only allowed architecturally
if all of the active threads have the same value for the normal
register, which means that they can normally be propagated into e.g. ALU
instructions or other copies. However, there are a few instruction types
where this is not (currently) allowed, namely the scan macro where the
source is tied to a shared destination and the collect/split macros
where the lowering doesn't currently allow differently-typed sources and
destinations (although we may want to allow that in the future), so we
need to clean up ir3_valid_flags() to catch that.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22075>
We now use INVALID_REG to mean that a source or destination does not
have a preassigned register. We ignore this for anything but inputs and
outputs for now, but don't make it look like we're preassigning the
array to r0.x. This also will allow us to assert that preassigned
registers are in the correct range.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22075>
This is what the rest of ra validation uses, because it returns the
correct thing for arrays (i.e. the base of the array, instead of the
actual register accessed). num is sometimes not set, so it was causing
spurious assertion failures.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22075>
In the past we avoided emitting pure 16-bit subgroup macros because of
this bug, but because we're going to start emitting the special moves
they expand to directly, we also have to handle the bug directly.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22075>
Split up the dependencies into multiple files, similar to RA, and
calculate the file + index. This lets us remove the previous hack we had
and lets us handle half shared registers correctly.
The actual calculation of the file is moved into a shared
ir3_reg_file_offset() function so that it can be reused in other places
which have to check for overlapping registers.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22075>
Catch when we try to propagate an immediate or const, which can happen
if we forget to specify the valid flags for the instruction, and make
sure that it's the same size and type.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22075>
Those crashes are gone if VK_EXT_extended_dynamic_state is supported.
It is worth to note that the previous entry mentioned Ricardo's patch
as tentative. That is already on vk-gl-cts main (not still on the tag
used by the CI), and the code at this point has been tested with and
without that patch.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27609>
This commit introduces a significant change when we emit STENCIL_CFG,
with any dynamic state: we stop to use cl_emit_with_prepacked, and use
directly cl_emit. The reason is that now most of the STENCIL_CFG
parameters are dynamic, any improvement of using
cl_emit_with_prepacked is minimized. Also gets the code simpler, and
avoid the need to be extra careful with the fact that
cl_emit_with_prepaked doesn't override values.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27609>
Note that although the topology affects the final shader, and it is
part of the v3d_fs_key (through is_points and is_lines), changing
dynamically the topology would not trigger a shader recompilation as
that would only needed if there was a topology class change. From
spec:
"VUID-vkCmdDraw-dynamicPrimitiveTopologyUnrestricted-07500
If the bound graphics pipeline state was created with the
VK_DYNAMIC_STATE_PRIMITIVE_TOPOLOGY dynamic state enabled and the
dynamicPrimitiveTopologyUnrestricted is VK_FALSE, then the
primitiveTopology parameter of vkCmdSetPrimitiveTopology must be of
the same topology class as the pipeline
VkPipelineInputAssemblyStateCreateInfo::topology state"
dynamicPrimitiveTopologyUnrestricted is defined at
VK_EXT_extended_dynamic_state3, so for now it is false. And even if in
the future we support that extension, it is really likely that we
would return False there.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27609>
As the values depends on several values that can be dynamic too.
Note that the current approach of this commit is keeping this info
duplicated on the pipeline and the cmd_buffer. The alternative would
be to just track it at the cmd_buffer, like we did recently with
z_updates_enable, but getting the values for ez_state/incompatible_ez
were more complex, so this commit still computes it when the pipeline
is created, and uses it as default value.
This is debatable though, and the alternative would be to just keep
ez_state/incompatible_ez_state at the command buffer.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27609>
As it depends on values that could be dynamic now. Technically we
could try to keep pre-emitting, just in case that info is provided
statically.
But for the dynamic case, we would still need to compute that bits,
and we would need to discard all the pre-emitted CFG set, and
recompute it completely (as right now cl_emit_with_prepacked doesn't
allow to override values).
It is also gets a simpler code by setting those flags in only one
codepath.
As we are here, we also move z_updates_enable from the pipeline to the
cmd_buffer. This values doesn't require a complex compute, so it is
easier to just keep it on one place.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27609>
As with CmdSetViewport, we need to provide a custom implementation
because we want to call and save the outcome of viewport_compute_xform
when the viewport is set, not during emission.
We can just call v3dv_CmdSetViewport, as that one is already calling
vk_common_SetViewportWithCount.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27609>
Mostly equal to vkCmdBindVertexBuffers, but adding strides, that with
VK_EXT_extended_dynamic_state become dynamic, and setting pSizes.
It is worth to note that at this moment we don't use
CmdBindVertexBuffers2 pSizes.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27609>
Specifically to use the common vk_dynamic_graphics_state.
The advantage of using the common struct is not only reducing the size
of our custom one, but also using common helpers (like all those cmd
buffer setters), and a lot of the logic that in the future will be
used for other extensions.
Some notes:
* We still keep dirty flags, for things like PIPELINE,
DESCRIPTOR_SETS, etc. Other driver do the same. FWIW, this is also
an improvement, as before we were mixing those with the per-spec
Vulkan dynamic info.
* For the port viewport/scissor we still keep some data on a custom
structure, as we cache the translate/scale info that is derived
from scissor/viewport, but used in three different places.
For that we also maintain a custom implementation of
CmdSetViewport, that computes translate/scale, and call the common
implementation.
* We make the same for color_write_enables. The vulkan runtime saves
it as a 8-bit bitset, with a bit per attachment. But when combining
with color_write_mask you need a 32bit with 4 bits set per
attachment. To avoid recompute it during emission, we also cache
the color_write_enables, using the runtime just to track the dirty
status.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27609>
This array has 3 components, because it's meant to hold the X, Y and Z
components of the work-group size sysval. However, mir_pick_ubo assumes
vec4 for the push-uniforms, which ends up promoting this to 4
components.
So let's make sure we don't write that last component. It's not going to
do anything good.
In practice, this leads to the viewport descriptor being smashed, which
doesn't actually do any real-world harm, because this only happens in
compute batches where that descriptor is unused. However, writing
outside of arrays is undefined behavior, so we should fix it regardless.
Fixes: 5006167061 ("panfrost: Hook-up indirect dispatch support")
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28856>
Even if the pipeline is the same.
The followin sequence, used on
dEQP-VK.dynamic_state.*.double_static_bind tests, is valid:
1. Bind pipeline with some static state.
2. Set state command for that static state (to a bad value).
3. Bind the same pipeline again.
4. Draw.
So on 3 we need to ensure to load again the pipeline static state.
Fixes: dEQP-VK.dynamic_state.*.double_static_bind
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28897>
Some cards can do higher bitrate, but 1000 Mbit/s should be high enough
for any practical use. It's also the value that AMF reports as max bitrate.
Fixes: 54d499818c ("radv/video: add initial support for encoding with h264.")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28736>
Pending feedback resources (cmds, buffers, slots) for timeline semaphores are
generally reclaimed for re-use during subsequent semaphore waits/queries or any
queue submission containing at least one "wait" semaphore.
They are never reclaimed in the unexpected case when all submissions only
contain "signal" timeline semaphores, which consume such resources but
are never subsequently queried or waited upon.
This strange behavior is observed in several Valve games (Portal 2,
L4D2, CS2), which all run natively on linux with their own internal
distributions of DXVK v2.0 (at time of this MR submission). A Cursory
analysis of recent DXVK history indicates that it may be gone by v2.1.
The consequence is rapid guest memory leak and host Vk resource leak,
resulting in a crash within 1-2 minutes.
Fix that leak by running the reclaimation procedure for submissions with
_any_ accompanying semaphores.
Fixes: d63432012d ("venus: refactor semaphore feedback")
Signed-off-by: Ryan Neph <ryanneph@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28915>
There're many cases in which the ring submissions must succeed. We don't
worry about real oom since things would fail earlier. For simulated oom
from random intentional allocs, there isn't robust way to fail those
must succeeds. e.g. the commands that don't have return codes or valid
error return struct defaults. So real oom propagation is still at best
effort.
Cc: mesa-stable
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28914>
optimized pipeline compile jobs may still be ongoing during ctx
destroy, and these must complete too or else crashes will occur
fixes shutdown crash with dEQP-EGL.functional.sharing.gles2.multithread.simple.images.texture_source.teximage2d_render
cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28900>
it's possible for a shader to be precompiling its separate shader variants
during destruction, which requires that the programs set be iterated
under lock in order to prune every new variant as it is created without
crashing
fixes crashes in spec@arb_separate_shader_objects@400 combinations.*
cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28900>
Add vlVaDriver::has_external_handles and set it to true when external
handles are imported via VASurfaceAttribMemoryType or exported via
vaExportSurfaceHandle.
It will serve the same purpose as
gl_shared_state::HasExternallySharedImages does, but for va.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28771>
When texture-buffers are created from buffers that are larger than the
max-size, the correct thing to do is to clamp the size. Let's do that.
This fixes these piglits:
- spec/arb_texture_buffer_object/texture-buffer-size-clamp/r8ui_texture_buffer_size_via_sampler
- spec/arb_texture_buffer_object/texture-buffer-size-clamp/rg8ui_texture_buffer_size_via_sampler
- spec/arb_texture_buffer_object/texture-buffer-size-clamp/rgba8ui_texture_buffer_size_via_sampler
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28908>
It doesn't work for all models, with the same happening to the
proprietary driver. There may be some hardware limitation on at least
the HW that is currently supported in Mesa.
So match what the proprietary driver is doing and disable by default.
Fixes: d6473ce28e ("etnaviv: Use NN cores to accelerate convolutions")
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28918>
Each codec has its own size in the dec message,
for example: AVC has sizeof(rvcn_dec_message_avc_t) and
AV1 has sizeof(rvcn_dec_message_av1_t)
This patch will set the correct size for index_codec section
and set the total_size properly for the dec message header.
Signed-off-by: David (Ming Qiang) Wu <David.Wu3@amd.com>
Reviewed-by: Leo Liu <leo.liu@amd.com>
Reviewed-by: Boyuan Zhang <Boyuan.Zhang@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28886>
We access sysvals as if they were declared as a big struct containing
all the sysvals for all the stages in a pipeline. Declaring fields
as panvk_sysval_vec4 when we don't use all the components doesn't make
sense, so let's drop panvk_sysval_vec4 and declare exactly what we
need.
We also take this as an opportunity to split the graphics and compute
sysval structs.
Signed-off-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/28399>
broadcom-rpi4-fails
The arb_texture_view@rendering-formats test crash is caused by V3D not
supporting PIPE_FORMAT_{R16,R16G16,R16G16B16A16}_UNORM for rendering
so move the rendering-formats test to the appropriate section
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28862>
With float_controls2, shaders can decide on the behavior of
NaN/Inf/SignedZero preservation by decorating specific instructions, on
top of having a default for the whole program.
Add where to track these to nir_alu_instr and propagate them to new
instructions everywhere that exact is being done already.
v2: use less bits for fp_fast_math in nir_alu_instr (Alyssa)
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27281>
Align16 is only used on Gfx9, while Align1 is used on Gfx11+. We can
decode both kinds of encodings in the same function with a simple
devinfo check. One snag is that the align16 encodings didn't have a
separate exec_type field, but we can just pass 0.
This lets us have a single function named brw_type_decode_for_3src,
which is much less of a mouthful.
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28847>
In ancient days, we directly used the hardware register type encodings
throughout the compiler. As more GPU generations came out, encodings
shifted, and we moved to an abstract enum that we could encode/decode
to a particular GPU's hardware encoding. But there was no particular
meaning behind any particular value.
One downside to this approach is that we end up with switch statements
galore. Want to know a type's size? Switch. Convert a unsigned type
to a signed one? Switch. Get a type with the same base type, but
different bit size? Switch. This is both inefficient and inconvenient.
In contrast, nir_alu_type takes a nicer approach - the type encoding has
certain bits representing the base type, and others encoding the size of
the type. Switching base types or sizes is a simple matter of masking
out the relevant field and substituting a different one.
Tigerlake's encoding adopts a similar approach: two bits represent the
size as a 2-bit unsigned number n, where the bit size is (8 * 2^n).
Two more bits represent the base type. Past encodings were a bit ad hoc
as new data types were added over time, but Gfx12 is organized (mostly).
This patch converts our brw_reg_type enum over to a new system that's
patterned after the Tigerlake style (for easy conversion) while
deviating in a few ways that make our vector immediate type size
handling simpler. Should we add additional base types, we're likely
to continue deviating. Still, converting is much simpler.
Type size calculations (which are performed all the time) are now a
simple mask and shift, instead of a switch.
We also adopt the name BRW_TYPE_* instead of BRW_REGISTER_TYPE_* because
it's much shorter and easier to type. Similarly, we create new helper
functions named brw_type_* for working with these types, with a cleaner
naming convention. Legacy names still exist but will we dropped over
the next few patches as pieces get cleaned up.
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28847>
Icelake removed the PLN instruction for interpolating fragment shader
inputs, instead adding a special "Native Float" (NF) data type which
was a 66-bit floating point data type that could only be used with the
accumulator. On Tigerlake, they dropped NF support in favor of just
doing the interpolation with MAD instructions.
We stopped using NF years ago (commit 9ea90aae1e),
instead just using the fs_visitor::lower_linterp() pass to emit MADs.
Since this existed only for a short time, and had very limited utility,
we drop it from the compiler. One downside is that we can no longer
disassemble Icelake shaders containing NF types properly, but I doubt
anyone really minds.
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28847>
We were accidentally leaving XY_BLOCK_COPY_BLT's Source and Destination
MOCS fields set to 0 (Error: Reserved for Non-Use) on Gfx12.0 systems.
This was causing assert fails in debug builds, since we try to ensure
that we don't do that. In theory, MOCS 0 is supposed to be equivalent
to MOCS 2 (all the caching), but...we probably ought to use MOCS 3
(uncached). Every Gfx12.5+ platform requires it, so although there
isn't a note about Gfx12.0 needing that, it's possible that it does.
We're currently only using the blitter for DRI PRIME blits on Gfx12.0,
anyway, and I think we're flushing all the caches regardless.
This bug was somewhat obscure to hit:
- You need a hybrid graphics system with Gfx12.0 and some other GPU
- You have to be using "reverse PRIME", i.e. rendering on the integrated
GPU and displaying on the discrete one. This is not the common case.
- You have to be using a debug build.
No observable performance delta in GfxBench5 Car Chase (an arbitrary
program) when rendering on Alderlake GT1 and displaying on an Arc A770.
Fixes: 194afe8416 ("anv/iris/blorp: use the right MOCS values for each engine")
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Rohan Garg <rohan.garg@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28894>
This was missing and this caused test failures for formats different
than VK_FORMAT_R8_UINT which is the only one supported for FSR.
Fixes recent
dEQP-VK.api.info.unsupported_image_usage.*.fragment_shading_rate_attachment.*.
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28893>
@@ -30,7 +30,7 @@ For rendering errors, attach screenshots of the problem and (if possible) of how
- Backtrace (for crashes)
- Output of `dmesg`
- Hang reports: Run with `RADV_DEBUG=hang` and attach the files created in `$HOME/radv_dumps_*/`
- Hang reports: Follow the steps described [here](https://docs.mesa3d.org/drivers/amd/hang-debugging.html#radv-debug-hang) and attach the files created in `$HOME/radv_dumps_*/`.
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.
