Crash on Rasp Pi 4

These bugs are specific to the SoftPoly backend

Moderator: GZDoom Developers

User avatar
drfrag
Vintage GZDoom Developer
Posts: 3150
Joined: Fri Apr 23, 2004 3:51 am
Location: Spain

Crash on Rasp Pi 4

Post by 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.
User avatar
Rachael
Posts: 13793
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her

Re: Crash on Rasp Pi 4

Post by 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.
User avatar
drfrag
Vintage GZDoom Developer
Posts: 3150
Joined: Fri Apr 23, 2004 3:51 am
Location: Spain

Re: Crash on Rasp Pi 4

Post by 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.
User avatar
Rachael
Posts: 13793
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her

Re: Crash on Rasp Pi 4

Post by 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.
User avatar
drfrag
Vintage GZDoom Developer
Posts: 3150
Joined: Fri Apr 23, 2004 3:51 am
Location: Spain

Re: Crash on Rasp Pi 4

Post by drfrag »

You mean a software driver right? It would be slow.
User avatar
phantombeta
Posts: 2119
Joined: Thu May 02, 2013 1:27 am
Operating System Version (Optional): Windows 10
Graphics Processor: nVidia with Vulkan support
Location: Brazil

Re: Crash on Rasp Pi 4

Post by phantombeta »

drfrag wrote: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)
User avatar
Rachael
Posts: 13793
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her

Re: Crash on Rasp Pi 4

Post by Rachael »

drfrag wrote:You mean a software driver right? It would be slow.
No, it's not a software driver. Phantom explained it better than I did.
User avatar
drfrag
Vintage GZDoom Developer
Posts: 3150
Joined: Fri Apr 23, 2004 3:51 am
Location: Spain

Re: Crash on Rasp Pi 4

Post by 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.

Return to “SoftPoly2 Bugs”