On Mon, Apr 4, 2016 at 11:41 AM, Rob Clark <robdclark at gmail.com> wrote: > On Sun, Apr 3, 2016 at 8:14 PM, Inki Dae <inki.dae at samsung.com> wrote: >> >> 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? > > https://git.kernel.org/cgit/linux/kernel/git/padovan/linux.git/commit/?h=fences&id=4e0db925ff6dcbd5834ab37f9e6ce27301cc3b2e > > Note that on the in-fence side of things, the current proposal from > Gustavo is to have a new property, rather than separate flag and > additional args to atomic ioctl. But end result would be the same. > > Keep in mind, this is not merged yet, so things could change. > Compared to his current patchset[1] I think we at least need to add a > driver feature flag. > > [1] > https://git.kernel.org/cgit/linux/kernel/git/padovan/linux.git/log/?h=fences > >>> 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? > > I think we need to add a flag to driver_features (ie. > DRIVER_EXPLICIT_FENCE or something like that)
well, I should say, there is also the possibility that we could handle fences entirely in drm core. Although it would mean that atomic-helper would need to know about the driver's workqueue for blocking on the fence(s) for _NONBLOCK commits.. BR, -R > BR, > -R > >> 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 >>>
