[Mesa-dev] [PATCH v3 5/6] tegra: Initial support

[Thierry Reding]

On Thu, Mar 01, 2018 at 09:41:37AM -0500, Ilia Mirkin wrote:
> Is this substantially different than the renderonly helper? i.e. could
> you reuse it somehow? (If not, that's fine too, just asking.)

Yeah, this is fairly different from renderonly in that it completely
wraps another driver. renderonly was derived from an earlier version of
this patch and simplified this by actually returning the GPU screen from
the scanout "frontend" driver. This requires changing the GPU driver to
know about a potential scanout engine because the GPU driver needs to
call into the scanout driver when creating resources in order for the
scanout driver to allocate or import the resources so that it is able to
scan them out.

This reversal makes things very simple, but at the same time limits the
flexibility because the "frontend" driver becomes essentially a slave to
the GPU driver. The other disadvantage is that the GPU driver needs to
be aware of the scanout part to make it all work.

Note that there are cases where this is absolutely fine. If all you care
about is passing buffers between scanout and render engines, renderonly
is good enough. Or if that's all you can do, then renderonly will do a
good job.

The wrapper driver has the same goal of making split scanout/render
setups behave as any other combined scanout/render setup, so that
applications don't have to be made aware of the split and encapsulate
the mechanism of how buffers are shared between GPU and scanout within
Mesa. But, in my opinion, there are some advantages to it: firstly, the
situation on Tegra is somewhat different from other SoCs in that the
same GPU driver (Nouveau) is also used on combined scanout/render
devices. So modifying it to talk to an external scanout engine seems a
little tacked on. Secondly, having a wrapper around Nouveau allows us to
implement policy specific to Tegra. For example, some formats or
modifiers may work well on a desktop GPU but perform very badly on
Tegra. The wrapper driver gives us more flexibility in filtering out
such combinations and exposing Tegra-specific capabilities if need be.
Thirdly we have a couple of other hardware units on Tegra that we may
want to use in a Mesa driver (such as VIC for image composition). These
units are not available to Nouveau, but via the host1x interface that is
accessed using the Tegra DRM device node. The wrapper driver makes it
easy to intercept some operations and redirect them to VIC if we know
that they will be better suited to its capabilities.

Technically we could reuse the renderonly helper, but we'd be limiting
ourselves to using Nouveau underneath. We'd also need to modify Nouveau
to become aware of non-GPU aspects of Tegra and we'd be unable to use
non-GPU hardware units to offload some operations. Those are all fairly
big restrictions, so the wrapper driver is the preferred solution.

> Also, will this work with the following code in nvc0_resource_fence
> (which I recently discovered does *not* play nice with the trace
> driver):
> 
>    struct nvc0_screen *screen = nvc0_screen(res->base.screen);
> 
> i.e. will the resource's screen be the nvc0 screen or the tegra
> screen? [for resources passed into the nvc0 driver obviously]

Yes, this should work fine. I've occasionally seen crashes caused by the
wrapper handing the wrong resources to nvc0, but I'm fairly confident
that these are all fixed now. I was able to run a fairly wide range of
applications, on all of bare-metal, X and Wayland, including glxgears,
glmark2, kmscube, Weston (with some of the sample applications), some
NVIDIA internal demos as well as a source port of Doom 3[0].

The way this is achieved is that the Tegra driver wraps every resources
upon allocation and storing a pointer to the nvc0 resource created by
Nouveau. When these resources are used, the Tegra driver unwraps the
resources and passes the pointer to the nvc0 resource to the nvc0
context.

Thierry

[0]: https://github.com/dhewm/dhewm3
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20180302/c1c62f7f/attachment.sig>