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... ROCr usage of Thunk API: https://github.com/RadeonOpenCompute/ROCR-Runtime/blob/roc-3.1.0/src/core/ru... HCC code using ROCr API: https://github.com/RadeonOpenCompute/hcc/blob/98ee9f34945d3b5f572d7a4c15cbff... HIP code using HCC API: https://github.com/ROCm-Developer-Tools/HIP/blob/cf8589b8c8a40ddcc55fa3a51e2...
---------------------------------------------------------------- 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(-)
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
dri-devel@lists.freedesktop.org