Re: Question with regards to componentAlpha

Around 7 o'clock on Sep 16, Thomas Roell wrote:

> Then the spec is wrong. It says:
> 
> 	Indexed PictFormats never have alpha channels and the direct component
> 	is all zeros. Indexed PictFormats always have a colormap in which
> 	the specified colors are allocated read-only and
> 	are therefore screen dependent. 

That part of the spec is referring to the DIRECTFORMAT component of the 
PICTFORMINFO datatype; I agree that it is somewhat misleading.  If you 
look at the description of the INDEXVALUE structure, you'll see all four 
components present for each pixel.

> Also two other issues we ran into. You do set up this translation
> table for index to color. What happens if the index is outside the
> defined color-cube ? I mean, the rest of it is pretty much colormap
> specific.

Yes, this part is not very clear.  The reason the PICTFORMINFO structure 
has a colormap member is so that the server can use that colormap for all 
pictures of the specified format.  All pixel values from pictures of the 
specified format are interpreted relative to this colormap so that index 
values outside of the INDEXVALUE set of colors have well defined RGB 
values.  As the colormap has no alpha storage, alpha values for pixels 
outside of the INDEXVALUE list are all 1.

When drawing, Render will use only the set of pixels advertised in 
INDEXVALUE.

> The other thing is more tricky. OpenGL allows you to have an
> alpha-channel. Is this notion of the alpha-channel shared with XRENDER?

Render doesn't prescribe a particular relationship with OpenGL.

> I mean we tried to expose this via a visual with a depth of 32 and
> 32 planes (a8r8g8b8). However half of the desktop would be drawn
> wrong.

Then it sounds like you have some bugs to fix; Render is quite happy to 
use the extra 8 bits in the frame buffer as a destination alpha channel.  
All Render drawing should generate the right results.  Of course, using 
the core protocol will be a bit tricky as the core colormap is defined to 
start at pixel 0 which will make that appear transparent unless 
applications "know" to | in 0xff000000.

> On the other hand if only a depth of 24 is exposed (and 24 planes), then in
> reality the alpha channel is either never written (using HW planemask, at a
> significant price), or written with random data.

Depth 24 means that the server makes no promises about the additional 8 
bits, you're welcome to do whatever you like with them.  Of course, 
they'll need to be masked out in GetImage as clients expect them to be 
zero.

> The problem seems not to be the CPU, but the readback path via AGP.

Yes, I know.  I know the CPU architects responsible for the Intel version
of that particular problem, the P4 was designed about ten miles from my
home.  The CPU doesn't have prefetch hardware when running in write
combining mode.  One option is to use DMA to get the necessary subset of
the frame buffer moved to main memory, operate on it there and push the
results back to the screen.

Using DMA will also improve performance for regular image transfers as the
CPU doesn't have enough buffering in write combining mode to cover the AGP
latency, so CPU->AGP transfers are slower than DMA transfers controlled by
the graphics card.

I discussed switching the AGP space to write-back mode, but the CPU always 
fills cache lines from memory on the first write, so performance will 
suffer when writing data.  A couple of the P4 designers had a plan to make 
the CPU wait and see if the entire cacheline was written before loading it 
from memory, but that got dropped from the final P4 memory design.

I presume the Athlon has similar characteristics, certain performance 
measurements I've done on Athlon systems show essentially identical 
characteristics with P4 systems.  Perhaps now that I know some people at 
AMD, I'll get some better information.

> I was suprised that you didn't simply choose the OpenGL/DX7 blending
> model, and implement more complex algorithms ontop of that. 

Whereever possible, you'll note that Render does match OpenGL semantics.
Where the existing software models are inadequate, I'm willing to accept
a performance penalty for improved image quality.  Other users may make 
other choices.

Render doesn't do anything outside the scope of existing systems, the 
per-channel alpha compositing is just not (yet) provided as a part of
these two 3D graphics APIs.

Any existing system limited to the semantics exposed by DX7 or OpenGL will
not be able to accelerate this operation in a straightforward fashion.

Keith Packard        XFree86 Core Team        HP Cambridge Research Lab