[Nouveau] [Mesa-dev] [RFC] tegra: Initial support

[Thierry Reding]

On Fri, Nov 28, 2014 at 12:32:43AM -0500, Ilia Mirkin wrote:
> On Thu, Nov 27, 2014 at 11:39 AM, Thierry Reding
> <thierry.reding at gmail.com> wrote:
> > Tegra K1 and later use a GPU that can be driven by the Nouveau driver.
> > But the GPU is a pure render node and has no display engine, hence the
> > scanout needs to happen on the Tegra display hardware. The GPU and the
> > display engine each have a separate DRM device node exposed by the
> > kernel.
> >
> > To make the setup appear as a single device, this driver instantiates
> > a Nouveau screen with each instance of a Tegra screen and forwards GPU
> > requests to the Nouveau screen. For purposes of scanout it will import
> > buffers created on the GPU into the display driver. Handles that
> > userspace requests are those of the display driver so that they can be
> > used to create framebuffers.
> >
> > This has been tested with some GBM test programs, as well as kmscube and
> > weston. All of those run without modifications, but I'm sure there is a
> > lot that can be improved.
> >
> > TODO:
> > - use Nouveau headers to get at the prototype for creating a screen
> > - implement enough support to seamlessly integrate with X
> > - refactor some of the code to be reusable by other drivers
> >
> > Signed-off-by: Thierry Reding <treding at nvidia.com>
> 
> With the exception of resource creation, I don't see anything
> tegra-specific in here. Is there perhaps something that could be done
> to abstract that a little more, e.g. a wrapper driver, or...
> something? This is a situation that several mobile GPU's are in,
> AFAIK, and it may be nice to make it work for them as well.

I think it might be possible to factor out some things to reduce some
amount of boilerplate, but I don't expect it to be very much. There is
likely going to be hardware-specific details in each of these drivers
that will be hard to abstract out.

Given that this is the first driver of this sort I have no idea what
other drivers will require, so it doesn't seem wise for me to make this
any more generic. It's very likely to turn out completely wrong. Hence
why I opted for just a straight implementation that would work on Tegra.

That said, if it turns out that drivers for other SoCs need to duplicate
a lot of the code in this driver I'm sure we can find ways to alleviate
some of that. But like I already said in my reply to Rob, I don't think
a common wrapper driver is going to cut it. Perhaps something like the
u_transfer abstraction could work, but there is potential for that to
turn into a midlayer of sorts and actually make things more difficult.

The bottom-line is that the vast majority of the code is really just a
skeleton driver, so it's not unlike any of the existing drivers.
Requiring this particular driver to be common for all "mobile" SoCs is a
little like saying that Radeon and Nouveau should share code because
they both use PCI as the transport.

> Also, can you explain why it's advantageous for the setup to appear as
> though it is a single device? i.e. what's wrong with just using
> nouveau as a render node or whatever? [The answer may be simple, but
> I'm very unfamiliar with a lot of that stuff, and perhaps others are
> in a similar predicament.]

There are two reasons. For one, pretty much every software out there
that runs on the "bare metal" (i.e. GBM) uses the same initialization
sequence and it doesn't involve opening two DRM devices. So in order to
support Tegra and other SoCs with a similar architecture, each of these
applications would need to be patched. Now typically a lot of the
applications would run under X or Wayland, so the number of applications
that need patching is somewhat reduced. However, it would still mean
that every Wayland compositor would need to be patched in order to
support this, and each of them would use a mostly identical copy of that
code.

The second reason derives from the first. One of the issues I ran into
when I prototyped the dual-fd code for kmscube was that the code to
share these buffers between GPU and display is in fact highly hardware-
specific. At least on Tegra it is, because we can take advantage of the
tight coupling between GPU and display by directly scanning out block-
linear buffers. For that to work we need to make assumptions and that
just doesn't work generically.

So we need to solve two problems: reduce code duplication and hide the
hardware specific details. The natural solution for these two problems
is to move the code into a library. But we already have that library:
Mesa/GBM.

> > diff --git a/src/gallium/winsys/tegra/drm/Makefile.am b/src/gallium/winsys/tegra/drm/Makefile.am
> > new file mode 100644
> > index 000000000000..8e3685ee20e8
> > --- /dev/null
> > +++ b/src/gallium/winsys/tegra/drm/Makefile.am
> > @@ -0,0 +1,11 @@
> > +include Makefile.sources
> > +include $(top_srcdir)/src/gallium/Automake.inc
> > +
> > +AM_CFLAGS = \
> > +       -I$(top_srcdir)/src/gallium/drivers \
> > +       $(GALLIUM_WINSYS_CFLAGS) \
> > +       $(FREEDRENO_CFLAGS)
> 
> oops?

Yes, I wanted to make it obvious from where I copied. =) Good catch,
thanks.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/nouveau/attachments/20141128/99aacfd3/attachment.sig>