GLAMOR Acceleration Might Work On Newer X.Org

[Rexilion]

Personally I would love to now what would be the best way to test speed of flags for libjpeg-turbo, mesa or x264 both encoding and decoding and others like it or better yet someone said that on their specific machine certain flag gives additional boost of "%" with no noticed problems.

I agree with the above statements. However, I want to add that, libjpeg-turbo is mostly handwritten asm. I do not believe that compiler flags will change much about it's performance.

[ryszardzonk]

Apologies, I mistook you for jrch2k8.

no offence taken.

What I want to say is that you notice the speed improvements. But packages can break in subtle ways. Packages could change their behaviour in corner cases which do not get as much production testing. These optimizations are 'ready when they are ready'.

That is true but in my experience I does not happen all that often as it is believed. In years with Linux I reported quite a number of bugs and only like 1/10 of them where flag related and some of those few could be fixed by small changes in the code. In one case for example in this very forum in thread about llvm I reported problem with -DG_DISABLE_ASSERT and it turned out it was fixed with adding just one appropriate ifdef to the code already in place.

Furthermore, multimedia packages are already by default mostly optimized with CFLAGS deemed appropiate by it's original author.

This might be true, but once in the past I tested decompressing speed of apps such as bzip2 and gzip once compiled with different flags -Os, -O2, -O3, -O3 + ffmath, etc and difference between slowest and fastest was 10-15%, where like 2-3% was betwwen -Os and -O2, 7-10% from -O3 and then the rest, so replacing default -O2 with -O3 for apps that use a lot of computations I believe to be very appropriate.

Finally, in Gentoo a lot of packages are silently substituting your CFLAGS out of the equation to prevent breakage. The speed improvement is between your ears. However, jrch2k8 mentioning QT4 could be a speed increase. But that is about it.

Yes it does replace it and one might not harness its full potential when simply is going with the default like the above test reveled for me. Going system wide with all the flags available is just plain wrong and will create problems, but saying they optimization are not to be tried on app by app or lib by lib is just as wrong and IMHO it is not only QT that will gain from it.

Personally I would love to now what would be the best way to test speed of flags for libjpeg-turbo, mesa or x264 both encoding and decoding and others like it or better yet someone said that on their specific machine certain flag gives additional boost of "%" with no noticed problems.

[Rexilion]

Whatever gave You the idea that I use that for coreutils??? Have You actually read what You comment on? I said I use conservative settings -O2 for system libs, then there is comma in the sentence...

Apologies, I mistook you for jrch2k8.

my make.conf pass around 30 flags to gcc including LTO/Graphite/bulldozer specifics/etc.[have a regular set of flags too without lto for some problematic packages maybe 30 in my whole emerge world]

What I want to say is that you notice the speed improvements. But packages can break in subtle ways. Packages could change their behaviour in corner cases which do not get as much production testing. These optimizations are 'ready when they are ready'.

Furthermore, multimedia packages are already by default mostly optimized with CFLAGS deemed appropiate by it's original author.

Finally, in Gentoo a lot of packages are silently substituting your CFLAGS out of the equation to prevent breakage. The speed improvement is between your ears. However, jrch2k8 mentioning QT4 could be a speed increase. But that is about it.

[curaga]

Why wouldn't one want LTO for coreutils? ~10% smaller binaries for free.

[ryszardzonk]

The only sane reason I can think of doing this is that if you use something a lot it might help. E.g. like giving the lame encoder 30 CFLAGS to make it faster if you encode a lot of audio. Why on earth do this insanity system-wide?

Seriously, you don't want coreutils with lto and ffast-math.

Whatever gave You the idea that I use that for coreutils??? Have You actually read what You comment on? I said I use conservative settings -O2 for system libs, then there is comma in the sentence...

[Rexilion]

my friend please share the mentioned flags you use. Others like me for instance would like to try them as well I believe to see how their millage varies.

Personally on my install I usually go conservative like -O2 on system libs, -O3 --ffasth-math (or -Ofast) on multimedia & archive compression stuff and few more tweaks here and there

The only sane reason I can think of doing this is that if you use something a lot it might help. E.g. like giving the lame encoder 30 CFLAGS to make it faster if you encode a lot of audio. Why on earth do this insanity system-wide?

Seriously, you don't want coreutils with lto and ffast-math.

[ryszardzonk]

for example
Qt-gui with -o2 native is fast ofc but you notice few Ms delay between click and apps opening
Qt-gui with my 30 flags is almost open when you take your finger of the mouse
Qt-gui with my 30 flags + PGO[<-- not easy] is instant i mean freaking instant

so if you dare to play with your compiler setting you can gain some free perfomance and squeze some additional responsiveness

my friend please share the mentioned flags you use. Others like me for instance would like to try them as well I believe to see how their millage varies.

Personally on my install I usually go conservative like -O2 on system libs, -O3 --ffasth-math (or -Ofast) on multimedia & archive compression stuff and few more tweaks here and there

[ickle]

On 1.14, not 1.13, and it at least runs, if I understand that message correctly.

Resolved. glamor is up and running tests right now on SandyBridge.

[GreatEmerald]

Chris Wilson is claiming it's still broken.

Maybe it's just partially working, or is worse on Intel or something.

On 1.14, not 1.13, and it at least runs, if I understand that message correctly.

[smitty3268]

Or maybe not

Chris Wilson is claiming it's still broken.

Maybe it's just partially working, or is worse on Intel or something.

http://lists.x.org/archives/xorg-devel/2013-March/035730.html