Re: xaa vs. WriteImage()
Michael Lorenz <[email protected]> Thu, 6 Mar 2008 18:19:49 -0500
| Newsgroups | gmane.comp.xfree86.devel |
|---|---|
| Message-ID | <[email protected]> |
-----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-----