On 2019/06/21, Koenig, Christian wrote: > No this should apply to all drivers, not just amdgpu. > > > While I suggested: > > - keeping amdgpu consistent with the rest > > - exposing the KConfig option for the whole of the kernel, and > > - merging it alongside this work > > > > So I effectively waited for weeks, instead of simply going ahead and > > writing/submitting patches. That's a bit unfortunate... > > > >>> Because we simply made sure that userspace is using the render node for > >>> command submission and not the primary node. > >>> > >>> So nobody can go ahead and remove render node support any more :) > >> How does this work? I thought the entire problem of DRM_AUTH removal > >> for you was that it broke stuff, and you didn't want to deal with > >> that. We still have that exact problem afaics ... old userspace > >> doesn't simply vanish, even if you entirely nuke it going forward. > >> > >> Also, testing on the amdgpu stack isn't really testing a hole lot > >> here, it's all the various silly compositors out there I'd expect to > >> fall over. Will gbm/radeonsi/whatever just internally do all the > >> necessary dma-buf import/export between the primary node and display > >> node to keep this all working? > > If I understood Christian, feel free to correct me, the fact that my > > earlier patch broke RADV was not the argument. The problem was was the > > patch does. > > Well partially. That RADV broke is unfortunate, but we have done so many > customized userspace stuff both based on Mesa/DDX as well as closed > source components that it is just highly likely that we would break > something else as well. > As an engineer I like to work with tangibles. The highly likely part is probable, but as mentioned multiple times the series allows for a _dead_ trivial way to address any such problems. > > 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. > Do you have an example of userspace doing such an extremely silly thing? It does seem like suspect you're a couple of steps beyond overcautious, perhaps rightfully so. Maybe you've seen some closed-source user-space going crazy? Or any other projects? In other words, being cautious is great, but without references of misuse it's very hard for others to draw the full picture. > > I'm really sad that amdgpu insists on standing out, hope one day it will > > converge. Yet since all other maintainers are ok with the series, I'll > > start merging patches in a few hours. I'm really sad that amdgpu wants > > to stand out, hope it will converge sooner rather than later. > > > > Christian, how would you like amdgpu handled - with a separate flag in > > the driver or shall we special case amdgpu within core drm? > > No, I ask you to please stick around DRM_AUTH for at least amdgpu and > radeon. And NOT enable any render node functionality for them on the > primary node. > My question is how do you want this handled: - DRM_PLEASE_FORCE_AUTH - added to AMDGPU/RADEON, or - driver_name == amdgpu, in core DRM. Thanks Emil _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
