This patch is Reviewed-by: Felix Kuehling
Regards,
Felix
On 3/12/2019 9:17 PM, Yang, Philip wrote:
> userptr may cross two VMAs if the forked child process (not call exec
> after fork) malloc buffer, then free it, and then malloc larger size
> buf, kerenl will create new VMA adjacent to old
Hi Felix,
Submitted v3 to fix the potential problems with invalid userptr.
Philip
On 2019-03-12 3:30 p.m., Kuehling, Felix wrote:
> See one comment inline. There are still some potential problems that
> you're not catching.
>
> On 2019-03-06 9:42 p.m., Yang, Philip wrote:
>> userptr may cross
userptr may cross two VMAs if the forked child process (not call exec
after fork) malloc buffer, then free it, and then malloc larger size
buf, kerenl will create new VMA adjacent to old VMA which was cloned
from parent process, some pages of userptr are in the first VMA, the
rest pages are in the
When we use SDMA, we don't wait on the CPU. The GPU scheduler waits for
the fences on the root PD reservation before executing the SDMA IB.
amdgpu_vm_bo_update_mapping gets those fences and builds the sync object
for the scheduler after all the page tables have been allocated, so it
should be
Never mind. I must have messed up my build. I can't reproduce the
problem any more. The patch I sent out is still needed and valid. AFAICT
it should be all that's needed to fix GPUVM for KFD.
I have not seen any faults with KFDCWSRTest.BasicTest on my system with
Fiji or Vega10 with that patch
Hi,
I think even use SDMA to update PTE we may still need to wait the clear
job to be completed if we can not guarantee the clear and set PTE job
will use the exact same SDMA engine ( Did we use a dedicate SDMA engine
for PTE update including clear? ). But if we didn't use the same
engine ,
Forcing the sclk and mclk high may impact the CPU frequency since they share
TDP.
Alex
From: amd-gfx on behalf of Lauri
Ehrenpreis
Sent: Tuesday, March 12, 2019 5:31 PM
To: Kuehling, Felix
Cc: Tom St Denis; amd-gfx@lists.freedesktop.org
Subject: Re: Slow
However it's not only related to mclk and sclk. I tried this:
rocm-smi --setsclk 2
rocm-smi --setmclk 3
rocm-smi
ROCm System Management Interface
IN the case when memory is slow, the rocm-smi outputs this:
ROCm System Management Interface
GPU Temp AvgPwr SCLKMCLKPCLK
When page table are updated by the CPU, synchronize with the
allocation and initialization of newly allocated page tables.
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 20 +---
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git
I'm also still seeing VM faults in the eviction test even with my fix,
and even with SDMA page table updates. There is still something else
going wrong. :/
Thanks,
Felix
On 2019-03-12 5:13 p.m., Yang, Philip wrote:
> vm fault happens about 1/10 for KFDCWSRTest.BasicTest for me. I am using
>
vm fault happens about 1/10 for KFDCWSRTest.BasicTest for me. I am using
SDMA for page table update. I don't try CPU page table update.
Philip
On 2019-03-12 11:12 a.m., Russell, Kent wrote:
> Peculiar, I hit it immediately when I ran it . Can you try use
> --gtest_filter=KFDCWSRTest.BasicTest
The root cause is that we don't wait after calling amdgpu_vm_clear_bo in
amdgpu_vm_alloc_pts.
Waiting for the page table BOs to be idle for CPU page table updates is
done in amdgpu_vm_bo_update_mapping. That is now *before* the page
tables are actually allocated and cleared in
On 2019-03-06 9:42 p.m., Yang, Philip wrote:
> Userptr restore may have concurrent userptr invalidation after
> hmm_vma_fault adds the range to the hmm->ranges list, needs call
> hmm_vma_range_done to remove the range from hmm->ranges list first,
> then reschedule the restore worker. Otherwise
See one comment inline. There are still some potential problems that
you're not catching.
On 2019-03-06 9:42 p.m., Yang, Philip wrote:
> userptr may cross two VMAs if the forked child process (not call exec
> after fork) malloc buffer, then free it, and then malloc larger size
> buf, kerenl will
I find that it's related to CPU page table updates. If I force page
table updates with SDMA, I don't get the VM fault.
Regards,
Felix
On 2019-03-11 12:55 p.m., Christian König wrote:
> Hi guys,
>
> well it's most likely some missing handling in the KFD, so I'm rather
> reluctant to revert
They are not the same, but the guilty job belongs to only one {entity,
scheduler} pair and so we mark as guilty only for that particular entity in the
context of that scheduler only once.
Andrey
From: Eric Anholt
Sent: 12 March 2019 13:33:16
To:
5.0-stable review patch. If anyone has any objections, please let me know.
--
[ Upstream commit e02f5c1bb2283cfcee68f2f0feddcc06150f13aa ]
The DRM driver stack is designed to work with cache coherent devices
only, but permits an optimization to be enabled in some cases, where
Andrey Grodzovsky writes:
> Also stop calling drm_sched_increase_karma multiple times.
Each v3d->queue[q].sched was initialized with a separate
drm_sched_init(). I wouldn't have thought they were all the "same
sched".
signature.asc
Description: PGP signature
4.14-stable review patch. If anyone has any objections, please let me know.
--
[ Upstream commit e02f5c1bb2283cfcee68f2f0feddcc06150f13aa ]
The DRM driver stack is designed to work with cache coherent devices
only, but permits an optimization to be enabled in some cases, where
4.19-stable review patch. If anyone has any objections, please let me know.
--
[ Upstream commit e02f5c1bb2283cfcee68f2f0feddcc06150f13aa ]
The DRM driver stack is designed to work with cache coherent devices
only, but permits an optimization to be enabled in some cases, where
4.9-stable review patch. If anyone has any objections, please let me know.
--
[ Upstream commit e02f5c1bb2283cfcee68f2f0feddcc06150f13aa ]
The DRM driver stack is designed to work with cache coherent devices
only, but permits an optimization to be enabled in some cases, where
4.20-stable review patch. If anyone has any objections, please let me know.
--
[ Upstream commit e02f5c1bb2283cfcee68f2f0feddcc06150f13aa ]
The DRM driver stack is designed to work with cache coherent devices
only, but permits an optimization to be enabled in some cases, where
Also stop calling drm_sched_increase_karma multiple times.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/v3d/v3d_sched.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/v3d/v3d_sched.c b/drivers/gpu/drm/v3d/v3d_sched.c
index
On 2019-03-12 3:26 p.m., Koenig, Christian wrote:
> Am 12.03.19 um 14:47 schrieb Michel Dänzer:
>> On 2019-02-05 6:40 p.m., Michel Dänzer wrote:
>>> FWIW, I've hit this twice now today, whereas I don't remember ever
>>> hitting it before (not 100% sure though).
>>>
>>> I reverted the remaining
[adding the list back]
I'd suspect a problem related to memory clock. This is an APU where
system memory is shared with the CPU, so if the SMU changes memory
clocks that would affect CPU memory access performance. If the problem
only occurs when OpenCL is running, then the compute power
On Tue, Mar 12, 2019 at 8:37 AM Christian König
wrote:
>
> We need the first paging queue to handle page faults.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c | 20
> 1 file changed, 12 insertions(+), 8 deletions(-)
>
> diff --git
I don't think Raven has a paging queue in the first place.
Alex
From: amd-gfx on behalf of Kuehling,
Felix
Sent: Tuesday, March 12, 2019 11:29 AM
To: Christian König; amd-gfx@lists.freedesktop.org
Subject: RE: [PATCH 2/3] drm/amdgpu: free up the first paging
I think this would break Raven, which only has one SDMA engine.
Regards,
Felix
-Original Message-
From: amd-gfx On Behalf Of Christian
König
Sent: Tuesday, March 12, 2019 8:38 AM
To: amd-gfx@lists.freedesktop.org
Subject: [PATCH 2/3] drm/amdgpu: free up the first paging queue
We
Peculiar, I hit it immediately when I ran it . Can you try use
--gtest_filter=KFDCWSRTest.BasicTest . That one hung every time for me.
Kent
> -Original Message-
> From: Christian König
> Sent: Tuesday, March 12, 2019 11:09 AM
> To: Russell, Kent ; Koenig, Christian
> ; Kuehling,
Yeah, same problem here.
I removed libhsakmt package and installed it manually and now it seems
to work.
Doing some testing now, but at least of hand I can't seem to reproduce
the VM fault on a Vega10.
Christian.
Am 12.03.19 um 16:01 schrieb Russell, Kent:
Oh right, I remember that
Oh right, I remember that issue. I had that happen to me once, where my
installed libhsakmt didn't match up with the latest source code, so I ended up
having to remove the libhsakmt package and pointing it to the folders instead.
Kent
> -Original Message-
> From: Koenig, Christian
>
On 3/12/19 3:43 AM, Tomeu Vizoso wrote:
> On Thu, 27 Dec 2018 at 20:28, Andrey Grodzovsky
> wrote:
>> Decauple sched threads stop and start and ring mirror
>> list handling from the policy of what to do about the
>> guilty jobs.
>> When stoppping the sched thread and detaching sched fences
>>
Yeah, the problem is I do have the libhsakmt installed.
Going to give it a try to specify the directory directly.
Christian.
Am 12.03.19 um 15:47 schrieb Russell, Kent:
> The README.txt file inside the tests/kfdtest folder has instructions on how
> to do it if you don't have the libhsakmt
The README.txt file inside the tests/kfdtest folder has instructions on how to
do it if you don't have the libhsakmt package installed on your system:
export LIBHSAKMT_PATH=/*your local libhsakmt folder*/
With that, the headers and libraries are searched under
LIBHSAKMT_PATH/include and
On Tue, Mar 12, 2019 at 10:19 AM Harinath Reddy wrote:
>
> If I am not confused/wrong with your information,if I want get use of the
> xf86-video-amdgpu (UMD ) which is capable of driving GCN core cards in
> hp-ux, I should
> write hp-ux compatible drm based kenel module.
Correct.
Am 12.03.19 um 14:47 schrieb Michel Dänzer:
> On 2019-02-05 6:40 p.m., Michel Dänzer wrote:
>> FWIW, I've hit this twice now today, whereas I don't remember ever
>> hitting it before (not 100% sure though).
>>
>> I reverted the remaining hunk of the "cleanup setting bulk_movable"
>> change, and it
If I am not confused/wrong with your information,if I want get use of
the xf86-video-amdgpu (UMD ) which is capable of driving GCN core cards
in hp-ux, I should
write hp-ux compatible drm based kenel module.
Thanks,
Harinath
On Tue, Mar 12, 2019 at 7:37 PM Alex Deucher wrote:
> All
All drivers for recent hardware require a proper kernel driver. There
have not been user mode X drivers for new AMD hardware released in the
last 7-8 years.
Alex
On Tue, Mar 12, 2019 at 10:02 AM Harinath Reddy wrote:
>
> Hope it is different from xorg-video-radeon/hd driver which is not
Hope it is different from xorg-video-radeon/hd driver which is not require
any kernel component to drive the FireMV2250 card, except card
initialization( ATOMBIOS run from the HP-UX kernel on behalf of the xf86
request ).
If it is tightly coupled with amdgpu kernel module, and it is again
> -Original Message-
> From: Pan, Xinhui
> Sent: Tuesday, March 12, 2019 6:14 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander ; Quan, Evan
> ; Zhang, Hawking
> Subject: [PATCH 2/2] drm/amdgpu: add new ras workflow control flags
>
> add ras post init function.
> Do some
On 2019-02-05 6:40 p.m., Michel Dänzer wrote:
>
> FWIW, I've hit this twice now today, whereas I don't remember ever
> hitting it before (not 100% sure though).
>
> I reverted the remaining hunk of the "cleanup setting bulk_movable"
> change, and it survived a piglit run. Could just be luck,
Reviewed-by: Alex Deucher
From: Pan, Xinhui
Sent: Tuesday, March 12, 2019 6:13 AM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander; Quan, Evan; Zhang, Hawking
Subject: [PATCH 1/2] drm/amdgpu: let ras initialization a little noticeable
add drm info output
The series is Reviewed-by: Chunming Zhou
在 2019/3/8 22:31, Christian König 写道:
> It's a bug having a dead pointer in the IDR, silently returning
> is the worst we can do.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c | 10 --
> 1 file changed, 10
Hi guys,
so found a few minutes today to compile kfdtest.
Problem is that during the compile I get a lots of this:
CMakeFiles/kfdtest.dir/src/BaseQueue.cpp.o: In Funktion
»BaseQueue::Create(unsigned int, unsigned int, unsigned long*)«:
On 3/12/19 2:44 AM, Boris Brezillon wrote:
> On Mon, 11 Mar 2019 23:22:03 -0300
> Helen Koike wrote:
>
>> In the case of a normal sync update, the preparation of framebuffers (be
>> it calling drm_atomic_helper_prepare_planes() or doing setups with
>> drm_framebuffer_get()) are performed in the
To aid recoverable page faults.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c
index 335a0edf114b..8f5026c123ef 100644
---
Ping? Can anybody take a look?
Christian.
Am 08.03.19 um 15:31 schrieb Christian König:
It's a bug having a dead pointer in the IDR, silently returning
is the worst we can do.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c | 10 --
1 file changed, 10
Reviewed-by: Evan Quan
> -Original Message-
> From: Pan, Xinhui
> Sent: 2019年3月12日 18:14
> To: amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander ; Quan, Evan
> ; Zhang, Hawking
> Subject: [PATCH 2/2] drm/amdgpu: add new ras workflow control flags
>
> add ras post init function.
>
add ras post init function.
Do some initialization after all IP have finished their late init.
Add new member flags which will control the ras work flow.
For now, vbios enable ras for us on boot. That might change in the
future.
So there should be a flag from vbios to tell us if ras is enabled or
add drm info output if ras initialized successfully.
add ras atomfirmware sanity check.
Signed-off-by: xinhui pan
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
Am 12.03.19 um 09:35 schrieb Michel Dänzer:
On 2019-03-12 4:14 a.m., Harinath Reddy wrote:
Hi,
Present we are using the radeon HD driver from xorg to driver AMDFirMV2250
card. We would like to replace AMD FireMV2250 with AMD Radeon Pro Wx2100
card.
I saw xf86-video-amdgpu xorg driver is
On 2019-03-12 4:14 a.m., Harinath Reddy wrote:
> Hi,
>
> Present we are using the radeon HD driver from xorg to driver AMDFirMV2250
> card. We would like to replace AMD FireMV2250 with AMD Radeon Pro Wx2100
> card.
>
> I saw xf86-video-amdgpu xorg driver is available, but we are not sure
>
On Thu, 27 Dec 2018 at 20:28, Andrey Grodzovsky
wrote:
>
> Decauple sched threads stop and start and ring mirror
> list handling from the policy of what to do about the
> guilty jobs.
> When stoppping the sched thread and detaching sched fences
> from non signaled HW fenes wait for all signaled
On Mon, 11 Mar 2019 23:22:03 -0300
Helen Koike wrote:
> In the case of a normal sync update, the preparation of framebuffers (be
> it calling drm_atomic_helper_prepare_planes() or doing setups with
> drm_framebuffer_get()) are performed in the new_state and the respective
> cleanups are
55 matches
Mail list logo
