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-----