On Wed, Dec 14, 2016 at 01:30:04PM +0100, 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. > > Until that exists I really think that the VIC part (and only that, since > tk1/tx1 in general seems to work with nouveau and all that) should stay > out of tree. I think the VIC is somewhat special with regard to userspace ABI. I understand and completely agree with the requirements the community has established. However, as Mikko already said, there's no use for standalone VIC at all. There aren't any APIs that map to what the hardware does (except maybe parts of X or perhaps pixman, neither of which are likely to see implementations using VIC). I'm also not aware of any of the proprietary driver stack using only VIC for any use cases. The primary reason that I want VIC support upstream is because it makes it easier to test host1x support. Currently the only units that we can test against are gr2d and gr3d on Tegra20 through Tegra114. With Tegra124 gr2d and gr3d went away and got replaced by the gk20a GPU which doesn't use the host1x infrastructure. So on Tegra124 and later we currently have no way of exercising that code. Now, Tegra124 and Tegra210 are by far the most popular generations at this point and there are very few people running Tegra20 or Tegra30 with an upstream kernel (there are some still, and I think they're all awesome) so the host1x infrastructure is effectively untested and therefore I get very nervous whenever I have to apply patches against it because we can only validate on very old chips. Tegra124 is also somewhat of a special case. While it has a GPU that's driven by Nouveau, it doesn't yet have NVDEC and NVENC support that the newer Tegra210 has. The video encoding, if I remember correctly, is a precursor to NVENC (MSENC?) but video decoding is the "legacy" hardware that we had on earlier chips. That involved a fairly complicated setup with firmware that needs to be loaded to a fixed address in system memory (or mapped using the IOMMU). The bottom line is that it's unlikely that we'll ever see an open-source implementation for video decoding on Tegra124 (unless somebody reverse-engineers it), and hence we'd essentially be left without any way of testisc host1x support on TK1. All of that said, I could carry these patches out of tree and use them for testing until we've got a complete userspace ready. It's just something that I had hoped I could avoid. Thierry
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
