[kwin] [Bug 489952] Inconsistent frame timing of cursor on desktop and some apps
https://bugs.kde.org/show_bug.cgi?id=489952 --- Comment #45 from pallaswept --- Oh hey, I didn't expect that client to work under kwin, very nice! I guess you already know this but it runs just great: 924: f2c 3 ms, c2p 31 ms, f2p 34 ms, p2p 16668 us, t2p 30795, [sce_], seq 0 925: f2c 2 ms, c2p 31 ms, f2p 33 ms, p2p 1 us, t2p 30913, [sce_], seq 0 926: f2c 2 ms, c2p 31 ms, f2p 33 ms, p2p 1 us, t2p 30849, [sce_], seq 0 927: f2c 3 ms, c2p 31 ms, f2p 34 ms, p2p 16668 us, t2p 30911, [sce_], seq 0 928: f2c 2 ms, c2p 31 ms, f2p 33 ms, p2p 16665 us, t2p 30940, [sce_], seq 0 929: f2c 2 ms, c2p 31 ms, f2p 33 ms, p2p 16668 us, t2p 30959, [sce_], seq 0 930: f2c 3 ms, c2p 31 ms, f2p 34 ms, p2p 16665 us, t2p 30892, [sce_], seq 0 931: f2c 2 ms, c2p 31 ms, f2p 33 ms, p2p 16668 us, t2p 30947, [sce_], seq 0 932: f2c 2 ms, c2p 31 ms, f2p 33 ms, p2p 1 us, t2p 30910, [sce_], seq 0 933: f2c 3 ms, c2p 31 ms, f2p 34 ms, p2p 16667 us, t2p 30919, [sce_], seq 0 934: f2c 2 ms, c2p 31 ms, f2p 33 ms, p2p 16667 us, t2p 30837, [sce_], seq 0 935: f2c 2 ms, c2p 31 ms, f2p 33 ms, p2p 1 us, t2p 30953, [sce_], seq 0 936: f2c 3 ms, c2p 31 ms, f2p 34 ms, p2p 16668 us, t2p 30882, [sce_], seq 0 937: f2c 2 ms, c2p 31 ms, f2p 33 ms, p2p 16665 us, t2p 30824, [sce_], seq 0 938: f2c 2 ms, c2p 31 ms, f2p 33 ms, p2p 16668 us, t2p 30910, [sce_], seq 0 939: f2c 3 ms, c2p 31 ms, f2p 34 ms, p2p 16667 us, t2p 30949, [sce_], seq 0 Thanks again! -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 489952] Inconsistent frame timing of cursor on desktop and some apps
https://bugs.kde.org/show_bug.cgi?id=489952 --- Comment #44 from pallaswept --- (In reply to Zamundaaa from comment #43) > Some jitter is normal - while I also didn't expect it at first, the duration > of each refresh cycle doesn't seem to be perfectly stable. We have code in > KWin to deal with that, and re-schedule frames when a new timestamp comes in. > > For vkcube, do keep in mind that afaik it does not use presentation time to > get the actual presentation timestamps from the compositor. > What you want to use for testing this is weston-presentation-shm. It should > show a p2p that's stable down to a few microseconds. On Nvidia, it might not > be as stable as that, but it should definitely not fluctuate by multiple > milliseconds. Thanks mate very helpful info! I took a bit of a deepdive on this and was starting to feel like it wasn't even possible, and then saw news of VK_EXT_present_timing and realised that it wasn't just me who was trying to solve this problem :D I'm sure glad there are better devs working on it than me! Kwin has been behaving very well in the meantime, so thanks again! -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 489952] Inconsistent frame timing of cursor on desktop and some apps
https://bugs.kde.org/show_bug.cgi?id=489952 Zamundaaa changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #43 from Zamundaaa --- Some jitter is normal - while I also didn't expect it at first, the duration of each refresh cycle doesn't seem to be perfectly stable. We have code in KWin to deal with that, and re-schedule frames when a new timestamp comes in. For vkcube, do keep in mind that afaik it does not use presentation time to get the actual presentation timestamps from the compositor. What you want to use for testing this is weston-presentation-shm. It should show a p2p that's stable down to a few microseconds. On Nvidia, it might not be as stable as that, but it should definitely not fluctuate by multiple milliseconds. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 489952] Inconsistent frame timing of cursor on desktop and some apps
https://bugs.kde.org/show_bug.cgi?id=489952 [email protected] changed: What|Removed |Added CC||[email protected] -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 489952] Inconsistent frame timing of cursor on desktop and some apps
https://bugs.kde.org/show_bug.cgi?id=489952 --- Comment #42 from pallaswept --- Zamundaa, I would like to mark this issue resolved, because my eyes tell me that it is... But there's a problem. I can't show it objectively. Turns out, according to any measurement I take, my machine won't hold 60FPS, and it turns out nobodies will. I'd venture to guess that even yours won't, because I've seen zero pass this test: MANGOHUD_CONFIG="fps_metrics='0.99+0.01+0.001'" mangohud vkcube --present_mode 2 Nobody gets a 0.1 or 1% frametime that matches their average FPS and refresh rate. It's the same for the ftrace markers from kwin, and the drm_vblank_delivered events traced from the kernel. There's significant (several milliseconds) jitter on the delivery timestamps (can't see the actual vblank timestamps on nvidia) and I've checked the interrupt routines are not lagging (they're <10us to userspace on average, ~200us worst case under load over time) I can't make any sense of it. Every measurement says we are dropping frames, everyone agrees they don't see it. I've had people test it on AMD, over 5 different distros, X11, Wayland and XWayland, dual and single screens, opengl, vulkan, various apps each... nothing, not a single one of maybe 30+ PCs can hold a framerate matching refresh rate. They all fail the same way, hovering around it, alternating in exceeding and undercutting the required frametime. It seems like a measurement error so maybe I could blame mangohud, but gpuvis, trace-cmd report, nsight systems, all agree with it. Should I be taking this to kernel.org? I figure it can't be mesa if it's happening to nvidia, can't be nvidia if it's happening to amd cards, can't be kwin if it happens on icewm for example. Kernel seems the only commonality. That, and the tools doing the measurement. Am I measuring wrong? -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 489952] Inconsistent frame timing of cursor on desktop and some apps
https://bugs.kde.org/show_bug.cgi?id=489952 --- Comment #41 from pallaswept --- This is definitely vastly better, but there are still frame pacing problems. vblank intervals (in gpuvis/trace-cmd reports) are perfect within single-digit microseconds, if I run an app without vsync, and let it spin... but the same app will show constant variation in frametimes if it's vsynced, and the vblank intervals are averaging out to (I think *exactly*, it's real close!) 10us too long every time. It's definitely always too long by some amount. If the app's framerate is limited below the refresh rate, it never drops a beat. It's the same with triple buffering enabled/disabled, but mailbox doesnt seem effected. I thought that was interesting because as far as I understand it's still synced to vblank (which fails for fifo mode) , but single-buffered like immediate is (which works). I think I might be looking at a different issue and closing this one but I'm not sure yet. While I've been tracing, I'm pretty sure I caught this bug report in action: https://old.reddit.com/r/kde/comments/1og5l4c/is_kde_to_blame_for_this_weird_issue_where/ It's reported there as alt-tabbing and a permanent FPS boost, but in an isolated environment from the game (vkcube, glxgears) there are timing problems when any app starts, and then they disappear for up to a minute or two when it is minimized then raised again. It really threw a spanner in the works of my testing because everything fails until I minimize it, and then it's only reliable for a while, during which the frametimes are a flat line, and afterwards, it goes back to being all wobbly resulting from the long frames as described above. I've also come across a mangohud bug which is diverting my time from this as it's blocking my tests, (and might even be contributing to problems, unknown) but I will get it done soon. BTW, mangohud recently got an ftrace plot feature, which will be super handy for jobs like this for quick visualisation. The setup it needs is the same as gpuvis (trace-cmd-foo.sh scripts) and then in mangohud's config we just need to change the filter for nvidia eg add 'delivered': ftrace=histogram/drm_vblank_event_delivered -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 489952] Inconsistent frame timing of cursor on desktop and some apps
https://bugs.kde.org/show_bug.cgi?id=489952 --- Comment #40 from pallaswept --- Not sure if relevant but, everything I've reported so far and will in this post, also applies with `export KWIN_USE_OVERLAYS=1` in my kwin_env.sh. So that seems to be working. I'll just leave it on because I know its Windows equivalent MPO is very helpful I figure it's gonna be nice here, too. Also I'm a good guinea pig :D HAH! I put VRR on 'always' which has always slammed the GPU into P0... works! P8. VRR is actually really working, too - if I trace it with it set to adaptive, I see the sync events roll in at a constant rate (it's not the correct rate, that's a long story...anyway, point is the rate is consistently around the same number, and it's close to what it should be) but when I set it to always, the vsync events are varying by several milliseconds, and generally inconsistently timed, I guess depending on what I did with the mouse. Phwoar it even displays 24FPS video without being a disgusting stuttering trainwreck. It's never been able to do that on linux, any distro, any DE, X11 or wayland. What magic have you done to it Zamundaa it's SO much better!! -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 489952] Inconsistent frame timing of cursor on desktop and some apps
https://bugs.kde.org/show_bug.cgi?id=489952 --- Comment #39 from pallaswept --- Is this expected to be fixed in 6.5, because I don't wanna jinx us but it kinda looks like it is :D Traces are entirely different now, and I can't replicate the 'dropped frames' of the cursor any more. Something is definitely very different. The traces taken as before with the gpuvis scripts, show that all of the vblank events are delivered by nvidia-modeset, and they're all (very nearly, at least, within 100ths of a millisecond) on-time, and they are there for both monitors, simultaneously, and it doesn't seem to matter if they mouse is on the display or not. It's just totally different. This change seems not only to have effected the mouse but I'm also seeing things like the vsynctester.com or testufo.com websites are behaving differently. It's not perfect, but it's close, it's the closest I've ever seen it, by a long shot. I'm going to play with this a bit more before I start throwing my hat in the air but I'd love to hear if this is something that I should consider is really fixed. I think you've done it zamundaaa! -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 489952] Inconsistent frame timing of cursor on desktop and some apps
https://bugs.kde.org/show_bug.cgi?id=489952 --- Comment #38 from pallaswept --- Created attachment 184179 --> https://bugs.kde.org/attachment.cgi?id=184179&action=edit GPUVis trace at the moment the issue occurs -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 489952] Inconsistent frame timing of cursor on desktop and some apps
https://bugs.kde.org/show_bug.cgi?id=489952 pallaswept changed: What|Removed |Added Status|NEEDSINFO |CONFIRMED Resolution|WAITINGFORINFO |--- Ever confirmed|0 |1 --- Comment #37 from pallaswept --- Tracing this was really interesting this time. I found a perfect demo. Moving the mouse over the desktop 'drops frames' (quotes because I have no idea what to really call this) Moving the mouse over konsole is the same Moving the mouse over firefox the mouse looks normal As discussed above, my firefox profile animates the browser for a few seconds, which keeps the cursor happy. So I made konsole transparent, so I could do the traces with firefox in the background still rendered through the konsole window. I started the trace, alt-tabbed to firefox to kick off the animation timers, alt-tabbed back to konsole so firefox would time out, do it's animation, and then stop. Meanwhile I just moved the mouse in figure-8s over konsole. After the timers end, the animation runs, they end and the cursor goes bad, I let it run a couple seconds and stop the trace. This way there's a clean 'cut' between 'working, because firefox is doing stuff' to 'busted because firefox stopped doing stuff', but nothing else has changed, there was no switching active app or anything like that, just me, movin the mouse in 8's over the same window. Attached is an image of that moment in GPUview. I have filtered for the vblank events. This is a 60Hz HDMI TV, so they should be 16.667ms apart. While firefox is animating, this is the case. The moment that firefox stops animating and goes idle, the cursor goes bad, and the vblank events are now 14.4ms apart and growing. Occasionally, the vblank events are handled differently (by nvidia-modeset, as it was when firefox was animating, rather than this thread named after the device (what is that?)) and those arrive on time (even rounding for the error of the previous frame) . I see about 6 per second here, which seems about right? for how many 'dropped frames' we see in the cursor. Once one of those events is correctly spaced at ~16.66ms, nvidia-modeset stops handling the vblanks again and it switches back to the monitor-thread-thing, drifts a while, until nvidia-modeset tries again. zamundaaa, does this mean anything to you? It seems to me as though there are two processes which can handle those vblank events and one of them has this timing problem and occasionally the modeset driver kicks in to try and correct it? I've see late vblank events a bunch but this is... different :D -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 489952] Inconsistent frame timing of cursor on desktop and some apps
https://bugs.kde.org/show_bug.cgi?id=489952 --- Comment #36 from S. Christian Collins --- Following up on my previous comment, it appears at the default safety margin of 1500 that cursor frames are being dropped, but at 5000 that some frames are out of place. Perhaps it's just two different symptoms of the same problem, and I have to admit I don't really understand the mechanisms at play here. Anyway, on my secondary monitor (75 Hz refresh), setting the safety margin to 5000 doesn't really make things seem or feel better, just different. At 1500 safety margin, it seems to be a combination of equidistantly-spaced frames with gaps, whereas at 5000 safety margin, the frame spacing seems to be all over the place, which almost feels worse. Either way, increasing the safety margin up to 5000 doesn't solve the problem, but might improve it depending on your monitor's refresh rate. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 489952] Inconsistent frame timing of cursor on desktop and some apps
https://bugs.kde.org/show_bug.cgi?id=489952 --- Comment #35 from S. Christian Collins --- Created attachment 184082 --> https://bugs.kde.org/attachment.cgi?id=184082&action=edit image illustrating uneven cursor trail I have experimented with setting the KWIN_DRM_OVERRIDE_SAFETY_MARGIN environment variable between 2000 and 5000, and here is what I've found on my 144 Hz display: * 2000: maybe slightly better * 3000: improved timing, but not yet perfect * 4000: still not perfect * 5000: almost perfect, but still some frames out of place With KWIN_DRM_OVERRIDE_SAFETY_MARGIN=5000, I was able to get a better glimpse at what is actually happening. It's not that cursor frames are being dropped, but rather the mouse movement is occasionally being "snapshotted" too early or too late. The attached image illustrates what I am seeing when moving the cursor horizontally for 8 frames. In this example, all 8 frames are present, but not all of them are spaced equidistantly as they should be. Lastly, I have discovered another scenario where the cursor moves perfectly smoothly: 1. Right click on a program in the task manager (I am using the Icons-and-Text Task Manager, if that matters). 2. Move the cursor within the region of the menu that pops up. Result: the cursor movement is perfectly smooth. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 489952] Inconsistent frame timing of cursor on desktop and some apps
https://bugs.kde.org/show_bug.cgi?id=489952 --- Comment #34 from S. Christian Collins --- (In reply to Zamundaaa from comment #32) > 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)? I am using Fedora, which installs the NVIDIA open kernel module as default from RPM Fusion. When I switch to Nouveau, this cursor bug does not happen. However, I'm not sure if Nouveau is using hardware cursor, as it feels slightly latent compared to the NVIDIA driver. As others have found, I also see that cursor movement is perfectly smooth over the Firefox web browser and when dragging a window (neither the cursor nor the dragged window appear to be dropping any frames). Interestingly, the cursor movement in GIMP (Flatpak) is perfectly smooth if the cursor is *not* the default pointer. So, if you have a tool selected (rectangle select, etc.), the corresponding custom cursor when moved over the editing area is perfectly smooth with no dropped frames. When you leave the editing area and the cursor returns to the default pointer, it drops frames again. This isn't true for every app with custom cursors, however. In REAPER, all of the custom cursors still drop frames when moved. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 489952] Inconsistent frame timing of cursor on desktop and some apps
https://bugs.kde.org/show_bug.cgi?id=489952 --- Comment #33 from pallaswept --- (In reply to Zamundaaa from comment #32) > Nothing needed rebuilding... The machine froze and the forced shutdown caused disk corruption :( We got it back no problem :) Totally pilot error, not a KDE problem, but I was just trying to demonstrate that tinkering with settings might not be a good idea if we don't understand what they're doing. so: > > What is this safety margin? What is the effect of decreasing it? > 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. Thanks for clarifying! :) No luck with that one I'm afraid, it was worth a shot! > 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)? I tried the closed module, and also tried it with the firmware disabled, but it didn't have any bearing on this. I'm on the open module aside from that testing but I can switch if you want some testing done. I expect to get a little free time over the weekend and I'm very curious to see how those timing plots look with this new vblank parameter because it's visibly very different. Maybe it'll give us a hint. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 489952] Inconsistent frame timing of cursor on desktop and some apps
https://bugs.kde.org/show_bug.cgi?id=489952 Zamundaaa changed: What|Removed |Added Status|REPORTED|NEEDSINFO Resolution|--- |WAITINGFORINFO --- Comment #32 from Zamundaaa --- (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.
[kwin] [Bug 489952] Inconsistent frame timing of cursor on desktop and some apps
https://bugs.kde.org/show_bug.cgi?id=489952 --- Comment #31 from pallaswept --- (In reply to S. Christian Collins from comment #30) > I should also mention that these tests are most reliably performed using a > high polling rate wired mouse, as many cheaper and especially bluetooth mice > will exhibit frame issues of their own. Testing this bug was the thing that made me realise that an 8K mouse doesn't seem to make any difference on KDE ;) You may like to check out the conversation above if you want to get into the weeds on testing this: https://bugs.kde.org/show_bug.cgi?id=489952#c9 TL;DR yes the hardware cursor plane is involved, but also, there seems to be an underlying frame timing problem. This is definitely impacted by the nvidia driver. Newer versions of the driver have changed the behaviour on a few occasions, and a recent example is the new NVreg_RegistryDwords=RmEnableAggressiveVblank=1 parameter in the 580 drivers. It's even worse with that on. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 489952] Inconsistent frame timing of cursor on desktop and some apps
https://bugs.kde.org/show_bug.cgi?id=489952 --- Comment #30 from S. Christian Collins --- I should also mention that these tests are most reliably performed using a high polling rate wired mouse, as many cheaper and especially bluetooth mice will exhibit frame issues of their own. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 489952] Inconsistent frame timing of cursor on desktop and some apps
https://bugs.kde.org/show_bug.cgi?id=489952 S. Christian Collins changed: What|Removed |Added CC||[email protected] --- Comment #29 from S. Christian Collins --- Just adding my own observations as I am also experiencing this bug. The bug seems to be related to the use of hardware cursor. The NVIDIA proprietary drivers use hardware cursor, but Nouveau does not, as far as I can tell. How do I know? I don't, but the cursor under Nouveau—though it never drops frames—feels a bit more latent at low refresh rates compared to the proprietary NVIDIA driver. I know "feel" isn't a reliable metric, but I swear by it in this case. Hardware cursor is preferred vs. software as it is lower latency and more immediately correspondent to the movement of the mouse. Under kwin, I have also been able to determine that no cursor frames are dropped when dragging a window, though this is a bit harder to see with the naked eye vs. moving the cursor over a stationary background. My system: * OS: Fedora Linux Plasma Desktop Edition 42 (Plasma Desktop 6.4.4, KDE Frameworks 6.17.0, Qt 6.9.1) * Linux Kernel: 6.15.9-201.fc42.x86_64 (64-bit) * Video: EVGA NVIDIA GeForce RTX 2080 SUPER w/ 8GB RAM * NVIDIA video driver: 575.64.05 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 489952] Inconsistent frame timing of cursor on desktop and some apps
https://bugs.kde.org/show_bug.cgi?id=489952 --- Comment #28 from pallaswept --- (In reply to thesword from comment #27) > Maybe setting `KWIN_DRM_OVERRIDE_SAFETY_MARGIN` environment variable to a > lower value might help especially on a high refresh rate monitor. It's set > to 1500 by default. 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. Playing with a setting called 'override safety margin' is obviously inherently unsafe, so I would like to know more about this before I change it, since I'm definitely gonna be all alone trying to fix it if something goes wrong and I can't get online. 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? Also, the documentation for this variable says: The issue usually manifests in only getting half the refresh rate of what you set the screen to. But that doesn't quite match our symptoms so doesn't fill me with confidence that I'm even trying the right thing. You're the kwin dev not me, so obviously I'm missing something here, but I'd just like to know what I'm doing before I do it, would you mind filling in some of the blanks for me? -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 489952] Inconsistent frame timing of cursor on desktop and some apps
https://bugs.kde.org/show_bug.cgi?id=489952 thesword changed: What|Removed |Added CC||[email protected] --- Comment #27 from thesword --- Maybe setting `KWIN_DRM_OVERRIDE_SAFETY_MARGIN` environment variable to a lower value might help especially on a high refresh rate monitor. It's set to 1500 by default. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 489952] Inconsistent frame timing of cursor on desktop and some apps
https://bugs.kde.org/show_bug.cgi?id=489952 Random Jerk changed: What|Removed |Added CC||[email protected] --- Comment #26 from Random Jerk --- I also see this issue on my machine running KDE 6.4.2 on Wayland on CachyOS. Observed it both on 6800XT and 9070. Below are the details of my machine. Operating System: CachyOS Linux KDE Plasma Version: 6.4.2 KDE Frameworks Version: 6.15.0 Qt Version: 6.9.1 Kernel Version: 6.15.4-4-cachyos (64-bit) Graphics Platform: Wayland Processors: 32 × AMD Ryzen 9 5950X 16-Core Processor Memory: 64 GiB of RAM (62.7 GiB usable) Graphics Processor: AMD Radeon RX 9070 Manufacturer: Gigabyte Technology Co., Ltd. Product Name: X570 AORUS PRO WIFI System Version: -CF -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 489952] Inconsistent frame timing of cursor on desktop and some apps
https://bugs.kde.org/show_bug.cgi?id=489952 TraceyC changed: What|Removed |Added Status|NEEDSINFO |REPORTED Resolution|WAITINGFORINFO |--- -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 489952] Inconsistent frame timing of cursor on desktop and some apps
https://bugs.kde.org/show_bug.cgi?id=489952 --- Comment #25 from pallaswept --- (In reply to Zamundaaa from comment #24) > Can you still reproduce this issue in Plasma 6.3? I'm afraid so. Thanks for checking. I saw a few of your timing changes, some I even got excited enough to cherry pick and package them for myself... No luck, yet. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 489952] Inconsistent frame timing of cursor on desktop and some apps
https://bugs.kde.org/show_bug.cgi?id=489952 Zamundaaa changed: What|Removed |Added Resolution|--- |WAITINGFORINFO Status|REPORTED|NEEDSINFO --- Comment #24 from Zamundaaa --- Can you still reproduce this issue in Plasma 6.3? There have been some potentially related fixes since 6.1 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 489952] Inconsistent frame timing of cursor on desktop and some apps
https://bugs.kde.org/show_bug.cgi?id=489952 TraceyC changed: What|Removed |Added CC||[email protected] -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 489952] Inconsistent frame timing of cursor on desktop and some apps
https://bugs.kde.org/show_bug.cgi?id=489952 --- Comment #23 from pallaswept --- (In reply to pallaswept from comment #22) > That appears to stop this glitch, too. For testing consistency I also tried > this with firefox, just resized it to smallest, and left it in the corner. > Like this, the whole desktop around it, is fine. This conflicted with my original report, and it bothered me, so I tested more. Background: part of my firefox theme is a CSS transition with a 12 second duration. It sits there doing nothing for 10s, then animates for 2s. This 'timer' begins when my mouse leaves the ff window. When I position the ff window on the desktop, resize it to smallest and put it in the corner, move my mouse back-and-forth over the desktop around it... The mouse animation is smooth - as per my reply from today. But only for those 12 seconds. After the CSS animation (10s no visual change at all, but it is "animating"+2s visually changes) is complete, the mouse begins to stutter again - as per my original report. So, that's the reason for the conflicting reports. It depends not only on the app being on the same display, but also it actually drawing stuff (even if that 'stuff' is nothing, apparently). Hopefully this distinction is useful. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 489952] Inconsistent frame timing of cursor on desktop and some apps
https://bugs.kde.org/show_bug.cgi?id=489952 --- Comment #22 from pallaswept --- (In reply to Zamundaaa from comment #21) > for now you could get a more accurate reading by leaving glxgears running on > the screens while doing the testing. That appears to stop this glitch, too. For testing consistency I also tried this with firefox, just resized it to smallest, and left it in the corner. Like this, the whole desktop around it, is fine. > If you set the environment variable KWIN_FORCE_SW_CURSOR=1 for KWin, does the > issue go away permanently? Yes. Ooh, smoth :) -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 489952] Inconsistent frame timing of cursor on desktop and some apps
https://bugs.kde.org/show_bug.cgi?id=489952 --- Comment #21 from Zamundaaa --- (In reply to pallaswept from comment #14) > Hmm, I'm not so sure that's the same issue I'm seeing - In this timeframe on > the 120Hz monitor I would have had in the region of hundreds of frames where > it should have drawn the cursor but didn't. If I draw a circle on my desktop > I see several, maybe 10 breaks in that single circle of cursors, and in > these logs I draw many dozens of circles. It's expected that the tool won't capture all dropped cursor updates - it only records data for frames where something except the cursor has changed. So if you move the cursor in a circle and the window below it didn't update, it won't log anything in that duration. That should get fixed with some near-ish future changes in KWin, but for now you could get a more accurate reading by leaving glxgears running on the screens while doing the testing. > Sorry, I forgot about the 'shake cursor' effect. If I draw these test circles > too fast, that kicks in, and that also makes the frame timing smooth. That's an important piece of information... the effect forces a software cursor. If you set the environment variable KWIN_FORCE_SW_CURSOR=1 for KWin, does the issue go away permanently? -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 489952] Inconsistent frame timing of cursor on desktop and some apps
https://bugs.kde.org/show_bug.cgi?id=489952 --- Comment #20 from pallaswept --- (In reply to pallaswept from comment #14) > The immediately most interesting thing about this is that yes, that's a 0 > byte file, for the desktop (no firefox) scenario, on the 120Hz monitor (my > secondary). I tried to record this with spectacle today. It recorded no frames until I accidentally got too close to the screen edge, recorded a few frames where the edge highlight animated, and no others afterward. The resulting mp4 file is effectively broken as a result, you can't seek, etc. Let me know if you'd like me to attach it, perhaps a closer analysis might pull something useful from it, but visually, it's just a black rectangle with a mostly-stationary cursor on it. These results seem related, so I thought I should mention it. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 489952] Inconsistent frame timing of cursor on desktop and some apps
https://bugs.kde.org/show_bug.cgi?id=489952 --- Comment #19 from pallaswept --- (In reply to pallaswept from comment #14) > only thing that seems to have any effect is what the cursor is being drawn > above. Sorry, I forgot about the 'shake cursor' effect. If I draw these test circles too fast, that kicks in, and that also makes the frame timing smooth. I did do that briefly by accident in the first test (desktop 60Hz) and thought that I should mention it. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 489952] Inconsistent frame timing of cursor on desktop and some apps
https://bugs.kde.org/show_bug.cgi?id=489952 --- Comment #18 from pallaswept --- Created attachment 172332 --> https://bugs.kde.org/attachment.cgi?id=172332&action=edit firefox 120Hz -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 489952] Inconsistent frame timing of cursor on desktop and some apps
https://bugs.kde.org/show_bug.cgi?id=489952 --- Comment #17 from pallaswept --- Created attachment 172331 --> https://bugs.kde.org/attachment.cgi?id=172331&action=edit firefox 60Hz -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 489952] Inconsistent frame timing of cursor on desktop and some apps
https://bugs.kde.org/show_bug.cgi?id=489952 --- Comment #16 from pallaswept --- Created attachment 172330 --> https://bugs.kde.org/attachment.cgi?id=172330&action=edit desktop 120Hz -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 489952] Inconsistent frame timing of cursor on desktop and some apps
https://bugs.kde.org/show_bug.cgi?id=489952 --- Comment #15 from pallaswept --- Created attachment 172329 --> https://bugs.kde.org/attachment.cgi?id=172329&action=edit desktop 60hz -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 489952] Inconsistent frame timing of cursor on desktop and some apps
https://bugs.kde.org/show_bug.cgi?id=489952 --- Comment #14 from pallaswept --- (In reply to Zamundaaa from comment #13) > Okay, there's 58 frames dropped because of late atomic commits in the log of > the 60Hz monitor (vs. only 10 on the 120Hz one), which would also affect the > cursor. I think the fix for bug 490358 should help here too. Hmm, I'm not so sure that's the same issue I'm seeing - In this timeframe on the 120Hz monitor I would have had in the region of hundreds of frames where it should have drawn the cursor but didn't. If I draw a circle on my desktop I see several, maybe 10 breaks in that single circle of cursors, and in these logs I draw many dozens of circles. That bug is also reported as being worse under CPU load, whereas mine is not. There's no effect by any CPU load I've been able to generate with stress-ng or everyday apps, and I have no gradient of good-to-bad effect with mine, there's no better/worse, it's either doing it, or it isn't. The only thing that seems to have any effect is what the cursor is being drawn above. I also wonder about this, on my 5900X+3090 system, this rig is getting old but it's still pretty fast. I haven't read into your patch, but f you had to slow down kwin for this system, I'd say there might be something else wrong. I attempted to better capture the two behaviours in my logs. Attached are four files - one for each monitor, and one for each of two scenarios. The first scenario, I reboot, open the launcher, draw 20 circles on the desktop on the 60Hz hdmi monitor, then 20 circles on the 120Hz DP monitor. The second scenario is the same, but I open firefox before drawing the circles, and maximise it to the display I'm drawing on, so I'm drawing circles over firefox rather than over the desktop. The immediately most interesting thing about this is that yes, that's a 0 byte file, for the desktop (no firefox) scenario, on the 120Hz monitor (my secondary). I'm not sure if that's a sign that this logging can't capture this fault, or if it's a hint as to why this fault is seen? Hope this is helpful. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 489952] Inconsistent frame timing of cursor on desktop and some apps
https://bugs.kde.org/show_bug.cgi?id=489952 --- Comment #13 from Zamundaaa --- Okay, there's 58 frames dropped because of late atomic commits in the log of the 60Hz monitor (vs. only 10 on the 120Hz one), which would also affect the cursor. I think the fix for bug 490358 should help here too. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 489952] Inconsistent frame timing of cursor on desktop and some apps
https://bugs.kde.org/show_bug.cgi?id=489952 --- Comment #12 from pallaswept --- Created attachment 172319 --> https://bugs.kde.org/attachment.cgi?id=172319&action=edit kwin log 120Hz display -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 489952] Inconsistent frame timing of cursor on desktop and some apps
https://bugs.kde.org/show_bug.cgi?id=489952 --- Comment #11 from pallaswept --- Created attachment 172318 --> https://bugs.kde.org/attachment.cgi?id=172318&action=edit kwin log 60Hz display (In reply to Zamundaaa from comment #10) > Just set it for KWin, and it should put some csv files with performance > logging in your home directory, which we can analyze Attached. I collected just a few minutes usage, first with the mouse over the desktop or apps which don't 'fix' this, and at the end, I spent a good chunk of time on the 120Hz monitor with the mouse over firefox as a comparison. Let me know if I could run more specific tests. I thought maybe I could collect traces simultaneously to illustrate the difference. I honestly can't tell one from the other, in these logs. Kwin runs like a clock (literally never drops so much as a nanosecond, wow, nice work). -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 489952] Inconsistent frame timing of cursor on desktop and some apps
https://bugs.kde.org/show_bug.cgi?id=489952 --- Comment #10 from Zamundaaa --- Yeah, that's very weird. We have an environment variable to debug performance issues in general, though I'm not sure if it'll help here, it's worth a shot: https://invent.kde.org/plasma/kwin/-/wikis/Environment-Variables#kwin_log_performance_data Just set it for KWin, and it should put some csv files with performance logging in your home directory, which we can analyze -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 489952] Inconsistent frame timing of cursor on desktop and some apps
https://bugs.kde.org/show_bug.cgi?id=489952 --- Comment #9 from pallaswept --- In addition to the observation above, I just captured a trace which had the mouse moving in circles over the desktop, and then over firefox (about:blank). When the mouse was over firefox, I see the drm_vblank_event_delivered1 events in the row for nvidia-modeset. Those are all correctly timed, at 8.3ms apart. Then, I minimise that app, and while the mouse is over the desktop, the blank events appear in the DP-1 row. These are all incorrectly timed, at ~6.4ms. Weird? -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 489952] Inconsistent frame timing of cursor on desktop and some apps
https://bugs.kde.org/show_bug.cgi?id=489952 --- Comment #8 from pallaswept --- (In reply to David Edmundson from comment #7) > gpuvis: https://github.com/mikesart/gpuvis Cheers! I had seen this one, but wasn't sure it applied to either KDE or the nvidia card. Do you know any magic for tracing nvidia events? I gather it's not possible, but thought I should ask. > but it's still quite overwhelming . You're not wrong about that :) I'll try to get something useful soon. At a first glance - keeping in mind I'm a noob at this on linux - I think I may see a problem. I can clearly see by the plot, which monitor my mouse was on, by the drm_vblank_event_deliveredN events on the corresponding monitor's row. I can only assume by the name, these events should be spaced according to the monitor's refresh rate; 16.67ms@60Hz/8.3ms@120Hz, for my two monitors. But what I'm seeing is that every one of these events is spaced shorter than the maximum refresh rate of the monitor - it's at 14.5ms and 6.4ms. Is it just me or is that weird? -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 489952] Inconsistent frame timing of cursor on desktop and some apps
https://bugs.kde.org/show_bug.cgi?id=489952 --- Comment #7 from David Edmundson --- gpuvis: https://github.com/mikesart/gpuvis we have some docs at: https://invent.kde.org/plasma/kwin/-/wikis/Using-FTrace-Markers but it's still quite overwhelming . -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 489952] Inconsistent frame timing of cursor on desktop and some apps
https://bugs.kde.org/show_bug.cgi?id=489952 --- Comment #6 from pallaswept --- Hi Zamundaaa, I hope you might be so kind as to lend me some advice. I hope this is not too far off-topic, although I would use this to troubleshoot this issue. I haven't done anything like this on linux yet. On Windows, I might look into this with a tool called GPUView. It is maintained by MS now but this page from the author explains it better than I can: https://graphics.stanford.edu/~mdfisher/GPUView.html Is there a tool (or suite of tools) like that for KDE or linux in general? Or what I really want to ask is, is there one that you personally recommend? -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 489952] Inconsistent frame timing of cursor on desktop and some apps
https://bugs.kde.org/show_bug.cgi?id=489952 --- Comment #5 from pallaswept --- (In reply to Zamundaaa from comment #4) > What NVidia driver version are you on? 550.100 > Do you still see this if you set the kernel boot argument > nvidia.NVreg_EnableGpuFirmware=0 I do. Thanks again for checking this one out. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 489952] Inconsistent frame timing of cursor on desktop and some apps
https://bugs.kde.org/show_bug.cgi?id=489952 --- Comment #4 from Zamundaaa --- What NVidia driver version are you on? Do you still see this if you set the kernel boot argument > nvidia.NVreg_EnableGpuFirmware=0 ? -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 489952] Inconsistent frame timing of cursor on desktop and some apps
https://bugs.kde.org/show_bug.cgi?id=489952 --- Comment #3 from pallaswept --- (In reply to pallaswept from comment #2) > It's not the sort of thing everyone would notice. Very subjective I just noticed this very poorly worded description. My apologies for any confusion I may have caused. To clarify what I meant: The ability to notice it, is subjective - As in, some people can, some people can't, maybe some monitors will show it more or less, etc... But the behaviour itself, is objectively, measurably broken. In layman's terms, it's 'dropping frames'. Thanks for correctly re-assigning this for me Nate! -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 489952] Inconsistent frame timing of cursor on desktop and some apps
https://bugs.kde.org/show_bug.cgi?id=489952 Nate Graham changed: What|Removed |Added CC||[email protected], ||[email protected], ||[email protected] Component|general |performance Assignee|[email protected] |[email protected] Summary|Inconsistent frame timing |Inconsistent frame timing |of cursor on desktop|of cursor on desktop and ||some apps Target Milestone|1.0 |--- Product|plasmashell |kwin -- You are receiving this mail because: You are watching all bug changes.
