This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• Fixes extension checking on OpenGL ES (SDL_GL_ExtensionSupported.patch, text/plain, 2011-08-26 05:41:29 +0000, 533 bytes)
• Android_GL_GetProcAddress implementation (Android_GL_GetProcAddress.diff, text/plain, 2011-09-06 17:26:22 +0000, 1175 bytes)

Reported in version: HG 2.0
Reported for operating system, platform: Android (All), All

Comments on the original bug report:

On 2011-08-25 17:42:27 +0000, Gabriel Jacobo wrote:

The function SDL_GL_ExtensionSupported in SDL_video.c doesn't seem to be working correctly under OpenGL ES. I think it's because it uses SDL_GL_GetProcAddress("glGetString"); to get the function to get the extensions, and this does not seem to be valid. The attached patch corrects the problem for OpenGL ES 1.1 and 2

On 2011-08-26 03:59:38 +0000, Tim Angus wrote:

I think you forgot to attach a patch :).

On 2011-08-26 05:41:29 +0000, Gabriel Jacobo wrote:

Created attachment 687
Fixes extension checking on OpenGL ES

I need to do a crash course on this bug tracker, I was 100% sure I had attached this.

On 2011-08-26 22:15:09 +0000, Ryan C. Gordon wrote:

The more important question is: why does SDL_GL_GetProcAddress() fail in this case? Is it just unimplemented for OpenGL ES (or Android? etc).

Does it not work with core GLES APIs?

I mean, if it's just flat out busted, I'd rather we fix that, so we can avoid this #ifdef, and correct a platform bug, too.

--ryan.

On 2011-08-27 05:06:50 +0000, Gabriel Jacobo wrote:

I can't claim to have much experience with OpenGL ES at all, but from comparing the OpenGL and OpenGL ES backend, I see that the pattern of dynamically assigned functions via GetProcAddress is not used in ES.

ES 2: http://www.khronos.org/opengles/sdk/docs/man/
ES 1: http://www.khronos.org/opengles/sdk/1.1/docs/man/

It seems that the API for these versions does not have a GetProcAddress, so I don't really think it's an Android exclusive issue. (Though it's always possible other platforms go out of spec and support this..?)

I think this might have gone unnoticed because in ES the extension detection was used only for "GL_OES_draw_texture" and if this extension is not detected as present, rendering goes on anyway.

On 2011-08-27 06:36:41 +0000, Tim Angus wrote:

I'm not sure I get why glGetString is being "loaded" in the first place. Surely it's a core function that's always available?

On 2011-08-27 22:20:51 +0000, Ryan C. Gordon wrote:

(In reply to comment # 5)

I'm not sure I get why glGetString is being "loaded" in the first place. Surely
it's a core function that's always available?

It's so we don't have to link directly against libGL. Apps may not need it, so SDL shouldn't force it to be loaded if you don't.

Also: SDL_GL_LoadLibrary() may point to a different libGL, and we want the glGetString() from that lib, not what the dynamic loader found at launch.

--ryan.

On 2011-08-27 22:21:59 +0000, Ryan C. Gordon wrote:

(In reply to comment # 4)

It seems that the API for these versions does not have a
GetProcAddress, so I don't really think it's an Android exclusive
issue. (Though it's always possible other platforms go out of spec and support
this..?)

It wouldn't be in GLES, it'd be in a platform layer (for regular OpenGL, this would turn into a glX call, or a wgl call, etc).

--ryan.

On 2011-08-27 22:39:09 +0000, Ryan C. Gordon wrote:

Well this explains it...

void *
Android_GL_GetProcAddress(_THIS, const char *proc)
{
__android_log_print(ANDROID_LOG_INFO, "SDL", "[STUB] GL_GetProcAddress\n");
return 0;
}

--ryan.

On 2011-08-28 22:51:18 +0000, Ryan C. Gordon wrote:

(I'm just using this bug report for notes at the moment; you can take yourself off the CC list if this annoys you.)

eglGetProcAddress() is available in the NDK in android-9 and later...

http://www.khronos.org/opengles/documentation/opengles1_0/html/eglGetProcAddress.html

...looks like it maps to the exactly to glXGetProcAddress() (and doesn't have the context restrictions that wglGetProcAddress() has).

--ryan.

On 2011-08-29 04:31:29 +0000, Gabriel Jacobo wrote:

You probably already are aware of these as they are among Google's top hits, but I'll leave it for reference, it seems there is/was trouble with that function:

http://code.google.com/p/android/issues/detail?id=7681

And this confirms it is available in the android-ndk 9:

http://groups.google.com/group/android-ndk/browse_thread/thread/977ab75823cd8013

On 2011-08-31 22:45:19 +0000, Ryan C. Gordon wrote:

(In reply to comment # 6)

It's so we don't have to link directly against libGL. Apps may not need it, so
SDL shouldn't force it to be loaded if you don't.

Also: SDL_GL_LoadLibrary() may point to a different libGL, and we want the
glGetString() from that lib, not what the dynamic loader found at launch.

(Also, fwiw, neither of these are necessarily good reasons on Android, but I'd rather this match as closely as possible on all platforms, and have the platform layers hide the differences when reasonable.)

--ryan.

On 2011-09-06 17:26:22 +0000, Gabriel Jacobo wrote:

Created attachment 699
Android_GL_GetProcAddress implementation

This patch solves the issue while following Ryan's guidelines. I tried to follow a similar route to what the X11 GLES code does but for some reason it doesn't quite work (I can get the eglGetProcAddress function, but when I use it I get SEG FAULTS).
Anyway, this is similar perhaps a little more hackish but it does the job.

On 2011-09-06 17:27:29 +0000, Gabriel Jacobo wrote:

By the way, I grepped inside the Android NDK and the eglGetProcAddress function is present in all libGL from android-4 onwards.

On 2011-10-12 22:32:56 +0000, Ryan C. Gordon wrote:

(In reply to comment # 12)

Created attachment 699 [details]
Android_GL_GetProcAddress implementation

I think this is acceptable for now, until Android's eglGetProcAddress() becomes more reliable.

I made one change, to have dlsym() use the dlopen()'d handle instead of RTLD_DEFAULT. If that causes problems, let me know.

This is now hg changeset 80bd6c922b4e.

I think this should resolve the original issue too (no glGetString), so I'm resolving this bug. Please reopen if we're still busted!

--ryan.

On 2011-10-13 05:38:43 +0000, Gabriel Jacobo wrote:

There seems to be a problem as I'm not seeing this changeset in http://hg.libsdl.org/SDL/. I wanted to test your modifications because if I recall correctly I initially tried what you did (use the dlopen'd handle) and was having problems with that.

On 2011-10-13 21:24:29 +0000, Ryan C. Gordon wrote:

(In reply to comment # 15)

There seems to be a problem as I'm not seeing this changeset in
http://hg.libsdl.org/SDL/. I wanted to test your modifications because if I
recall correctly I initially tried what you did (use the dlopen'd handle) and
was having problems with that.

Whoops, it helps to actually push the changeset. :)

After rebasing, this is now hg changeset f4b73deb9d26, and it's definitely in the public repo this time. Sorry about that!

--ryan.