Bug 101506 - [HSW] desktop gets laggy while prime offloading
Summary: [HSW] desktop gets laggy while prime offloading
Status: RESOLVED WORKSFORME
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Intel GFX Bugs mailing list
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard: ReadyForDev
Keywords:
Depends on:
Blocks:
 
Reported: 2017-06-19 21:41 UTC by Karol Herbst
Modified: 2019-07-15 06:39 UTC (History)
3 users (show)

See Also:
i915 platform: HSW
i915 features: display/Other


Attachments
Xorg config file (289 bytes, text/plain)
2017-06-20 08:53 UTC, Karol Herbst
no flags Details
Xorg log (30.61 KB, text/plain)
2017-06-20 18:32 UTC, Karol Herbst
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Karol Herbst 2017-06-19 21:41:52 UTC
kernel: 4.11.4-gentoo

starting with 4.9 the entire desktop might get super laggy when prime offloading. I think this is because intel starts to sync while prime offloading.

This is best observable while prime offloading pixmark_piano from gputest on nouveau.

Even though the intel GPU doesn't need to do anything (except rendering the desktop and doing prime offloading) the entire desktops "fps" drops below the fps of the prime offloaded application.

this also occurs in a few games, where my Nvidia GPU is able to run games at around 40-50fps, but due this bug the desktop and the game stutter quite a lot and the experience is way worse in the end. This is super annoying and it makes no fun offloading some applications like this.

I once got a patch for i915 to fix this behavior, but I forgot the details.
Comment 1 Chris Wilson 2017-06-19 22:49:18 UTC
The patch I gave you would have skipped the sync on the nouveau fence.

There's something not quite right here. The desktop shouldn't be capped to the throughput on the nouveau device ... unless it too was rendering on the dGPU, or the buffer exchange is not quite right (and we are recycling buffers too early and causing a fence cycle). It would stutter when syncing on new frames from the dGPU, but in between it would use the current content to re-render.

One solution is to only queue the copy from dGPU->iGPU once the dGPU is complete. Present does provide a fence to delay the PresentPixmap which mesa could fill in to tell Present to wait until it has completed the dGPU task. That would probably require handing off to a thread so that it could wait on the dGPU fence before signaling the X fence.

dri2 could be taught a similar trick, but simpler since we can just defer the task inside X until the next vblank.

The complication really is deducing where in the chain of client / X / compositor / X do we need to apply the decoupling, i.e. who do we fix. In the wayland world, it is client / compositor and it is much more obvious about how to organise the compositor to avoid the implicit sync.
Comment 2 Karol Herbst 2017-06-19 22:56:06 UTC
I see, well at least this behavior also occurs when no compositor is running at all, if this information helps in any way.
Comment 3 Chris Wilson 2017-06-20 08:37:24 UTC
Could you attach Xorg.log? Just interested to know which combination of drivers to read and mull over.
Comment 4 Karol Herbst 2017-06-20 08:53:33 UTC
Created attachment 132078 [details]
Xorg config file

(In reply to Chris Wilson from comment #3)
> Could you attach Xorg.log? Just interested to know which combination of
> drivers to read and mull over.

can do this after work (in roughly 8 hours). Currently I use the intel DDX with SNA and DRI3 enabled and dummy for nouveau, so that the nouveau DDX doesn't get loaded at all and I can unload nouveau while X is running.
Comment 5 Karol Herbst 2017-06-20 18:32:11 UTC
Created attachment 132099 [details]
Xorg log
Comment 6 Elizabeth 2017-06-22 14:13:05 UTC
Adding tag into "Whiteboard" field - ReadyForDev
*Status is correct
*Platform is included
*Feature is included
*Priority and Severity correctly set
*Logs included
Comment 7 Elizabeth 2018-01-25 22:43:06 UTC
Hello, Chris, Karol, any news on this case?? Thanks.
Comment 8 Jani Saarinen 2018-03-29 07:10:38 UTC
First of all. Sorry about spam.
This is mass update for our bugs. 

Sorry if you feel this annoying but with this trying to understand if bug still valid or not.
If bug investigation still in progress, please ignore this and I apologize!

If you think this is not anymore valid, please comment to the bug that can be closed.
If you haven't tested with our latest pre-upstream tree(drm-tip), can you do that also to see if issue is valid there still and if you cannot see issue there, please comment to the bug.
Comment 9 Karol Herbst 2018-04-02 22:42:59 UTC
the issue still exists
Comment 10 Jani Saarinen 2018-04-25 06:50:43 UTC
ok, thanks for informing. Chris any advice here?
Comment 11 Lakshmi 2018-09-17 14:13:31 UTC
Reporter, do you still have the issue?
Please try to reproduce the issue using drm-tip (https://cgit.freedesktop.org/drm-tip) and kernel parameters drm.debug=0x1e log_buf_len=4M, and if the problem persists attach the full dmesg from boot.
Comment 12 Lakshmi 2018-10-21 17:51:02 UTC
No feedback for more than a month, reducing the priority to medium.
Comment 13 Lakshmi 2019-07-15 06:39:09 UTC
No feedback from more few months, closing this bug as WORKSFORME.
If this issue happens to occur on drmtip, please attach the dmesg from boot and
reopen the issue.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.