Re: PRT support for amdgpu

On 02.02.2017 10:29, Bas Nieuwenhuizen wrote: On Thu, Feb 2, 2017, at 10:18, Nicolai Hähnle wrote: On 02.02.2017 02:49, Dave Airlie wrote: I think we would require a fully open source user for this sort of thing, there are way to many corner cases for us to fall down here, prematurely pushing

Re: PRT support for amdgpu

[ ceterum censeo, + John for addrlib :P ] On 02.02.2017 02:49, Dave Airlie wrote: answered better by Dave. Yeah, though so as well. Dave can you comment? I think we would require a fully open source user for this sort of thing, there are way to many corner cases for us to fall down here,

Re: [PATCH] winsys/radeon: Allow visible VRAM size > 256MB with kernel driver >= 2.49

Both patches: Reviewed-by: Nicolai Hähnle <nicolai.haeh...@amd.com> On 31.01.2017 07:54, Michel Dänzer wrote: From: Michel Dänzer <michel.daen...@amd.com> The kernel driver reports correct values now. Signed-off-by: Michel Dänzer <michel.daen...@amd.com> --- src/gallium

Re: PRT support for amdgpu

On 31.01.2017 17:28, Christian König wrote: Am 31.01.2017 um 14:06 schrieb Bas Nieuwenhuizen: So this API seems usable, and I think this is something we can use for radv. However, I'm not sure how much time it takes for us to implement, as the TFE variants are not in LLVM yet and I haven't

Re: [PATCH libdrm] amdgpu: add PRT unit test

On 08.02.2017 16:06, Christian König wrote: From: Christian König <christian.koe...@amd.com> Just a simple test if PRT works or not. Signed-off-by: Christian König <christian.koe...@amd.com> Reviewed-by: Nicolai Hähnle <nicolai.haeh...@amd.com> Too bad we can't ask the k

Re: [PATCH 1/6] drm/amdgpu: add support for BO_VAs without BO

On 02.02.2017 11:26, Christian König wrote: Am 30.01.2017 um 15:43 schrieb Nicolai Hähnle: On 30.01.2017 13:57, Christian König wrote: From: Christian König <christian.koe...@amd.com> For PRT support we need mappings which aren't backed by any memory. Signed-off-by: Christian

[PATCH libdrm 2/2] amdgpu: add amdgpu_bo_va_op_raw

From: Nicolai Hähnle <nicolai.haeh...@amd.com> This variant allows the caller full control over flags and size, and allows passing a NULL bo (for PRT support). Cc: Christian König <christian.koe...@amd.com> Cc: Bas Nieuwenhuizen <b...@basnieuwenhuizen.nl> Cc: Jerry Zhang &l

[PATCH libdrm 1/2] amdgpu: add AMDGPU_VM_PAGE_PRT

From: Nicolai Hähnle <nicolai.haeh...@amd.com> This is a new kernel interface. Signed-off-by: Nicolai Hähnle <nicolai.haeh...@amd.com> --- include/drm/amdgpu_drm.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/drm/amdgpu_drm.h b/include/drm/amdgpu_drm.h index d8f2

Re: [PATCH libdrm 2/2] amdgpu: add amdgpu_bo_va_op_raw

On 08.02.2017 13:44, Nicolai Hähnle wrote: On 08.02.2017 13:39, Christian König wrote: Am 08.02.2017 um 13:34 schrieb Nicolai Hähnle: From: Nicolai Hähnle <nicolai.haeh...@amd.com> This variant allows the caller full control over flags and size, and allows passing a NULL bo (for PRT s

Re: [PATCH libdrm 2/2] amdgpu: add amdgpu_bo_va_op_raw

On 08.02.2017 13:39, Christian König wrote: Am 08.02.2017 um 13:34 schrieb Nicolai Hähnle: From: Nicolai Hähnle <nicolai.haeh...@amd.com> This variant allows the caller full control over flags and size, and allows passing a NULL bo (for PRT support). Cc: Christian König <chri

Re: [PATCH 4/6] drm/amdgpu: implement PRT for GFX6 v2

On 02.02.2017 11:25, Christian König wrote: From: Christian König Enable/disable the handling globally for now and print a warning when we enable it for the first time. v2: write to the correct register, adjust bits to that hw generation Signed-off-by: Christian

Re: [PATCH libdrm 2/3] amdgpu: don't mess with shared_handle if amdgpu_bo_import() fails

I don't think is correct. The incoming handle is in shared_handle, not in handle. Once the code block around line 310 has executed, shared_handle is the handle produced by drmPrimeFDToHandle, and closing it on error (as the code currently does) should be the correct thing to do. The only

Re: [PATCH libdrm 1/3] amdgpu: add missing unlock on drmPrimeFDToHandle() failure

On 22.01.2017 19:48, Emil Velikov wrote: Cc: amd-gfx@lists.freedesktop.org Signed-off-by: Emil Velikov <emil.l.veli...@gmail.com> Reviewed-by: Nicolai Hähnle <nicolai.haeh...@amd.com> --- amdgpu/amdgpu_bo.c | 1 + 1 file changed, 1 insertion(+) diff --git a/amdgpu/amdgpu_b

Re: [PATCH] drm/amdgpu: drop pitcairn dpm quirks

On 25.01.2017 00:26, Alex Deucher wrote: No longer necessary with the new 58 mc ucode. Should this perhaps have a firmware version check? Would suck if somebody's system regressed if they upgrade the kernel but missed upgrading the firmware... Nicolai Signed-off-by: Alex Deucher

Re: PRT support for amdgpu

[ Cc John for addrlib ] On 30.01.2017 13:57, Christian König wrote: An open problem with the proposal is that we don't know when or if we want to add the userspace implementation into radeonsi. So price question could you guys use this for radv as well? Or is it sufficient to just write an

Re: [PATCH 1/6] drm/amdgpu: add support for BO_VAs without BO

On 30.01.2017 13:57, Christian König wrote: From: Christian König For PRT support we need mappings which aren't backed by any memory. Signed-off-by: Christian König --- drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 20 ++-- 1

Re: [PATCH 1/2] drm/amdgpu: fix race in GEM VA map IOCTL

On 30.01.2017 10:45, Christian König wrote: From: Christian König <christian.koe...@amd.com> Somebody could try to free the bo_va between mapping and updating it. Signed-off-by: Christian König <christian.koe...@amd.com> Nice catch! Both patches: Reviewed-by: Nicolai Hähnle &

Re: [PATCH] drm/amdgpu: refuse to reserve io mem for split VRAM buffers

On 17.02.2017 11:08, Christian König wrote: Am 17.02.2017 um 00:21 schrieb Nicolai Hähnle: We may still have other bugs with split BOs, though. Yeah, agree as well. I was also considering disabling that feature by default for the moment if it helps with your corruption bug. The corruption

Re: [PATCH] drm/amdgpu: refuse to reserve io mem for split VRAM buffers

Ping? People seem to agree, but I haven't seen an explicit R-b... On 16.02.2017 23:55, Nicolai Hähnle wrote: From: Nicolai Hähnle <nicolai.haeh...@amd.com> When the fast blit path fails while attempting to move a buffer from RAM to VRAM, we fall back to a CPU-based memcpy that cannot

Re: [PATCH] drm/amdgpu: refuse to reserve io mem for split VRAM buffers

On 20.02.2017 18:29, Christian König wrote: Sorry, patch is Reviewed-by: Christian König <christian.koe...@amd.com>. Thanks! Christian. Am 20.02.2017 um 18:23 schrieb Nicolai Hähnle: Ping? People seem to agree, but I haven't seen an explicit R-b... On 16.02.2017 23:55, Nicolai

[PATCH] drm/amdgpu: refuse to reserve io mem for split VRAM buffers

From: Nicolai Hähnle <nicolai.haeh...@amd.com> When the fast blit path fails while attempting to move a buffer from RAM to VRAM, we fall back to a CPU-based memcpy that cannot handle split VRAM buffers. Instead of crashing, simply fail the buffer move. Ideally, we would teach TTM about

Re: [PATCH] drm/amdgpu: refuse to reserve io mem for split VRAM buffers

On 17.02.2017 00:02, Alex Deucher wrote: On Thu, Feb 16, 2017 at 5:55 PM, Nicolai Hähnle <nhaeh...@gmail.com> wrote: From: Nicolai Hähnle <nicolai.haeh...@amd.com> When the fast blit path fails while attempting to move a buffer from RAM to VRAM, we fall back to a CPU-based memcpy

[PATCH] drm/ttm: fix use-after-free races in vm fault handling

From: Nicolai Hähnle <nicolai.haeh...@amd.com> The vm fault handler relies on the fact that the VMA owns a reference to the BO. However, once mmap_sem is released, other tasks are free to destroy the VMA, which can lead to the BO being freed. Fix two code paths where that can happen, both r

Re: PRT support for amdgpu v3

Hi, Some more testing uncovered a bug in cleanup paths. When the application segfaults while PRT mappings exist, I get a WARN_ON (which seems fairly straightforward) and occasionally also an RCU error warning -- see the attached dmesg logs. Regular application shutdown works fine, though.

Re: [PATCH v2 1/2] drm/amdgpu: fix a potential deadlock in amdgpu_bo_create_restricted()

On 14.02.2017 03:56, zhoucm1 wrote: On 2017年02月14日 03:03, Nicolai Hähnle wrote: On 13.02.2017 19:58, Nicolai Hähnle wrote: On 13.02.2017 19:38, Samuel Pitoiset wrote: On 02/13/2017 07:09 PM, Nicolai Hähnle wrote: On 13.02.2017 19:04, Nicolai Hähnle wrote: On 13.02.2017 18:49, Samuel

[PATCH] drm/ttm: make TTM_MAX_BO_PRIORITY unsigned

From: Nicolai Hähnle <nicolai.haeh...@amd.com> Fix a warning about different types in min() macro in amdgpu: In file included from ./include/linux/list.h:8:0, from drivers/gpu/drm/amd/amdgpu/amdgpu_object.c:32: drivers/gpu/drm/amd/amdgpu/amdgpu_object.c: In fu

[PATCH 1/2] drm/ttm: never add BO that failed to validate to the LRU list

From: Nicolai Hähnle <nicolai.haeh...@amd.com> Fixes a potential race condition in amdgpu that looks as follows: Task 1: attempt ttm_bo_init, but ttm_bo_validate fails Task 1: add BO to global list anyway Task 2: grabs hold of the BO, waits on its reservation lock Task 1: releases its ref

[PATCH] drm/amdgpu: fix a warning about different types in min() macro

From: Nicolai Hähnle <nicolai.haeh...@amd.com> In file included from ./include/linux/list.h:8:0, from drivers/gpu/drm/amd/amdgpu/amdgpu_object.c:32: drivers/gpu/drm/amd/amdgpu/amdgpu_object.c: In function ‘amdgpu_bo_create_restricted’: ./include/linux/kernel.h:739:16: w

Re: [PATCH 1/2] drm/ttm: never add BO that failed to validate to the LRU list

On 14.02.2017 11:38, Christian König wrote: Am 14.02.2017 um 10:18 schrieb Nicolai Hähnle: From: Nicolai Hähnle <nicolai.haeh...@amd.com> Fixes a potential race condition in amdgpu that looks as follows: Task 1: attempt ttm_bo_init, but ttm_bo_validate fails Task 1: add BO to globa

Re: [PATCH 1/3] drm/ttm: split BO structure initialization into a separate function

On 14.02.2017 11:49, Christian König wrote: Am 14.02.2017 um 11:37 schrieb Nicolai Hähnle: From: Nicolai Hähnle <nicolai.haeh...@amd.com> Allow callers to opt out of calling ttm_bo_validate immediately. This allows more flexibility in how locking of the reservation object is done,

[PATCH 0/2] drm/ttm, amdgpu: fix use-after-free in recent deadlock fix

Hi all, based on my current theory on how a deadlock could happen in the buffer allocation code, these two patches should fix the deadlock without having a use-after-free. I'm still working on a way to clean up the ttm_bo_init sequence overall, but I'm separating these two out for a hopefully

[PATCH 1/3] drm/ttm: split BO structure initialization into a separate function

From: Nicolai Hähnle <nicolai.haeh...@amd.com> Allow callers to opt out of calling ttm_bo_validate immediately. This allows more flexibility in how locking of the reservation object is done, which is needed to fix a locking bug (destroy locked mutex) in amdgpu. Signed-off-by: Nicolai

[PATCH 2/3] drm/ttm: fix the documentation of ttm_bo_init

From: Nicolai Hähnle <nicolai.haeh...@amd.com> As the comment says: callers of ttm_bo_init cannot rely on having the only reference to the BO when the function returns successfully. Signed-off-by: Nicolai Hähnle <nicolai.haeh...@amd.com> --- include/drm/ttm/ttm_bo_api.h | 6 ++

[PATCH 3/3] drm/amdgpu: fix lock cleanup during buffer creation

From: Nicolai Hähnle <nicolai.haeh...@amd.com> Open-code the initial ttm_bo_validate call, so that we can properly unlock the reservation lock when it fails. Also, properly destruct the reservation object when the first part of TTM BO initialization fails. Actual deadlocks caused by the m

Re: PRT support for amdgpu v3

On 08.02.2017 16:04, Christian König wrote: Hi guys, ok I finally found time to write an unit test for this and hammered out the last few bugs. Seems to work fine on my Tonga now. Please note that this set is based on "fix race in GEM VA map IOCTL v2", without that patch you will run into a

Re: [PATCH 1/3] drm/ttm: split BO structure initialization into a separate function

On 15.02.2017 04:16, zhoucm1 wrote: On 2017年02月14日 18:37, Nicolai Hähnle wrote: From: Nicolai Hähnle <nicolai.haeh...@amd.com> Allow callers to opt out of calling ttm_bo_validate immediately. This allows more flexibility in how locking of the reservation object is done, which is needed

Re: [PATCH 1/3] drm/ttm: split BO structure initialization into a separate function

On 14.02.2017 13:51, Christian König wrote: Am 14.02.2017 um 13:00 schrieb Nicolai Hähnle: On 14.02.2017 11:49, Christian König wrote: Am 14.02.2017 um 11:37 schrieb Nicolai Hähnle: From: Nicolai Hähnle <nicolai.haeh...@amd.com> Allow callers to opt out of calling ttm_bo_validate immed

Re: [PATCH v2 1/2] drm/amdgpu: fix a potential deadlock in amdgpu_bo_create_restricted()

On 09.02.2017 11:33, Samuel Pitoiset wrote: When ttm_bo_init() fails, the reservation mutex should be unlocked. In debug build, the kernel reported "possible recursive locking detected" in this codepath. For debugging purposes, I also added a "WARN_ON(ww_mutex_is_locked())" when ttm_bo_init()

Re: [PATCH] Add new gmc/smu registers

Hi Tom, it's probably a good idea to use subject prefixes for umr patches. git config format.subjectPrefix "PATCH umr" or edit .git/config accordingly, e.g. for libdrm I have this in .git/config: [format] subjectPrefix = PATCH libdrm Then format-patch and friends will automatically

Re: [PATCH 1/2] drm/amdgpu: fix PRT cleanup order in the VM

On 13.02.2017 14:23, Christian König wrote: From: Christian König <christian.koe...@amd.com> We need to unmap the PRTs first and then free our scheduler entity. Thanks for the quick fix! Both patches are Reviewed-by: Nicolai Hähnle <nicolai.haeh...@amd.com> ... and I'll probabl

Re: [PATCH v2 2/2] drm/amdgpu: report the number of bytes moved at buffer creation

On 09.02.2017 11:33, Samuel Pitoiset wrote: Like ttm_bo_validate(), ttm_bo_init() might need to move BO and the number of bytes moved by TTM should be reported. This can help the throttle buffer migration mechanism to make a better decision. Hmm, this could double-count bytes if there's a

Re: [PATCH v2 1/2] drm/amdgpu: fix a potential deadlock in amdgpu_bo_create_restricted()

On 13.02.2017 19:04, Nicolai Hähnle wrote: On 13.02.2017 18:49, Samuel Pitoiset wrote: On 02/13/2017 05:25 PM, Nicolai Hähnle wrote: On 09.02.2017 11:33, Samuel Pitoiset wrote: When ttm_bo_init() fails, the reservation mutex should be unlocked. In debug build, the kernel reported "pos

Re: [PATCH v2 1/2] drm/amdgpu: fix a potential deadlock in amdgpu_bo_create_restricted()

On 13.02.2017 19:11, Samuel Pitoiset wrote: On 02/13/2017 07:04 PM, Nicolai Hähnle wrote: On 13.02.2017 18:49, Samuel Pitoiset wrote: On 02/13/2017 05:25 PM, Nicolai Hähnle wrote: On 09.02.2017 11:33, Samuel Pitoiset wrote: When ttm_bo_init() fails, the reservation mutex should

Re: [PATCH 1/2] drm/amdgpu: fix PRT cleanup order in the VM

On 13.02.2017 17:40, Nicolai Hähnle wrote: On 13.02.2017 14:23, Christian König wrote: From: Christian König <christian.koe...@amd.com> We need to unmap the PRTs first and then free our scheduler entity. Thanks for the quick fix! Both patches are Reviewed-by: Nicolai Hähnle <nic

Re: [PATCH v2 1/2] drm/amdgpu: fix a potential deadlock in amdgpu_bo_create_restricted()

On 13.02.2017 18:49, Samuel Pitoiset wrote: On 02/13/2017 05:25 PM, Nicolai Hähnle wrote: On 09.02.2017 11:33, Samuel Pitoiset wrote: When ttm_bo_init() fails, the reservation mutex should be unlocked. In debug build, the kernel reported "possible recursive locking det

Re: Initial Public Release of AMDGPU debugger

On 13.02.2017 03:39, Dave Airlie wrote: Is there any plans or would it be possible to add some sort of info on what you are looking at with UMR. Say the GRBM busy states what sort of meaning can be extracted from the percentage values etc, can you say with how busy some of the blocks are what

Re: [PATCH v2 1/2] drm/amdgpu: fix a potential deadlock in amdgpu_bo_create_restricted()

On 13.02.2017 19:58, Nicolai Hähnle wrote: On 13.02.2017 19:38, Samuel Pitoiset wrote: On 02/13/2017 07:09 PM, Nicolai Hähnle wrote: On 13.02.2017 19:04, Nicolai Hähnle wrote: On 13.02.2017 18:49, Samuel Pitoiset wrote: On 02/13/2017 05:25 PM, Nicolai Hähnle wrote: On 09.02.2017 11:33

Re: [PATCH v2 1/2] drm/amdgpu: fix a potential deadlock in amdgpu_bo_create_restricted()

On 13.02.2017 19:38, Samuel Pitoiset wrote: On 02/13/2017 07:09 PM, Nicolai Hähnle wrote: On 13.02.2017 19:04, Nicolai Hähnle wrote: On 13.02.2017 18:49, Samuel Pitoiset wrote: On 02/13/2017 05:25 PM, Nicolai Hähnle wrote: On 09.02.2017 11:33, Samuel Pitoiset wrote: When ttm_bo_init

Re: [PATCH libdrm 1/2] amdgpu: add AMDGPU_VM_PAGE_PRT

On 09.02.2017 17:24, Emil Velikov wrote: On 8 February 2017 at 12:34, Nicolai Hähnle <nhaeh...@gmail.com> wrote: From: Nicolai Hähnle <nicolai.haeh...@amd.com> This is a new kernel interface. Signed-off-by: Nicolai Hähnle <nicolai.haeh...@amd.com> --- include/drm/amdgp

Re: [PATCH 3/6] drm/amdgpu: IOCTL interface for PRT support v4

viewed-by: Nicolai Hähnle <nicolai.haeh...@amd.com> Signed-off-by: Junwei Zhang <jerry.zh...@amd.com> Signed-off-by: Christian König <christian.koe...@amd.com> --- drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 16 +++-- dr

[PATCH v3 1/3] drm/ttm: fix the documentation of ttm_bo_init

From: Nicolai Hähnle <nicolai.haeh...@amd.com> As the comment says: callers of ttm_bo_init cannot rely on having the only reference to the BO when the function returns successfully. Signed-off-by: Nicolai Hähnle <nicolai.haeh...@amd.com> --- include/drm/ttm/ttm_bo_api.h | 6 ++

[PATCH v3 3/3] drm/amdgpu: simplify reservation handling during buffer creation

From: Nicolai Hähnle <nicolai.haeh...@amd.com> By using ttm_bo_init_reserved instead of the manual initialization of the reservation object, the reservation lock will be properly unlocked and destroyed when the TTM BO initialization fails. Actual deadlocks caused by the missing unlock

[PATCH v3 2/3] drm/ttm: add ttm_bo_init_reserved

From: Nicolai Hähnle <nicolai.haeh...@amd.com> This variant of ttm_bo_init returns the validated buffer object with the reservation lock held when resv == NULL. This is convenient for callers that want to use the BO immediately, e.g. for initializing its contents. Signed-off-by: Nicolai

Re: [PATCH v2 3/3] drm/amdgpu: fix lock cleanup during buffer creation

On 16.02.2017 02:00, Michel Dänzer wrote: On 16/02/17 04:10 AM, Nicolai Hähnle wrote: From: Nicolai Hähnle <nicolai.haeh...@amd.com> Open-code the initial ttm_bo_validate call, so that we can properly unlock the reservation lock when it fails. Also, properly destruct the reservation

Re: [PATCH 1/3] drm/ttm: split BO structure initialization into a separate function

On 15.02.2017 14:35, Nicolai Hähnle wrote: On 14.02.2017 13:51, Christian König wrote: Am 14.02.2017 um 13:00 schrieb Nicolai Hähnle: On 14.02.2017 11:49, Christian König wrote: Am 14.02.2017 um 11:37 schrieb Nicolai Hähnle: From: Nicolai Hähnle <nicolai.haeh...@amd.com> Allow c

Re: [PATCH 1/3] drm/amdgpu: minor PRT turnoff fix

Hi Christian, On 15.02.2017 16:59, Christian König wrote: Nicolai could you give that set a try? It should fix your problems with PRT tear down on process crash. Yes, it fixes those issues for me, thanks! The first two patches have my R-b, for the third one I don't really understand the bug

[PATCH v2 2/3] drm/ttm: fix the documentation of ttm_bo_init

From: Nicolai Hähnle <nicolai.haeh...@amd.com> As the comment says: callers of ttm_bo_init cannot rely on having the only reference to the BO when the function returns successfully. Signed-off-by: Nicolai Hähnle <nicolai.haeh...@amd.com> --- include/drm/ttm/ttm_bo_api.h | 6 ++

[PATCH v2 3/3] drm/amdgpu: fix lock cleanup during buffer creation

From: Nicolai Hähnle <nicolai.haeh...@amd.com> Open-code the initial ttm_bo_validate call, so that we can properly unlock the reservation lock when it fails. Also, properly destruct the reservation object when the first part of TTM BO initialization fails. Actual deadlocks caused by the m

Re: [PATCH 1/3] drm/ttm: split BO structure initialization into a separate function

On 15.02.2017 04:16, zhoucm1 wrote: On 2017年02月14日 18:37, Nicolai Hähnle wrote: From: Nicolai Hähnle <nicolai.haeh...@amd.com> Allow callers to opt out of calling ttm_bo_validate immediately. This allows more flexibility in how locking of the reservation object is done, which is

Re: [PATCH] drm/amdgpu: refuse to reserve io mem for split VRAM buffers

On 17.02.2017 11:08, Christian König wrote: Am 17.02.2017 um 00:21 schrieb Nicolai Hähnle: On 17.02.2017 00:02, Alex Deucher wrote: On Thu, Feb 16, 2017 at 5:55 PM, Nicolai Hähnle <nhaeh...@gmail.com> wrote: From: Nicolai Hähnle <nicolai.haeh...@amd.com> When the fast blit path

[PATCH] drm/amdgpu: initialize the context reset_counter in amdgpu_ctx_init

From: Nicolai Hähnle <nicolai.haeh...@amd.com> Ensure that we really only report a GPU reset if one has happened since the creation of the context. Signed-off-by: Nicolai Hähnle <nicolai.haeh...@amd.com> --- drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c | 3 +++ 1 file changed, 3 inserti

Re: [PATCH] drm/amdgpu: initialize the context reset_counter in amdgpu_ctx_init

On 06.10.2016 16:43, Marek Olšák wrote: On Thu, Oct 6, 2016 at 4:24 PM, Alex Deucher wrote: On Thu, Oct 6, 2016 at 6:28 AM, Marek Olšák wrote: Do we need to bump the DRM version for this bug fix? Alternatively, we could just cc stable. Being that

Re: Raciness with page table shadows being swapped out

On 14.12.2016 15:56, Christian König wrote: Am 14.12.2016 um 15:22 schrieb Nicolai Hähnle: On 13.12.2016 10:48, Christian König wrote: The attached patch has fixed these crashes for me so far, but it's very heavy-handed: it collects all page table shadows and the page directory shadow and adds

[PATCH 1/5] drm/ttm: add evict parameter to ttm_bo_driver::move_notify

From: Nicolai Hähnle <nicolai.haeh...@amd.com> Ensure that the driver can listen to evictions even when they don't take the path through ttm_bo_driver::move. This is crucial for amdgpu, which relies on an eviction counter to skip re-binding page tables when possible. Signed-off-by: N

[PATCH 5/5] drm/amd/amdgpu: add check that shadow page tables are GPU-accessible

From: Nicolai Hähnle <nicolai.haeh...@amd.com> Skip amdgpu_gem_va_update_vm otherwise. Also clean up the check for the non-shadow page tables using the new helper function. This fixes a crash with the stack trace: amdgpu_gem_va_update_vm -> amdgpu_vm_update_page_directory -> amd

[PATCH 3/5] drm/amd/amdgpu: add amdgpu_bo_gpu_accessible helper function

From: Nicolai Hähnle <nicolai.haeh...@amd.com> Signed-off-by: Nicolai Hähnle <nicolai.haeh...@amd.com> --- drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 9 + 1 file changed, 9 insertions(+) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h b/drivers/gpu/dr

[PATCH 2/5] drm/amd/amdgpu: move eviction counting to amdgpu_bo_move_notify

From: Nicolai Hähnle <nicolai.haeh...@amd.com> This catches evictions of shadow page tables from the GART. Since shadow page tables are always stored in system memory, amdgpu_bo_move is never called for them. This fixes a crash during command submission that occurs when only a shadow page

[PATCH v2] drm/amd/amdgpu: add check that shadow page tables are GPU-accessible

From: Nicolai Hähnle <nicolai.haeh...@amd.com> Skip amdgpu_gem_va_update_vm otherwise. Also clean up the check for the non-shadow page tables using the new helper function. This fixes a crash with the stack trace: amdgpu_gem_va_update_vm -> amdgpu_vm_update_page_directory -> amd

Re: Raciness with page table shadows being swapped out

On 13.12.2016 10:48, Christian König wrote: The attached patch has fixed these crashes for me so far, but it's very heavy-handed: it collects all page table shadows and the page directory shadow and adds them all to the reservations for the callers of amdgpu_vm_update_page_directory. That is

Raciness with page table shadows being swapped out

Hi all, I just sent out two patches that hopefully make the kernel module more robust in the face of page table shadows being swapped out. However, even with those patches, I can still fairly reliably reproduce crashes with a backtrace of the shape amdgpu_cs_ioctl ->

Re: [PATCH 1/2] drm/amd/amdgpu: lock reservation object while creating shadow bo

On 11.01.2017 12:56, Christian König wrote: Am 11.01.2017 um 08:31 schrieb Nicolai Hähnle: From: Nicolai Hähnle <nicolai.haeh...@amd.com> ttm_bo_init checks that the reservation object is locked. This is the caller's responsibility when resv != NULL. Otherwise, the inline reservation

Re: [PATCH 1/2] drm/amd/amdgpu: lock reservation object while creating shadow bo

On 11.01.2017 12:56, Christian König wrote: Am 11.01.2017 um 08:31 schrieb Nicolai Hähnle: From: Nicolai Hähnle <nicolai.haeh...@amd.com> ttm_bo_init checks that the reservation object is locked. This is the caller's responsibility when resv != NULL. Otherwise, the inline reservation

[PATCH v2 1/2] drm/amd/amdgpu: lock reservation object while creating shadow bo

From: Nicolai Hähnle <nicolai.haeh...@amd.com> ttm_bo_init checks that the reservation object is locked. This is the caller's responsibility when resv != NULL. Otherwise, the inline reservation object of the newly allocated buffer is used and must explicitly be locked. Uninterruptible w/w

[PATCH v2 2/2] drm/amd/amdgpu: fix locking in bo creation error path

From: Nicolai Hähnle <nicolai.haeh...@amd.com> Unlock the resv lock only if we were the ones to lock it in the first place. Signed-off-by: Nicolai Hähnle <nicolai.haeh...@amd.com> Reviewed-by: Edward O'Callaghan <funfunc...@folklore1984.net> Reviewed-by: Christian König <chr

[PATCH 1/2] drm/amd/amdgpu: lock reservation object while creating shadow bo

From: Nicolai Hähnle <nicolai.haeh...@amd.com> ttm_bo_init checks that the reservation object is locked. This is the caller's responsibility when resv != NULL. Otherwise, the inline reservation object of the newly allocated buffer is used and must explicitly be locked. Using a trylock i

[PATCH 0/2] drm/amd/amdgpu: locking fixes

Hi all, two fixes for locking issues that I noticed. The first one is something that I actually encountered live; it probably only matters when lock debugging is enabled, but obviously needs to be fixed anyway. The second one I only noticed upon reading the code -- I haven't seen it fail live

[PATCH 2/2] drm/amd/amdgpu: fix locking in bo creation error path

From: Nicolai Hähnle <nicolai.haeh...@amd.com> Unlock the resv lock only if we were the ones to lock it in the first place. Signed-off-by: Nicolai Hähnle <nicolai.haeh...@amd.com> --- drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)

Re: [PATCH 1/5] drm/ttm: add evict parameter to ttm_bo_driver::move_notify

On 16.12.2016 03:49, zhoucm1 wrote: On 2016年12月16日 01:10, Nicolai Hähnle wrote: From: Nicolai Hähnle <nicolai.haeh...@amd.com> Ensure that the driver can listen to evictions even when they don't take the path through ttm_bo_driver::move. This is crucial for amdgpu, which relies on an ev

Question about page table updates at BO destroy

Hi all, there's a bit of a puzzle where I'm wondering whether there's a subtle bug in the amdgpu kernel module. Basically, the concern is that a buggy user space driver might trigger a sequence like this: 1. Submit a CS that accesses some BO _without_ adding that BO to the buffer list.

Re: [PATCH 1/2] drm/amdgpu: guarantee bijective mapping of ring ids for LRU

atic bool amdgpu_ring_is_blacklisted(struct amdgpu_ring *ring, + int *blacklist, int num_blacklist) +{ + int i; + + for (i = 0; i < num_blacklist && blacklist[i] != -1; i++) { ... and then you can also drop the blacklist[i] != -1 h

Re: [PATCH 1/2] drm/amdgpu: guarantee bijective mapping of ring ids for LRU

On 17.03.2017 19:52, Andres Rodriguez wrote: Depending on usage patterns, the current LRU policy may create a non-injective mapping between userspace ring ids and kernel rings. This behaviour is undesired as apps that attempt to fill all HW blocks would be unable to reach some of them. This

Re: Question about page table updates at BO destroy

Hi Jerry, On 23.03.2017 03:26, Zhang, Jerry (Junwei) wrote: On 03/22/2017 11:06 PM, Nicolai Hähnle wrote: Hi all, there's a bit of a puzzle where I'm wondering whether there's a subtle bug in the amdgpu kernel module. Basically, the concern is that a buggy user space driver might trigger

Re: [PATCH] Revert "drm/radeon: Try evicting from CPU accessible to inaccessible VRAM first"

On 29.03.2017 11:36, Michel Dänzer wrote: On 29/03/17 06:07 PM, Christian König wrote: Am 29.03.2017 um 10:59 schrieb Michel Dänzer: On 28/03/17 08:00 PM, Julien Isorce wrote: On 28 March 2017 at 10:36, Michel Dänzer > wrote: On 28/03/17

[PATCH v2 1/2] drm/amdgpu: add optional fence out-parameter to amdgpu_vm_clear_freed

From: Nicolai Hähnle <nicolai.haeh...@amd.com> We will add the fence to freed buffer objects in a later commit, to ensure that the underlying memory can only be re-used after all references in page tables have been cleared. Signed-off-by: Nicolai Hähnle <nicolai.haeh...@amd.com> ---

[PATCH v2 2/2] drm/amdgpu: clear freed mappings immediately when BO may be freed

From: Nicolai Hähnle <nicolai.haeh...@amd.com> Also, add the fence of the clear operations to the BO to ensure that the underlying memory can only be re-used after all PTEs pointing to it have been cleared. This avoids the following sequence of events that could be triggered by user spa

Re: [PATCH] drm/amdgpu: clear freed mappings immediately when BO may be freed

On 23.03.2017 19:18, Christian König wrote: Am 23.03.2017 um 18:22 schrieb Nicolai Hähnle: From: Nicolai Hähnle <nicolai.haeh...@amd.com> Also, add the fence of the clear operations to the BO to ensure that the underlying memory can only be re-used after all PTEs pointing to it hav

Re: [PATCH 1/2] amdgpu: add new VA operations CLEAR and REPLACE

This should use the proper procedure for updating amdgpu_drm.h, as explained in include/drm/README. I can take care of this as soon as all the kernel patches for PRT are in a tree that doesn't rebase (i.e. agd5f/drm-next-4.12 or airlied/drm-next). Nicolai On 17.03.2017 06:59, Junwei Zhang

Re: [PATCH 2/2] amdgpu: add REPLACE and CLEAR checking for VA op

On 17.03.2017 06:59, Junwei Zhang wrote: Signed-off-by: Junwei Zhang --- amdgpu/amdgpu_bo.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/amdgpu/amdgpu_bo.c b/amdgpu/amdgpu_bo.c index 71cd666..8fe3cfd 100644 --- a/amdgpu/amdgpu_bo.c +++

Re: [PATCH libdrm 2/7] amdgpu: update amdgpu_drm.h for Vega10

In the past, I was told off for patches that update this file without following the procedure described in include/drm/README. Tbh, that procedure causes some annoyances. Anyway, it's definitely useful to have the patch out on the mailing list in any case. Cheers, Nicolai On 21.03.2017

Re: [PATCH libdrm v2] amdgpu: add REPLACE and CLEAR checking for VA op (v2)

On 22.03.2017 04:14, Junwei Zhang wrote: v2: fix indent Signed-off-by: Junwei Zhang <jerry.zh...@amd.com> Reviewed-by: Nicolai Hähnle <nicolai.haeh...@amd.com> --- amdgpu/amdgpu_bo.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/amdgpu/amdgpu_b

[PATCH libdrm 1/3] headers: sync amdgpu_drm.h from airlied/drm-next

From: Nicolai Hähnle <nicolai.haeh...@amd.com> Changes include: PRT and preemption flags, sensor info, and some more changes for Vega10. Generated using make headers_install from airlied/drm-next commit 320d8c3d38739fa8e31a076b86cbdafcf8897d5e. Signed-off-by: Nicolai Hähnle <nic

[PATCH libdrm 3/3] amdgpu: add REPLACE and CLEAR checking for VA op (v2)

From: Junwei Zhang <jerry.zh...@amd.com> v2: fix indent Signed-off-by: Junwei Zhang <jerry.zh...@amd.com> Reviewed-by: Nicolai Hähnle <nicolai.haeh...@amd.com> Reviewed-by: Christian König <christian.koe...@amd.com> --- amdgpu/amdgpu_bo.c | 4 +++- 1 file changed, 3 i

[PATCH libdrm 2/3] headers: the uint*_t vs. __u* discrepancy in amdgpu_drm is fixed

From: Nicolai Hähnle <nicolai.haeh...@amd.com> This was already done in commit 3dc002df3e5 ("amdgpu: sync amdgpu_drm.h with kernel 4.11-rc2"), now update the README accordingly. Signed-off-by: Nicolai Hähnle <nicolai.haeh...@amd.com> --- include/drm/README | 4 1 fil

Re: [PATCH 5/6] drm/amdgpu: use TTM_PL_FLAG_CONTIGUOUS

On 04.04.2017 13:33, Christian König wrote: Am 03.04.2017 um 18:22 schrieb Nicolai Hähnle: On 31.03.2017 11:47, Christian König wrote: From: Christian König <christian.koe...@amd.com> Implement AMDGPU_GEM_CREATE_VRAM_CONTIGUOUS using TTM_PL_FLAG_CONTIGUOUS instead of a placement

Re: [PATCH 2/2] drm/amdgpu: handle CPU access for split VRAM buffers

ons in the earlier thread. Both patches are Reviewed-by: Nicolai Hähnle <nicolai.haeh...@amd.com> --- drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 4 +--- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 16 2 files changed, 13 insertions(+), 7 deletions(-) diff --git a/dr

Re: [PATCH 3/6] drm/ttm: add TTM_PL_FLAG_CONTIGUOUS v2

-by: Nicolai Hähnle <nicolai.haeh...@amd.com> Patch 4: Acked-by: Nicolai Hähnle <nicolai.haeh...@amd.com> --- drivers/gpu/drm/ttm/ttm_bo.c| 4 +++- include/drm/ttm/ttm_placement.h | 1 + 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/ttm/ttm_bo

Re: [PATCH 5/6] drm/amdgpu: use TTM_PL_FLAG_CONTIGUOUS

On 31.03.2017 11:47, Christian König wrote: From: Christian König Implement AMDGPU_GEM_CREATE_VRAM_CONTIGUOUS using TTM_PL_FLAG_CONTIGUOUS instead of a placement limit. That allows us to better handle CPU accessible placements. Signed-off-by: Christian König

Re: [PATCH] radeonsi: add new polaris10 pci id

On 05.04.2017 15:46, Alex Deucher wrote: Cc: 13.0 17.0 <mesa-sta...@lists.freedesktop.org> Signed-off-by: Alex Deucher <alexander.deuc...@amd.com> Reviewed-by: Nicolai Hähnle <nicolai.haeh...@amd.com> --- include/pci_ids/radeonsi_pci_ids.h | 1 + 1 file changed, 1 insert

Re: [PATCH] drm/amdgpu: fix VM clearing in amdgpu_gem_object_close

("drm/amdgpu: clear freed mappings immediately when BO may be freed") Reviewed-by: Nicolai Hähnle <nicolai.haeh...@amd.com> --- drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 68 ++--- 1 file changed, 37 insertions(+), 31 deletions(-) diff --git

Re: [PATCH 3/3] drm/amdgpu: CIK support is no longer experimental

On 11.04.2017 00:06, Felix Kuehling wrote: On 17-04-08 04:50 AM, Nicolai Hähnle wrote: On 07.04.2017 22:15, Felix Kuehling wrote: Change the wording of the CONFIG_DRM_AMDGPU_CIK option to indicate that it's no longer experimental. Signed-off-by: Felix Kuehling <felix.kuehl...@amd.

  1   2   >