It always felt weird having the extension management in two different
places. Later once we require LLVM-14 we might even be able to clean it up
a little more.
Signed-off-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26641>
We use SETMSF to implement discard, so we need to ensure that any
TMU writes after a SETMSF don't actually execute. We emit a TMU flush
before a discard but we also need to ensure that the QPU scheduler
honors this.
Fixes some tests in dEQP-VK.spirv_assembly.instruction.terminate_invocation.*
when we expose the extension that would otherwise fail because the
QPU scheduler would incorrectly move some image writes emitted after a SETMSF
before the SETMSF instruction.
Also fixes spec@arb_shader_atomic_counters@fragment-discard
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26631>
This isn't currently causing any issues as the driver only supports the
VK_KHR_display extension for now, so there will always be a valid display FD
when a WSI allocation is requested. However, checking that we have a valid
display FD when attempting to allocate via the display driver is more correct
and, when we come to support VK_KHR_wayland_surface, will avoid
vkAllocateMemory() unnecessarily failing.
This addresses a comment made here:
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15507#note_2188052
Signed-off-by: Frank Binns <frank.binns@imgtec.com>
Reviewed-by: Luigi Santivetti <luigi.santivetti@imgtec.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26516>
The queue_family field is not an array, but a pointer.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: 9866c4e32b ("anv: Skip layout transition on the compute queue")
Reviewed-by: Rohan Garg <rohan.garg@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26645>
Once lowered low enough, it's not always possible to tell what strings
are used. So include them all when linking another shader.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26505>
https://man7.org/linux/man-pages/man2/kcmp.2.html
The kcmp() system call first appeared in Linux 3.5.
But was probably also not supported by all major platforms
at that time. So fallback to the check that is done for windows.
Signed-off-by: Thomas Devoogdt <thomas.devoogdt@barco.com>
Acked-by: Yonggang Luo <luoyonggang@gmail.com>
Acked-by: Michel Dänzer <mdaenzer@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18517>
This is allowed by D3D, RADV, ANV and Nvidia GL drivers
at least, so it should work on any hardware with S3TC.
Confirmed to work in OpenXRay on radeonsi.
Signed-off-by: Pavel Asyutchenko <svenpavel@gmail.com>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26389>
In amdgpu_cs.c, struct amdgpu_ib variable is named as ib which creates
confusion since struct drm_amdgpu_cs_chunk_ib is also called as ib in
some places.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26612>
preamble ib is created using amdgpu_cs_setup_preemption()
function. only IB_MAIN memory is allocated from struct amdgpu_ib.
Hence remove ib_type variable from struct amdgpu_ib.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26612>
This is not needed. validate_ir_tree() is called at the end of the
glsl ir linker and the IR is not modified again after so we can
drop this.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26628>
Perhaps it should use div_round_up() unlike normal timestamp conversion,
but this is close enough and it makes the connection to the 19.2MHz RBBM
counter more obvious.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26640>
The kernel returns the 19.2MHz RBBM counter, same as what is used for
timestamp queries. So it needs to be converted the same way.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26640>
Vulkan backend of Hades can only handle at most 3 swapchain images.
It affects all drivers after below commit:
04d654a5d0
and then only affects specific driver backend which enables
extra_xwayland_image in wsi device options after below commit:
c1a62476ac
Cc: mesa-stable
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Renato Pereyra <renatopereyra@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26607>
Once decl_reg is handled, src[0].ssa->divergent will be properly set, so
load_reg and load_reg_indirect do not need special treatment.
shader-db can run to completion on HSW, IVB, and SNB now. No other
testing was done.
v2: Refactor nir_intrinsic_load_reg and nir_intrinsic_load_reg_indirect
handling. Suggested by Daniel Schürmann.
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Fixes: 4fd257d20f ("nir: Properly handle divergence for load_reg")
Fixes: 6dbb5f1e07 ("intel/fs: rerun divergence analysis prior to convert_from_ssa")
Closes: #10233
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26436>
