These are funky enough that they make more sense as intrinsics than
texture opcodes.
Reviewed-by: Christoph Pillmayer <christoph.pillmayer@arm.com>
Reviewed-by: Lorenzo Rossi <lorenzo.rossi@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41036>
This uprev:
- brings in vrend fixes with virgl ci expectation updated
- enables new venus extensions support
- drops render-server-worker since process isolation is the default
- updates venus ci expectations
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41331>
This has a bit of sorting overhead, but can significantly increase BVH
quality especially in big BVHs. gfx12 is faster at intersecting, so only
enable for gfx11 and earlier right now.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41300>
64-bit morton codes are required for decent lbvh tlas builds since the
scene bounds are usually much bigger than the area that is actually
important.
The changes were done without understanding the code but they seem to
work.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41300>
This removes the conversion between iris_madvice and i915 values, placing it by
a static assert in case this values ever don't match.
Also adds a warn once in case of DRM_IOCTL_I915_GEM_MADVISE ever fails.
As at last in case of failure of DRM_IOCTL_I915_GEM_MADVISE returns as if the
bo is not retained anymore to have a safe behavior.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Suggested-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40573>
Initially this uAPI was part of the first public version of Xe KMD uAPI but as
it did not had any users it was removed in some of fixes releases of the
Linux version that added Xe KMD but I missed to update the comment in Mesa.
At that time this uAPI had a restriction that did not allowed us to use, it
was compatible with VMs created with DRM_XE_VM_CREATE_FLAG_SCRATCH_PAGE but now
this flag is supported so here implementing it.
Link: https://patchwork.freedesktop.org/series/156651/
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40573>
Fix OpenCL-CTS error in `math_brute_force/test_bruteforce -w ldexp`
Valhall LDEXP.v2f16 takes a 16-bit exponent, while NIR ldexp uses a
32-bit exponent. Truncating large exponents can flip overflow into
underflow or leave huge 16-bit exponents to hardware behavior that does
not match OpenCL's expected signed infinity/zero results.
Clamp the exponent to a range sufficient to overflow or underflow all
fp16 values before lowering to ldexp16_pan.
Signed-off-by: Eric Guo <eric.guo@nxp.com>
Reviewed-by: Lorenzo Rossi <lorenzo.rossi@collabora.com>
Reviewed-by: Christoph Pillmayer <christoph.pillmayer@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41234>
This property is unrelated to the CTS conformance process from Khronos,
it just means that the driver passes that CTS version, even if not
"officially" conformant.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41258>
Even if they are in the same block, we might still need to move the
source instructions if they are otherwise after our insert location.
This can happen in the case where we insert strict_wqm_coord before
terminate_if.
Fixes: ac33f82d54 ("ac/nir/lower_tex_coords: move input loads instead of cloning them")
Reviewed-by: Marek Olšák <maraeo@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41336>
Note: the atomic host-mem-barrier tests assume that the atomic
buffer could be shared which is not how the r600 operates.
This change was tested on palm and cayman, with the exception
of the "atomic counter" tests, it fixes all the other cases:
spec/arb_shader_image_load_store/host-mem-barrier/.*: fail pass
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41199>
LRZ and FDM have a few major performance pitfalls, if they are not
clearly surfaced when doing perfetto trace - they are easy to miss.
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40935>
We rely on tu_lrz_flush_valid_at_suspending_rp_boundary() to make sure
that subsequent resuming renderpasses get the correct LRZ state. However
this doesn't work on early a6xx GPUs without tracking support. Disable
LRZ in this case, similar to secondaries.
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40935>
