locking memory ranges with the exa memory manager

[Thomas Winischhofer]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jesse Barnes wrote:
> On Wednesday, August 10, 2005 6:00 pm, Thomas Winischhofer 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.
> 
> 
> Sure, but this is a very inflexible approach.  If we could just tell EXA 
> about different memory ranges, or better yet, implement the callbacks 
> that Michael described in the original EXA announcement thread, it 
> would be much easier to port EXA into current drivers, which tend to do 
> their own memory management...

I was merely talking about the current implementation. As regards
improvments, just go for it... I agree with all you say.


- --
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+v8MzydIRAktyUcRApEVAJ9BgtdxP5Si5jRIlsrCoTFmhAoMYACfTL1u
xyPy2ryMBbxZ5CIhdNy87io=
=ZqD9
-----END PGP SIGNATURE-----