GL4ES does not initialize in Mono games on the RPi

[HelloOO7]

Using your guide in the ODROID magazine, I've set up a gl4es environment for Mono based games (Stardew Valley to be precise, I am not expecting it to run good, it's just a fun project).

Any attempt to launch the game results in an OpenGL extension compatibility error. However, from my past experiences with gl4es, it does not seem to be running. Here's the full terminal output:

Could not get EGL display
Invalid window
displayIndex must be in the range 0 - 0
Invalid window
displayIndex must be in the range 0 - 0
Invalid window
Invalid window
[ERROR] FATAL UNHANDLED EXCEPTION: System.PlatformNotSupportedException: MonoGame requires OpenGL 3.0 compatible drivers, or either ARB_framebuffer_object or EXT_framebuffer_object extensions.Try updating your graphics drivers.
  at OpenGL.GraphicsContext..ctor (OpenGL.IWindowInfo info) [0x00045] in <fc7453fea4a743f685f56e963b9ce2a9>:0 
  at OpenGL.GL.PlatformCreateContext (OpenGL.IWindowInfo info) [0x00000] in <fc7453fea4a743f685f56e963b9ce2a9>:0 
  at OpenGL.GL.CreateContext (OpenGL.IWindowInfo info) [0x00000] in <fc7453fea4a743f685f56e963b9ce2a9>:0 
  at Microsoft.Xna.Framework.Graphics.GraphicsDevice.PlatformSetup () [0x0002b] in <fc7453fea4a743f685f56e963b9ce2a9>:0 
  at Microsoft.Xna.Framework.Graphics.GraphicsDevice.Setup () [0x00033] in <fc7453fea4a743f685f56e963b9ce2a9>:0 
  at Microsoft.Xna.Framework.Graphics.GraphicsDevice..ctor (Microsoft.Xna.Framework.Graphics.GraphicsAdapter adapter, Microsoft.Xna.Framework.Graphics.GraphicsProfile graphicsProfile, Microsoft.Xna.Framework.Graphics.PresentationParameters presentationParameters) [0x000f0] in <fc7453fea4a743f685f56e963b9ce2a9>:0 
  at Microsoft.Xna.Framework.GraphicsDeviceManager.Initialize () [0x00085] in <fc7453fea4a743f685f56e963b9ce2a9>:0 
  at Microsoft.Xna.Framework.GraphicsDeviceManager.CreateDevice () [0x00000] in <fc7453fea4a743f685f56e963b9ce2a9>:0 
  at Microsoft.Xna.Framework.GamePlatform.BeforeInitialize () [0x00037] in <fc7453fea4a743f685f56e963b9ce2a9>:0 
  at Microsoft.Xna.Framework.SdlGamePlatform.BeforeInitialize () [0x00016] in <fc7453fea4a743f685f56e963b9ce2a9>:0 
  at Microsoft.Xna.Framework.Game.DoInitialize () [0x00006] in <fc7453fea4a743f685f56e963b9ce2a9>:0 
  at Microsoft.Xna.Framework.Game.Run (Microsoft.Xna.Framework.GameRunBehavior runBehavior) [0x00033] in <fc7453fea4a743f685f56e963b9ce2a9>:0 
  at Microsoft.Xna.Framework.Game.Run () [0x0000c] in <fc7453fea4a743f685f56e963b9ce2a9>:0 
  at StardewValley.Program.Main (System.String[] args) [0x00028] in <a34eed43f73946abb9480bc07ff05f6d>:0 

As you can see, there are no LIBGL: outputs whatsoever. Considering it's confirmed to work on ODROID and Pyra, I suspect there may be some specific problems on the Pi branch.

[ptitSeb]

Is libGL.so built and in the same folder as the rest, and with the LD_LIBRARY_PATH referencing it?

I assume it is (but it's better be checked twice), does libGL runs with a simple glxgears or something similar? There seems to be an error with EGL that doesn't seems to come from gl4es, so it seems libGL from gl4es is not used somehow.

[HelloOO7]

Yep, I already made sure the library works and ran glxgears under X11 (same env vars, just changed the executable). It ran really good. Everything is in the same directory. I also built SDL2 for Stardew from source because I was not sure if the RPi one has full GL support.

[ptitSeb]

You are following this https://magazine.odroid.com/article/playing-modern-fna-games-on-the-odroid-platform/ right? What command line di you used when launching Stardew Valley?

[HelloOO7]

Yep, I am following the aforementioned guide.

LC_ALL=”C” LIBGL_FB=3 LIBGL_GL=21 LIBGL_DEFAULTWRAP=2 LIBGL_FBOFORCETEX=1 LD_LIBRARY_PATH=/home/pi/code/monolibs mono StardewValley.exe

The results are the same as if I use only the LD_LIBRARY_PATH with FB=3 (adding GL=21 does not change anything). There is never any LIBGL related output in any of those cases.

[ptitSeb]

Then I'm pretty sure SDL2 doesn't have OpenGL enabled. Can you check the logs of the cmake, or use ccmake to check that OpenGL is enabled? (maybe the guide is missing some extra configuration step for SDL2 or RPi)

[HelloOO7]

It looks like all the video options are enabled in SDL2 by default (OpenGL desktop and ES, X11, Vulkan etc.). I've compiled the library and moved it into Stardew Valley's lib/ directory. Maybe the system one's being used?

I also tried copying the new SDL2 libs into the monolibs directory (which is set as LD_LIBRARY_PATH) to ensure the system libs are not being used.

I'll try running Axiom Verge as well and see if it behaves the same.

[ptitSeb]

You can use the environnement variable LD_DEBUG=libs to see wich library is loaded, it can be usefull in this case.

[HelloOO7]

It looks like my SDL2 library is found and being used, however there is no libGL mention whatsoever.

I recompiled it again with OpenGL video enabled and GLES and RPi video disabled. However, for some reason, GLES support was still included. I remember hearing this is some SDL2 bug. What's strange, after adding this SDL2 build into my library path, many more libs showed up in LD_DEBUG's output. To be precise, libbrcmGLESv2 and libbrcmEGL. This is completely twisted, because those are the exact things I disabled in CCMake and they didn't show up when they were enabled. There's still no libGL anywhere though.

[HelloOO7]

Axiom Verge gets a little bit further but there is still no success when obtaining a graphics adapter.

LD_LIBRARY_PATH=/home/pi/code/monolibs/ LIBGL_GL=21 LIBGL_DEFAULTWRAP=2 LIBGL_FBOFORCETEX=1 LC_ALL="C" LIBGL_FB=3 mono AxiomVerge.exe
2019-02-23 13:05:49,502 - Setting SDL Hint to Allow Joystick Background Events
2019-02-23 13:05:49,559 - RunGame() Begin
Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
jack server is not running or cannot be started
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
AL_SOFT_gain_clamp_ex not found!
Update your OpenAL Soft library!
2019-02-23 13:05:49,779 - Creating Game.
2019-02-23 13:05:50,825 - Attempting to load Settings.xml
2019-02-23 13:05:50,911 - Settings object was null; initializing new object.
2019-02-23 13:05:50,985 - Initializing settings data.
2019-02-23 13:05:51,061 - Initializing Settings Data.
2019-02-23 13:05:51,133 - Initializing control mappings.
2019-02-23 13:05:51,214 - Creating Graphics object.
2019-02-23 13:05:51,290 - Creating Graphics Device Manager.
2019-02-23 13:05:51,380 - Caught exception constructing THGame().
System.ArgumentOutOfRangeException: Specified argument was out of the range of valid values.
Parameter name: index
  at System.Array.InternalArray__get_Item[T] (System.Int32 index) [0x0000c] in <8f2c484307284b51944a1a13a14c0266>:0 
  at (wrapper managed-to-managed) Microsoft.Xna.Framework.Graphics.GraphicsAdapter[]:System.Collections.Generic.IList`1.get_Item (int)
  at System.Collections.ObjectModel.ReadOnlyCollection`1[T].get_Item (System.Int32 index) [0x00000] in <8f2c484307284b51944a1a13a14c0266>:0 
  at Microsoft.Xna.Framework.Graphics.GraphicsAdapter.get_DefaultAdapter () [0x00005] in <c3fb032222c0495799663f6126e13053>:0 
  at Microsoft.Xna.Framework.GraphicsDeviceManager.Microsoft.Xna.Framework.IGraphicsDeviceManager.CreateDevice () [0x00006] in <c3fb032222c0495799663f6126e13053>:0 
  at Microsoft.Xna.Framework.GraphicsDeviceManager.get_GraphicsDevice () [0x00008] in <c3fb032222c0495799663f6126e13053>:0 
  at OuterBeyond.THGraphics.ApplySettings () [0x00034] in <41f1566a9a2042b5b20870095a693b20>:0 
  at OuterBeyond.THGraphics..ctor (OuterBeyond.THGame game) [0x0006e] in <41f1566a9a2042b5b20870095a693b20>:0 
  at OuterBeyond.THGame..ctor () [0x00121] in <41f1566a9a2042b5b20870095a693b20>:0 
  at OuterBeyond.Program.RunGame () [0x00011] in <41f1566a9a2042b5b20870095a693b20>:0 
2019-02-23 13:05:51,469 - game was null.
2019-02-23 13:05:51,542 - RunGame() End

It really looks like SDL2 is at fault here. But it shouldn't be...

[ptitSeb]

Use LD_DEBUG=libs to check which SDL2 is loaded

[HelloOO7]

Alright, I did that again, it's still using the one from my monolibs directory. Which was compiled against desktop GL (though the ES support got bugged in as I said), so there shouldn't be a problem. The system SDL2-image looks like it's being used, but that shouldn't make a difference.

[ptitSeb]

And the correct libGL is also loaded?

[HelloOO7]

No libGL library is loaded, that's where the problem lies I suppose. Maybe SDL2 puts ES in priority and as a result does not contact gl4es. And it looks like disabling ES in build settings does nothing, probably because of that SDL bug.

[ptitSeb]

SDL2 should use OpenGL in priority when both OpenGL and ES support are built-in.

You can try to force the use libGL by preloading it with LD_PRELOAD=~/monolibs/libGL.so.1

[HelloOO7]

Forcing the libGL makes gl4es load (that's kind of expected though). However, neither Axiom Verge or Stardew Valley are making use of it. In fact, Axiom Verge does not load ANY GL library at all, not even GLES. With the LD_DEBUG enabled, it shows that the game is not even looking for the library anywhere. That would mean there is a problem most possibly with SDL, but that thing's compiled against GL as it should be. I tried both CMake and ./configure with --disable-video-opengles and --disable-video-rpi and the libraries ARE being used, but for some reason there is no attempt to load libGL.

I tried enabling the RPi's experimental OpenGL driver and libGL.so.1 is never loaded (both games) and Stardew Valley still loads libbrcmGLESv2 and libbrcmEGL (Axiom Verge does not). Everything points to SDL2 or something in the games being at fault.

[ptitSeb]

Can you try the SDL2 lib with some SDL2 opensource game, it will be easier to debug may be (for example, Prototype on my github account can be built against SDL2 and it use OpenGL).

[HelloOO7]

Well, I'd rather not use Prototype because of our... experiences from #66. I installed neverball (which worked before) and it actually gets somewhere. It does not launch though. Using libSDL with every video output except OpenGL disabled, I get: Failed to initialize SDL (No available video device) (could that be because i used --disable-video-x11?) in X11, same in terminal.

Using the system provided libSDL, I get: Failed to create window (Could not get EGL display) in X11, the same followed with a segfault in command line.

Though in all cases, gl4es initializes.

[ptitSeb]

Mmmm, I'm unsure now. We closed this ticket, so the initial issue was fixed, right? It was the GPU that needed more memory, and Prototype was working in the end, isn't it?

[ptitSeb]

And yes, disable x11 will most probably disable desktop OpenGL in SDL2. (also, Neverball use SDL2?)

[HelloOO7]

The initial issues were segfaults on Minecraft and OpenMW, both were resolved, though OpenMW ended up running 4-5 FPS, so I doubt everything was fine. We never got Prototype to actually get past the intro text.

Oh right, neverball actually uses SDL1 I think, sorry. Prototype does not launch without any errors (the engine shuts down normally) when using SDL2.

I'll try Xash3D, maybe that will work.

[HelloOO7]

Well, Xash does not work either. Using the system libraries, it fallbacks into dedicated server mode, using SDL2 with only OpenGL and X11 enabled, it throws "No available video device" at SDL::Init and proceeds into dedicated mode as well. In the command line, the system libs segfault and mine throw the same error. Interestingly enough, in all of those cases, gl4es is not running either.

[ptitSeb]

So it's failling before even initializing GL. Must be something with one of the x11 utility lib, like libXinerama, libXxf86vm or libXrandr?

[HelloOO7]

Hmm, I'd say it fails at initializing GL with SDL2, considering FNA has crashed at video init. As for Xash, there's no difference when launching with standard LD_LIBRARY_PATH and when adding gl4es (in terminal, looks like x11 is a no-go). There's never any libGL output, it just starts, gets bits per pixel and segfaults. Come to think of it, I could actually try building OpenMW again, which although was a pain before, it's confirmed that gl4es somewhat worked there. And if I remember correctly, OpenMW is SDK2 too.

[ghost]

oh! this issue its very useful as an start to me. @HelloOO7 Ive tried openmw on mesa 19 and it runs much better, maybe you need to tweak a bit this gl4es to get proper performance. anyway, i will leave here this link, on the beginning its running my build of openmw 0.46. it skips the menu because an ffmpeg bug i couldnt resolve and outside the performance at 1080p (mid settings) isnt great, 25-30 fps. inside its 50-55. but if you downgrade resolution you get much higher fps (45-50). my channel its salvador liebana if you want to check more videos about openmw.

https://www.youtube.com/watch?v=HB5kESo7cVA&t=472s

going back on topic, i will take this suggestions and try to use gl4es on bastion.

[ptitSeb]

What make you think gl4es is not optimized? When I run gl4es+mesa(GLES) vs Mesa GL (on an x86 VM), gl4es is faster. On the RPi, maybe the mesa GL driver is faster for certain operation than the legacy GLES driver (especialy when x11 gets in the way) ?

[ghost]

I didnt know that. Anyway, I was refering to tweack the configuration og gl4es, not your code. That would be unrespectful. I will try to run this project, but right now I get only than it cant start the service, with or without the gl mesa driver on on my /boot/config.txt

[ptitSeb]

No problem, I just try to explain that just because is "wrapped" doesn't mean it's slow (plus, it's more than just a wrapper now).

Good luck fixing your service issue.

[ghost]

Making progress..... sorta. I've tested your gl4es on a clean raspbian setup. mixed results, at least I can start the service. it fails to create EGL contex, no matter what I tried. maybe you could give me some idea of whats happening or what i could try.

EGL contex failed - gl4es on RPI3 clean raspbian.txt

[ptitSeb]

Well, it seems to be unable to create an EGL context with X11.

Try with LIBGL_FB=1 first. In last resort, try LIBGL_FB=3. This one should work, but may be slower.

Also, I can see that already:

LIBGL: Max vertex attrib: 8
LIBGL: Max texture size: 2048
LIBGL: Max Varying Vector: 8

I assume MesaGL driver use the same hardware constraint as the GLES driver: so max texture is 2048x2048 (like on the OpenPandora). In that case, Stardew Valley (and Bastion IIRC) will not run whithout some on-the-fly texture shrinking, but mesaGL doesn't do that kind of hack (like LIBGL_SHRINK=11).

[ghost]

Well done ptit! yes, LIBGL_FB=1 crash on SDL but LIBGL_FB=3 did the trick (but as you know, its slow). LIBGL_SHRINK=11 fix the issue with textures... but ingame was a nightmare of texture errors (a lot of glGetError 0x505 appeared on my terminal). anyway, I will give it a shot back on my main raspbian setup!! They are any chances of implement that hack (LIBGL_SHRINK=11) if your gl4es doesnt work on my main raspbian (with mesa 19)???. its not related with your project, but maybe you know something... you always know something more hahaha thanks

[ghost]

The other way its shrink all the textures manually.... That could be an option?

[ptitSeb]

Texture error? Ah. on Bastion or Stardew Valley? Also, don't forget the other env. var for FNA games, as stated in the article, they can help the speed, and should reduce texture error too.

Well, I don't think it would be easy to implement LIBGL_SHRINK=11 on Mesa. And I don't think the mesa team would like this kind of hack anyway. But doesn't mesa19 also provide EGL/GLES2 driver? If that's the case, you can probably use gl4es in top of that (I do that on x86 VM to test gl4es).

[ptitSeb]

Shink the textures by hand. Well, tricky, because the texture are not easily accessible and needs some tools to be developped (like my rexwb for the sound).

[ptitSeb]

Mmm, I'm not familiar with RPi, but maybe yu can try to disable "BCMHOST" on your gl4es build, to avoid the use of the BCM specific services. Maybe you are using Mesa you don't have to init bcm stuff because it's handled by mesa driver?

[ghost]

Yes, thas what I need. let me explain.

pi@pi:~/Desktop/gl4es/build/lib $ LD_LIBRARY_PATH=/home/pi/Desktop/gl4es/build/lib glxgears LIBGL: Initialising gl4es LIBGL: v1.1.1 built on Apr 15 2019 01:02:59 LIBGL: Using GLES 2.0 backend LIBGL: loaded: libbcm_host.so >>> this could be out? how? I set BCMHOST=OFF and it keeps using it. LIBGL: loaded: libvcos.so >>>> no idea. LIBGL: loaded: libbrcmGLESv2.so >>> this are from broadcom, not mine from mesa , i need to change it and place the mesa one (ive read something about that on documentation, but i need to change them by default) LIBGL: loaded: libbrcmEGL.so >>> the same too, I need to change it to the mesa EGL LIBGL: loaded: libgbm.so >>> dont know if it using the built by mesa (and dont know what it does too) LIBGL: Using GLES 2.0 backend >>> for bastion I believe I need 2.1 (mesa give me that profile), whats going here??

• failed to add service - already in use? >>> this its because I cant use gl4es on mesa driver, just because it uses all the broadcom stuff??

I could recompile mesa and give you an installation package if you need for testing on your vm... just a thought

[ptitSeb]

Mmm, you know it's all described in USAGE.md...

Anyway, I have pushed a commit to not look for broadcom specific EGL/GLES libs if not building with BCMHOST flags. So it should be good now.

If needed, it's LIBGL_EGL=/PATH/TO/libEGL.so and LIBGL_GLES=/PTH/TO/libGLES.so...

To force OpenGL 2.1, it's LIBGL_GL=21. But you need other env. var for FNA games (well, not needed, but nice to have, as they speedup things). It's all in the article.

[ghost]

ok, now it load the right libs. LIBGL_GL=21 didnt work in this case, it keeps on 2.0... and the main problem its an segfault ): its ok anyway, thanks ptit!

segfault.txt

[ptitSeb]

The LIBGL_GL works, but it crashes before beeing able to do anything with it. It seems to be crashing very early, probably while trying to get Hardware capalities: it is supposed to create a PBuffer (i.e. offscreen surface) to query hardware capalities, and it's probably crashing at init.

If you launch with gdb maybe the backtrace you can get will help understanding what is happening.

[ghost]

I will try gdb. ok, It could be than my mesa havent off-screen rendering or its not related? thanks as always.

[ptitSeb]

Is this still an issue or can I close it?

[chrisvannooten]

I hope it's fine that I post this here (as the issue is quite old and has been inactive) but I have been having a similar problem on the Odroid N2+.

I tried to follow the same guide and got to the same point as Hello007. However strangely enough when I used a different user I only got an error for ARB_framebuffer_object or EXT_framebuffer_object and nothing about the Opengl3.0 compatible drivers.

Even stranger is that the glxgears program runs but unlike on my X86_64 Ubuntu PC it sometimes changes the shade of the color of the gears (sometimes a darker red and sometimes a darker blue), something that doesn't happen on the X86_64 machine. Additionally I tried to run a different game to see if everything works so I went with QuakeSpasm, the menu ran fine but the second I tried to play the actual game it crashed and blamed a segfault in the report window.

[ptitSeb]

You'll have to copy/paste log error here if you want me to help.

Also, don't worry about the subtlse change os shade seen in glxgear: this one use "flat" shade mode, wich gl4es doesn't emulated, as it's difficult to do and is only used by glxgears.

[chrisvannooten]

Ok, I thought I messed something up at compile.

Here is the pastebin for Quake. And here the pastebin of the mono games.

Should I try the Quake one with gdb?

[ptitSeb]

Why are you using LIBGL_FB=3 ? Also, are you sure those are the correct EGL/GLESv2 driver that you are loading?

(for Quake3 don't forget to select OpenGL1 renderer, not OpenGL2).

[chrisvannooten]

Not to sure, I remember it got less further a while ago without that command so at this point I guess it became superstition. Quake does run with LIBGL_GL=10..14.

I tried to rerun the stardew/monogames without the LIBGL_FB=3 (as well as 0 and 1), still no luck. I assume the correct EGL Drivers are loading, do I use LD_DEBUG=libs to find out? Can't seem to fully scroll up whenever I run it with this command and streaming it to a file only streams the GL4ES initialisation.

[chrisvannooten]

Okay so I got it working after watching the LD_DEBUG, it was using the system SDL2 library instead of the SDL2 that was compiled as per the guide's instruction. The library was named libSDL2-2.0.so.0 upon creation but should just be libSDL2.so, cp-ing it with just the rename was enough to get StarDew running.

Thanks for the help and my apologies for not noticing it sooner.