Strange speed differences on composite

[Adam Jackson]

On Saturday 11 February 2006 14:13, Tomasz Torcz wrote:
> On Fri, Feb 10, 2006 at 07:00:03AM -0500, Owen Taylor wrote:
> > On Thu, 2006-02-09 at 18:55 +0100, Tomasz Torcz wrote:
> > >   The question: how it comes that software-only Xephyr is _faster_ at
> > > drawing shadows than fully hw accelerated X server with mga driver?
> >
> > If you ever have to read data from the frame buffer, that's *slow* -
> > you lose far more than you gain from any hardware acceleration you
> > might be getting.
>
>   But why read data? Shouldn't it be composed by graphic card in VRAM?
> Isn't that what acceleration is for?

"Acceleration" isn't an all-or-nothing thing.  Almost all the drivers we have 
are accelerated to one degree or another.  The issue is that very few of them 
accelerate the image composition operations that Render exposes.

When you do an Over blend in Render, you're computing values for each pixel:

output = 1 * src_color + (1 - src_alpha) * dst_color

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.  

That's essentially the same as reading the entire image back from the 
framebuffer into host memory.  Write speeds are pretty fast, but framebuffer 
readback speeds pretty much top out at 50M/sec or so, so that's how fast 
you're going to go.

Phrased another way, your assertion above:

> > > drawing shadows than fully hw accelerated X server with mga driver?

is that the mga driver is fully hardware accelerated.  It's not, it doesn't 
accelerate Render in hardware.

- 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/20060214/147c1178/attachment.pgp>