radeon, apertures & memory mapping

Benjamin Herrenschmidt benh at kernel.crashing.org
Mon Mar 14 13:51:52 PST 2005


> 
> Ok so the problem is byte swapping. Looking at atyfb for example it uses 
> the "big-endian" aperture on big-endian systems and selects the byte 
> swapping method according to the bit depth. If that really means that all 
> host access to the aperture gets byte swapped then I don't see how the 
> current situation can work correctly for DirectFB. Offscreen surfaces can 
> use any bit depth and so their bytes could be swapped incorrectly. Makes 
> me wish I had a PPC box alongside the x86 one.

Possibly yes. In X, when blitting to an overlay surface, we
save/clear/restore the swapper indeed.

I would really like to keep the swappers independant though. Take things
like MOL (MacOnLinux). I maps the framebuffer and passes it to MacOS,
which expects proper swapping and doesn't (for a basic non-accelerated
framebuffer, which is what MOL implements) provide an easy way to
set/restore the swapper.

Also, doing so would require arbitration between clients using both
heads, while 2 independant swappers mean that even if the client wants
to temporarily disable it (for uploading an offscreen surface for
example), it has it's own swapper and won't conflict with whoever is
using the other framebuffer.

That means some knowledge about those swappers of course.

Note that almost all fbdev's on big endian platforms have some kind of
swapping mecanism on accesses, so that's something you'll have to deal
with anyway.

Ben.





More information about the xorg mailing list