Bug 119631 - RadeonSI get a huge performance dip with used with the nine state tracker
Summary: RadeonSI get a huge performance dip with used with the nine state tracker
Status: NEW
Alias: None
Product: Drivers
Classification: Unclassified
Component: Video(DRI - non Intel) (show other bugs)
Hardware: x86-64 Linux
: P1 normal
Assignee: drivers_video-dri
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-06-04 16:10 UTC by Mathieu Belanger
Modified: 2016-08-16 00:56 UTC (History)
5 users (show)

See Also:
Kernel Version: 4.7-rc1
Subsystem:
Regression: Yes
Bisected commit-id:


Attachments
Xorg log file after running EVE (36.80 KB, text/plain)
2016-06-12 23:27 UTC, Mathieu Belanger
Details
dmesg after running EVE (59.04 KB, text/plain)
2016-06-12 23:28 UTC, Mathieu Belanger
Details

Description Mathieu Belanger 2016-06-04 16:10:02 UTC
Hi,

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.
Comment 1 Vedran Miletić 2016-06-04 21:42:53 UTC
Compared to 4.6? Can you bisect?
Comment 2 Mathieu Belanger 2016-06-05 07:22:01 UTC
Compared to 4.6-rc5
There.

c63dd758589b1f7e8398841d1f443f06ebfbcefc is the first bad commit
commit c63dd758589b1f7e8398841d1f443f06ebfbcefc
Author: Michel Dänzer <michel.daenzer@amd.com>
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 <christian.koenig@amd.com>
    Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

:040000 040000 2f3d8295e7fa2809a3546a23c64da33311e624b9 6cd9fd9b53df0942efab559295e4c11fc6cc0463 M      drivers
Comment 3 Michel Dänzer 2016-06-07 08:56:18 UTC
Please attach the corresponding Xorg log file, preferably captured after running EVE-Online.
Comment 4 Mathieu Belanger 2016-06-12 23:27:06 UTC
Created attachment 219661 [details]
Xorg log file after running EVE
Comment 5 Mathieu Belanger 2016-06-12 23:28:16 UTC
Created attachment 219671 [details]
dmesg after running EVE
Comment 6 Michel Dänzer 2016-06-14 02:45:36 UTC
Does the problem also occur with xserver 1.18.3 or newer?
Comment 7 Mathieu Belanger 2016-06-14 05:12:28 UTC
Yes, I just updated xserver to 1.18.3, bug still present.
Comment 8 Michel Dänzer 2016-06-14 07:45:23 UTC
Does setting the environment variable thread_submit=true for the EVE-Online process avoid the problem?
Comment 9 Mathieu Belanger 2016-06-14 08:41:30 UTC
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
Comment 10 Axel Davy 2016-06-14 19:31:13 UTC
Hi,

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:

https://paste.fedoraproject.org/379178/93261014/
Comment 11 Mathieu Belanger 2016-06-15 00:19:57 UTC
I will test the patch this night.

Isn't thread_submit just to fix rendering on DRI PRIME or something like that?
Comment 12 Axel Davy 2016-06-15 06:39:43 UTC
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.
Comment 13 Mathieu Belanger 2016-06-20 02:42:40 UTC
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.
Comment 14 Michel Dänzer 2016-06-20 03:33:41 UTC
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.
Comment 15 The Linux kernel's regression tracker (Thorsten Leemhuis) 2016-07-02 12:27:52 UTC
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.
Comment 16 Michel Dänzer 2016-07-04 01:50:36 UTC
(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.
Comment 17 John Brooks 2016-08-15 17:47:26 UTC
Looks like it may actually have been a kernel regression. https://bugs.freedesktop.org/show_bug.cgi?id=97260#c12
Comment 18 Michel Dänzer 2016-08-16 00:56:34 UTC
(In reply to John Brooks from comment #17)
> Looks like it may actually have been a kernel regression.
> https://bugs.freedesktop.org/show_bug.cgi?id=97260#c12

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.

Note You need to log in before you can comment on or make changes to this bug.