[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1178251621.27028.9.camel@neko.keithp.com>
Date: Thu, 03 May 2007 21:07:01 -0700
From: Keith Packard <keithp@...thp.com>
To: Thomas Hellström <thomas@...gstengraphics.com>
Cc: keithp@...thp.com, Eric Anholt <eric@...olt.net>,
dri-devel@...ts.sourceforge.net, Dave Airlie <airlied@...il.com>,
Linux Kernel <linux-kernel@...r.kernel.org>,
Jesse Barnes <jbarnes@...tuousgeek.org>
Subject: Re: [RFC] [PATCH] DRM TTM Memory Manager patch
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.
--
keith.packard@...el.com
Download attachment "signature.asc" of type "application/pgp-signature" (190 bytes)
Powered by blists - more mailing lists