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.

Alex

>  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?

Sorry, I'm not that familiar with XAA.

Alex

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

Reply via email to