Re: [PATCH 01/13] drm/amdgpu: introduce and honour DRM_FORCE_AUTH workaround

["Christian König" <ckoenig.leichtzumerken-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

Am 21.06.19 um 13:03 schrieb Daniel Vetter:
> On Fri, Jun 21, 2019 at 12:31 PM Koenig, Christian
> <Christian.Koenig@amd.com> 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.

Ok, that is something I didn't knew before and is rather interesting.

> 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.

So what else can we do? That sounds like you suggest we should 
completely drop render node functionality.

I mean it's not my preferred option, but certainly something that 
everybody could do.

My primary concern is that we somehow need to get rid of thinks like GEM 
flink and all that other crufty stuff we still have around on the 
primary node (we should probably make a list of that).

Switching everything over to render nodes just sounded like the best 
alternative so far to archive that.

> 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.

Yeah, the problem is I don't see an option which currently works for 
everyone.

I absolutely need a grace time of multiple years until we can apply this 
to amdgpu/radeon.

And that under the prerequisite to have a plan to somehow enable that 
functionality now to make it at least painful for userspace to rely on 
hack around that.

> 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.

How about this:
1. We keep DRM_AUTH around for amdgpu/radeon for now.
2. We add a Kconfig option to ignore DRM_AUTH, currently default to N. 
This also works as a workaround for old RADV.
3. We start to work on further removing old cruft from the primary node. 
Possible the Kconfig option I suggested to disable GEM flink.

Regards,
Christian.

>
> tldr; consistent color choice on this bikeshed please.
>
> Thanks, Daniel

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx