On Fri, Jun 21, 2019 at 12:31 PM Koenig, Christian <Christian.Koenig@xxxxxxx> wrote: > Am 21.06.19 um 12:20 schrieb Emil Velikov: > > In particular, that user-space will "remove" render nodes. > > Yes, that is my main concern here. You basically make render nodes > superfluously. That gives userspace all legitimization to also remove > support for them. That is not stupid or evil or whatever, userspace > would just follow the kernel design. This already happened. At least for kms-only display socs we had to hide the separate render node (and there you really have to deal with the separate render node, because it's a distinct driver) entirely within gbm/mesa. So if you want to depracate render functionality on primary nodes, you _have_ to do that hiding in userspace. Or you'll break a lot of compositors everywhere. Just testing -amdgpu doesn't really prove anything here. So you won't move the larger ecosystem with this at all, that ship sailed. At that point this all feels like a bikeshed, and for a bikeshed I don't care what the color is we pick, as long as they're all painted the same. Once we picked a color it's a simple technical matter of how to roll it out, using Kconfig options, or only enabling on new hw, or "merge and fix the regressions as they come" or any of the other well proven paths forward. So if you want to do this, please start with the mesa side work (as the biggest userspace, not all of it) with patches to redirect all primary node rendering to render nodes. The code is there already for socs, just needs to be rolled out more. Or we go with the DRM_AUTH horrors. Or a 3rd option, I really don't care which it is, as long as its consistent. tldr; consistent color choice on this bikeshed please. Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
