On Wed, Feb 7, 2018 at 2:30 AM, Felix Kuehling wrote:
> On 2018-02-06 03:53 AM, Oded Gabbay wrote:
>> On Mon, Feb 5, 2018 at 9:00 PM, Christian König
>> wrote:
>>> Looks good to me on first glance.
>>>
>>> You probably don't mind that I'm going to pull a good part of that into
>>> amdgpu as next
Hi, Roger,
On 02/06/2018 10:04 AM, Roger He wrote:
currently ttm code has no any allocation limit. So it allows pages
allocatation unlimited until OOM. Because if swap space is full
of swapped pages and then system memory will be filled up with ttm
pages. and then any memory allocation request w
Cloning a sync object is useful for waiting for a sync object
without locking the original structure indefinitely, blocking
other threads.
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c | 35
drivers/gpu/drm/amd/amdgpu/amdgpu_sync.h |
Signed-off-by: Felix Kuehling
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h | 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
index
On GFX7 the CP does not perform a TC flush when queues are unmapped.
To avoid TC eviction from accessing an invalid VMID, flush it
explicitly before releasing a VMID.
v2:
* Fix unnecessary list_for_each_entry_safe
Signed-off-by: Amber Lin
Signed-off-by: Felix Kuehling
---
.../gpu/drm/amd/amdkf
Use __u32 and __u64 instead of POSIX types that may not be defined
in user mode builds.
Signed-off-by: Felix Kuehling
---
include/uapi/linux/kfd_ioctl.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/uapi/linux/kfd_ioctl.h b/include/uapi/linux/kfd_ioctl.h
ind
From: Yong Zhao
The extra fields in struct kgd_mem aren't actually needed. This struct
will be used for GPUVM allocations later.
Signed-off-by: Yong Zhao
Signed-off-by: Felix Kuehling
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c | 48 ++-
This was missed in a previous commit that made the scheduler policy
a per-device setting.
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manage
Also used for cleaning up on process termination.
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdkfd/kfd_priv.h| 11 ++
drivers/gpu/drm/amd/amdkfd/kfd_process.c | 66
2 files changed, 77 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd
From: Harish Kasiviswanathan
Unaligned atomic operations can cause problems on some CPU
architectures. Use simpler bitmask operations instead. Atomic bit
manipulations are not necessary since dqm->lock is held during these
operations.
Signed-off-by: Harish Kasiviswanathan
Signed-off-by: Felix K
Simulate large-BAR system by exporting only visible memory. This
limits the amount of available VRAM to the size of the BAR, but
enables CPU access to VRAM.
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 5 +
drivers/gpu/drm/amd/amdkfd/kfd_crat.c| 3 +++
dri
Create/destroy the GPUVM context during PDD creation/destruction.
Get VM page table base and program it during process registration
(HWS) or VMID allocation (non-HWS).
v2:
* Used dev instead of pdd->dev in kfd_flush_tlb
Signed-off-by: Felix Kuehling
---
.../gpu/drm/amd/amdkfd/kfd_device_queue_m
The events page must be accessible in user mode by the GPU and CPU
as well as in kernel mode by the CPU. On dGPUs user mode virtual
addresses are managed by the Thunk's GPU memory allocation code.
Therefore we can't allocate the memory in kernel mode like we do
on APUs. But KFD still needs to map t
v2:
* Fix error handling after kfd_bind_process_to_device in
kfd_ioctl_map_memory_to_gpu
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdkfd/kfd_chardev.c| 329
drivers/gpu/drm/amd/amdkfd/kfd_priv.h | 8 +
drivers/gpu/drm/amd/include/kgd_kf
Dereferencing NULL pointers will cause a BUG anyway. No need to do
an explicit check.
Signed-off-by: Felix Kuehling
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c| 6 --
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c | 2 --
drivers/gpu/drm/amd/amdgpu
When the TTM memory manager in KGD evicts BOs, all user mode queues
potentially accessing these BOs must be evicted temporarily. Once
user mode queues are evicted, the eviction fence is signaled,
allowing the migration of the BO to proceed.
A delayed worker is scheduled to restore all the BOs belo
v2:
* Removed unused flags from struct kgd_mem
* Updated some comments
* Added a check to unmap_memory_from_gpu whether BO was mapped
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/Makefile |1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c|1 +
drivers/
Signed-off-by: Felix Kuehling
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v8.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c
b/d
Changes since v1:
* Rebased
* Several fixes
* Conditional IOMMU change carried over from previous patch series and updated
AMDGPU:
Patches 1-5 are minor cleanups and fixes
Patches 6-10 add and implement KFD->KGD interfaces for GPUVM
AMDKFD:
Patch 11: Make IOMMU conditional (carried over from prev
From: Oak Zeng
Populate DRM render device minor in kfd topology
Signed-off-by: Oak Zeng
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdkfd/kfd_topology.c | 4
drivers/gpu/drm/amd/amdkfd/kfd_topology.h | 1 +
2 files changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/amd/amd
Add GPUVM size and DRM render node. Also add function to query the
VMID mask to avoid hard-coding it in multiple places later.
v2:
* Cut off GPUVM size at the VA hole
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c | 20 ++--
drivers/gpu/drm/amd
Signed-off-by: Felix Kuehling
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c | 9 -
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v8.c | 10 --
drivers/gpu/drm/amd/include/kgd_kfd_interface.h | 2 --
3 files changed, 21 deletions(-)
diff --
dGPUs work without IOMMUv2. Make IOMMUv2 initialization dependent on
ASIC information. Also allow building KFD without IOMMUv2 support.
This is still useful for dGPUs and prepares for enabling KFD on
architectures that don't support AMD IOMMUv2.
v2:
* Centralize IOMMUv2 code to avoid #ifdefs in to
Currently the number of GPUs is limited by aperture placement options
available on GFX7 and GFX8 hardware. This limitation is not necessary.
Scratch and LDS represent per-work-item and per-work-group storage
respectively. Different work-items and work-groups use the same virtual
address to access t
Set up the GPUVM aperture for SVM (shared virtual memory) that allows
sharing a part of virtual address space between GPUs and CPUs.
Report the size of the the GPUVM size supported by KGD accurately.
The low part of the GPUVM aperture is reserved for kernel use. This is
for kernel-allocated buffe
Add helpers for allocating GPUVM memory in kernel mode and use them
to allocate memory for the CWSR trap handler.
v2:
* Use dev instead of pdd->dev in kfd_process_free_gpuvm
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdkfd/kfd_process.c | 125 +++
1 file
This fence is used by KFD to keep memory resident while user mode
queues are enabled. Trying to evict memory will trigger the
enable_signaling callback, which starts a KFD eviction, which
involves preempting user mode queues before signaling the fence.
There is one such fence per process.
v2:
* Gr
This can be used for flushing caches when not using the HWS.
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c| 55 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h| 4 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c | 1 +
driv
On 2018-02-06 03:53 AM, Oded Gabbay wrote:
> On Mon, Feb 5, 2018 at 9:00 PM, Christian König
> wrote:
>> Looks good to me on first glance.
>>
>> You probably don't mind that I'm going to pull a good part of that into
>> amdgpu as next step?
>>
> That indeed looks better then the first approach.
>
Add common smu_soc_asic_init function to emulate the sillicon post sequence
Change-Id: I6ff04e1199d1ebdbdb31d0e7e8ca3c240c61ab3a
Signed-off-by: Shaoyun Liu
---
drivers/gpu/drm/amd/amdgpu/Makefile| 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 2 ++
drivers/gpu/drm/amd/amdgpu/amdgp
> -Original Message-
> From: Liu, Shaoyun
> Sent: Tuesday, February 6, 2018 5:42 PM
> To: Deucher, Alexander
> Cc: amd-gfx list ; Bridgman, John
>
> Subject: RE: [PATCH] drm/amdgpu: Add place holder for soc15 asic init on
> emulation
>
> Thanks . Can I add Review-By you for this patch
Alternatively, you could also just return 0 in
amdgpu_atomfirmware_get_vram_width() if emu == 1. Either way:
Reviewed-by: Alex Deucher
From: amd-gfx on behalf of Shaoyun Liu
Sent: Tuesday, February 6, 2018 5:31 PM
To: amd-gfx@lists.freedesktop.org
Cc: Liu, S
Thanks . Can I add Review-By you for this patch ?
Shaoyun.liu
-Original Message-
From: Deucher, Alexander
Sent: Tuesday, February 06, 2018 5:37 PM
To: Liu, Shaoyun; Alex Deucher
Cc: amd-gfx list; Bridgman, John
Subject: RE: [PATCH] drm/amdgpu: Add place holder for soc15 asic init on
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Liu, Shaoyun
> Sent: Tuesday, February 6, 2018 5:26 PM
> To: Alex Deucher
> Cc: amd-gfx list ; Bridgman, John
>
> Subject: RE: [PATCH] drm/amdgpu: Add place holder for soc15 asic init on
> e
Change-Id: I10030e83d63b2c27bfd16b64178e4f07c13addfa
Signed-off-by: Shaoyun Liu
---
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
index 0a1868b..785fb78 100
You are right , I try to use the emu_soc_asic_init()as a entry point for any
family .
For driver to get into amdgpu_atom_asic_init() function call , it depends on
other logic like read bios and check some register etc . On emulation mode ,
we can not get bios image so it will requires mor
On Tue, Feb 6, 2018 at 4:55 PM, Liu, Shaoyun wrote:
> Ye, I try to put the asic specific register sequences for emulation in a
> separate emu_soc.c file, I think it's suggested by John or you ? The asic
> specific code will be keep in separate bring up branch , but a common place
> to add
Yes, I made that suggestion in order to make it easy for us to replace the
massive function we use in emulation with a stub function for upstream. I
figured if we had that function in a separate file it would be cleaner, but
maybe that is not the case.
I was thinking that we could replace the
Ye, I try to put the asic specific register sequences for emulation in a
separate emu_soc.c file, I think it's suggested by John or you ? The asic
specific code will be keep in separate bring up branch , but a common place
to add them seems not bad to me .
Shaoyun.liu
-Original Me
On Tue, Feb 6, 2018 at 4:41 PM, Shaoyun Liu wrote:
> Change-Id: I6ff04e1199d1ebdbdb31d0e7e8ca3c240c61ab3a
> Signed-off-by: Shaoyun Liu
What is the purpose of this? If it's just as a hint the the driver
writer as to where to add the emulation register sequences from the IP
teams, I don't see muc
Change-Id: I6ff04e1199d1ebdbdb31d0e7e8ca3c240c61ab3a
Signed-off-by: Shaoyun Liu
---
drivers/gpu/drm/amd/amdgpu/Makefile | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 2 ++
drivers/gpu/drm/amd/amdgpu/emu_soc.c | 33 +
drivers/gpu/drm/amd/amdgpu/soc15.c | 4 ++
Yes. SMU only provides enabling message.
Thanks,
Eric
On 2018-02-06 03:50 PM, Deucher, Alexander wrote:
-Original Message-
From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
Of Eric Huang
Sent: Tuesday, February 6, 2018 3:41 PM
To: amd-gfx@lists.freedesktop.org
Cc: H
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Eric Huang
> Sent: Tuesday, February 6, 2018 3:41 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Huang, JinHuiEric
> Subject: [PATCH 3/3] drm/amd/powerplay: implement
> set_mmhub_powergating_by
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Eric Huang
> Sent: Tuesday, February 6, 2018 3:41 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Huang, JinHuiEric
> Subject: [PATCH 2/3] drm/amd/powerplay: add mmhub powergating by smu
> in po
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Eric Huang
> Sent: Tuesday, February 6, 2018 3:41 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Huang, JinHuiEric
> Subject: [PATCH 1/3] drm/amdgpu: add mmhub powergating set by smu
>
> PSP w
PSP will disable legacy mmhub PG setting that is programming
registers, and drive will use SMC message to
set it up.
Signed-off-by: Eric Huang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_dpm.h| 4
drivers/gpu/drm/amd/amdgpu/mmhub_v1_0.c| 3 +++
drivers/gpu/drm/amd/include/kgd_pp_i
Signed-off-by: Eric Huang
---
drivers/gpu/drm/amd/powerplay/hwmgr/rv_hwmgr.c | 6 ++
drivers/gpu/drm/amd/powerplay/inc/rv_ppsmc.h | 3 ++-
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/rv_hwmgr.c
b/drivers/gpu/drm/amd/powerplay/hwmgr/rv_h
Signed-off-by: Eric Huang
---
drivers/gpu/drm/amd/powerplay/amd_powerplay.c | 22 ++
drivers/gpu/drm/amd/powerplay/inc/hwmgr.h | 1 +
2 files changed, 23 insertions(+)
diff --git a/drivers/gpu/drm/amd/powerplay/amd_powerplay.c
b/drivers/gpu/drm/amd/powerplay/amd_powerpl
On Tue, Feb 6, 2018 at 2:34 PM, Shaoyun Liu wrote:
> On emulation mode , driver will be loaded with powerplay disabled
>
> Change-Id: I22c343d990f9a306b033728a1cb560c1e8a4677f
> Signed-off-by: Shaoyun Liu
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c | 8 +++
On emulation mode , driver will be loaded with powerplay disabled
Change-Id: I22c343d990f9a306b033728a1cb560c1e8a4677f
Signed-off-by: Shaoyun Liu
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c | 8
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 3 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.
On Tue, Feb 6, 2018 at 7:35 AM, Dan Carpenter wrote:
> We deleted some code in e154162ef75d ("drm/amd/powerplay: refine pp code
> for raven") but there were a few related bits that were missed. Let's
> delete them as well.
>
> Signed-off-by: Dan Carpenter
Applied. Thanks!
Alex
>
> diff --git
Reviewed-by: Alex Deucher
From: amd-gfx on behalf of Tom St Denis
Sent: Tuesday, February 6, 2018 2:09 PM
To: amd-gfx@lists.freedesktop.org
Cc: StDenis, Tom
Subject: [PATCH] drm/amd/powerplay: Zero out power data in
AMDGPU_PP_SENSOR_GPU_POWER readout
Since 1
Since 12 of the 16 bytes are not initialized with anything let's ensure they're
sensibly zeroed out otherwise debugfs callers will read back garbage
(because they assume debugfs wrote sensible data back...)
Signed-off-by: Tom St Denis
---
drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c | 2 ++
Yintian,
Any plans to commit this?
Alex
On Wed, Dec 13, 2017 at 11:36 AM, Deucher, Alexander
wrote:
> This seems like a good thing to do in general even with Monk's fix.
>
>
> Acked-by: Alex Deucher
>
>
> From: amd-gfx on behalf of Yintian
> Tao
> Sent: Tuesd
We deleted some code in e154162ef75d ("drm/amd/powerplay: refine pp code
for raven") but there were a few related bits that were missed. Let's
delete them as well.
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/amd/powerplay/inc/hwmgr.h
b/drivers/gpu/drm/amd/powerplay/inc/hwmgr.h
in
Move the new call out of ttm_mem_global_reserve() and into
ttm_page_alloc.c or ttm_page_alloc_dma.c (but keep it in ttm_memory.c).
ttm_mem_global_reserve() is called for each page allocated and
si_mem_available() is a bit to heavy for that.
Good idea! Agree with you completely, bec
Nice work, but a few comments.
First of all you need to reorder the patches. Adding the exceptions to
the restrictions should come first, then the restriction itself.
Otherwise we might break a setup in between the patches and that is bad
for bisecting.
Then make all values configurable, e.g
if true for it, allocate TTM pages regardless of zone global memory
account limit.
that is for another special case: suspend.
doesn't care the zone global memory account limit for this case.
Signed-off-by: Roger He
---
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 2 +-
drivers/gpu/drm/amd/amd
set TTM_OPT_FLAG_ALLOW_ALLOC_ANYWAY when we are servicing for page
fault routine.
for ttm_mem_global_reserve if in page fault routine, allow the gtt
pages reservation always. because page fault routing already grabbed
system memory and the allowance of this exception is harmless.
Otherwise, it wil
for saving memory and more bit flag can be used in future
Signed-off-by: Roger He
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 4 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 4 ++--
drivers/gpu/drm/ttm/ttm_bo.c | 3 ++-
include/drm/ttm/ttm_bo_api.h | 7 +
for avoid OOM. if free swap space is less than 256MB, reject
the TTM page allocation. Otherwise, swap space will be full
of swapped pages and then system memory will be filled up
with ttm pages. and then any memory allocation request will
trigger OOM.
to cover two cases:
a. If total swap space > 2
set the no_retry flag in struct ttm_mem_global and init it
after ttm_mem_global_init
Signed-off-by: Roger He
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 8 +---
drivers/gpu/drm/ttm/ttm_memory.c| 3 +++
include/drm/ttm/ttm_memory.h| 3 +++
3 files changed, 11 insertions(
currently ttm code has no any allocation limit. So it allows pages
allocatation unlimited until OOM. Because if swap space is full
of swapped pages and then system memory will be filled up with ttm
pages. and then any memory allocation request will trigger OOM.
the following patches is for preve
On Mon, Feb 5, 2018 at 9:00 PM, Christian König
wrote:
> Looks good to me on first glance.
>
> You probably don't mind that I'm going to pull a good part of that into
> amdgpu as next step?
>
That indeed looks better then the first approach.
Felix, I've applied all other patches from the dGPU top
On Wed, Jan 31, 2018 at 6:27 PM, Felix Kuehling wrote:
> On 2018-01-31 10:29 AM, Oded Gabbay wrote:
>> On Wed, Jan 31, 2018 at 5:23 PM, Deucher, Alexander
>> wrote:
>>>
>>> From: amd-gfx on behalf of Oded
>>> Gabbay
>>> Sent: Wednesday, January 31, 2018 10:17 AM
65 matches
Mail list logo