[Bug 1189174] Virtual DRM drivers cause excessive framerates, maxing out CPU
https://bugzilla.suse.com/show_bug.cgi?id=1189174 https://bugzilla.suse.com/show_bug.cgi?id=1189174#c8 --- Comment #8 from Thomas Zimmermann <tzimmermann@suse.com> --- (In reply to Fabian Vogt from comment #7)
(In reply to Thomas Zimmermann from comment #6)
FYI, I've done some work on this issue, but nothing upstream-able. IMHO we should first push userspace to fix that. AFAIU they are coupling their animation loops to the display refresh rate. That's generally a bad idea.
Can you elaborate? The wayland protocol design is based around that approach...
Right now, the kernel tells userspace when the current frame has been transferred to the display. For better hardware, that's synced to vertical blanking via a dedicated HW interrupt. But most trivial hardware (and that's the majority actually) doesn't have such a VBLANK interrupt. So the kernel processes frames ASAP. There's no point in waiting. Hence for most display hardware, the rate of frame updates is unpredictable; even if the display mode specifies a certain frequency. And some display modes don't specify a frequency; what shall we do then? To compensate these differences in hardware, the userspace animation loop should therefore always be uncoupled from the actual display update. The compositor would sync its animation to the hardware's available rate of frame updates, but not blindly follow it. Computer games have done that ever since; compositors could likely do something similar. The compositor has a much better knowledge of its animation and can easily take available CPU resources into account. All the kernel can do is to delay the current frame's output. -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply@suse.com