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>
