Loch failing to initialize GLX propely

[hbeni]

Hello,
on my debian box (debian sid/bullseye), i cannot get loch running.
The error message is not eloberate enough to debug this in any means.

How can i proceed further?

beni@segin:~$ loch
Error: glXCreateContext failed

Some GLX debug shows, that the card seems to be propely supported by the OS:

beni@segin:~$ xrandr --listproviders
Providers: number : 1
Provider 0: id: 0x5a cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 6 outputs: 5 associated providers: 0 name:Radeon RX 580 Series @ pci:0000:09:00.0
beni@segin:~$ DRI_PRIME=1 glxinfo | grep "OpenGL renderer"
OpenGL renderer string: Radeon RX 580 Series (POLARIS10, DRM 3.32.0, 5.2.0-3-amd64, LLVM 9.0.0)

beni@segin:~$ glxinfo | grep OpenGL
OpenGL vendor string: X.Org
OpenGL renderer string: Radeon RX 580 Series (POLARIS10, DRM 3.32.0, 5.2.0-3-amd64, LLVM 9.0.0)
OpenGL core profile version string: 4.5 (Core Profile) Mesa 19.2.3
OpenGL core profile shading language version string: 4.50
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 4.5 (Compatibility Profile) Mesa 19.2.3
OpenGL shading language version string: 4.50
OpenGL context flags: (none)
OpenGL profile mask: compatibility profile
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.2 Mesa 19.2.3
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20
OpenGL ES profile extensions:

beni@segin:~$ glxinfo  | grep rendering
direct rendering: Yes

beni@segin:~$ glxgears
383 frames in 5.0 seconds = 76.557 FPS

[hbeni]

Maybe it would also be good to see if loch runs at a recent debian on other machines...
I tried also my laptop and run into the same issue.

Currently i suppose something is wrong with some library on the system or something, but even recompiling loch brings no result.
I'm rather stuck now :(

[hbeni]

A little more debug options how that the dri infrastructure initializes:

beni@segin:~$ export LIBGL_ALWAYS_SOFTWARE=false; export LIBGL_ALWAYS_INDIRECT=false; export LIBGL_DEBUG=verbose; export MESA_DEBUG=1; loch
libGL: pci id for fd 7: 1002:67df, driver radeonsi
libGL: MESA-LOADER: dlopen(/usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so)
/usr/share/libdrm/amdgpu.ids version: 1.0.0
libGL: Using DRI3 for screen 0
libGL: pci id for fd 13: 1002:67df, driver radeonsi
libGL: MESA-LOADER: dlopen(/usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so)
libGL: Using DRI3 for screen 0
Error: glXCreateContext failed

beni@segin:~$ glxgears
libGL: pci id for fd 4: 1002:67df, driver radeonsi
libGL: MESA-LOADER: dlopen(/usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so)
/usr/share/libdrm/amdgpu.ids version: 1.0.0
libGL: Using DRI3 for screen 0
Running synchronized to the vertical refresh.  The framerate should be
approximately the same as the monitor refresh rate.
362 frames in 5.0 seconds = 72.379 FPS

[hbeni]

Bill said in the mailing list:

I also have this problem. I am running Fedora, and have seen this for about the last 6 months on both Fedora 30 and 31. It happens on computers with nVidia, Intel and VirtualBox display

Aven works fine.

[hbeni]

root cant call it either (to rule out permission issues) :(

wx-config reports GL support:

root@segin:~# wx-config --version
3.0.4

root@segin:~# wx-config --list

    Default config is gtk3-unicode-3.0

  Default config will be used for output

  Alternate matches:
    base-unicode-3.0

root@segin:~# wx-config --libs all
-L/usr/lib/x86_64-linux-gnu -pthread   -lwx_gtk3u_xrc-3.0 -lwx_gtk3u_stc-3.0 -lwx_gtk3u_richtext-3.0 -lwx_gtk3u_ribbon-3.0 -lwx_gtk3u_propgrid-3.0 -lwx_gtk3u_aui-3.0 -lwx_gtk3u_gl-3.0 -lwx_gtk3u_media-3.0 -lwx_gtk3u_html-3.0 -lwx_gtk3u_qa-3.0 -lwx_gtk3u_adv-3.0 -lwx_gtk3u_core-3.0 -lwx_baseu_xml-3.0 -lwx_baseu_net-3.0 -lwx_baseu-3.0

[hbeni]

Olly responded:

FWIW I see it too.

I don't think it's a wxWidgets bug - this is failing in code in
loch/lxR2P.c which makes calls to the glx layer which is a lower
level API than wxWidgets. It could be some sort of interaction
with wxWidgets OpenGL support though since it's effectively going
behind wxWidgets back.

I'm not sure why loch doesn't just use wxWidgets OpenGL support - that's
what aven does and that still works in current Debian unstable.

You probably want Martin or Stacho rather than me - they wrote this code
and presumably understand the API it's using and why.

[...]

Cheers,
Olly

[ojwb]

I've just uploaded therion 5.4.4ds1-4 to Debian unstable, which works around the problem (if creating this context fails, it just continues rather than giving up - this probably means you can't render a large image from loch, but that beats not being able to run it at all).

I don't think wxWidgets OpenGL support allows rendering to a pixmap as such. In aven the "screenshot" and movie features just work from what's rendered to the window, but that doesn't work if you want an image large than the window, or at least not without rendering as a series of tiles. Maybe you could create a large wxGLCanvas to render to and never show it.

[hbeni]

@ojwb Hi Olly,
the new package with the patch works here :)
Thank you very much!

@smudrak for your information :)

[hbeni]

hi stacho,
confirming commit 19eb624 fixes this issue.
Thank you very much!

[wookey]

Do you still have this hardware, and are you in a position to test if this patch to therion is still needed on 'testing' (the next stable release)? I've left it in the debian package for now, but ideally this would either go upstream or be dropped as no longer needed. It's not been included upstream in the new 5.5.4 release. I'm not sure if it just got forgotten or they'd like a better fix.
I could make you a version without this fix, to test, if you will have time.

[smudrak]

Rendering to pixmap was disabled at all - tiled rendering to screen buffer is used instead on all platforms. So this problem should be fixed.

[hbeni]

Do you still have this hardware, and are you in a position to test if this patch to therion is still needed on 'testing' (the next stable release)

Yes i do; but currently i use my self compiled version.
I can help you test the debian package, as i'm on debian testing.

Should i just apt-get it and test? or do i need to wait for something?

[ojwb]

@wookey Since 19eb624 the functions this patch changes no longer appear to ever get called (at least if LXLINUX is defined, which it looks to be in the Debian package build - if it isn't defined then loch/lxR2P.c calls R2PCreate(300, 300); from main(), which seems to be some sort of test program). So I don't think my patch is still useful for the Debian package.

[ojwb]

Oh sorry, I hadn't seen Stacho's reply when I wrote mine.

[wookey]

On 2020-12-16 09:49 -0800, Stacho Mudrak wrote: Rendering to pixmap was disabled at all - tiled rendering to screen buffer is used instead on all platforms. So this problem should be fixed.

OK. I'll remove this patch from a 5.5.4-2 upload. If someone can test that does indeed not cause any regressions, that would be good. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/

[hbeni]

@wookey How can i test it? I think i have just to wait for the package to arrive in the debian testing repo?