Introduction and updates from NVIDIA

[Miguel Angel Vico]

Hi all,

I just sent a second round of patches to add support for EGLStream &
friend in Weston.

Also, we've uploaded two weston branches that include all these patches
on top of weston master branch.

You can find them here:

  https://cgit.freedesktop.org/~jjones/weston/

'nvidia_head' contains the same set of patches I sent out for review.

'nvidia_r364' contains a slightly different set of patches to make
weston work with our r364 driver, which doesn't have an implementation
of EGL_WL_wayland_eglstream.


Don't hesitate to send me an email if you have doubts or suggestions
about the patches.

I'm also available on Freenode IRC as 'mvicomoya'.


Thanks,
Miguel.


On Mon, 21 Mar 2016 17:28:13 +0100
Miguel Angel Vico <mvicomoya at nvidia.com> wrote:

> 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