Re: xaa vs. WriteImage()

[Michael Lorenz]

-----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-----
_______________________________________________
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel