[PATCH v2 3/3] imx: gallium driver for imx-drm scanout driver

[Thierry Reding]

On Fri, Dec 23, 2016 at 11:04:51PM +0100, Christian Gmeiner wrote:
[...]
> +struct pipe_screen *imx_drm_screen_create(int fd)
> +{
> +   struct renderonly ro = {
> +      .create_for_resource = renderonly_create_kms_dumb_buffer_for_resource,
> +      .kms_fd = fd,
> +      .gpu_fd = open("/dev/dri/renderD128", O_RDWR | O_CLOEXEC)
> +   };
> +
> +   if (ro.gpu_fd < 0)
> +      return NULL;
> +
> +   struct pipe_screen *screen = etna_drm_screen_create_renderonly(&ro);
> +   if (!screen)
> +      close(ro.gpu_fd);
> +
> +   return screen;
> +}

So while trying to port Tegra to this renderonly library, I realized
that we're not going to be able to use this for Tegra after all. It
should work, and I'm going to go through with the port just for the
sake of testing, for the specific use-case of hooking up the GPU and
the scanout device.

However there's some work being done to implement functionality for
other Tegra units within Mesa, which is going to make this a bit of
a showstopper.

To be more specific: in the above, the imx-drm driver returns the screen
associated with the etnaviv render node, rather than a full wrapper for
the KMS file descriptor. That's effectively what allows you to have this
work without jumping through extra hoops since it will cause DRI3 and
Wayland to properly set up the driver for clients.

For Tegra, however, we're going to need a beefier wrapper in order to
multiplex between the GPU and other units, such as the VIC, NVENC or
NVDEC.

Emil, my recollection is that you had fairly strong objections to the
initial proposal of a full-blown wrapper for Tegra. In light of the
above I don't think we can avoid it forever, though.

I guess a good way forward would be to add a very thin driver for Tegra,
similar to what Christian has done for i.MX and move to a more flexible
solution later on when work for VIC/NVENC/NVDEC becomes ready. The most
obvious advantage is that it would get us the long-wanted support fairly
easily. A disadvantage, albeit a small one, is that the changes we need
to make to Nouveau will become obsolete.

Furthermore I think most of the work I did on PRIME support becomes
unnecessary with the above workaround. Given that Mesa will only ever
see the Nouveau pipe_screen, at least Weston should work properly out of
the box. DRI3 might still be problematic according to Alex's earlier
tests of the Tegra renderonly port. I have a couple more ideas that I'd
like to try out to see if they can solve this issue.

Thierry
-------------- 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/etnaviv/attachments/20170104/742c1c29/attachment.sig>