More AMD RadeonSI Improvements Land In Mesa Git

[duby229]

Isn't mtune redundant once you have set march to native anyway?

I can only answer for gentoo, but there are some ebuilds that only allow -mtune, so if you only apply -march, those ebuilds that look for -mtune will not get optimized.

[dungeon]

Isn't mtune redundant once you have set march to native anyway?

No it is not the same, nor redundant. If you are radeon mesa user, look at this bug:

https://bugs.freedesktop.org/show_bug.cgi?id=83436

You can compile following code as 32bit binary and see if or with what mtune settings you might be affected:

https://bugs.freedesktop.org/attachment.cgi?id=105688

Most distros pass -mtune=generic by default which is also slow there and some of those too:

-mtune=i586 = slow
 -mtune=pentium = slow
 -mtune=pentium-mmx = slow
 -mtune=pentium-pro = fast
 -mtune=i686 = fast
 -mtune=pentium3 = fast
 etc...

[geearf]

I can only answer for gentoo, but there are some ebuilds that only allow -mtune, so if you only apply -march, those ebuilds that look for -mtune will not get optimized.

Oh interesting.
Why do they only allow mtune?

No it is not the same, nor redundant. If you are radeon mesa user, look at this bug:

https://bugs.freedesktop.org/show_bug.cgi?id=83436

You can compile following code as 32bit binary and see if or with what mtune settings you might be affected:

https://bugs.freedesktop.org/attachment.cgi?id=105688

Most distros pass -mtune=generic by default which is also slow there and some of those too:

-mtune=i586 = slow
 -mtune=pentium = slow
 -mtune=pentium-mmx = slow
 -mtune=pentium-pro = fast
 -mtune=i686 = fast
 -mtune=pentium3 = fast
 etc...

I see what you are saying, but I believe that setting march to native automatically sets mtune to native as well (at least in arch).
From gcc doc:

Moreover, specifying -march=cpu-type implies -mtune=cpu-type.

https://gcc.gnu.org/onlinedocs/gcc-4.5.3/gcc/i386-and-x86_002d64-Options.html

[dungeon]

I see what you are saying, but I believe that setting march to native automatically sets mtune to native as well (at least in arch).
From gcc doc:

https://gcc.gnu.org/onlinedocs/gcc-4...4-Options.html

Docs for docs, practice for practice. In mesa i got slow results until i forced right -mtune and that for both CC and CXX flags.

[geearf]

Docs for docs, practice for practice. In mesa i got slow results until i forced right -mtune and that for both CC and CXX flags.

Hmmmmm

#gcc -march=native -E -v - </dev/null 2>&1 | sed -n 's/.* -v - //p'
-march=nehalem -mmmx -mno-3dnow -msse -msse2 -msse3 -mssse3 -mno-sse4a -mcx16 -msahf -mno-movbe -mno-aes -mno-sha -mno-pclmul -mpopcnt -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-bmi2 -mno-tbm -mno-avx -mno-avx2 -msse4.2 -msse4.1 -mno-lzcnt -mno-rtm -mno-hle -mno-rdrnd -mno-f16c -mno-fsgsbase -mno-rdseed -mno-prfchw -mno-adx -mfxsr -mno-xsave -mno-xsaveopt -mno-avx512f -mno-avx512er -mno-avx512cd -mno-avx512pf -mno-prefetchwt1 --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=8192 -mtune=nehalem -fPIE -fstack-protector-strong

#gcc -E -v - </dev/null 2>&1 | sed -n 's/.* -v - //p' 
-mtune=generic -march=x86-64 -fPIE -fstack-protector-strong

What distro are you using?

[dungeon]

What distro are you using?

Debian. It shows the -mtune is the same there, but try building mesa with only -march set and look at processes what you get Did you use radeon, so you can test that example?

Keep in mind that i am talking about 32 bit toolchain, mesa and apps... 64bit is fine.

[geearf]

Debian. It shows the -mtune is the same there, but try building mesa with only -march set and look at processes what you get Did you use radeon, so you can test that example?

Keep in mind that i am talking about 32 bit toolchain, mesa and apps... 64bit is fine.

I've just build my mesa an hour ago so let's check that.
But I don't understand what you mean by "look at processes what you get".
Do you mean looking at how gcc was called?

Oh I was looking at 64b, I haven't build 32b mesa in a while, but I don't mind trying if you explain to me what to look for.
And I am on radeonsi.

[lorenzoz]

So I found out the problem with checkinstall.

checkinstall

checkinstall 1.6.2, Copyright 2009 Felipe Eduardo Sanchez Diaz Duran
           This software is released under the GNU GPL.



*****************************************
**** Debian package creation selected ***
*****************************************

*** Warning: The package name "LLVM" contains upper case
*** Warning: letters. dpkg might not like that so I changed
*** Warning: them to lower case.

This package will be built according to these values: 

0 -  Maintainer: [ root@debian ]
1 -  Summary: [ LLVM (An Optimizing Compiler Infrastructure) ]
2 -  Name:    [ llvm ]
3 -  Version: [ 3.7.0svn ]
4 -  Release: [ 0 ]
5 -  License: [ GPL ]
6 -  Group:   [ Development/Compilers ]
7 -  Architecture: [ i386 ]
8 -  Source location: [ llvm ]
9 -  Alternate source location: [  ]
[B]10 - Requires: [ /sbin/ldconfig ][/B]
11 - Provides: [ llvm ]
12 - Conflicts: [  ]
13 - Replaces: [  ]

Enter a number to change any of them or press ENTER to continue:

That line has to start with an alphanumeric character, not a /.
But I don't know what that setting means, I'm really noob in compiling.

I've tried to replace /sbin/ldconfig with a blank space and it build the package, but .... will it work?

[marek]

Eh, I think the improvements in LLVM (VGPR spilling and machine scheduler) are much more important for performance and correctness than these changes to Mesa.

The patches shouldn't improve performance, but you made a good point. LLVM has a lot of performance improvements worth mentioning. Not only that, it has compiler support for Tonga (HD 285) and Carrizo, which will be supported by the new amdgpu driver, and Carrizo hasn't even been launched.

[Kraut]

Some updates from the last days fixed all the frame lag in valley for my 7870. Here are some numbers.

Preset: Extreme HD (1080p)
Linux 3.19.0-rc6 x86_64 with oibaf of course
Average FPS: 21.7

Compared to win7 DX11:
Average FPS: 32.9