[PATCH] drm: turn syncobj timeline support off by default

[Daniel Vetter]

On Tue, Apr 16, 2019 at 11:51 AM Lionel Landwerlin
<lionel.g.landwerlin at intel.com> wrote:
>
> On 15/04/2019 21:23, Dave Airlie wrote:
> > On Tue, 16 Apr 2019 at 06:05, Lionel Landwerlin
> > <lionel.g.landwerlin at intel.com> wrote:
> >> On 15/04/2019 20:52, Dave Airlie wrote:
> >>> On Tue, 16 Apr 2019 at 05:48, Lionel Landwerlin
> >>> <lionel.g.landwerlin at intel.com> wrote:
> >>>> Unfortunately userspace users of this API cannot be publicly disclosed
> >>>> yet so disable this stuff by default until all is revealed.
> >>> This begs the question how userspace is meant to know we support these?
> >>>
> >>> Is there a CAP for it? if not why not?
> >>>
> >>> Dave.
> >>>
> >> This comes with a submission path, so in i915 I've added a CAP.
> >>
> >> AMD seems to have a versioned interface.
> > I think we would do like we did for syncobjs, you have a generic cap
> > that the driver controls.
> >
> > The versioned interface won't be useful if we decide to backport a fix for this.

I guess amdgpu could then backport the version bump. Also, this is why
I don't like versioned uapi really. Either way we also need to hide
the amdgpu version bump until we've finalized the uapi and khr pushed
out the spec.

> Okay, but then it's not a global setting anymore :)
>
> Which is what was suggested on IRC.
>
>
> I'm fine with it regardless :)

I think global is good enough. If either i915 or amdgpu screwed up the
uapi enough that we can't backport the enabling patch, then maybe not
a good idea to do for either. Ofc this assumes the uapi as merged is
forward compatible already, i.e. new userspace has a way to figure out
whether timeline sync are support or not for a given driver.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch