| Summary: | SDL_GL_ExtensionSupported doesnt' work under OpenGL ES | ||
|---|---|---|---|
| Product: | SDL | Reporter: | Gabriel Jacobo <gabomdq> |
| Component: | video | Assignee: | Sam Lantinga <slouken> |
| Status: | RESOLVED FIXED | QA Contact: | Sam Lantinga <slouken> |
| Severity: | normal | ||
| Priority: | P2 | CC: | icculus, tim |
| Version: | HG 2.0 | ||
| Hardware: | All | ||
| OS: | Android (All) | ||
| Attachments: |
Fixes extension checking on OpenGL ES
Android_GL_GetProcAddress implementation |
||
I think you forgot to attach a patch :). Created attachment 687 [details]
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.
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. 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 <something>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. 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? (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. (In reply to comment #4) > It seems that the API for these versions does not have a > <something>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.
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.
(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. 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 (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. Created attachment 699 [details]
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.
By the way, I grepped inside the Android NDK and the eglGetProcAddress function is present in all libGL from android-4 onwards. (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. 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. (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. |
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