locking memory ranges with the exa memory manager

[Alex Deucher]

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.

Alex

> Thomas
> 
> - --
> Thomas Winischhofer
> Vienna/Austria
> thomas AT winischhofer DOT net         *** http://www.winischhofer.net
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
> 
> iD8DBQFC+2BNzydIRAktyUcRArrGAJ9dgt/zqNNk/vi6VSlZb9RjI+A3LwCfUQ2a
> yYaRTxY5owS/yWCi9ygviJA=
> =r9En
> -----END PGP SIGNATURE-----
>