Radeon vs. Nouveau Open-Source Drivers On Mesa Git + Linux 4.9

[pal666]

I thought mesa drivers shared a lot of code, how is such a big difference possible?

remaining unshared code could result in unbounded amount of difference

[dungeon]

Blah, it is acceptable that drivers are borked during development.

I complain only when releases are borked

[octra]

And thats why i left nVidia... At least the nouveau devs try to improve the situation.
Thanks for the benchmarks!

[marek]

I wonder if the difference between the nouveau and radeonsi performance is due to amdgpu having more robust memory management and radeonsi being a more reliable driver overall.

[imirkin]

I wonder if the difference between the nouveau and radeonsi performance is due to amdgpu having more robust memory management and radeonsi being a more reliable driver overall.

May be worthwhile to run 'perf' and see what's up. From what I gather, radeonsi does more work per batch since it effectively re-emits everything (either there are no hw contexts, or radeonsi doesn't use them). Nouveau also tends to be pretty stingy about actually submitting stuff. Not sure how radeonsi fares there.

There's something to be said for a lack of locking rigour in nouveau, but I think if that's done correctly it should only be a *very* minimal increase in overhead.

There's also a very good mapping between gallium set_* and internal states - not a lot of things cause state validation to hit.

Most of nouveau's instability tends to be due to lack of documentation on how to handle various scenarios, as well as unexpected interactions. I earnestly don't believe solving nouveau's lack of robustness would measurably increase overhead.

[dungeon]

I wonder if the difference between the nouveau and radeonsi performance is due to amdgpu having more robust memory management and radeonsi being a more reliable driver overall.

After lately seeing that CS:GO is double slower on i965 just because DE is Gnome3, MATE and Xfce compositors also show their slowmo cases too, etc... i can't draw any reasonable conslusion when benchmarking is done on... on practicaly any composited desktops

[dungeon]

I would like to see Michael doing those tests in openbox, total to be sure as that does not have those compositor affected weird corner cases... otherwise we also disscus a diff how much EXA, UXA, SNA, GLAMOR... have corner cases with random driver and random compositors while gaming

[marek]

May be worthwhile to run 'perf' and see what's up. From what I gather, radeonsi does more work per batch since it effectively re-emits everything (either there are no hw contexts, or radeonsi doesn't use them). Nouveau also tends to be pretty stingy about actually submitting stuff. Not sure how radeonsi fares there.

We usually have only a couple of batches per frame, so that's a very unlikely cause of the slowdown. We have some overhead in radeonsi, but it's pretty low compared to st/mesa and vbo. We also go through u_vbuf, which nouveau doesn't.

There's also a very good mapping between gallium set_* and internal states - not a lot of things cause state validation to hit.

Yeah, that mapping is not so good for radeonsi. The 2 games where radeonsi is slower than 680 are Bioshock and CS:GO. I've profiled Bioshock so much that I think there is not much to gain from micro-optimizations there.