Re: [Linux-fbdev-devel] Re: FB model basic issues (WAS: radeon, apertures & memory mapping)

["Ville Syrjälä" <syrjala@sci.fi>]

On Wed, Mar 16, 2005 at 12:51:27PM +1100, Benjamin Herrenschmidt wrote:
> On Wed, 2005-03-16 at 03:47 +0200, Ville Syrjälä wrote:
> 
> > There's also the case with Matrox Millennium I/II cards. They must place 
> > the visible frame buffer so that no line crosses the boundary of memory 
> > banks. matroxfb deals with that by moving the buffer and changing 
> > smem_start and smem_len appropriately. But that is really bad for 
> > DirectFB's offscreen memory management. After a mode switch the memory 
> > manager would need to know what kind of initial byte offset was used. Of 
> > couse it would be possible to determine that from smem_start by knowing 
> > how the aperture must be aligned. Actually we already do that sort of 
> > thing to allow hw accelerated rendering when used on matroxfb controlled 
> > G450/G450/G550 CRTC2. But in that case the offset won't change on mode 
> > switch.
> 
> So it alls end up to -> mode switch has to bust memory layout, and any
> assumptions that DirectFB tries to do are incorrect.

I don't think so. Due to fbdev API limitations DirectFB just can't 
accurately determine how much memory will be used by the fbdev buffer. It 
can make an educated guess though. Just as long as you don't change the 
fact that the fbdev buffer will be located at the beginning of the memory 
that is.

> > > and because
> > > it seems that directFB has only been tested on little endian machines
> > > (damn them !) and thus doesn't understand the problem with swapper on
> > > framebuffer access).
> > 
> > Actually people do use it on big-endian systems but since neither the 
> > mach64, ati128 or radeon drivers play with the swapper settings I can only 
> > assume that they haven't been tested very extensively.
> 
> You are wrong here, all of those 3 drivers do play with the swapper
> setting, they all 3 set the swapper based on the bit depth of the
> screen, so writing an image to offscreen memory with a different bit
> depth will be broken. See usage of SURFACE_CNTL in radeonfb for example.

This was about the DirectFB drivers.

One thing just popped to my head though. If in the future we are going to 
allow graphics cards to render to system memory, using the swapper will no 
longer work. I don't see any other solution that having the CPU perform 
the byte swapping.

-- 
Ville Syrjälä
syrjala@sci.fi
http://www.sci.fi/~syrjala/