Re: linux-dmabuf and eglBindWaylandDisplayWl

[Pekka Paalanen]

Hi Matt,

you already got the answer, but here are some other details I want to
note explicitly.


On Thu, 9 Apr 2020 14:42:17 -0500
Matt Hoosier  wrote:

> Hi,
> 
> Historically, many EGL implementations have registered a private wl_drm
> buffer factory for use internally by the implementation's Wayland backend,
> as part of the setup work done go eglBindWaylandDisplayWl().

Yes, and I think it makes sense to keep on using
eglBindWaylandDisplayWl() in compositors when the EGL implementation
supports it, because it's a sign that the EGL implementation client side
might not support zwp_linux_dmabuf. But, it is also possible to not use
eglBindWaylandDisplayWl() and still have everything working if the
client side does use zwp_linux_dmabuf. E.g. a Vulkan-only compositor
should be possible.

> Separately, compositors have started to implement explicit support for the
> zwp_linux_dmabuf_v1 buffer factory, independent of the GPU backend.
> 
> 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 talk has been about the Wayland client side only.

I suppose it would be nice to have a write-up on what EGL extensions
compositors will use to implement zwp_dmabuf_linux themselves.

> That would mean that EGL backends
> would now also want to register a zwp_linux_dmabuf_v1 global.

That, as said by others, I think is intended to not happen.

> I'm wondering how the logistics on that would work. Normally, you can't
> register two globals having the same name in the compositor.

Technically you can. The usual examples are wl_seat and wl_output
interfaces that can routinely have multiple globals advertised. Nothing
stops you from doing it with other interfaces in your compositor.

It only creates a problem in the clients if the protocol extension
designer did not take this possibility into account and give some
information to let the clients choose the right global to refer to, if
it even matters. Clients that do not expect an interface to have
multiple global instances might just pick the first or last one
advertised. Of course, clients could also malfunction if the code made
bad assumptions.

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

Yes, kind of. If both the compositor and server-side EGL implementation
register zwp_linux_dmabuf global each, you wouldn't really know which
one clients will pick. Both should work, but might work differently.


Thanks,
pq


pgpAFs6JyO62A.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: linux-dmabuf and eglBindWaylandDisplayWl

[Matt Hoosier]

On Thu, Apr 9, 2020 at 5:51 PM Simon Ser  wrote:

> On Friday, April 10, 2020 12:48 AM, Matt Hoosier 
> wrote:
>
> > 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?
>
> No, this is the compositor's responsibility only.
>

Thanks, I think that answers the original question pretty clearly.

-Matt
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: linux-dmabuf and eglBindWaylandDisplayWl

[Simon Ser]

On Friday, April 10, 2020 12:48 AM, Matt Hoosier  wrote:

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

No, this is the compositor's responsibility only.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: linux-dmabuf and eglBindWaylandDisplayWl

[Matt Hoosier]

+ list

On Thu, Apr 9, 2020 at 5:48 PM Matt Hoosier  wrote:

> On Thu, Apr 9, 2020 at 5:42 PM Scott Anderson  wrote:
>
>> On 10/04/20 10:34 am, Matt Hoosier wrote:
>> > On Thu, Apr 9, 2020 at 2:51 PM Simon Ser > > > wrote:
>> >
>> > On Thursday, April 9, 2020 9:41 PM, Matt Hoosier
>> > mailto:matt.hoos...@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?
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: linux-dmabuf and eglBindWaylandDisplayWl

[Scott Anderson]

On 10/04/20 10:34 am, Matt Hoosier wrote:
On Thu, Apr 9, 2020 at 2:51 PM Simon Ser > wrote:


On Thursday, April 9, 2020 9:41 PM, Matt Hoosier
mailto:matt.hoos...@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
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: linux-dmabuf and eglBindWaylandDisplayWl

[Matt Hoosier]

On Thu, Apr 9, 2020 at 2:51 PM Simon Ser  wrote:

> On Thursday, April 9, 2020 9:41 PM, Matt Hoosier 
> 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
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: linux-dmabuf and eglBindWaylandDisplayWl

[Simon Ser]

On Thursday, April 9, 2020 9:41 PM, Matt Hoosier  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.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel