Intel framebuffer compression & tiling update

[René Rebe]

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