On Thu, Mar 6, 2008 at 5:17 PM, Michael Lorenz <macallan@xxxxxxxxxx> 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 > > <macallan@xxxxxxxxxx> wrote: > >> On Mar 6, 2008, at 15:58, Alex Deucher wrote: > >> > >>> 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 > >>>>> 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@xxxxxxxxxxx http://XFree86.Org/mailman/listinfo/devel