Written by Daniel Stone, Graphics Lead at Collabora.

The past few months have been busy ones on the open-source graphics front, bringing with them Wayland 1.13, Weston 2.0, Mesa 17.0, and Linux 4.10. These releases have been quite interesting in and of themselves, but the biggest news must be that with Mesa 17.0, recent Intel platforms are fully conformant with the most recent Khronos rendering APIs: OpenGL 4.5, OpenGL ES 3.2, and Vulkan 1.0. This is an enormous step forward for open-source graphics: huge congratulations to everyone involved!

Mesa 17.0 also includes the Etnaviv driver, supporting the Vivante GPUs found in NXP/Freescale i.MX SoCs, amongst others. The Etnaviv driver brings with it a ‘renderonly’ framework for Mesa, explicitly providing support for systems with a separate display controller and 3D GPU. Etnaviv joins Mesa as the sixth hardware vendor to have a supported, fully open-source, driver.

Extending buffer modifier support

Though we were proud to participate in some of the new feature enablement work in Mesa to lift it to conformance (including arrays-of-arrays, enhanced UBO layouts, much shader cache work, etc), much of our work recently has been focused on behind-the-scenes performance improvements. Varad Gautam blogged about buffer modifiers and their importance; we continue to work on buffer modifier support both in Wayland/Weston and Mesa. With Wayland and Weston now re-opened for development after their release, we should see this support merged into the respective protocols soon.

We have also worked with Ben Widawsky at Intel and Kristian Høgsberg at Google to enable rendering and direct display of buffers with modifiers. Respectively, their patchsets extend the GBM API (used to enable GPU rendering for direct display to KMS) to accept a list of supported modifiers for rendering, and extend the KMS API to advertise a list of supported modifiers for each plane. With both allocation and advertisement solved, we are getting closer to a fully end-to-end-optimal pipeline.

An atomic Weston, and its little helpers

Weston is currently being used as a testbed/showcase for the new GBM and KMS API. The large patchset for Weston to support atomic modesetting is in the process of review and merge. In addition to numerous bugfixes found in the DRM backend during development, the atomic series delivers on the basic premise of atomic modesetting: that clients will be able to have their content displayed directly on hardware overlay planes, with no specific hardware knowledge required to achieve this.

Implementing this and having it fully correct exposed a number of design issues with Weston’s DRM backend, which long predates atomic. The legacy and atomic KMS APIs are substantially different, and the premise at the time was that Weston would use a hardware-specific component which would generate plane configurations for it.

Instead, the KMS atomic modesetting API provides an incremental approach: userspace builds up display state one by one, asking the kernel to validate the proposed configuration. In this, Weston attempts to place on-screen objects into display planes one by one, which requires repeatedly proposing, modifying, and tearing down internal state objects. The resulting patchset is the largest development in the DRM backend since 1.0, and one which should substantially improve the stability, quality, and extensibility of the DRM backend.

Bringing this up on new hardware has worked almost flawlessly, thanks to the kernel’s helper library design. In the old legacy-API world of KMS, each driver implemented extremely varied semantics, and trying to run generic userspace for all but the most basic tasks was an exercise in frustration. Instead, with atomic drivers, there is very little to go wrong: for the only one driver I’ve found out of nine which didn’t work out of the box with Weston, the fix was to remove driver-specific code and move more work to generic helpers.

The varying capabilities and implementations between platforms has long been a huge bone of frustration for us, as it makes more difficult for our customers to port their offerings between platforms in response to commercial/logistical, performance, or other issues. The work with atomic to make drivers as consistent as possible narrows this gap, and narrows the NRE investment required to change hardware platforms.

A reusable Weston

Speaking of large developments in Weston, its 2.0 version number was the result of developments in libweston, the API enabling external window managers and desktop environments to reuse our solid and complete core code. The original premise behind Weston was that compositors should be so small that everyone could write their own.

Unfortunately, experience has not borne this out: in order to deliver predictable repaint timings, support for mechanisms like dmabuf and modifiers, atomic modesetting and full use of hardware overlay planes, and so on, quite a lot of core code is required. However, tying Weston to one particular window manager or desktop environment would limit our scope and our reach.

The solution chosen was libweston: to expose Weston’s scene graph, protocol and hardware support, as a library for external users. Some environments such as Orbital are already making use of libweston, but we hope to see more in the future.

Towards this end, Weston 2.0 contains the work of Armin Krezović, a Google Summer of Code 2016 student who worked tirelessly on backend and output configuration. His work allows the environment to have more control over the configuration and placement of monitors and outputs, which we will absolutely need in full desktop environments. We’re immensely grateful to Armin for his work throughout the summer, Google for their annual support of the program, and to Pekka and Kat for mentoring Armin and dealing with the organisational side of GSoC, respectively.

Ever onwards

But we’re not done yet. Following on from the atomic Weston and dmabuf-modifier work, we plan to continue Gustavo Padovan’s work bringing Android fences to mainline Linux, and bring explicit fencing support into Wayland. The support for this is beginning to land properly in Mesa and the kernel, and we plan to make this available to Wayland, for direct clients as well as through the Vulkan WSI.

GDC also brought a new Vulkan release, support for which is being worked on in Mesa by Jason Ekstrand of Intel and Chad Versace of Google. Of particular note for window systems was the long-awaited external memory/image support, making it possible to write Vulkan-based compositors for the first time.

Collabora was also very pleased to announce our involvement in the OpenXR working group, as we explore the AR/VR space together with Khronos and our partners in the industry; watch this space.

Elie Tournier also joined our team, bravely moving to Cambridge during the darkest months of the year. You may recognise the name from his GSoC work developing a pure GLSL library to support double-precision floating-point (FP64) operations on GPUs which otherwise lack native support. Elie has been working with us to bring this to upstream Mesa, integrating it with Mesa’s low-level GLSL IR / NIR to provide transparent support, rather than requiring explicit app support. Welcome Elie!

The X.Org Foundation is also participating in GSoC again this year, offering students the chance to work all throughout the graphics stack (X.Org itself, Mesa, Wayland, and DRM). We look forward to welcoming even more students – and new developers – into the fold.

We’re here to help

The world of open-source graphics can be confusing, and despite some recent stellar efforts, somewhat underdocumented. We pride ourselves in our knowledge of the landscape – including others such as multimedia and core kernel development and hardware enablement – and are always happy to discuss it with you. If you would like to discuss any work or are even just seeking advice, please contact us: our friendly and knowledgable staff are standing by to take your call.