Major Performance Breakthrough Discovered For Intel's Mesa Driver

[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 ...

[dungeon]

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

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

[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]

@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]

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]

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

[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?

But just keep in mind performance mode is still frequency scaling used, it looks similar but that is not the same as not at all . So, if you can and compile your kernels, disable it compitely to be sure and at first watch the temps!!! (i don't know what happen temp/power wise on i7-3770K when feature is not there at all) and try to get some random crash...

[jrch2k8]

Very broadly experienced bug for MONTHS: Random radeonsi crashes
Nobody knows what the heck is causing this. Radeon HD 7770 here on Arch Linux but with Mesa 10.1.4 to at least avoiding this blocker bug (but apparently Mesa is not to blame).
But I agree with you that Catalyst is horrible. It was stable for me, at least the last two years, but has a mountain of bugs. I actually had to switch to Radeon because GPU accelerated rendering in Firefox resulted in a black window.

mmm, holunder i have an MSI R7700 Ghz Edition GD5 and i don't suffer from this bug, maybe that can helps pin point which manufacturers have the bug

[chrisb]

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?


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

Tracking down such a bug is not impossible, it just takes time and patience. The bug report you are linking to is a mess, as pointing out by others, it has become a dumping ground for different bugs and it is not obvious which reports are related to the issue you are having. My advice:

• Compile your packages with debugging symbols. You posted a backtrace without debugging symbols, which is almost useless. A backtrace is much more useful with line numbers.
• Come up with a reliable test. It is very good if this step can be automated, like running the Phoronix Test Suite or some other benchmarks. But you need to have an actual test that is reliable, even if that test is "use as my desktop for 7 days without hanging". Automation or overnight runs are preferable - can you run PTS or some demo mode overnight to reproduce? Can you loop mplayer playing fullscreen video files overnight? There must be some way of testing, for some period of time, that causes the fault to appear if it is present.
• Test methodically. If it is not clear where the bug lies, then make a test matrix, covering combinations of versions of different packages, and then test one after the other. Yes, it takes time, but sometimes it is the only way to figure out where the fault lies.
• Remember that each system is unique due to different hardware, cpu, gpu, mainboard, software, compiler, user usage patterns etc. If you often hit a bug, you might be the only person who can repeatedly reproduce that bug on their system. If one of the developers could reliably reproduce the issue, it would probably be fixed already.
• It helps to have a remote machine logged in via ssh (or even better, a serial port console) so you can get logs when the gui hangs. See Reporting GPU lockup Bugs and Backtrace with gdb/ Debugging Hangs / Freezes / Lockups for how to gather information about the crash by either logs or attaching to the hung process with gdb and getting a backtrace.
• If the kernel is crashing and non-responsive, try using kdump or crashdump to capture the crash details - see Ubuntu Kernel Crash Dump and How to use kdump to debug kernel crashes
• Don't forget that instability can also be caused by hardware incompatibilities, overheating, PSU glitches, etc. It might be worth swapping out your graphics card for another that is known to have good support, and running that for a while to see if it is stable. Put the "bad" card in to another PC and see if you can still reproduce the problem etc.
• Patience is a virtue. Professional testers can spend months identifying, characterising, and creating test cases to reproduce a single bug. I once tracked down an intermittent bug that occurred, on average, once every six weeks... try to look upon it as a fun project where you will get to do some cool stuff and learn some new things, rather than the laborious repetitive task it actually is