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

[Emil Velikov]

On 4 January 2017 at 09:10, Thierry Reding <thierry.reding at gmail.com> wrote:
> 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.
>
Re-reading my reply - there seems to be some
confusion/misunderstanding. Perhaps my inline nitpicks diverted the
whole thing.

Ether way:
I was in favour of the approach since it gives us a nice quick
solution, which can be reworked [at a later stage] as better
solution(s) come to mind.

> 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.
>
Fully agree with going for this solution for now. One will only need
200-300 loc so nuking those at a later stage should be quite OK.

> 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.
>
I think that your work on PRIME/libdrm is a requirement for proper
coupling and thus opening the correct kms/render node.
Atm. we're going a bit of a guessing with the hardcoded nodename.

I've not looked at the Wayland code recently so we might want to
double-check that alongside EGL.

Thanks
Emil