[pull] amdgpu, amdkfd drm-next-5.8

[Alex Deucher]

On Thu, May 14, 2020 at 5:42 AM Daniel Stone <daniel at fooishbar.org> wrote:
>
> Hi Alex,
>
> On Thu, 30 Apr 2020 at 22:30, Alex Deucher <alexdeucher at gmail.com> wrote:
> > UAPI:
> > - Add amdgpu UAPI for encrypted GPU memory
> >   Used by: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4401
>
> Did this ever go through uAPI review? It's been pushed to the kernel
> before Mesa review was complete. Even then, Mesa only uses it when
> behind a magic environment variable, rather than through the EGL
> extensions which have been specifically designed for protected content
> (EGL_EXT_protected_content, protected_surface, etc). The winsys
> usecase was based on a Wayland system which seems like it will only
> work when composition bypass is available - not using any of the
> Wayland protected-content extensions, and it's completely unclear what
> will happen if composition bypass can't actually be achieved.
>
> I don't think this should be landing before all those open questions
> have been answered. We're trying to come up with a good and coherent
> story for handling protected content, and I'd rather not see AMD
> landing its own uAPI which might completely contradict that.

Well, the patches have been public for months and we have a UAPI and
mesa userspace which works for our use cases and the mesa side has
been merged and the recent comments on the MR didn't seem like show
stoppers.  I don't disagree with your point, but I feel like agreeing
on a what we want to do for EGL protected content could drag out for
months or years.  Our UAPI is pretty straight forward and pretty much
matches how our hw works and what we already do for other GPUVM
mapping attributes like read/write/execute.  I don't see the current
UAPI being a blocker for any future protected content work, but of
course we can't be sure until it actually happens.

Alex