I have a Radeon 7970HD and I use the Gallium Nine state tracker to play a specific game (EVE-Online). I did notice that the performance take a big dip when used with the kernel 4.7-next and -rc1. I did know about a regretion affecting some opengl game, that might and might not be related.
Using the kernel 4.7, I lose about 1/3 to 2/3 of the fps depending of the situation.
Compared to 4.6? Can you bisect?
Compared to 4.6-rc5
c63dd758589b1f7e8398841d1f443f06ebfbcefc is the first bad commit
Author: Michel Dänzer <firstname.lastname@example.org>
Date: Fri Apr 1 18:51:34 2016 +0900
drm/radeon: Support DRM_MODE_PAGE_FLIP_ASYNC
When this flag is set, we program the hardware to execute the flip
during horizontal blank (i.e. for the next scanline) instead of during
vertical blank (i.e. for the next frame).
Currently this is only supported on ASICs which have a page flip
completion interrupt (>= R600), and only if the use_pflipirq parameter
has value 2 (the default).
Reviewed-by: Christian König <email@example.com>
Signed-off-by: Michel Dänzer <firstname.lastname@example.org>
Signed-off-by: Alex Deucher <email@example.com>
:040000 040000 2f3d8295e7fa2809a3546a23c64da33311e624b9 6cd9fd9b53df0942efab559295e4c11fc6cc0463 M drivers
Please attach the corresponding Xorg log file, preferably captured after running EVE-Online.
Created attachment 219661 [details]
Xorg log file after running EVE
Created attachment 219671 [details]
dmesg after running EVE
Does the problem also occur with xserver 1.18.3 or newer?
Yes, I just updated xserver to 1.18.3, bug still present.
Does setting the environment variable thread_submit=true for the EVE-Online process avoid the problem?
No,thread_submit=true just remove more fps.
Big drop if I run EVE without DRM_MODE_PAGE_FLIP_ASYNC
Small drop if I run EVE with DRM_MODE_PAGE_FLIP_ASYNC
It looks like to be a bug in gallium nine, wine side. (Though I don't get why thread_submit=true didn't help)
Please try with the following diff:
I will test the patch this night.
Isn't thread_submit just to fix rendering on DRI PRIME or something like that?
thread_submit delays submission of buffers to the X server until the moment the buffer has all rendering finished.
This is useful for DRI PRIME, because the kernel doesn't have yet all the pieces to have the other card wait for the rendering.
I thought perhaps in your case the issue was that the async flip was taking too long because it needed to wait for the rendering to finish, but apparently not.
Tested Axel patch.
It making it better. Instead of loosing about half of the fps, I lose about 10
337 -> 331
175 -> 165
But still have a "small" loss, I don't know if it's normal with DRM_MODE_PAGE_FLIP_ASYNC or no. Note, I did test the patch with DRM_MODE_PAGE_FLIP_ASYNC disabled too and did get the same exact fps than without the patch.
The DRM_MODE_PAGE_FLIP_ASYNC change can't have any effect with Axel's patch, because it explicitly forces the Present operations to be executed as copies instead of flips. The difference you're seeing must therefore be caused by something else.
What's the status of this issue? Just wondering, as this issue is listed
in my regression reports for 4.7 and it seems nothing much happened for
more than a week now – which is a bad sign as the 4.7 release seems only
a week or two away.
(In reply to Thorsten Leemhuis from comment #15)
> What's the status of this issue? Just wondering, as this issue is listed
> in my regression reports for 4.7 [...]
This isn't a kernel regression. It's a Wine/nine issue.
Looks like it may actually have been a kernel regression. https://bugs.freedesktop.org/show_bug.cgi?id=97260#c12
(In reply to John Brooks from comment #17)
> Looks like it may actually have been a kernel regression.
We can't be sure about that until the problem is fully understood / fixed. So far it still seems more likely that the kernel change triggered an existing issue somewhere else.