Right now, the varying layout is entirely a series of assumptions made
various places in the driver and compiler. This adds an explicit
structure for tracking the layout which we will eventually plumb through
everywhere.
Co-authored-by: Lorenzo Rossi <lorenzo.rossi@collabora.com>
Reviewed-by: Lorenzo Rossi <lorenzo.rossi@collabora.com>
Acked-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38681>
In preparation for future commits, we're builing better alternatives
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Acked-by: Eric R. Smith <eric.smith@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38681>
neither pipe_grid_info::block nor pipe_grid_info::grid_base are used
by the GL frontend, and using them in lavapipe prevents the GL side from
working
Reviewed-by: Konstantin Seurer <konstantin.seurer@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37408>
They all do exactly the same thing, except that GS multiplies by an
extra factor, and TCS has urb_read_length == 0 so it skips one line.
No need for four copies.
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40328>
Just return the register instead of having multiple functions stash the
register in an array of registers. Way too much hoopla here.
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40328>
This was used for Gfx4-5. Since then, we're just passing around a
boolean that nobody wants. Even if someone did, a better plan is to
just check nir->info directly.
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40328>
When the slice configuration from frontend is possible with variable
slice mode, prefer to use it. This lets us respect the config more
closely.
Co-authored-by: Benjamin Cheng <benjamin.cheng@amd.com>
Reviewed-by: David Rosca <david.rosca@amd.com>
Reviewed-by: Benjamin Cheng <benjamin.cheng@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40329>
Normally Venus on Nvidia GPUs takes the prime blit path. The exception
is when KWin or any wlroots based compositors are used:
1. KWin and wlroots based compositors always add LINEAR to dmabuf
feedback tranches assuming LINEAR can be handled by GPU drivers.
2. Venus + Virgl only sees the compositor injected LINEAR mod since
Virgl doesn't support explicit modifiers on the driver side.
3. Nvidia GPUs doesn't support LINEAR color attachment, and it's too
late to reject LINEAR mod when the native image path has already
been taken instead of the prime image path.
Gamescope requires VK_EXT_physical_device_drm and its runtime doesn't
use standard WSI extensions, so venus can spoof without impacting it.
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40339>
This allows the exported fds to be mapped for writing. This is needed
for nested venus in the VM env, where virgl gbm is used to allocate
external memory for backing venus host visible support. Venus can't use
its own export alloc since they are all blob mem, while we can use the
Virgl guest storage when available.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40358>
On V3D 4.2, txf instructions with an out of bounds LOD do not
return robust values (zero) as required by robustImageAccess2.
This commit introduces a NIR lowering pass that explicitly checks
if the LOD is within bounds. If the LOD is out of bounds,
the texture coordinate is replaced with an out of bounds value
to force the hardware to return the robust value.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39430>
When masking out of bounds image loads, we previously returned a vector
of all zeros. However, for robustImageAccess2, depending on the format,
some components such as the alpha channel in an RGB format
should evaluate to 1.
This corrects the replacement value based on the format swizzle.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39430>
No need to invalidate the VCACHE again (applications are supposed to
emit a barrier) and INV_SCACHE/INV_L2 are not necessary either.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40342>
When VRS rates are copied from the VRS image to HTILE. Only the
vector cache needs to be flushed becaue it's using VMEM.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40342>
