export-dmabuf: provide driverUUID and deviceUUID

[i509VCB]

The export dmabuf protocol should provide the driver and device uuid along side the drm node of the device.

The driver and device uuids are defined in the following Vulkan/EGL extensions:

• VK_KHR_driver_properties (Or Vulkan 1.2) (Implemented by most drivers)

• GL_EXT_external_objects (Implemented by Mesa)

• EGL_EXT_device_persistent_id (Not yet implemented by Mesa)

For vulkan in particular, knowing if the dmabuf is from the same driver and device can be used to optimize memory barriers (The driver uuid would differ if two different versions of Mesa are used across the Wayland socket).

If the driver and device uuids match, the implementation can perform queue family ownership transfer from the sentinel "external" queue family instead of having to use the sentinel "foreign" queue family. Testing by Nvidia's driver team showed that the more optimized memory barrier can lead to a 50% performance improvement in some cases.

Now this all sounds great, are there any protocol considerations that need to be made?

Well, using the external queue family on a dmabuf which is infact foreign leads to undefined behavior in Vulkan. This means the protocol MUST mandate that implementations provide the correct device and driver uuid.

The driver and device uuid fields must be optional. In that case clients must assume the worst and use the most conservative memory barriers.

If a compositor supports the driver and device uuid, the implementation must report both (probably by transmitting both in one event).

Anyways I hope that one day this protocol is standardized in Wayland protocols :)

[Drakulix]

We are going to deprecate the export-dmabuf protocol, but I guess the same applies to the buffer_info event of the screencopy protocol.

While I generally agree with this (and would like to be able to optimize this use-case), we want to switch to ext-screencopy as soon as it lands. So I am not adding any additional fields, which aren't strictly required for our functionality and not present in it's current draft: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/124
I guess this discussion is better had over at wayland-protocols?