[GZ] errors in monster sight code on ARM
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.
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.
[GZ] errors in monster sight code on ARM
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:
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.
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.
Re: [GZ] errors in monster sight code on ARM
I figured it out. ARMv8 extensions were enabled, which adds the flag "unsafe math optimizations". removing that flag fixes the issue. Weird.
Re: [GZ] errors in monster sight code on ARM
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.
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
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.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.
I looked up the specs and the Pi 3 model I have is actually an ARMv8-A. Good to know.
- Graf Zahl
- 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
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
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
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
I'll just have to save up the money and get another one. 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.
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
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
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.
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
That would be a great idea. I'm sure it's possible!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.
Re: [GZ] errors in monster sight code on ARM
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.
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.
- 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
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.