You are right I use vdpau for video playback. I didn't see stutter while scrolling in chrome but as it happen every 5s approximately I think it's hard to see it with scrolling. The stutter is also present in glxgears :

glxgears
Running synchronized to the vertical refresh. The framerate should be
approximately the same as the monitor refresh rate.
123 frames in 5.0 seconds = 24.402 FPS
120 frames in 5.0 seconds = 23.982 FPS
120 frames in 5.0 seconds = 23.979 FPS
120 frames in 5.0 seconds = 23.979 FPS
120 frames in 5.0 seconds = 23.979 FPS
120 frames in 5.0 seconds = 23.978 FPS

happen every 5s approximately

This would mean the output is ~0.2 fps faster than the sync/repaint.

Let's check whether and how you sync.
What are the outputs of

Code: Select all

qdbus org.kde.KWin /KWin supportInformation | grep -iE '(bufferswap|block)'

Code: Select all

grep -i triple /var/log/Xorg.0.log

Code: Select all

tr '\0' '\n' < /proc/`pidof kwin`/environ | grep -i yield

Ok this is what I got

- qdbus org.kde.KWin /KWin supportInformation | grep -iE '(bufferswap|block)'

glPreferBufferSwap: 99
Painting blocks for vertical retrace: no

- grep -i triple /var/log/Xorg.0.log

nothing

- tr '\0' '\n' < /proc/`pidof kwin`/environ | grep -i yield

__GL_YIELD=USLEEP

Ok, what this means:

glPreferBufferSwap: 99
__GL_YIELD=USLEEP

You're syncing to vblank (the mode doesn't actually matter because you've buffer age support) and that's also not downforced (otherwise w/o triple buffering glSwapBuffers would enter a busy wait and burn your CPU)

nothing

Triple buffering is not actually available

Painting blocks for vertical retrace: no

But our heuristic believes it is (unless this value was taken "briefly" after starting the compositor. The system analyzes block times for 500 frames)

If the values are correct (ie. notably triple buffering is misdetected) the frame timer will be wrong (it believes that glSwapBuffers doesn't block, so it doesn't try to "pre-jump" it) and you'll easily lose frames (I assume that is what happens and oc. for 24Hz, you'd loose ~42ms, what is VERY long)

Try to either enable triple buffering or run

Code: Select all

KWIN_TRIPLE_BUFFER=0 kwin --replace &

/etc/X11/xorg.conf.d/20-nvidia.conf

Code: Select all

Section "Device"
    Identifier "Default nvidia Device"
    Driver      "nvidia"
    Option      "NoLogo"                                "True" # no adverts on startup
        Option  "CoolBits"                              "1" # pot. more options in nvidia-settings
        Option  "TripleBuffer"                  "True" # <== that's the important option
EndSection


I enabled triple buffering in xorg.conf but nothing change, still stutter every 1s (instead of 5s like I wrongly said)

Hello luebking,

Have you some other ideas ?

I also noticed that if I use "Block Compositing" when MPV is lauched sometimes the audio is slightly out of sync (behind the video). It never happen when I use "unredirect fullscreen windows".

One jumping frame per second (I assume you'd not recognize a hanging one as stutter) suggests that the video runs at 25Hz (PAL) if the system syncs to 24Hz (what seems to be confirmed by the glxgears output)

I doubt that there's a relation between the compositor *ABSENCE* (even if the unredirection of the window *would* be different towards the client on disabling the compositor) and A/V sync, also the delay would have to be around 200ms to be notable, ie. 4-5 frames.

=> Does the AV delay increase over time?

I made a little video for you to see what happen :
https://www.dropbox.com/s/gq9wh0mde2v5b ... 1.mp4?dl=1

I tried glxgears @24.000hz and no stutter with compositing enabled ! It's only @23.976hz that problem occur.
Maybe there is something wrong in kwin or drivers when we use frequencies with decimals ?

When I use "Block Compositing" and when the AV delay happen it don't increase over time. It seems to be arround 150-250ms.

Do you think it's possible there is something wrong in kwin or drivers when we use frequencies with decimals ?

No.
While the refreshrate is indeed only obtained as integer (and only reported as 24Hz in both cases anyway, see your xrandr output), the relevant number is not the FPS (that's some human stuff) but the delay between two frames in ms, which would be 41.666... for 24Hz and 41.708375041... for 23.976Hz - that delay is undercut by the timer.

So KWin would run rather too "fast" than to slow, what *could* lead to a double frame in the buffer stack (a hanging frame), but only once every 42 seconds!

...unless libxrandr, xvidmode or nvidia-settings report the wrong number (or junk) altogether in the 23.976Hz case and/or we fall back to 60Hz

You could try

Code: Select all

kwriteconfig --file kwinrc --group Compositing --key RefreshRate 24

luebking wrote:You could try

Code: Select all

kwriteconfig --file kwinrc --group Compositing --key RefreshRate 24

That's works. No stutter with compositing @23.976hz in mpv and glxgears.
So what we do next

"great" - that implies that the xvidmode extension reports a wrong refresh rate for the 23.976Hz setup.
Out of curiosity: "which"? (run "kdebugdialog" and ensure 1212 (KWin) is enabled; then run "kwin --replace & | grep -i refresh" from konsole and check the output)

About "what to do":
unfortunately "wait" - we removed the xvidmode refresh query for 5.3 (was originally introduced because nvidia abused the xrandr refresh rate for TwinView configurations, so it always reported nonsense) - KWin 4.x will only see security related fixes.

If you can/will compile kwin yourself, patching is (likely) easy, though.

luebking wrote:"great" - that implies that the xvidmode extension reports a wrong refresh rate for the 23.976Hz setup.
Out of curiosity: "which"? (run "kdebugdialog" and ensure 1212 (KWin) is enabled; then run "kwin --replace & | grep -i refresh" from konsole and check the output)

The command "kwin --replace & | grep -i refresh" don't work but this is the output of "kwin --replace &". There isn't "refresh" entry.

Code: Select all

kwin --replace &
[1] 3505
jeremy@PC-Dl:~$ QDBusConnection: session D-Bus connection created before QCoreApplication. Application may misbehave.
QCoreApplication::sendPostedEvents: Cannot send posted events for objects in another thread
QCoreApplication::sendPostedEvents: Cannot send posted events for objects in another thread
Bus::open: Can not get ibus-daemon's address.
IBusInputContext::createInputContext: no connection to ibus-daemon
QCoreApplication::sendPostedEvents: Cannot send posted events for objects in another thread
QCoreApplication::sendPostedEvents: Cannot send posted events for objects in another thread
OpenGL vendor string:                   NVIDIA Corporation
OpenGL renderer string:                 GeForce GT 430/PCIe/SSE2
OpenGL version string:                  3.1.0 NVIDIA 346.47
OpenGL shading language version string: 1.40 NVIDIA via Cg compiler
Driver:                                 NVIDIA
Driver version:                         346.47
GPU class:                              GF100
OpenGL version:                         3.1
GLSL version:                           1.40
X server version:                       1.15.1
Linux kernel version:                   3.13
Direct rendering:                       yes
Requires strict binding:                no
GLSL shaders:                           yes
Texture NPOT support:                   yes
Virtual Machine:                        no

luebking wrote:About "what to do":
unfortunately "wait" - we removed the xvidmode refresh query for 5.3 (was originally introduced because nvidia abused the xrandr refresh rate for TwinView configurations, so it always reported nonsense) - KWin 4.x will only see security related fixes.

If you can/will compile kwin yourself, patching is (likely) easy, though.

Ok I can wait, "unredirect fullscreen windows" works perfectly in the meantime and I'm glad that this bug will be fixed.
Thank you very much !

paviluf wrote:The command "kwin --replace & | grep -i refresh" don't work

Sorry, my bad - I assume you still have the RefreshRate key in place? Then it's oc. not being detected.
You'll have to edit ~/.kde/share/config/kwinrc by hand to remove it (or fetch the supercool kconfig tool from https://github.com/luebking/KLItools

paviluf wrote:Ok I can wait, "unredirect fullscreen windows" works perfectly in the meantime and I'm glad that this bug will be fixed.

I won't be too optimistic here - chances are, that XRandr may return similar junk.
But since we now know the cause, just file a bug in case =)

The command "kwin --replace & | grep -i refresh" can't work, it says "syntax error". If I remove "RefreshRate" key from kwinrc and I do "kwin --replace &" I don't see any "refresh" value.

I created a bug report https://bugs.kde.org/show_bug.cgi?id=344864 and I hope this will be fixed now we know what's wrong