ptitSeb / gl4es

GL4ES is a OpenGL 2.1/1.5 to GL ES 2.0/1.1 translation library, with support for Pandora, ODroid, OrangePI, CHIP, Raspberry PI, Android, Emscripten and AmigaOS4.
http://ptitseb.github.io/gl4es/
MIT License
711 stars 160 forks source link

No gl rendering after destroying and recreating the surface #67

Open dpeddi opened 6 years ago

dpeddi commented 6 years ago

I'm trying to get running emulationstation on an embedded platform that doesn't provide gl but only gles2.

To get so I had to patch sdl2 to include some vendor function.

I have all running but when emulationstation start a new emulator it close SDL and reopen it when the emulator exits. When emulationstation come back I have just a white background and nothing rendered.

I've tried to write a small test program to figure out the issue.

I get the background colour rendered correctly on the second init but not the drawing as well.

Could be an issue with gl4es GL2 implementation?

Regards

ptitSeb commented 6 years ago

Maybe it is. GLX Context creation / deletion is bit complex.

If you can copy/paste libGL console printf, that can help.

Also, uncomment line #37 of src/glx/glx.c to enable many log on glX function, that could also help understanding the issue.

For now, I have seen that deleting than recreation a context on the same window (so without destroying and recreating the window) as a tendancy to fail. EGL doesn't seems to really free the context, and the recreation fail. I haven't coded a workaround for that issue yet (I have one in mind, but haven't taken the time to code it yet). Not sure you are facing that same issue.

dpeddi commented 6 years ago

Thank you, I'll do... You avoided me to dissect the whole source code to locate how to increase loglevel.

dpeddi commented 6 years ago

well, I don't have so much debug information: I've compiled gl4es with set(NOX11 ON) set(NOEGL ON)

so i create the context externally.

when the screen is white I can read: [...] Use FPE program 9 glVertexAttribPointer(0, 2, GL_FLOAT, 0, 16, 0x3e6bf0) glVertexAttribPointer(1, 4, GL_UNSIGNED_BYTE, 1, 0, 0x3e6e38) glVertexAttribPointer(2, 2, GL_FLOAT, 0, 16, 0x3e6bf8) [...]

ptitSeb commented 6 years ago

I don't think FPE program is to blame (but you can have log of compile failure using LIBGL_LOGSHADERERROR=1 evironnement variable). I think it's more an issue on the context creation. Can you copy/paste all the init part, with the glX function call (once you activate DEBUG in glx.c) ?

dpeddi commented 6 years ago

Sorry, I don't have x11 on that board, so the context is created with vendor function. by activating DEBUG in glx I don't get any more verbose output

ptitSeb commented 6 years ago

Ah ok, fine. So you built with "NOX11", and possibly "NOEGL"? Or do you have EGL?

What are the function for creating and destroying an EGL surface?

Also, are you using "LIBGL_FB=1" maybe, or "LIBGL_FB=3"?

dpeddi commented 6 years ago

Hi, The GLES initializatio code was taken from this example code: http://archive.vuplus.com/download/build_support/libvupl-example-cube-0.2.1.r1.tar.gz

it should be based on https://github.com/benosteen/opengles-book-samples chapter8 for linuxX11 and patched for their platform.

By referencing the libvupl library I get some function that wraps to the low level Broadcom Nexus API

These are the definition (i'm using the one in bold): vuInitResult VUGLES_InitPlatform(const char *name);* vuInitResult VUGLES_InitPlatformAndDefaultDisplay(const char name, float aspect, uint32_t w, uint32_t h); extern void VUGLES_GetDefaultNativeWindowInfo(VUGLES_NativeWindowInfo info); void VUGLES_RegisterDisplayPlatform(VUGLES_PlatformHandle handle); VUGLES_CreateNativeWindow(const VUGLES_NativeWindowInfo info); int VUGLES_GetClientID(void nativeWin); void VUGLES_SetPosition(int clientID, vuRect rect, bool immediately); extern void VUGLES_UpdateNativeWindow(void nativeWin, const VUGLES_NativeWindowInfo info); extern void VUGLES_SetVisible(int clientID, bool visible); extern void VUGLES_SetVirtualDisplay(int clientID, int width, int height, bool immediately); void VUGLES_DestroyNativeWindow(void *nativeWin); void VUGLES_UnregisterDisplayPlatform(VUGLES_PlatformHandle handle); void VUGLES_TermPlatform(void);

I've patched that gles2 example code to keep opened the window, and if I keep it open in the example code I can keep it open and play with zorder instead create and destroy the window...

If I close and reopen the window with their code I get a lot of GLES2 Overflow... so... maybe they have issue in their implementation.

About LIBGL_FB I'm actually not considering it at yet. Should I do it?

REgards

ptitSeb commented 6 years ago

Mmm, indeed, if in the sample you have issue with a create/delete/create native window context scenario, then it will be the same in gl4es.

I want to create an option the not delete context and recycle them, but I haven't worked on that yet. That will probably be the solution for your case.

About LIBGL_FB, well, LIBGL_FB=3 create a PixMap or PBuffer surface (depending if PixMap are availbale, PBuffer as backup) instead of a native window, and that blit the image in the X11 window (so PixMap are faster). If using PBuffer, it can be slower (PixMap are usualy as fast, and even somtimes faster than Native window?!!!), but it should work. LIBGL_FB=1 is for using the FrameBuffer directly, and so bypassing X11, so maybe it's not applicable in your case.

ptitSeb commented 6 years ago

@dpeddi : is that issue still present? It should be fixed now with latest commit.

dpeddi commented 6 years ago

I have to find some spare time to test.. i'll let you know early

Il sab 13 ott 2018, 21:43 ptitSeb notifications@github.com ha scritto:

@dpeddi https://github.com/dpeddi : is that issue still present? It should be fixed now with latest commit.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ptitSeb/gl4es/issues/67#issuecomment-429569803, or mute the thread https://github.com/notifications/unsubscribe-auth/ABCVX6eBvGvZpeX4z43__HvKXP3O_hF9ks5ukkJqgaJpZM4V5m3E .

dpeddi commented 6 years ago

Just tested... It seems it work not so different then before...when emulationstation comes back the surface is white

should I try to enable logging again? regards

ptitSeb commented 6 years ago

If you can do that, yes please, because it seems it's not the issue I thought it was...

ptitSeb commented 5 years ago

Just to note, I have submited some fix in the destroy surface / context code. Maybe it fixed your issue, if you have some time to re-test.

dpeddi commented 5 years ago

no, sorry the issue still persist

ptitSeb commented 5 years ago

Ah, ok :(