The 'struct drm_amdgpu_cs_chunk_fence' is processed as
'struct drm_amdgpu_cs_chunk_data' which is a union.
This change ensures the proper alignment for this structure
to be processed as 'struct drm_amdgpu_cs_chunk_data'.
The presence of __u64 as one member of
'struct drm_amdgpu_cs_chunk_data' makes the
whole structure expected to be 64-bit aligned.
This is a minor issue detected by the gcc sanitizer (ubsan), for instance at the libdrm library:
../amdgpu/amdgpu_cs.c:937:26: runtime error: member access within misaligned address 0x63100001484c for type 'struct drm_amdgpu_cs_chunk_data', which requires 8 byte alignment
0x63100001484c: note: pointer points here
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
^
Fixes: ae7e4d7619 ("amd: rename ring_type --> amd_ip_type and match the kernel enum values")
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/22920>
(cherry picked from commit acdd6a2a6c)
if a sampler is never used (no derefs) then its binding will never be
applied here, leaving it with binding=0. this will clobber the real binding=0
sampler in driver backends, leading to errors, so try to iterate using
the same criteria as above and apply bindings in the same way
fixes#8974
cc: mesa-stable
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22902>
(cherry picked from commit ccbfcf3933)
the inner conditional here didn't include uncached readback, meaning
that many (most?) buffers allocated with uncached memory (i.e., BAR) were
being read back directly instead of using staging resources to be faster
at some point this inner conditional should be reevaluated to determine
whether it still does anything, but this is not that time
fixes, among other things, loading in DOOM2016 on some GPUs
Fixes: 52f27cda05 ("zink: allow direct memory mapping for any COHERENT+CACHED buffer")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22907>
(cherry picked from commit 24350064ca)
in the case where a cmdbuf was submitted with write access and the subsequent
batch promotes an op to unordered, it's important for associated barriers
to happen-before those ops to guarantee synchronization
the fixes tag is wrong on this, but it's all in the same release
Fixes: bf0af0f8ed ("zink: move all barrier-related functions to c++")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22907>
(cherry picked from commit 6452849b11)
Otherwise accesses to non-0 views of input attachments may be considered
out-of-bounds and return 0. This should've been removed when enabling
multiview for GMEM, not sure how it was missed.
Fixes: def56b531c ("tu: Support GMEM with layered rendering and multiview")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20304>
(cherry picked from commit f6902bf425)
We go to initialize the disk cache before we've compiled any shaders so
agx_compiler_debug is 0 at this point. Don't try to read it, instead go through
sa safe getter that will do the right thing.
Fixes: 5e9538c12e ("agx: isolate compiler debug flags")
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22891>
(cherry picked from commit e9b471d1b3)
With the following test :
dEQP-VK.spirv_assembly.instruction.terminate_invocation.terminate.no_out_of_bounds_load
There is a :
shader_start:
... <- no control flow
g0 = some_alu
g1 = fbl
g2 = broadcast g3, g1
g4 = get_buffer_size g2
... <- no control flow
halt <- on some lanes
g5 = send <surface>, g4
eliminate_find_live_channel will remove the fbl/broadcast because it
assumes lane0 is active at get_buffer_size :
shader_start:
... <- no control flow
g0 = some_alu
g4 = get_buffer_size g0
... <- no control flow
halt <- on some lanes
g5 = send <surface>, g4
But then the instruction scheduler will move the get_buffer_size after
the halt :
shader_start:
... <- no control flow
halt <- on some lanes
g0 = some_alu
g4 = get_buffer_size g0
g5 = send <surface>, g4
get_buffer_size pulls the surface index from lane0 in g0 which could
have been turned off by the halt and we end up accessing an invalid
surface handle.
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/20765>
(cherry picked from commit 9471ffa70a)
Fixes:
```
[829/1646] Compiling C object src/panfrost/vulkan/libpanvk_v6.a.p/panvk_vX_meta_clear.c.o
In function 'panvk_meta_clear_zs_img',
inlined from 'panvk_v6_CmdClearDepthStencilImage' at ../src/panfrost/vulkan/panvk_vX_meta_clear.c:457:7:
../src/panfrost/vulkan/panvk_vX_meta_clear.c:415:26: warning: storing the address of local variable 'view' in '((struct pan_fb_info *)((char *)commandBuffer + 144))[23].zs.view.zs' [-Wdangling-pointer=]
415 | fbinfo->zs.view.zs = &view;
| ~~~~~~~~~~~~~~~~~~~^~~~~~~
../src/panfrost/vulkan/panvk_vX_meta_clear.c: In function 'panvk_v6_CmdClearDepthStencilImage':
../src/panfrost/vulkan/panvk_vX_meta_clear.c:393:26: note: 'view' declared here
393 | struct pan_image_view view = {
| ^~~~
../src/panfrost/vulkan/panvk_vX_meta_clear.c:393:26: note: 'commandBuffer' declared here
[844/1646] Compiling C object src/panfrost/vulkan/libpanvk_v7.a.p/panvk_vX_meta_clear.c.o
In function 'panvk_meta_clear_zs_img',
inlined from 'panvk_v7_CmdClearDepthStencilImage' at ../src/panfrost/vulkan/panvk_vX_meta_clear.c:457:7:
../src/panfrost/vulkan/panvk_vX_meta_clear.c:415:26: warning: storing the address of local variable 'view' in '((struct pan_fb_info *)((char *)commandBuffer + 144))[23].zs.view.zs' [-Wdangling-pointer=]
415 | fbinfo->zs.view.zs = &view;
| ~~~~~~~~~~~~~~~~~~~^~~~~~~
../src/panfrost/vulkan/panvk_vX_meta_clear.c: In function 'panvk_v7_CmdClearDepthStencilImage':
../src/panfrost/vulkan/panvk_vX_meta_clear.c:393:26: note: 'view' declared here
393 | struct pan_image_view view = {
| ^~~~
../src/panfrost/vulkan/panvk_vX_meta_clear.c:393:26: note: 'commandBuffer' declared here
```
Cc: mesa-stable
Suggested-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: David Heidelberg <david.heidelberg@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22829>
(cherry picked from commit 2b4ce498ee)
../src/microsoft/vulkan/dzn_image.c: In function ‘dzn_GetImageMemoryRequirements2’:
../src/microsoft/vulkan/dzn_image.c:918:91: error: passing argument 6 of ‘dzn_ID3D12Device12_GetResourceAllocationInfo3’ from incompatible pointer type [-Werror=incompatible-pointer-types]
918 | &image->castable_format_count, &image->castable_formats,
| ^~~~~~~~~~~~~~~~~~~~~~~~
| |
| DXGI_FORMAT **
In file included from ../src/microsoft/vulkan/dzn_private.h:67,
from ../src/microsoft/vulkan/dzn_image.c:24:
../src/microsoft/vulkan/dzn_abi_helper.h:64:107: note: expected ‘const DXGI_FORMAT * const*’ but argument is of type ‘DXGI_FORMAT **’
64 | const UINT *num_castable_formats, const DXGI_FORMAT *const *castable_formats,
| ~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
ninja: build stopped: subcommand failed.
Fixes: 71dbb3120a ("dzn: Use GetResourceAllocationInfo3 for castable formats")
Signed-off-by: Eric Engestrom <eric@engestrom.ch>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22877>
(cherry picked from commit cb4e4fc5de)
These are unneeded. Events can't be used to indefinitely stall work
like you can with a semaphore or timeline semaphore. The signals
still need to happen so that execution will modify the state that
can be polled from the CPU though.
Fixes dEQP-VK.synchronization.basic.event.single_submit_multi_command_buffer
Fixes: 04fa6c71 ("dzn: Batch command lists together")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22842>
(cherry picked from commit be34257197)
with tc, query results can be fetched async, and it's impossible to
sync tc in this scenario. to avoid needing to sync when a sync is not
possible, sync ahead of time in all cases
Fixes: 7c96e98975 ("zink: always start/stop/resume queries inside renderpasses")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22827>
(cherry picked from commit 2e3ce614b9)
UE4's Vulkan backend uses vkCmdWriteTimestamp with TOP_OF_PIPE
to measure how long a workload took in the GPU Benchmark. This is wrong
and writes the timestamp before the workload is actually finished,
making it seem like the GPU is much faster than it actually is.
This caused subsequent benchmark passes to contain way too big workloads,
which caused soft hangs on slower GPUs.
Fixes GPU hangs with Splitgate during automatic settings configuration.
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22823>
(cherry picked from commit 0b251d4362)
This change makes usage bits verification closer to the Vulkan spec.
i.e. VK_IMAGE_CREATE_MUTABLE_FORMAT_BIT does not always require all formats
to support all the requested usage bits.
Also, VK_IMAGE_CREATE_EXTENDED_USAGE_BIT, when combined with
VK_IMAGE_CREATE_MUTABLE_FORMAT_BIT can relax the requirements for the
usage supported by the original image format.
v2: Removed strict verification of the format_list_info formats usage
per chadversary's suggestion. Other minor style/comments tweaks.
v3: Added checking of all compatible formats when
VK_IMAGE_CREATE_MUTABLE_FORMAT_BIT and VK_IMAGE_CREATE_EXTENDED_USAGE_BIT
are specified, but no list of possible formats was given.
v4: Add VK_IMAGE_CREATE_BLOCK_TEXEL_VIEW_COMPATIBLE_BIT handling.
Cc: 22.2 <mesa-stable>
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/6031
Signed-off-by: Sviatoslav Peleshko <sviatoslav.peleshko@globallogic.com>
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17182>
(cherry picked from commit 697ed61e7c)
This value depends on the per-sample value which can be unknown at
compile time with graphics pipeline libraries. So we need to have this
dynamic has well and pick the right value when generating the
3DSTATE_PS/3DSTATE_WM packet.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: d8dfd153c5 ("intel/fs: Make per-sample and coarse dispatch tri-state")
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22728>
(cherry picked from commit 5489033fa8)
Indeed, these references are not freed.
For instance, this issue is triggered on an evergreen card with
"piglit/bin/shader_runner tests/spec/arb_shader_atomic_counter_ops/execution/all_touch_test.shader_test -auto -fbo"
while setting GALLIUM_REFCNT_LOG=refcnt.log.
Fixes: 06993e4ee3 ("r600: add support for hw atomic counters. (v3)")
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/22798>
(cherry picked from commit 4ca8be82d5)
Indeed, the objects are not freed when the function returns NULL.
"psurf->texture = tex;" is redundant with
"pipe_resource_reference(&psurf->texture, tex);".
For instance, this issue is triggered with
"piglit/bin/ext_texture_array-compressed teximage pbo -fbo -auto"
while setting GALLIUM_REFCNT_LOG=refcnt.log.
Fixes: f3630548f1 ("crocus: initial gallium driver for Intel gfx 4-7")
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22799>
(cherry picked from commit d615dfca40)
We track fences in a global list and have a per context "current" fence
which we randomly attach things to. If we take such a fence and emit it
without also creating a new fence for future tasks we can get out of sync
leading to random failures.
Some of our queries could trigger such cases and even though this issues
appears to be triggered by the MT rework, I'm convinced that this was only
made more visible by those fixes and we had this bug lurking for quite a
while.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/7429
Fixes: df0a4d02f2 ("nvc0: make state handling race free")
Signed-off-by: Karol Herbst <git@karolherbst.de>
Acked-by: M Henning <drawoc@darkrefraction.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22722>
(cherry picked from commit 37c6c5c624)
It might happen that a raw data object (from pipeline cache creation)
was never looked up, and thus never deserialized, before it gets
inserted again into the cache. In this case, the deserialized object
got replaced by the raw data object.
Instead, replace the raw data object with the real object in the cache.
Fixes: 8b13ee75ba ('vulkan: Fall back to raw data objects when deserializing if ops == NULL')
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22735>
(cherry picked from commit cbab396f54)
The Vulkan spec says:
"If the depth clamping state is changed dynamically, and the pipeline
was not created with VK_DYNAMIC_STATE_DEPTH_CLIP_ENABLE_EXT enabled,
then depth clipping is enabled when depth clamping is disabled and
vice versa"
Fixes: e48c0fbd8f ("radv: add support for dynamic depth clamp enable")
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22777>
(cherry picked from commit e25e4c81de)
Commit f9a074dd55 ("dri2/android: Bypass throttling") dropped
unnecessary throtting in the SwapBuffers() path for android. But
unfortunately MSAA resolve got tangled up in the throttle reason
flag. So add a new flag that indicates "no throttingling, but yes
please do MSAA resolve".
Fixes: f9a074dd55 ("dri2/android: Bypass throttling")
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22719>
(cherry picked from commit 08ffa8e0d2)
Indeed, the hardcoded framebuffer cleanup doesn't handle "resolve".
For instance, this issue is triggered with "piglit/bin/glx-copy-sub-buffer -samples=2 -auto"
while setting GALLIUM_REFCNT_LOG=refcnt.log.
Fixes: f5bde99cbd ("gallium: plumb resolve attachments through from frontends -> pipe_framebuffer_state")
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22554>
(cherry picked from commit c39a2d67ea)
0: KIL -none.1111
Negate is not allowed for texturing opcodes, so the incorrect swizzle
was detected, however later optimization, where we try to rewrite incorrect
swizzles from constant (immediate) registers by adding a new ones with
correct order was interfering and not handling this correctly, so we
ended with
CONST[0] = { -1.0000 -1.0000 -1.0000 -1.0000 }
0: KIL const[0].xyz-w;
Even if it would get the swizzle right, texturing opcodes can't read from
constant registers, so just skip it and let this be handled by a later
part which inserts an extra mov instead.
Signed-off-by: Pavel Ondračka <pavel.ondracka@gmail.com>
Reviewed-by: Filip Gawin <filip@gawin.net>
Fixes: a8e1e5b5c2
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22704>
(cherry picked from commit db6c3cd13d)
Instead of forcing vertex buffer stride to be 4 byte aligned only,
DX10 actually allows the stride to be non 4-byte aligned but the
alignment of an element must be the nearest power of 2 greater or equal to the
width of the element's format, or 4, whichever is less. So the requirement is
better met with PIPE_CAP_VERTEX_ATTRIB_ELEMENT_ALIGNED_ONLY which if set to
TRUE, the sum of vertex element offset + vertex buffer offset + vertex buffer
stride must be aligned to the vertex attributes component size.
Note: PIPE_CAP_VERTEX_ATTRIB_ELEMENT_ALIGNED_ONLY cannot be set
with other alignment-requiring CAPs, so we have to return 0 for all the
other alignement CAPs.
This avoids some unnecessary software vertex translate fallback.
cc: mesa-stable
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22689>
(cherry picked from commit c661f38342)
Indeed, the function nir_to_tgsi() returns an ureg_get_tokens() allocated
object which is assigned locally. The ureg_get_tokens() allocated object
should be freed.
For instance, this issue is triggered with a llvm enabled lima,
"piglit/bin/gl-1.0-rendermode-feedback -auto -fbo":
Direct leak of 512 byte(s) in 1 object(s) allocated from:
#0 0x7faeaa4500 in __interceptor_realloc (/usr/lib64/libasan.so.6+0xa4500)
#1 0x7fa4a88f1c in tokens_expand ../src/gallium/auxiliary/tgsi/tgsi_ureg.c:239
#2 0x7fa4a88f1c in get_tokens ../src/gallium/auxiliary/tgsi/tgsi_ureg.c:262
#3 0x7fa4a900f4 in copy_instructions ../src/gallium/auxiliary/tgsi/tgsi_ureg.c:2079
#4 0x7fa4a900f4 in ureg_finalize ../src/gallium/auxiliary/tgsi/tgsi_ureg.c:2129
#5 0x7fa4a91dfc in ureg_get_tokens ../src/gallium/auxiliary/tgsi/tgsi_ureg.c:2206
#6 0x7fa4b20a2c in nir_to_tgsi_options ../src/gallium/auxiliary/nir/nir_to_tgsi.c:4011
#7 0x7fa4a0c914 in draw_create_vertex_shader ../src/gallium/auxiliary/draw/draw_vs.c:77
Fixes: b5e782f5f4 ("aux/draw: use nir_to_tgsi for draw shader in llvm path")
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21924>
(cherry picked from commit 6a8e6716ac)
We can now no longer rely on certain dirty bits to re-trigger draw time
resource tracking. We need to use the new fd_dirty*_resource() APIs.
Fixes `org.skia.skqp.SkQPRunner#gles_recordopts` on android 9.
Fixes: 0a62a874fc ("freedreno: Re-work dirty-resource tracking")
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22683>
(cherry picked from commit d437e389e0)
Previously it was assumed that between the and the variable there was
only one deref.
To handle all cases a new function is introduced that recreates a chain
of derefs.
Fixes: 5a4083349f ("zink: add provoking vertex mode lowering")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22678>
(cherry picked from commit 39770c6503)
The first attempt at the sprintf would have consumed part of va, so if
we're going to recurse on overflow to try again in a new allocation then
we have to do our work on a copy.
This was a common failure mode for MESA_GLSL=source, where it would just print:
Mesa: info: GLSL source for fragment shader 1:
Mesa: info: (null)
Fixes: 7a18a1712a ("util/log: improve logger_file newline handling")
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22618>
(cherry picked from commit 7f99cbf25e)
The VK pipeline cache passes a NULL bytes with a nonzero size to a
NULL-data blob to set up the size of the blob. In this case, we don't
actually execute the memcpy, so the non-existent "bytes" doesn't need to
have defined contents. Avoids a valgrind warning:
==972858== Unaddressable byte(s) found during client check request
==972858== at 0x147F4166: blob_write_bytes (blob.c:165)
==972858== by 0x147F4166: blob_write_bytes (blob.c:158)
==972858== by 0x14695FFF: vk_pipeline_cache_object_serialize (vk_pipeline_cache.c:240)
[...]
==972858== Address 0x0 is not stack'd, malloc'd or (recently) free'd
Fixes: 591da98779 ("vulkan: Add a common VkPipelineCache implementation")
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22617>
(cherry picked from commit ae2784b832)
Before testing the waddr for SFU we should first validate this
is indeed a valid (not NOP) magic write. Use the helper we have for
this which gets this right.
total instructions in shared programs: 12898957 -> 12850958 (-0.37%)
instructions in affected programs: 4328937 -> 4280938 (-1.11%)
helped: 19974
HURT: 439
Instructions are helped.
total max-temps in shared programs: 2211503 -> 2210893 (-0.03%)
max-temps in affected programs: 12924 -> 12314 (-4.72%)
helped: 509
HURT: 20
Max-temps are helped.
total sfu-stalls in shared programs: 22233 -> 21975 (-1.16%)
sfu-stalls in affected programs: 722 -> 464 (-35.73%)
helped: 297
HURT: 54
Sfu-stalls are helped.
total inst-and-stalls in shared programs: 12921190 -> 12872933 (-0.37%)
inst-and-stalls in affected programs: 4337977 -> 4289720 (-1.11%)
helped: 20015
HURT: 404
Inst-and-stalls are helped.
total nops in shared programs: 333743 -> 305911 (-8.34%)
nops in affected programs: 86902 -> 59070 (-32.03%)
helped: 14545
HURT: 76
Nops are helped.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22593>
(cherry picked from commit 18a3a0d915)
Previously, whenever a vertex was emitted immediately after emitting a
primitive, that vertex would not use the attributes that where assigned
last because the position variable got set.
Now the temporary attributes array is treated as a ring buffer and
whenever the position is set to 0 it's previous value is used as an
offset when accessing it. This way when a new primitive is created the
attributes at index 0 correspond to the last attributes written.
Fixes: 5a4083349f ("zink: add provoking vertex mode lowering")
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22599>
(cherry picked from commit 89077b866c)
otherwise the pool is freed before the query and zink will
give the vulkan driver NULL query pool which can make it crash.
this was seen when running the following cases with
primitivesGeneratedQueryWithRasterizerDiscard and color write
features disabled:
dEQP-GL45.functional.tessellation.invariance.outer_triangle_set.triangles_fractional_odd_spacing
dEQP-GL45.functional.tessellation.invariance.outer_triangle_set.triangles_fractional_even_spacing
dEQP-GL45.functional.tessellation.invariance.outer_triangle_set.quads_equal_spacing
dEQP-GL45.functional.tessellation.invariance.outer_triangle_set.quads_fractional_odd_spacing
dEQP-GL45.functional.tessellation.invariance.outer_triangle_set.quads_fractional_even_spacing
dEQP-GL45.functional.tessellation.invariance.tess_coord_component_range.triangles_equal_spacing_ccw
dEQP-GL45.functional.tessellation.invariance.tess_coord_component_range.triangles_equal_spacing_ccw_point_mode
dEQP-GL45.functional.tessellation.invariance.tess_coord_component_range.triangles_equal_spacing_cw
dEQP-GL45.functional.tessellation.invariance.tess_coord_component_range.triangles_equal_spacing_cw_point_mode
dEQP-GL45.functional.tessellation.invariance.tess_coord_component_range.triangles_fractional_odd_spacing_ccw
dEQP-GL45.functional.tessellation.invariance.tess_coord_component_range.triangles_fractional_odd_spacing_ccw_point_mode
dEQP-GL45.functional.tessellation.invariance.tess_coord_component_range.triangles_fractional_odd_spacing_cw
dEQP-GL45.functional.tessellation.invariance.tess_coord_component_range.triangles_fractional_odd_spacing_cw_point_mode
dEQP-GL45.functional.tessellation.invariance.tess_coord_component_range.triangles_fractional_even_spacing_ccw
dEQP-GL45.functional.tessellation.invariance.tess_coord_component_range.triangles_fractional_even_spacing_ccw_point_mode
Fixes: e5d517f362 ("zink: rework query pool overflow")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22575>
(cherry picked from commit 3291050cc1)
Initially this was just adding a missing popd, but actually there's no
reason to pushd into the build dir, so let's just pass the build dir as
arguments to cmake & ninja instead.
`--arch x64` was also dropped as it only applies to Windows builds,
which this script doesn't support anyway.
Fixes: 512f1c160a ("ci/zink: Add coverage using the vulkan validation layer on lvp.")
Signed-off-by: Eric Engestrom <eric@igalia.com>
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22488>
(cherry picked from commit 3c64f3dcbc)
This is really noticeable for games that resolve a bunch of occlusion
queries (in this case 4096) because it seems that emitting 4096
WAIT_REG_MEM packets can stall more than expected. Fixes this by
waiting for queries in the resolve query shader.
This improves performance of an unreleased game by +~10% (71->78 FPS).
RADV should now be really close to Windows performance for that title.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22630>
Previously, continue preambles and postambles were added directly to
the CS array which means all BOs were correctly added to the BO list,
and this has been broken recently. IB BOs need to be added to the list.
When a BO isn't added to the list as part of a submission, it might
randomly VM faults.
This fixes VM faults and random GPU hangs on NAVI21 in Mesa CI.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/8849
Fixes: 41a9bced31 ("radv: Fill continue preambles and postambles properly.")
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22625>
(cherry picked from commit 84d8ea6e2b)
For MTL (verx10 == 125), float64 is supported, but int64 is not.
Therefore we need to lower cluster broadcast using 32-bit int ops.
For gfx12.5+ platforms that support int64, the register regions
used by cluster broadcast aren't supported by the 64-bit pipeline.
On MTL, dEQP-VK.subgroups.clustered.*_double* and
dEQP-VK.subgroups.clustered.*_dvec* were failing to validate the
compiled shader in debug mode, and reportedly gpu-hanging in release
mode.
With this change dEQP-VK.subgroups.clustered.*_double* passed all 48
tests and dEQP-VK.subgroups.clustered.*_dvec* passed all 140 tests on
MTL.
Rework:
* Move from generator to brw_fs_lower_regioning.cpp. (Suggested by
Francisco)
* Apply to verx10 >= 125.. (Suggested by Francisco)
Cc: 23.1 <mesa-stable>
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Marcin Ślusarz <marcin.slusarz@intel.com> (v1)
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22569>
(cherry picked from commit fcb72ffd0c)
So far we were only considering the number of vertices to draw to
compute the offset in a stream output buffer.
But this is not correct, as it depends on the primitive type too. For
instance, with 4 vertices, if we use a triangle strip primitive, then 2
triangles are generated from those 4 vertices, so 6 vertices will be
captured.
This fixes spec@!opengl es
3.0@gles-3.0-transform-feedback-uniform-buffer-object.
CC: 23.1
Reviewed-by: Emma Anholt <emma@anholt.net>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22607>
(cherry picked from commit a86d18a8c4)
It appears to be possible that IDLE is observed before COMPLETE.
In this case, an application may access present_id in subsequent
QueuePresentKHR and race against the fence worker reading present_id.
Solve this by adding a separate signal_present_id that is used when
completing to avoid the race.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
Reviewed-by: Adam Jackson <ajax@redhat.com>
(cherry picked from commit 32f7ff2c20)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22637>
The buffer max_index value in translate_generic struct is relevant for
indexed draw only. So do not clamp the element index in generic_run() as it
is called for non-indexed draw only.
This patch passes index_size to the common generic_run_one function
so index clamping is only performed when a non-zero index_size is specified.
This fixes a text selection bug with kitty terminal emulator running on ARM
when it falls back to the generic translate path for unsigned byte vertex
array.
cc: mesa-stable
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22568>
(cherry picked from commit 13e885842a)
if an attachment other than the msrtss blit attachment has clears pending,
unbinding the other attachment will trigger a clear flush, which will then
recurse into the msrtss blit that's being triggered
instead, save/restore these clears around the msrtss blit since they
can be executed during the normal renderpass
(cherry picked from commit 82add9f2e9)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22598>
with the new zsbuf elimination handling, the fb state calculated in
u_blitter's fb restore may be incorrect if the zsbuf has indeed been
eliminated, so ensure the right fb is stored to be reapplied so that
misrenders will be avoided
fixes some crashes/misrenders in webgl
(cherry picked from commit ec0860b401)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22598>
To implement some of the features of the layer, we need to enable some
of the feature bits at device/command_buffer creation. To do so, we
need to edit some of the structures coming from the application. Most
of those are const so we need to clone them before edition.
This change disables some of the layer features if we run into a
situation where one of the structure we need to clone is unknown such
that we can't make a copy of it (since we don't know its size).
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/7677
Cc: mesa-stable
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19897>
(cherry picked from commit b30a75a195)
Indeed, the reference was overwritten.
For instance, this issue is triggered with:
"piglit/bin/shader_runner tests/spec/arb_shader_image_load_store/execution/write-to-rendered-image.shader_test -auto -fbo"
while setting GALLIUM_REFCNT_LOG=refcnt.log.
Fixes: a6b3792843 ("r600: add core pieces of image support.")
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22394>
(cherry picked from commit 4f42d3b843)
This is the analogous of
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9490 but for
r600.
Discoloration of NV12 video frames was observed in Chrome/ChromeOS and
the problem was tracked down to the fact that Mesa was following the
PIPE_FORMAT_R8_G8B8_420_UNORM/lower_yuv_external() path. The symptom is
that (for an unknown reason) the YUV-to-RGB conversion is using the
value of Y as the value of Y, U, and V. So, for example, if the input
value is YUV = (50, 120, 130), then what actually gets converted to RGB
is YUV = (50, 50, 50).
Considering that PIPE_FORMAT_R8_G8B8_420_UNORM was introduced for
freedreno
(https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6693) and it
is already being reported as unsupported for radeonsi, it's reasonable
to assume that GPUs targeted by r600 don't support this path either.
Note: I tested this patch with an AMD Palm device which follows the
evergreen_is_format_supported() path. I did not have access to a device
to test the r600_is_format_supported() path.
v2: Changed >= 2 to > 1.
Fixes: 826a10255f ("st/mesa: Add NV12 lowering to PIPE_FORMAT_R8_G8B8_420_UNORM")
Tested-by: Andres Calderon Jaramillo <andrescj@chromium.org>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22511>
(cherry picked from commit 4405e8a9e1)
previously there was a fallback path here (broken by f6d3a5755f)
which would attempt to demote BAR allocations to other heaps on failure
to avoid oom
this was great, but it's not the most robust solution, which is to iterate
all the memory types matching the given heap and try them in addition to having
a demotion fallback
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22567>
This fixes some CTS compiler tests where they relied on the cl_kernel
object to be released in time so it can recompile a program without
throwing CL_INVALID_OPERATION due to still having active kernel objects.
Fixes: 47a80d7ff4 ("rusticl/event: proper eventing support")
Signed-off-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22510>
(cherry picked from commit 60cfe15d79)
For instance, this issue is triggered with: "piglit/bin/useprogram-flushverts-2 -auto -fbo" or
"piglit/bin/primitive-restart-draw-mode line_loop -auto"
while setting GALLIUM_REFCNT_LOG=refcnt.log.
Fixes: 27dcb46629 ("gallium: add take_ownership param into set_vertex_buffers to eliminate atomics")
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22395>
(cherry picked from commit 28cb33fada)
With the on_demand shaders feature, meta pipelines are only created
when they are used, otherwise they are NULL. Though, inside secondary
cmdbuffers, the graphics pipeline might be also NULL. In this specific
case, radv_is_{dcc,fmask}_decompress_pipeline() would return
TRUE because these pipelines are NULL too...
This fixes flakes with tests that use secondary cmdbuffers with
TC-compat images.
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22440>
(cherry picked from commit 0b4e7491f3)
This feature is supported, but enabling it accidentally enables
OpenGL 3.0 & 3.1, which are not supported.
The feature is enabled in main and discussion to fix the issue is
underway, but we're disabling it in releases until we find a better
solution.
Signed-off-by: Eric Engestrom <eric@igalia.com>
Reviewed-by: Juan A. Suarez <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22260>
2023-04-13 23:16:11 +01:00
5272 changed files with 323720 additions and 735518 deletions
# Bring artifacts back from the NFS dir to the build dir where gitlab-runner
# will look for them.
cp -Rp /nfs/results/. results/
if[ -f "${STRUCTURED_LOG_FILE}"];then
cp -p ${STRUCTURED_LOG_FILE} results/
echo"Structured log file is available at https://${CI_PROJECT_ROOT_NAMESPACE}.pages.freedesktop.org/-/${CI_PROJECT_NAME}/-/jobs/${CI_JOB_ID}/artifacts/results/${STRUCTURED_LOG_FILE}"
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
