In set top boxes without OpenGL hardware, the usual graphics hardware is a blitter. Although each blitter is unique they all share some basic functions:
- Fill a rectangular area of the screen with a fixed colour
- Copy a block of memory (image) to another block of memory (screen)
- Scale copies
Boxes and images (with alpha). Thats all we have.
How Blitters Perform
There are three critical measures of blitter performance:
- Setup time - the time to issue a command to the blitter to draw something which involves setting blitter registers
- The fill rate - the number of pixels a blitter can fill in one second at some bit depth with a scale of 1.0
- Time taken to complete a blit request - how fast can the code continue after submitting a blit request
The fill rate is obvious and for most applications not an issue. Modern blitters can fill an HD screen (1920x1080) many times a second. However, quoted figures for fill rate are usually from a local cache for the blitter, whereas in practice the source for blitting is the DRAM of the STB. This means the REAL fill rate will be dependent on how much else the set top box is doing such as video decoding. Nontheless filling an HD screen ten times over is possible and animation speeds of 30fps can be achieved with care.
Fill rate is slowed by alpha blending, though at some predictable rate, and by scaling.
Scaling an image up slows a blitter down. As a guideline - an image zoomed by 200% will be drawn 2x slower. This depends on caches and write bandwidth but its a good guideline. Scaling an image down is not slower than drawing a normal size image but obviously results in less pixels being displayed and thus the effective fill rate is 50% of that at scale factor of 1.
Setup
Blitters in digital receivers are designed to copy large visual areas. Setup time is often less optimised. A typical user interface for set top boxes may only require a few tens of blit commands to redraw and so this usually is not an issue, except in one very important case: text. Text, even vector fonts, is usually prerendered as character bitmaps and characters drawn to the screen to form words. If each character is blitted seperately, we may have many hundreds of blits to render text. It can even occur that setup time becomes so significant with smaller text that using a software loop on the main CPU is faster than using the blitter!
It is setup that prevents us using blitters to draw arbitrary shapes. One can imagine drawing a triangle by drawing each of the scanlines across it. Fill rate exists on blitters to do this but the setup for each scanline is both computationally expensive for set top boxes and also too slow on the blitter itself.
(N.B. some blitters can take display lists of edges and produce arbitrary shapes using this but it is not common to all blitters).
Fast Return of Control
Although mainly a driver issue, not a blitter issue, the speed of blitting can be greatly slowed down on some devices because blit commands block instead of returning. Using non-blocking blits allows code to continue with execution. Many blitters have a blitter queue. This is a buffer into which blit commands can be thrown without blocking and the blitter left to complete them as fast as it can. The code can return and complete some non-graphics tasks in the mean time. Using a blitter queue greatly enhances performance.
Conclusion
Blitters then are the basic graphics hardware for driver writers wanting to optimise graphics performance on digital devices. Even with some 3D enabled devices, the blitter is identified as a fast path for 2D operations. They will remain in set top boxes and anyone wishing to know how to develop fast graphic for digital receivers must understand them and how they work.
No comments:
Post a Comment