Re: xaa vs. WriteImage()

[Michael Lorenz]

-----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?
So far my driver supports image writes, screen-to-screen copies,  
rectangle fills, solid and dashed lines, colour expansion and alpha  
textures. ARGB textures should work as well but I couldn't find a  
user for those - nothing in xfce4 or windowmaker seems to do anything  
with that.
Another thing - I sprinkled xf86Msg()s all over XAA, sometimes  
XCopyArea() calls seem to end up writing to the framebuffer but not  
through xaaCopyArea() - any ideas?

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

iQEVAwUBR89I6cpnzkX8Yg2nAQIkHAgAribd+WTw/t5Xv5nunNUZn6hrwluv+e7J
ox9Hg9V/Yp2CVZVPgSc+3aJOjLPUTPg6L/4tVuNBQLSVnbMO2j7MdGLkhxGznGzl
iv5NNqqToXDO2MM9ctBo8dNB1o3RU76dnbs4QomHYqi/HpNmG+JLJLu3L1+uNjoC
cKjTsUEKWM/UgK+A2UMkjV9vpdEEYoYz2zRu6Njy3bfP7Jyoyh7mwl/c/kamWvU6
k8KnHcRalgsXjmhNRGSV4VOmpc3c/JubHROYTrG5T61aNVge1GAi2jLl27I99vhR
0Bv8iA6juJ5KxZpUajbHSL5vXAZk/QaXss1g7AuVSGCphqE3IC/kHA==
=wynV
-----END PGP SIGNATURE-----
_______________________________________________
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel