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
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 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
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 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 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
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
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.
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
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
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
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 the
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 the
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.
If
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 buffer
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 for
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
could
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 around
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-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
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..
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..
>
>
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..
On Wed, May 02, 2007 at 12:36:36AM +0200, Ingo Oeser wrote:
> On Tuesday 01 May 2007, Dave Airlie wrote:
> > > - what's with the /proc interface? Don't add new proc code for
> > > non-process related things. This should all go into sysfs
> > > somewhere. And yes, I know /proc/dri/ is
On Tuesday 01 May 2007, Dave Airlie wrote:
> > - what's with the /proc interface? Don't add new proc code for
> > non-process related things. This should all go into sysfs
> > somewhere. And yes, I know /proc/dri/ is there today, but don't add
> > new stuff please.
>
> Well we
On Tuesday 01 May 2007, Dave Airlie wrote:
- what's with the /proc interface? Don't add new proc code for
non-process related things. This should all go into sysfs
somewhere. And yes, I know /proc/dri/ is there today, but don't add
new stuff please.
Well we should move
On Wed, May 02, 2007 at 12:36:36AM +0200, Ingo Oeser wrote:
On Tuesday 01 May 2007, Dave Airlie wrote:
- what's with the /proc interface? Don't add new proc code for
non-process related things. This should all go into sysfs
somewhere. And yes, I know /proc/dri/ is there
Dave Airlie wrote:
Most likely in doxygen as that is what Mesa uses and the intersection
of developers is higher in that area, I'll take it as a task to try
and kerneldoc the drm at some stage..
- what's with the /proc interface? Don't add new proc code for
non-process related things.
On Tue, May 01, 2007 at 09:10:00AM +1000, Dave Airlie wrote:
> Okay this needs fixing, we do check most ioctls args, the main thing
> passed in are handles and these are all looked up in the hash table,
> it may not be so obvious, also most of the ioctls are probably going
> to end up root
A few easy and simple comments based on looking at this for 5 minutes:
- drop the typedefs. Yeah, they might be a drm thing, but we don't
need them here.
Okay I think in-kernel typedefs have to go, but we have a defined DRM
interface like it or not and I'd like to be consistent on the
A few easy and simple comments based on looking at this for 5 minutes:
- drop the typedefs. Yeah, they might be a drm thing, but we don't
need them here.
Okay I think in-kernel typedefs have to go, but we have a defined DRM
interface like it or not and I'd like to be consistent on the
On Tue, May 01, 2007 at 09:10:00AM +1000, Dave Airlie wrote:
Okay this needs fixing, we do check most ioctls args, the main thing
passed in are handles and these are all looked up in the hash table,
it may not be so obvious, also most of the ioctls are probably going
to end up root or
Dave Airlie wrote:
Most likely in doxygen as that is what Mesa uses and the intersection
of developers is higher in that area, I'll take it as a task to try
and kerneldoc the drm at some stage..
- what's with the /proc interface? Don't add new proc code for
non-process related things.
On Thu, Apr 26, 2007 at 04:55:14PM +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..
>
>
>
On Thu, Apr 26, 2007 at 04:55:14PM +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..
42 matches
Mail list logo
