locking memory ranges with the exa memory manager

[Thomas Winischhofer]

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

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