On 08/28/2018 08:40 PM, Emily Deng wrote:
Fix the VMC page fault when the running sequence is as below:
1.amdgpu_gem_create_ioctl
2.ttm_bo_swapout->amdgpu_vm_bo_invalidate, as not called
amdgpu_vm_bo_base_init, so won't called
list_add_tail(>bo_list, >va). Even the bo was evicted,
it won't set
>-Original Message-
>From: amd-gfx On Behalf Of
>zhoucm1
>Sent: Wednesday, August 29, 2018 10:12 AM
>To: Koenig, Christian ; Deng, Emily
>; amd-gfx@lists.freedesktop.org
>Subject: Re: [PATCH] drm/amdgpu: Need to set moved to true when evict bo
>
>
>
>On 2018年08月28日 20:47, Christian König
On 2018年08月28日 20:47, Christian König wrote:
Am 28.08.2018 um 14:40 schrieb Emily Deng:
Fix the VMC page fault when the running sequence is as below:
1.amdgpu_gem_create_ioctl
2.ttm_bo_swapout->amdgpu_vm_bo_invalidate, as not called
amdgpu_vm_bo_base_init, so won't called
On 08/28/2018 08:17 PM, Christian König wrote:
Correct sign extend the GMC addresses to 48bit.
Could you explain a bit more why to extend the sign?
the address is uint64_t. is if failed in some case?
> -/* VA hole for 48bit addresses on Vega10 */
> -#define AMDGPU_VA_HOLE_START
On 08/28/2018 05:27 PM, Michel Dänzer wrote:
From: Michel Dänzer
Doing it earlier hits a WARN_ON_ONCE in amdgpu_bo_gpu_offset.
Fixes: "drm/amdgpu: remove gart.table_addr"
Signed-off-by: Michel Dänzer
Reviewed-by: Junwei Zhang
---
drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c | 5 -
Approach 3 seems not workable since we do not know the default value.
I would prefer approach 1 if we have to fit into original APIs. There needs
three pairs of to recalculate the voltage curve. Instead of
silently calucating dpm_mid_leve’s offset in our driver, i would prefer to have
it
Move some KFD-related (but used in amdgpu_drv.c) definitions from
kfd_priv.h to kgd_kfd_interface.h so we don't need to include kfd_priv.h
in amdgpu_drv.c. This fixes a build failure when AMDGPU is enabled but
MMU_NOTIFIER is not.
This patch also disables KFD-related module options when HSA_AMD is
This caused a confusing error message, but there is functionally
no problem since the default method is DIRECT.
Signed-off-by: Alex Deucher
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c | 1 +
1 file changed, 1 insertion(+)
diff --git
See one more comment inline. With that fixed, the series is Reviewed-by:
Felix Kuehling
Regards,
Felix
On 2018-08-28 01:34 PM, Oak Zeng wrote:
> To make a amdgpu vm to a compute vm, the old pasid will be freed and
> replaced with a pasid managed by kfd. Kfd can't reuse original pasid
>
Hi,
I am running vanilla 4.18 kernel and I noticed that whenever I boot Windows 10,
the card fans are off, unless I start to utilize the GPU. On Linux however the
fans are always on around 400-800 rpm, while card takes about 36W according to
sensors interface.
I can manually force the fan
On 2018-08-28 08:20 AM, Christian König wrote:
> Not used any more.
>
> Signed-off-by: Christian König
Reviewed-by: Felix Kuehling
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 13 -
> 1 file changed, 13 deletions(-)
>
> diff --git
The GPU always has access to the entire guest physical address space.
You can just program arbitrary addresses into page table entries and set
the system bit. That's how GART and GPUVM mappings work. They will not
go through the AGP aperture. And there is no mechanism (other than an
IOMMU) to
On 2018-08-28 02:53 AM, Christian König wrote:
> Am 28.08.2018 um 06:21 schrieb zhoucm1:
>>
>>
>> On 2018年08月28日 03:03, Felix Kuehling wrote:
>>> The point of this series seems to be to allow access to small system
>>> memory BOs (one page) without a GART mapping. I'm guessing that reduces
>>>
For compute vm acquired from amdgpu, vm.pasid is managed
by kfd. Decouple pasid from such vm on process destroy
to avoid duplicate pasid release.
Signed-off-by: Oak Zeng
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h| 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c | 1 +
To make a amdgpu vm to a compute vm, the old pasid will be freed and
replaced with a pasid managed by kfd. Kfd can't reuse original pasid
allocated by amdgpu because kfd uses different pasid policy with amdgpu.
For example, all graphic devices share one same pasid in a process.
Signed-off-by: Oak
On Tue, Aug 28, 2018 at 12:35 PM Zhu, Rex wrote:
>
> Got it. Thanks Alex.
>
>
>
> I think we can simplify the od_clk_voltage on vega20.
>
>
>
> When user cat pp_od_clk_voltage
>
> The output can be simplified as:
>
>
>
> Sclk:
>
> 0 clock_value voltage_offset
>
> 7 clock_value
This is the next version of my patch series for teaching DRM how to
automatically create debugfs nodes for drivers with MST topologies. This
was originally intended just for nouveau, but has since been expanded to
all DRM drivers.
Changes since previous version:
- Fix documentation error that
There's no actual reason we pass the connector ID instead of a pointer
to the connector itself, and we're going to need the entire connector
(but only temporarily) in order to name MST debugfs folders properly
since connector IDs can't be looked up until the driver has been
registered with
On 2018-08-28 11:14 a.m., Michel Dänzer wrote:
>
> Hi Ray,
>
>
> On 2018-08-22 9:52 a.m., Huang Rui wrote:
>> The new bulk moving functionality is ready, the overhead of moving PD/PT bos
>> to
>> LRU is fixed. So move them on LRU again.
>>
>> Signed-off-by: Huang Rui
>> Tested-by: Mike
Got it. Thanks Alex.
I think we can simplify the od_clk_voltage on vega20.
When user cat pp_od_clk_voltage
The output can be simplified as:
Sclk:
0 clock_value voltage_offset
7 clock_valuevoltage_offset
Mclk
3 mclk_value
Range:
sclk {min, max}
mclk {min, max}
voltage{min, max}
for
Right. I'm saying use the same sysfs file (pp_od_clk_voltage) for all devices
rather than adding a new one. The output of reading that file will be
different on each asic that supports a different way of adjusting the clock and
voltage parameters and the supported inputs will be different.
Hi Alex,
Sorry, i cannot get your point.
The OD feature sysfs file used by previous ASICs is "pp_od_clk_voltage". And it
binds to two APIs "amdgpu_get_pp_od_clk_voltage" and
"amdgpu_set_pp_od_clk_voltage".
static DEVICE_ATTR(pp_od_clk_voltage, S_IRUGO | S_IWUSR,
On Tue, Aug 28, 2018 at 6:26 AM Rex Zhu wrote:
>
> change function name gfx_v6/7/8/9_0_gpu_init to
> gfx_v6/7/8/9_0_constants_init.
> this function is just for init gfx constants such
> as max pipes, render backends...
>
> Signed-off-by: Rex Zhu
Reviewed-by: Alex Deucher
> ---
>
Yes, this is a bug fix for multi monitor case. Without this, we may have
trouble to light up multi monitors.
Regards,
Evan
From: Deucher, Alexander
Sent: Tuesday, August 28, 2018 10:19:30 PM
To: Samuel Pitoiset; Quan, Evan
Cc: Zhu, Rex;
Good point. I also planned to do it the way you suggested.
Sent from my iPad
On 2018-08-28, at 7:21 AM, Christian König
wrote:
> Am 27.08.2018 um 22:45 schrieb Oak Zeng:
>> For compute vm acquired from amdgpu, vm.pasid is managed
>> by kfd. Decouple pasid from such vm on process destroy
>> to
IIRC, this was a dpm bug fix, such that prior to the patch, the mclk would
never drop below 500Mhz or something like that and after the fix, it goes down
to the lowest frequency. The dpm heuristics are not a perfect match for some
games.
Alex
From: amd-gfx
On 2018-08-28 2:20 p.m., Christian König wrote:
> Not used any more.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 13 -
> 1 file changed, 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
>
I use a defconfig + enable AMDGPU
$ grep AMDGPU .config
CONFIG_DRM_AMDGPU=m
CONFIG_DRM_AMDGPU_SI=y
CONFIG_DRM_AMDGPU_CIK=y
# CONFIG_DRM_AMDGPU_USERPTR is not set
# CONFIG_DRM_AMDGPU_GART_DEBUGFS is not set
Tom
On 08/28/2018 09:28 AM, Lin, Amber wrote:
Hi Tom,
May I ask which config I can use
Hi Tom,
May I ask which config I can use to see the issue? I used x86_64_defconfig
before I submit the patch.
I'll check immediately. Thanks for the notice.
Amber
-Original Message-
From: StDenis, Tom
Sent: Tuesday, August 28, 2018 9:19 AM
To: Lin, Amber
Cc:
Hi Amber,
This commit:
commit 7c3a4287bfc05a26baa9d32d060feffe387b9b84 (HEAD ->
amd-staging-drm-next, origin/amd-staging-drm-next, origin/HEAD)
Author: Amber Lin
Date: Thu Aug 23 10:52:34 2018 -0400
drm/amdgpu: Move KFD parameters to amdgpu
After merging KFD into amdgpu, move
Hi Lyude,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v4.19-rc1 next-20180828]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci
Am 28.08.2018 um 14:40 schrieb Emily Deng:
Fix the VMC page fault when the running sequence is as below:
1.amdgpu_gem_create_ioctl
2.ttm_bo_swapout->amdgpu_vm_bo_invalidate, as not called
amdgpu_vm_bo_base_init, so won't called
list_add_tail(>bo_list, >va). Even the bo was evicted,
it won't set
Fix the VMC page fault when the running sequence is as below:
1.amdgpu_gem_create_ioctl
2.ttm_bo_swapout->amdgpu_vm_bo_invalidate, as not called
amdgpu_vm_bo_base_init, so won't called
list_add_tail(>bo_list, >va). Even the bo was evicted,
it won't set the bo_base->moved.
Not used any more.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 13 -
1 file changed, 13 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
index 18945dd6982d..907fdf46d895 100644
---
Correct sign extend the GMC addresses to 48bit.
v2: sign extending turned out easier than thought.
v3: clean up the defines and move them into amdgpu_gmc.h as well
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
Hi there,
I found a performance regression that affects my Vega10 with Dawn Of War
III and RADV (ie. 74FPS -> 71FPS). I bisected to:
commit ea7f492b6ac6eced0d09ccb2b0a2909a0025e22e
Author: Evan Quan
Date: Mon Jul 16 17:23:19 2018 +0800
drm/amd/powerplay: correct the argument for
Am 27.08.2018 um 20:50 schrieb Felix Kuehling:
On 2018-08-27 12:53 PM, Christian König wrote:
Helper to figure out the location of the AGP BAR.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c | 42 +
drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.h
Am 28.08.2018 um 04:52 schrieb Zhang, Jerry (Junwei):
On 08/28/2018 12:53 AM, Christian König wrote:
Enable the old AGP aperture to avoid GART mappings.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/gfxhub_v1_0.c | 10 +-
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c |
Well that is indeed true, but we still have IOMMU between the GPU and
the system memory.
So we should still catch issues when something goes terrible wrong.
Additional to that only the system domain, e.g. kernel copies, page
table updates etc are allowed to use it.
Regards,
Christian.
Am
Correct sign extend the GMC addresses to 48bit.
v2: sign extending turned out easier than thought.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
Am 28.08.2018 um 11:27 schrieb Michel Dänzer:
From: Michel Dänzer
Doing it earlier hits a WARN_ON_ONCE in amdgpu_bo_gpu_offset.
Fixes: "drm/amdgpu: remove gart.table_addr"
Signed-off-by: Michel Dänzer
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c | 5 -
Am 27.08.2018 um 22:45 schrieb Oak Zeng:
For compute vm acquired from amdgpu, vm.pasid is managed
by kfd. Decouple pasid from such vm on process destroy
to avoid duplicate pasid release.
Signed-off-by: Oak Zeng
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h| 1 +
Reviewed-by: Christian König
Am 27.08.2018 um 21:25 schrieb Marek Olšák:
Reviewed-by: Marek Olšák
Marek
On Mon, Aug 27, 2018 at 2:55 PM, Alex Deucher wrote:
On Mon, Aug 27, 2018 at 2:23 PM Andrey Grodzovsky
wrote:
The fault reports the page number where the fault happend and not
the
change function name gfx_v6/7/8/9_0_gpu_init to
gfx_v6/7/8/9_0_constants_init.
this function is just for init gfx constants such
as max pipes, render backends...
Signed-off-by: Rex Zhu
---
drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c | 4 ++--
drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c | 10 +-
From: Michel Dänzer
Doing it earlier hits a WARN_ON_ONCE in amdgpu_bo_gpu_offset.
Fixes: "drm/amdgpu: remove gart.table_addr"
Signed-off-by: Michel Dänzer
---
drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c | 5 -
drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c | 5 -
Hi Ray,
On 2018-08-22 9:52 a.m., Huang Rui wrote:
> The new bulk moving functionality is ready, the overhead of moving PD/PT bos
> to
> LRU is fixed. So move them on LRU again.
>
> Signed-off-by: Huang Rui
> Tested-by: Mike Lothian
> Tested-by: Dieter Nützel
> Acked-by: Chunming Zhou
>
To make a amdgpu vm to a compute vm, the old pasid will be freed and
replaced with a pasid managed by kfd. Kfd can't reuse original pasid
allocated by amdgpu because kfd uses different pasid policy with amdgpu.
For example, all graphic devices share one same pasid in a process.
Signed-off-by: Oak
For compute vm acquired from amdgpu, vm.pasid is managed
by kfd. Decouple pasid from such vm on process destroy
to avoid duplicate pasid release.
Signed-off-by: Oak Zeng
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h| 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c | 1 +
I mean it has risk to make GPU allowed to access to most system memory without
explicit claiming, it's easier to mask problem.
Regards,
Jack
-Original Message-
From: Koenig, Christian
Sent: Tuesday, August 28, 2018 2:46 PM
To: Xiao, Jack ; Kuehling, Felix ;
Christian König ;
Am 28.08.2018 um 06:21 schrieb zhoucm1:
On 2018年08月28日 03:03, Felix Kuehling wrote:
The point of this series seems to be to allow access to small system
memory BOs (one page) without a GART mapping. I'm guessing that reduces
pressure on the GART and removes the need for HDP and TLB flushes.
I
This series patches seems to make AGP aperture allowed to access any system
memory (16GB) bypass GPU VM protection.
The system aperture should only be active in the system domain, or
otherwise applications would have access to local memory as well.
There are some bits in the VM registers to
51 matches
Mail list logo
