Re: [PATCH v2 0/7] Host1x IOMMU support + VIC support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [ARM Kernel]     [Linux ARM]     [Linux ARM MSM]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux