On 13 April 2017 at 08:34, Chris Wilson wrote:
> On Thu, Apr 13, 2017 at 07:41:28AM +1000, Dave Airlie wrote:
>> >
>> > The problem, as I see it, is that you are taking functionality away from
>> > sync_file. If you are wrapping them up inside a sync_file, we have a
>> > fair expectation that our
On Thu, Apr 13, 2017 at 07:41:28AM +1000, Dave Airlie wrote:
> >
> > The problem, as I see it, is that you are taking functionality away from
> > sync_file. If you are wrapping them up inside a sync_file, we have a
> > fair expectation that our code to handle sync_files will continue to
> > work.
>
>
> The problem, as I see it, is that you are taking functionality away from
> sync_file. If you are wrapping them up inside a sync_file, we have a
> fair expectation that our code to handle sync_files will continue to
> work.
What code? there is no code existing that should be sharing sync object
On Thu, Apr 13, 2017 at 06:51:17AM +1000, Dave Airlie wrote:
> On 13 April 2017 at 06:39, Chris Wilson wrote:
> > On Wed, Apr 12, 2017 at 09:01:32PM +0100, Chris Wilson wrote:
> >> On Thu, Apr 13, 2017 at 05:05:27AM +1000, Dave Airlie wrote:
> >> > >>
> >> > >> Not sure what the best semantics are
On 13 April 2017 at 06:39, Chris Wilson wrote:
> On Wed, Apr 12, 2017 at 09:01:32PM +0100, Chris Wilson wrote:
>> On Thu, Apr 13, 2017 at 05:05:27AM +1000, Dave Airlie wrote:
>> > >>
>> > >> Not sure what the best semantics are there, any opinions on barring
>> > >> wakeups/polling on semaphore sy
On Wed, Apr 12, 2017 at 09:01:32PM +0100, Chris Wilson wrote:
> On Thu, Apr 13, 2017 at 05:05:27AM +1000, Dave Airlie wrote:
> > >>
> > >> Not sure what the best semantics are there, any opinions on barring
> > >> wakeups/polling on semaphore sync_files, and just punting this
> > >> until we need i
On Thu, Apr 13, 2017 at 05:05:27AM +1000, Dave Airlie wrote:
> >>
> >> Not sure what the best semantics are there, any opinions on barring
> >> wakeups/polling on semaphore sync_files, and just punting this
> >> until we need it.
> >
> > I think getting it right now will make writing sw_sync-esque
>>
>> Not sure what the best semantics are there, any opinions on barring
>> wakeups/polling on semaphore sync_files, and just punting this
>> until we need it.
>
> I think getting it right now will make writing sw_sync-esque (i.e. cpu)
> tests easier and more complete.
I just don't have any use c
On Wed, Apr 12, 2017 at 12:36:37PM +1000, Dave Airlie wrote:
> On 11 April 2017 at 17:50, Chris Wilson wrote:
> > On Tue, Apr 11, 2017 at 01:22:17PM +1000, Dave Airlie wrote:
> >> From: Dave Airlie
> >>
> >> This object can be used to implement the Vulkan semaphores.
> >>
> >> The object behaviou
From: Dave Airlie
This object can be used to implement the Vulkan semaphores.
The object behaviour differs from fence, in that you can
replace the underlying fence, and you cannot merge semaphores.
v2: change replace fence API to have a return value,
don't allow polling on semaphore objects,
do
On 11 April 2017 at 17:50, Chris Wilson wrote:
> On Tue, Apr 11, 2017 at 01:22:17PM +1000, Dave Airlie wrote:
>> From: Dave Airlie
>>
>> This object can be used to implement the Vulkan semaphores.
>>
>> The object behaviour differs from fence, in that you can
>> replace the underlying fence, and
On Tue, Apr 11, 2017 at 01:22:17PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> This object can be used to implement the Vulkan semaphores.
>
> The object behaviour differs from fence, in that you can
> replace the underlying fence, and you cannot merge semaphores.
>
> Signed-off-by: Dave
From: Dave Airlie
This object can be used to implement the Vulkan semaphores.
The object behaviour differs from fence, in that you can
replace the underlying fence, and you cannot merge semaphores.
Signed-off-by: Dave Airlie
---
drivers/dma-buf/sync_file.c| 36
On Tue, Apr 04, 2017 at 12:52:32PM +0100, Chris Wilson wrote:
> On Tue, Apr 04, 2017 at 02:27:30PM +1000, Dave Airlie wrote:
> > +struct dma_fence *sync_file_replace_fence(struct sync_file *sync_file,
> > + struct dma_fence *fence)
> > +{
> > + struct dma_fence
On Tue, Apr 04, 2017 at 02:27:30PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> This object can be used to implement the Vulkan semaphores.
>
> The object behaviour differs from fence, in that you can
> replace the underlying fence, and you cannot merge semaphores.
>
> Signed-off-by: Dave
On Tue, Apr 04, 2017 at 02:27:30PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> This object can be used to implement the Vulkan semaphores.
>
> The object behaviour differs from fence, in that you can
> replace the underlying fence, and you cannot merge semaphores.
>
> Signed-off-by: Dave
From: Dave Airlie
This object can be used to implement the Vulkan semaphores.
The object behaviour differs from fence, in that you can
replace the underlying fence, and you cannot merge semaphores.
Signed-off-by: Dave Airlie
---
drivers/dma-buf/sync_file.c| 36
17 matches
Mail list logo
