Segfault on RPi 3 #66
Comments
|
Can you copy-paste the whole gl4es output here? Do you know how to make a gdb backtrace also? |
(It's not a copy paste, I've rewritten it here, because I'm too lazy to log outside X11) Yeah, I KINDA know how to use gdb, but I haven't yet figured out how to use the environment variable LD_LIBRARY_PATH in there. Edit: Figured it out. Here: |
|
It looks like GLES is not really initialized (gl4es try to check the extension availble but the extension string is NULL. Also, some I find strange is that |
|
Tested glxgears with NOTEST, it gets a bit further: OpenMW actually launches (!!), but I never used it from CLI before and the documentation is horrible, so I can't actually run the game. If you have any experiences of how to link the bsa archive (it seems it can't find some textures contained in those), please let me know, so I can test it too. Though this probably doesn't belong here. And yes, the libs you mentioned are in /opt/vc/lib. |
|
Ok, I think the wrong libs are loaded. Can you try with latest commit cab03d4 it should makes the brcm version of EGL and GLES load first, and should fix all issues. The |
|
Nope, something's still odd. Also, GLES1 doesn't use the brcm libs as they were deprecated (I believe, in Raspbian Stretch), so only 2 does something for now. Log: GDB for ES1 is still the same, [New Thread 0x7674b450 (LWP 2624)] |
|
Ok, the ES1.1 is stilll using regulat EGL/GLES1. I guess For ES2.0, the right libs are loaded, but it seems it cannot create EGL context correctly. |
|
Yeah, I said that the ES1 libraries are no longer distributed, anyway, FB3 gives some real nice results: (It's the output of both 3 and 1) So that's glxgears somehow worked around. Any instructions on how to get OpenMW running? Everything I can find uses the GUI/launcher, not the source-compiled CLI. Yeah, I know it's a bit off-issue-topic, but it should push the tests forward. I'll try Minecraft in the meantime. |
|
Ah yes, I somehow didn't read the part about ES1.1 beeing deprecated. Maybe you can build with default to ES2.0 then, using So FB=3 is 3x faster than FB=1? Interesting. Now, about OpenMW, I used only the qt launcher on my side (on the Pandora, that is also ARM and using gl4es for OpenMW, with qt built for GLES2 and OpenMW built for GL using gl4es). I don't know what kind of command line argument should be used. Why don't you build the launcher? |
|
Can't. There's some bad conflicting declaration between freeglut, which uses GLES and Qt4, which uses GL. I could probably solve it by compiling Qt4 manually, but I'll probaby just copy over a config from my PC. Currently I'm trying to get MC working too, but I have to change a few scripts to work with my Java, so that'll take some time. I'll call it a day for today and get some sleep. I'll try to keep you informed with the test results here. |
|
You should have freeglut compiled against OpenGL and Qt4 compiled against GLES2. That had worked for me. Qt4 should work with gl4es and so OpenGL now, but I haven't tested it yet. |
|
Hello again, here's Minecraft (no difference between FB 3 and 1 AFAIK): I got OpenMW to launch, but no luck with displaying anything except a cursor so far: |
|
For Minecraft: yeah, gl4es was interfering with Java JVM. I have just pushed a change that should fix the "Illegal Instruction" issue. For OpenMW, I'm unsure what is going on. I see that it's unable to open any GL Context. That's a bit strange. How was built OSG? Is it the regular OSG, built with GL1 and GL2 atleast? |
|
OpenMW: Yeah, now that I think about it, it probably wasn't. I got the openscenegraph-3.4 package from the regular Raspbian repo. I checked the source for it on my PC and found this line in Minecraft: Nice, looks like we are getting somewhere OHMYGOD YESS (window appears) Oh... alright. I guess this doesn't tell you much, any idea how to attach GDB to Minecraft's JVM? Can't seem to find its PID, ps shows only bash and ps. |
|
For OpenMW: For MineCraft: |
|
For MineCraft: |
|
Alright, I'll check the changes once I get home, I'm currently away for ~10 days. Please don't close this issue until then. |
|
Don't worry, I wont close it yet (and I'm also in holiday for around 2 weeks). |
|
Hey, so good news, Minecraft just got in-game! OpenMW... welll... nothing has changed since recompiling OSG (and OpenMW too since it could not find the old libs). The log's the same as before except that instead of using OSG3.4 it uses 3.7. I'll try to get some more debug info for it and also check out the precompiled version on the Debian archives, as well as try using the RPi GL drivers (that is, if they work outside X11) tomorrow. |
|
Ah good. 5fps is not super good :( , maybe there is still something wrong, I was expecting it to go faster than that on RPi3. No idea for now why OpenMW would not work. I'll have to retry on my side, to check current gl4es version don't have issues with it (but probably not before end next week). |
|
Hello again, testing OpenMW with the GL driver yields no better results than with gl4es. Good news is, I got some more info on the bus error: The precompiled version is a dependency hell, for my OSG and other libs that I compiled are in /usr/local, not in /usr, and dpkg won't let me install openmw until I get the .deb versions of them, which are out of date for ARM, so it won't accept those either. I could not find any doc on how MC should run, but my guess it that FB3 is just slower than 0..? Any clues as to why the default FB does not work? |
|
For OpenMW, I built it all from scratch on the Pandora, including all dependancies (basically OSG and ffmpeg, I also have many built of Qt4 and qt5). Yeah, that's a lot of dependancies :( For MC, I think I have seen video of it running at around 20 ~ 25 fps on Pi3. FB3 maybe slower than FB0, but not always. I have seen cases where it is fast. FB1 should also be fast. No ideas why FB0 doesn't work. I guess some bad interaction between X11 and EGL driver. It seems X11 is slow on RPi, especially 3D stuff. Now, I have just retried OpenMW on the Pandora using latest gl4es. I used LIBGL_ES=2 LIBGL_MIPMAP=5 LIBGL_SHRINK=11 |
|
I searched for a bit about OpenMW and it seems that the SWscaler bus error was encountered in different cases, but always on RPi. I'll try recompiling FFmpeg from source. Testing MC with the GL driver gets me around CINEMATIC EXPERIENCE 24 FPS. Considering GL4ES is a translator, 5 FPS seems about right. I exaggerated a bit about the framerate though, it's more like 1-2FPS. What surprises me is that the Pandora's HW isn't THAT good and it still is playable. I have a feeling that it might be running over a SW renderer or something (the F3 MC info says that the GPU is GL4ES though). |
|
I would expect the speed to be on par with the GL driver. It's a translator but there are some optimizations that make gl4es not really slow (I have done test on a Linux x64 running on a VBox VM, and gl4es is sometimes faster than the built in driver). |
|
A quick MC update while compiling FFmpeg, MC actually works pretty good. The problem was that the game spawned me underwater where the performance was terrible, then when I respawned on a beach, I got around 10 FPS. Perf didn't show anything suspicious. Was about to take a screenshot and... |
|
Temperature issue? Then the freeze left some MC data corrupted? |
|
Oh my bad, I probably worded it wrong. Yeah, the crash is definitely because of temperature, but the freeze occurs after a few minutes of playing. I'll test some more to see if it's actually GL4ES's issue, but rn I'm busy compiling FFmpeg. In the meantime, if you know some confirmed working GL4ES-compatible program that I can test, I'll get right to it. |
|
From debian repo, you can try "neverball", it should work fine. |
|
Progress report: I'm still stuck with ffmpeg. After compiling it from source and recompiling OSG, openmw compiles fine but fails at 100% when linking the executable with completely unrelated error. |
|
try using |
|
Ah, ooops, I have left some Pandora specific code in this one. I'll check later. Prototype still doesn't start? Odd. Any interesting things in the log? |
|
Nope, nothing new. Here's TreadMarks btw, backtrace included. |
|
Ok, there was an issue with LIBGL_FB=3 (among other things). It should be fixed now with comit db24e29 |
|
Treadmarks now launches! I tested FB1 and there's a shader compilation error and a segfault. Unfortunately, I wasn't able to get a backtrace of that one, as running in gdb keeps TM running after the segfault, which, as FB1 is fullscreen, completely locks me out of my Pi (although something tells me I could work around it with SSH). Anyway, here's the output produced without BT: |
|
I'm not sure of what is happening here. It seems the window dimensions changed and trigger the need to resize the underlying EGL Surface... I think commit c5b9be0 may fix the issue with LIBGL_FB=3. |
|
Nothing has changed, unfortunately. It's also worth noting that the shakes of the window and the game/intro are independent. The window title and buttons are constantly moving left-right, the taskbar icon up-down and the game in random directions. |
|
Ï don't understand. Do you mean the game window is moving across the screen by itself? Also, are you using X11 or Wayland? |
|
Yep. The window itself stays in a place but the right border is constantly moving left and right, causing the control buttons and window title to shake. |
|
That's super odd! I don't change Window geometry in gl4es. |
|
I'm using plain LXDE if I am not mistaken. Installed with |
|
So, it's either my |
|
To check if the repeated XgetGeometry disturb it, in src/glx/glx.c go line 2464 and change with |
|
The shakes now happen only for a short period of time, then they stop. The problem is that now there's no picture. There is just the window frame, quiet and transparent. By the way, I got it to launch nicely in command line with |
|
It would be good to have DEBUG info on glx.c, to see the size of the PBuffer it creates, and try to understand what is happening. |
|
So here's the log with the DEBUG define uncommented in glx.c: It's not complete as most of the lines before was just -> 0xsomething SPAM. The pbuffer swap lines appeared just when I terminated the program, although the window was shaking all the time. Here's a run with valgrind: I also had to terminate that one. Again, incomplete but much longer than the first one. |
|
I think I've caught up on the 107 comments, and this looks like the right place to post more Raspberry Pi gl4es crash logs. Minecraft: Cannot get it to start. Whether LIBGL_FB=1 or 3, LWJGL throws an exception with "No unique GLX 1.3 config matches peer info": minecraft_config_mismatch.txt For this run I turned on I saw above that @HelloOO7 may have gotten Minecraft to launch at some point, but then withdrew that statement as it might have actually been using the system libGL.so with swrast? Yamagi Quake 2: Raspbian users are now using the OpenGL 1.3 build because the opengl_es branch is more than 6 years old. When I run with LIBGL_FB=3 it launches but crawls at about 2 fps (compared to ~40 fps with the Mesa VC4 driver) on this Pi 3B+. Here's a log with the stack trace on LIBGL_FB=1 or 2: From what I've read, if LIBGL_FB=3 runs while 1 and 2 fail, that suggests the application requires GL inside a window. However, I've got vid_fullscreen "1" in the yq config file and it does render fullscreen with the Mesa driver. Suggestions? |
|
For Minecraft, I think it's something in my glx stuffs in gl4es. I need to investigate and see what lwjgl expect (I haven't tested minecraft latelly, I may have broken it). For yquake2, I assume no eglContext has been created, and so shader doesn't compile because of that. Is there some error at the launch of the game, with some GLX error when creating the context? |
|
The Minecraft error looks about the same with 5b01037 + DEBUG logging, attached: minecraft_5b01037.txt I notice the GLXFBConfigID in there says not 0 or 1, but 4. yquake2 appears to successfully create the context in both the LIBGL_FB=1 and 3 cases, and even creates a surface. I replaced all 8- or 7-git hex numbers with 0xXXXXXXXX and ran a diff: |
|
The minecraft issue should be fixed (for good) with 87f9dc6 For yquake2, I'm unsure. that it works for LIBGL_FB=3 means there isn't anything wrong with FPE and all, but that the context created is somehow not compatible with GLES Shaders. Can you have the Link error message or that message is not readable? |
|
Awesome to see Minecraft running now. I'm using OptiFine with dozens of fancy effects disabled, and with the default window size performance is quite satisfactory. It's about 50 fps on scenes where the Mesa VC4 driver achieves 60 fps. The case where gl4es really shines is 1080p full screen, where Mesa's performance drops by half while gl4es retains about the same framerate. I recall minecraft-pi also has such a pronounced effect comparing full screen brcmEGL to Mesa EGL. One difference that largely affects playability is losing the 2D desktop mouse cursor, necessary for navigating the player's inventory. Any suggestions to deal with this? I have the same issue with Minetest and imagine many desktop GL programs have some point-and-click element. So far the one hack I have is to restore some window transparency and set the desktop background to a solid color, but this is a hack which leaves everything tinted. yquake2: Sorry I forgot to run the last batch with LIBGL_LOGSHADERERROR. I'm not sure why the error code didn't show in the earlier yquake2_fpe_failed.txt, but after printing the vertex and fragment shaders it now says: |
|
Glad to see Minecraft running. And faster and Mesa/CV4 in FullHD? Nice! About the mouse cursor, I don't know well RPi architecture, but DispmanX has a Z info for each layer, I guess if the mouse cursor could be, somehow, drawn alone on a dispmanX layer, with transparency, on top of all other layer, it would solve that issue. No idea if mouse cursor is drawn alone or just handled by X11 in the same layer has X11 windows. For yquake2, it still doesn't make sense. The context doesn't seems valid, so I assume the deletion / recreation of the context I see in the log is not working correctly. I need to analyse that. |
|
Good idea. I see Qt implements its cursor as a DispmanX overlay in its Pi-specific code. The first option I considered was modifying the Java code to use org.lwjgl.input.Cursor. Hypothetically if Minecraft 1.13+ can eventually run on a Pi, with LWJGL3 + GLFW this would likely be easiest by LD_PRELOAD to intercept glfwEnable/Disable(GLFW_MOUSE_CURSOR). Neither of these two would generalize to other games (like Minetest) so the DispmanX overlay remains the best in theory. As I was setting up more debug logs, yquake2 started working on one of my Pi devices. I investigated further, and it turns out I just needed to run yquake2 in LIBGL_FB=1 plays a bit choppy, often down to 15 fps for normal scenes. There's a lot of variation e.g. it goes up to 60 fps when facing a corner wall. Overall might still be of use to Retropie users who practically cannot practically use the open-source driver. Minetest gets past its launch dialog, slow as expected (<5 fps) because it's also slow with the Mesa GL driver. If I set |
|
Ah, so a simple GPU Memory issue! Interresting. For yquake2, try uisng "LIBGL_BATCH=5" or 10, because this engine send fragmented draw commend, BATCH could help. Minetest, I haven't tested lately. there is an issue with shader? But there isn't any shader compile error? |
|
yquake2: Ahh yes I remember seeing LIBGL_BATCH in the first 107 comments but needed to be reminded. Using LIBGL_BATCH=5 makes everything much more responsive, often achieving 60 fps in combat. From there, I see no difference in framerate going from 5 vs 10. Batching also makes a big difference for extremetuxracer: somewhat playable at low resolutions (requires LIBGL_FB=3). Minetest: with use_shaders = true, it shows no shader errors in the output even with LIBGL_LOGSHADERERROR=1. The terrain just appears very red and the player's weapon in hand comes with a black billboard. |
|
It's true that this issue is bit long now. I guess this one can now closed, as the original Segfault is solved, and the residual issue was about GPU Memory, that needed to be boosted a bit. I propose we close this issue (@jdonald @HelloOO7 are you ok?) and you can open a new one for the Minetest shaders. |
|
Fine by me. |
Hey,
I've compiled latest gl4es with -DBCMHOST=1 on my RPi 3 and tried running OpenMW and Minecraft. Both loaded the libraries (libGL: Initializin gl4es... etc...) and failed with Segmentation fault, even though they haven't launched at all (I ran OpenMW with only --help, to check if it runs). I'm unsure if the SDL that came with my distro (RetroPie) was compiled with OpenGL support, so I tested glxgears and the same thing happened (Segfault with no window or anything appearing).
I've tested both GLES1 and 2 backends.
The text was updated successfully, but these errors were encountered: