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.red...@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 <tred...@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
pgpxQR6tsTapx.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
