mbox series

[pull] amdgpu, amdkfd drm-next-5.8

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

Pull-request

git://people.freedesktop.org/~agd5f/linux tags/amd-drm-next-5.8-2020-04-30

Message

Alex Deucher April 30, 2020, 9:29 p.m. UTC
Hi Dave, Daniel,

More new stuff for 5.8.

The following changes since commit e748f07d00c1c4a9106acafac52df7ea4ecf6264:

  drm/amdgpu: retire legacy vega10 sos version check (2020-04-23 15:41:06 -0400)

are available in the Git repository at:

  git://people.freedesktop.org/~agd5f/linux tags/amd-drm-next-5.8-2020-04-30

for you to fetch changes up to b8020b0304c8f44e5e29f0b1a04d31e0bf68d26a:

  drm/amdkfd: Enable over-subscription with >1 GWS queue (2020-04-28 16:20:30 -0400)

----------------------------------------------------------------
amd-drm-next-5.8-2020-04-30:

amdgpu:
- SR-IOV fixes
- SDMA fix for Navi
- VCN 2.5 DPG fixes
- Display fixes
- Display stuttering fixes for pageflip and cursor
- Add support for handling encrypted GPU memory
- Add UAPI for encrypted GPU memory
- Rework IB pool handling

amdkfd:
- Expose asic revision in topology
- Add UAPI for GWS (Global Wave Sync) resource management

UAPI:
- Add amdgpu UAPI for encrypted GPU memory
  Used by: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4401
- Add amdkfd UAPI for GWS (Global Wave Sync) resource management
  Thunk usage of KFD ioctl: https://github.com/RadeonOpenCompute/ROCT-Thunk-Interface/blob/roc-2.8.0/src/queues.c#L840
  ROCr usage of Thunk API: https://github.com/RadeonOpenCompute/ROCR-Runtime/blob/roc-3.1.0/src/core/runtime/amd_gpu_agent.cpp#L597
  HCC code using ROCr API: https://github.com/RadeonOpenCompute/hcc/blob/98ee9f34945d3b5f572d7a4c15cbffa506487734/lib/hsa/mcwamp_hsa.cpp#L2161
  HIP code using HCC API: https://github.com/ROCm-Developer-Tools/HIP/blob/cf8589b8c8a40ddcc55fa3a51e23390a49824130/src/hip_module.cpp#L567

----------------------------------------------------------------
Aaron Liu (5):
      drm/amdgpu: expand sdma copy_buffer interface with tmz parameter
      drm/amdgpu: expand amdgpu_copy_buffer interface with tmz parameter
      drm/amdgpu: enable TMZ bit in sdma copy pkt for sdma v4
      drm/amdgpu: enable TMZ bit in sdma copy pkt for sdma v5
      drm/amdgpu: enable TMZ bit in FRAME_CONTROL for gfx10

Alex Deucher (5):
      drm/amdgpu: add UAPI for creating encrypted buffers
      drm/amdgpu: define the TMZ bit for the PTE
      drm/amdgpu: set TMZ bits in PTEs for secure BO (v4)
      drm/amdgpu: move CS secure flag next the structs where it's used
      drm/amdgpu: check ring type for secure IBs

Alex Sierra (1):
      drm/amdgpu: pass unlocked flag to params at amdgpu_vm_bo_update_mapping

Anthony Koo (1):
      drm/amd/display: clean up some header paths

Aric Cyr (4):
      drm/amd/display: 3.2.82
      drm/amd/display: Use cursor locking to prevent flip delays
      drm/amd/display: 3.2.83
      drm/amd/display: 3.2.83.1

Christian König (10):
      drm/amdgpu: also add the TMZ flag to GART
      drm/amdgpu: add TMZ handling to amdgpu_move_blit
      drm/amdgpu: stop evicting encrypted BOs to swap
      drm/amdgpu: cleanup amdgpu_ttm_copy_mem_to_mem and amdgpu_map_buffer v2
      drm/amdgpu: add full TMZ support into amdgpu_ttm_map_buffer v2
      drm/amdgpu: fix size calculation in amdgpu_ttm_copy_mem_to_mem
      drm/amdgpu: partial revert VM sync changes
      drm/amdgpu: cleanup IB pool handling a bit
      drm/amdgpu: rename direct to immediate for VM updates
      drm/amdgpu: add new unlocked flag for PTE updates

Colin Ian King (3):
      drm/amd/display: remove redundant assignment to variable ret
      drm/amdgpu/gmc: Use consistent variable on unlocks
      amdgpu/dc: remove redundant assignment to variable 'option'

Dmytro Laktyushkin (2):
      drm/amd/display: check if REFCLK_CNTL register is present
      drm/amd/display: fix rn soc bb update

Evan Quan (2):
      drm/amdgpu: move kfd suspend after ip_suspend_phase1
      drm/amdgpu: drop redundant cg/pg ungate on runpm enter

Guchun Chen (2):
      drm/amdgpu: switch to SMN interface to operate RSMU index mode
      drm/amdgpu: decouple EccErrCnt query and clear operation

Harry Wentland (1):
      drm/amd/display: Indicate use of TMZ buffers to DC

Huang Rui (10):
      drm/amdgpu: add tmz feature parameter (v2)
      drm/amdgpu: add amdgpu_tmz data structure
      drm/amdgpu: add function to check tmz capability (v4)
      drm/amdgpu: add tmz bit in frame control packet
      drm/amdgpu: expand the emit tmz interface with trusted flag
      drm/amdgpu: expand the context control interface with trust flag
      drm/amdgpu: job is secure iff CS is secure (v5)
      drm/amdgpu: remove the alignment placeholder for secure buffer
      drm/amdgpu: fix the wrong logic checking when secure buffer is created (v3)
      drm/amdgpu: Fix per-IB secure flag GFX hang

James Zhu (1):
      drm/amdgpu/vcn2.5: wait for tiles off after unpause

Jason Yan (3):
      drm/amdgpu: remove conversion to bool in amdgpu_device.c
      drm/amd/display: remove conversion to bool in dcn20_mpc.c
      drm/amd/display: remove conversion to bool in dc_link_ddc.c

Jonathan Kim (1):
      drm/amdgpu: sw pstate switch should only be for vega20

Joseph Greathouse (3):
      drm/amdkfd: Put ASIC revision into HSA capability
      drm/amdkfd: Enable GWS based on FW Support
      drm/amdkfd: Enable over-subscription with >1 GWS queue

Joshua Aberback (2):
      drm/amd/display: Add DML variable for future asics
      drm/amd/display: Add dummy p-state latency bounding box override

Krunoslav Kovac (1):
      drm/amd/display: Internal refactoring to abstract color caps

Luben Tuikov (4):
      drm/amdgpu: add UAPI to create secure commands (v3)
      drm/amdgpu: implement TMZ accessor (v3)
      drm/amdgpu: Move to a per-IB secure flag (TMZ)
      drm/amdgpu: Fine-grained TMZ support

Marek Olšák (3):
      drm/amdgpu: add tiling flags from Mesa
      drm/amdgpu: invalidate L2 before SDMA IBs (v2)
      drm/amdgpu: bump version for invalidate L2 before SDMA IBs

Monk Liu (9):
      drm/amdgpu: ignore TA ucode for SRIOV
      drm/amdgpu: skip cg/pg set for SRIOV
      drm/amdgpu: sriov is forbidden to call disable DPM
      drm/amdgpu: provide RREG32_SOC15_NO_KIQ, will be used later
      drm/amdgpu: clear the messed up checking logic
      drm/amdgpu: enable one vf mode for nv12
      drm/amdgpu: skip sysfs node not belong to one vf mode
      drm/amdgpu: for nv12 always need smu ip
      drm/amdgpu:  extent threshold of waiting FLR_COMPLETE

Nicholas Kazlauskas (3):
      drm/amd/display: Fix DMUB meta offset for new load method
      drm/amd/display: Defer cursor update around VUPDATE for all ASIC
      drm/amd/display: Pass command instead of header into DMUB service

Oak Zeng (1):
      drm/amdkfd: New IOCTL to allocate queue GWS (v2)

Stephen Rothwell (1):
      drm/amdgpu: fix up for amdgpu_tmz.c and removal of drm/drmP.h

Sung Lee (4):
      drm/amd/display: Do not disable pipe split if mode is not supported
      drm/amd/display: Fail validation if building scaling params fails
      drm/amd/display: Change viewport limit to 12 for DCN2
      drm/amd/display: Update downspread percent to match spreadsheet for DCN2.1

Tiecheng Zhou (2):
      Revert "drm/amd/powerplay: avoid using pm_en before it is initialized"
      drm/amd/powerplay: avoid using pm_en before it is initialized revised

Yintian Tao (1):
      drm/amdgpu: protect ring overrun

Yongqiang Sun (2):
      drm/amd/display: Add panel cntl id for set backlight level.
      drm/amd/display: Add set backlight to hw sequencer.

Zheng Bin (1):
      drm/amdgpu: Remove unneeded semicolon

 drivers/gpu/drm/amd/amdgpu/amdgpu.h                |  21 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c         |   7 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h         |   1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_benchmark.c      |   2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c             |   3 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c         |  11 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c            |  21 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c          |  10 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c            |   8 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c            |  22 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c            |  35 +++
 drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.h            |   4 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c             |  92 +++---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c            |   6 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_job.h            |   1 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_object.c         |   2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_object.h         |  11 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c             |  48 +--
 drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h           |  21 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_sdma.h           |   5 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c           |   5 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_test.c           |   6 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c            | 324 ++++++++++++---------
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h            |   8 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c            |   4 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c            |   5 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c           |   8 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c             |  91 +++---
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h             |  20 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm_cpu.c         |   2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm_sdma.c        |  30 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c           |   4 +-
 drivers/gpu/drm/amd/amdgpu/cik_sdma.c              |   3 +-
 drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c             |  23 +-
 drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c              |  27 +-
 drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c             |  11 +-
 drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c              |   8 +-
 drivers/gpu/drm/amd/amdgpu/mxgpu_ai.h              |   2 +-
 drivers/gpu/drm/amd/amdgpu/mxgpu_nv.h              |   2 +-
 drivers/gpu/drm/amd/amdgpu/navi10_sdma_pkt_open.h  |  16 +
 drivers/gpu/drm/amd/amdgpu/nv.c                    |   3 +-
 drivers/gpu/drm/amd/amdgpu/nvd.h                   |   1 +
 drivers/gpu/drm/amd/amdgpu/psp_v11_0.c             |   2 +
 drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c             |   3 +-
 drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c             |   3 +-
 drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c             |   6 +-
 drivers/gpu/drm/amd/amdgpu/sdma_v5_0.c             |  20 +-
 drivers/gpu/drm/amd/amdgpu/si_dma.c                |   3 +-
 drivers/gpu/drm/amd/amdgpu/soc15_common.h          |   3 +
 drivers/gpu/drm/amd/amdgpu/soc15d.h                |   1 +
 drivers/gpu/drm/amd/amdgpu/umc_v6_1.c              | 112 ++++++-
 drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c              |   6 +-
 drivers/gpu/drm/amd/amdkfd/kfd_chardev.c           |  42 +++
 drivers/gpu/drm/amd/amdkfd/kfd_device.c            |  40 ++-
 .../gpu/drm/amd/amdkfd/kfd_device_queue_manager.c  |  43 ++-
 .../gpu/drm/amd/amdkfd/kfd_device_queue_manager.h  |   1 +
 drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue.c      |   1 +
 drivers/gpu/drm/amd/amdkfd/kfd_packet_manager.c    |   6 +-
 drivers/gpu/drm/amd/amdkfd/kfd_packet_manager_v9.c |   2 +-
 drivers/gpu/drm/amd/amdkfd/kfd_priv.h              |  16 +
 drivers/gpu/drm/amd/amdkfd/kfd_process.c           |   1 +
 .../gpu/drm/amd/amdkfd/kfd_process_queue_manager.c |   9 +
 drivers/gpu/drm/amd/amdkfd/kfd_topology.c          |   6 +-
 drivers/gpu/drm/amd/amdkfd/kfd_topology.h          |   5 +-
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c  |  29 +-
 .../drm/amd/display/amdgpu_dm/amdgpu_dm_color.c    |   7 +-
 .../gpu/drm/amd/display/dc/bios/command_table2.c   |  62 ++--
 drivers/gpu/drm/amd/display/dc/core/dc.c           |   4 +-
 drivers/gpu/drm/amd/display/dc/core/dc_link.c      |  36 +--
 drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c  |   2 +-
 drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c   |   2 +-
 drivers/gpu/drm/amd/display/dc/core/dc_resource.c  |   4 +-
 drivers/gpu/drm/amd/display/dc/core/dc_stream.c    |  40 +--
 drivers/gpu/drm/amd/display/dc/dc.h                |  48 ++-
 drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c       |   2 +-
 drivers/gpu/drm/amd/display/dc/dc_dmub_srv.h       |   5 +-
 drivers/gpu/drm/amd/display/dc/dc_helper.c         |   6 +-
 drivers/gpu/drm/amd/display/dc/dce/dce_abm.c       |  15 +-
 drivers/gpu/drm/amd/display/dc/dce/dmub_abm.c      |  28 +-
 drivers/gpu/drm/amd/display/dc/dce/dmub_psr.c      |  12 +-
 .../amd/display/dc/dce110/dce110_hw_sequencer.c    |  35 ++-
 .../amd/display/dc/dce110/dce110_hw_sequencer.h    |   4 +
 .../drm/amd/display/dc/dce110/dce110_opp_csc_v.c   |   3 +-
 .../drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c  |  19 +-
 .../drm/amd/display/dc/dcn10/dcn10_hw_sequencer.h  |   1 +
 drivers/gpu/drm/amd/display/dc/dcn10/dcn10_init.c  |   2 +
 drivers/gpu/drm/amd/display/dc/dcn10/dcn10_mpc.c   |  15 +
 drivers/gpu/drm/amd/display/dc/dcn10/dcn10_mpc.h   |  20 +-
 .../gpu/drm/amd/display/dc/dcn10/dcn10_resource.c  |  48 ++-
 drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c |  12 +-
 drivers/gpu/drm/amd/display/dc/dcn20/dcn20_init.c  |   2 +
 drivers/gpu/drm/amd/display/dc/dcn20/dcn20_mpc.c   |   3 +-
 drivers/gpu/drm/amd/display/dc/dcn20/dcn20_mpc.h   |   3 +-
 .../gpu/drm/amd/display/dc/dcn20/dcn20_resource.c  |  71 ++++-
 .../gpu/drm/amd/display/dc/dcn20/dcn20_resource.h  |   2 +-
 drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hubp.c  |  33 ++-
 drivers/gpu/drm/amd/display/dc/dcn21/dcn21_init.c  |   2 +
 .../gpu/drm/amd/display/dc/dcn21/dcn21_resource.c  | 112 ++++---
 .../drm/amd/display/dc/dml/display_mode_structs.h  |   1 +
 .../gpu/drm/amd/display/dc/dml/display_mode_vba.c  |   1 +
 .../gpu/drm/amd/display/dc/dml/display_mode_vba.h  |   1 +
 drivers/gpu/drm/amd/display/dc/inc/hw/abm.h        |   5 +-
 drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h        |  16 +
 drivers/gpu/drm/amd/display/dc/inc/hw_sequencer.h  |   5 +
 drivers/gpu/drm/amd/display/dmub/inc/dmub_cmd.h    |   6 +-
 drivers/gpu/drm/amd/display/dmub/inc/dmub_rb.h     |   6 +-
 drivers/gpu/drm/amd/display/dmub/inc/dmub_srv.h    |   3 +-
 drivers/gpu/drm/amd/display/dmub/inc/dmub_types.h  |  11 +
 drivers/gpu/drm/amd/display/dmub/src/dmub_srv.c    |  10 +-
 .../drm/amd/display/modules/color/color_gamma.c    |  31 +-
 .../drm/amd/display/modules/color/color_gamma.h    |   4 +-
 drivers/gpu/drm/amd/powerplay/amd_powerplay.c      |   9 +-
 drivers/gpu/drm/amd/powerplay/amdgpu_smu.c         |  26 +-
 drivers/gpu/drm/amd/powerplay/navi10_ppt.c         |   6 +-
 drivers/gpu/drm/amd/powerplay/smu_v11_0.c          |  49 +++-
 include/uapi/drm/amdgpu_drm.h                      |  15 +-
 include/uapi/linux/kfd_ioctl.h                     |  19 +-
 117 files changed, 1539 insertions(+), 639 deletions(-)

Comments

Daniel Stone May 14, 2020, 9:40 a.m. UTC | #1
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
Alex Deucher May 14, 2020, 1:36 p.m. UTC | #2
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
Daniel Stone May 14, 2020, 2:13 p.m. UTC | #3
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
Alex Deucher May 14, 2020, 3:18 p.m. UTC | #4
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