locking memory ranges with the exa memory manager

Thomas Winischhofer thomas at winischhofer.net
Thu Aug 11 07:27:25 PDT 2005

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 -----------------------------------------------------------------------------
>>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

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


- --
Thomas Winischhofer
thomas AT winischhofer DOT net	       *** http://www.winischhofer.net

Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org


More information about the xorg mailing list