https://bugs.kde.org/show_bug.cgi?id=489952
--- Comment #42 from pallaswept <[email protected]> --- 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.
