Gitiles
Code Review Sign In
gerrit-public.fairphone.software / platform / external / libepoxy / 7c4817f2eed2faf0353c1ceb5f38b500f6aff7cf
commit7c4817f2eed2faf0353c1ceb5f38b500f6aff7cf[log] [tgz]
authorAdam Jackson <ajax@redhat.com>Wed Jul 12 13:26:05 2017 -0400
committerAdam Jackson <ajax@redhat.com>Wed Jul 12 14:05:54 2017 -0400
tree51e3c1779514b1d2e076c04e81502c809a6ac125
parentf81274b12470a0ce8678465112998708f63c3559 [diff]
dispatch: Be more paranoid about detecting GLX or not

This code attempts not to dlopen anything if it can find the appropriate
winsys symbols in the global namespace. That's nice. However we normally
do dlopen(RTLD_LOCAL) when we open lib{GLX,EGL} so those symbols will
_not_ in fact be in the global namespace. The code also prefers checking
GLX to EGL, which means even if we initialize EGL through epoxy, and
even if we're using glvnd, we'll still dlopen libGL the first time we
hit epoxy_is_desktop_gl().

There's a couple of ways to skin this cat, let's take the easy one. If
either-but-not-both of the glx or egl handles in the global API state
are initialized, then we know we're already in one or the other. If
neither or both are initialized, then the current heuristic should work
fine.

Note that epoxy_is_desktop_gl() is only bothering to check for GLX to
work around PowerVR's broken GLES. One suspects a better way to do that
would be to check GL_VENDOR or GL_RENDERER and avoid probing the window
system at all.

Signed-off-by: Adam Jackson <ajax@redhat.com>
1 file changed
tree: 51e3c1779514b1d2e076c04e81502c809a6ac125
  1. cross/
  2. doc/
  3. include/
  4. registry/
  5. src/
  6. test/
  7. .appveyor.yml
  8. .dir-locals.el
  9. .editorconfig
  10. .gitignore
  11. .travis.yml
  12. autogen.sh
  13. configure.ac
  14. COPYING
  15. epoxy.pc.in
  16. Makefile.am
  17. meson.build
  18. meson_options.txt
  19. README.md
README.md

Build Status Build status

Epoxy is a library for handling OpenGL function pointer management for you.

It hides the complexity of dlopen(), dlsym(), glXGetProcAddress(), eglGetProcAddress(), etc. from the app developer, with very little knowledge needed on their part. They get to read GL specs and write code using undecorated function names like glCompileShader().

Don't forget to check for your extensions or versions being present before you use them, just like before! We'll tell you what you forgot to check for instead of just segfaulting, though.

Features

  • Automatically initializes as new GL functions are used.
  • GL 4.5 core and compatibility context support.
  • GLES 1/2/3 context support.
  • Knows about function aliases so (e.g.) glBufferData() can be used with GL_ARB_vertex_buffer_object implementations, along with GL 1.5+ implementations.
  • EGL, GLX, and WGL support.
  • Can be mixed with non-epoxy GL usage.

Building

mkdir _build && cd _build
meson
ninja
sudo ninja install

Dependencies for Debian:

  • meson
  • libegl1-mesa-dev

Dependencies for macOS (using MacPorts):

  • pkgconfig
  • meson

The test suite has additional dependencies depending on the platform. (X11, EGL, a running X Server).

Switching your code to using epoxy

It should be as easy as replacing:

#include <GL/gl.h>
#include <GL/glx.h>
#include <GL/glext.h>

with:

#include <epoxy/gl.h>
#include <epoxy/glx.h>

As long as epoxy's headers appear first, you should be ready to go. Additionally, some new helpers become available, so you don't have to write them:

int epoxy_gl_version() returns the GL version:

  • 12 for GL 1.2
  • 20 for GL 2.0
  • 44 for GL 4.4

bool epoxy_has_gl_extension() returns whether a GL extension is available (GL_ARB_texture_buffer_object, for example).

Note that this is not terribly fast, so keep it out of your hot paths, ok?

Why not use libGLEW?

GLEW has several issues:

  • Doesn't know about aliases of functions (There are 5 providers of glPointParameterfv(), for example, and you don't want to have to choose which one to call when they're all the same).
  • Doesn't support OpenGL ES.
  • Doesn't support EGL.
  • Has a hard-to-maintain parser of extension specification text instead of using the old .spec file or the new .xml.
  • Has significant startup time overhead when glewInit() autodetects the world.
  • User-visible multithreading support choice for win32.

The motivation for this project came out of previous use of libGLEW in piglit. Other GL dispatch code generation projects had similar failures. Ideally, piglit wants to be able to build a single binary for a test that can run on whatever context or window system it chooses, not based on link time choices.

We had to solve some of GLEW's problems for piglit and solving them meant replacing every single piece of GLEW, so we built piglit-dispatch from scratch. And since we wanted to reuse it in other GL-related projects, this is the result.

Known issues when running on Windows

The automatic per-context symbol resolution for win32 requires that epoxy knows when wglMakeCurrent() is called, because wglGetProcAddress() returns values depend on the context's device and pixel format. If wglMakeCurrent() is called from outside of epoxy (in a way that might change the device or pixel format), then epoxy needs to be notified of the change using the epoxy_handle_external_wglMakeCurrent() function.

The win32 wglMakeCurrent() variants are slower than they should be, because they should be caching the resolved dispatch tables instead of resetting an entire thread-local dispatch table every time.