Major Performance Breakthrough Discovered For Intel's Mesa Driver

[TheAaronB123]

no, it is easy. it is the same number of steps regardless. if bug doesn't occur for long time then you are happy because you have no crashes. if it occurs sooner, then you are happy because you are one step closer to end.
so stop complaining and bisect

You are wrong, that is all I'm going to leave it at. I've bisected a few issues for them related to my card, I'm not exactly new, I even had a automated script to forward and set up bisects and installs. When a commit isn't bad because of one commit specifically in one software but maybe multiple like the kernel and such, you can't bisect from one and get a good result, period. YOu narrow it down by jumping versions, but you also have to know which mesa is good. If the kernel is bad, they're ALL bad! Does it make sense, yet?

Hey AMD: I do have a 100% reliable 3D engine lockup, is someone interested before selling my card to buy a GTX 970?

I also did just that, My GTX 970-2978 Superclocked will be in the mail in 2 days, and this AMD possessed card will be gone.

Please, buy my card, bisect it, then come back and tell me I'm an idiot, I promise you I'm not. I mean seriously, what a joke it is to call people out on this. Also to not, I've had about 20 crashes the last 4 days, about 5 a day, for no reason. I'm on about 45 minutes stable right now, but we'll see how long it takes to crash. The 3.18 kernel also affect this crash: It used to be able to GPU Reset into usability for another few seconds/minutes and let you prepare/reboot, but now it doesn't even do that.

Also, an R9 270X is a 7850, basically. Since everyone with a 77XX series is stable, maybe...you don't have the instability because your card doesn't have the same hardware? Because it doesn't. So good for you you picked an old enough card to be stable. New hardware still is unstable.

[chrisb]

Those backtraces are useless anyway becuase 90% of times they are caused by the lockup recover which tries to reset the GPU.

Backtraces are usually useful - you won't know if your backtrace is useless or not until you get it.

I will repeat it again: I didn't manage to find a reproducible pattern. It doesn't matter how long we tried, nobody managed.

I managed to find a 100% reproducible pattern and Christian helped me telling which logs he needed, which patches to apply to narrow it down etc. It may or not may be related to the "random radeonsi crashes" but hey, it's a 100% reproducible lockup and still no one except Christian seems to be interested
Hey AMD: I do have a 100% reliable 3D engine lockup, is someone interested before selling my card to buy a GTX 970?

Are you talking about two separate issues here? You say that nobody managed to find a reproducible pattern, but then say that you managed to find a 100% reproducible pattern? Anyway, when I was talking about testing I didn't mean that your test must necessarily be something short and easy - your test could be manually using the system for a week - whatever it takes to discriminate between a working system and a failed system.

The bug is in the kernel. Period.

Then bisect the kernel. Even if it takes, say, 5 days of manual use to test each kernel, you could find the bad commit in 30-40 days.

BULLSHIT. More than one time I already offered remote access and I'm even willing to send my GPU to a developer for a couple of weeks to fix this nasty thing. Any more excuses?

And how do you think that having remote access to a system, without a way to reproduce the problem, is going to help? You would probably need to send the whole system, including the software you are running, and have a way for the developer to reproduce the bug. If you are willing to do that, then the developers might be more interested. But right now your bug report is basically, "I am running random bits of software that I compiled off the internet, and my computer hangs every so often, and I have no idea why, and have no crash logs or backtraces or bisect results or reproducible test case, or anything else for you to look at". What would you do if you were a developer reading a bug report like that?

I always debug with my laptop attached and I even have a serial console, but if a developer doesn't tell you what to do it's just a waste of time.

You have been given lots of advice by several people. What more do you need? Compile with debug symbols, get a proper backtrace, kernel crash log, bisect the kernel, etc. If you can't be bothered to do any of that, then that is fine, but don't blame the developers when your bug report is insufficient to identify the problem.

I am patient since 6 months. HALF AN YEAR. Tired to be patient, time to buy a GTX 970.

I suggest you do that and move on with your life.

[asdfblah]

Oh, I forgot I came to say something in this thread...
Please, LunarG guys, work in the radeon driver :P

[asdfblah]

I will repeat it again: I didn't manage to find a reproducible pattern. It doesn't matter how long we tried, nobody managed.
...
I always debug with my laptop attached and I even have a serial console, but if a developer doesn't tell you what to do it's just a waste of time. I managed to find a 100% reproducible pattern and Christian helped me telling which logs he needed, which patches to apply to narrow it down etc. It may or not may be related to the "random radeonsi crashes" but hey, it's a 100% reproducible lockup and still no one except Christian seems to be interested
Hey AMD: I do have a 100% reliable 3D engine lockup, is someone interested before selling my card to buy a GTX 970?

???

Anyway... as I posted in other thread, this is the kind of things the radeon devs have to deal with: https://bugs.freedesktop.org/show_bug.cgi?id=60389#c28 https://bugs.freedesktop.org/show_bug.cgi?id=60389#c64
Do you think they have an easy job? They are a small group, and have managed to make an awesome driver... I doubt they don't want to see their own product improved. It's just that the hardware seems particularly picky, and they don't really have a lot of time or resources...

[pal666]

Hard to bisect something that takes 5 minutes to 3 days to arise

no, it is easy. it is the same number of steps regardless. if bug doesn't occur for long time then you are happy because you have no crashes. if it occurs sooner, then you are happy because you are one step closer to end.
so stop complaining and bisect

[darkbasic]

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

Those backtraces are useless anyway becuase 90% of times they are caused by the lockup recover which tries to reset the GPU.

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

I will repeat it again: I didn't manage to find a reproducible pattern. It doesn't matter how long we tried, nobody managed.

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

The bug is in the kernel. Period.

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

BULLSHIT. More than one time I already offered remote access and I'm even willing to send my GPU to a developer for a couple of weeks to fix this nasty thing. Any more excuses?

• 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

I always debug with my laptop attached and I even have a serial console, but if a developer doesn't tell you what to do it's just a waste of time. I managed to find a 100% reproducible pattern and Christian helped me telling which logs he needed, which patches to apply to narrow it down etc. It may or not may be related to the "random radeonsi crashes" but hey, it's a 100% reproducible lockup and still no one except Christian seems to be interested
Hey AMD: I do have a 100% reliable 3D engine lockup, is someone interested before selling my card to buy a GTX 970?

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

Hardware incompatibilities which I don't have with kernels <=3.14 or with fglrx
In the meantime I even changed PSU and it's not an overheating problem because it happens even after a few minutes I started the pc.

• 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

I am patient since 6 months. HALF AN YEAR. Tired to be patient, time to buy a GTX 970.

[profoundWHALE]

I have a 7870, I've used 6000 series cards, and I've built and run 3 r600 / radoensi APUs. The only time radeonsi ever crashes is in extremely new games, and very rarely, but example I got one crash in ~80 hours of borderlands 2 and it was due to a firmware bug on the card that got fixed a week later.

Catalyst, on the other hand, is lucky to last an afternoon.

Can confirm, I played borderlands for about an hour and it crashed on me with fglrx. I'll be trying it on RadeonSI tonight, but every game I've tried with RadeonSI runs much smoother and is more responsive than fglrx.

[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

[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

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