Bug 119631
| Summary: | RadeonSI get a huge performance dip with used with the nine state tracker | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | Mathieu Belanger (b747xx) |
| Component: | Video(DRI - non Intel) | Assignee: | drivers_video-dri |
| Status: | NEW --- | ||
| Severity: | normal | CC: | devurandom, john, regressions, vebveb, vedran |
| Priority: | P1 | ||
| Hardware: | x86-64 | ||
| OS: | Linux | ||
| Kernel Version: | 4.7-rc1 | Subsystem: | |
| Regression: | Yes | Bisected commit-id: | |
| Attachments: |
Xorg log file after running EVE
dmesg after running EVE |
||
|
Description
Mathieu Belanger
2016-06-04 16:10:02 UTC
Compared to 4.6? Can you bisect? 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 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 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/ 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. > 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. |