Matthew Garrett on the race to idle [LWN.net]

Matthew Garrett on the race to idle

Posted May 10, 2008 18:39 UTC (Sat) by renox (guest, #23785)
In reply to: Matthew Garrett on the race to idle by farnz
Parent article: Matthew Garrett on the race to idle

Weird, if your application needs to update the screen every 16ms, this means that you're using
some kind of timers to wake up every 16ms, so the kernel ought to be aware of this deadline
and change the C-state of the CPU accordingly..

Either I'm misunderstanding something or there is a bug somewhere, have you discussed this on
the LKML?

(Log in to post comments)

Matthew Garrett on the race to idle

Posted May 10, 2008 19:23 UTC (Sat) by farnz (guest, #17727) [Link]

Not yet discussed this on the LKML - disabling C states is a good enough workaround for now, and I'm currently knee-deep in VIA hardware issues to debug.

We're not using timers at all - we use the DRM to wait for VBlank. The kernel can't easily know (without kernel modesetting, which is a whole different can of worms to fix) that the frame rate of our screens is 60Hz. Once kernel modesetting lands, I'll certainly be looking into ensuring that the kernel is aware of the latency limits that wait for VBlank implies.

Matthew Garrett on the race to idle

Posted May 13, 2008 13:41 UTC (Tue) by daenzer (✭ supporter ✭, #7050) [Link]

> We're not using timers at all - we use the DRM to wait for VBlank.

But then use X11 for rendering? If so, part of the reason for the latency being too high could
be the several context switches between the interrupt and the rendering operation taking
place. By using OpenGL with current Mesa and a current drm Git snapshot, it would be possible
to have the DRM emit the buffer swap operation from a tasklet triggered by the interrupt, and
the application could generate frames ahead of time and transparently sleep when it's too far
ahead.

Matthew Garrett on the race to idle

Posted May 13, 2008 14:46 UTC (Tue) by farnz (guest, #17727) [Link]

We do use X11 for rendering, but it's definitely the move from a low C-state that kills us. We can easily measure the latency of the rendering operation; in the worst case we've seen thus far (not on an Intel platform), we see around 0.03 milliseconds between the wait for VBlank syscall returning, and us being about to enter the wait again. Note that we sync the X stream at this point, so we don't re-enter the wait until the server has finished drawing.

Note that we don't draw by blitting a new frame from scratch; we delta the existing on-screen frame instead, which minimises the work involved.