On Mon, Apr 4, 2016 at 11:41 AM, Rob Clark wrote:
> On Sun, Apr 3, 2016 at 8:14 PM, Inki Dae wrote:
>>
>> 2016ë
03ì 31ì¼ 23:10ì Rob Clark ì´(ê°) ì´ ê¸:
>>> On Thu, Mar 31, 2016 at 7:26 AM, Inki Dae wrote:
Hi Daniel,
2016-03-31 19:56 GMT+09:00 Daniel Stone :
> Hi Ink
On Sun, Apr 3, 2016 at 8:14 PM, Inki Dae wrote:
>
> 2016ë
03ì 31ì¼ 23:10ì Rob Clark ì´(ê°) ì´ ê¸:
>> On Thu, Mar 31, 2016 at 7:26 AM, Inki Dae wrote:
>>> Hi Daniel,
>>>
>>> 2016-03-31 19:56 GMT+09:00 Daniel Stone :
Hi Inki,
On 31 March 2016 at 11:05, Inki Dae wrote:
>>>
2016ë
03ì 31ì¼ 23:10ì Rob Clark ì´(ê°) ì´ ê¸:
> On Thu, Mar 31, 2016 at 7:26 AM, Inki Dae wrote:
>> Hi Daniel,
>>
>> 2016-03-31 19:56 GMT+09:00 Daniel Stone :
>>> Hi Inki,
>>>
>>> On 31 March 2016 at 11:05, Inki Dae wrote:
2016ë
03ì 31ì¼ 18:35ì Daniel Stone ì´(ê°) ì´ ê¸
2016-03-31 19:04 GMT+09:00 Daniel Vetter :
> On Thu, Mar 31, 2016 at 10:35:11AM +0100, Daniel Stone wrote:
>> Well, it has to be one or the other: mixing explicit and implicit,
>> defeats the purpose of using explicit fencing. So, when explicit
>> fencing is in use, implicit fences must be ignored.
Hi Daniel,
2016-03-31 19:56 GMT+09:00 Daniel Stone :
> Hi Inki,
>
> On 31 March 2016 at 11:05, Inki Dae wrote:
>> 2016ë
03ì 31ì¼ 18:35ì Daniel Stone ì´(ê°) ì´ ê¸:
>>> On 31 March 2016 at 08:45, Inki Dae wrote:
As of now, it seems that this wouldn't be optional but mandatory if
>
Hi Daniel,
2016ë
03ì 31ì¼ 18:35ì Daniel Stone ì´(ê°) ì´ ê¸:
> Hi Inki,
>
> On 31 March 2016 at 08:45, Inki Dae wrote:
>> 2016ë
03ì 29ì¼ 22:23ì Rob Clark ì´(ê°) ì´ ê¸:
>>> On Mon, Mar 28, 2016 at 10:18 PM, Inki Dae wrote:
In addition, I wonder how explicit and implicit
2016ë
03ì 29ì¼ 22:23ì Rob Clark ì´(ê°) ì´ ê¸:
> On Mon, Mar 28, 2016 at 10:18 PM, Inki Dae wrote:
>>
>> In addition, I wonder how explicit and implicit fences could coexist
>> together.
>> Rob said,
>> "Implicit sync ofc remains the default, but userspace could opt-in to
>> explicit
Hi Inki,
On 31 March 2016 at 12:26, Inki Dae wrote:
> 2016-03-31 19:56 GMT+09:00 Daniel Stone :
>> On 31 March 2016 at 11:05, Inki Dae wrote:
>>> Then, existing drivers would need additional works for explicit fencing
>>> support. This wouldn't be really what the drivers have to but should be
On Thu, Mar 31, 2016 at 10:35:11AM +0100, Daniel Stone wrote:
> Well, it has to be one or the other: mixing explicit and implicit,
> defeats the purpose of using explicit fencing. So, when explicit
> fencing is in use, implicit fences must be ignored.
You can mix it, if you're careful. CrOS wants
Hi Inki,
On 31 March 2016 at 11:05, Inki Dae wrote:
> 2016ë
03ì 31ì¼ 18:35ì Daniel Stone ì´(ê°) ì´ ê¸:
>> On 31 March 2016 at 08:45, Inki Dae wrote:
>>> As of now, it seems that this wouldn't be optional but mandatory if
>>> explicit fence support is added to the atomic helper framew
Hi Inki,
On 31 March 2016 at 08:45, Inki Dae wrote:
> 2016ë
03ì 29ì¼ 22:23ì Rob Clark ì´(ê°) ì´ ê¸:
>> On Mon, Mar 28, 2016 at 10:18 PM, Inki Dae wrote:
>>> In addition, I wonder how explicit and implicit fences could coexist
>>> together.
>>> Rob said,
>>> "Implicit sync ofc remains
On Thu, Mar 31, 2016 at 7:26 AM, Inki Dae wrote:
> Hi Daniel,
>
> 2016-03-31 19:56 GMT+09:00 Daniel Stone :
>> Hi Inki,
>>
>> On 31 March 2016 at 11:05, Inki Dae wrote:
>>> 2016ë
03ì 31ì¼ 18:35ì Daniel Stone ì´(ê°) ì´ ê¸:
On 31 March 2016 at 08:45, Inki Dae wrote:
> As of now
Hi Daniel,
2016ë
03ì 28ì¼ 22:26ì Daniel Stone ì´(ê°) ì´ ê¸:
> Hi Inki,
>
> On 28 March 2016 at 02:26, Inki Dae wrote:
>> 2016ë
03ì 25ì¼ 21:10ì Daniel Stone ì´(ê°) ì´ ê¸:
>>> Second, really. Vulkan avoids implicit sync entirely, and exposes
>>> fence-like primitives througho
On Mon, Mar 28, 2016 at 10:18 PM, Inki Dae wrote:
>
> In addition, I wonder how explicit and implicit fences could coexist together.
> Rob said,
> "Implicit sync ofc remains the default, but userspace could opt-in to
> explicit sync instead"
>
> This would mean that if we use explicit sync for us
Hi Inki,
On 28 March 2016 at 02:26, Inki Dae wrote:
> 2016ë
03ì 25ì¼ 21:10ì Daniel Stone ì´(ê°) ì´ ê¸:
>> Second, really. Vulkan avoids implicit sync entirely, and exposes
>> fence-like primitives throughout its whole API. These include being
>> able to pass prerequisite fences for dis
Hi Rob and Daniel,
2016ë
03ì 25ì¼ 21:10ì Daniel Stone ì´(ê°) ì´ ê¸:
> Hi all,
>
> On 25 March 2016 at 11:58, Rob Clark wrote:
>> On Thu, Mar 24, 2016 at 7:49 PM, Inki Dae wrote:
>>> It's definitely different case. This tries to add new user-space interfaces
>>> to expose fences to u
Hi all,
On 25 March 2016 at 11:58, Rob Clark wrote:
> On Thu, Mar 24, 2016 at 7:49 PM, Inki Dae wrote:
>> It's definitely different case. This tries to add new user-space interfaces
>> to expose fences to user-space. At least, implicit interfaces are embedded
>> into drivers.
>> So I'd like to
2016ë
03ì 25ì¼ 00:40ì Rob Clark ì´(ê°) ì´ ê¸:
> On Thu, Mar 24, 2016 at 4:18 AM, Inki Dae wrote:
>> Hi,
>>
>> 2016ë
03ì 24ì¼ 03:47ì Gustavo Padovan ì´(ê°) ì´ ê¸:
>>> From: Gustavo Padovan
>>>
>>> Hi,
>>>
>>> This is a first proposal to discuss the addition of in-fences sup
Hi Guestavo,
2016ë
03ì 24ì¼ 23:39ì Gustavo Padovan ì´(ê°) ì´ ê¸:
> Hi Inki,
>
> 2016-03-24 Inki Dae :
>
>> Hi,
>>
>> 2016ë
03ì 24ì¼ 03:47ì Gustavo Padovan ì´(ê°) ì´ ê¸:
>>> From: Gustavo Padovan
>>>
>>> Hi,
>>>
>>> This is a first proposal to discuss the addition of in-fen
On Thu, Mar 24, 2016 at 7:49 PM, Inki Dae wrote:
>
>
> 2016ë
03ì 25ì¼ 00:40ì Rob Clark ì´(ê°) ì´ ê¸:
>> On Thu, Mar 24, 2016 at 4:18 AM, Inki Dae wrote:
>>> Hi,
>>>
>>> 2016ë
03ì 24ì¼ 03:47ì Gustavo Padovan ì´(ê°) ì´ ê¸:
From: Gustavo Padovan
Hi,
Th
Hi,
2016ë
03ì 24ì¼ 03:47ì Gustavo Padovan ì´(ê°) ì´ ê¸:
> From: Gustavo Padovan
>
> Hi,
>
> This is a first proposal to discuss the addition of in-fences support
> to DRM. It adds a new struct to fence.c to abstract the use of sync_file
> in DRM drivers. The new struct fence_collecti
this patch series reminder me my another thoughts recently, But I don't
know if my idea is appropriated:
sometimes one person could only need wait any of these fence array, but
it doesn't want to call fence_wait_any since which will block its
thread. if there is a mechanism let the person regist
On Thu, Mar 24, 2016 at 4:18 AM, Inki Dae wrote:
> Hi,
>
> 2016ë
03ì 24ì¼ 03:47ì Gustavo Padovan ì´(ê°) ì´ ê¸:
>> From: Gustavo Padovan
>>
>> Hi,
>>
>> This is a first proposal to discuss the addition of in-fences support
>> to DRM. It adds a new struct to fence.c to abstract the use o
Hi Inki,
2016-03-24 Inki Dae :
> Hi,
>
> 2016ë
03ì 24ì¼ 03:47ì Gustavo Padovan ì´(ê°) ì´ ê¸:
> > From: Gustavo Padovan
> >
> > Hi,
> >
> > This is a first proposal to discuss the addition of in-fences support
> > to DRM. It adds a new struct to fence.c to abstract the use of sync_fil
Hi Maarten,
2016-03-24 Maarten Lankhorst :
> Hey,
>
> Op 23-03-16 om 19:47 schreef Gustavo Padovan:
> > From: Gustavo Padovan
> >
> > Hi,
> >
> > This is a first proposal to discuss the addition of in-fences support
> > to DRM. It adds a new struct to fence.c to abstract the use of sync_file
>
Hey,
Op 23-03-16 om 19:47 schreef Gustavo Padovan:
> From: Gustavo Padovan
>
> Hi,
>
> This is a first proposal to discuss the addition of in-fences support
> to DRM. It adds a new struct to fence.c to abstract the use of sync_file
> in DRM drivers. The new struct fence_collection contains a arra
From: Gustavo Padovan
Hi,
This is a first proposal to discuss the addition of in-fences support
to DRM. It adds a new struct to fence.c to abstract the use of sync_file
in DRM drivers. The new struct fence_collection contains a array with all
fences that a atomic commit needs to wait on
/**
*
27 matches
Mail list logo