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

[Michel Dänzer]

On 2019-06-21 5:52 p.m., Michel Dänzer wrote:
> On 2019-06-21 5:44 p.m., Daniel Vetter wrote:
>> On Fri, Jun 21, 2019 at 05:15:22PM +0200, Michel Dänzer wrote:
>>> On 2019-06-21 1:50 p.m., Daniel Vetter wrote:
>>>> On Fri, Jun 21, 2019 at 1:37 PM Christian König
>>>> <ckoenig.leichtzumerken at gmail.com> wrote:
>>>>> Am 21.06.19 um 13:03 schrieb Daniel Vetter:
>>>>>> 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.
>>>>
>>>> tbh I do like that plan too, but it's a lot more work. And I think to
>>>> have any push whatsoever we probably need to roll it out in gbm as a
>>>> hack to keep things going. But probably not enough.
>>>>
>>>> I also think that at least some compositors will bother to do the
>>>> right thing, and actually bother with render nodes and all that
>>>> correctly. It's just that there's way more which dont.
>>>
>>> With amdgpu, we can make userspace always use render nodes for rendering
>>> with changes to libdrm_amdgpu/radeonsi/xf86-video-amdgpu (and maybe some
>>> amdgpu-pro components) only. No GBM/compositor changes needed.
>>
>> This is a very non-exhaustive list of userspace that runs on your driver
>> ... This wayland compositor thing, actually shipping now, and there's many :-)
> 
> You don't seem to understand what I wrote. Everything will work at least
> as well as now, without any other changes.
> 
> [...]
> 
>> That was the entire point of kms, and it succeed really well. That's
>> why I don't think amdgpu doing their own flavour pick is going to help
>> anyone here,
> Other drivers are welcome to emulate amdgpu's design making the above
> possible. :)

Seriously though, I don't think any changes outside of libdrm/Mesa
should be needed with other drivers either. Fundamentally there's
nothing magic about it, just sharing BOs via PRIME between the render
node file description and that passed in via the EGL/GBM/... API.


-- 
Earthling Michel Dänzer               |              https://www.amd.com
Libre software enthusiast             |             Mesa and X developer