locking memory ranges with the exa memory manager

[Eric Anholt]

On Thu, 2005-08-11 at 10:58 -0400, Alex Deucher wrote:
> On 8/11/05, Thomas Winischhofer <thomas at winischhofer.net> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > Alex Deucher wrote:
> > > On 8/10/05, Thomas Winischhofer <thomas at winischhofer.net> wrote:
> > >
> > > Alex Deucher wrote:
> > >
> > >>Unless I'm missing something, I think exa needs a function to set the
> > >>number and size of offscreen memory pools.  In porting exa to savage,
> > >>I'm having a hard time preventing the exa memory manager from using
> > >>the back/depth/texture buffers, etc.  XAA allows you to pass a boxrect
> > >>to the memory manager to specify the size of the offscreen memory.
> > >>how would one do that with exa?  All I can see right now is limiting
> > >>the size of the videoram you pass to exa.
> > >
> > >>For example on savage the memory is laid out like this:
> > >
> > >>start -----------------------------------------------------------------------------
> > >>end
> > >>front | offscreen | back | depth | textures | BCI queue | hwcursor
> > >
> > >
> > >>How do I limit the exa memory manager to just the offscreen portion?
> > >
> > >
> > > Erm... unless I totally misunderstood your question or the whole EXA
> > > memory manager concept, isn't that was
> > > EXADriverPtr->card.offscreenBase/memorySize is for? (Provided that you
> > > pre-allocate back, depth, textures, BCI queue and hwcursor.)
> > >
> > > start ---------------------------------------------------------- end
> > > front | offscreen | back | depth | textures | BCI queue | hwcursor
> > > |     |           |
> > > memoryBase        |
> > >       |           |
> > >   offscreenBase   |
> > >                   |
> > >              memorySize
> > >
> > > (Hope you view this with a fixed width font)
> > >
> > > I don't see any reason whatsoever to specify the *real* video memory
> > > size in card.memorySize.
> > >
> > >
> > >
> > >> Thanks Thomas, that's I ended up doing.
> > >
> > >> However, what about if offscreen memory is not contiguous with the
> > >> front buffer?  how about:
> > >
> > >> start ------------------------------- end
> > >> front | back | depth | textures | offscreen | etc.
> > >> | fbstart
> > >>                                           | offscreen base
> > >
> > >>                                                        | memory size?
> > >
> > >> I guess most cards will be contiguous since that's how XAA worked, but
> > >> I can defintiely see cases wehre you would want multiple sparse
> > >> offscreen pools.
> > >
> > 
> > The offscreen memory manager only looks at card.offScreenBase and
> > card.memorySize.
> > 
> > In fact, the card.offscreenBase holds an offset (not a pointer),
> > relative to card.memoryBase. So if your front buffer and offscreen
> > memory are not contiguous, I don't think that would matter.
> > card.memoryBase should point to the framebuffer (front buffer's virtual
> > address), and the offscreenBase should be relative to that. If there is
> > a "hole" in between, why should that matter? (given that exa won't issue
> > blits into/from the front buffer beyond the dimensions of the virtual
> > screen)
> > 
> 
> Thanks Thomas that definitely clarifies things for me.  I didn't
> realize exa has access to the virtual size.  So for my own
> understanding:
> 
> memoryBase is basically the start address of the viewable portion of
> videoram.   exa knows the limits of the viewable buffer from the
> pScrn->virtualX and Y.  I assume viewable area pitch requirements are
> handled but the card.align variables.  What if offscreen memory was
> below the front buffer?  I suppose offscreen base would have a
> negative offset?
> 
> offscreenBase is the offset relative to memoryBase of offscreen memory.
> 
> memorySize marks the end of offscreen memory.  This does not influence
> access to the fornt buffer.

exa actually doesn't care about the limits of the viewable buffer or the
pitch.  The screen pixmap's pointer should have been set by the generic
code that mapped the framebuffer, iirc.  If you've got pitch
requirements on your visible screen (for example, for acceleration, or
tiling requirements), it's your responsibility.  Since your driver has
XAA history, it's probably already taking care of that elsewhere, and
the screen pixmap should be reflecting those pitch changes.

Currently, the offscreen allocator allocates within memory ranges from
(memoryBase + offScreenBase) to (memoryBase + memorySize).  Your
memoryBase should point to the beginning of framebuffer memory.  Adjust
your offScreenBase and memorySize to get the allocator to point to
whatever region you want it to, probably the largest one.  I'm actually
wondering if there is any case where the driver doesn't stick its static
things at the start and end of framebuffer memory, i.e. why people are
so worried about this simple system for now.

It would be nice to support multiple ranges, though, since a lot of
cards can probably treat agp space basically the same as framebuffer.
However, that gets into more complicated migration questions that we
haven't dealt with in exa yet.

-- 
Eric Anholt                                     eta at lclark.edu
http://people.freebsd.org/~anholt/              anholt at FreeBSD.org