Re: libdrm, memory manager

[Keith W. <ke...@tu...>]

Keith Whitwell wrote:
> Dave,
> 
> I'm starting to put some flesh on the bones of this thing, and I'm 
> wondering about some aspects of situating it in libdrm.
> 
> Specifically, things like initialization and dealing with 
> hardware-specific quirks.  As it stands, there's no way I know of to put 
> hardware-specific code into the libdrm userspace.
> 
> Consider the memory manager needs some sort of hook into hardware, say 
> to emit a fence for synchronization.  Currently that's done differently 
> on all each platform with some combination of device ioctls, numbers in 
> sareas, etc.
> 
> What isn't clear is how that can continue if the memory manager is in 
> libdrm - it could only work if each client of libdrm had that kludgy 
> mess of code available for each possible hardware platform and were able 
> to plug it into libdrm as callbacks.
> 
> Or perhaps if libdrm were to acquire the ability to load a sub-driver 
> for each piece of hardware, or had all of them built in?
> 
> Or finally, if things like setting and testing for fences were all to be 
> re-implemented hardware independently, using device-independent ioctls. 
>  Even then, for the fence example, you'd like to have a new field in the 
> device-independent part of the sarea so that you could identify some 
> expired fences without issuing an ioctl...
> 
> So the choices seem to be:
>     - all libdrm clients know about device-specific ioctls
>     - libdrm learns about device-specific ioctls (or grows a sub-driver 
> model)
>     - functionality required by libdrm is made available as 
> device-independent ioctls

Or
	- The memory manager code in libdrm is carefully designed to avoid 
referencing functionality that isn't already (or won't be) provided 
device-independently.

This actually might turn out to be possible.

Keith