On Thu, 2007-05-03 at 01:01 +0200, Thomas Hellström wrote:
> It might be possible to find schemes that work around this. One way
> could possibly be to have a buffer mapping -and validate order for
> shared buffers.
If mapping never blocks on anything other than the fence, then there
isn't any dead lock possibility. What this says is that ordering of
rendering between clients is *not DRMs problem*. I think that's a good
solution though; I want to let multiple apps work on DRM-able memory
with their own CPU without contention.
I don't recall if Eric layed out the proposed rules, but:
1) Map never blocks on map. Clients interested in dealing with this
are on their own.
2) Submit blocks on map. You must unmap all buffers before submitting
them. Doing the relocations in the kernel makes this all possible.
3) Map blocks on the fence from submit. We can play with pending the
flush until the app asks for the buffer back, or we can play with
figuring out when flushes are useful automatically. Doesn't matter
if the policy is in the kernel.
I'm interested in making deadlock avoidence trivial and eliminating any
map-map contention.
--
[email protected]
Attachment:
signature.asc
Description: This is a digitally signed message part
- Follow-Ups:
- Re: [RFC] [PATCH] DRM TTM Memory Manager patch
- From: Thomas Hellström <[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]>
- [RFC] [PATCH] DRM TTM Memory Manager patch
- Prev by Date: Re: [PATCH 5/5] ext4: write support for preallocated blocks/extents
- Next by Date: Re: Remove constructor from buffer_head
- Previous by thread: Re: [RFC] [PATCH] DRM TTM Memory Manager patch
- Next by thread: Re: [RFC] [PATCH] DRM TTM Memory Manager patch
- Index(es):
 |