2016ë 03ì 31ì¼ 23:10ì Rob Clark ì´(ê°) ì´ ê¸: > 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
What is the new flag? And Where I could find the new flag? > 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 I couldn't find where such exceptions are considered. And as of now, I think implicit fence is implemented by drivers so hided from drm core framework. So how atomic/kms framework knows whether explicit or implicit fence is supported by driver? Otherwise, you mean such things are TODO in the future? There may be some logic I don't understand yet. Thanks, Inki Dae > 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 > _______________________________________________ > dri-devel mailing list > dri-devel at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel >
