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.d...@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@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
