Major Performance Breakthrough Discovered For Intel's Mesa Driver

[Kano]

@darkbasic

Sandy Bridge: iX-2xxx
Ivy Bridge: iX-3xxx
Haswell: iX-4xxx

That means your GPU is not yet supported by that Mesa patch. Basically Haswell was not that much faster over Ivy Bridge, maybe they could speed it up as well. In case you want to use fullspeed you should NOT use performance mode (only works with intel_pstate=disable anyway) as you disable Turbo mode too. Better enable all ACPI C-States, Turbo and SpeedStep in the firmware, maybe combined with All Core Turbo setting (basically out of spec, but should do fine) and it will rock With external gfx Haswell is a useless upgrade, maybe with the small exception of the i7-4790k in case you don't already oc your cpu > 4 ghz.

[dungeon]

I have an i7-3770K. Do you think using the performance governor will be enough? I'm pretty doubtful about your theory, but I'm so tired of this bug that I'm even willing to do a pilgrimage to the AMD holy grail if necessary

Well just try it if it helps , i had also these lockups in 3.16 kernel cycle (i tried nearly everything and i mean it , i know how that bug is awfull) until i disable freq scaling it completely in my kernel config.

Actually i disable it because of performance reason at first, then i discovered it also triggers some lockups when radeon is used

[darkbasic]

I have an i7-3770K. Do you think using the performance governor will be enough? I'm pretty doubtful about your theory, but I'm so tired of this bug that I'm even willing to do a pilgrimage to the AMD holy grail if necessary

[dungeon]

@darkbasic

What CPU do you have? Did you try without CPU frequency scaling?

BTW did you have sometimes "CPU X stuck. Dazed and confused, blah, blah..." messages? I somehow think CPU scaling interfere when that happens and triggers those lockups in radeon . It is wild guess of course, but in my testing with kernel without CPU frequency scaling feature even compiled, those random lockups just goes away for the last ~2 months

[darkbasic]

After all this time, there's still not one person who's bisected the regression.

Maybe because it's not that simple? Did you try bisecting a bug which nobody knows how to reproduce and which can take up to 5 days to mark a commit as good?

If there's a guaranteed non-interactive reproducer and someone's willing to lend a machine for a longer period of time or so, probably not hard to script automated bisecting

You're making semplicistic statements: I have a 100% reliable radeonsi lockup with a testbox fully available to developers and still nobody had time to ssh into it. Christian did help me to narrow it down to the 3D engine (no VM or DMA) but unfortunately sometimes the real life steps in and he can't help me anymore right now. I sent an e-mail to the AMD crew but I still didn't find anyone interested enough to even dare to reply. Do you still think it's that simple? I challenge you to get some help with a non-reproducible issue like bug #79980: good luck

its stable when you do not use chrome / chromium ...

Wrong. Firefox users suffer from the same bug and I had myself lots of crashes without Chrome. Sometimes even logging into KDE had been enough to trigger the crash.

P.S.
This is the second time I'm writing this post because of the fu*king bug #79980. Damn I hate it

[dungeon]

its stable when you do not use chrome / chromium ...

Is that issues begin when they change toolkit? GTK>Aura 35>36 versions?

[tomtomme]

'we've discovered a way to make the radeonsi driver STABLE' would be even better.

its stable when you do not use chrome / chromium ...

[nanonyme]

Hard to bisect something that takes 5 minutes to 3 days to arise. I am the OP to bug 61844 for Mesa's RadeonSI random crashes. Why don't you go ahead and bisect it for me over an entire month, even if it is because of a single commit? Be reminded it's not known clearly to be Mesa, or a kernel update that shows it, or anything else. I personally think it's DMA issues of some sort, but I'm also not a kernel/AMD dev. Still, besides this bug for me, RadeonSI is fine on my R9 270X. But this bug is bad. And it's been a problem for about 3 months now. Other than that, most games run fine with everything on Ultra: Civ 5, The Witcher, tons of valve games. Rust has major engine issues with it being a POS, but most games programmed well are just fine.

If there's a guaranteed non-interactive reproducer and someone's willing to lend a machine for a longer period of time or so, probably not hard to script automated bisecting

[log0]

Easy now guys. The truth is that the FGLRX is stable for some cards/games, but unstable for others ... the FOSS drivers are also stable for some, but not for others. If you read the forums enough you'll notice that.

I myself hadn't had a problem with the radeon driver for maybe 3 or 4 years, but I didn't game much with it.

I think the Intel Linux driver guys don't benchmark against the Windows driver. But they run benchmarks against themselves, to track performance changes.

And then there are the AMD guys who don't (have time to) benchmark at all.

My guess is, if you want performance to match the Windows driver you will have to figure out it by yourself, like the Lunar guys did.

[jaxxed]

Don't you dare. You have no idea WTF you're talking about and Darkbasic is 100% correct. Ever since Linux 3.14 and the new radeonsi firware there is a random crash bug that hasn't been fixed so you either have an old kernel or a older linux firmare (that technically was 600) or are lying. I had to go back to catalyst for stablity (which hasn't crashed once).

Easy now guys. The truth is that the FGLRX is stable for some cards/games, but unstable for others ... the FOSS drivers are also stable for some, but not for others. If you read the forums enough you'll notice that.

I myself hadn't had a problem with the radeon driver for maybe 3 or 4 years, but I didn't game much with it.