gl4es icon indicating copy to clipboard operation
gl4es copied to clipboard

OpenGL context managers issues

Open mittorn opened this issue 4 years ago • 5 comments

When creating context with SDL or other similar library, you usually do not matter if it use egl/glx/wgl/emscripten/apple, it just gives existing context gl4es uses EGL and has very poor functionality without it ( i'm getting broken textures now, hardware detection disabled), enabling hardware detection breaks it because most of extensions do not work without GetProcAddress. After adding own GetProcAddress to loader.h it works correctly When using gl4es with EGL in SDL application, it crashes because SDL uses GLX instead of EGL to create context (it depend on configuration, version, but usually GLX used when enabled). All contexts have similar XXXGetProcAddress function to implement lookup. There is no way to set GetProcAddress implementation, but there are ifdefs for every platform. Other problem is default visibility forced to all exports. SDL loads libGL.so.1 with RTLD_GLOBAL and it replacing all exports. After removing visibility attributes from AliasExport and stub.c it works. How i see the solution:

  • Add some API like initialize_gl4es() to provide implementation for GetProcAddress and GetMainFBSize implementations (and maybe something i missed, maybe some context switch callbacks?). initialize_gl4es needed anyway when context created elsewhere
  • add some EXPORT macro for default visibility. It may define as " _stdcall declspec(dllexport)" on windows (which does not have symbol visibility) or none in static libraries when export not needed

Other improvements that may make porting easier, but may break existing ports:

  • add common lookup.c implementation for GL only, which have common GetProcAddress function and return only gl (not glx, egl, etc..) functions. Other (glx, agl and something that may be added later) will use it instead of copying all code. This will hepl remove big amount of NOX11 macro checks because not X11 apps do not require GLX. And of cause, using "glXGetProcAddress" function on platforms without X11 is strange.
  • split all non-egl hardware queries to separate funcion/file, this avoids large amount of EGL macros and egl code in non-egl apps

mittorn avatar Feb 22 '20 12:02 mittorn

  • Add some API like initialize_gl4es() to provide implementation for GetProcAddress and GetMainFBSize implementations (and maybe something i missed, maybe some context switch callbacks?). initialize_gl4es needed anyway when context created elsewhere

Mmm ok. So having some default "get_proc" function (depending on the build platform), but gives an API to allow overrrinding it.

  • add some EXPORT macro for default visibility. It may define as " _stdcall declspec(dllexport)" on windows (which does not have symbol visibility) or none in static libraries when export not needed

Should be easy enough, I'll start with that.

  • add common lookup.c implementation for GL only, which have common GetProcAddress function and return only gl (not glx, egl, etc..) functions. Other (glx, agl and something that may be added later) will use it instead of copying all code. This will hepl remove big amount of NOX11 macro checks because not X11 apps do not require GLX. And of cause, using "glXGetProcAddress" function on platforms without X11 is strange.

Yeah, that should not be too difficult to split

  • split all non-egl hardware queries to separate funcion/file, this avoids large amount of EGL macros and egl code in non-egl apps

That may be a bit tricky, I have to think about that (to accomodate cases where EGL is not available, but a context is already present, like Android).

ptitSeb avatar Feb 22 '20 13:02 ptitSeb

So commit 84ff8f0 should address the EXPORT macro.

ptitSeb avatar Feb 22 '20 13:02 ptitSeb

And the lookup split is in commit 7e602ea I haven't done anything special for Android (or Apple) for now, but maybe that would be needed now?

ptitSeb avatar Feb 22 '20 14:02 ptitSeb

android uses EGL, so it does not have something special in lookup. BTW, i found that Android.mk has BCMHOST defined. Why? It is special target with broadcom drivers?

mittorn avatar Feb 22 '20 15:02 mittorn

There was no special reason, I can remove it, I think it's useless.

ptitSeb avatar Feb 22 '20 15:02 ptitSeb