On Tue, Apr 16, 2019 at 11:51 AM Lionel Landwerlin <[email protected]> wrote: > > On 15/04/2019 21:23, Dave Airlie wrote: > > On Tue, 16 Apr 2019 at 06:05, Lionel Landwerlin > > <[email protected]> wrote: > >> On 15/04/2019 20:52, Dave Airlie wrote: > >>> On Tue, 16 Apr 2019 at 05:48, Lionel Landwerlin > >>> <[email protected]> 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 _______________________________________________ dri-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/dri-devel
