On 2019-02-04 3:17 p.m., Kuehling, Felix wrote:
> This may cause regressions in KFD if PT BO allocation can trigger
> eviction fences. The previous call to amdgpu_vm_alloc_pts was in a
> context where we had temporarily removed the eviction fence. PT BO
> allocation in amdgpu_vm_bo_update is not
On Mon, 4 Feb 2019 at 19:59, wrote:
>
> Sorry to pop in the bug report.
>
> I run git linux(amd-staging-drm-next), drm, llvm (erk!), mesa-gl, mesa-vulkan,
> xserver, xf86-video-amdgpu from yesterday, that on AMD tahiti xt.
>
> I have run dota 2 vulkan, artifact (vulkan), cs:go (still opengl)
On 2019-02-04 9:32 a.m., Nicholas Kazlauskas wrote:
> [Why]
> When CONFIG_DEBUG_FS isn't defined then amdgpu_dm_crtc_set_crc_source
> is NULL. This causes a compilation error since it's being called
> unconditionally.
>
> [How]
> Guard the call based on CONFIG_DEBUG_FS - CRC capture isn't
On 2019-02-04 7:42 a.m., Christian König wrote:
> No functional change.
>
> Signed-off-by: Christian König
Minor indentation issue inline. With that fixed, this patch is
Reviewed-by: Felix Kuehling
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 16
> 1 file changed, 8
On 2019-02-04 7:42 a.m., Christian König wrote:
> Otherwise we open up the possibility to use uninitialized memory.
>
> Signed-off-by: Christian König
This patch is Reviewed-by: Felix Kuehling
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 7 ++-
> 1 file changed, 6 insertions(+), 1
On Mon, Feb 4, 2019 at 3:05 PM Kasiviswanathan, Harish
wrote:
>
> >
> > For e.g. In my machine the hierarchy looks as shown below. The current code
> > only looks at the top 2 and decides incorrectly as Gen 4.
> >
> > amdgpu :07:00.0: lnksta:1103 lnkcap2:180001e lnkcap:400d04 --
> >
This may cause regressions in KFD if PT BO allocation can trigger
eviction fences. The previous call to amdgpu_vm_alloc_pts was in a
context where we had temporarily removed the eviction fence. PT BO
allocation in amdgpu_vm_bo_update is not protected like that.
I vaguely remember looking into
>
> For e.g. In my machine the hierarchy looks as shown below. The current code
> only looks at the top 2 and decides incorrectly as Gen 4.
>
> amdgpu :07:00.0: lnksta:1103 lnkcap2:180001e lnkcap:400d04 --
> PCIE_SPEED_16_0GT - Gen 4
> pcieport :06:00.0: lnksta:7103 lnkcap2:180001e
On Tue, 5 Feb 2019 at 04:35, Alex Deucher wrote:
>
> On Sun, Feb 3, 2019 at 11:57 PM Dave Airlie wrote:
> >
> > On Mon, 4 Feb 2019 at 13:27, Dave Airlie wrote:
> > >
> > > On Sat, 26 Jan 2019 at 09:15, Alex Deucher wrote:
> > > >
> > > > Hi Dave, Daniel,
> > > >
> > > > New stuff for 5.1.
> >
On Mon, Feb 4, 2019 at 12:55 PM Kasiviswanathan, Harish
wrote:
>
> Hi Alex,
>
> I already have that patch in my code. The function
> amdgpu_device_get_pcie_info() updates platform caps
> (CAIL_PCIE_LINK_SPEED_SUPPORT_GEN*) based on pcie_get_speed_cap() of the bus
> AMD GPU is connected. I
On Sun, Feb 3, 2019 at 11:57 PM Dave Airlie wrote:
>
> On Mon, 4 Feb 2019 at 13:27, Dave Airlie wrote:
> >
> > On Sat, 26 Jan 2019 at 09:15, Alex Deucher wrote:
> > >
> > > Hi Dave, Daniel,
> > >
> > > New stuff for 5.1.
> > > amdgpu:
> > > - DC bandwidth formula updates
> > > - Support for DCC
Replace our MMU notifier with hmm_mirror_ops.sync_cpu_device_pagetables
callback. Enable CONFIG_HMM and CONFIG_HMM_MIRROR as a dependency in
DRM_AMDGPU_USERPTR Kconfig.
It supports both KFD userptr and gfx userptr paths.
Change-Id: Ie62c3c5e3c5b8521ab3b438d1eff2aa2a003835e
Signed-off-by: Philip
Hi Christian,
This patch is rebased to lastest HMM. Please review the GEM and CS part changes
in patch 3/3.
Thanks,
Philip Yang (3):
drm/amdgpu: use HMM mirror callback to replace mmu notifier v7
drm/amdkfd: avoid HMM change cause circular lock dependency v2
drm/amdgpu: replace
Use HMM helper function hmm_vma_fault() to get physical pages backing
userptr and start CPU page table update track of those pages. Then use
hmm_vma_range_done() to check if those pages are updated before
amdgpu_cs_submit for gfx or before user queues are resumed for kfd.
If userptr pages are
There is circular lock between gfx and kfd path with HMM change:
lock(dqm) -> bo::reserve -> amdgpu_mn_lock
To avoid this, move init/unint_mqd() out of lock(dqm), to remove nested
locking between mmap_sem and bo::reserve. The locking order
is: bo::reserve -> amdgpu_mn_lock(p->mn)
Change-Id:
Am 04.02.19 um 18:17 schrieb Yang, Philip:
On 2019-02-04 10:18 a.m., Christian König wrote:
Am 04.02.19 um 16:06 schrieb Yang, Philip:
Replace our MMU notifier with hmm_mirror_ops.sync_cpu_device_pagetables
callback. Enable CONFIG_HMM and CONFIG_HMM_MIRROR as a dependency in
Hi Alex,
I already have that patch in my code. The function
amdgpu_device_get_pcie_info() updates platform caps
(CAIL_PCIE_LINK_SPEED_SUPPORT_GEN*) based on pcie_get_speed_cap() of the bus
AMD GPU is connected. I think to get the system caps going up just one level in
PCI hierarchy is not
Den 04.02.2019 16.41, skrev Daniel Vetter:
> On Sun, Feb 03, 2019 at 04:41:56PM +0100, Noralf Trønnes wrote:
>> The only thing now that makes drm_dev_unplug() special is that it sets
>> drm_device->unplugged. Move this code to drm_dev_unregister() so that we
>> can remove drm_dev_unplug().
>>
>>
>then we should probably use 1024 for mmCP_MEC_DOORBELL_RANGE_UPPER.
This is also what I thought.
Thanks,
Oak
From: Zhao, Yong
Sent: Monday, February 4, 2019 12:28 PM
To: Zeng, Oak ; Kuehling, Felix ;
amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH 2/3] drm/amdkfd: Fix bugs regarding CP user
The decision we need to make here is which value we should program
mmCP_MEC_DOORBELL_RANGE_UPPER. It is not very consistent right now throughout
our code. If we let CP to use all the doorbells left over by SDMA, IH and VCN,
then we should probably use 1024 for mmCP_MEC_DOORBELL_RANGE_UPPER. If
On 2019-02-04 10:18 a.m., Christian König wrote:
> Am 04.02.19 um 16:06 schrieb Yang, Philip:
>> Replace our MMU notifier with hmm_mirror_ops.sync_cpu_device_pagetables
>> callback. Enable CONFIG_HMM and CONFIG_HMM_MIRROR as a dependency in
>> DRM_AMDGPU_USERPTR Kconfig.
>>
>> It supports both
Correct. MEC_DOORBELL_RANGE should cover both user and kernel CP
(KIQ/HIQ/DIQ/amdgpu kernel MEC rings)queues. USERQUEUE_START/END should be
renamed to USER_CP_QUEUE_START/END.
Thanks,
Oak
-Original Message-
From: Kuehling, Felix
Sent: Monday, February 4, 2019 11:35 AM
To: Zeng, Oak ;
On Mon, Feb 4, 2019 at 11:09 AM Koenig, Christian
wrote:
>
> Am 04.02.19 um 16:55 schrieb Marek Olšák:
>
> On Mon, Feb 4, 2019 at 7:42 AM Christian König
> wrote:
>>
>> At least from coding style, backward compatibility etc.. this looks sane to
>> me, so feel free to add an Acked-by.
>>
>> But
I don't see anything about userqueue start/end in Yong's patch. That
said, I think you're mixing up two different things. MEC_DOORBELL_RANGE
is not the same as userqueues? We have MEC kernel queues as well that
would have to fall in the same range. And we have SDMA user queues that
don't
On Mon, Feb 04, 2019 at 03:43:36PM +, Wentland, Harry wrote:
> DRM actually bumped this to 32 due to an issue with a Dell 4k display.
As I feared there is a retry counter higher in the code. My bad.
> It depends. I wouldn't call one or the other more correct. I seem to remember
> that the DP
Am 04.02.19 um 16:55 schrieb Marek Olšák:
On Mon, Feb 4, 2019 at 7:42 AM Christian König
mailto:ckoenig.leichtzumer...@gmail.com>>
wrote:
At least from coding style, backward compatibility etc.. this looks sane to me,
so feel free to add an Acked-by.
But I absolutely can't judge if that is
FYI, when I push this, I'll bump the DRM version.
Marek
On Mon, Feb 4, 2019 at 10:55 AM Marek Olšák wrote:
> On Mon, Feb 4, 2019 at 7:42 AM Christian König <
> ckoenig.leichtzumer...@gmail.com> wrote:
>
>> At least from coding style, backward compatibility etc.. this looks sane
>> to me, so
Reviewed-by: Roman Li
-Original Message-
From: amd-gfx On Behalf Of S, Shirish
Sent: Monday, February 4, 2019 4:20 AM
To: Li, Sun peng (Leo) ; Wu, Hersen ;
Wentland, Harry
Cc: amd-gfx@lists.freedesktop.org; S, Shirish
Subject: [PATCH] drm/amd/display: Use context parameters to enable
On Mon, Feb 4, 2019 at 7:42 AM Christian König <
ckoenig.leichtzumer...@gmail.com> wrote:
> At least from coding style, backward compatibility etc.. this looks sane
> to me, so feel free to add an Acked-by.
>
> But I absolutely can't judge if that is correct from the hardware point of
> view or
On 2019-02-04 4:20 a.m., S, Shirish wrote:
> [What]
> FBC fails to get enabled when switched between LINEAR(console/VT)
> and non-LINEAR(GUI) based rendering due to default value of
> tiling info stored in the current_state which is used for deciding
> whether or not to turn FBC on or off.
>
>
From: amd-gfx on behalf of Bhawanpreet
Lakha
Sent: February 4, 2019 10:45 AM
To: amd-gfx@lists.freedesktop.org
Cc: Sun, Yongqiang
Subject: [PATCH 15/35] drm/amd/display: pass vline_config parameter by
reference.
From: Yongqiang Sun
Change-Id:
From: Yongqiang Sun
Change-Id: Icfe018c7579ad2b3ef65195f578b8e44422d53f3
Signed-off-by: Yongqiang Sun
Reviewed-by: Aric Cyr
Acked-by: Bhawanpreet Lakha
---
drivers/gpu/drm/amd/display/dc/core/dc.c | 4 ++--
drivers/gpu/drm/amd/display/dc/dcn10/dcn10_optc.c| 8
Thanks, I will update, add your RB and push.
Andrey
On 2/3/19 10:51 AM, Koenig, Christian wrote:
@@ -1090,6 +1091,14 @@ static int amdgpu_cs_process_fence_dep(struct
amdgpu_cs_parser *p,
fence = amdgpu_ctx_get_fence(ctx, entity,
On 2019-02-01 5:55 p.m., sylvain.bertr...@gmail.com wrote:
> On Fri, Feb 01, 2019 at 09:20:56PM +, Wentland, Harry wrote:
>> DRM's AUX code uses usleep_range in drm_dp_dpcd_access.
>
> My bad, forgot about the usleep_range switch. That said AUX_RETRY_INTERVAL is
> 500 us, with a usleep_range
On Sun, Feb 03, 2019 at 04:41:56PM +0100, Noralf Trønnes wrote:
> The only thing now that makes drm_dev_unplug() special is that it sets
> drm_device->unplugged. Move this code to drm_dev_unregister() so that we
> can remove drm_dev_unplug().
>
> Signed-off-by: Noralf Trønnes
> ---
>
> Maybe
On 2/4/19 7:49 AM, Koenig, Christian wrote:
> Am 04.02.19 um 13:44 schrieb S, Shirish:
>> vce ring test fails during resume since mmVCE_RB_RPTR*
>> is not intitalized/updated.
>>
>> Hence start vce block before ring test.
> Mhm, I wonder why this ever worked. But yeah, same problem seems to
>
Am 04.02.19 um 16:06 schrieb Yang, Philip:
Replace our MMU notifier with hmm_mirror_ops.sync_cpu_device_pagetables
callback. Enable CONFIG_HMM and CONFIG_HMM_MIRROR as a dependency in
DRM_AMDGPU_USERPTR Kconfig.
It supports both KFD userptr and gfx userptr paths.
The depdent HMM patchset from
There is circular lock between gfx and kfd path with HMM change:
lock(dqm) -> bo::reserve -> amdgpu_mn_lock
To avoid this, move init/unint_mqd() out of lock(dqm), to remove nested
locking between mmap_sem and bo::reserve. The locking order
is: bo::reserve -> amdgpu_mn_lock(p->mn)
Change-Id:
Use HMM helper function hmm_vma_fault() to get physical pages backing
userptr and start CPU page table update track of those pages. Then use
hmm_vma_range_done() to check if those pages are updated before
amdgpu_cs_submit for gfx or before user queues are resumed for kfd.
If userptr pages are
Replace our MMU notifier with hmm_mirror_ops.sync_cpu_device_pagetables
callback. Enable CONFIG_HMM and CONFIG_HMM_MIRROR as a dependency in
DRM_AMDGPU_USERPTR Kconfig.
It supports both KFD userptr and gfx userptr paths.
The depdent HMM patchset from Jérôme Glisse are all merged into 4.20.0
Hi Christian,
This patch is rebased to lastest HMM. Please review the GEM and CS part changes
in patch 3/3.
Regards,
Philip Yang (3):
drm/amdgpu: use HMM mirror callback to replace mmu notifier v6
drm/amdkfd: avoid HMM change cause circular lock dependency v2
drm/amdgpu: replace
> > List of tested application:
> > - Rise of the Tomb Raider
Sorry to pop in the bug report.
I run git linux(amd-staging-drm-next), drm, llvm (erk!), mesa-gl, mesa-vulkan,
xserver, xf86-video-amdgpu from yesterday, that on AMD tahiti xt.
I have run dota 2 vulkan, artifact (vulkan), cs:go
[Why]
When CONFIG_DEBUG_FS isn't defined then amdgpu_dm_crtc_set_crc_source
is NULL. This causes a compilation error since it's being called
unconditionally.
[How]
Guard the call based on CONFIG_DEBUG_FS - CRC capture isn't supported
without this.
Cc: Leo Li
Cc: Harry Wentland
Fixes:
On 2/3/19 5:42 PM, Noralf Trønnes wrote:
> There are no users left.
>
> Signed-off-by: Noralf Trønnes
Reviewed-by: Oleksandr Andrushchenko
> ---
> drivers/gpu/drm/drm_drv.c | 17 -
> include/drm/drm_drv.h | 1 -
> 2 files changed, 18 deletions(-)
>
> diff --git
On 2/3/19 5:41 PM, Noralf Trønnes wrote:
> drm_dev_unplug() has been stripped down and is going away. Open code its
> 2 remaining function calls.
>
> Also remove the drm_dev_is_unplugged() check since this can't be true
> before drm_dev_unregister() is called which happens after the check.
>
> Cc:
On 2/3/19 5:41 PM, Noralf Trønnes wrote:
> The only thing now that makes drm_dev_unplug() special is that it sets
> drm_device->unplugged. Move this code to drm_dev_unregister() so that we
> can remove drm_dev_unplug().
>
> Signed-off-by: Noralf Trønnes
Reviewed-by: Oleksandr Andrushchenko
> ---
On 2/3/19 5:41 PM, Noralf Trønnes wrote:
> If userspace has open fd(s) when drm_dev_unplug() is run, it will result
> in drm_dev_unregister() being called twice. First in drm_dev_unplug() and
> then later in drm_release() through the call to drm_put_dev().
>
> Since userspace already holds a ref
+ Roman
-Original Message-
From: S, Shirish
Sent: Monday, February 4, 2019 4:20 AM
To: Li, Sun peng (Leo) ; Wu, Hersen ;
Wentland, Harry
Cc: amd-gfx@lists.freedesktop.org; S, Shirish
Subject: [PATCH] drm/amd/display: Use context parameters to enable FBC
[What]
FBC fails to get
Den 04.02.2019 11.42, skrev Oleksandr Andrushchenko:
> On 2/3/19 5:41 PM, Noralf Trønnes wrote:
>> drm_dev_unplug() has been stripped down and is going away. Open code its
>> 2 remaining function calls.
>>
>> Also remove the drm_dev_is_unplugged() check since this can't be true
>> before
Clear the VM PDs/PTs only after initializing all the structures.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
No functional change.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index 44950f3b8801..69b0bee0661e
Otherwise we open up the possibility to use uninitialized memory.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
This way we only deal with the real BO in here.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 64 --
1 file changed, 39 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
When something is unmapped we now free the affected PDs/PTs again.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 71 +++---
1 file changed, 53 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
Adding Andrey who looked into cleaning this up a while ago as well.
Christian.
Am 03.02.19 um 16:41 schrieb Noralf Trønnes:
> This series removes drm_dev_unplug() and moves the unplugged state
> setting to drm_dev_unregister(). All drivers will now have access to the
> unplugged state if they so
Am 04.02.19 um 13:44 schrieb S, Shirish:
> vce ring test fails during resume since mmVCE_RB_RPTR*
> is not intitalized/updated.
>
> Hence start vce block before ring test.
Mhm, I wonder why this ever worked. But yeah, same problem seems to
exits for VCE 2 as well.
Leo any comment on this?
vce ring test fails during resume since mmVCE_RB_RPTR*
is not intitalized/updated.
Hence start vce block before ring test.
Signed-off-by: Shirish S
---
* vce_v4_0.c's hw_init sequence already has this change.
drivers/gpu/drm/amd/amdgpu/vce_v3_0.c | 4
1 file changed, 4 insertions(+)
Let's start to allocate VM PDs/PTs on demand instead of pre-allocating
them during mapping.
Signed-off-by: Christian König
---
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 6 -
drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c | 9 --
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 10 --
Not needed any more since we now free PDs/PTs on demand.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 14 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h | 1 -
2 files changed, 1 insertion(+), 14 deletions(-)
diff --git
At least from coding style, backward compatibility etc.. this looks sane
to me, so feel free to add an Acked-by.
But I absolutely can't judge if that is correct from the hardware point
of view or not.
And I think that somebody else looking at this is mandatory for it to be
committed.
Instead of providing it from outside figure out the ats status in the
function itself from the data structures.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 52 ++
1 file changed, 29 insertions(+), 23 deletions(-)
diff --git
On 2019-02-03 4:17 a.m., Kenneth Feng wrote:
> This reverts commit ea37fc706e4cde83b39ad2104eec0241e752b8ea.
> Since we have another patch to fix the below problem,
> we need to revert the 'revert'
> https://bugs.freedesktop.org/show_bug.cgi?id=109462
> Acked by Alex Deucher
>
> Signed-off-by:
On 2019-02-03 7:15 p.m., Mikhail Gavrilov wrote:
> Hi folks.
> Today I tried update mesa to 19.0.0~rc1 version, but after update all
> vulkan based application stop working.
>
> List of tested application:
> - Rise of the Tomb Raider
> - F1 2017
> - Any game launched via steam play DXVK
> -
On Sun, Feb 03, 2019 at 04:41:54PM +0100, Noralf Trønnes wrote:
> This series removes drm_dev_unplug() and moves the unplugged state
> setting to drm_dev_unregister(). All drivers will now have access to the
> unplugged state if they so desire.
>
> The drm_device ref handling wrt to the last fd
[What]
FBC fails to get enabled when switched between LINEAR(console/VT)
and non-LINEAR(GUI) based rendering due to default value of
tiling info stored in the current_state which is used for deciding
whether or not to turn FBC on or off.
[How]
Use context structure's tiling information which is
Hi folks.
Today I tried update mesa to 19.0.0~rc1 version, but after update all
vulkan based application stop working.
List of tested application:
- Rise of the Tomb Raider
- F1 2017
- Any game launched via steam play DXVK
- vulcan-cube (backtrace is included to this message)
Last working mesa
Remove extraneous parentheses around the comparison
to silence this warning
Signed-off-by: Pratik Vishwakarma
---
drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_auto.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/calcs/dcn_calc_auto.c
67 matches
Mail list logo
