Thanks to a new, low overhead extension in Mesa, OpenGL and Vulkan applications can now talk to each other, bringing more flexibility to application developers while easing the transition path between the industry-standard Khronos® APIs.

After several months of work, I'm excited to present a way for OpenGL and Vulkan applications to talk to each other when using Mesa.

Quoting from Khronos's own website, Vulkan promises to be a "new generation graphics and compute API that provides high-efficiency, cross-platform access to modern GPUs". However, as with all new API's, rewrites of any graphics applications leveraging Vulkan are going to be slow process. And not all applications might want to make the switch.

Since Vulkan offers higher efficiency and features missing in OpenGL, an application developer could however choose to rewrite performance critical sections in Vulkan, while keeping other parts in OpenGL for the sake of convenience. This would need a way for OpenGL and Vulkan to talk to each other. As of late 2016, this was formalized in the EXT_external_objects spec that defines primitives for exchanging buffers and synchronization primitives between OpenGL and Vulkan.

Mesa <3 EXT_external_objects

For the past several months Collabora has been working on bringing this functionality to Intel drivers for use by Chromium OS in collaboration with other stakeholders in Mesa.

The Iris driver, supporting modern Intel GPUs using Mesa's Gallium framework, first received this support thanks to work from Igalia. This was then followed by support for the i965 driver, supporting older Intel GPUs thanks to work done by Collabora.

The very first steps to really get this extension off the ground was to extend piglit tests to be able to confidently push forward feature work on the driver side. Eleni Maria Stea has a excellent series of blog posts covering this work that I highly recommend checking out to fully understand how the spec works from a applications point of view (a word of caution: it is a 10 part series).

Once that was underway, the Iris driver was extended to support the new EXT_external_objects spec. The ongoing merge request for that can be found over here. Having understood all of the above over the course of a few weeks, it was time for me to begin implementing the equivalent for the i965 side of things. The only major hiccup being that i965 does not make use of the Gallium framework within Mesa that most modern drivers end up using. This meant translating concepts back and forth between the Gallium and pre-Gallium world. While tedious, it was a great learning experience to be able to dive into both architectures. Eventually, I opened a equivalent merge request for i965. A special shout out to Eleni, Tapani Pälli and Faith Ekstrand for paving the way for me to be able to put this together. As noted in the MR's, excepting depth/stencil buffer support, this should now be feature complete!

Emulating OpenGL features

VirGL is a project that allows for creating a virtual 3D GPU for use inside virtual machines, which enables the guest operating system to use the capabilities of the host GPU to accelerate 3D rendering.

Getting this functionality merged into Mesa would allow VirGL guests to be able to create buffers with a persistent mapping by allocating the buffer storage through GBM on hosts that do not support ARB_Buffer_Storage, and importing them into VirGL.

The road ahead

Implementing this feature allows application developers to be able to use Vulkan for their rendering needs while using OpenGL for everything else and while piglit tests pass, they are by no means a real world usecase. We're finding corner cases when running first class applications that make use of this new feature, allowing us to expand our test coverage and make the code more robust. I'd like to encourage application developers to try out this new feature and report their findings on the merge requests to help the Mesa community make the drivers more robust.

Bringing this feature to i965 and Iris allows Mesa to keep being a competitive player in the graphics world and merging this feature in allows for a very exciting future!

Related Posts

OpenGL on DirectX: Conformance & upstreaming of the D3D12 driver

Desktop OpenGL 3.1 on Mali GPUs with Panfrost

Deep dive into OpenGL over DirectX layering

Related Posts

OpenGL on DirectX: Conformance & upstreaming of the D3D12 driver

Desktop OpenGL 3.1 on Mali GPUs with Panfrost

Deep dive into OpenGL over DirectX layering