[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAPj87rOZMLs3oQHm1vWaA3i_uLXQ59ZwV3Nkp5ArPp5NVGShEA@mail.gmail.com>
Date: Thu, 31 Mar 2016 11:56:54 +0100
From: Daniel Stone <daniel@...ishbar.org>
To: Inki Dae <inki.dae@...sung.com>
Cc: Rob Clark <robdclark@...il.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
Arve Hjønnevåg <arve@...roid.com>,
Daniel Vetter <daniel.vetter@...ll.ch>,
Riley Andrews <riandrews@...roid.com>,
Gustavo Padovan <gustavo.padovan@...labora.co.uk>,
John Harrison <John.C.Harrison@...el.com>
Subject: Re: [RFC 0/6] drm/fences: add in-fences to DRM
Hi Inki,
On 31 March 2016 at 11:05, Inki Dae <inki.dae@...sung.com> wrote:
> 2016년 03월 31일 18:35에 Daniel Stone 이(가) 쓴 글:
>> On 31 March 2016 at 08:45, Inki Dae <inki.dae@...sung.com> wrote:
>>> As of now, it seems that this wouldn't be optional but mandatory if explicit fence support is added to the atomic helper framework. This would definitely be duplication and it seems not clear enough even if one of them is just skipped in runtime.
>>
>> Drivers would have to opt in to explicit fencing support, and part of
>> that would be ensuring that the driver does not wait on implicit
>> fences when the user has requested explicit fencing be used.
>>
>
> Then, existing drivers would need additional works for explicit fencing support. This wouldn't be really what the drivers have to but should be handled with this patch series because this would affect exising device drivers which use implicit fencing.
Well, yes. Anyone implementing their own atomic commit would need to
ensure that the commit works properly for fences. The helpers could
also add it, but the helpers are not mandatory, and you are not
required to use every part of the helper to use one part of the
helper. There is no magic wand you can wave that instantly makes it
work for every driver.
Cheers,
Daniel
Powered by blists - more mailing lists