Thread (5 messages) flat view 5 messages, 2 authors, 2021-02-17

Re: [PATCH 09/10] drm/qxl: map/unmap framebuffers in prepare_fb+cleanup_fb callbacks.

From: Thomas Zimmermann <tzimmermann@suse.de>
Date: 2021-02-17 10:24:28
Also in: dri-devel, lkml

Hi

Am 17.02.21 um 11:02 schrieb Gerd Hoffmann:
On Tue, Feb 16, 2021 at 02:46:21PM +0100, Thomas Zimmermann wrote:
quoted

Am 16.02.21 um 14:27 schrieb Thomas Zimmermann:
quoted
Hi

this is a shadow-buffered plane. Did you consider using the new helpers
for shadow-buffered planes? They will map the user BO for you and
provide the mapping in the plane state.

  From there, you should implement your own plane state on top of struct
drm_shadow_plane_state, and also move all the other allocations and
vmaps into prepare_fb and cleanup_fb. Most of this is not actually
allowed in commit tails. All we'd have to do is to export the reset,
duplicate and destroy code; similar to what
__drm_atomic_helper_plane_reset() does.
AFAICT the cursor_bo is used to implement double buffering for the cursor
image.

Ideally, you can do what ast does: pre-allocate/vmap 2 BOs at the end of the
vram. Then pageflip between them in atomic_update(). Resolves all the
allocation and mapping headaches.
Just waded through the ast patches.
I just received your ack. Thanks a lot for looking at the ast patches.
It is not that simple for qxl.  You have to send a command to the
virtualization host and take care of the host accessing that memory
when processing the command, so you can't reuse the memory until the
host signals it is fine to do so.

But, yes, it should be possible to handle cursor_bo creation in
prepare_fb without too much effort.
I've been thinking about this issue and here's an idea:

If you take the ast code as a blueprint, you'd store two cursor bo in a 
cursor-plane structure. Aditionally each of these BOs would have a 
pointer to a fence associated with it.

One idea for the fencing code would be to allocate each new fence in 
prepare_fb and store it in the cursor plane state. In atomic_update, 
pick the unused BO in the cursor plane and wait on its fence. This 
should guarantee that the BO is available. (?) Then swap the BO's fence 
with the one in the cursor plane state. Setup the new fence for 
synchronization with the host. Next time you pick this cursor BO, the 
fence will be there for synchronization. The old fence from the cursor 
BO will now be stored in the cursor-plane state and can be freed in 
cleanup_fb().

My main interest here is to move all fail-able/locking calls out of the 
atomic_update function. I might be missing some crucial corner case, but 
this should resolve the issue. (?) In any case, it's maybe worth a 
separate patchset.

Best regards
Thomas
take care,
   Gerd

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help