Threaded Optimizations in 378.13 make "shotcut" stutter with workaround

Graphics / Linux Linux
1

Hello,

I noticed that using the video editor “shotcut” in GPU-accelerated mode with the 378.13 drivers make videos stutter back and forth while playing. Disabling the newly introduced Threaded Optimizations using __GL_THREADED_OPTIMIZATIONS=0 as described in the README makes the hiccups go away. In my case I’m playing back H264 videos. I’m using a fully updated Arch Linux 64-bit with a GTX 1080.

Best regards
Ochi

2

Does force enabling the threaded optimizations (setting the variable to 1) reproduce the problem as well?
Thanks

3

Thank you for your reply. Yes, forcing the optimizations also reproduces the problem.

4

To help us investigate, would you please:

  • confirm that the problem reproduces when forcing enabled the threaded optimizations in r375 or earlier drivers
  • provide detailed instructions on how to observe the problem
    Thanks!
5

Hello,

I was indeed able to reproduce the problem with 375.26 when explicitly forcing the optimizations, so at least the underlying problem is not a regression of version 378.

The way I repro the problem:

  • Get the Linux version of shotcut from shotcut.org (I’m using version 17.02.05).
  • Open shotcut, possibly setting __GL_THREADED_OPTIMIZATIONS=1 in a Terminal.
  • Activate Settings → GPU processing (experimental) in the menus.
  • Restart shotcut.
  • Open some (H264) video in the Source tab, e.g. by dragging the file into the shotcut window.
  • Hit play and watch out for jumps in video playback.

By the way, in addition to my other machine with a 1080, it also happens on a 780 Ti.

Best regards
Ochi

6

I’m not able to reproduce the problem:

  • with shotcut 17.02.19 from Archlinux AUR, I can’t enable GPU processing (“GPU processing not supported”)
  • with shotcot 17.02.05 from shotcut.org, I can enable GPU processing, but when I load a H264 video I can play it without a problem

How often do the jumps happen? Can you maybe grab an Apitrace of the problem? (You’ll want to double check that replaying the trace exposes the problem)

Thanks

7

Also please provide the video clip you are using to reproduce this issue. Please provide nvidia bug report of your system. Can you share video recording of the issue that will us to understand and see stutter/hiccups. What desktop env you are running kde, gnome or else? Is the desktop effects disabled? Is vsync on/off?

8

Hello,

the jumps happen immediately and are very visible. I have created the following files:

Note that even if my main system used here is relatively complex (multiple monitors, ForceCompositionPipeline enabled in xorg.conf), I can reproduce the issue on a simpler system with a single monitor and without ForceCompositionPipeline as well.

I’m using plain openbox without any desktop effects.

EDIT: I noticed that the apitrace replay with enabled optimizations only shows the stuttering if apitrace replay is also run with the optimizations enabled. If run without optimizations, the trace looks fine. The trace with disabled optimizations plays smoothly no matter if I run apitrace replay with or without optimizations.

9

we are tracking this issue under : 200282699

10

Nothing obvious stands out as either a driver or application bug, and more investigation will be needed to find the root cause for the problem.
Have you observed similar problems with other Qt applications, or is the issue specific to shotcut?
Thanks

11

Although it has been some time, I would like to point out that the issue has recently been fixed on the side of shotcut, or more precisely the MLT framework:

https://github.com/mltframework/mlt/commit/c3574674e7d72ef2c81d90fb561bdfcaa5c7101f

Thanks

12

Yes, it was fixed after I reported the bug to MLT’s maintainer.

13

Ah, great, thank you. :)