Radeon HD Vertical Blanking Interrupt Support is Done

Posted by Hans de Ruiter

Thanks to accelerated development, Vertical Blanking (VBlank) interrupt support for Radeon HD 2000-4000 cards (R600/R700 chipsets) is now done. If development pace had continued at the old "spare-time project" rate, then this would still be a work-in-progress. VBlank interrupts are used to achieve smooth double-buffered animation. According to one beta tester, "the 3DCompositeDemo runs a lot more smoothly now with interrupts enabled."

Apart from providing smoother animation, this also eliminates the wasting of CPU cycles while waiting for the VBlank period. RadeonHD.chip driver users may have noticed that certain programs (including the Composite3DDemo) caused CPU usage to go up to 100%. Well, lack of interrupt support in the driver is the reason why. Without interrupts, waiting for the VBlank period means polling the graphics card, wasting a lot of CPU cycles in the process. With interrupt support implemented, CPU usage with the Composite3DDemo drops down to 25-75%, depending on the hardware and resolution.

A Complex Interrupt Controller

With Radeon X1000 series cards, VBlank interrupt support was so easy to implement that they weren't even worth mentioning. However, Radeon HD cards are a completely different design. They have a complex interrupt controller that even has its own microcode (which the driver must upload to the controller). Interrupt events are written to a ring-buffer, which the driver must then read and interpret in the interrupt handler. While this setup has its advantages, it is quite a bit more complicated than simple interrupt status registers (which it also has). Additionally, the details of this controller are missing from the documentation. This is why this feature had not yet been implemented.

Fortunately, AMD provides not only the all-important microcode, but also code to program the interrupt controller (via the open-source Linux drivers). Using this code as a starting point, adding interrupt support proved to be relatively plain sailing. In fact, once all of the code adaptation had been done, it almost worked on the first test. The one mistake that I had made was forgetting to pass on the VBlank interrupt to Picasso96, meaning that programs were left waiting forever. There was also an issue with waiting for interrupts while switching screen-modes (during which time Radeon HD cards don't send VBlank interrupts), but that was solved fairly quickly.

What are VBlank Interrupts and how do they Help?

The VBlank period is the small period between outputting the last line of one frame, and starting on the next frame. Back when computer monitors and televisions were Cathode Ray Tubes (CRTs), this was the brief period during which the electron beam that drew the image onto the screen would quickly be moved up to the top of the screen for the next frame (or field for interlaced displays). Today, this VBlank period is still there. More importantly, this corresponds to the start of a new frame.

Programs that display animations need to swap one frame (image) for the next during the VBlank period. Failing to perform the swap during that time can result in part of the screen showing an old frame, and the other showing the new one. This is visible as ugly "tearing" artifacts. Thus, the program needs to know when the VBlank period occurs.

This is where the VBlank interrupt comes in. The graphics card sends an interrupt to the CPU, letting it know that the VBlank period is now. Next, the OS performs double-buffering and/or lets any program that is waiting for the VBlank period resume execution. The result is smooth and tear-free animation.

Without VBlank interrupts, the CPU has to poll the graphics card's VBlank state. This wastes CPU cycles, and instantly brings CPU usage to 100% (as mentioned earlier). Apart from being inefficient, it is also less accurate. It's easy to see why VBlank interrupts are superior to polling the hardware (as are interrupts in general).

What's Next?

As I said in the previous development log post, the next task is implementing Video RAM (VRAM) management for the RadeonHD_RM.resource (intelligent VRAM buffer paging). This is essential for stable 3D operation. At present, if a 3D application were to run out of VRAM, bad things might happen. By paging out textures/buffers that are least likely to be needed soon, the drivers will be able to handle "out of VRAM" situations with ease.

NOTE: This development log gives a "behind the scenes look" at the progress of the RadeonHD driver's development. As such, its contents reflect the state of the development version of the driver, and not the state of the publicly released version.

Comments (1) | 27 February 2012