Crash on Rasp Pi 4

These bugs are specific to the SoftPoly backend

Moderator: GZDoom Developers

Crash on Rasp Pi 4

Postby drfrag » Fri Mar 06, 2020 2:57 pm

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 allExpand view
(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
drfrag
Os voy a romper a pedazos!
Vintage GZDoom Developer
 
Joined: 23 Apr 2004
Location: Spain
Discord: drfrag#3555
Github ID: drfrag666

Re: Crash on Rasp Pi 4

Postby Rachael » Fri Mar 06, 2020 3:41 pm

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
Rachael
Webmaster
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: Crash on Rasp Pi 4

Postby drfrag » Fri Mar 06, 2020 4:59 pm

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
drfrag
Os voy a romper a pedazos!
Vintage GZDoom Developer
 
Joined: 23 Apr 2004
Location: Spain
Discord: drfrag#3555
Github ID: drfrag666

Re: Crash on Rasp Pi 4

Postby Rachael » Fri Mar 06, 2020 5:44 pm

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
Rachael
Webmaster
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: Crash on Rasp Pi 4

Postby drfrag » Fri Mar 06, 2020 5:53 pm

You mean a software driver right? It would be slow.
User avatar
drfrag
Os voy a romper a pedazos!
Vintage GZDoom Developer
 
Joined: 23 Apr 2004
Location: Spain
Discord: drfrag#3555
Github ID: drfrag666

Re: Crash on Rasp Pi 4

Postby phantombeta » Fri Mar 06, 2020 6:08 pm

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
phantombeta
In the meadow of sinful thoughts, every flower's a perfect one
 
Joined: 02 May 2013
Location: Brazil, South America, Earth, Orion-Cygnus Arm, Milky Way
Discord: phantombeta#2461
Twitch ID: phantombeta_
Github ID: Doom2fan
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: Crash on Rasp Pi 4

Postby Rachael » Fri Mar 06, 2020 6:27 pm

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
Rachael
Webmaster
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: Crash on Rasp Pi 4

Postby drfrag » Sun Mar 22, 2020 5:28 pm

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.
User avatar
drfrag
Os voy a romper a pedazos!
Vintage GZDoom Developer
 
Joined: 23 Apr 2004
Location: Spain
Discord: drfrag#3555
Github ID: drfrag666


Return to SoftPoly2 Bugs

Who is online

Users browsing this forum: No registered users and 0 guests