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
16 matches
Mail list logo
