Re: xaa vs. WriteImage()

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

On Mar 6, 2008, at 14:12, Alex Deucher wrote:

> On Thu, Mar 6, 2008 at 2:00 PM, Michael Lorenz  
> <[email protected]> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>>  Hash: SHA1
>>
>>  Hello,
>>
>>  On Mar 5, 2008, at 19:06, Alex Deucher wrote:
>>
>>> On Tue, Mar 4, 2008 at 5:34 PM, Michael Lorenz
>>> <[email protected]> wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>  Hash: SHA1
>>>>
>>>>  Hello,
>>>>
>>>>
>>>> On Mar 4, 2008, at 15:37, Marc Aurele La France wrote:
>>>>
>>>>> On Mon, 3 Mar 2008, Michael Lorenz wrote:
>>>>>
>>>>>> I noticed the following - XAACopyArea() only attempts to use
>>>>>> accelerated WriteImage() when writing to a DRAWABLE_WINDOW but  
>>>>>> not
>>>>>> on off-screen pixmaps. I used the following changes to make it
>>>>>> work:
>>>>>
>>>>>> diff -u -w -r1.1.1.3 xaaCpyArea.c
>>>>>> - --- xaaCpyArea.c   9 Jun 2001 15:09:02 -0000       1.1.1.3
>>>>>> +++ xaaCpyArea.c     3 Mar 2008 20:51:05 -0000
>>>>>> @@ -64,9 +64,16 @@
>>>>>>            return (XAABitBlt( pSrcDrawable, pDstDrawable,
>>>>>>              pGC, srcx, srcy, width, height, dstx, dsty,
>>>>>>              XAADoBitBlt, 0L));
>>>>>> +    } else {
>>>>>> +        if(infoRec->ScreenToScreenBitBlt &&
>>>>>> +         CHECK_ROP(pGC,infoRec->ScreenToScreenBitBltFlags) &&
>>>>>> +         CHECK_ROPSRC(pGC,infoRec->ScreenToScreenBitBltFlags) &&
>>>>>> +         CHECK_PLANEMASK(pGC,infoRec- 
>>>>>> >ScreenToScreenBitBltFlags))
>>>>>> +            return (XAABitBlt( pSrcDrawable, pDstDrawable,
>>>>>> +            pGC, srcx, srcy, width, height, dstx, dsty,
>>>>>> +            XAADoImageWrite, 0L));
>>>>>>      }
>>>>>>    }
>>>>>
>>>>> This does not look correct.  Shouldn't this be more in line with
>>>>> the case where the destination drawable is a window?  (i.e. test
>>>>> bitsPerPixel's and WritePixmap files instead of
>>>>> ScreenToScreenBitBlt).
>>>>
>>>>  The whole logic looks a little bit fishy, I used the first if()'s
>>>>  source-in-memory branch first but wasn't quite sure if that's  
>>>> doing
>>>>  the right thing, where it;s now looked better to me but I won't
>>>> claim
>>>>  I completely understand XAA's inner voodoo. All I want is the make
>>>>  XAA use ImageWrite()s for all RAM-to-VRAM transfers if the driver
>>>>  supports it.
>>>>  Otherwise, teaching the framebuffer layer to cope with a tiled
>>>>  framebuffer might be necessary in the long run, any pointers
>>>> where to
>>>>  start?
>>>
>>> Several drivers (radeon, intel, savage) in the Xorg tree provide
>>> support for various tiling methods.  Generally the chip provides a
>>> surface control or aperture for exposing a tiled region to the  
>>> CPU as
>>> a linear surface.  For acceleration, you have to keep track of what
>>> buffers are tiled in the driver and do the right thing with the
>>> blitter when using those surfaces.
>>
>>  Yeah, I'm dimly aware of these things - my problem is that the
>>  hardware in question doesn't give me a linear view on the  
>> framebuffer.
>>  All I have is a small linear buffer I can use to DMA data in or out
>>  of the tiled framebuffer. The other problem is that the machine's
>>  native pixel format is RGBA, if I want 24bit colour that's the only
>>  one I can use. Fortunately the DMA engine can convert pixels on the
>>  fly so I can pretend it's ABGR. So pixels would have to be endian-
>>  flipped as well when the fb layer accesses VRAM - is there any prior
>>  art for that?
>
> EXA has prepare/finish access hooks for CPU access to buffers.  I
> don't think XAA has anything similar.  There's also an wrapable FB
> module, although I think it's only available in Xorg.

I'll have a look at that - the main reason I'm using XFree86 is that  
it's already working on NetBSD/sgimips, Xorg needs some more work but  
I'll eventually do it.
Hmm, some drivers access video memory through tiny apertures like the  
VGA range - maybe I can do something like this - let the rest of the  
Xserver render into my DMA buffer and then blit it in place.

have fun
Michael
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iQEVAwUBR9BM2cpnzkX8Yg2nAQK+dAf7B+5F0uHL8Vh0o7FCqWmdEHMs0EFT1eb1
4tvc/V8SVB2ZFnHBdkA5YdwXq6dIhNeQQRFDCu29VFBwlj4GHzkhAcYdkI00sDDa
84OpdxtuYTT0WvC74uaW486zMpEze0/0AvI3ZFeiP078TCUJ4161u8pA5zq6VkOu
FjaFBYcte/rGhNcg/VsBsDOx5gLwQxpEqImtFuqIRg9xgN2R1Zmto7BZvKV7eUvS
FRnvfZjBiTt/AbjdHtwwWEeRnp/3vu4cTz3+6pWmDMlVq4UFtLkvLVk8429Oz/eQ
tjv3MlU7cpeXLwFz3s3QqJ/4RYlmQGI7dDGYHDWT1yRLdAnDLVdafg==
=Biva
-----END PGP SIGNATURE-----