We're hiring!

En route to a robust GPU device selection in GL

Emil Velikov avatar

Emil Velikov
August 21, 2018

Share this post:

Some history

As we all know, OpenGL is an aging API which originated in the 1990s. Despite that, it uses modular structure, allowing new features to be added via extensions. An extremely useful approach, proven to be robust and used by many other APIs - OpenCL and Vulkan are the more well known.

Although, OpenGL in itself is the rendering API, the windowing system binding APIs such as GLX, WGL and EGL, are showing their age as well. An era where multi GPU systems were extremely uncommon and even harder to find.

Fast-forward to present days: dual GPU systems are becoming the norm, with platforms using 16 or even 32 not being unheard of.

So how did the API evolve, how do we handle multi GPUs installed on the same system? Solutions vary across vendors, but in Mesa we have DRI_PRIME.


DRI_PRIME is an environment variable, initially introduced to work with two GPUs. By setting it to 1 prior to calling their application, the GL stack will query the X server and use the "other" GPU present on the system.

That was a good initial solution, although it brought a number of questions:

  • What would the "other" device be, if the system had 3 or more GPUs?
  • How do we handle systems without X server?
  • How can the developer decide which GPU their application should use?

With the first question being more urgent, the community came with a solution: Allow the user to select the device by listing the device ID_PATH_TAG, as provided by udev, in DRI_PRIME.

With that ticked off, how do we handle the other two? Thanks to the extendable structure of EGL, we can accomplish that with the EGLDevice family of extensions.

Enter EGLDevice

The EGL_EXT_device_base extension is implemented in terms of EGL_EXT_device_enumeration and EGL_EXT_device_query.

They define the concept of EGLDevice, the means of enumerating and querying device specific attributes. Another two extensions EGL_EXT_device_drm and EGL_MESA_device_software define respectively hardware devices, backed with a DRM device node and software devices - as available in Mesa, but not many other GL implementations.

Another extension EGL_EXT_platform_device, defines a way of using an EGLDevice, yet without an explicit awareness of the underlying windowing system.

Which means that we can create a context, although we cannot test and analyse the interactions with the Android, Wayland compositor or X11 that's underneath. To address that, EGL_EXT_explicit_device was proposed - allowing us to select, simultaneously, the device and the platform to be used.


As pointed earlier, the set of extensions allows us to explicitly select which device we want to use.

Hence, the use-cases are only limited to one's imagination. Here are a few that come to mind:

  • Render the graphics server/windowing manager with on the less power hungry device, while gaming on the more powerfull one.
  • Having a dedicated device per task - to crunch the untrusted WebGL, time sensitive GPU tasks, etc.

My personal interest is testing and development. We could easily have a single system with multiple GPUs instead of one system per GPU. That will make it easier for driver developers to test across different devices, improving the process and robustness of the drivers.

Implementation status

As part of the process, I have provided patches for Mesa and the Piglit testing suite. They cover the following extensions:

At the time of writing, the Piglit patches have been merged, while the Mesa ones are on the mailing list awaiting review.

  • EGL_EXT_device_base - implementing both EGL_EXT_device_enumeration and EGL_EXT_device_query
  • EGL_EXT_device_drm
  • EGL_MESA_device_software
  • EGL_EXT_platform_device

In my testing, they have proved to be in fairly good shape, although further testing and review is needed.

Future work

While the extension EGL_MESA_device_software is in good shape, we are planning to follow the official Khronos process and ratify it. Additionally, a few questions were raised in the EGL_EXT_explicit_device spec, which will need to be resolved and Mesa implementation will be required.

While that covers most issues, one corner-case remains - how can one do the same with X? GLX does not have such a set of extensions. Our goals is to draft and bring them forward to Khronos. Thus projects which aim to simplify all the platform specifics for you, such as Waffle and SDL, they will have a consistent way of handling device selection.

Which brings us to the final piece. We are planning to design and implement a user-friendly API for Waffle, that makes use of the extensions.


  • Nvidia for designing the initial set of EGLDevice extensions.
  • Adam Jackson for EGL_MESA_device_software and EGL_EXT_explicit_device.
  • My employer Collabora for funding all this work.

Want to hear more?

I'll be giving a talk about this and the Mesa releasing this September at XDC 2018 in A Coruña, Spain. A dozen Collaborans will be in attendance as well, so please come say hello!

Comments (0)

Add a Comment

Allowed tags: <b><i><br>Add a new comment:

Search the newsroom

Latest Blog Posts

An xrdesktop summer of code


This summer, Christoph Haag and I had the pleasure of taking part in Google Summer of Code as mentors for xrdesktop, the Open Source project…

Adding VP9 and MPEG2 stateless support in v4l2codecs for GStreamer


Earlier this year, from January to April 2021, I worked on adding support for stateless decoders for GStreamer as part of a multimedia internship…

Bag of Freebies for XR Hand Tracking: Machine Learning & OpenXR


In our previous post, we presented a project backed by INVEST-AI which introduces a multi-stage neural network-based solution. Now let's…

Testing cameras with lc-compliance on KernelCI


Initiated as a joint effort by the Google Chrome OS team and Collabora, the recent KernelCI hackfest brought the addition of new tests including…

Zink: Summer 2021 update


There's a lot that has happened in the world of Zink since my last update, so let's see if I can bring you up to date on the most important…

Open Source OpenGL ES 3.1 on Mali GPUs with Panfrost


Panfrost, the open source driver for Arm Mali, now supports OpenGL ES 3.1 on both Midgard (Mali T760 and newer) and Bifrost (Mali G31, G52,…

Open Since 2005 logo

We use cookies on this website to ensure that you get the best experience. By continuing to use this website you are consenting to the use of these cookies. To find out more please follow this link.

Collabora Ltd © 2005-2021. All rights reserved. Privacy Notice. Sitemap.

Collabora Limited is registered in England and Wales. Company Registration number: 5513718. Registered office: The Platinum Building, St John's Innovation Park, Cambridge, CB4 0DS, United Kingdom. VAT number: 874 1630 19.