New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 3 users
Status: Accepted
Owner:
Last visit > 30 days ago
Cc:
Area: ----
Priority: Medium
Type: Defect



Sign in to add a comment
EGL GrGLCreateNativeInterface failing because of eglGetProcAddress
Project Member Reported by deanm@chromium.org, Oct 29 2014 Back to list
The EGL version of GrGLCreateNativeInterface is using eglGetProcAddress (via egl_get_gl_proc).  This was failing in an EGL environment, according to the EGL spec (1.3):

eglGetProcAddress may not be queried for core (non-extension)
functions in EGL or client APIs . For functions that are queryable
with eglGetProcAddress, implementations may choose to also export
those functions statically from the ob- ject libraries implementing
those functions. However, portable clients cannot rely on this
behavior.

However, Skia is trying to query all function pointers through eglGetProcAddress, however it seems it is only intended and working for extension functions, not for core functions.

I remedied this for my case by falling back to dlsym(RTLD_DEFAULT), however this no longer makes it EGL-portable but now relies on a posix-like environment for dlsym().
 
Project Member Comment 1 by bsalo...@google.com, Oct 29 2014
It seems like this can only be solved in a platform specific way, or by pulling in a GL header and linking against a gl lib.

Thus far we've avoided the latter because we sometimes want multiple types of GL in the same build (e.g. native GL and ANGLE in the windows build) and have had issues with accidentally linking in the wrong implementation gl* functions.

The assemble interface stuff means that the platform specific code is pretty small - a wrapper around dlsym and/or the windowing system's GL GetProcAddress (eglGetProcAddress, wglGetProcAddress, ...).

I'm not really sure what to do here, but open to any suggestions. Also, happy to collect platform specific implementations in the code base as long as they're testable in our automated build system.
Project Member Comment 2 by deanm@chromium.org, Oct 29 2014
Why not expose the callback so that the caller is responsible for supplying a function to resolve the function names?  It means you don't just have GrGLCreateNativeInterface but maybe you have GrGLCreateNativeInterfaceWithFunctionLookerUpper() or whatever, but it solves the problem in a way without making much impact on Skia's build and multiple GL configurations.  It just makes it the callers problem to resolve.
Project Member Comment 3 by bsalo...@google.com, Oct 31 2014
That's a really good idea
Project Member Comment 4 by hcm@google.com, Dec 7 2015
Labels: Hotlist-Fixit
Sign in to add a comment