On Tue, Jan 17, 2017 at 06:22:36PM +0200, Mikko Perttunen wrote: > On 12/14/2016 04:11 PM, Daniel Vetter wrote: > > On Wed, Dec 14, 2016 at 03:32:16PM +0200, Mikko Perttunen wrote: > > > On 14.12.2016 15:05, Daniel Vetter wrote: > > > > On Wed, Dec 14, 2016 at 02:41:28PM +0200, Mikko Perttunen wrote: > > > > > On 14.12.2016 14:30, Daniel Vetter wrote: > > > > > > On Wed, Dec 14, 2016 at 01:16:10PM +0200, Mikko Perttunen wrote: > > > > > > > This series adds IOMMU support to Host1x and TegraDRM > > > > > > > and adds support for the VIC (Video Image Compositor) > > > > > > > host1x client. The series is available as a git repository at > > > > > > > git://github.com/cyndis/linux.git; branch vic-2. > > > > > > > > > > > > > > A userspace test case for VIC can be found at > > > > > > > https://github.com/cyndis/drm/tree/work/tegra. > > > > > > > The testcase is in tests/tegra and is called submit_vic. > > > > > > > The testcase/TRM include full headers and documentation > > > > > > > to program the unit. The unit by itself, however, does not > > > > > > > readily map to existing userspace library interfaces, so > > > > > > > implementations for those are not provided. > > > > > > > > > > > > Afaik libva has an entire pile of post-processing support. Pretty > > > > > > sure > > > > > > other video transcode libraries have similar interfaces, so should > > > > > > all be > > > > > > possible to implement this. > > > > > > > > > > We don't have any actual video transcoding support though, so unless > > > > > it's > > > > > possible to just implement a part of libva and defer the rest to some > > > > > CPU > > > > > implementation, I don't see how this is useful. I suppose I could > > > > > implement > > > > > a GStreamer plugin for colorspace conversion or resizing, since those > > > > > are > > > > > very modular. > > > > > > > > Hm, I guess the question then is, how did that get enabled? > > > > > > What is "that"? I'm not exactly sure. > > > > > > Our architecture is such that there's the VIC that handles colorspace > > > conversion, rescaling, blitting and can do some 2d postprocessing effects > > > as > > > well. > > > > > > Then there's the separate NVDEC that is a video bitstream decoder. There's > > > no support for that at the moment. I am working on the IP side of that. > > > > > > The video processing pipeline is then such that NVDEC is fed the > > > bitstream; > > > NVDEC outputs a YUV picture in a specific format; VIC takes that YUV > > > picture > > > and converts/rescales it into the desired format. Or if we are encoding > > > video, VIC takes your RGB image, converts it into a format that NVENC > > > understands, and so on. > > > > > > So with just VIC support, I could implement some simple 2D things. I don't > > > know if anyone would want to specifically use the VIC for those since > > > applications already have fast CPU algorithms. For the video pipeline > > > using > > > VIC is nice since these units can synchronize work without CPU involvement > > > and when you're already using NVDEC or NVENC it's barely any extra effort > > > to > > > involve VIC as well. It can also be useful in power usage sensitive > > > situations, but we aren't really fit for those situations with the > > > upstream > > > kernel anyway :) > > > > Ah I thought the nvdec was already enabled, since for i915 that's how we > > went about things (we have a pretty much exactly matching split in the > > various video related engines). But if that's not there yet then no > > worries, all fine. > > > > Since you do seem to plan to enable everything anyway, might be worth it > > to go directly with something like libva or libvdpau or whatever the cool > > thing is. libva is my recommendation since it works on non-X11 too afaik, > > but I have 0 clue. And might be worth it to check out whether you can't do > > a super-basic libva driver that only does the post processing stuff. With > > libva you can import/export images, so it might be possible even ... And > > directly doing the full video engine support instead of a one-off in > > gstreamer sounds more sensible to me. > > -Daniel > > > > It took a while, but I now have a libva backend to go with this kernel > driver: https://github.com/cyndis/vaapi-tegra-driver. > > It is far from complete, but the libva putsurface testcase runs and its > output looks correct when compared to the intel backend. Would this be > suitable or should something more be implemented before merging the kernel > driver?
Seems all reasonable to move ahead with this. Thanks for doing it. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
