Crash on Rasp Pi 4

[drfrag]

The discord user NickZ has reported a crash with vid_rendermode 4. The error message was "System Bus error" (SIGBUS) so i think it's a memory alignment issue.
The backtrace is from my master branch but i believe it's exactly the same code. I changed default sector light mode to software (it's much faster).

Code: Select all

(gdb) bt
#0  PolyMainVertexShader::mul (mat=..., v=...)
    at /home/pi/lzdoom/src/rendering/polyrenderer/drawers/poly_vertex_shader.h:175
#1  0x007ad418 in PolyMainVertexShader::main (this=0xa01ff838)
    at /home/pi/lzdoom/src/rendering/polyrenderer/drawers/poly_vertex_shader.h:59
#2  0x007a498c in PolyTriangleThreadData::ShadeVertex (this=0xa0193014, 
    index=3406)
    at /home/pi/lzdoom/src/rendering/polyrenderer/drawers/poly_thread.cpp:400
#3  0x007a4580 in PolyTriangleThreadData::Draw (this=0xa0193014, index=3406, 
    vcount=4, drawmode=PolyDrawMode::TriangleFan)
    at /home/pi/lzdoom/src/rendering/polyrenderer/drawers/poly_thread.cpp:351
#4  0x007af80c in PolyDrawCommand::Execute (this=0xa252b670, thread=0x44df73c)
    at /home/pi/lzdoom/src/rendering/polyrenderer/drawers/poly_triangle.cpp:315
#5  0x006f826c in DrawerThreads::WorkerMain (
    this=0x10820a8 <DrawerThreads::Instance()::threads>, thread=0x44df73c)
    at /home/pi/lzdoom/src/rendering/swrenderer/drawers/r_thread.cpp:167
#6  0x006f838c in DrawerThreads::<lambda()>::operator()(void) const (
    __closure=0x4a131d4)
    at /home/pi/lzdoom/src/rendering/swrenderer/drawers/r_thread.cpp:227
#7  0x00728508 in std::__invoke_impl<void, DrawerThreads::StartThreads()::<lambda()> >(std::__invoke_other, DrawerThreads::<lambda()> &&) (__f=...)
    at /usr/include/c++/8/bits/invoke.h:60
--Type <RET> for more, q to quit, c to continue without paging--
#8  0x00727ce0 in std::__invoke<DrawerThreads::StartThreads()::<lambda()> >(DrawerThreads::<lambda()> &&) (__fn=...) at /usr/include/c++/8/bits/invoke.h:95
#9  0x0072c48c in std::thread::_Invoker<std::tuple<DrawerThreads::StartThreads()::<lambda()> > >::_M_invoke<0>(std::_Index_tuple<0>) (this=0x4a131d4)
    at /usr/include/c++/8/thread:244
#10 0x0072c3c4 in std::thread::_Invoker<std::tuple<DrawerThreads::StartThreads()::<lambda()> > >::operator()(void) (this=0x4a131d4)
    at /usr/include/c++/8/thread:253
#11 0x0072c354 in std::thread::_State_impl<std::thread::_Invoker<std::tuple<DrawerThreads::StartThreads()::<lambda()> > > >::_M_run(void) (this=0x4a131d0)
    at /usr/include/c++/8/thread:196
#12 0xb6a069b0 in ?? () from /usr/lib/arm-linux-gnueabihf/libstdc++.so.6
#13 0xb6e6a494 in start_thread (arg=0xa0d27310) at pthread_create.c:486
#14 0xb680b578 in ?? () at ../sysdeps/unix/sysv/linux/arm/clone.S:73
   from /lib/arm-linux-gnueabihf/libc.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

@Rachael You own a Rasp Pi 4 right? Does it run there? The carmack modes work.

[Rachael]

I am aware of this issue but never reported it because it is one of those things that is in the "veeeerrry loosely supported" category (i.e. you'd be lucky if it works - sure as fuck nobody's going to fix it if it doesn't).

You're probably better off forcing OpenGL 3.3 through Mesa and attempting to run GZDoom with OpenGL instead. (A bit glitchy, but last time I tried it I remember it working) Or wait until the Vulkan driver gets completed.

Even if you manage to get SoftPoly2 working on the Pi, I doubt it will ever run at a playable speed. Carmack works just fine though, as you pointed out, and if I run GZDoom on the Pi that's all I will use, for now.

[drfrag]

It's not mine, the guy offered me a Pi 4 but i declined the offer. I don't think i would be able to fix that besides i wouldn't put it to good use, that thing has HDMI and i still use CRTs (one of them is dying). Performance probably would be similar as for the old softpoly. The card supports only OpenGL 2.1 so i wouldn't hold my breath for Vulkan, may be for Pi 5.

[Rachael]

The Pi4 most definitely supports OpenGL 3 functions, they simply aren't enabled by default. But you can force the Mesa driver to work with them. I do that to get Raze running on it.

[drfrag]

You mean a software driver right? It would be slow.

[phantombeta]

You mean a software driver right? It would be slow.

The Raspberry Pi 4 supports OpenGL ES 3.0, which, as far as I know, is roughly equivalent to OpenGL 4.x*, so not necessarily.
* (Which also explains why a Vulkan driver is possible for it. As far as I know, pretty much any GPU that supports a certain version of OpenGL 4.x or above can have Vulkan support)

[Rachael]

You mean a software driver right? It would be slow.

No, it's not a software driver. Phantom explained it better than I did.

[drfrag]

I wonder if other android devices are affected, most likely they are. Then it's a different story but i wonder if those devices would be too slow to run Softpoly 2.
That guy dissapeared after i declined the offer, after sending a lot of messages now he's very busy.
He made a bug report about mouse position being wrong for resolutions lower than native and i guess now i'll have to test it myself soon on my linux desktop (my laptop only runs SDLFB). I think the problem was introduced here https://github.com/coelckers/gzdoom/com ... 3ee263ab1f and i attempted a fix here https://github.com/drfrag666/gzdoom/com ... fc673eb4e7
The ScaleCoordsFromWindow function is overriden since that commit but there was a previous adjustment performed in SDLGLFB::ScaleCoordsFromWindow.