pi3d on Ubuntu 20.04 about pi3d HOT 11 CLOSED

Jonathan, thank you very much for persisting with this. It's all useful info for anyone else hitting this problem so I will add something to the pi3d FAQ page.

Also I need to find why the fake KMS driver on the RPi 4 is so slow for 4k displays with pi3d - possibly not related but I should try switching all the variables around and seeing what makes a difference.

from pi3d.

jonathan, Someone else had an issue with ubuntu 20.04 in vm and ended up using glx all the time. I'll checkout what was needed to make the background opaque (See development here github.com/helgeerbe/picframe). I use 20.04 on this laptop for all pi3d development, but vanilla install.

I notice you don't mention install mesa-utils-extra which I think I have always had to do for running on ubuntu.

from pi3d.

@jonathanhacker you might find some info using journalctl to see where the graphics card is complaining when you try and use EGL, which might help find info that can help when searching for solutions.

from pi3d.

jonathan here is the thread about getting glx working generally for pi3d. I can't see, off hand, if Helge installed mesa-utils-extra but it looks like exactly your problem.

from pi3d.

Thanks for the quick replies!

Installing mesa-utils-extra does not change anything, unfortunately. Neither does using the git-version of pi3d (sys.path.insert solution).

logging is also not very helpful:

kernel: [22555.007947] python3[87214]: segfault at 4400011 ip 00007fb7d1f68495 sp 00007ffe3f09ec30 error 4 in libEGL_mesa.so.0.0.0[7fb7d1f4f000+27000]
kernel: [22555.007953] Code: e1 97 ff ff 49 8b 7f 30 48 8d 54 24 1f 4c 89 ee e8 30 99 ff ff 49 8b 87 d8 00 00 00 8b 88 30 02 00 00 85 c9 0f 8e 1b 01 00 00 <41> 8b 7c 24 10 48 8b 80 28 02 00 00 31 d2 eb 0e 0f 1f 00 83 c2 01

In your linked discussion, it worked in the vm by disabling 3d acceleration and using glx (link). On my setup, the glx variant already works in both the vm and directly on hardware, so it does not quite help with the egl problem.

I also found in the discussion that alpha values smaller than one are respected during rendering. I will try if I can make my stuff work with use_glx=True and alpha values like 0.99.

Still, I'm wondering why the egl variant does not work on my system when it does on yours. Do you have any ideas what else I could check?
By parsing the GL_VERSION I found out that the used OpenGL version is 4.6 (Compatibility Profile) Mesa 20.2.6. Could the compatibility profile be a problem?

from pi3d.

Running in GDB might shed a little more light, someone else with the same "error 4" did:
https://discuss.getsol.us/d/5472-segfault-when-trying-to-run-game

Searching also lead back to this bug tracker
#177

In that issue remoting into the computer where they were trying to run Pi3D caused an issue.

I might be wrong, but I think compatibility profile might be OK, since it is more permissive.
I think there are some MESA environment variables you can try tweaking for more logging, or to tweak the GL version it returns https://docs.mesa3d.org/envvars.html

from pi3d.

It could well be a driver GL version issue. What do you get if you put in a line print(DISPLAY.opengl.gl_id) It might be worth making a local repo of pi3d or edit the pip installed one (probably in ~/.local/lib/python3.8/site-packages/pi3d/util/DisplayOpenGL.py)
and insert c. line 129:

    version = ctypes.cast(version, c_char_p).value
    print(version) #<<<<<<<<<<<
    if b"ES" in version:

Really it would make sense to keep that whole value in an accessible place for debugging, rather than just the trimmed down version in DisplayOpenGL.gl_id

On my ubuntu 20.04 I get

b'GLES3'
# and
b'OpenGL ES 3.2 NVIDIA 390.141'

from pi3d.

@stuaxo The gdb stack trace does not shed any more light (at least for me):

#0  0x00007ffff33bf495 in ?? () from /lib/x86_64-linux-gnu/libEGL_mesa.so.0
#1  0x00007ffff33aa76f in ?? () from /lib/x86_64-linux-gnu/libEGL_mesa.so.0
#2  0x00007ffff7fbcff5 in ?? () from /lib/x86_64-linux-gnu/libffi.so.7
#3  0x00007ffff7fbc40a in ?? () from /lib/x86_64-linux-gnu/libffi.so.7
#4  0x00007ffff73ea2ac in _ctypes_callproc ()
   from /usr/lib/python3.8/lib-dynload/_ctypes.cpython-38-x86_64-linux-gnu.so
... (Python trace)

I am trying to run on the local machine, so remote access is not the cause either. Also it can't be my hardware setup, since it works with 18.04. My best guess is that it's either the GL driver or the mesa library.

I did not know about these magical mesa envvars, thanks a lot for the link.
Adding EGL_LOG_LEVEL='debug' unfortunately does not seem to give any info related to the error (I think):

...
libEGL debug: did not find optional extension DRI_FlushControl version 1
libEGL debug: did not find optional extension DRI_MutableRenderBufferDriver version 1
libEGL debug: No DRI config supports native format R8  
libEGL debug: No DRI config supports native format GR88
libEGL debug: No DRI config supports native format AR15
libEGL debug: No DRI config supports native format XB24
libEGL debug: No DRI config supports native format AB24
libEGL debug: No DRI config supports native format XB30
libEGL debug: No DRI config supports native format AB30
libEGL debug: No DRI config supports native format XB4H
libEGL debug: No DRI config supports native format AB4H
zsh: segmentation fault (core dumped)  EGL_LOG_LEVEL='debug' python3 Minimal_2d.py

@paddywwoof When I have pi3d print the version and the gl_id, I get the following:
Interestingly, the 20.04 vm sometimes (although rarely) makes it to a black window, then it can print the versions, otherwise it segfaults before it can get that far.

So I definitely have another GL version (no dedicated graphics card). Still, I'm not sure if a driver is the problem or a library.

In the meantime I managed to make my code work with use_glx=True and setting alpha to 0.999. Behavior is identical to before, even with a lot of custom shaders (I only had to change some attributes to ins). Also, the glx variant runs on the Pi 4 as well. So I will stick to that and not try to make it work with egl.

If however you have any ideas what the cause might be I would be happy to assist with testing.

from pi3d.

Thanks, it's definitely interesting to stare at and gives some avenues of investigation.

Can you try setting the environment EGL_PLATFORM=x11 (as seen here anbox/anbox#1266)

from pi3d.

What's the output you get from glxinfo | grep "OpenGL" ?

from pi3d.

Wow, EGL_PLATFORM=x11 magically fixes all problems! Crazy, thanks a lot. Now I can choose which solution to use, probably I'm going to profile both of them on my pi and see which one is faster (if there is a difference).

I think I also found the reason (or at least a hint) why it does not work on Ubuntu 20.04. If I use EGL_PLATFORM=x11,wayland (the order does not matter) as the egl platform, I get the bad behavior I described. If only x11 is given, everything works fine. So my guess is that Ubuntu 20.04 provides both options while Ubuntu 18.04 only gave x11. I still have no idea why providing both options does not work.

Output of glxinfo | grep "OpenGL" (on my system, no VM):

OpenGL vendor string: Intel
OpenGL renderer string: Mesa Intel(R) UHD Graphics 620 (KBL GT2)
OpenGL core profile version string: 4.6 (Core Profile) Mesa 20.2.6
OpenGL core profile shading language version string: 4.60
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 4.6 (Compatibility Profile) Mesa 20.2.6
OpenGL shading language version string: 4.60
OpenGL context flags: (none)
OpenGL profile mask: compatibility profile
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.2 Mesa 20.2.6
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20
OpenGL ES profile extensions:

from pi3d.