A Mesa Fix Lands To Take Care Of The R9 290 Issue, Intel/Radeon Performance Problems

[duby229]

50% is well within glxgears margin, 10x is within glxgears margin. Just move the window around and you can see that for yourself. This isn't news.

[dungeon]

But main diff here is probably cos Michel uses xserver git, where there are glamor improvments... but users usually test something else

[droste]

It may changes by a few hundreds fps but this was an increase of at least 50% in "performance". That's not within the error margin. Especially if you read the bug report where they measured before the first change that broke this, after the change and after the fix. It's pretty clear that it is a benchmark for this and even if you repeat yourself it doesn't become more true. And I'm also not sure how the quote was out of context? Nothing you wrote added new infos to this. You just made same claim with more words but without any new evidence.

[dungeon]

Of course it is CPU bound, with DRI2 it is bound to singlethread so more CPU bound and with DRI3 less - it uses more CPU

[duby229]

I guess with the patch glxgears is not anymore CPU bound

glxgears is not cpu bound. It's not anything bound. It just doesn't do very much.

[duby229]

It actually is a benchmark for this problem (but only this!), because what you want to test is how fast can the driver swap the buffers. So lower gpu load -> better swapping test

I don't see how you could possibly tell any difference when just moving the window can change fps by hundreds or even thousands. How can you know the difference is from this patch or from a difference in window position.....

That's why quoting out of context is so stupid. I already said this and now I'm forced to repeat myself because you chose to quote only what matters the least.

[dungeon]

I guess with the patch glxgears is not anymore CPU bound

[droste]

That really doesn't mean anything. [...] It's not capable of showing performance differences. Please benchmark a game, that would actually tell any real difference.

It actually is a benchmark for this problem (but only this!), because what you want to test is how fast can the driver swap the buffers. So lower gpu load -> better swapping test

[M@GOid]

Padoka updated his PPA just before the patch was released... Lets hope he update it again soon.

[duby229]

I applied that patch to my tree. Before:

$ vblank_mode=0 glxgears
ATTENTION: default value of option vblank_mode overridden by environment.
16922 frames in 5.0 seconds = 3384.292 FPS
17131 frames in 5.0 seconds = 3426.033 FPS
17176 frames in 5.0 seconds = 3435.125 FPS

After:

$ vblank_mode=0 glxgears
ATTENTION: default value of option vblank_mode overridden by environment.
26543 frames in 5.0 seconds = 5308.593 FPS
26631 frames in 5.0 seconds = 5326.078 FPS
26310 frames in 5.0 seconds = 5261.816 FPS
26708 frames in 5.0 seconds = 5341.584 FPS

I'm on an R9 390.

That really doesn't mean anything. The difference there could easily be explained by the window spawning in a different spot on screen. If you don't believe me, then run glxgears and move the window around, see for yourself. Just the simple matter of the window being in a different spot changes the framerate. glxgears is not a benchmark. It's not capable of showing performance differences. Please benchmark a game, that would actually tell any real difference.