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

[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
>