On 14.12.2016 16:11, 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.
Ah, I see :) Yes, perhaps I should have described the situation and hardware in a bit more detail initially - sometimes I forget I'm writing to other people than Thierry as well.. something to keep in mind for future patches. > > 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 > I'll take a look at libva. Thanks, Mikko.
