Questions about possible EXA Composite acceleration for savage

[Eric Anholt]

On Mon, 2008-04-14 at 13:56 -0500, Alex Villací­s Lasso wrote:
> I am currently studying the feasibility of implementing Composite 
> acceleration for the savage driver. The 3D hardware available has two 
> texture units, which require power-of-two dimensions to work (both width 
> and height). From what I could see, setting the POT flag only sets up a 
> POT source pitch, but does nothing for the height. What could happen if 
> I use the next bigger power-of-two height as the texture height? Does 
> EXA guarantee that I will not overrun into the next stored texture, or not?
> 
> Another question: apparently the POT flag has effect on the reported 
> texture pitch, not on the actual image width 
> (PixmapPtr->drawable->width). What is stored on the right of the true 
> width? Is it garbage, or does EXA guarantee it to be some constant 
> value, or that it will always be covered by the mask texture or source 
> alpha channel? How should this be handled if the driver needs to repeat 
> the source texture, as apparently required by a source texture of 1x1 
> and a destination coordinate of, say 28, 15? Note that, even though 1 is 
> a power of two, EXA still honors the pitch alignment of 128 bytes (one 
> tile pitch).
> 
> This might be easier to answer for me if I could examine existing source 
> code for some other driver that has both EXA Composite acceleration and 
> the POT requirement. Do you know whether any of the existing drivers 
> meet both requirements?

The POT flag is about rounding up to a power of two pitch so that for
non-power-of-two (NPOT) texture sizes the layout is set up so you can
lie to the hardware about the texture size.

The Xati kdrive driver (hw/kdrive/ati) has a r128 render acceleration
implementation that requires POT pitches.  The padding contents are
undefined, as well as anything beyond the height of the pixmap.  This
means you can't support repeats for NPOT pictures (If in RepeatNone mode
and there's no transform, your destination coordinates will be clipped
such that no access outside of pixmap width/height will occur).

For your 1x1, you should be fine.  You program a 1x1 texture with 128
byte pitch, and you can use hardware repeat support, because the
hardware will handle it right.  Same for any power-of-two size.  It's
only the NPOT textures where you're lying about the size that you have
to special case.

-- 
Eric Anholt                             anholt at FreeBSD.org
eric at anholt.net                         eric.anholt at intel.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg/attachments/20080414/1cd8ba75/attachment.pgp>