xaa vs. WriteImage()
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, 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)); } } have fun Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iQEVAwUBR8yJLspnzkX8Yg2nAQJB1Af/WJURJ35CVffglB7R3mZm6oNZARbxmiGo yUn2se/QF5MmuuUqOWexdyGhw6W1rpzlDUdpvLhaOV0zFXW1Jbt9zQLFtWkY58TE 2esnUzJNGrt5HZ7egcjfQvKcvLHePJp8N+nBObY8skQhEQJIrgRdRUCRF6NwPF2M P7erfgmTBOu3nZpRAoDAED5A7DQ3BAvR9NG6WOUGVWq+5OB1vk9JJ/paR0Dmy/vQ vtnyn0mO8SMvYd4vy8YVgQN27O4tuSojdJW4A9cFM775fOwbdZ98W6w6pHhKCzkC OP1kylCXNu9pth4MzgLa0b/7lyEs8z3Zq3M/eihpiQKz6Hnqji98cQ== =67pe -END PGP SIGNATURE- ___ 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()
-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()
-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()
-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()
-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()
-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()
-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()
-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