New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 3078 link

Starred by 3 users

Issue metadata

Status: Accepted
Last visit > 30 days ago
Area: ----
NextAction: ----
Priority: Medium
Type: Defect

Sign in to add a comment

EGL GrGLCreateNativeInterface failing because of eglGetProcAddress

Project Member Reported by, Oct 29 2014

Issue description

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

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, 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, 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, Oct 31 2014

That's a really good idea
Project Member

Comment 4 by, Dec 7 2015

Labels: Hotlist-Fixit

Sign in to add a comment