[GZ] errors in monster sight code on ARM

Bugs that have been investigated and resolved somehow.

Moderator: GZDoom Developers

Forum rules
Please don't bump threads here if you have a problem - it will often be forgotten about if you do. Instead, make a new thread here.
Post Reply
User avatar
Csonicgo
Posts: 1193
Joined: Thu Apr 15, 2004 3:28 pm
Location: Leeds

[GZ] errors in monster sight code on ARM

Post by Csonicgo »

I recently upgraded my Raspberry Pi 3 to Raspbian Stretch(32-bit), and immediately noticed that monsters that aren't supposed to see me do see me through walls. Here is a screenshot 9 seconds into MAP01:

Image

I hadn't moved or fired a single shot. While I admire the increase in difficulty, this isn't intended behavior by a long shot.

It seems to be monsters to the north east of my position in the map that wake up first, although that isn't always the case.

GCC 6.1.0, ARMv8. Happens with -O3 & -O2.

I tried the last GZDoom Release (not devbuild) and it happens there too.
User avatar
Csonicgo
Posts: 1193
Joined: Thu Apr 15, 2004 3:28 pm
Location: Leeds

Re: [GZ] errors in monster sight code on ARM

Post by Csonicgo »

I figured it out. ARMv8 extensions were enabled, which adds the flag "unsafe math optimizations". removing that flag fixes the issue. Weird.
User avatar
Rachael
Posts: 13530
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her
Contact:

Re: [GZ] errors in monster sight code on ARM

Post by Rachael »

So as long as we add a compiler flag to disable unsafe math optimizations here, we should be okay.

Unfortunately, I don't have the hardware to test it on. Mine is the good ol' RPi3 which uses ARMv7 afaik. Is it possible to give the exact GCC parameter as a command line option so I can add it to CMake? Have you tried this with Clang? We should strive for both compilers compatibility on that platform.
User avatar
Csonicgo
Posts: 1193
Joined: Thu Apr 15, 2004 3:28 pm
Location: Leeds

Re: [GZ] errors in monster sight code on ARM

Post by Csonicgo »

Rachael wrote:So as long as we add a compiler flag to disable unsafe math optimizations here, we should be okay.

Unfortunately, I don't have the hardware to test it on. Mine is the good ol' RPi3 which uses ARMv7 afaik. Is it possible to give the exact GCC parameter as a command line option so I can add it to CMake? Have you tried this with Clang? We should strive for both compilers compatibility on that platform.
Clang works fine but it's really slow on ARMv8 because it's not a 64-bit build, which apparently matters more on ARM than it would x86 or something.

I looked up the specs and the Pi 3 model I have is actually an ARMv8-A. Good to know.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49056
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: [GZ] errors in monster sight code on ARM

Post by Graf Zahl »

Rachael wrote:So as long as we add a compiler flag to disable unsafe math optimizations here, we should be okay.

Why is this stuff even enabled by default if it is called 'unsafe' (as aptly proven hee.) :? In any case, insanities like this seem to be par for course for GCC.
User avatar
Rachael
Posts: 13530
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her
Contact:

Re: [GZ] errors in monster sight code on ARM

Post by Rachael »

This is strange. I didn't even know the 3rd gen model even had different processor types available. It seems mine is stuck with good ol' ARMv7 just as I originally posted. :( I thought for sure when you said you had a Pi 3 with an ARMv8 mine would be, too.
Spoiler:
User avatar
Csonicgo
Posts: 1193
Joined: Thu Apr 15, 2004 3:28 pm
Location: Leeds

Re: [GZ] errors in monster sight code on ARM

Post by Csonicgo »

That's weird and unfortunate, because ARMv8 is several orders of magnitude better than v7 in terms of floating point performance.
User avatar
Rachael
Posts: 13530
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her
Contact:

Re: [GZ] errors in monster sight code on ARM

Post by Rachael »

I'll just have to save up the money and get another one. :P I'm hoping to wait until they release a new model though - I really want the latest and greatest and I want to stretch the limits of what it can do.

I'll probably just turn the ARMv7 one into a custom wifi router. :)

At any rate - can you please give me the option you used to disable unsafe math, that you have verified is working? I'd like to get it into CMakeLists and close this. The reason I've left it open so far is because this issue will break deterministic compatibility on ARMv8, which will break multiplayer and demo support with the Intel instruction set processors, as well as with ARMv7 - so it really is necessary. (Or did you add it manually, yourself, with "-funsafe-math-optimizations" and later remove it?)

Actually, nevermind - that was something *I* added (I copy-pasted it from a website) - I removed it. This is fixed now.
User avatar
Csonicgo
Posts: 1193
Joined: Thu Apr 15, 2004 3:28 pm
Location: Leeds

Re: [GZ] errors in monster sight code on ARM

Post by Csonicgo »

:cheers:

EDIT: for giggles though I'd like to see how to make it work *with* that flag on, because it helps a lot with the dynamic lighting code. Last I checked, it was all float math there.
User avatar
Rachael
Posts: 13530
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her
Contact:

Re: [GZ] errors in monster sight code on ARM

Post by Rachael »

Actually - I dunno how to do this with CMake - but it *is* possible to do that for the r_ and poly_ files specifically - and not any of the other code like the g_ and d_ files. That would help things a lot.

None of what happens in r_ and poly_ should affect the playsim, so it should be possible to enable unsafe math on those files and leave the rest alone.
User avatar
Csonicgo
Posts: 1193
Joined: Thu Apr 15, 2004 3:28 pm
Location: Leeds

Re: [GZ] errors in monster sight code on ARM

Post by Csonicgo »

Rachael wrote:Actually - I dunno how to do this with CMake - but it *is* possible to do that for the r_ and poly_ files specifically - and not any of the other code like the g_ and d_ files. That would help things a lot.

None of what happens in r_ and poly_ should affect the playsim, so it should be possible to enable unsafe math on those files and leave the rest alone.
That would be a great idea. I'm sure it's possible!
User avatar
Rachael
Posts: 13530
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her
Contact:

Re: [GZ] errors in monster sight code on ARM

Post by Rachael »

So after researching this (this was on my to-do list for a while and I just got around to it), I've found out that r_all.cpp and poly_all.cpp are already compiled with unsafe math enabled (it's implied by the "-ffast-math" GCC flag which is set in the root CMakeLists.txt file). In fact, that's actually implied with the ${FASTMATH_SOURCES} list in CMake, and the flags are set for both compilers to make this happen. It happens with actually a large number of the files in the source.

This actually explains why software renderer bugs are so hard to diagnose in release mode; when fast math is enabled a lot of the safety checks go off (hence, it being labeled as "unsafe"), including division by zero checks and interrupt catchers. It also explains why the software renderer behaves differently in ARM and i686; hence, why some software renderer bugs are ARM-specific. The math that is executed in these functions will, in fact, break IEEE conformity, and what happens at that point really is processor-specific.

So yeah, it really was my fault for enabling unsafe math across the board - that should never have been done, and it turns out it's already enabled where it's actually needed (in performance-critical code, including the renderer) - so nothing further needs to be done here. :)
User avatar
Marisa the Magician
Posts: 3886
Joined: Fri Feb 08, 2008 9:15 am
Preferred Pronouns: She/Her
Operating System Version (Optional): (btw I use) Arch
Graphics Processor: nVidia with Vulkan support
Location: Vigo, Galicia
Contact:

Re: [GZ] errors in monster sight code on ARM

Post by Marisa the Magician »

Actually all models of the Pi3 have an ARMv8 processor, but most distros (especially raspbian) run it in ARMv7 mode because apparently there's issues with 64-bit stuff, namely the proprietary firmware.
Post Reply

Return to “Closed Bugs [GZDoom]”