Intel framebuffer compression & tiling update
René Rebe
rene at exactcode.de
Fri Aug 17 11:01:40 PDT 2007
Hi,
On Friday 17 August 2007 19:30:01 Jesse Barnes wrote:
> 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.
Btw. The NSC/AMD Geode chip and X.org driver allow for something
quite simillar.
Yours,
--
René Rebe - ExactCODE GmbH - Europe, Germany, Berlin
http://exactcode.de | http://t2-project.org | http://rene.rebe.name
More information about the xorg
mailing list