Reducing The CPU Usage In Mesa To Improve Performance

[asdfblah]

I barely know anything about all of this, but... Mesa isn't optimized for SSE2? Even in 64 bit builds? One would think this is one of the first things you'd do :/
That's news to me...

[My8th]

Maybe you can get early access to Civilization: Beyond Earth, and some donated hardware. The game will definitely not be playable without binary drivers but wishful thinking...wishful

[looserouting]

i am wondering why audio isnt disabled for opengl benchmarks o.0

[dungeon]

This is a long shot but does changing the first if statment from:

if (aligned_count >= 4) {

to

if (aligned_count >= 8) {

help at all?

The same with that .

I barely know anything about all of this, but... Mesa isn't optimized for SSE2? Even in 64 bit builds? One would think this is one of the first things you'd do :/
That's news to me...

One is build time compiler optimization, another is runtime mesa optimization.

i am wondering why audio isnt disabled for opengl benchmarks o.0

Why so? Likely you will get same/similar results, it is better to disable sound driver at boot time if you wish just to compare sound driver overhead . It can be tramendous difference even in games if there is CPU overhead, i have 25% better fps rate in Xonotic 64bit, and 30% better fps rate in Xonotic 32bit just with the sound driver disabled .

But Xonotic is special case it use plain alsa for sound, no openal... so it can't be optimized

[tarceri]

@dungeon

How exactly are you running the tux racer as a benchmark? I've tried:

etr -a

on fedora 20 but it doesn't do anything it just opens the game as normal.

Update: Also how are you measuring a drop in cpu? I just ran it in callgrind completing the first level and its saying only 0.04% of cpu is spent in the function the patch optimises. Its was called only 1200 time compared to millions of times in OpenArena.

[tarceri]

I barely know anything about all of this, but... Mesa isn't optimized for SSE2? Even in 64 bit builds? One would think this is one of the first things you'd do :/
That's news to me...

Just because SSE2 is enabled doesnt always mean gcc will know when its best to use it.

[V10lator]

Just because SSE2 is enabled doesnt always mean gcc will know when its best to use it.

So there's a performance difference between compiling with -march=native and the SSE2 patch(es) ? If so: Are there any plans for SSE3, SSE4a and/or 3Dnow! patches (could be good for AMD CPUs) ?

[dungeon]

@dungeon

How exactly are you running the tux racer as a benchmark? I've tried:

etr -a

on fedora 20 but it doesn't do anything it just opens the game as normal.

Update: Also how are you measuring a drop in cpu? I just ran it in callgrind completing the first level and its saying only 0.04% of cpu is spent in the function the patch optimises. Its was called only 1200 time compared to millions of times in OpenArena.

Benchmarking by eye GALLIUM_HUD=cpu,fps Somehow benchmark does not work it seems in 0.6 etr (it is more like ppracer, but not extremetuxracer), and 0.5, 0.4 extremetuxracer... i much like planetpenguinracer 0.3... huh, how many forks that tuxracer had

So there's a performance difference between compiling with -march=native and the SSE2 patch(es) ? If so: Are there any plans for SSE3, SSE4a and/or 3Dnow! patches (could be good for AMD CPUs) ?

3Dnow! is abandonware as of 2010. i think, it is not recommended to use at any new code... maybe it is now right time to remove that hardly ever halfly broken instruction from mesa

Sometimes it is the best to remove all that optimization from mesa --disable-asm and hackete hack configure.ac to remove sse4.1 support... yeah sometimes you can see better performace if you don't build that

[tarceri]

So there's a performance difference between compiling with -march=native and the SSE2 patch(es) ? If so: Are there any plans for SSE3, SSE4a and/or 3Dnow! patches (could be good for AMD CPUs) ?

If anyones interested I just got sent an email pointing me to this post [1] about auto-vectorization in gcc i.e automated use of SSE/AVX.

There are likely to be at most 3 targets for this particular optimisation:

SSE2 - Because its common and can be assumed by default in 64-bit builds.

SSE4.1 - Because it includes min/max instructions which means its faster as thats the main thing the function does.

AVX2 - Because it has min/max instructions that can compare 8 values at once rather than 4 in SSE4.1

Also for anyone curious here is a list of the intrinsics available [2]

[1] http://locklessinc.com/articles/vectorize/
[2] https://software.intel.com/sites/lan...trinsicsGuide/

[tarceri]

Benchmarking by eye GALLIUM_HUD=cpu,fps Somehow benchmark does not work it seems in 0.6 etr (it is more like ppracer, but not extremetuxracer), and 0.5, 0.4 extremetuxracer... i much like planetpenguinracer 0.3... huh, how many forks that tuxracer had

To use your own words, I'm not impressed by that benchmarking technique As I said previously the function in question seems to be hardly used at all in extremetuxracer so if you are really seeing a difference (which would be very difficult to conclude because your not really comparing anything) its very unlikely that its caused by the patch.

Sometimes it is the best to remove all that optimization from mesa --disable-asm and hackete hack configure.ac to remove sse4.1 support... yeah sometimes you can see better performace if you don't build that

I'm not trying to be rude here but I seriously think you need to try some real benchmarks before handing out this advice or providing feedback on patches.

Also I'm pretty sure sse4.1 support in mesa is only currently use to build one function which is used in the intel driver, so its highly unlikely that removing this from configure.ac will do anything at all since you are using AMD hardware.