locking memory ranges with the exa memory manager
Alex Deucher
alexdeucher at gmail.com
Thu Aug 11 07:58:56 PDT 2005
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-----
>
More information about the xorg
mailing list