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

--- Comment #2 from smoki smoki00790@gmail.com ---

I seeing that too now, all of those are 32bit apps is it?

-03 compiled mesa seems to fixed that for me.

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

--- Comment #4 from Maciej gutigen@outlook.com --- Wait a minute... Unigine is affected, but it's 64bit. Reporting bugs is confusing, especially when you can't edit your post ;)

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

--- Comment #5 from smoki smoki00790@gmail.com --- (In reply to comment #4)

Wait a minute... Unigine is affected, but it's 64bit. Reporting bugs is confusing, especially when you can't edit your post ;)

Unigine Heaven have 64 and 32 variants in it as i see, are you sure he does not load 32bit one?

If you build you mesa try -O3 gcc optimization, that seems fixed those... don't know yet what is particular issue with default optimization :).

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

--- Comment #7 from smoki smoki00790@gmail.com --- Actually nothing to do with the -O3, but with the -mtune -march it seems.

On Debian default is -mtune=generic -march=i586 maybe that is the problem, if i pass -mtune=native -march=native then it performs fine in most cases :) But not all, glretrace sometimes perform slow sometimes fast... so build system seems borked currently even more on 32bit :)

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

--- Comment #9 from Maciej gutigen@outlook.com --- Did an update today, performance decrease is still there, but fps drops are gone. I had no other apps running in the background, so I'm not sure what's up. However fps drops in TF2 are still a thing.

As for bisecting, I really have no skills to do that, I'm just a gamer with AMD card :/

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

--- Comment #11 from smoki smoki00790@gmail.com --- (In reply to comment #8)

Can you guys bisect?

So latest good is 37d43ebb28ce8be38f3d9b0805b8b14354ce786d, after 07c65b85eada8dd34019763b6e82ed4257a9b4a6 there is corruption (so i can't tested this) all the way until 150ac07b855b5c5f879bf6ce9ca421ccd1a6c938 one week later where is a fix for 3.17 kernel. Took the patch tried 07c65b85eada8dd34019763b6e82ed4257a9b4a6 again an bingo, blah, blah...

So PIPE_USAGE_STREAM seems to be a main problem again, but unlike 64bit on 32bit it can't be reverted to old behavior, on 32bit it is unusable produce much corruption.

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

--- Comment #13 from smoki smoki00790@gmail.com --- (In reply to comment #12)

That happens with default ./autogen blah blah

As i said earlier if i pass -mtune=native -march=native flags perf is normal, very weird and funny thing in the same time :D

But almost normal, as i said earlier too glretrace for example is slowish again :) Very weird issues, all is fine on 37d43ebb28ce8be38f3d9b0805b8b14354ce786d.

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

--- Comment #15 from smoki smoki00790@gmail.com --- Default what Debian 32bit passes in addition to mesa options is:

/usr/lib/gcc/i586-linux-gnu/4.9/cc1 -E -quiet -v -imultiarch i386-linux-gnu - -mtune=generic -march=i586

That is with -mtune=generic -march=i586, with -mtune=native -march=native on AMD Kabini it passes this:

/usr/lib/gcc/i586-linux-gnu/4.9/cc1 -E -quiet -v -imultiarch i386-linux-gnu - -march=btver2 -mmmx -mno-3dnow -msse -msse2 -msse3 -mssse3 -msse4a -mcx16 -msahf -mmovbe -maes -mno-sha -mpclmul -mpopcnt -mabm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mbmi -mno-bmi2 -mno-tbm -mavx -mno-avx2 -msse4.2 -msse4.1 -mlzcnt -mno-rtm -mno-hle -mno-rdrnd -mf16c -mno-fsgsbase -mno-rdseed -mprfchw -mno-adx -mfxsr -mxsave -mxsaveopt -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=2048 -mtune=btver2

So Debian default works fine for the 10.2 branch, and for the 10.3-devel up to the commit 37d43ebb28ce8be38f3d9b0805b8b14354ce786d . But anything newer is affected, 10.3 branch and git master.

Maybe some of those options need to be added to default, not sure what of these make is work normal :)

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

--- Comment #17 from smoki smoki00790@gmail.com --- OK i found -mtune=generic is culprit for performance :). Played a little with -mtune to found what is minimum this code wants to work fast:

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

So -mtune=generic seems to set lower cpu target than this code needed to perform fast.

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

--- Comment #19 from smoki smoki00790@gmail.com --- (In reply to comment #18)

Just tried oibaf's radeonsi_dri.so to copy here on Debian (just to be sure :D) and it suffers from the same problem with -march=generic ;)

I mean -mtune=generic of course :).

Now to bisect where that SSE4.1 code start to compile this slow (4 minututes on Kabini just for that) :D Issue also not present on 64bit ;)

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

--- Comment #21 from smoki smoki00790@gmail.com --- (In reply to comment #20)

(In reply to comment #19)

...

(In reply to comment #18)

...

Just tried oibaf's radeonsi_dri.so to copy here on Debian (just to be sure :D) and it suffers from the same problem with -march=generic ;)

I mean -mtune=generic of course :).

Now to bisect where that SSE4.1 code start to compile this slow (4 minututes on Kabini just for that) :D Issue also not present on 64bit ;)

I haven't seen the perf issue on my pure 64 bit setup, but have noticed that the compile sits on sse4.1 for a while recently - just using one core, like it's blocking the other threads of a make -j5 till it's done.

Oh i bisected that ine, it takes 200X more time to compile on 32bit :D , actually compile libmesa_gallium i think this is the commit:

http://cgit.freedesktop.org/mesa/mesa/commit/?id=d55f77b503ab7b59ecdd8f31c4f...

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

--- Comment #23 from smoki smoki00790@gmail.com --- (In reply to comment #22)

(In reply to comment #21)

...

(In reply to comment #20)

...

(In reply to comment #19)

...

(In reply to comment #18)

...

Just tried oibaf's radeonsi_dri.so to copy here on Debian (just to be sure :D) and it suffers from the same problem with -march=generic ;)

I mean -mtune=generic of course :).

Now to bisect where that SSE4.1 code start to compile this slow (4 minututes on Kabini just for that) :D Issue also not present on 64bit ;)

I haven't seen the perf issue on my pure 64 bit setup, but have noticed that the compile sits on sse4.1 for a while recently - just using one core, like it's blocking the other threads of a make -j5 till it's done.

Oh i bisected that ine, it takes 200X more time to compile on 32bit :D , actually compile libmesa_gallium i think this is the commit:

http://cgit.freedesktop.org/mesa/mesa/commit/ ?id=d55f77b503ab7b59ecdd8f31c4f7dc498710e75b

For this look, here:

http://lists.freedesktop.org/archives/mesa-dev/2014-August/065823.html

Greetings and happy 'bisecting'...;-)

Dieter

So what is the solution for that after one month? Simply to use -O0 maybe :)

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

--- Comment #25 from smoki smoki00790@gmail.com --- (In reply to comment #24)

(In reply to comment #23)

...

(In reply to comment #22)

...

(In reply to comment #21)

...

(In reply to comment #20)

...

(In reply to comment #19)

...

(In reply to comment #18) > Just tried oibaf's radeonsi_dri.so to copy here on Debian (just to be sure > :D) and it suffers from the same problem with -march=generic ;)

I mean -mtune=generic of course :).

Now to bisect where that SSE4.1 code start to compile this slow (4 minututes on Kabini just for that) :D Issue also not present on 64bit ;)

I haven't seen the perf issue on my pure 64 bit setup, but have noticed that the compile sits on sse4.1 for a while recently - just using one core, like it's blocking the other threads of a make -j5 till it's done.

Oh i bisected that ine, it takes 200X more time to compile on 32bit :D , actually compile libmesa_gallium i think this is the commit:

http://cgit.freedesktop.org/mesa/mesa/commit/ ?id=d55f77b503ab7b59ecdd8f31c4f7dc498710e75b

For this look, here:

http://lists.freedesktop.org/archives/mesa-dev/2014-August/065823.html

Greetings and happy 'bisecting'...;-)

Dieter

So what is the solution for that after one month? Simply to use -O0 maybe :)

Ping Jason Ekstrand, maybe 8-)

Ping.

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

--- Comment #27 from smoki smoki00790@gmail.com --- OpenJK even with -O0 is ~2.5x times faster then -O2 -mtune=generic :)

Anyway, just found code example from bug 83442 is useful here too, so maybe more people can easely test if they are affected.

32bit on commit 37d43ebb28ce8be38f3d9b0805b8b14354ce786d:

-mtune=generic 4-7ms -mtune=native 6-10ms -O0 6-10ms

32bit current git:

-mtune=generic 197-200ms -mtune=native 5-8ms

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

Fabio Pedretti fabio.ped@libero.it changed:

What |Removed |Added ---------------------------------------------------------------------------- Summary|Sudden framerate drops in |Sudden framerate drops in |multiple games |multiple games when | |compiling with | |-mtune=generic (as well | |with -mtune=pentium-mmx and | |older CPUs)

--- Comment #29 from Fabio Pedretti fabio.ped@libero.it ---

Oh i bisected that ine, it takes 200X more time to compile on 32bit :D , actually compile libmesa_gallium i think this is the commit:

The slow compile should be fixed with: http://cgit.freedesktop.org/mesa/mesa/commit/?id=cfeb394224f2daeb2139cf4ec48...

Is the original issue - slow performance with -mtune=generic - still an issue?

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

--- Comment #31 from smoki smoki00790@gmail.com --- As i mentioned on your Phoronix thread, after much and further testing i am pretty sure now that generic make those random lockups on 64bit :)

Don't use Chromium but those people from bug 81644 should try non generic tuned build :)

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

--- Comment #33 from smoki smoki00790@gmail.com --- (In reply to smoki from comment #32)

As of mesa commit 7b4276d7acf2e0f77044cb50caa6ad936fa78786 -mtune=generic works normal.

After further testing actually this fixed major fps drops with -mtune=generic, but there is still very worse stuter in (m)any games with it , so i not considered still this as fixed.

I also tried this patch https://bugs.freedesktop.org/attachment.cgi?id=107655 to remove corruption after that commit, it helps for that... but -mtune=generic is not fixed, i need to patch mesa too to remove any occuranes of GTT_WC then -mtune=generic works fine for me.

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

--- Comment #35 from smoki smoki00790@gmail.com --- (In reply to Marek Olšák from comment #34)

Is this issue still happening on current Mesa git?

32bit apps on 32bit kernel are fine, as GTT_WC is disabled for X86_32:

http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=a0...

But now issue appear too for 64bit kernel using 32bit apps, so it is still an issue. 64bit kernel and 64bit apps are not affected.

Unrelated to this driver, but i also found that 32bit fglrx is also slow on the same thing... GTT_WC while running some 32bit apps simply made things much slower. Of course no idea how to do anything with that driver to 100% approve that :)

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

--- Comment #37 from egon2003 erik.badman@gmail.com --- I updated my videocard bios and that made everything a lot better, still some minor drops here and there but for example Unigine Heaven runs as it should now.

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

--- Comment #39 from smoki smoki00790@gmail.com --- (In reply to smoki from comment #38)

egon2003, please open another bug for specific issue.

This one is related to only 32bit some apps run much slower, compiler so gcc involved, libc maybe... that sort of things.

Huh and when i mention libc and immediately found it, just libc6-i686 was not installed - what a buff :D

Yeah i will close this one now, but someone needs to wrote it somewhere even highly depend libc6-i686 for mesa and Catalyst even.