On 4 January 2017 at 09:10, Thierry Reding <thierry.red...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev