Re: xaa vs. WriteImage()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Mar 6, 2008 at 2:58 PM, Michael Lorenz <macallan@xxxxxxxxxx> 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
>  > <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.
>
>  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.

The sgi impact driver does something similar:
http://cgit.freedesktop.org/xorg/driver/xf86-video-impact/

Alex
_______________________________________________
Devel mailing list
Devel@xxxxxxxxxxx
http://XFree86.Org/mailman/listinfo/devel

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [X Forum]     [XFree86]     [XFree86 Newbie]     [X.Org]     [IETF Annouce]     [Security]     [Fontconfig]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]

  Powered by Linux