[GZ] errors in monster sight code on ARM

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 a reply

Smilies
:D :) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :geek: :ugeek: :!: :?: :idea: :arrow: :| :mrgreen: :3: :wub: >:( :blergh:
View more smilies

BBCode is OFF
Smilies are ON

Topic review
   

Expand view Topic review: [GZ] errors in monster sight code on ARM

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

by Marisa the Magician » Thu May 09, 2019 3:49 am

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.

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

by Rachael » Thu Oct 26, 2017 9:56 am

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. :)

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

by Csonicgo » Thu Sep 07, 2017 2:29 pm

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!

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

by Rachael » Thu Sep 07, 2017 2:11 pm

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.

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

by Csonicgo » Thu Sep 07, 2017 2:01 pm

: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.

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

by Rachael » Thu Sep 07, 2017 1:43 pm

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.

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

by Csonicgo » Thu Sep 07, 2017 1:07 pm

That's weird and unfortunate, because ARMv8 is several orders of magnitude better than v7 in terms of floating point performance.

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

by Rachael » Thu Sep 07, 2017 12:23 pm

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:

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

by Graf Zahl » Thu Sep 07, 2017 12:01 pm

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.

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

by Csonicgo » Thu Sep 07, 2017 11:08 am

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.

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

by Rachael » Thu Sep 07, 2017 9:48 am

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.

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

by Csonicgo » Thu Sep 07, 2017 7:55 am

I figured it out. ARMv8 extensions were enabled, which adds the flag "unsafe math optimizations". removing that flag fixes the issue. Weird.

[GZ] errors in monster sight code on ARM

by Csonicgo » Tue Sep 05, 2017 5:58 pm

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.

Top