On Thu, Mar 31, 2016 at 7:26 AM, Inki Dae <daeinki at gmail.com> wrote: > Hi Daniel, > > 2016-03-31 19:56 GMT+09:00 Daniel Stone <daniel at fooishbar.org>: >> Hi Inki, >> >> On 31 March 2016 at 11:05, Inki Dae <inki.dae at samsung.com> wrote: >>> 2016ë 03ì 31ì¼ 18:35ì Daniel Stone ì´(ê°) ì´ ê¸: >>>> On 31 March 2016 at 08:45, Inki Dae <inki.dae at samsung.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 > > I meant there are already several DRM drivers which work properly for > implicit fence. So if atomic helper framework of DRM core is > considered only for the explicit fence, then fencing operation would > affect the existing DRM drivers. So I hope this trying could consider > existing implicit fence users. >
Note that there would be a new flag on the atomic ioctl to request explicit fencing, and with an old kernel or a driver that does not support it, the ioctl would be rejected and an error returned. The atomic/kms framework would of course continue to support implicit fencing. And an explicit-fencing userspace would require a sufficiently new kernel and possibly some minor driver support (above and beyond 'struct fence' conversion). BR, -R
