| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
tests with CMake. Add support for linking with the static run-time library with MSVC.
|
| |
|
|
|
|
| |
support for Android. Add built-in support for building with EGL support (using "khrplatform.h" and "eglplatform.h" which are distributed together with Epoxy, and should work with any platform).
|
| |
|
|
|
|
| |
appropriate. Fix tests build errors.
|
|
|
|
|
|
| |
Since our provider enums are small, we can store them as bytes or
shorts if we just let the compiler know that it's OK. Saves 20kb in
the compiled library.
|
|
|
|
|
|
|
|
| |
According to the OpenGL ES standard, "glGetString(GL_VERSION)" should
return a string starting with "OpenGL ES". However, PowerVR's OpenGL
ES implementation (and perhaps others) don't comply with the standard
here. If our context happend to be bound using EGL, then we can just
ask EGL what kind of context it was, avoiding the glGetString() check.
|
|
|
|
|
| |
The windows ABI is GL 1.1, not 1.0. You get NULL pointers for 1.1
functions when calling wglGetProcAddress(). Fixes #47.
|
|
|
|
|
|
|
| |
Don't mark epoxy_conservative_gl_version() for export, as it is meant
to be a private API to be used within libepoxy only.
Reviewed-by: Eric Anholt <eric@anholt.net>
|
|
|
|
|
| |
Visual Studio does not like __stdcall before the return type, which is
what GLAPIENTRY and EPOXY_CALLSPEC expands to on Windows.
|
|
|
|
|
| |
It is a C99 feature that is not supported (nor will it probably be at
any point) on Visual Studio.
|
| |
|
|
|
|
| |
Fixes #29.
|
|
|
|
|
| |
I've decided it's time to accept that building with MSVC 2010 is a way
that people want to use this software.
|
|
|
|
|
|
|
|
| |
This has been tested with both OpenGL and OpenGL ES on Android.
We can't use dlsym on Android to get all the function pointers since Android's libGLES* libraries are just shim libraries that pass everything through
to the real vendor specific libraries.
Due to this we must grab function pointers entirely through eglGetProcAddress instead of dlsym.
|
|
|
|
|
|
|
| |
Fixes failure of the X Server with glamor using desktop GL on EGL, and
the associated testcase in the tree. This was clearly just
copy-and-paste failure on my part in
b251e3ae337cecda3cbede6fde8cc8f7cef942c9.
|
|
|
|
|
|
|
| |
Now that it's split out from epoxy_get_core_proc_address(),
the particular symbols we were testing for before calling
GetCurrentContext() didn't make much sense, plus we were leaking
dlerror()s still.
|
|
|
|
| |
Fixes #24
|
|
|
|
|
| |
It turns out I need to reuse this for GLES symbols when using
GLX_EXT_create_context_es2_profile.
|
|
|
|
| |
Again, no known bugs, but it seems like a bad idea.
|
|
|
|
| |
No reported bugs I'm fixing here, just cleanup.
|
| |
|
|
|
|
|
|
| |
If you already had GLX loaded by epoxy, this wouldn't happen, but on
the first call, fallback cases might have taken the EGL path if EGL
was loaded.
|
|
|
|
| |
I want to reuse this from get_core_proc_address().
|
|
|
|
|
|
|
| |
Fixes the GLX-only subtest of egl_and_glx_different_pointers. Now
what remains is dispatch tables for when you're actively using both.
Fixes #23
|
|
|
|
| |
Fixes the EGL-only subtest of egl_and_glx_different_pointers.
|
|
|
|
|
| |
This is the case on the nvidia binary driver's GL, or when you've got
a system mixing nvidia binary GL and Mesa EGL.
|
|
|
|
|
|
|
| |
ARM and Mesa disagreed on how to look up the functions, so support
both ways.
Fixes #21
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes crashes on ARM's Mali drivers, where desktop GL isn't
supported, and epoxy didn't notice the error and tried to dlsym() on
libGL.so.1.
An alternative would have been to look at the response from
eglQueryAPI() first, but that would have meant that we still need to
BindAPI in the case that eglQueryAPI returns something like VG or CL,
and so we needed to handle these errors regardless.
Fixes #22
|
| |
|
| |
|
| |
|
|
|
|
| |
Fixes #19
|
|
|
|
|
|
| |
If you happened to do both GLES2 and GLES1 in a process, it meant that
you'd try to look up v1 procs in the v2 API, and lose. Caught by
piglit oes_fixed_point-attribute-arrays.
|
|
|
|
|
| |
Mesa reports "OpenGL ES-CM 1.1", so we need to not look for a space
after "ES", and 1.1 is still a 1.0-compatible implementation.
|
|
|
|
|
|
|
|
|
|
| |
For performance, I want to be able to make single-context (well,
single-pixel-format-and-device) apps be able to directly call GL
functions through function pointers. Bake that into the ABI now so I
can get a release out the door and fix this up later.
This also fixes the lack of __stdcall annotation on the
PFNWHATEVERPROC typedefs.
|
| |
|
|
|
|
|
| |
If you accidentally call it on a non-egl platform, better to get an
informative error message.
|
|
|
|
|
| |
This should help get us better error handling when we accidentally
call the wrong loader path.
|
|
|
|
| |
Not sure how I misplaced the \n in the previous fix.
|
|
|
|
|
|
| |
For a non-GLX application, at least, we need to pull our extensions
using dlsym, not glXGetProcAddress(). The symptom was a segfault in
glXGetProcAddress().
|
|
|
|
|
|
|
|
| |
In addition to the failing testcase, there were a couple of
regressions in piglit's attribs test: one from glBegin_unwrapped vs
glBegin confusion in the __asm__ directives we were generating, and
one where the function pointers apparently were just getting mixed up
at application runtime.
|
|
|
|
|
| |
This should give us a more informative failure mode than the one
mentioned in the README.
|
|
|
|
| |
We could keep examining the same ptr value over and over.
|
| |
|
| |
|
|
|
|
|
| |
It doesn't exist. There's EAGL, but that's not something we're
covering.
|
|
|
|
| |
This is very poorly tested at this point, but survives a simple testcase.
|
| |
|
|
|
|
|
|
| |
This is going to change for macos and win32, and this will be easier
than trying to spread that logic through the python code and into the
generated code.
|