[RK3326/Mali] Renderdoc+libGLEW Hangs

[JohnnyonFlame]

Hello,

I'm trying to get box86 to run games on an RK3326 powered device using a Mali G31 GPU (ArkOS, libmali-rk-bifrost-g31-rxp0-wayland-gbm_1.7-2+deb10_armhf drivers from HardKernel), using Shovel Knight as a starting point.

Issue is, I'm getting no graphics output on Shovel Knight. I attempted to kill the Framebuffer code in GL4ES by returning from the specific calls and skipping the last glDrawArrays call when certain conditions are met (to skip a fullscreen blit), the result were garbled graphics, like if only the lower right pixel of the textures were present and nothing more, so you could see a little pixel running around in place of enemies, the player character, main menu elements, anything.

In an attempt to debug this issue, I've built Renderdoc with a quick and dirty patch to enable headless replay which looked promising enough

Until it hung on glXGetProcAddressARB from libGLEW.so.1.10.

Any ideas on how to debug the hang, or why such a thing would happen?

[ptitSeb]

I think this is more a gl4es issue than a box86.

Did you tried LIBGL_FB=4 to use (experimental) gbm backend of gl4es?

[JohnnyonFlame]

I think this is more a gl4es issue than a box86.

Did you tried LIBGL_FB=4 to use (experimental) gbm backend of gl4es?

Thanks for the quick reply - yes, that's what I'm using to get graphics. In fact, the sdlgears running on the renderdoc output is running with GL4ES under box86 and being captured remotely by renderdoc (it's the simplest test app I could think of.) and it's working perfect as far as the eye can see.

edit: I also managed to get graphics output with box86+GL4ES in Postal w/o the dynarec, but it crashes with the Dynarec enabled - but I digress, that's something for another issue.

[ptitSeb]

ShovelKnight runs fine on my side with box86+box86, but I don't have hardware configured for LIBGL_FB=4... ShovelKnight use OpenGL 2.1 with Shaders and X11 to setup the Windows IIRC...

[JohnnyonFlame]

It seems to call into the native libSDL2.0 library and setup the window/renderer there, but also calls the affected glxGetProcAddressARB function, and despite initializing it displays weird broken graphics. I am guessing this is some sort of driver quirk because otherwise, I have copied the code related to framebuffer binding and blitting into sdlgears using an apitrace of Shovel Knight running with GL4ES as reference and it does render to the FBO correctly, and also draws the FBO texture to the screen correctly.

Without being able to figure out why glxGetProcAddressARB hangs when renderdoc is attached, the only alternative is slowly creating reproduction code by extracting assets with a known working linux box running Shovel Knight+GL4ES and renderdoc, but I'd rather not have to do that for every single graphical issue.

[ptitSeb]

glxGetProcAddressARB is the function that gives GL pointer functions. It's a crutial one, but also a complicated one for soft like RenderDoc or APITrace...

[JohnnyonFlame]

By setting BOX86_NOSIGSEGV=1 the gdb instance attaches properly, seems like renderdoc also adds some signal handlers, this allowed me to find the underlying issue (eglGetPlatformDisplay didn't exist, but renderdoc still exposed and tried to execute it despite it not being present on my system, should probably report that on renderdoc's github...).

There were some annoying red herrings in the process - the first screenshot didn't actually load GL4ES, and I hadn't noticed it.

By disabling GL/GLX hooks I managed to hook the underlying GLESv2 calls and get this:

Closing this issue.