Disable aysnc mapping in case we are updating a external memobj.
Fixes following Piglit tests:
spec@ext_external_objects@vk-pix-buf-update-errors
spec@ext_external_objects@vk-vert-buf-update-errors
Cc: mesa-stable
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29303>
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>
Latency is hooked up to a new winsys framebuffer interface method. Swap
interval replaces the previous environment variable. This does make the
environment variable lowercase but that seems worth the break to be able
to set it from driconf.
Reviewed-By: Sil Vilerino <sivileri@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31157>
The check function will free the db or the file if the other is NULL,
however, in this case db and the file are passed to foz_destroy, which
will also free them. This results in a double free. Instead, check that
either is NULL, and then goto the error case to ensure proper cleanup.
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29881>
What we actually want here is the size of the 1/2/3D part of the level,
not the array part. This means a little more code duplication but the
result is also way more clear. This shouldn't be a functional change as
Extent4D<units::Bytes>::size_B() doesn't take array_len into account.
This means we no longer call Image::level_size_B() for layout. Instead,
Image::level_size_B() should mirror this code.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31191>
Most of our visitors have custom destructors because they wrap C types,
and need to manually call destructors for those types. Because of this,
the implicitly generated copy constructors and copy-assignment operators
are not safe due copying pointers rather than data. Since we don't need
these features just delete them, so any attempt to use them would be a
compilation error. This doesn't fix any existing issue except stopping
coverity from complaining, but it does prevent new issues in the future.
Acked-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29662>
To keep the rule-of-three. This points out that the implicit copy
operations would be dangerous when there is an explicit constructor and
destructor, since the class is holding un-managed memory.
Acked-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29667>
We have a couple of checks where we allow this to be NULL, but later we
unconditionally and unavoidably dereference the pointer, which means
there's no way that it ever could have been NULL. Change the assert at
the top to not allow NULL, and remove checks for it being NULL
CID: 1616544
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31156>
Our array has a fixed size of 32, and we know at the start of the block
that our type_count is < 32, but in the loop we grow the block, in
theory up to 31 times. Coverity notes that, and points out we could
write off the end of the array. Add an assert in the loop to ensure we
don't, and to help Coverity out.
CID: 1615171
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31173>
As coverity points out, if the second uint64_t was greater than the
first (I don't think it actually can be), then the overflow would result
in the check succeeding when it shouldn't. We could cast this to an
integer type, but since we have uint64_t, we'd need int128_t for that.
Instead, replace the comparison to 0 with a direct comparison, since
that would give the correct result without potential to overflow.
CID: 1604833
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31175>
The extension only affects non semantic instructions that need no
handling in the backend compiler.
Signed-off-by: Rohan Garg <rohan.garg@intel.com>
Acked-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30791>
The extension only affects non semantic instructions that need no
handling in the backend compiler.
Signed-off-by: Rohan Garg <rohan.garg@intel.com>
Acked-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30791>
The extension only affects non semantic instructions that need no
handling in the backend compiler.
Signed-off-by: Rohan Garg <rohan.garg@intel.com>
Acked-by: Connor Abbott <cwabbott0@gmail.com>
Acked-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30791>
The extension only affects non semantic instructions that need no
handling in the backend compiler.
Signed-off-by: Rohan Garg <rohan.garg@intel.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Acked-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30791>
The extension only affects non semantic instructions that need no
handling in the backend compiler.
Signed-off-by: Rohan Garg <rohan.garg@intel.com>
Acked-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30791>
The extension only affects non semantic instructions that need no
handling in the backend compiler.
Signed-off-by: Rohan Garg <rohan.garg@intel.com>
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Acked-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30791>
VK_KHR_pipeline_binary allows the application to take full control on
the cache and internal caches (disk or in-memory) can be disabled.
Though the shader hash should still be computed, otherwise all pipeline
binaries have a key with all zeroes.
Fixes: 8802612458 ("radv: advertise VK_KHR_pipeline_binary"
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31163>
Otherwise, if a pipeline is found in cache it will use a different
shader arena for allocation and the capture replay shader group handles
won't match.
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31188>
There's nothing in spec that says that key is only written
if data is also written.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
Fixes: be06bfcbed ("radv: add initial support for pipeline binaries")
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31162>
This fix doesn't concern CDNA based chips such as gfx940 directly
but it fixes corruptions on other chips that use emulated image
loads and stores using buffers when AMD_IMAGE_OPCODES=false.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30891>
The expected PIPE_INTERLEAVE_BYTES size is ADDR_PIPEINTERLEAVE_256B on
gfx940 (or other CDNA based chips). Since CDNA based chips like gfx940
doesn't support image opcodes, it gets gibberish value from the kernel.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30891>
This is useless and causes hangs (eg: with Firefox).
Instead use a custom emit function for the sqtt state, and
add the pipeline BO to the buffer list at this point.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31171>
This was only a best effort fallback and it doesn't always work.
Driver is expected to only output slice NALs when packed headers
are not enabled, so let's just do that.
Reviewed-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31126>
Some apps would default to smaller resolutions than we currently report
as supported, despite the hardware being able to encode it. It's also
common for test apps/suites to use small resolutions.
libva-utils/h264encode uses 176x144 resolution by default and vulkan cts
have video clips with the same resolution too which would previously
fail to encode.
Reviewed-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31109>
We want barriers to only consider compute as a possibility, and CP DMA
has to work with that, which means barriers can't have code specific
to CP DMA.
Always executing the CP DMA sync seems acceptable because CP DMA operations
are usually small, and CP DMA is almost never used on GFX10+.
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31168>
This makes the CP DMA code simpler and reuses the logic we use for internal
compute shaders.
The only thing that can't be handled in the barrier functions is
"!cp_dma_has_L2 -> SI_CONTEXT_INV_L2" because the barrier functions should
assume that only compute shader coherency is required to make them usable
everywhere, and the CP DMA code has to deal with it.
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31168>
