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
signature.asc
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev