Re: Slow memory access when using OpenCL without X11

Even if it's using CPU for OCL (I know it's not doing this), why does memcpy on CPU slow down permanently, if I'm not doing anything with OpenCL after clCreateContext? As you see from test program it just does clCreateContext and then a loop of memcpy-s on CPU. Also I found out that writing diffe

Re: [PATCH v2] drm/amdgpu: Fix lockdep warning in RAS SYSFS v2

thanks for finding the problem. but NACK for the solution. struct attribute { ... bool ignore_lockdep:1; ... } lockdef is useless here. I would like just set the ignore bit.

RE: [PATCH 3/6] drm/amdgpu: allocate VM PDs/PTs on demand

My concerns were related to eviction fence handing. It would manifest by unnecessary eviction callbacks into KFD that aren't cause by real evictions. I addressed that with a previous patch series that removed the need to remove eviction fences and add them back around page table updates in amdg

[PATCH v2] drm/amdgpu: Fix lockdep warning in RAS SYSFS v2

Problem: When loading driver with debug lockdep enabled the WARN_ON as bellow was observed. Gooling about this warning i found the follwing explanation - https://git.sphere.ly/tucstwo/cam-test/commit/671ee198b38694cf1dfbaa0b9ea823929517c367 Fix: Switch all debugfs attributes in RAS to static v2:

[PATCH] drm/amdgpu: Fix lockdep warning in RAS SYSFS.

Problem: When loading driver with debug lockdep enabled the WARN_ON as bellow was observed. Gooling about this warning i found the follwing explanation - https://git.sphere.ly/tucstwo/cam-test/commit/671ee198b38694cf1dfbaa0b9ea823929517c367 Fix: Switch all debugfs attributes in RAS to static Mar

RE: [PATCH 3/3] drm/amdgpu: stop evicting busy PDs/PTs

Should we even consider not evicting all PDs/PTs, busy or not. See PDs/PTs only use a tiny bit (roughly ~0.05%) of the total memory. You really don't get much memory when you evict them. But I doubt the evict/restore performance penalty is big. Thanks, Oak -Original Message- From: amd-

Re: Slow memory access when using OpenCL without X11

I think you are probably using the CPU for OCL in the remote login case. When you log into the desktop, the permissions on the device nodes get changed dynamically to support accelerated rendering. You probably need to change the permissions on the device nodes manually if you are not logging int

Slow memory access when using OpenCL without X11

Hi! I am using Ryzen 2400G with Gigabyte AMD B450 AORUS board. I have latest bios, ubuntu 18.04 and latest mainline kernel (5.0.0-05-generic) installed. Also I have rocm-dev 2.1.96 but no rock-dkms installed. I found that when I log in over ssh and try to use OpenCL (doing clCreateContext is

Re: [PATCH xf86-video-ati] Revert "glamor: Avoid glamor_create_pixmap for pixmaps backing windows"

Acked-by: Alex Deucher From: amd-gfx on behalf of Michel Dänzer Sent: Friday, March 8, 2019 5:51 AM To: amd-gfx@lists.freedesktop.org Subject: [PATCH xf86-video-ati] Revert "glamor: Avoid glamor_create_pixmap for pixmaps backing windows" From: Michel Dänzer

Re: [PATCH] drm/amdgpu: Clear VRAM for DRM dumb_create buffers

On Fri, Mar 8, 2019 at 10:38 AM Nicholas Kazlauskas wrote: > > The dumb_create API isn't intended for high performance rendering > and it's more useful for userspace (ie. IGT) to have them precleared. > > The bonus here is that we also won't needlessly leak whatever was > previously in VRAM, but i

Re: [PATCH] drm/amdgpu: limit the number of IVs processed at once

On 2019-03-08 3:35 p.m., Christian König wrote: > Only process a maximum of 32 IVs before writing back the RPTR. This improves > hw handling when we get close to an overflow in the ring buffer. > > Signed-off-by: Christian König > --- > drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c | 3 ++- > drivers/g

[PATCH] drm/amdgpu: Clear VRAM for DRM dumb_create buffers

The dumb_create API isn't intended for high performance rendering and it's more useful for userspace (ie. IGT) to have them precleared. The bonus here is that we also won't needlessly leak whatever was previously in VRAM, but it also probably wasn't sensitive if it was going through this API. Sig

Re: [PATCH] drm/amdgpu: enable IH ring 1&2 for Vega20 as well

Ups that was the wrong patch, please ignore. Am 08.03.19 um 15:35 schrieb Christian König: That doesn't seem to have any negative effects. Signed-off-by: Christian König Acked-by: Chunming Zhou --- drivers/gpu/drm/amd/amdgpu/vega10_ih.c | 30 +++--- 1 file changed, 13 i

[PATCH] drm/amdgpu: limit the number of IVs processed at once

Only process a maximum of 32 IVs before writing back the RPTR. This improves hw handling when we get close to an overflow in the ring buffer. Signed-off-by: Christian König --- drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c | 3 ++- drivers/gpu/drm/amd/amdgpu/amdgpu_ih.h | 3 +++ 2 files changed, 5 inse

[PATCH] drm/amdgpu: enable IH ring 1&2 for Vega20 as well

That doesn't seem to have any negative effects. Signed-off-by: Christian König Acked-by: Chunming Zhou --- drivers/gpu/drm/amd/amdgpu/vega10_ih.c | 30 +++--- 1 file changed, 13 insertions(+), 17 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/vega10_ih.c b/drivers/gp

[PATCH 3/3] drm/amdgpu: stop evicting busy PDs/PTs

Otherwise we won't be able to cleanly handle page faults. Signed-off-by: Christian König --- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c index cd0ccfbbcb84..c

[PATCH 1/3] drm/amdgpu: remove non-sense NULL ptr check

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 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c b/drivers/gpu/drm/amd/amdgpu/

[PATCH 2/3] drm/amdgpu: wait for VM to become idle during flush

Make sure that not only the entities are flush, but that we also wait for the HW to finish all processing. Signed-off-by: Christian König --- drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c | 6 +++--- drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.h | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 7 ---

RE: [PATCH 3/6] drm/amdgpu: allocate VM PDs/PTs on demand

That dmesg was from Fiji, but it occurred on Vega10 as well. Kent > -Original Message- > From: Christian König > Sent: Friday, March 08, 2019 9:14 AM > To: Russell, Kent ; amd-gfx@lists.freedesktop.org > Subject: Re: [PATCH 3/6] drm/amdgpu: allocate VM PDs/PTs on demand > > My best gu

Re: [PATCH 3/6] drm/amdgpu: allocate VM PDs/PTs on demand

My best guess is that we forget somewhere to update the PDs. What hardware is that on? Felix already mentioned that this could be problematic for the KFD. Maybe he has an idea, Christian. Am 08.03.19 um 15:04 schrieb Russell, Kent: Hi Christian, This patch ended up causing a VM Fault in KFDT

RE: [PATCH 3/6] drm/amdgpu: allocate VM PDs/PTs on demand

Hi Christian, This patch ended up causing a VM Fault in KFDTest. Reverting just this patch addressed the issue: [ 82.703503] amdgpu :0c:00.0: GPU fault detected: 146 0x480c for process pid 0 thread pid 0 [ 82.703512] amdgpu :0c:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x000

[PATCH] drm/amdgpu: use ring/hash for fault handling on GMC9 v3

Further testing showed that the idea with the chash doesn't work as expected. Especially we can't predict when we can remove the entries from the hash again. So replace the chash with a ring buffer/hash mix where entries in the container age automatically based on their timestamp. v2: use ring bu

[PATCH xf86-video-ati] Revert "glamor: Avoid glamor_create_pixmap for pixmaps backing windows"

From: Michel Dänzer This reverts commit 274703087f80342f51fa69c935bb9a1cb0c4ae47. Reports of visual corruption were bisected to this, e.g. https://bugs.archlinux.org/task/61941 . I can reproduce this with Turks, but not with Bonaire. I assume it's a Mesa/glamor bug, but let's revert for now. Si

locking related bug detected since "drm/amdgpu: lookup vbios table to check ecc capability"

Hi Xinhui, since this commit, amdgpu_ras_init runs on my development system with Bonaire, and generates the attached BUG and lock debug warning reports. Before this commit, amdgpu_ras_init returned early, because RAS isn't supported. There's no mention of this change of behaviour in the commit

Re: randr: Virtual monitor not present with MST display

On 2019-03-06 5:35 p.m., Paul Menzel wrote: > On 03/06/19 15:55, Michel Dänzer wrote: >> On 2019-03-06 1:41 p.m., Paul Menzel wrote: >>> On 03/05/19 20:07, Alex Deucher wrote: On Tue, Mar 5, 2019 at 1:16 PM Paul Menzel wrote: >>> > Using the MST display Dell UP3214Q (two panels) with an AM

Re: [PATCH] drm/amdgpu: Cosmetic change for calling func amdgpu_gmc_vram_location

Am 08.03.19 um 00:05 schrieb Zeng, Oak: Use function parameter mc as the second parameter of amdgpu_gmc_vram_location, so codes look more consistent. Change-Id: Ib5b06d188ebc6e82eb0d4d2a57d995149bf5f7a5 Signed-off-by: Oak Zeng Reviewed-by: Christian König --- drivers/gpu/drm/amd/amdgpu/g