https://bugs.kde.org/show_bug.cgi?id=489952

Zamundaaa <[email protected]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REPORTED                    |NEEDSINFO
         Resolution|---                         |WAITINGFORINFO

--- Comment #32 from Zamundaaa <[email protected]> ---
(In reply to pallaswept from comment #28)
> I'm seeing an increasing number of people noticing this bug lately (lots of
> mentions on reddit/forums/discord/etc), resulting in a lot of random guesses
> from random people, some of them with damaging consequences. I saw a guy's
> root partition need rebuilding after trying the NO_AMS variable on an nvidia
> card crashed his machine.
Nothing needed rebuilding... Afaik NVidia doesn't support legacy modesetting
properly, so they would've needed to unset this variable from a tty.
If you don't know how to do that, then indeed please do not mess with anything.

> What is this safety margin? What is the effect of decreasing it?
> 
> The source says:
>     // the 1.5ms on top of that was chosen experimentally, for the time it
> takes to commit + scheduling inaccuracies 
> 
> Which implies that, in order to commit earlier and not run late, this number
> should *larger*, but you said to set it smaller?
It changes how long before a given refresh cycle KWin needs to commit the next
frame. And you should indeed increase it, reducing it won't help. Try values up
to like 5000µs, more than that may cause additional stutter rather than prevent
it.

It seems that everyone affected is on NVidia. Do I assume correctly that all of
you are using the proprietary driver (rather than the open kernel modules or
Nouveau)?
If so, the proprietary NVidia driver doesn't provide pageflip timestamps, so
regular frame drops are to be expected. Increasing the safety margin *might*
help work around the issue, but ultimately it's impossible to do things right
without reliable timing information.
If your hardware is supported, try the open kernel modules, they should be
providing proper timestamps.

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to