Intel framebuffer compression & tiling update
Jesse Barnes
jbarnes at virtuousgeek.org
Fri Aug 17 10:30:01 PDT 2007
On Friday, August 17, 2007 5:31 am Matthias Hopf wrote:
> On Aug 16, 07 12:15:25 -0700, Jesse Barnes wrote:
> > Framebuffer compression is an Intel feature that uses run length
> > encoding (RLE) to compress the front buffer to a separate
> > compressed buffer from which actual scanout occurs. When enabled,
> > if your desktop is amenable to RLE, it can save as much as 0.7W in
> > configurations I've tested, due to reduced memory bandwidth
> > consumption during scanout (i.e. reading a compressed scanout
> > buffer uses less bw than reading the full, uncompressed one). It
> > shouldn't measurably affect performance adversely, since we've
> > configured it to re-compress the front buffer only every 1000
> > vblank events, nor should it increase power consumption in any
> > measurable way, even in pathological configurations.
>
> Just being curious: how does this work with partial updates? Is the
> compression line-based, so do you have a starting point per line and
> only have to recompress the lines where something changed? Otherwise,
> how would you deal with small changes like animated gifs in a
> webpage?
The compression is line based, so if any line (or part of a line) is
modified either during or after compression, it won't be scanned out
from the compressed buffer, the GPU will use the uncompressed version
instead. Likewise, if a line hasn't been modified since the last pass,
it won't be re-compressed; the per-line status is tracked in the
compressed line length buffer (the "compressed ll" line the memory
layout dump in the server log).
So in order to save power with framebuffer compression, it's best to
have a fairly static desktop with lots of solid colors on a linewise
basis (so a vertical gradient or solid background would compress well,
whereas a horizontal one or a photo likely wouldn't). That'll minimize
the amount of memory bandwidth needed to read from the compressed
buffer and keep it valid for log periods of time.
Jesse
More information about the xorg
mailing list