egl image creation in case of atomic

Pekka Paalanen ppaalanen at gmail.com
Tue Sep 11 14:34:28 UTC 2018


On Tue, 11 Sep 2018 16:10:17 +0300
Pekka Paalanen <ppaalanen at gmail.com> wrote:

> On Tue, 11 Sep 2018 12:47:15 +0000
> "Hosokawa, Kenji (ADITG/ESB)" <khosokawa at de.adit-jv.com> wrote:
> 
> > We would like to discuss the following part.  
> > >Creating egl images are not needed at all, when the client buffer
> > >can be imported to a DRM plane. We would like to reduce CPU usage of
> > >weston in that case.    
> 
> Hi,
> 
> ok, that sounds fine to me. Maybe something like this: the GL-renderer
> attach hook just unrefs existing EGLImages but does not create new
> ones. New ones are created at repaint time on demand. This should
> implictly result in composite-bypass avoiding the EGLImage creation,
> because the renderer does not repaint those views.
> 
> Does this answer your question?
> 
> This is just off the top of my head, I didn't actually check how the
> code would allow this.

Oh, one important detail:

One cannot skip creating the EGLImage in the
zwp_linux_buffer_params_v1.create path, because it is the test to see
if the compositor can use the dmabuf at all. It must be done at the
create step, so that potential failure can be communicated gracefully.

One might be able to argue, that skipping the initial import test in
create_immed path is ok, because it is meant to be unchecked anyway and
documented to result in fatal protocol errors if anything fails.

So you may not be able to eliminate the EGLImage creation during
wl_buffer creation, but you should be able to eliminate or optimize the
EGLImage creation when an existing wl_buffer is re-used. I hope that is
sufficient for your use cases.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20180911/69c3e3d5/attachment.sig>


More information about the wayland-devel mailing list