Split _mesa_set_vertex_format into 2 functions and set the derived fields
after we know that the format is different.
This skips _PipeFormat and _ElementSize recomputation every time we get
gl*Pointer with the same format.
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20287>
The motivation is to remove branching from prepare_indexed_draw
and remove the unsafe hack in vbo_save_playback_vertex_list.
There is some duplication that is not identical in all 3 cases.
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20287>
Natively support it for virtgpu while passthrough renderer support for
vtest. This is a must support to avoid prime blit in common wsi.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20310>
Commit d08bd9a8d8 ("etnaviv: don't expose array and 3D texture support on pre-halti GPUs")
started returning 0 from PIPE_CAP_MAX_TEXTURE_2D_SIZE as well due to switch
case fallthrough. Reinstate the behavior of PIPE_CAP_MAX_TEXTURE_2D_SIZE,
while at the same time, retain the new behavior introduced by commit
d08bd9a8d8 , Otherwise not even kmscube displays the spinning cube,
weston does not display desktop and so on.
Triggered on "Vivante GC600 rev 4653" , i.MX8M Mini .
Fixes: d08bd9a8d8 ("etnaviv: don't expose array and 3D texture support on pre-halti GPUs")
Closes: #7898
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Signed-off-by: Marek Vasut <marex@denx.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20373>
Add the GenXML hardware description for Mali architecture v10, as implemented in
Mali-G610. This is not 100% complete but it should be good enough for parity
with v9.
The XML itself is forked off of v9, with all Job Managerisms replaced with
CSFisms. This notably includes a large number of new structures defining the
instructions that run on the Command Execution Unit (CEU).
This is the first step towards supporting Mali-G610 (i.e. RK3588) upstream. Next
up will be pandecode support.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20360>
We already know from the userspace fence whether the fence has signaled
or not. No need to do a syscall if we aren't going to wait.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20263>
WC is fine for staging upload buffers, and will let us hit the default
heap. Probably introducing a separate cached-coherent heap is overkill,
and given that staging uploads are common (but downloads uncommon, out-
side of dEQP/piglit), it is better to just ask for WC.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20263>
Add a heap that we can use for allocations of small mappable buffers.
This avoids the churn of mmap/unmap, which is especially expensive in
a VM. It also allows packing more smaller allocations together in a
page, which is useful for PIPE_BUFFERs (which are also mappable).
This avoid jank caused by the overhead of setting up or tearing down
guest mappings when running in a VM. And also significantly reduces
the # of BOs referenced on a submit.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20263>
Add a way to request that allocations do not span a specified PoT
boundary. This can be used, for ex, to ensure that allocations do
not span 4GB boundaries to work around hw/fw bugs.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20263>
Remove the last fence-like-struct that isn't fd_fence. Now that
fences are refcnt'd we can just attach them directly to BOs. This
will simplify busy-ness tracking for suballoc BOs.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20263>
Now that we (a) create the fence ourselves, returning a reference from
fd_submit_flush(), and (b) refcnt the fences, we can now merge submits
with on out-fence by just attaching the same fence to all the submits.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20263>
Once we are sharing an out-fence for multiple deferred/merged submits
the complicated logic in fd_pipe_sp_flush() no longer works (or makes
sense), so just simplify all the paths into a single helper.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20263>
This moves away from embedding the submit fence inside the pipe fence,
which lets us start refcnt'ing the fence. This will enable several
cleanups and improvements:
1. Get rid of fd_bo_fence, and just have fd_bo hold pending fd_fence
refs instead, which will be needed for cpu_prep implementation of
sub-allocated buffers.
2. For merged submits, we can just return a new reference to an
existing fence.
Note that this temporarily defeats submit-merging, which will be
fixed (and improved) in a following commit.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20263>
These are redundent with the alloc_flags. A following commit will map
alloc_flags directly to bo heap that should be used, and adding the
FD_BO_SHARED bit when a BO is exported neatly avoids returning it to
the pool to be potentially erroneously reused.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20263>
Sub-alloc'd heap BOs will need to do something a bit more special, ie.
not immediately cleanup fences (because those will be needed to know
when the BO is actually idle and vma node can be released), not tear
down the mmap (because the BO doesn't own it), and not close the handle
(also because the BO doesn't own it).
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20263>
Suballocated heap BOs will bypass the rest of bo_new() (as they skip the
BO cache, don't get an entry in the handle table, etc). So move more of
the initialization into fd_bo_init_common().
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20263>
The context and screen already holds refs to the device. But since
fd_bo_fence holds a ref to the pipe, anyone anywhere leaking a single
bo with unwaited fences could cause the device to leak indirectly.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20263>
This moves the table_lock into a small critical section in the BO delete
path when we are actually removing the entries from the handle/name
tables, so finally table_lock isn't the big-bo-lock!
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20263>
Get rid of the per-device table of deferred handles, and instead keep
this on the stack so that no additional locking is needed. This will
simplify getting rid of table_lock in the bo delete path. For the BO
cache, add fd_bo_del_list_nocache() which works like fd_bo_del_array()
except that it bypasses returning BOs to the cache. This gets rid of
the BO cache calls to private fd_bo fxns (which is useful now that the
bo_del/close_handles() dance has become a bit more complicated).
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20263>
We want to get back to the point where table_lock is only doing what
it's named for (ie. protecting handle/name tables). This is the first
step. Add new locks to protect fencing and the bo caches. A single
global lock for fences, to avoid atomic instructions in the loop per
submit bo attaching fences.
This couldn't be broken appart into different commits, otherwise there
would have been an ABBA deadlock in BO cache's call to fd_bo_state()
to check if a BO is idle.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20263>
To prepare for moving fence state out from under table_lock, simplify
cleanup_fences() and stop trying to re-use it in the bo destruction
path (which otherwise wouldn't need the fence lock, since there is
no other owner of the bo ref at that point, and simply needs to drop
pipe refs).
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20263>
Fixes
dEQP-GLES2.functional.texture.mipmap.cube.basic.linear_nearest
when run with a GLES2 version.
We wire up seamless cube maps for GLES3+ only, working around an obscure
mesa/st limitation. See 6148e3aae7 ("mesa: Fix
ctx->Texture.CubeMapSeamless") for the full context.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20365>
