Message ID | 20200430212951.3902-1-alexander.deucher@amd.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | [pull] amdgpu, amdkfd drm-next-5.8 | expand |
Hi Alex, On Thu, 30 Apr 2020 at 22:30, Alex Deucher <alexdeucher@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. Cheers, Daniel
On Thu, May 14, 2020 at 5:42 AM Daniel Stone <daniel@fooishbar.org> wrote: > > Hi Alex, > > On Thu, 30 Apr 2020 at 22:30, Alex Deucher <alexdeucher@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
Hi, On Thu, 14 May 2020 at 14:36, Alex Deucher <alexdeucher@gmail.com> wrote: > On Thu, May 14, 2020 at 5:42 AM Daniel Stone <daniel@fooishbar.org> wrote: > > 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. As a generic compositor author, it's pretty important for me to understand what happens when trying to access protected content. Does the import simply fail? Does it sample rubbish? Does my context killed? etc. > 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. I don't really see what the problem is, but it would've been nice if it was at least attempted, rather than just parachuted in ... I know I'm going to end up getting bug reports about it for Wayland/Weston, and then all of a sudden it's become my problem that this was just dropped in as a vendor-specific feature in a vendor-specific island. Cheers, Daniel
On Thu, May 14, 2020 at 10:15 AM Daniel Stone <daniel@fooishbar.org> wrote: > > Hi, > > On Thu, 14 May 2020 at 14:36, Alex Deucher <alexdeucher@gmail.com> wrote: > > On Thu, May 14, 2020 at 5:42 AM Daniel Stone <daniel@fooishbar.org> wrote: > > > 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. > > As a generic compositor author, it's pretty important for me to > understand what happens when trying to access protected content. Does > the import simply fail? Does it sample rubbish? Does my context > killed? etc. Unless you are a GPU engine in secure mode, you'll just get garbage. You specify what mode you want each engine to operate in when you submit work to the GPU. > > > 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. > > I don't really see what the problem is, but it would've been nice if > it was at least attempted, rather than just parachuted in ... I know > I'm going to end up getting bug reports about it for Wayland/Weston, > and then all of a sudden it's become my problem that this was just > dropped in as a vendor-specific feature in a vendor-specific island. I'm not sure what you mean by parachuted in. The patches for both the kernel and mesa were send out to their respective review mediums a number of times and there were actually a number of revisions as we worked through issues that came up. We were certainly not trying to "sneak" this in. I didn't realize anyone was actually seriously working on this at the moment either until you brought it up. What is the current status? Does anyone else have anything similar in progress? Alex