Jesse Barnes wrote:
>On Saturday, March 03, 2007, Thomas Hellström wrote:
>
>
>>Hi!
>>
>>There's a document available describing the design philosophy behind the
>>DRM Memory manager at
>>http://www.tungstengraphics.com/mm.pdf
>>There's no API description yet, but hopefully I'll have time to write
>>that up at some point.
>>
>>I've also put a link on the DRI documentation page
>>http://dri.freedesktop.org/wiki/Documentation
>>
>>
>
>Cool stuff. The document does a good job of describing the issues with
>video memory management, but while I was reading it I thought of a few
>questions... you mention that 'fences' are required to unpin buffers
>after the GPU is done with them, but aren't the buffers really locked
>after validation until the fence completes? I.e. would describing the
>buffers as 'locked by the GPU' make sense or can buffers be evicted after
>validation but before the GPU touches them?
>
>
You're right.
In the current implementation, a buffer that is validated ends up on an
"unfenced" list, and
cannot be evicted unless there is an emergency.
The calling process then issues the GPU commands, and finally calls a
"fence all unfenced" ioctl, which associates the buffers with a fence
and places them on the relevant LRU lists. Then the buffers can be
referred to as "Locked by the GPU" until the fence signals, as you mention.
All this should be done while the calling process holds the hardware
lock, since it needs to be an atomic operation, and probably the device
specific driver should really implement a single "schedule batch" IOCTL
for the whole process, to make it more efficient and secure.
When validating a buffer, it's possible to add a hint to make it go the
relevant LRU list directly, instead of to the unfenced list. Such a
buffer can, in principle, be immediately evicted.
>Also, I like what you had to say about sub-page allocation, I've been
>guessing that some sort of slab allocator would be necessary on the
>userspace side for managing small chunks of data (icons, chunks of text,
>small textures, etc.); how far along is the Mesa code you mention? Have
>you done any analysis of object sizes under different workloads?
>
>
>
No. The Mesa code just implements hooks for whatever allocation scheme
("pool") you like. The only sub-allocator implemented currently is a
pool of fixed-size batch buffers, and there is really no performance
analysis done on it. All other small objects currently gets a drm buffer
of their own. Room for improvement.
We should probably, in the end, have a small number of sub-allocator
implementations that the driver can choose from: A slab allocator (fast
and avoids fragmentation) and probably also a standard allocator
(saves space).
>Thanks,
>Jesse
>
>
Regards,
Thomas
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
