How to make glproxy suitable for real-world applications

Registered by Jesse Barker

Planning to take glproxy from a proof of concept level to a library suitable for integration into a real-world application like glcompbench (for example).

Blueprint information

Jesse Barker
Marc Ordinas i Llopis
Needs approval
Marc Ordinas i Llopis
Series goal:
Milestone target:
milestone icon backlog
Started by
Jesse Barker
Completed by
Jesse Barker

Related branches



The glproxy library's objective is to help with two common problems for OpenGL and OpenGL ES applications:
- The two APIs are almost the same, but due to both libraries exporting the same symbols, it's impossible to link to both at the same time, thus precluding choosing one or the other at run-time.
- There are two different APIs to access an OpenGL context: GLX is the traditional way of accessing OpenGL on X, and EGL is the newer API which, in theory, could be used to access both APIs but is usually limited to OpenGL ES.

At the moment glproxy solves the first problem by virtualizing the API calls: Depending on what the application asks for and the target system, it loads one of the API libraries and resolves its calls at run-time.

Applications using glproxy should also be able to access an OpenGL or OpenGL ES context without worrying about which API is present in the system. Right now glproxy doesn't help with this, and applications must choose whether to use GLX or EGL to create and access a rendering context. This means having to maintain at least two code paths in the application: One for doing so through GLX and another one for EGL.

Meeting agenda:
- How can glproxy allow applications to access whatever API is installed in a simple way? Some proposals are a simple API and implementing EGL on top of GLX.
- Extension handling.
- Testing and LAVA support.

Notes from the session:


Work Items

This blueprint contains Public information 
Everyone can see this information.