That Radeon Performance Regression For R9 290 Might Be Nailed

[phoronix]

Phoronix: That Radeon Performance Regression For R9 290 Might Be Nailed

Present in the Linux 4.7 kernel and thus far in the Linux 4.8 development cycle has been a significant performance regression affecting the Radeon R9 290 and other select GPUs. This performance drop has been very noticeable and I've seen it since Linux 4.7-rc1 while finally an independent user went through the process of bisecting the kernel to find the problematic commit of this hefty performance drop...

http://www.phoronix.com/scan.php?page=news_item&px=R9-290-Perf-Drop-Commit

[M@GOid]

I want to say thanks to Kai for the trouble of doing the bisecting thing.

[M@GOid]

Oh, and for those of you who can install the kernel from source, Alex Deucher is asking for people to test the solution: https://bugs.freedesktop.org/show_bug.cgi?id=97260#c16

[kenjitamura]

Oh, and for those of you who can install the kernel from source, Alex Deucher is asking for people to test the solution: https://bugs.freedesktop.org/show_bug.cgi?id=97260#c16

Wouldn't call that a solution so much as a stop-gap measure.

[nadro]

Oh, and for those of you who can install the kernel from source, Alex Deucher is asking for people to test the solution: https://bugs.freedesktop.org/show_bug.cgi?id=97260#c16

I already sent a response that a solution posted by Alex solve this issue on my Radeon R9 380.

[RavFX]

Good to know that when I found it two month before (https://bugzilla.kernel.org/show_bug.cgi?id=119631), it was Wine fault...

[RavFX]

this performance regression show us one think: we the community need to put more resources to phoronix.com ... the git bisecting would be done weeks ago.

In my point of view phoronix.com is the backbone of linux eco system to solve problems like this.

I did bisect it in june, kernel 4.7-rc1, like less than a week after the benchmark showed the bug. https://bugzilla.kernel.org/show_bug.cgi?id=119631

[RavFX]

My guess is that people don't really look at the kernel bugzilla for radeon bug as most of the stuff append on mesa. My bug just rotted there as a Wine bug (it was kind of) but with the fps loss it was matching the phoronix bench, just that people just did not try to reverse that patch by looking only in mesa bug, my guess. Maybe the solution should be a unified location for all the graphic stack (like mesa and drm in the same bug tracker). that would give more visibility.

Maybe adding a kind of subscription system to phoronix article when they are regression related so if someone think he fould the actual bug he can flag the article and ping interested people for testing.

[agd5f]

Wouldn't call that a solution so much as a stop-gap measure.

It's neither. I just want to see if it the problem is from the change in hw programming sequences or exposing the async flag.

[agd5f]

My guess is that people don't really look at the kernel bugzilla for radeon bug as most of the stuff append on mesa. My bug just rotted there as a Wine bug (it was kind of) but with the fps loss it was matching the phoronix bench, just that people just did not try to reverse that patch by looking only in mesa bug, my guess. Maybe the solution should be a unified location for all the graphic stack (like mesa and drm in the same bug tracker). that would give more visibility.

Wine apparently has an issue as well. It would have been good to know that other apps besides wine were affected at the time. https://bugs.freedesktop.org is a unified bug tracker that covers the kernel graphics drivers, mesa, etc. and was the original bug tracker for DRI bugs. We still look at kernel bugzilla, but it's harder to deal with because bugs in the non-kernel part of the stack are not covered there so if the bug is found to be a mesa or xserver bug, we can't adjust the component.

This may not even be a kernel bug in the end. The kernel just exposes the new functionality. It may turn out to be a bug in the xserver or mesa or ddx that just happens to be exposed when async pageflips are available.