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.
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.
I see, well at least this behavior also occurs when no compositor is running at all, if this information helps in any way.
Could you attach Xorg.log? Just interested to know which combination of drivers to read and mull over.
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.
Created attachment 132099 [details]
Adding tag into "Whiteboard" field - ReadyForDev
*Status is correct
*Platform is included
*Feature is included
*Priority and Severity correctly set
Hello, Chris, Karol, any news on this case?? Thanks.
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.
the issue still exists
ok, thanks for informing. Chris any advice here?
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.
No feedback for more than a month, reducing the priority to medium.
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.