Board index FlightGear Support Compiling

Simgear compilation failure

Building FlightGear from source, and in the need for help?

Re: Simgear compilation failure

Postby wkitty42 » Sun Jan 01, 2017 6:36 pm

elgaton wrote in Sun Jan 01, 2017 11:01 am:
wkitty42 wrote in Sun Jan 01, 2017 10:32 am:what are AVX extensions? do we need them for anything special??

They are special extensions designed to speed up vector operations on processors that support them

thanks for you and sanhozy for this...

elgaton wrote in Sun Jan 01, 2017 11:01 am:
wkitty42 wrote in Sun Jan 01, 2017 10:32 am:why is dutchguy seeing them and other's aren't?

He's probably compiling SimGear with the -march=native switch, which enables all extensions (SIMD/AVX) supported by the processor in use. My guess is that either you do not use that switch, or you are using it but your CPU does not support AVX (this is my case); thus, since the faulty code is embedded in an #ifdef block, it is not compiled on your system and the error is not triggered.

i have an 8-core AMD Vishera 8350 4Ghz chip... i honestly don't know what the download_and_compile.sh script is using... my system does a configure and full compile each time, though...

elgaton wrote in Sun Jan 01, 2017 11:01 am:Anyway, Erik Hofman (the developer responsible for that part) has just pushed a fix to the SimGear repository - to the original poster, could you please check if it works?

i did see that update come through... i'll try to update in a little while and see what happens... from the looks of the patch, most of us shouldn't have any problems with the two fixes posted... (changing '>' to '<' and using // to comment out the other line)
"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up."
"Why not?" said Gurder.
"Dunno. It's frightened of heights, I guess."
User avatar
wkitty42
 
Posts: 4637
Joined: Fri Feb 20, 2015 3:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 14.04.5

Re: Simgear compilation failure

Postby elgaton » Sun Jan 01, 2017 7:33 pm

wkitty42 wrote in Sun Jan 01, 2017 6:36 pm:i have an 8-core AMD Vishera 8350 4Ghz chip... i honestly don't know what the download_and_compile.sh script is using... my system does a configure and full compile each time, though...

The script does not pass any special options to GCC, so it uses whatever the default is for your system. You can see the extensions enabled by default by running:
Code: Select all
gcc -Q --help=target

in a terminal. On my Arch Linux system, for instance, all SSE/AVX extensions are disabled by default (even though my processor supports the SSE instruction set up to version 4.2); that was probably chosen because, should I wish to create a static Linux binary and to run it on another system (possibly supporting different SSE/AVX versions), not enabling SSE/AVX at all guarantees the best compatibility (at the expense of performance).

Since, apparently, your processor supports SSE up to version 4.2, as well as AVX, you should be able to enable them by running the script like this:
Code: Select all
CFLAGS="-march=native" CPPFLAGS="-march=native" ./download_and_compile.sh [other options...]

Alternatively, you can get the files used by your distribution to generate the official Debian packages, tweak them to use the FlightGear repository you have already cloned on your hard drive (and to enable the SSE/AVX extensions), then rebuild the .deb packages.

An even better option would be to always compile SimGear with SSE enabled and to use an instruction set detector at runtime (such as this one) to check if the CPU and OS support the required instruction set (falling back on the "classic" algorithms if the SSE/AVX instructions are unsupported).
NIATCA 2nd admin, regular ATC at LIPX and creator of the LIPX custom scenery
elgaton
 
Posts: 1107
Joined: Tue Mar 19, 2013 4:58 pm
Callsign: I-ELGA/LIPX_TW
Version: Git
OS: Windows + Arch Linux

Re: Simgear compilation failure

Postby erik » Sun Jan 01, 2017 10:02 pm

elgaton wrote in Sun Jan 01, 2017 7:33 pm:An even better option would be to always compile SimGear with SSE enabled and to use an instruction set detector at runtime (such as this one) to check if the CPU and OS support the required instruction set (falling back on the "classic" algorithms if the SSE/AVX instructions are unsupported).

That won't work in our case, in fact it will slow down the code (considerably) because it prevents compile time optimizations. The current code guides the compiler into faster code generation. What was decided however is that current CPU's at least support SSE3 so that is enabled by default now, Enabling AVX adds another speedup for double precision floating point calculations which is pretty much all of the FlightGear math.

Erik

Erik
erik
 
Posts: 1500
Joined: Thu Nov 01, 2007 1:41 pm

Re: Simgear compilation failure

Postby elgaton » Sun Jan 01, 2017 10:07 pm

I see. Thanks for the clarification!
NIATCA 2nd admin, regular ATC at LIPX and creator of the LIPX custom scenery
elgaton
 
Posts: 1107
Joined: Tue Mar 19, 2013 4:58 pm
Callsign: I-ELGA/LIPX_TW
Version: Git
OS: Windows + Arch Linux

Re: Simgear compilation failure

Postby wkitty42 » Mon Jan 02, 2017 12:40 am

elgaton wrote in Sun Jan 01, 2017 7:33 pm:
wkitty42 wrote in Sun Jan 01, 2017 6:36 pm:i have an 8-core AMD Vishera 8350 4Ghz chip... i honestly don't know what the download_and_compile.sh script is using... my system does a configure and full compile each time, though...

The script does not pass any special options to GCC,


i didn't think it did... at least none that i was aware of with all the rooting through the script that i've done... that cmake stuff, on the other hand, i have no clue about and don't expect to be wandering in that forest for a long while yet ;)

thanks for all the additional information... i may try those "native" options and see what happens... it would be really really great to get even more FPS out of flightgear and if this is a step forward, i'll use it to my advantage ;)
"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up."
"Why not?" said Gurder.
"Dunno. It's frightened of heights, I guess."
User avatar
wkitty42
 
Posts: 4637
Joined: Fri Feb 20, 2015 3:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 14.04.5

Re: Simgear compilation failure

Postby wkitty42 » Mon Jan 02, 2017 1:38 am

erik wrote in Sun Jan 01, 2017 10:02 pm:What was decided however is that current CPU's at least support SSE3 so that is enabled by default now,

even when it is disabled by default in the compiler?

erik wrote in Sun Jan 01, 2017 10:02 pm:Enabling AVX adds another speedup for double precision floating point calculations which is pretty much all of the FlightGear math.

i'm trying elgaton's command line from above on an update now... i'm very curious to see what happens ;)

[edit]

hummm... i did see some simd and simd4x4 files installed but i don't know that i see much difference in the FPS... i'll have to play with it some more...

is there any way to tell if those extensions were actually included in the compile?
"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up."
"Why not?" said Gurder.
"Dunno. It's frightened of heights, I guess."
User avatar
wkitty42
 
Posts: 4637
Joined: Fri Feb 20, 2015 3:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 14.04.5

Re: Simgear compilation failure

Postby erik » Mon Jan 02, 2017 9:21 am

wkitty42 wrote in Mon Jan 02, 2017 1:38 am:
erik wrote in Sun Jan 01, 2017 10:02 pm:What was decided however is that current CPU's at least support SSE3 so that is enabled by default now,

even when it is disabled by default in the compiler?

Yes, SSE2 was introduced in 2001. If you have a CPU which doesn't support it you will have to compile FlightGear with -DENABLE_SIMD=OFF. But thore are extremely rare these days and running FlightGear on them will be a pain anyhow.

wkitty42 wrote in Mon Jan 02, 2017 1:38 am:
erik wrote in Sun Jan 01, 2017 10:02 pm:Enabling AVX adds another speedup for double precision floating point calculations which is pretty much all of the FlightGear math.

i'm trying elgaton's command line from above on an update now... i'm very curious to see what happens ;)

[edit]

hummm... i did see some simd and simd4x4 files installed but i don't know that i see much difference in the FPS... i'll have to play with it some more...

is there any way to tell if those extensions were actually included in the compile?

On 64-bit CPU's the compiler already assumes SSE2 is present (rightfully so), so you have been running the optimized code already fore some weeks.

Erik
erik
 
Posts: 1500
Joined: Thu Nov 01, 2007 1:41 pm

Re: Simgear compilation failure

Postby wkitty42 » Mon Jan 02, 2017 7:29 pm

ok... it must be something else that makes the 757-200 have such low FPS... i don't know what, though :(
"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up."
"Why not?" said Gurder.
"Dunno. It's frightened of heights, I guess."
User avatar
wkitty42
 
Posts: 4637
Joined: Fri Feb 20, 2015 3:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 14.04.5

Re: Simgear compilation failure

Postby erik » Mon Jan 02, 2017 10:43 pm

Is it only the 757 which has a low frame-rate or does the PC-7 (for example) suffer from the same problem?
One thing I found is that disabling AI traffic increased the frame-rate considerably.

Erik
erik
 
Posts: 1500
Joined: Thu Nov 01, 2007 1:41 pm

Re: Simgear compilation failure

Postby wkitty42 » Tue Jan 03, 2017 2:09 am

i do use AI traffic... i'll check the PC-7, too... the c712p didn't seem to have a problem the last time i flew it... i'll try it again, too... that'll be on the morrow, though...
"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up."
"Why not?" said Gurder.
"Dunno. It's frightened of heights, I guess."
User avatar
wkitty42
 
Posts: 4637
Joined: Fri Feb 20, 2015 3:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 14.04.5

Re: Simgear compilation failure

Postby erik » Tue Jan 03, 2017 9:37 am

Ok then my gut feeling tells me it's probably heavy on canvas. Especially MFD drawing operations are far from ideal right now. I did some small work on it but James announced he wants to replace the vector drawing routines with another package which was designed with SIMD in mind sounds much more promising than trying to optimize the current code.

Erik
erik
 
Posts: 1500
Joined: Thu Nov 01, 2007 1:41 pm

Re: Simgear compilation failure

Postby dutchguy » Tue Jan 03, 2017 4:29 pm

Hi all,

Turns out there is still a problem. The program compiles fine, but once I try to start it, I get a segfault. This is also the only output, so it is not much to go on I'm afraid. I did do two checks to make sure that this is really a problem in the same part of the code:

  • The most obvious check is to compile without -march=native. Doing this, the problem disappears.
  • I also checked that this is not related to mismatches due to recompiling only certain source files, by deleting all intermediate files (so including not only object files but also makefiles, etc.) and recompiling. This does not remove the problem.

I ran gdb to see if I could find out more, and it gives the following output:
Code: Select all
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x000000000073c3fe in _GLOBAL__sub_I__Z10read_valuePK14SGPropertyNodePS_PKcdd ()

Perhaps the author of the code knows where this function is located?
dutchguy
 
Posts: 108
Joined: Mon Mar 31, 2014 4:16 pm

Re: Simgear compilation failure

Postby wkitty42 » Tue Jan 03, 2017 7:12 pm

i've not seen this in my recent testing... i am pulling the latest updates at the time of this writing... i use the dnc script for my compiling... it creates other scripts for running the programs... in the case of running the debug stuff, i found that gdb wasn't being told where the source code for fgfs was so i fixed that and it should be in the currently available dnc script if you use it... i always build a debug version and run in gdb... what commit are you at? i have
Code: Select all
********** 20170103_141239EST **********
********** Total elapsed update and compile time is 8m 30s **********

PLib:    1b3b3e1d7689a85a50720f112614022c65d592bb
OSG:     18389c84d105ce2875aad7dee3d723902d1cce51
Simgear: 03cff6abcaaa4ef12675f0b0c5b9b48255674a5e
FGFS:    206b272210c83738f283d232addc1693bb01aeb4
FGData:  49836f9956d15029488c920e745ff8dbf0585567
FGAddon: r2375 | deltaecho | 2017-01-03 13:35:14 -0500 (Tue, 03 Jan 2017)
"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up."
"Why not?" said Gurder.
"Dunno. It's frightened of heights, I guess."
User avatar
wkitty42
 
Posts: 4637
Joined: Fri Feb 20, 2015 3:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 14.04.5

Re: Simgear compilation failure

Postby erik » Wed Jan 04, 2017 11:57 am

dutchguy wrote in Tue Jan 03, 2017 4:29 pm:Hi all,

Turns out there is still a problem. The program compiles fine, but once I try to start it, I get a segfault. This is also the only output, so it is not much to go on I'm afraid. I did do two checks to make sure that this is really a problem in the same part of the code:

  • The most obvious check is to compile without -march=native. Doing this, the problem disappears.
  • I also checked that this is not related to mismatches due to recompiling only certain source files, by deleting all intermediate files (so including not only object files but also makefiles, etc.) and recompiling. This does not remove the problem.

I ran gdb to see if I could find out more, and it gives the following output:
Code: Select all
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x000000000073c3fe in _GLOBAL__sub_I__Z10read_valuePK14SGPropertyNodePS_PKcdd ()

Perhaps the author of the code knows where this function is located?


I've checked every bit of the AVX code for errors but found nothing obvious. But I did some small modifications. It would be great if you could check them out.

The backtrace is not very useful I'm afraid.

Erik
erik
 
Posts: 1500
Joined: Thu Nov 01, 2007 1:41 pm

Re: Simgear compilation failure

Postby dutchguy » Wed Jan 04, 2017 11:59 am

I'm up to date with current git. The only difference I can see is that you seem to compile Plib and OSG yourself, and I just take the latest stable version. However, I think it's unlikely that the problem originates there, since it seems to disappear when turning off -march=native. I've used
Code: Select all
gcc -march=native -Q --help=target

to see which compiler flags are turned on for me, which gives the following output:
Code: Select all
The following options are target specific:
  -m128bit-long-double              [disabled]
  -m16                              [disabled]
  -m32                              [disabled]
  -m3dnow                           [disabled]
  -m3dnowa                          [disabled]
  -m64                              [enabled]
  -m80387                           [enabled]
  -m8bit-idiv                       [disabled]
  -m96bit-long-double               [enabled]
  -mabi=                            sysv
  -mabm                             [enabled]
  -maccumulate-outgoing-args        [disabled]
  -maddress-mode=                   short
  -madx                             [disabled]
  -maes                             [enabled]
  -malign-data=                     compat
  -malign-double                    [disabled]
  -malign-functions=                0
  -malign-jumps=                    0
  -malign-loops=                    0
  -malign-stringops                 [enabled]
  -mandroid                         [disabled]
  -march=                           haswell
  -masm=                            att
  -mavx                             [enabled]
  -mavx2                            [enabled]
  -mavx256-split-unaligned-load    [disabled]
  -mavx256-split-unaligned-store    [disabled]
  -mavx512bw                        [disabled]
  -mavx512cd                        [disabled]
  -mavx512dq                        [disabled]
  -mavx512er                        [disabled]
  -mavx512f                         [disabled]
  -mavx512ifma                      [disabled]
  -mavx512pf                        [disabled]
  -mavx512vbmi                      [disabled]
  -mavx512vl                        [disabled]
  -mbionic                          [disabled]
  -mbmi                             [enabled]
  -mbmi2                            [enabled]
  -mbranch-cost=                    0
  -mcld                             [disabled]
  -mclflushopt                      [disabled]
  -mclwb                            [disabled]
  -mcmodel=                         32
  -mcpu=                            
  -mcrc32                           [disabled]
  -mcx16                            [enabled]
  -mdispatch-scheduler              [disabled]
  -mdump-tune-features              [disabled]
  -mf16c                            [enabled]
  -mfancy-math-387                  [enabled]
  -mfentry                          [enabled]
  -mfma                             [enabled]
  -mfma4                            [disabled]
  -mforce-drap                      [disabled]
  -mfp-ret-in-387                   [enabled]
  -mfpmath=                         387
  -mfsgsbase                        [enabled]
  -mfused-madd                      
  -mfxsr                            [enabled]
  -mglibc                           [enabled]
  -mhard-float                      [enabled]
  -mhle                             [disabled]
  -mieee-fp                         [enabled]
  -mincoming-stack-boundary=        0
  -minline-all-stringops            [disabled]
  -minline-stringops-dynamically    [disabled]
  -mintel-syntax                    
  -mlarge-data-threshold=           0x10000
  -mlong-double-128                 [disabled]
  -mlong-double-64                  [disabled]
  -mlong-double-80                  [enabled]
  -mlwp                             [disabled]
  -mlzcnt                           [enabled]
  -mmemcpy-strategy=                
  -mmemset-strategy=                
  -mmmx                             [enabled]
  -mmovbe                           [enabled]
  -mmpx                             [disabled]
  -mms-bitfields                    [disabled]
  -mmwaitx                          [disabled]
  -mno-align-stringops              [disabled]
  -mno-default                      [disabled]
  -mno-fancy-math-387               [disabled]
  -mno-push-args                    [disabled]
  -mno-red-zone                     [disabled]
  -mno-sse4                         [disabled]
  -mnop-mcount                      [disabled]
  -momit-leaf-frame-pointer         [disabled]
  -mpc32                            [disabled]
  -mpc64                            [disabled]
  -mpc80                            [disabled]
  -mpclmul                          [enabled]
  -mpcommit                         [disabled]
  -mpopcnt                          [enabled]
  -mprefer-avx128                   [disabled]
  -mpreferred-stack-boundary=       0
  -mprefetchwt1                     [disabled]
  -mprfchw                          [disabled]
  -mpush-args                       [enabled]
  -mrdrnd                           [enabled]
  -mrdseed                          [disabled]
  -mrecip                           [disabled]
  -mrecip=                          
  -mrecord-mcount                   [disabled]
  -mred-zone                        [enabled]
  -mregparm=                        0
  -mrtd                             [disabled]
  -mrtm                             [disabled]
  -msahf                            [enabled]
  -msha                             [disabled]
  -mskip-rax-setup                  [disabled]
  -msoft-float                      [disabled]
  -msse                             [enabled]
  -msse2                            [enabled]
  -msse2avx                         [disabled]
  -msse3                            [enabled]
  -msse4                            [enabled]
  -msse4.1                          [enabled]
  -msse4.2                          [enabled]
  -msse4a                           [disabled]
  -msse5                            
  -msseregparm                      [disabled]
  -mssse3                           [enabled]
  -mstack-arg-probe                 [disabled]
  -mstack-protector-guard=          tls
  -mstackrealign                    [enabled]
  -mstringop-strategy=              [default]
  -mtbm                             [disabled]
  -mtls-dialect=                    gnu
  -mtls-direct-seg-refs             [enabled]
  -mtune-ctrl=                      
  -mtune=                           haswell
  -muclibc                          [disabled]
  -mveclibabi=                      [default]
  -mvect8-ret-in-mem                [disabled]
  -mvzeroupper                      [disabled]
  -mx32                             [disabled]
  -mxop                             [disabled]
  -mxsave                           [enabled]
  -mxsavec                          [disabled]
  -mxsaveopt                        [enabled]
  -mxsaves                          [disabled]

  Known assembler dialects (for use with the -masm-dialect= option):
    att intel

  Known ABIs (for use with the -mabi= option):
    ms sysv

  Known code models (for use with the -mcmodel= option):
    32 kernel large medium small

  Valid arguments to -mfpmath=:
    387 387+sse 387,sse both sse sse+387 sse,387

  Known data alignment choices (for use with the -malign-data= option):
    abi cacheline compat

  Known vectorization library ABIs (for use with the -mveclibabi= option):
    acml svml

  Known address mode (for use with the -maddress-mode= option):
    long short

  Known stack protector guard (for use with the -mstack-protector-guard= option):
    global tls

  Valid arguments to -mstringop-strategy=:
    byte_loop libcall loop rep_4byte rep_8byte rep_byte unrolled_loop vector_loop

  Known TLS dialects (for use with the -mtls-dialect= option):
    gnu gnu2
dutchguy
 
Posts: 108
Joined: Mon Mar 31, 2014 4:16 pm

PreviousNext

Return to Compiling

Who is online

Users browsing this forum: No registered users and 1 guest