Re: xaa vs. WriteImage()
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, On Mar 7, 2008, at 13:03, Marc Aurele La France wrote: On Wed, 5 Mar 2008, Michael Lorenz wrote: Otherwise, teaching the framebuffer layer to cope with a tiled framebuffer might be necessary in the long run, any pointers where to start? By design, this is a driver issue, as it is responsible for providing VRAM access to the rest of the server. Really. Now /that/ was helpful. Guess I'm on my own here. Not really. This sounds like the kind of thing that is right up the mibank screen wrapper's alley, assuming the tiles are all the same size. They are, always 64KB, depending on colour depth they're 512x128, 256x128 or 128x128 pixels. mibank can interoperate with any other screen wrapper (including XAA), except shadowfb, because the later is not a true screen wrapper. An example of the use of mibank can be found in ATIPreInit() and ATIScreenInit(). Mine, that is; not X.Org's lobotomised imitations of same. That sounds like it's what I need, thanks! have fun Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iQEVAwUBR9GKRspnzkX8Yg2nAQK9fwf/bNN+ZV299AWKn2PFcLi67H82tH6JoSTd Ykhwgnai7fw8iMhY9wPIK3nbYkWaEE88CdQ8ZzEyYVGcPix+XDydo+kbs5xSPvNr +t+YHWabiyopbq3YjE1QXUzh6xNwknMRSuGo6iEzWSUhQfxpwzPNwXePZK7+PDdw 1OhKu9QpI8jxLqQOoH5BYTteK8leuVx15E+m1hXhIgFbrdnIgzF7bSnD5SkJwqou QEnXXGY+A1Tx60RfrZssFDSA1+TnINKN55jJFRBWCC5DYRitFpRdXVqfyZdPU4dt aW5qVAPk8NJl2/+Ck5tJrjvoBqo8dxl7MCGjBqkDRMFS/To2XKYBYQ== =kP5V -END PGP SIGNATURE- ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: xaa vs. WriteImage()
On Wed, 5 Mar 2008, Michael Lorenz wrote: Otherwise, teaching the framebuffer layer to cope with a tiled framebuffer might be necessary in the long run, any pointers where to start? By design, this is a driver issue, as it is responsible for providing VRAM access to the rest of the server. Really. Now /that/ was helpful. Guess I'm on my own here. Not really. This sounds like the kind of thing that is right up the mibank screen wrapper's alley, assuming the tiles are all the same size. mibank can interoperate with any other screen wrapper (including XAA), except shadowfb, because the later is not a true screen wrapper. An example of the use of mibank can be found in ATIPreInit() and ATIScreenInit(). Mine, that is; not X.Org's lobotomised imitations of same. Marc. +--+--+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +--+ | University of Alberta | | | Edmonton, Alberta |Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+--+ ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: xaa vs. WriteImage()
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, On Mar 6, 2008, at 18:02, Alex Deucher wrote: On Thu, Mar 6, 2008 at 5:17 PM, Michael Lorenz <[EMAIL PROTECTED]> wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, On Mar 6, 2008, at 16:40, Alex Deucher wrote: On Thu, Mar 6, 2008 at 4:26 PM, Michael Lorenz <[EMAIL PROTECTED]> wrote: 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 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! Yeah, you gotta pick one or the other IIRC. However for most modern desktops you either have to be entirely SW or entirely HW or performance sucks. You lose if any sort of fallbacks cause a pixmap migration to/from vram. In my case VRAM is RAM, and the CPU is pretty slow - I've had things running entirely SW and performance sucked. Not the slowest I've ever seen but nowhere near what the HW can do. Also, many X applications have trouble with the HW's native pixel format, cairo for instance just crashes. Using the DMA engine I can pretend it's using something more common - ABGR - and those applications just work fine. I think the next thing I'll try is to pretend that we're accessing VRAM through a small window, there must be prior art for that somewhere in the source tree. the sgi impact driver I mentioned before (http://cgit.freedesktop.org/xorg/driver/xf86-video-impact/) does that. IIRC, there's no way to access the vram directly so everything gets sent to the card via dma. Yeah, that's the software-only case. Interesting but I'd rather find a way to make this work while being able to use the rendering engine. have fun Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iQEVAwUBR9B8FcpnzkX8Yg2nAQIe8Qf9FN2yZYRhGQv9f6B+ljBbkbIUx/8yXSe9 T9i4tMWGH5p1RnzoSU0GX8qHmmF8lm2ajMKI8yY496+Kma34NiPUN2QgrRJJrlen yG2WOydYC1iqCYj+MA3pfJ3Nqns/xMJDj24BWVfpQGDDEHEaegjIcFpsXH5MW++W dQbojEECbMFivSmTAuZ3u/YmfDskw6TqE+fTBGLLXurmnQY0lFok1IUeyS7dITuw A5L2BJJMFjvP32uglb6LGUlw921Aj5o7kMEI7VBvJx8lgoTBPmT+lwXaacUbQ2iv bG9+GFctpswI9nuI/CDNhvdKyMHlgUieYn9nHX90VQuGil02AvfpFw== =t834 -END PGP SIGNATURE- ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: xaa vs. WriteImage()
On Thu, Mar 6, 2008 at 5:17 PM, Michael Lorenz <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hello, > > On Mar 6, 2008, at 16:40, Alex Deucher wrote: > > > On Thu, Mar 6, 2008 at 4:26 PM, Michael Lorenz > > <[EMAIL PROTECTED]> wrote: > >> 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 > > 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! > > > > Yeah, you gotta pick one or the other IIRC. However for most modern > > desktops you either have to be entirely SW or entirely HW or > > performance sucks. You lose if any sort of fallbacks cause a pixmap > > migration to/from vram. > > In my case VRAM is RAM, and the CPU is pretty slow - I've had things > running entirely SW and performance sucked. Not the slowest I've ever > seen but nowhere near what the HW can do. > Also, many X applications have trouble with the HW's native pixel > format, cairo for instance just crashes. Using the DMA engine I can > pretend it's using something more common - ABGR - and those > applications just work fine. I think the next thing I'll try is to > pretend that we're accessing VRAM through a small window, there must > be prior art for that somewhere in the source tree. > the sgi impact driver I mentioned before (http://cgit.freedesktop.org/xorg/driver/xf86-video-impact/) does that. IIRC, there's no way to access the vram directly so everything gets sent to the card via dma. Alex ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: xaa vs. WriteImage()
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, On Mar 6, 2008, at 16:40, Alex Deucher wrote: On Thu, Mar 6, 2008 at 4:26 PM, Michael Lorenz <[EMAIL PROTECTED]> wrote: 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 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! Yeah, you gotta pick one or the other IIRC. However for most modern desktops you either have to be entirely SW or entirely HW or performance sucks. You lose if any sort of fallbacks cause a pixmap migration to/from vram. In my case VRAM is RAM, and the CPU is pretty slow - I've had things running entirely SW and performance sucked. Not the slowest I've ever seen but nowhere near what the HW can do. Also, many X applications have trouble with the HW's native pixel format, cairo for instance just crashes. Using the DMA engine I can pretend it's using something more common - ABGR - and those applications just work fine. I think the next thing I'll try is to pretend that we're accessing VRAM through a small window, there must be prior art for that somewhere in the source tree. have fun Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iQEVAwUBR9BtZcpnzkX8Yg2nAQJKvggAuAmc/lGnCFx4JYnvLKeE9uMyDBWIu48V emxeNH3eIbH2U8kc4rthaQVtDfmcMK6rWHgk89shlZiUonZAjuCjl9alDERAPu3Z By2y5PX/0KFfVq/PXr2YpuFpxQSUD8Av9Mn+ReouTA6usOABPSRVEfVjx5hsCbkq 7dYyLsAYkz9gBV3YzfmZn16ltOIfu2dzXXaTUGDkoL//jkj0pMDCptr2k5UvGzdm R4FNvGImR3lf51HzMjx43qvkpWu2vvjdDZrOdZdZr4bxY0Wem2OzgmOtgGzACh8z zNgsKVxRfJ8w2TzfUibeI16FanT+60nZuikJvBh/ZEfZaH+igcp8Cg== =NHsm -END PGP SIGNATURE- ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: xaa vs. WriteImage()
On Thu, Mar 6, 2008 at 4:26 PM, Michael Lorenz <[EMAIL PROTECTED]> wrote:
> -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 - 1.1.1.3
> +++ xaaCpyArea.c 3 Mar 2008 20:51:05 -
> @@ -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.
>
>
Re: xaa vs. WriteImage()
-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 - 1.1.1.3
+++ xaaCpyArea.c 3 Mar 2008 20:51:05 -
@@ -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
Re: xaa vs. WriteImage()
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 - 1.1.1.3
> >> +++ xaaCpyArea.c 3 Mar 2008 20:51:05 -
> >> @@ -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@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel
Re: xaa vs. WriteImage()
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 - 1.1.1.3
> >> +++ xaaCpyArea.c 3 Mar 2008 20:51:05 -
> >> @@ -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.
Alex
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel
Re: xaa vs. WriteImage()
-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 - 1.1.1.3
+++ xaaCpyArea.c 3 Mar 2008 20:51:05 -
@@ -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.
have fun
Michael
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (Darwin)
iQEVAwUBR9BM2cpnzkX8Yg2nAQK+dAf7B+5F0uHL8Vh0o7FCqWmdEHMs0EFT1eb1
4tvc/V8SVB2ZFnHBdkA5YdwXq6dIhNeQQRFDCu29VFBwlj4GHzkhAcYdkI00sDDa
84OpdxtuYTT0WvC74uaW486zMpEze0/0AvI3ZFeiP078TCUJ4161u8pA5zq6VkOu
FjaFBYcte/rGhNcg/VsBsDOx5gLwQxpEqImtFuqIRg9xgN2R1Zmto7BZvKV7eUvS
FRnvfZjBiTt/AbjdHtwwWEeRnp/3vu4cTz3+6pWmDMlVq4UFtLkvLVk8429Oz/eQ
tjv3MlU7cpeXLwFz3s3QqJ/4RYlmQGI7dDGYHDWT1yRLdAnDLVdafg==
=Biva
-END PGP SIGNATURE-
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel
Re: xaa vs. WriteImage()
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 - 1.1.1.3
> +++ xaaCpyArea.c 3 Mar 2008 20:51:05 -
> @@ -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
Re: xaa vs. WriteImage()
-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 - 1.1.1.3
+++ xaaCpyArea.c 3 Mar 2008 20:51:05 -
@@ -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
Re: xaa vs. WriteImage()
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 - 1.1.1.3
> >> +++ xaaCpyArea.c 3 Mar 2008 20:51:05 -
> >> @@ -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.
Alex
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel
Re: xaa vs. WriteImage()
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, Otherwise, teaching the framebuffer layer to cope with a tiled framebuffer might be necessary in the long run, any pointers where to start? By design, this is a driver issue, as it is responsible for providing VRAM access to the rest of the server. Really. Now /that/ was helpful. Guess I'm on my own here. have fun Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iQEVAwUBR88QOspnzkX8Yg2nAQJvNQgApOyezj1wfcoiLcO/IpS6R9mdnQ7RdOHT R08xjo5fueS512tBGgjnB8ay8vilEbaTRE94J45sLGhLueKtRd6nNjUseyz3rggt v1xaHsaNQzTJIQ0BL5m27YN5bg3bk4e16EuekGeggdyBd/zDFHCWPNdm03Jy/ku4 ypxDlrF8OV+Wrf5hRnDP64iBT2KzOptIkg/UBiIk3fGbbxLJAryL03gozV35c6Zt b9g5I30HNKzr4pnb0AfOZ08fdBLQW3J5CqnD1a5CDrCQJW/BmfR6MttbNKvaqTwk 63iY5Abey8VTtXG6gmdFkAjX/N4ArYnHsbS78TlrIFQ6NwE4+C4HRw== =vrbT -END PGP SIGNATURE- ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: xaa vs. WriteImage()
On Tue, 4 Mar 2008, Michael Lorenz wrote:
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 - 1.1.1.3
+++ xaaCpyArea.c3 Mar 2008 20:51:05 -
@@ -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.
You could check that the change doesn't introduce additional xtest
failures.
Otherwise, teaching the framebuffer layer to cope with a tiled framebuffer
might be necessary in the long run, any pointers where to start?
By design, this is a driver issue, as it is responsible for providing VRAM
access to the rest of the server.
Marc.
+--+--+
| Marc Aurele La France | work: 1-780-492-9310 |
| Academic Information and| fax:1-780-492-1729 |
|Communications Technologies | email: [EMAIL PROTECTED] |
| 352 General Services Building +--+
| University of Alberta | |
| Edmonton, Alberta |Standard disclaimers apply|
| T6G 2H1 | |
| CANADA | |
+--+--+
XFree86 developer and VP. ATI driver and X server internals.
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel
Re: xaa vs. WriteImage()
-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 - 1.1.1.3
+++ xaaCpyArea.c3 Mar 2008 20:51:05 -
@@ -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?
have fun
Michael
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (Darwin)
iQEVAwUBR83OYspnzkX8Yg2nAQJNnAf/auo5d5PGw/M8IpvL+GIoCXL7ME2QGMsp
Wv6wSrZ9ONA+uFEI/ppUBF10gwdXulEMuXy6bVyqzTGzRDCl3xxmF2f0IVuo6MWX
/Ar+rg7wHJgnl94UUQnX6z02mBS3ldx/f9U534KqjmrUsnU8nx00AHe07hQRHBrE
m0gPaiO2/ueX5IXmtVS1S+TmV6tkQ2UKp+sZjflHEp7078kV9wQkC8A7ImkOPhxe
DBkRLt76uGR6YUlvivHAMxpdqBiIbxBLWpd1mg65/Cw48uJD850j3BoAGFZqDl+x
sPadDNC6yxY4/5c/Oq4vEo2Fcss87PdNQbow9YR9m9AEmsktK5DS5Q==
=hzKc
-END PGP SIGNATURE-
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel
Re: xaa vs. WriteImage()
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 - 1.1.1.3
+++ xaaCpyArea.c3 Mar 2008 20:51:05 -
@@ -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).
have fun
Always.
Marc.
+--+--+
| Marc Aurele La France | work: 1-780-492-9310 |
| Academic Information and| fax:1-780-492-1729 |
|Communications Technologies | email: [EMAIL PROTECTED] |
| 352 General Services Building +--+
| University of Alberta | |
| Edmonton, Alberta |Standard disclaimers apply|
| T6G 2H1 | |
| CANADA | |
+--+--+
XFree86 developer and VP. ATI driver and X server internals.
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel
