Thread (1 message) 1 message, 1 author, 2016-12-14

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

From: Thierry Reding <hidden>
Date: 2016-12-14 14:18:55
Also in: dri-devel

Possibly related (same subject, not in this thread)

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:
quoted
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

Attachments

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help