NVIDIA Presents Over GBM vs. EGLStreams, The Big Wayland Support Debate Continues
James Jones of NVIDIA just finished taking the stage at XDC2016 where he was talking about Unix device memory allocation, which comes down to the big EGLStreams vs. GBM debate... A.k.a. NVIDIA pushing a different approach for their Wayland support from the Wayland compositors currently focusing around GBM for buffers. This debate is leading towards the development of a new API.
If you are not familiar with this topic, see our past articles such as NVIDIA To Meet With Wayland, Linux Kernel Developers To Discuss GBM vs. Streams, A Wayland Developer Shares His Concerns About NVIDIA's EGLStreams Proposal, and Streams vs. GBM: The Fight Continues Over NVIDIA's Proposed Wayland Route, among several other articles.
This debate largely comes down to device-accessible surface allocation in user-space, surface state/layout management, surface handles, and synchronization. What James Jones expressed as goals for this device memory allocation debate is for gaining a consensus over a forward-looking API that is agnostic to vendors / kernels / windowing systems, would be a minimal yet optimal driver interface, and for ultimately delivering optimized scene graphs for every frame. Yes, it's a big deal for Wayland compositors while NVIDIA is trying to look at the bigger picture too of optimal device memory allocation.
From the NVIDIA perspective at least, here is how James Jones described the current options:
GBM - The current way used by Wayland compositors... It provides buffer allocation, arbitration, and handles. The "benefits" expressed is that it's already supported by many code-bases, is widely-deployed and tested, and ia a minimal API while supporting allocation-time usage specification. Current GBM shortcomings expressed in the presentation are process-local handles only, very GPU-focused, and arbitration is within device scope.
Gralloc - The Android approach provides allocation, arbitration, and handles along with synchronization and out-of-process handles but requiring other components. Gralloc is clearly proven in the field with it being widely-used, it's an allocation-time usage specification, and supports non-graphics usage. But viewed shortcomings are no explicit surface state management, limited arbitration support, and Gralloc isn't fully open-source.
EGLStream - NVIDIA's current preferred method supports allocation, arbitration, handles, state management, and synchronization. It's viewed as being proven, portable, and comprehensive/extensive abilities. But viewed shortcomings of EGLStream are the open standard being implemented differently by vendors, there isn't cross-device support, it's based upon EGL, there is a lot of encapsulation, and the behavior can vary in some areas.
DMA-BUF - DMA-BUF provides handles and works with non-graphics devices, but there is no centralized user-space allocation API, only works on Linux, doesn't describe content layout, no arbitration, and limited allocation-time usage specification.
Vulkan - Vulkan gets mentioned since it does have interfaces concerning allocation, usage, state management, and synchronization. Vulkan has many benefits but it is graphics/compute/display-only and there is no cross-process/cross-API/cross-device handles or arbitration.
With those current "prior arts" from here, James Jones (NVIDIA) is hoping that the development community will ultimately devise a more optimal API that's minimal, portable, supports more than just GPUs, allows for optimal performance, handles driver-negotiated image capabilities, allows good performance, supports image layout transitions, and more. Again, while it's of concern to Wayland compositors and is the hot topic being debated right now since NVIDIA isn't supporting GBM, the hope is to make a much more universal and full-featured API to other clients / windowing systems. Obviously this isn't something that can be solved in one day, especially in trying to reach a consensus for a new, optimal API for device memory / surface allocation.
Hopefully there will ultimately be this new optimal API that's agreed upon -- and supported -- by all major vendors, but until then the Wayland compositor maintainers will still probably be focused on their GBM-only code-path. NVIDIA doesn't seem interested in budging right now on supporting GBM by their proprietary driver if it's only to be replaced in the (near?) future by a better surface allocation API and their interest in also seeing cross-platform support. Thus don't expect any miracles in the immediate future for the NVIDIA proprietary driver to work on the current-generation of Wayland compositors using GBM for their surface allocation. At least the XDC2016 feedback and comments so far have been productive and developers are open to discussing a new, better API.
More information can be found via James Jones' PDF slides and the discussion can be watched via the XDC2016 YouTube stream.