Re: [RFC] [PATCH] DRM TTM Memory Manager patch

[Keith Packard <keithp@keithp.com>]

[-- Attachment #1: Type: text/plain, Size: 1936 bytes --]

On Fri, 2007-05-04 at 10:07 +0200, Thomas Hellström wrote:
>  
> It's rare to have two clients access the same buffer at the same time. 
> In what situation will this occur?

Right, what I'm trying to avoid is having any contention for
applications *not* sharing the same objects. 

If there is any locking for mapping, we can either attempt to define a
locking order, or we can have a single global lock. The former leaves us
prone to deadlocks, the latter eliminates the ability for un-contended
parallel access.

>     * It will encourage different DRI clients to simultaneously access
>       the same buffer.

Sure. Separate 'DRI' from 'GL' and this may be a sensible plan. If you
want to prevent this *that's not DRI's problem*.

>     * Inter-client and GPU data coherence can be guaranteed if we issue
>       a mb() / write-combining flush with the unmap operation (which,
>       BTW, I'm not sure is done today). Otherwise it is up to the
>       clients, and very easy to forget.

CPU-GPU coherence is ensured by the mutual exclusion between mapping and
submitting. You may either have data available to the CPU or to the GPU.
I think that's a basic requirement for any solution in this space.
Keying the submit and map as to whether writing will occur means that
appropriate flushing and fencing can be automatically applied within the
kernel.

> OTOH, letting DRM resolve the deadlock by unmapping and remapping shared 
> buffers in the correct order might not be the best one either. It will 
> certainly mean some CPU overhead and what if we have to do the same with 
> buffer validation? (Yes for some operations with thousands and thousands 
> of relocations, the user space validation might need to stay).

I do not want to do relocations in user space. I don't see why doing
thousands of these requires moving this operation out of the kernel.

-- 
keith.packard@intel.com

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]