[Fixed] [GZ] errors in monster sight code on ARM

Bugs that have been investigated and resolved somehow.

Moderators: Developers, ZDoom.org Team

[GZ] errors in monster sight code on ARM

Postby Csonicgo » Tue Sep 05, 2017 6: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.
User avatar
Csonicgo
OPL Goddess
 
Joined: 15 Apr 2004
Location: Leeds

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

Postby Csonicgo » Thu Sep 07, 2017 8:55 am

I figured it out. ARMv8 extensions were enabled, which adds the flag "unsafe math optimizations". removing that flag fixes the issue. Weird.
User avatar
Csonicgo
OPL Goddess
 
Joined: 15 Apr 2004
Location: Leeds

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

Postby Rachael » Thu Sep 07, 2017 10: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.
User avatar
Rachael
Not all elves needs a stocking hat...
 
Joined: 13 Jan 2004

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

Postby Csonicgo » Thu Sep 07, 2017 12:08 pm

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
Csonicgo
OPL Goddess
 
Joined: 15 Apr 2004
Location: Leeds

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

Postby Graf Zahl » Thu Sep 07, 2017 1: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.
User avatar
Graf Zahl
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

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

Postby Rachael » Thu Sep 07, 2017 1: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:
User avatar
Rachael
Not all elves needs a stocking hat...
 
Joined: 13 Jan 2004

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

Postby Csonicgo » Thu Sep 07, 2017 2:07 pm

That's weird and unfortunate, because ARMv8 is several orders of magnitude better than v7 in terms of floating point performance.
User avatar
Csonicgo
OPL Goddess
 
Joined: 15 Apr 2004
Location: Leeds

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

Postby Rachael » Thu Sep 07, 2017 2: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.
User avatar
Rachael
Not all elves needs a stocking hat...
 
Joined: 13 Jan 2004

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

Postby Csonicgo » Thu Sep 07, 2017 3: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.
User avatar
Csonicgo
OPL Goddess
 
Joined: 15 Apr 2004
Location: Leeds

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

Postby Rachael » Thu Sep 07, 2017 3: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.
User avatar
Rachael
Not all elves needs a stocking hat...
 
Joined: 13 Jan 2004

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

Postby Csonicgo » Thu Sep 07, 2017 3: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!
User avatar
Csonicgo
OPL Goddess
 
Joined: 15 Apr 2004
Location: Leeds

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

Postby Rachael » Thu Oct 26, 2017 10: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. :)
User avatar
Rachael
Not all elves needs a stocking hat...
 
Joined: 13 Jan 2004


Return to Closed Bugs

Who is online

Users browsing this forum: Baidu [Spider] and 2 guests