Re: Question with regards to componentAlpha

In your message of 16 September 2002 you write:

> 
> 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.

Yes, INDEXVALUE has a alpha value, but the section I was citing
indicates that the alpha-value would be zero.
 
> > 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.

Ok. Could you update the upper section please to state that is a
picture format has no alpha channel, the aplha channel is assumed to
be 1.0. And then be explicite for the index case that the red, green
and blue components are taken from the colormap.

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

Correct.
 
> > 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.

It has to, as both have a notion of alpha channels that might be
associated with a window (or pixmap).
 
> > 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.

The bug as you found is not in our render implementation, it's more
the fact the normal X11 drawing by default will put alpha to be 0.0.

One idea here was to always set alpha to be 1.0 (i.e. adding it to the
fgPixel/bgPixel of a GC). But that would mean that you cannot really
access the alpha channel under X11, and hence you might as well not
expose the channel (which we opted to do).

> > 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.

Correct. However this seems to be inelegant, as would now have no
window picture formats that have an alpha channel. Apps that might
want to use a alpha channel would be forced down the road of hanving
an alphaMap for the destination, which by default needs to go throu a
slow SW path. That's why I was looking for more insight about how you
would handle this case.

> > 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.

Yes, DMAs will help. But it will be still slower than having the
Read/Modify/Write Framebuffer part of the compositing done on the
graphics hardware.

> 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.

That does not work. The AGP spec (well, more the databooks of the
northbridges that is) allows that the fetches that travel over the AGP
bus are not snooping the CPUs cacheline(s). Hence you would have to
manually flush dirty cache lines. As far as I understand this, the
IA32 design does not allow you to flush individual cache lines.

> 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.

I am not surprised that they are not, and I would not be surprised if
they would never be. A lot of the latest focus for 3D systems has been
to get more fleximiblty into the generation of the source component
(i.e. programmable fragment shaders and so on). The basic backend
blending path seems to be a constant (i.e. having a single
source, having a single destination, and having a single constant
color). I would not see where within OpenGL/DX semantics after a
fragement shader program has been processed (or the static
configuration of the texture pipeline), there would be any additional
input to the blender unit (other than maybe some other constant
factors). Not that this could never happen, it is just very unlikely
given that typical 3D effects are moew dealing with upstream
(i.e. source only) image compositing.

- Thomas
-- 
	     Thomas Roell   /\	       Das Reh sprint hoch,
	     Xi Graphics   /  \/\ _     das Reh springt weit,
	 [email protected]	  /   /	 \ \	 was soll es tun,
			 / Oelch! \ \     es hat ja Zeit.