Introduction and updates from NVIDIA

[Miguel Angel Vico]

Hi all,

First of all, I'd like to introduce myself to the Wayland community: My
name is Miguel A. Vico, and I've been working as a Software Engineer
for NVIDIA for some time now, more specifically, in the Linux drivers
team. Although I've never spoken before, I've been lately following the
amazing work that you all have been doing here.

We have been working on adding to our drivers all required features to
be able to run Wayland and Weston on top of it. We have just released
our NVIDIA's 364.12 GPU driver, which brings initial DRM KMS support
(among other things). Please, check out our public announcement here:

    https://devtalk.nvidia.com/default/topic/925605/linux/nvidia-364-12-release-vulkan-glvnd-drm-kms-and-eglstreams/


In order to make the Weston DRM compositor work with our drivers, we
have used EGLDevice, EGLOutput, and EGLStream objects.

For those not familiar with this set of EGL structures, here I try to
summarize the most important part of them, and how would they fit in
the current Weston DRM compositor design:

    EGLDevice provides means to enumerate native devices, and then
    create an EGL display connection from them.

    Similarly, EGLOutput will provide means to access different
    portions of display control hardware associated with an EGLDevice.

    For instance, EGLOutputLayer represents a portion of display
    control hardware that accepts an image as input and processes it
    for presentation on a display device.

    EGLStream implements a mechanism to communicate frame producers and
    frame consumers. By attaching an EGLOutputLayer consumer to a
    stream, a producer will be able to present frames on a display
    device.

    Thus, a compositor could produce frames and feed them to an
    EGLOutputLayer through an EGLStream for presentation on a display
    device.

    In a similar way, by attaching a GLTexture consumer to a stream, a
    producer (wayland client) could feed frames to a texture, which in
    turn can be used by a compositor to prepare the final frame to be
    presented.

    Whenever EGL_EXT_device_drm extension is present, EGLDevice can
    be used to enumerate and access DRM KMS devices, and EGLOutputLayer
    to enumerate and access DRM KMS crtcs and planes.

    By using EGLStreams and attaching an EGLOutputLayer consumer
    (representing a DRM KMS crtc or plane) to it, compositor-drm can
    produce final composition frames and present them on a DRM device.


Most of the EGL extensions required to implement this may be already
found in the Khronos registry, but we also needed extended
functionality for EGLStreams and EGLOutput consumers provided by
following extensions:

 - EGL_NV_stream_attrib:

   https://github.com/aritger/eglstreams-kms-example/blob/master/proposed-extensions/EGL_NV_stream_attrib.txt

   Among other things, this extension defines a version of the stream
   acquire function that takes an EGLAttrib parameter, allowing to
   modify/extend acquire behavior in several cases.

 - EGL_EXT_stream_acquire_mode:

   https://github.com/aritger/eglstreams-kms-example/blob/master/proposed-extensions/EGL_EXT_stream_acquire_mode.txt

   By default, EGLOutputLayer consumer are set to automatically acquire
   frames, so eglSwapBuffers() call on the producer side will present
   to the display without any further action. This extension defines a
   new EGLStream attribute which allows to change this behavior so that
   acquire operations must be issued manually with
   eglStreamConsumerAcquireAttribNV().

 - EGL_NV_output_drm_flip_event:

   https://github.com/aritger/eglstreams-kms-example/blob/master/proposed-extensions/EGL_NV_output_drm_flip_event.txt

   This extension defines a new acquire attribute for EGLOutputLayer
   consumers tied to DRM KMS CRTCs. It allows clients to get notified
   whenever an acquire operation issued with
   eglStreamConsumerAcquireAttribNV() is done.


Additionally, in order to allow wl_buffers to be bound to EGLStreams, we
kludged eglQueryWaylandBufferWL(EGL_WAYLAND_BUFFER_WL) to return the
stream file descriptor.

We think the proper way to handle this should be:

 - Update WL_bind_wayland_display such that eglQueryWaylandBufferWL()
   accepts a new attribute EGL_WAYLAND_BUFFER_TYPE_WL, returning
   EGL_WAYLAND_BUFFER_EGLIMAGE_WL for the non-stream case.

 - Add a new WL_wayland_buffer_eglstream extension, which would define
   EGL_WAYLAND_BUFFER_EGLSTREAM_WL as a return value for
   EGL_WAYLAND_BUFFER_TYPE_WL, and yet another attribute
   EGL_WAYLAND_BUFFER_EGLSTREAM_FD_WL to query the stream file
   descriptor.


I'm planning on posting to this mailing list the set of patches that
will add the support above-mentioned, hoping to get feedback from you.


Thanks in advance,

-- 
Miguel

NVIDIA GmbH, Wuerselen, Germany, Amtsgericht Aachen, HRB 8361
Managing Director: Karen Theresa Burns

-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------