Major Performance Breakthrough Discovered For Intel's Mesa Driver

[theghost]

I can confirm radeonsi (with Radeon R9 270x) is pretty much broken atm.
Also it's pretty easy to trigger hangs / crasher but I don't mind to create bug reports. I'm just a user.

Just run Gnome-Shell and start a CS:GO game. Full xorg crash at nearly every game. Happens since Xorg 1.16 and Mesa 10.3.x.

Also run XCom, just play a few minutes. Screen turns black, game comes back and full xorg crash. Also happens since Xorg 1.16 and Mesa 10.3.x.

Afaik the second crasher is pretty much known, I think it's this guy: https://www.libreoffice.org/bugzilla...g.cgi?id=80419

I don't understand why the bug reporter should bisect the problem. There are maintainers who are paid for this and who know their driver.

[smitty3268]

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.

So it happens in 3 days or less each time?

Great, that means you just have to run each version for a solid week. That's plenty of extra time, just to make sure.

After 3 months, you could have run run 13 steps in the bisection process. It'd probably be done, and fixed by now.

Instead, we are approximately nowhere. I bet in another 3 months, there are still people on here complaining about how it hasn't been fixed yet.

And that's fair enough, you can complain all you like. But if you really want it fixed, now is the time to start helping find the cause.

[tomtomme]

If you think that is dysfunctional, then head on over to AMD. How many drivers for Linux will AMD be maintaining? 1? 2? 3? I am not even sure now. I wish Valve would spend its own money to hire a third party developer to aid AMD. Competition is good but AMD needs some help in that department.

they are maintaining 1 and for some cases 2 linux drivers:

R9 285 (GCN 1.2) and newer: new combined oss+fglrx driver only
HD7000 to R9 (GCN 1.0+1.1): oss radeonsi + fglrx
HD5000 to HD6000 (VLIW): oss r600 + fglrx (but I bet it will be legacy soon)
HD2000 to HD4000 (VLIW): oss r600 only (fglrx is not maintained anymore = legacy)
even older cards: oss r300

[curaga]

So it happens in 3 days or less each time?

Great, that means you just have to run each version for a solid week. That's plenty of extra time, just to make sure.

After 3 months, you could have run run 13 steps in the bisection process. It'd probably be done, and fixed by now.

Instead, we are approximately nowhere. I bet in another 3 months, there are still people on here complaining about how it hasn't been fixed yet.

And that's fair enough, you can complain all you like. But if you really want it fixed, now is the time to start helping find the cause.

You really smell of hypocrisy. Show me one bug where *you* bisected something that took that long, on your workstation that you need daily to be stable for *actual work*.

[darkbasic]

You really smell of hypocrisy. Show me one bug where *you* bisected something that took that long, on your workstation that you need daily to be stable for *actual work*.

+1

Also, you don't have any guarantee that some other bug steps in and ruins your 3-months bisection because you marked a good commit as bad.

[smitty3268]

You really smell of hypocrisy. Show me one bug where *you* bisected something that took that long, on your workstation that you need daily to be stable for *actual work*.

Sure. I'll do that as soon as you show me where I've been complaining about a bug in open source code that hasn't been fixed for months.

It'd be different if this was proprietary software. You can't fix that.

[saski]

Any Updates on if and when these patches will be made public?

[dungeon]

Any Updates on if and when these patches will be made public?

These patches are probably already part of SteamOS Check those lunarg forks on github: https://github.com/LunarG/steamos_mesa/ or releases https://github.com/LunarG/steamos_mesa/releases , etc... maybe that is it .

Guessing it is this patch for mesa

http://lists.freedesktop.org/archives/intel-gfx/2014-October/054416.html

Plus something in the kernel, might be that is already part of some recent kernel... btw i take this with huge grain of salt - i don't have intel hardware to test that claim

[saski]

These patches are probably already part of SteamOS Check those lunarg forks on github: https://github.com/LunarG/steamos_mesa/ or releases https://github.com/LunarG/steamos_mesa/releases , etc... maybe that is it .

Guessing it is this patch for mesa

http://lists.freedesktop.org/archives/intel-gfx/2014-October/054416.html

Plus something in the kernel, might be that is already part of some recent kernel... btw i take this with huge grain of salt - i don't have intel hardware to test that claim

Thanks for pointing that out. No noticable improvement on my mobilel i7-Haswell. Maybe the drm patches didn't the latest danvet-nightly branch yet. Hopefully we'll see some benchmarks on phoronix in the near future.

[saski]

Thanks for pointing that out. No noticable improvement on my mobilel i7-Haswell. Maybe the drm patches didn't the latest danvet-nightly branch yet. Hopefully we'll see some benchmarks on phoronix in the near future.

Not merged yet - unfortunately.

http://lists.freedesktop.org/archive...er/055267.html