linux-dmabuf and eglBindWaylandDisplayWl

[Matt Hoosier]

+ list

On Thu, Apr 9, 2020 at 5:48 PM Matt Hoosier <matt.hoosier at gmail.com> wrote:

> On Thu, Apr 9, 2020 at 5:42 PM Scott Anderson <scott at anderso.nz> wrote:
>
>> On 10/04/20 10:34 am, Matt Hoosier wrote:
>> > On Thu, Apr 9, 2020 at 2:51 PM Simon Ser <contact at emersion.fr
>> > <mailto:contact at emersion.fr>> wrote:
>> >
>> >     On Thursday, April 9, 2020 9:41 PM, Matt Hoosier
>> >     <matt.hoosier at gmail.com <mailto:matt.hoosier at gmail.com>> wrote:
>> >
>> >      > If I remember correctly, I've read various messages on the list
>> >     here saying that eventually it would be preferred for EGL
>> >     implementations would just use linux-dmabuf as their buffer factory.
>> >     That would mean that EGL backends would now also want to register a
>> >     zwp_linux_dmabuf_v1 global.
>> >
>> >     Mesa already binds to zwp_linux_dmabuf_v1 and uses it if possible.
>> >
>> >      > I'm wondering how the logistics on that would work. Normally, you
>> >     can't register two globals having the same name in the compositor.
>> >     Does this lead to a conflict between the EGL implementation's
>> >     ability to enumerate a linux-dmabuf API for its own use, and the
>> >     linux-dmabuf API that the overall compositor might offer?
>> >
>> >     Just to be clear: we're talking about the client side right?
>> >
>> >     It's fine to bind twice to the same global. This creates two
>> >     independent objects.
>> >
>> >
>> > No, I mean from the standpoint of a compositor implementer.
>> >
>> > -Matt
>>
>> Mesa does not implement zwp_linux_dmabuf_v1 on the compositor side. It's
>> the compositor's job to do that, and they can use EGL or Vulkan
>> extensions [1] to import them for rendering with, or otherwise use them
>> with anything capable of consuming dmabufs.
>>
>> eglBindWaylandDisplayWL still only handles wl_drm.
>>
>> - Scott
>>
>> [1]:
>>
>> https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_image_dma_buf_import.txt
>>
>> https://www.khronos.org/registry/vulkan/specs/1.2-extensions/html/vkspec.html#VK_EXT_external_memory_dma_buf
>
>
> Okay, interesting that Mesa’s client will use Linux-dmabuf if the
> compositor happens to provide it, but the server-side EGL of Mesa offers
> wl_drm as a fallback.
>
> As a compositor author, do I have to account for the possibility that the
> EGL implementation may provide (squat on) the “zwp_linux_linux_dmabuf_v1”
> buffer factory itself, it is that strictly the prerogative of the
> individual compositor?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20200409/aba25861/attachment.htm>