On Thu, Mar 6, 2008 at 2:00 PM, Michael Lorenz <macallan@xxxxxxxxxx> 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
> > <macallan@xxxxxxxxxx> 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@xxxxxxxxxxx
> http://XFree86.Org/mailman/listinfo/devel
>
_______________________________________________
Devel mailing list
Devel@xxxxxxxxxxx
http://XFree86.Org/mailman/listinfo/devel
