How to make glproxy suitable for real-world applications
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
- Status:
- Complete
- Approver:
- Jesse Barker
- Priority:
- High
- Drafter:
- Marc Ordinas i Llopis
- Direction:
- Needs approval
- Assignee:
- Marc Ordinas i Llopis
- Definition:
- Discussion
- Series goal:
- None
- Implementation:
-
Implemented
- Milestone target:
-
backlog
- Started by
- Jesse Barker
- Completed by
- Jesse Barker
Whiteboard
Introduction:
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:
http://
