This is needed for the VIRTGPU_WAIT ioctl to work.
TODO we could perhaps limit this, since it is not needed for residency,
but only fencing. Ie. we could omit cmdstream, and probably anything
that has FD_BO_NOMAP flag.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16086>
This syncs up with the protocol of what eventually landed in virglrender.
1) Move all static params to capset to avoid having to query host
(reduce synchronous round trips at startup)
2) Use res_id instead of host_handle.. costs extra hashtable lookups in
host during submit, but this lets us (with userspace allocated IOVA)
make bo alloc and import completely async.
3) Require userspace allocated IOVA to simplify the protocol and not
have to deal with GEM_NEW/GEM_INFO potentially being synchronous.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16086>
If supported by host virglrenderer and host kernel, use userspace
allocated GPU virtual addresses. This lets us avoid stalling on
waiting for response from host kernel until we need to know the
host handle (which is usually not until submit time).
Handling the async response from host to get host_handle is done
thru the submit_queue, so that in the submit path (hot) we do not
need any additional synchronization to know that the host_handle
is valid.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16086>
We use nir_assign_io_var_locations() which compacts the varyings and
eliminates any unused input slots. We need to do the same thing when
processing pVertexAttributeDescriptions[] or else we'll end up with
mismatches between the shader and the state setup code.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16183>
Due to both Lavapipe on Windows and Dozen, we need to support MSVC in
the shared Vulkan code. So let's make sure we compile with the
compatibility flags for it.
Techinically speaking, we also need this in the wsi subdir, because we
also compile wsi_common_win32.c with MSVC. But wsi_common_wayland.c
contains void-pointer arithmetic, causing compiler errors if we do.
Fixing that properly is a bit more involved, because Meson doesn't love
passing different compiler arguments per source-file. The alternative is
to remove the void-pointer arithmetic, but that seems a bit pointless as
this code will never be compiled on MSVC.
So, let's leave that one out for now. We can probably do better in the
future, but this gets us a step further.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/6386
Reviewed-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16162>
On older GPUs a color tile was always 64 Byte. On new GPUs with
CACHE128B256BPERLINE support the tile size is either 128 Byte or
256 Byte depending on the TS mode. Add a helper to return the
color tile size and use in in places that use hard-coded tile
size values or do their own calculation.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9255>
With access to HALTI5 GPUs with and without DEC400 compression it's
obvious that the previous compression state setup only worked when
DEC400 was present. Properly set up the compression state bits.
This is only the second part of the fix, first part is moving the
compression state to the correct bit location, which has already
happened via the import of new rnndb headers.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9255>
We used the number of pipes to determine which state registers to use
for the RS pipe address configuration, as the dual pipe GPUs were the
first one where the new states were used. This isn't correct though,
as now there are single pipe GPUs which also use the new state
addresses.
There actually is a feature flag telling us to use the new RS pipe
address states, use it. As this feature flag is not available on early
GPUs using the new base address (mostly because we don't have HWDB
entries for them), still check for more than a single pipe as an
additional clue to use new states.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9255>
We used the number of pipes to determine which state registers to use
for the PE pipe address configuration, as the dual pipe GPUs were the
first one where those new states were used. Now there are some new
single pipe GPUs where this logic breaks. HALTI0 added the new PE
address states and all GPUs with at least this feature level are using
the new states exclusively, even if they only have a single PE pipe.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9255>
Rob Clark