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

From: "Koenig, Christian" <Christian.Koenig-5C7GfCeVMHo@public.gmane.org>
To: Emil Velikov <emil.l.velikov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: "Deucher,
	Alexander" <Alexander.Deucher-5C7GfCeVMHo@public.gmane.org>,
	David Airlie <airlied-cv59FeDIM0c@public.gmane.org>,
	"amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org"
	<amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>,
	"dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org"
	<dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>,
	Daniel Vetter <daniel-/w4YWyX8dFk@public.gmane.org>
Subject: Re: [PATCH 01/13] drm/amdgpu: introduce and honour DRM_FORCE_AUTH workaround
Date: Fri, 21 Jun 2019 12:13:54 +0000	[thread overview]
Message-ID: <76158d1f-676d-2afa-244b-934967a9cb75@amd.com> (raw)
In-Reply-To: <20190621115845.GC21486@arch-x1c3>

Am 21.06.19 um 13:58 schrieb Emil Velikov:
> On 2019/06/21, Koenig, Christian wrote:
>> Am 21.06.19 um 12:53 schrieb Emil Velikov:
>>> On 2019/06/21, Koenig, Christian wrote:
>>>> [SNIP]
>>>> 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.
>> Well to clarify my concern is that this won't be so trivial.
>>
>> You implemented on workaround for one specific case and it is perfectly
>> possible that for other cases we would have to completely revert the
>> removal of DRM_AUTH.
>>
> I would encourage you to take a closer look at my patch and point out
> how parcicular cases cannot be handled.

Well the last time I looked it only blocked the first call to the IOCTL.

If that is no longer the case then what is the actual difference to 
DRM_AUTH+DRM_ALLOW_RENDER?

>>>>> 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?
>> The key point is that I don't think this is silly or strange or crazy at
>> all. See the kernel defines the interface userspace can and should use.
>>
>> When the kernel defines that everything will work with the primary node
>> it is perfectly valid for userspace to drop support for the render node.
>>
>> I mean why should they keep this? Just because we tell them not to do this?
>>
>  From your experiense, do user-space developers care about doing (or
> generally do) the right thing?

No, not at all. Except for Marek and Michel they just take what works 
and even Marek is often short-cutting on this.

> In either case, as pointed already the cat is out of the bag - has been
> for years, and if developers did behave as you describe them they would
> have "removed" render nodes already.

Currently render nodes are mandatory because they are needed for 
headless operation.

E.g. we have a whole bunch of customers which do transcoding with that 
on GPUs which don't even have a CRTC or even X running.

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