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. -- [email protected]
Attachment:
signature.asc
Description: This is a digitally signed message part
- Follow-Ups:
- Re: [RFC] [PATCH] DRM TTM Memory Manager patch
- From: Keith Whitwell <[email protected]>
- Re: [RFC] [PATCH] DRM TTM Memory Manager patch
- References:
- [RFC] [PATCH] DRM TTM Memory Manager patch
- From: "Dave Airlie" <[email protected]>
- Re: [RFC] [PATCH] DRM TTM Memory Manager patch
- From: Eric Anholt <[email protected]>
- Re: [RFC] [PATCH] DRM TTM Memory Manager patch
- From: Thomas Hellström <[email protected]>
- Re: [RFC] [PATCH] DRM TTM Memory Manager patch
- From: Keith Packard <[email protected]>
- Re: [RFC] [PATCH] DRM TTM Memory Manager patch
- From: Thomas Hellström <[email protected]>
- [RFC] [PATCH] DRM TTM Memory Manager patch
- Prev by Date: Re: [RFC PATCH 1/3] Replace paravirt_probe with "platform type" boot header field
- Next by Date: Re: [RFC PATCH 3/3] boot bzImages under paravirt
- Previous by thread: Re: [RFC] [PATCH] DRM TTM Memory Manager patch
- Next by thread: Re: [RFC] [PATCH] DRM TTM Memory Manager patch
- Index(es):