Re: [PATCH] wayland: Add an extension to create wl_buffers from EGLImages
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 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
Re: [PATCH] wayland: Add an extension to create wl_buffers from EGLImages
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 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
Re: [PATCH] wayland: Add an extension to create wl_buffers from EGLImages
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 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
Re: [PATCH] wayland: Add an extension to create wl_buffers from EGLImages
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 > This adds an extension called EGL_WL_create_wayland_buffer_from_image > which adds the following single function: > > struct wl_buffer * > eglCreateWaylandBufferFromImageWL(EGLDisplay dpy, EGLImageKHR image); > > The function creates a wl_buffer which shares its contents with the given > EGLImage. The expected use case for this is in a nested Wayland compositor > which is using subsurfaces to present buffers from its clients. Using this > extension it can attach the client buffers directly to the subsurface > without > having to blit the contents into an intermediate buffer. The compositing > can > then be done in the parent compositor. > > The extension is only implemented in the Wayland EGL platform because of > course it wouldn't make sense anywhere else. > --- > .../specs/WL_create_wayland_buffer_from_image.spec | 85 > ++ > include/EGL/eglmesaext.h | 10 +++ > src/egl/drivers/dri2/platform_wayland.c| 71 > ++ > src/egl/main/eglapi.c | 25 +++ > src/egl/main/eglapi.h | 8 ++ > src/egl/main/egldisplay.h | 1 + > src/egl/main/eglmisc.c | 1 + > 7 files changed, 201 insertions(+) > create mode 100644 docs/specs/WL_create_wayland_buffer_from_image.spec > > diff --git a/docs/specs/WL_create_wayland_buffer_from_image.spec > b/docs/specs/WL_create_wayland_buffer_from_image.spec > new file mode 100644 > index 000..7e27695 > --- /dev/null > +++ b/docs/specs/WL_create_wayland_buffer_from_image.spec > @@ -0,0 +1,85 @@ > +Name > + > +WL_create_wayland_buffer_from_image > + > +Name Strings > + > +EGL_WL_create_wayland_buffer_from_image > + > +Contact > + > +Neil Roberts > + > +Status > + > +Proposal > + > +Version > + > +Version 1, September 6, 2013 > + > +Number > + > +EGL Extension #not assigned > + > +Dependencies > + > +Requires EGL 1.4 or later. This extension is written against the > +wording of the EGL 1.4 specification. > + > +EGL_KHR_base_image is required. > + > +Overview > + > +This extension provides an entry point to create a wl_buffer which > shares > +its contents with a given EGLImage. The expected use case for this is > in a > +nested Wayland compositor which is using subsurfaces to present > buffers > +from its clients. Using this extension it can attach the client > buffers > +directly to the subsurface without having to blit the contents into > an > +intermediate buffer. The compositing can then be done in the parent > +compositor. > + > +The nested compositor can create an EGLImage from a client buffer > resource > +using the existing WL_bind_wayland_display extension. It should also > be > +possible to create buffers using other types of images although there > is > +no expected use case for that. > + > +IP Status > + > +Open-source; freely implementable. > + > +New Procedures and Functions > + > +struct wl_buffer *eglCreateWaylandBufferFromImageWL(EGLDisplay dpy, > +EGLImageKHR > image); > + > +New Tokens > + > +None. > + > +Additions to the EGL 1.4 Specification: > + > +To create a client-side wl_buffer from an EGLImage call > + > + struct wl_buffer *eglCreateWaylandBufferFromImageWL(EGLDisplay dpy, > + EGLImageKHR > image); > + > +The returned buffer will share the contents with the given EGLImage. > Any > +updates to the image will also be updated in the wl_buffer. Typically > the > +EGLImage will be generated in a nested Wayland compositor using a > buffer > +resource from a client via the EGL_WL_bind_wayland_display extension. > + > +If there was an error then the function will return NULL. In > particular it > +will generate EGL_BAD_MATCH if the image is not in a format which the > +implementation can represent in a wl_buffer. It is > implementation-defined > +what formats and types of EGLImage will be successfully converted to > a > +wl_buffer without error. > + > +Issues > + > +None. > + > +Revision History > + > +Version 1, September 6, 2013 > +Initial draft (Neil Roberts) > diff --git a/include/EGL/eglmesaext.h b/include/EGL/eglmesaext.h > index e0eae28..0a65cb8 100644 > --- a/include/EGL/eglmesa
[PATCH] wayland: Add an extension to create wl_buffers from EGLImages
This adds an extension called EGL_WL_create_wayland_buffer_from_image which adds the following single function: struct wl_buffer * eglCreateWaylandBufferFromImageWL(EGLDisplay dpy, EGLImageKHR image); The function creates a wl_buffer which shares its contents with the given EGLImage. The expected use case for this is in a nested Wayland compositor which is using subsurfaces to present buffers from its clients. Using this extension it can attach the client buffers directly to the subsurface without having to blit the contents into an intermediate buffer. The compositing can then be done in the parent compositor. The extension is only implemented in the Wayland EGL platform because of course it wouldn't make sense anywhere else. --- .../specs/WL_create_wayland_buffer_from_image.spec | 85 ++ include/EGL/eglmesaext.h | 10 +++ src/egl/drivers/dri2/platform_wayland.c| 71 ++ src/egl/main/eglapi.c | 25 +++ src/egl/main/eglapi.h | 8 ++ src/egl/main/egldisplay.h | 1 + src/egl/main/eglmisc.c | 1 + 7 files changed, 201 insertions(+) create mode 100644 docs/specs/WL_create_wayland_buffer_from_image.spec diff --git a/docs/specs/WL_create_wayland_buffer_from_image.spec b/docs/specs/WL_create_wayland_buffer_from_image.spec new file mode 100644 index 000..7e27695 --- /dev/null +++ b/docs/specs/WL_create_wayland_buffer_from_image.spec @@ -0,0 +1,85 @@ +Name + +WL_create_wayland_buffer_from_image + +Name Strings + +EGL_WL_create_wayland_buffer_from_image + +Contact + +Neil Roberts + +Status + +Proposal + +Version + +Version 1, September 6, 2013 + +Number + +EGL Extension #not assigned + +Dependencies + +Requires EGL 1.4 or later. This extension is written against the +wording of the EGL 1.4 specification. + +EGL_KHR_base_image is required. + +Overview + +This extension provides an entry point to create a wl_buffer which shares +its contents with a given EGLImage. The expected use case for this is in a +nested Wayland compositor which is using subsurfaces to present buffers +from its clients. Using this extension it can attach the client buffers +directly to the subsurface without having to blit the contents into an +intermediate buffer. The compositing can then be done in the parent +compositor. + +The nested compositor can create an EGLImage from a client buffer resource +using the existing WL_bind_wayland_display extension. It should also be +possible to create buffers using other types of images although there is +no expected use case for that. + +IP Status + +Open-source; freely implementable. + +New Procedures and Functions + +struct wl_buffer *eglCreateWaylandBufferFromImageWL(EGLDisplay dpy, +EGLImageKHR image); + +New Tokens + +None. + +Additions to the EGL 1.4 Specification: + +To create a client-side wl_buffer from an EGLImage call + + struct wl_buffer *eglCreateWaylandBufferFromImageWL(EGLDisplay dpy, + EGLImageKHR image); + +The returned buffer will share the contents with the given EGLImage. Any +updates to the image will also be updated in the wl_buffer. Typically the +EGLImage will be generated in a nested Wayland compositor using a buffer +resource from a client via the EGL_WL_bind_wayland_display extension. + +If there was an error then the function will return NULL. In particular it +will generate EGL_BAD_MATCH if the image is not in a format which the +implementation can represent in a wl_buffer. It is implementation-defined +what formats and types of EGLImage will be successfully converted to a +wl_buffer without error. + +Issues + +None. + +Revision History + +Version 1, September 6, 2013 +Initial draft (Neil Roberts) diff --git a/include/EGL/eglmesaext.h b/include/EGL/eglmesaext.h index e0eae28..0a65cb8 100644 --- a/include/EGL/eglmesaext.h +++ b/include/EGL/eglmesaext.h @@ -132,6 +132,16 @@ typedef EGLBoolean (EGLAPIENTRYP PFNEGLQUERYWAYLANDBUFFERWL) (EGLDisplay dpy, st #endif +#ifndef EGL_WL_create_wayland_buffer_from_image +#define EGL_WL_create_wayland_buffer_from_image 1 + +#ifdef EGL_EGLEXT_PROTOTYPES +EGLAPI struct wl_buffer * EGLAPIENTRY eglCreateWaylandBufferFromImageWL(EGLDisplay dpy, EGLImageKHR image); +#endif +typedef struct wl_buffer * (EGLAPIENTRYP PFNEGLCREATEWAYLANDBUFFERFROMIMAGEWL) (EGLDisplay dpy, EGLImageKHR image); + +#endif + #ifndef EGL_NOK_swap_region #define EGL_NOK_swap_region 1 diff --git a/src/egl/drivers/dri2/platform_wayland.c b/src/egl/drivers/dri2/platform_wayland.c index 1d417bb..ee1a6bc 100644 --- a/src/egl/drivers/dri2/platform_wayland.c +++ b/src/egl/drivers/dri2/platform_wayland.c @@
