Hi Felix,
patch #3 looks good to me in general, but why do you need to cache the
pd_phys_addr?
The BO already does that anyway, so you can just use
amdgpu_bo_gpu_addr() for this which also makes some additional checks on
debug builds.
patch #5 well mixing power management into the VM funct
Am 02.03.2018 um 07:59 schrieb zhoucm1:
On 2018年03月02日 14:19, Kuehling, Felix wrote:
Hi David,
Compute contexts enable the compute power profile,
I heard from Rex, he said he prefer power profile depends on ring
busy/idle, rather than always enable it.
and can use a different VM update mod
On 2018年03月02日 14:19, Kuehling, Felix wrote:
Hi David,
Compute contexts enable the compute power profile,
I heard from Rex, he said he prefer power profile depends on ring
busy/idle, rather than always enable it.
and can use a different VM update mode from graphics contexts (SDMA vs. CPU)
Hi David,
Compute contexts enable the compute power profile, and can use a different VM
update mode from graphics contexts (SDMA vs. CPU). These differences are not
going away. Not yet, anyway. If we start sharing VM address space between
graphics and compute in the future, this will have to ch
This reverts commit 2ffe31deb27579e2f2c9444e01f4d8abf385d145.
The sdma wptr poll memomy doesn't have the same efficiency as
doorbell, and it will make sdma hang when running tests.
Change-Id: I6e334430b309b0c21aa18a08764320c7ff51e353
Signed-off-by: Emily Deng
---
drivers/gpu/drm/amd/amdgpu/amdgp
Hi Felix,
Out of patches, Could I ask what the difference of
AMDGPU_VM_CONTEXT_COMPUTE/GFX is?
After you merge kfd_vm to amdgpu_vm, does the difference still exist?
Thanks,
David Zhou
On 2018年03月02日 06:58, Felix Kuehling wrote:
Hi Christian,
I have a working patch series against amd-kfg
Patch#1 is Reviewed-by: Chunming Zhou
Patch#2~#4 are Acked-by: Chunming zhou
-Original Message-
From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of
Christian K?nig
Sent: Thursday, March 01, 2018 7:53 PM
To: amd-gfx@lists.freedesktop.org
Cc: ckoenig.leichtzumer...@g
Hi Christian,
I have a working patch series against amd-kfg-staging that lets KFD use
VMs from render node FDs, as we discussed. There are two patches in that
series that touch amdgpu_vm.[ch] that I'd like your feedback on before I
commit the changes to amd-kfd-staging and include them in my upstr
On Thu, Mar 1, 2018 at 3:04 PM, Harry Wentland wrote:
> From: Dmytro Laktyushkin
>
> v2: Fix commit title
>
> Signed-off-by: Dmytro Laktyushkin
> Reviewed-by: Tony Cheng
> Acked-by: Harry Wentland
Acked-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/display/dc/calcs/dcn_calcs.c | 2
From: Dmytro Laktyushkin
v2: Fix commit title
Signed-off-by: Dmytro Laktyushkin
Reviewed-by: Tony Cheng
Acked-by: Harry Wentland
---
drivers/gpu/drm/amd/display/dc/calcs/dcn_calcs.c | 2 +-
drivers/gpu/drm/amd/display/dc/core/dc_debug.c| 13 +++--
drivers/gpu/dr
From: "Leo (Sunpeng) Li"
Points in the DRM LUT are spaced linearly. Points in hardware are spaced
exponentially, with greater density towards 0. To maintain low-end
accuracy in hardware when sampling the DRM LUT, more points are needed.
However, X doesn't seem to play with legacy LUTs of such si
On 2018-02-27 11:44 AM, Michel Dänzer wrote:
> On 2018-02-27 05:16 PM, Harry Wentland wrote:
>> On 2018-02-27 11:08 AM, Michel Dänzer wrote:
>>> On 2018-02-27 04:54 PM, Leo Li wrote:
On 2018-02-27 05:34 AM, Michel Dänzer wrote:
> On 2018-02-26 09:15 PM, Harry Wentland wrote:
>> From: "
On Thu, Mar 1, 2018 at 10:41 AM, Guenter Roeck wrote:
> On Wed, Feb 28, 2018 at 2:17 PM, Matthias Kaehlcke wrote:
>> The util mkregtable includes a copy of the kernel API for linked lists,
>> only a small subset of it is used. Delete the unused functions and macros.
>>
>> Signed-off-by: Matthias
On 2018-02-28 02:27 AM, Monk Liu wrote:
> sometimes GPU is switched to other VFs and won't swich
> back soon, so the kiq reg access will not signal within
> a short period, instead of busy waiting a long time(MAX_KEQ_REG_WAIT)
> and returning TMO we can istead sleep 5ms and try again
> later (non i
On Wed, Feb 28, 2018 at 2:17 PM, Matthias Kaehlcke wrote:
> The util mkregtable includes a copy of the kernel API for linked lists,
> only a small subset of it is used. Delete the unused functions and macros.
>
> Signed-off-by: Matthias Kaehlcke
Reviewed-by: Guenter Roeck
> ---
> drivers/gpu/
On 2018-03-01 03:07 PM, Christoph Haag wrote:
> xorg-server.h defines _XSERVER64 which is used in X.h to choose the
> correct definition of XID
>
> this prevents a failure in the present.h configure test that disables
> DRI3 on X.Org 1.20
For future patches you want to be applied, please include
Am 01.03.2018 um 15:43 schrieb Tom St Denis:
The read/write pointers on sdma4 devices increment
beyond the ring size and should be masked. Tested
on my Ryzen 2400G.
Signed-off-by: Tom St Denis
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c | 2 +-
1 file chan
On Thu, Mar 1, 2018 at 9:43 AM, Tom St Denis wrote:
> The read/write pointers on sdma4 devices increment
> beyond the ring size and should be masked. Tested
> on my Ryzen 2400G.
>
> Signed-off-by: Tom St Denis
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c | 2 +-
The read/write pointers on sdma4 devices increment
beyond the ring size and should be masked. Tested
on my Ryzen 2400G.
Signed-off-by: Tom St Denis
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_
xorg-server.h defines _XSERVER64 which is used in X.h to choose the
correct definition of XID
this prevents a failure in the present.h configure test that disables
DRI3 on X.Org 1.20
---
configure.ac | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/configure.ac b/configure.
Am 01.03.2018 um 11:55 schrieb Liu, Monk:
Looks aborting in such case is the safe way, otherwise the fence_wait() outside
will still fail
Good point, just send a v2 of that patch which does exactly that.
Please review,
Christian.
-Original Message-
From: Christian König [mailto:cko
The ring status can change during GPU reset, but we still need to be
able to schedule TTM buffer moves in the meantime.
Otherwise we can ran into problems because of aborted move/fill
operations during GPU resets.
v2: still check if ring is available during direct submit.
Signed-off-by: Christia
Looks aborting in such case is the safe way, otherwise the fence_wait() outside
will still fail
-Original Message-
From: Christian König [mailto:ckoenig.leichtzumer...@gmail.com]
Sent: 2018年3月1日 18:50
To: Liu, Monk ; amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH 4/4] drm/amdgpu: use
Am 01.03.2018 um 11:33 schrieb Liu, Monk:
int amdgpu_mmap(struct file *filp, struct vm_area_struct *vma) @@ -1684,6
+1680,7 @@ int amdgpu_copy_buffer(struct amdgpu_ring *ring, uint64_t src_offset,
amdgpu_ring_pad_ib(ring, &job->ibs[0]);
WARN_ON(job->ibs[0].length_dw > num_dw);
> int amdgpu_mmap(struct file *filp, struct vm_area_struct *vma) @@ -1684,6
> +1680,7 @@ int amdgpu_copy_buffer(struct amdgpu_ring *ring, uint64_t
> src_offset,
amdgpu_ring_pad_ib(ring, &job->ibs[0]);
WARN_ON(job->ibs[0].length_dw > num_dw);
if (direct_submit) {
+
Instead of setting the active VRAM size directly provide a the info if
we can use the buffer functions or not.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 23 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h | 3 ++-
drivers/gpu/drm/amd/amdgpu/cik
When we reset the GPU we also disable/enable the SDMA, but we don't want
to change TTM idea of the VRAM size in the middle of that.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/a
Am 01.03.2018 um 11:17 schrieb Michel Dänzer:
From: Michel Dänzer
Signed-off-by: Michel Dänzer
Acked-by: Christian König
---
tests/amdgpu/amdgpu_test.c | 12 ++--
tests/amdgpu/amdgpu_test.h | 12 ++--
2 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/tes
The ring status can change during GPU reset, but we still need to be
able to schedule TTM buffer moves in the meantime.
Otherwise we can ran into problems because of aborted move/fill
operations during GPU resets.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 17 +
Those belong to the TTM handling.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 3 ---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h | 4
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu
From: Michel Dänzer
Signed-off-by: Michel Dänzer
---
tests/amdgpu/amdgpu_test.c | 12 ++--
tests/amdgpu/amdgpu_test.h | 12 ++--
2 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/tests/amdgpu/amdgpu_test.c b/tests/amdgpu/amdgpu_test.c
index 4f766aaf..f901a71d 1006
Am 01.03.2018 um 11:10 schrieb Chunming Zhou:
if some system hase no swap space and memory is less, than the test
could fail.
And bo eviction test takes much more time in some system, which effects
automation test result and efficiency.
So disable it by default now, only be used by developer manu
Oh yeah, I grep "ring->ready = false" and lost others ...
-Original Message-
From: Koenig, Christian
Sent: 2018年3月1日 17:51
To: Liu, Monk ; amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH 3/4] drm/amdgpu: don't return when ring not ready for
fill_buffer
Look for amdgpu_ttm_set_active_v
if some system hase no swap space and memory is less, than the test
could fail.
And bo eviction test takes much more time in some system, which effects
automation test result and efficiency.
So disable it by default now, only be used by developer manually.
Signed-off-by: Chunming Zhou
---
tests/
On 2018-03-01 10:55 AM, zhoucm1 wrote:
> Yes, Michel also pointed that, will do that.
Though based on Christian's earlier feedback, maybe you should rather
just explicitly disable it in the automation where it's causing trouble.
--
Earthling Michel Dänzer | http://ww
Yes, Michel also pointed that, will do that.
Thanks,
David Zhou
On 2018年03月01日 17:52, Christian König wrote:
Andrey worked on this, he should know that of hand.
Christian.
Am 01.03.2018 um 10:43 schrieb zhoucm1:
On 2018年03月01日 17:40, Christian König wrote:
Am 01.03.2018 um 10:37 schrie
Am 01.03.2018 um 10:24 schrieb Monk Liu:
sometimes GPU is switched to other VFs and won't swich
back soon, so the kiq reg access will not signal within
a short period, instead of busy waiting a long time(MAX_KEQ_REG_WAIT)
and returning TMO we can istead sleep 5ms and try again
later (non irq cont
Andrey worked on this, he should know that of hand.
Christian.
Am 01.03.2018 um 10:43 schrieb zhoucm1:
On 2018年03月01日 17:40, Christian König wrote:
Am 01.03.2018 um 10:37 schrieb Chunming Zhou:
if some system hase no swap space and memory is less, than the test
could fail.
And bo eviction t
Look for amdgpu_ttm_set_active_vram_size(), setting ring->ready to false
is directly beneath it.
Christian.
Am 01.03.2018 um 10:41 schrieb Liu, Monk:
Oops, looks only si will call this dma_stop() during hw_fini, I checked for
sdma4.0/3.0/2.4, no such logic
-Original Message-
From:
On 2018-03-01 10:37 AM, Chunming Zhou wrote:
> if some system hase no swap space and memory is less, than the test
> could fail.
> And bo eviction test takes much more time in some system, which effects
> automation test result and efficiency.
> So revert it now, only can be used by developer manua
On 2018年03月01日 17:40, Christian König wrote:
Am 01.03.2018 um 10:37 schrieb Chunming Zhou:
if some system hase no swap space and memory is less, than the test
could fail.
And bo eviction test takes much more time in some system, which effects
automation test result and efficiency.
So revert it
Oops, looks only si will call this dma_stop() during hw_fini, I checked for
sdma4.0/3.0/2.4, no such logic
-Original Message-
From: Christian König [mailto:ckoenig.leichtzumer...@gmail.com]
Sent: 2018年3月1日 17:39
To: Liu, Monk ; Koenig, Christian ;
amd-gfx@lists.freedesktop.org
Subject
Am 01.03.2018 um 10:37 schrieb Chunming Zhou:
if some system hase no swap space and memory is less, than the test
could fail.
And bo eviction test takes much more time in some system, which effects
automation test result and efficiency.
So revert it now, only can be used by developer manually.
Hi Monk,
look at si_dma_stop() and/or other SDMA generation code.
Regards,
Christian.
Am 01.03.2018 um 10:37 schrieb Liu, Monk:
Hi Christian
During suspend/resume, which stage will set sdma's ring->ready to false ?? I
can only find it in amdgpu_ring_fini()
But I saw that it is only invoked i
sometimes GPU is switched to other VFs and won't swich
back soon, so the kiq reg access will not signal within
a short period, instead of busy waiting a long time(MAX_KEQ_REG_WAIT)
and returning TMO we can istead sleep 5ms and try again
later (non irq context)
And since the waiting in kiq_r/weg is
if some system hase no swap space and memory is less, than the test
could fail.
And bo eviction test takes much more time in some system, which effects
automation test result and efficiency.
So revert it now, only can be used by developer manually.
This reverts commit 09642c073e8af71127cf98b48fe1b
Hi Christian
During suspend/resume, which stage will set sdma's ring->ready to false ?? I
can only find it in amdgpu_ring_fini()
But I saw that it is only invoked in unload_kms(), looks device_suspnd() will
not set ring->ready to false
/Monk
-Original Message-
From: amd-gfx [mailto:amd
Even for bare-metal changing the VRAM size in the memory manager because
we disable/enable the SDMA during GPU reset is quite a bug.
Going to work on this, a correct fix should actually be really trivial.
Regards,
Christian.
Am 01.03.2018 um 10:25 schrieb Liu, Monk:
Okay I missed the part of
Okay I missed the part of suspend/resume/s3
For SRIOV we don't run into that logic, looks I need to keep it in private
branch till
A better solution raised
/Monk
-Original Message-
From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of Liu,
Monk
Sent: 2018年3月1日 16:
> amdgpu_evict_flags() and amdgpu_bo_move() needs to know if the SDMA ring is
> available during suspend/resume.
As long as we are in gpu reset, we don't return error when ring not ready, cuz
eventually it either success or failed and rescheduled by scheduler since it is
kernel job
What's your
Sounds reasonable.
I would add a define for the 5ms timeout, with that done the patch is
Reviewed-by: Christian König as well.
Regards,
Christian.
Am 01.03.2018 um 09:40 schrieb Ding, Pixel:
Reviewed-by: Pixel Ding
—
Sincerely Yours,
Pixel
On 01/03/2018, 4:21 PM, "amd-gfx on behalf of L
If we are in gpu rest stage, we can let SDMA job live with the case of ring not
ready, can you point out where is the problem ?
amdgpu_evict_flags() and amdgpu_bo_move() needs to know if the SDMA ring
is available during suspend/resume.
E.g. suspend works as this:
1. Evict all normal BOs from
Reviewed-by: Pixel Ding
—
Sincerely Yours,
Pixel
On 01/03/2018, 4:21 PM, "amd-gfx on behalf of Liu, Monk"
wrote:
Hi Christian
KIQ is used by kernel, and we submit commands on it without gpu scheduler,
In sriov env, register access must go through KIQ in non-exclusive mode
Accel_working is only for GFX ring, I don't think test it is appropriate for
SDMA jobs
If we are in gpu rest stage, we can let SDMA job live with the case of ring not
ready, can you point out where is the problem ?
In fact we did stress TDR test with this patch and it can really fix coupl
Hi Christian
KIQ is used by kernel, and we submit commands on it without gpu scheduler,
In sriov env, register access must go through KIQ in non-exclusive mode because
we don’t want one VF access MMIO during the period that this VF is not
occupying
GPU resource,
But since now we use busy poll
Ah, crap yeah that won't work since we don't free the ring.
Key point is we need to distinct between the ring doesn't work temporary
because we are in a GPU reset and it doesn't work at all because we are
missing firmware or stuff like that.
And no, checking the gpu_reset flag is totally racy
From a coding style perspective a define for the 5ms timeout would be
nice to have and it might be better to use a do { } while instead of the
goto, but those are really minor issues.
But from the technical perspective I can't fully judge if that is a good
idea or not cause I'm not so deeply k
Am 01.03.2018 um 03:04 schrieb Alex Deucher:
Rather than querying it every time we need it.
Also fixes a crash in VM pass through if there is no
root bridge because the cached value fetch already checks
this properly.
v2: fix includes
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=105244
S
58 matches
Mail list logo
