Re: radeon, apertures & memory mapping

On Sun, 2005-03-13 at 10:22 +0200, Ville Syrjälä wrote:

quoted

 - We only really need to bother about CPU access for the framebuffer
itself (and possibly the cursor). That is normal non-accelerated fbdev
operations an mmap'ing of the framebuffer in user space. This is not
really a problem if that is limited to some part of vram. It puts a
small constraint on the allocation of video memory: the framebuffer has
to be near the beginning.

It will limit DirectFB to access only CONFIG_APER_SIZE. DirectFB needs CPU 
access to offscreen memory for software fallbacks and explicit user 
access. Any other compositing window system would need to do the same. If 
the video memory manager ever gets done then it shouldn't be a major 
problem because the kernel could blit the data to/from the inaccesible 
part without the application even realizing it. Although direct access 
might be useful in that case also since it could reduce pressure on the 
GART address space.

Yes, that means direct access will be limited to half of the vram on
some setups and not on others, depending on how the BIOS sets up the
card. Is this a real issue ? I don't think so personally. Especially
since directfb could make use of DRM to do DMA blits either from main
memory or from AGP space... Or things can be put in accessible space,
and blitted elsewhere using the accelerator.

That "half" of vram is plenty enough for a framebuffer (and more). it's
only an issue when you start doing very large offscreen surfaces. Do you
have much usage of those without DMA ?
 

quoted

But my opinion is that a mode switch will
pretty much always invalidate everything that is cached in video memory,

I don't see any reason for such a sledgehammer approach. If the new mode 
doesn't overlap with any offscreen data then there is no need to 
invalidate anything.

Depends how smart the memory manager is.

Ben.