Re: xaa vs. WriteImage()

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

Hello,

On Mar 6, 2008, at 15:58, Alex Deucher wrote:

> On Thu, Mar 6, 2008 at 2:58 PM, Michael Lorenz  
> <[email protected]> wrote:
>> -----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.
>
> Use shadowfb and hook in a custom shadowupdate() function.

Wouldn't that interfere with XAA? If I could catch the framebuffer  
writes that bypass XAA that way that would solve my problem.
Thanks!

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

iQEVAwUBR9BhlspnzkX8Yg2nAQLzKwf9GfmbcQZVMLvhx6Je/CgU6fadr/VJq+AZ
sBetdsOeXhFQxGlUFouG8DrDalrSwccXnEo+S4/zuPd5RGn01XmTfm5MBEvxMDAV
upT1U8a5szyHN8t7MgpGwzVoG6Y21F9n07RHsIs/hXB0OfV9yXaM6J3enKRt84Kp
S0pGZWB5xfyrTqBwP8gn1JSq1uTvJr/2zWHE/bwWu8ShAvD2l87FRrsAy0zKfRY6
NWua4rpwDY+XLAsx/kxkmTWbHsKFie+OuO6RUIyqRV+Ix5auLXb7rDRg5S/rKZfx
n2dXmXDs4BZBcl6WzyxEMzthiS88UCQNYjbhGlcL6cwaWC8H5hja1Q==
=OF0s
-----END PGP SIGNATURE-----