To get an useful UUID for systems that have a non-useful mtime
for the binaries.
I started using SHA1 to ensure we get reasonable mixing in the
various possibilities and the various build id lengths.
CC: <mesa-stable@lists.freedesktop.org>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
(cherry picked from commit d17443a459)
Apparently for compute there are only 16 instead of the 32 for the
graphics path.
Fixes dEQP-VK.binding_model.descriptorset_random.sets16.noarray.ubolimitlow.sbolimitlow.imglimitlow.noiub.comp.0
CC: <mesa-stable@lists.freedesktop.org>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
(cherry picked from commit 0dd8189f15)
Otherwise using 32 user SGPRs would be broken.
CC: <mesa-stable@lists.freedesktop.org>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
(cherry picked from commit d97c892584)
Indirect descriptors only need one entry, we don't have to
emit a location for every descriptors.
Fixes GPU hangs with new CTS:
dEQP-VK.binding_model.descriptorset_random.*
CC: 18.2 <mesa-stable@lists.freedesktop.org>
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
(cherry picked from commit 9de062ef20)
Let say, we first bind a graphics pipeline that needs indirect
descriptors sets. The userdata pointers will be emitted at draw
time. Then if we bind a compute pipeline that doesn't need any
indirect descriptors, the driver will re-emit them for all
grpahics stages.
To avoid this to happen, just check the bind point type.
CC: 18.2 <mesa-stable@lists.freedesktop.org>
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
(cherry picked from commit 748f4cce18)
This was wrong for descriptor #0 when all of them are indirect.
This is because indirect_offset was 0 and we emitted a
"normal" descriptor pointer for nothing.
While we are at it remove
radv_userdata_info::indirect_offset which is useless.
CC: 18.2 <mesa-stable@lists.freedesktop.org>
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
(cherry picked from commit aa30205929)
Bumping to 64 should be safe enough.
Fixes some crashes with new CTS:
dEQP-VK.binding_model.descriptorset_random.*
CC: 18.2 <mesa-stable@lists.freedesktop.org>
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
(cherry picked from commit b9f6521157)
It's actually just the opposite.
This fixes the new Sascha conditionalrender demo.
CC: 18.2 <mesa-stable@lists.freedesktop.org>
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
(cherry picked from commit abdf396cbe)
Otherwise they are not exported.
CC: 18.2 <mesa-stable@lists.freedesktop.org>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Reviewed-by: Dave Airlie <airlied@redhat.com
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
(cherry picked from commit d4bf954fe6)
Mirrors
1e40f69483 "ac/surface: fix CMASK fast clear for NPOT textures with mipmapping on SI/CI/VI"
CC: <mesa-stable@lists.freedesktop.org>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
(cherry picked from commit 233718a199)
No clue what gets fixed by this but both radeonsi and amdvlk do it.
CC: <mesa-stable@lists.freedesktop.org>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
(cherry picked from commit ab64891f4c)
Just mirror the radeonsi bits. Since this is just adding the extra
switch entries for new HW I think this should be fine for stable.
CC: <mesa-stable@lists.freedesktop.org>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
(cherry picked from commit 4dc244eb44)
CTS doesn't test input clip/cull distances for the fragment
shader stage, which explains why this was totally broken. I
wrote a simple test locally that works now.
This fixes a crash with GTA V and DXVK.
Note that we are exporting unused parameters from the vertex
shader now, but this can't be optimized easily because we don't
keep the fragment shader info...
Cc: mesa-stable@lists.freedesktop.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107477
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
(cherry picked from commit 6f47df3129)
While adding transfer queues to radv, I started writing some tests,
the first test I wrote fell over copying a buffer larger than this
limit.
Checked AMDVLK and found the correct limit.
Cc: <mesa-stable@lists.freedesktop.org>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
(cherry picked from commit 2c1f249f2b)
This fixes VM faults and corruption.
Cc: 18.1 18.2 <mesa-stable@lists.freedesktop.org>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
(cherry picked from commit 1e40f69483)
Thanks to reproducible builds, binary file timestamps may be identical
for both 32bit and 64bit packages when built from the same source.
This means radv will use the same cache for both 32 and 64 bit
processes, which leads to crashes.
Conveniently there is a spare byte in cache_uuid, let's place the
pointer size there.
Fixes: f4e499ec79 "radv: add initial non-conformant radv vulkan driver"
CC: 18.1 18.2 <mesa-stable@lists.freedesktop.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107601
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105904
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
(cherry picked from commit 356f6673d6)
This fixes a crash in build_tex_intrinsic() when trying to
launch the Basemark GPU benchmark on GFX8. It looks like
there is still something wrong because some frames are black.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106980
CC: 18.2 <mesa-stable@lists.freedesktop.org>
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
(cherry picked from commit 4c43ec461d)
Otherwise, nir_lower_clip_cull_distance_arrays might report
wrong number of output clips/culls because it relies on
shader output variables and some of them might be dead.
This fixes a rendering issue with Dolphin and Super Mario
Sunshine.
Fixes: b0c643d8f5 ("spirv: Use NIR per-member splitting")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107610
CC: 18.2 <mesa-stable@lists.freedesktop.org>
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
(cherry picked from commit 24ee53231d)
it causes corruption on several different GPU generations.
Cc: 18.2 <mesa-stable@lists.freedesktop.org>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
(cherry picked from commit a4a104fc81)
This fixes a regression with some Unity demos. Not sure
what the root cause of the problem is, especially because
the driver doesn't perform any fast color clears. So, it
shouldn't be needed to decompress DCC. RadeonSI says that
the decompression is relatively cheap if the surface has
been decompressed already.
One possible improvement is to two use predicates, one for
DCC and one for FCE that could be cleared when DCC, FMASK
or CMASK are performed by the driver. That might skip some
unnecessary decompression passes (not DCC though).
Fixes: ff7daadca1 ("radv: enable/disable predication for the DCC decompression pass")
CC: 18.2 <mesa-stable@lists.freedesktop.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107563
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
(cherry picked from commit 0aacb5eab6)
When the number of unique BO is 0, we optimize the list creation
by copying all buffers of the current CS directly into it. But
this is only valid if the CS doesn't have virtual buffers,
otherwise they are not added and hw might report VM faults.
This fixes VM faults with:
dEQP-VK.sparse_resources.image_sparse_binding.2d.rgba8ui.1024_128_1
CC: <mesa-stable@lists.freedesktop.org>
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
(cherry picked from commit d27e1584ce)
We have to do a fast-clear eliminate when clearing DCC
metadata with 0x20202020. I don't know if that fixes anything
but that seems correct to me.
CC: 18.2 <mesa-stable@lists.freedesktop.org>
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
(cherry picked from commit f9e8456c39)
This was missing when VK_EXT_conditional_rendering has been
implemented. The predication type should be -1 to avoid
restoring previous state when performing a decompression pass
with DCC enabled.
Note that we don't have to handle secondary command buffers
because we don't support this feature currently.
CC: 18.2 <mesa-stable@lists.freedesktop.org>
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
(cherry picked from commit f3a78a9da0)
Seems like DXVK depends on that and it might get reverted
upstream. Since apps are not supposed to use 0 in v2 anyway,
we should be safe implementing the old behavior there.
Fixes: 66e12451ac "radv: Update to new VK_EXT_vertex_attribute_divisor to version 2."
CC: 18.2 <mesa-stable@lists.freedesktop.org>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
(cherry picked from commit 011a811652)
Cc: <mesa-stable@lists.freedesktop.org>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
(cherry picked from commit f0a8accb0d)
This option allows us to remove additional s_waitcnt instructions
because s_barrier internally does s_waitcnt 0.
Though, apparently there is a problem with LDS accesses that
causes rendering issues with FFXV and DXVK. Disable this
optimization for now (RadeonSI still uses it).
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107460
CC: 18.2 <mesa-stable@lists.freedesktop.org>
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
(cherry picked from commit 71d5b2fbf8)
Follow radeonsi.
Fixes: 3665f66ef2 "radv: Add support for ETC2 textures."
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
(cherry picked from commit 4bb6c49375)
Behavior wrt firstInstance got changed, and a divisor of 0 has been
disallowed.
The new version of the ext got published in specification 1.1.81.
Sending to stable since the only known user is DXVK, which needs
this for correctness.
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
CC: 18.2 <mesa-stable@lists.freedesktop.org>
(cherry picked from commit 66e12451ac)
A problem was reported with arm,arm64 targets build due to missing
libLLVM shared library dependency with AOSP; to avoid this issue vulkan.radv
is built conditionally only when radeonsi is in BOARD_GPU_DRIVERS
Fixes: 0ca153f869 ("android: radv: enable build of vulkan.radv HAL module")
Reported-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Mauro Rossi <issor.oruam@gmail.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Cc: "18.2" <mesa-stable@lists.freedesktop.org>
(cherry picked from commit 1c7a2433b2)
To make dEQP-GLES31.functional.ssbo.layout.random.all_shared_buffer.23
finish sooner on the older CPUs. (otherwise it gets killed and we fail
the test)
Acked-by: Dave Airlie <airlied@gmail.com>
Python 2 had string_escape and unicode_escape codecs. Python 3 only has
the latter. These work the same as far as we're concerned, so let's use
the future-proof one.
However, the reste of the code expects unicode strings, so we need to
decode them again.
Signed-off-by: Mathieu Bridon <bochecha@daitauha.fr>
Reviewed-by: Dylan Baker <dylan@pnwbakers.com>
src/amd/Android.mk requires to include src/amd/vulkan/Android.mk
to enable the build of vulkan.radv module
Signed-off-by: Mauro Rossi <issor.oruam@gmail.com>
Reviewed-by: Robert Foss <robert.foss@collabora.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
radv implements the Android Vulkan HAL interface, this patch adds
Android.mk building rules by porting of radv automake rules.
vendor HAL module is installed as /vendor/lib/hw/vulkan.radv.so
Signed-off-by: Mauro Rossi <issor.oruam@gmail.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Patch changes radv entrypoints generator to not skip this extension even
though it is set as disabled in the vk.xml
Reference: 63525ba730 ("android: enable VK_ANDROID_native_buffer")
Fixes: 69f447553c ("vulkan: Drop vk_android_native_buffer.xml")
Signed-off-by: Mauro Rossi <issor.oruam@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Reviewed-by: Robert Foss <robert.foss@collabora.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Android build system will try to compile vk_format_table.c
as a shipped source, but at compile time it will be missing,
we move it to generated source, where it belongs
Fixes: f4e499ec79 ("radv: add initial non-conformant radv vulkan driver")
Signed-off-by: Mauro Rossi <issor.oruam@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Reviewed-by: Robert Foss <robert.foss@collabora.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Looks like a mistake from when the deref stuff landed.
Fixes: 506a07e4e3 ("ac/nir: Add deref support to image intrinsics.")
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
If we have tracing enabled we could do all the tracing emits
and overflow the precalculated cdw_max.
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
The code sizes return here get passed to the cache shader insert function,
which then memcpy from the code ptr, and causes all sorts of valgrind
errors like:
==6755== Invalid read of size 8
==6755== at 0x4C32FEE: memcpy@GLIBC_2.2.5 (vg_replace_strmem.c:1021)
==6755== by 0x2305D4C7: radv_pipeline_cache_insert_shaders (radv_pipeline_cache.c:416)
==6755== by 0x2305791D: radv_create_shaders (radv_pipeline.c:2158)
==6755== by 0x2305C523: radv_pipeline_init (radv_pipeline.c:3404)
==6755== by 0x2305C890: radv_graphics_pipeline_create (radv_pipeline.c:3515)
==6755== by 0x230188AB: radv_device_init_meta_blit_color (radv_meta_blit.c:871)
==6755== by 0x2301D50E: radv_device_init_meta_blit_state (radv_meta_blit.c:1278)
==6755== by 0x23011893: radv_device_init_meta (radv_meta.c:352)
==6755== by 0x2300744B: radv_CreateDevice (radv_device.c:1576)
==6755== by 0x5187D0F: ??? (in /usr/lib64/libvulkan.so.1.1.77)
==6755== by 0x518F6A3: ??? (in /usr/lib64/libvulkan.so.1.1.77)
==6755== by 0x5192A42: vkCreateDevice (in /usr/lib64/libvulkan.so.1.1.77)
==6755== Address 0x22a58548 is 4 bytes after a block of size 116 alloc'd
==6755== at 0x4C2EBAB: malloc (vg_replace_malloc.c:299)
==6755== by 0x23089DC4: ac_elf_read (ac_binary.c:144)
==6755== by 0x23090A60: ac_compile_module_to_binary (ac_llvm_helper.cpp:162)
==6755== by 0x23053F06: compile_to_memory_buffer (radv_llvm_helper.cpp:58)
==6755== by 0x23053F06: radv_compile_to_binary (radv_llvm_helper.cpp:98)
==6755== by 0x23052769: ac_llvm_compile (radv_nir_to_llvm.c:3394)
==6755== by 0x23052823: ac_compile_llvm_module (radv_nir_to_llvm.c:3418)
==6755== by 0x23053C05: radv_compile_nir_shader (radv_nir_to_llvm.c:3542)
==6755== by 0x23061B4E: shader_variant_create (radv_shader.c:580)
==6755== by 0x23061CFD: radv_shader_variant_create (radv_shader.c:634)
==6755== by 0x23057765: radv_create_shaders (radv_pipeline.c:2123)
==6755== by 0x2305C523: radv_pipeline_init (radv_pipeline.c:3404)
==6755== by 0x2305C890: radv_graphics_pipeline_create (radv_pipeline.c:3515)
Since we are just inserting the code into the cache, we can avoid these
bad reads and data in the cache by just using the binary code size here.
Fixes: 939e5a382 (radv: add padding for the UMR disassembler)
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
The driver might emit up to 4 dwords when RADV_TRACE_FILE is
used.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
This wasn't wrong but it looks better to me like this. It's
only used for debugging purposes (ie. RADV_TRACE_FILE).
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
