On Fri, Jun 8, 2012 at 3:56 PM, Erik Gilling wrote:
>> I guess my other thought is that implicit vs explicit is not
>> mutually exclusive, though I'd guess there'd be interesting
>> deadlocks to have to debug if both were in use _at the same
>> time_. :-)
>
> I think this is an approach worth inve
On Sat, Jun 9, 2012 at 12:22 AM, Erik Gilling wrote:
> The current linux graphics stack does not allow synchronization
> between the GPU and a camera/video decoder. ?When we've seen people
> try to support this behind the scenes, they get it wrong and introduce
> bugs that can take weeks to track
On Sat, Jun 9, 2012 at 12:22 AM, Erik Gilling wrote:
> The current linux graphics stack does not allow synchronization
> between the GPU and a camera/video decoder. When we've seen people
> try to support this behind the scenes, they get it wrong and introduce
> bugs that can take weeks to track
On Fri, Jun 8, 2012 at 3:56 PM, Erik Gilling wrote:
>> I guess my other thought is that implicit vs explicit is not
>> mutually exclusive, though I'd guess there'd be interesting
>> deadlocks to have to debug if both were in use _at the same
>> time_. :-)
>
> I think this is an approach worth inve
On Fri, Jun 08, 2012 at 01:56:05PM -0700, Erik Gilling wrote:
> On Thu, Jun 7, 2012 at 4:35 AM, Tom Cooksey wrote:
> > The alternate is to not associate sync objects with buffers and
> > have them be distinct entities, exposed to userspace. This gives
> > userpsace more power and flexibility and m
On Fri, Jun 8, 2012 at 2:42 PM, Daniel Vetter wrote:
>> I think this is an approach worth investigating. I'd like a way to
>> either opt out of implicit sync or have a way to check if a dma-buf
>> has an attached fence and detach it. Actually, that could work really
>> well. Consider:
>>
>> * Ea
On Thu, Jun 7, 2012 at 4:35 AM, Tom Cooksey wrote:
> The alternate is to not associate sync objects with buffers and
> have them be distinct entities, exposed to userspace. This gives
> userpsace more power and flexibility and might allow for use-cases
> which an implicit synchronization mechanism
On Fri, Jun 8, 2012 at 2:42 PM, Daniel Vetter wrote:
>> I think this is an approach worth investigating. ?I'd like a way to
>> either opt out of implicit sync or have a way to check if a dma-buf
>> has an attached fence and detach it. ?Actually, that could work really
>> well. Consider:
>>
>> * Ea
On Fri, Jun 08, 2012 at 01:56:05PM -0700, Erik Gilling wrote:
> On Thu, Jun 7, 2012 at 4:35 AM, Tom Cooksey wrote:
> > The alternate is to not associate sync objects with buffers and
> > have them be distinct entities, exposed to userspace. This gives
> > userpsace more power and flexibility and m
On Thu, Jun 7, 2012 at 4:35 AM, Tom Cooksey wrote:
> The alternate is to not associate sync objects with buffers and
> have them be distinct entities, exposed to userspace. This gives
> userpsace more power and flexibility and might allow for use-cases
> which an implicit synchronization mechanism
> >>>?The bigger issue is the previous point about how to deal
> >>> with cases where the CPU doesn't really need to get involved as an
> >>> intermediary.
> >>>
> >>> CPU fallback access to the buffer is the only legit case where we
> >>> need a standardized API to userspace (since CPU access is
> >>> The bigger issue is the previous point about how to deal
> >>> with cases where the CPU doesn't really need to get involved as an
> >>> intermediary.
> >>>
> >>> CPU fallback access to the buffer is the only legit case where we
> >>> need a standardized API to userspace (since CPU access is
On Wed, Jun 6, 2012 at 6:33 AM, John Reitan wrote:
>> But maybe instead of inventing something new, we can just use 'struct
>> kthread_work' instead of 'struct kds_callback' plus the two 'void *'s?
>> If the user needs some extra args they can embed 'struct
>> kthread_work' in their own struct an
> Sent: Monday, June 04, 2012 10:31 PM
> To: Tom Cooksey
> Cc: linaro-mm-...@lists.linaro.org; Pauli; dri-
> de...@lists.freedesktop.org
> Subject: Re: [Linaro-mm-sig] [RFC] Synchronizing access to buffers
> shared with dma-buf between drivers/devices
>
> Some comments inl
b Clark
> Sent: Monday, June 04, 2012 10:31 PM
> To: Tom Cooksey
> Cc: linaro-mm-sig at lists.linaro.org; Pauli; dri-
> devel at lists.freedesktop.org
> Subject: Re: [Linaro-mm-sig] [RFC] Synchronizing access to buffers
> shared with dma-buf between drivers/devices
>
> Some
On Wed, Jun 6, 2012 at 6:33 AM, John Reitan wrote:
>> But maybe instead of inventing something new, we can just use 'struct
>> kthread_work' instead of 'struct kds_callback' plus the two 'void *'s?
>> ?If the user needs some extra args they can embed 'struct
>> kthread_work' in their own struct an
Some comments inline.. at this stage mostly superficial issues about
how the API works, etc.. not had a chance to dig too much into the
implementation yet (although some of my comments about the API would
change those anyways).
Anyways, thanks for getting the ball rolling on this, and I think I
c
Some comments inline.. at this stage mostly superficial issues about
how the API works, etc.. not had a chance to dig too much into the
implementation yet (although some of my comments about the API would
change those anyways).
Anyways, thanks for getting the ball rolling on this, and I think I
c
> > There are multiple ways synchronization can be achieved,
> > fences/sync objects is one common approach, however we're
> > presenting a different approach. Personally, I quite like
> > fence sync objects, however we believe it requires a lot of
> > userspace interfaces to be changed to pass
On 25/05/12 14:08, Tom Cooksey wrote:
> Hi All,
>
> I realise it's been a while since this was last discussed, however I'd like
> to bring up kernel-side synchronization again. By kernel-side
> synchronization, I mean allowing multiple drivers/devices wanting to access
> the same buffer to do so wi
Hi All,
I realise it's been a while since this was last discussed, however I'd like
to bring up kernel-side synchronization again. By kernel-side
synchronization, I mean allowing multiple drivers/devices wanting to access
the same buffer to do so without bouncing up to userspace to resolve
depende
> > There are multiple ways synchronization can be achieved,
> > fences/sync objects is one common approach, however we're
> > presenting a different approach. Personally, I quite like
> > fence sync objects, however we believe it requires a lot of
> > userspace interfaces to be changed to pass
On 25/05/12 14:08, Tom Cooksey wrote:
Hi All,
I realise it's been a while since this was last discussed, however I'd like
to bring up kernel-side synchronization again. By kernel-side
synchronization, I mean allowing multiple drivers/devices wanting to access
the same buffer to do so without bou
Hi All,
I realise it's been a while since this was last discussed, however I'd like
to bring up kernel-side synchronization again. By kernel-side
synchronization, I mean allowing multiple drivers/devices wanting to access
the same buffer to do so without bouncing up to userspace to resolve
depende
24 matches
Mail list logo
