On Fri, Jun 26, 2020 at 04:59:45PM +0300, Dmitry Osipenko wrote: > 26.06.2020 16:38, Daniel Vetter пишет: > > On Fri, Jun 26, 2020 at 01:40:40PM +0200, Thierry Reding wrote: > >> On Fri, Jun 26, 2020 at 01:06:58PM +0200, Karol Herbst wrote: > >>> On Tue, Jun 23, 2020 at 3:03 PM Mikko Perttunen <cyndis@xxxxxxxx> wrote: > >>>> > >>>> # Host1x/TegraDRM UAPI proposal > >>>> > >>>> This is a proposal for a stable UAPI for Host1x and TegraDRM, to replace > >>>> the current TegraDRM UAPI that is behind `STAGING` and quite obsolete in > >>>> many ways. > >>>> > >>>> I haven't written any implementation yet -- I'll do that once there is > >>>> some agreement on the high-level design. > >>>> > >>>> Current open items: > >>>> > >>>> * The syncpoint UAPI allows userspace to create sync_file FDs with > >>>> arbitrary syncpoint fences. dma_fence code currently seems to assume all > >>>> fences will be signaled, which would not necessarily be the case with > >>>> this interface. > >>>> * Previously present GEM IOCTLs (GEM_CREATE, GEM_MMAP) are not present. > >>>> Not sure if they are still needed. > >>>> > >>> > >>> Hi, as this wasn't addressed here (and sorry if I missed it): is there > >>> an open source userspace making use of this UAPI? Because this is > >>> something which needs to be seen before it can be included at all. > >> > >> There's a set of commits that implement an earlier draft here: > >> > >> https://github.com/thierryreding/linux/tree/for-5.6/drm-tegra-destage-abi > >> > >> and corresponding changes to libdrm to make use of that and implement > >> tests using the various generations of VIC here: > >> > >> https://cgit.freedesktop.org/~tagr/drm/log/ > >> > >> Before actually jumping to an implementation we wanted to go over the > >> design a bit more to avoid wasting a lot of work, like we've done in > >> the past. Turns out it isn't easy to get everyone to agree on a good > >> ABI. Who would've thought? =) > >> > >> I expect that once the discussion around the ABI settles Mikko will > >> start on implementing this ABI in the kernel and we'll update the > >> libdrm patches to make use of the new ABI as well. > > > > Do we have more than libdrm and tests for this, like something somewhat > > functional? Since tegradrm landed years ago we've refined the criteria a > > bit in this regard, latest version is explicit in that it needs to be > > something that's functional (for end-users in some form), not just > > infrastructure and tests. > > We have Opentegra [1] and VDPAU [2] userspace drivers for older Tegra > SoCs that have been using the staging UAPI for years now. > > [1] https://github.com/grate-driver/xf86-video-opentegra > [2] https://github.com/grate-driver/libvdpau-tegra > > The UAPI and the kernel driver updates are very needed for these drivers > because of the missing UAPI synchronization features and performance > problems of the kernel driver. > > So we already have some real-world userspace for the testing! Awesome! Maybe for future rounds include the links for the vdpau driver. I didn't know about that one at all. -opentegra is probably not so relevant anymore (and I flat out forgot it exists) ... Including the userspace side links is good so that forgetful people like me don't nag :-) -Daniel > It's not the first and not the second time we're discussing the Tegra > DRM UAPI changes, but this time it feels like there is a good chance > that it will finally materialize and I'm very happy about it :) -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
