Keith Packard wrote:
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
On 5/4/07, Thomas Hellström [EMAIL PROTECTED] wrote:
Keith Packard wrote:
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.
On 5/4/07, Jerome Glisse [EMAIL PROTECTED] wrote:
On 5/4/07, Thomas Hellström [EMAIL PROTECTED] wrote:
Keith Packard wrote:
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
Jerome Glisse wrote:
On 5/4/07, Thomas Hellström [EMAIL PROTECTED] wrote:
Keith Packard wrote:
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
On 5/4/07, Thomas Hellström [EMAIL PROTECTED] wrote:
Jerome Glisse wrote:
On 5/4/07, Thomas Hellström [EMAIL PROTECTED] wrote:
Keith Packard wrote:
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
Jerome Glisse wrote:
On 5/4/07, Thomas Hellström [EMAIL PROTECTED] wrote:
Jerome Glisse wrote:
On 5/4/07, Thomas Hellström [EMAIL PROTECTED] wrote:
Keith Packard wrote:
On Thu, 2007-05-03 at 01:01 +0200, Thomas Hellström wrote:
It might be possible to find schemes that work
On 5/4/07, Thomas Hellström [EMAIL PROTECTED] wrote:
I was actually referring to an example where two clients need to have a
buffer mapped and access it at exactly the same time.
If there is such a situation, we have no other choice than to drop the
buffer locking on map. If there isn't we can
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
On Fri, 2007-05-04 at 11:40 +0200, Jerome Glisse wrote:
On a side note i think this scheme also fit well with gpu having
several context and which doesn't need big validation (read
nv gpu).
Yeah, I want to make sure we have a simple model that supports
multi-context hardware while also
On Fri, 2007-05-04 at 14:32 +0200, Thomas Hellström wrote:
If there isn't we can at least consider other
alternatives that resolve the deadlock issue but that also will help
clients synchronize and keep data coherent.
If clients want coherence, they're welcome to implement their own
Keith Packard wrote:
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
On Fri, 2007-05-04 at 16:57 +0100, Keith Whitwell wrote:
That's a special case of a the general problem of what do you do when a
client submits any validation list that can't be satisfied. Failing to
render isn't really an option, either the client or the memory manager
has to either
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
On Thu, 2007-04-26 at 16:55 +1000, Dave Airlie wrote:
Hi,
The patch is too big to fit on the list and I've no idea how we could
break it down further, it just happens to be a lot of new code..
Eric Anholt wrote:
On Thu, 2007-04-26 at 16:55 +1000, Dave Airlie wrote:
Hi,
The patch is too big to fit on the list and I've no idea how we could
break it down further, it just happens to be a lot of new code..
15 matches
Mail list logo
