Strange speed differences on composite

[Adam Jackson]

On Monday 20 February 2006 00:18, Torgeir Veimo wrote:
> On Tue, 2006-02-14 at 12:07 -0500, Adam Jackson wrote:
> > When Render is accelerated in hardware, you can simply load the 1 and
> > (1-srca) blend factors into the hardware and it runs like a normal
> > screen-to-screen blit; you can think of a plain blit as one where the
> > source blend factor is 1 but the dest blend factor is 0.  When it's
> > not accelerated in hardware, you have to compute each output pixel by
> > reading the dst_color pixel from the framebuffer, blending it with the
> > src_color pixel in the CPU, and then writing that result back to the
> > framebuffer.
>
> Wouldn't it make sense to do _all_ client based rendering in software
> and only hardware accelerate the copy to framebuffer memory operations
> that the compositor needs to do in the case when exa isn't sufficient
> implemented?

This is basically the shadowfb model, which kinda works.  Currently, using 
shadowfb means giving up DRI and Xv, and most people aren't willing to give 
that up.  Also shadowfb has at least one known bug in the presence of the 
Composite extension, which is admittedly fixable.

The problem is, unless you keep a full copy of the front buffer in host 
memory, it _will_ be possible for the user to ask you to do a blend whose 
destination pixels only exist in the front buffer, which is to say, on the 
card.  So you'd still need to do readouts.

EXA scoring should more or less handle this, with the advantage that since the 
driver gave you a DownloadFromScreen hook for DMA, you can get the pixels out 
of the framebuffer as fast as possible and en masse.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20060220/bcff3b1c/attachment.pgp>