[PATCH] wayland: Add an extension to create wl_buffers from EGLImages

[Axel Davy]

I want to add the use case that I describe is not with subsurfaces.

What I imagine is having a System compositor on card A (integrated),
and a Session compositor on card A (integrated card/energy saving) or 
card B (dedicated card/max performance).
The Session compositor wouldn't use subsurfaces, and would always give a 
full buffer to the System compositor (as weston running under weston).

The Session compositor window is fullscreen and the System compositor 
optimizes performance by using the Session compositor buffer as a 
scanout buffer.

If a fullscreen application runs inside the Session compositor, with 
your extension,
the Session compositor would not need to copy the content of the window 
application while on card A/energy saving mode.
Thanks to the extension, the fullscreen application will be used as a 
scanout buffer directly by the System compositor.

But if we are on the dedicated card (max performance mode), we need a 
copy because the clients use tiling: your extension should fail (or do a 
copy).

Axel Davy


>
>
> System compositor: set up wl_drm to import buffers on card A
>
> Session compositor: Detects it is on card B and not the card of 
> wl_drm. Creates a buffer without tiling and use wl_drm to share it 
> with the System compositor.
>
> The session compositor creates a new wl_drm for its clients.
> The clients: see they are on card B that is the card of the wl_drm 
> they see. They create a buffer with tiling since it is better 
> performance wise, and share it with the Session compositor.
>
>
> Without your extension, the session compositor has to copy the 
> contents of the clients (with card B) in its own buffer (readable by 
> card A and B) and commit it to the System compositor. Card A only sees 
> a buffer without tiling, even if the clients used tiling.
>
> Your extension avoid the copy, and the tiling mode is not changed (it 
> would need a copy). Since A doesn't understand the tiling mode of B, 
> the buffers will not be displayed correctly.
>
>
> Prime support isn't implemented in Mesa yet (It'll use render-nodes).
>
> I suggest you design your extension so it can fail if the texture 
> cannot be used on the card of the System compositor. When Prime 
> support would be ready, it will be needed to check if the card 
> described by wl_drm of the System compositor and the Session 
> compositor is the same than the one used by the session compositor.
> I assume a variable would be added to the dri2_dpy structure to tell 
> if it can use tiling or not when creating buffers, and you would just 
> need to check it.
>
> Axel Davy
>
> Le 09/09/2013 20:39, Neil Roberts a écrit :
>> Is this problem specific to the extension or is it a general problem?
>> Would there not be the same issue if the session compositor wasn't using
>> the extension but was creating textures from the client surfaces
>> instead? Presumably if cards A and B don't share a tiling mode then it
>> won't be possible for card B to make a texture out of buffers created on
>> card A either.
>>
>> My assumption was that if you have successfully created an EGLImage out
>> of the client's surface then it is a valid buffer for that EGL context.
>> Perhaps this situation should be detected in eglCreateImage rather than
>> in eglCreateWaylandBufferFromImage.
>>
>> I apologise in advance if I've misunderstood the problem.
>>
>> Regards,
>> - Neil
>>
>> Axel Davy <axel.davy at ens.fr> writes:
>>
>>> I think there is a problem with tiling handling in your patch.
>>>
>>> Thinks of a session compositor running on an other graphic card for 
>>> example.
>>>
>>>
>>> Main compositor: card A
>>> session compositor: card B. buffer is shared between A and B and when
>>> creating it, tiling was disabled (because A and B share no tiling mode)
>>> clients in the session compositor: card B. buffer is created on B, when
>>> creating it, tiling was enabled.
>>>
>>> In this configuration, your function should fail or do a copy 
>>> (because A
>>> won't recognize the tiling mode of B)
>>>
>>> Axel Davy
>> ---------------------------------------------------------------------
>> Intel Corporation (UK) Limited
>> Registered No. 1134945 (England)
>> Registered Office: Pipers Way, Swindon SN3 1RJ
>> VAT No: 860 2173 47
>>
>> This e-mail and any attachments may contain confidential material for
>> the sole use of the intended recipient(s). Any review or distribution
>> by others is strictly prohibited. If you are not the intended
>> recipient, please contact the sender and delete all copies.
>>
>> _______________________________________________
>> wayland-devel mailing list
>> wayland-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>>
>