Hey Chunming,
On 20.09.2018 13:03, Chunming Zhou wrote:
@@ -1113,48 +1117,91 @@ static int amdgpu_syncobj_lookup_and_add_to_sync(struct
amdgpu_cs_parser *p,
}
static int amdgpu_cs_process_syncobj_in_dep(struct amdgpu_cs_parser *p,
- struct amdgp
static int amdgpu_cs_submit(struct amdgpu_cs_parser *p,
diff --git a/include/uapi/drm/amdgpu_drm.h b/include/uapi/drm/amdgpu_drm.h
index 1ceec56de015..412359b446f1 100644
--- a/include/uapi/drm/amdgpu_drm.h
+++ b/include/uapi/drm/amdgpu_drm.h
@@ -517,6 +517,8 @@ struct drm_amdgpu_gem_va {
#def
On 12.04.2018 01:30, Cyr, Aric wrote:
At least with VDPAU, video players are already explicitly specifying the
target presentation time, so no changes should be required at that
level. Don't know about other video APIs.
The X11 Present extension protocol is also prepared for specifying the
targe
On 10.04.2018 23:45, Cyr, Aric wrote:
For video games we have a similar situation where a frame is rendered
for a certain world time and in the ideal case we would actually
display the frame at this world time.
That seems like it would be a poorly written game that flips like
that, unless they
On 10.04.2018 19:25, Cyr, Aric wrote:
-Original Message-
From: Michel Dänzer [mailto:mic...@daenzer.net]
Sent: Tuesday, April 10, 2018 13:16
On 2018-04-10 07:13 PM, Cyr, Aric wrote:
-Original Message-
From: Michel Dänzer [mailto:mic...@daenzer.net]
Sent: Tuesday, April 10, 2018
On 10.04.2018 18:26, Cyr, Aric wrote:
That presentation time doesn’t need to come to kernel as such and
actually is fine as-is completely decoupled from adaptive sync. As long
as the video player provides the new target_frame_duration_ns on the
flip, then the driver/HW will target the correct
On 30.01.2018 12:34, Michel Dänzer wrote:
On 2018-01-30 12:28 PM, Christian König wrote:
Am 30.01.2018 um 12:02 schrieb Michel Dänzer:
On 2018-01-30 11:40 AM, Christian König wrote:
Am 30.01.2018 um 10:43 schrieb Michel Dänzer:
[SNIP]
Would it be ok to hang onto potentially arbitrary mmget r
On 30.01.2018 11:48, Michel Dänzer wrote:
On 2018-01-30 11:42 AM, Daniel Vetter wrote:
On Tue, Jan 30, 2018 at 10:43:10AM +0100, Michel Dänzer wrote:
On 2018-01-30 10:31 AM, Daniel Vetter wrote:
I guess a good first order approximation would be if we simply charge any
newly allocated buffers
On 17.11.2017 20:18, Christian König wrote:
The obvious alternative which we are working on for a few years now is
to improve the input data we get from the hardware people.
In other words instead of getting a flat list of registers we want the
information about where and how many times a hard
On 16.11.2017 21:57, Dave Airlie wrote:
On 16 November 2017 at 14:59, Linus Torvalds
wrote:
On Wed, Nov 15, 2017 at 6:34 PM, Dave Airlie wrote:
There is some code touched on sound/soc, but I think the sound tree
should have the same commits from the same base,so this may luck different
if yo
Both patches:
Reviewed-by: Nicolai Hähnle
On 20.10.2017 16:57, Andres Rodriguez wrote:
Generated using make headers_install from:
airlied/drm-next 282dc83 Merge tag 'drm-intel-next-2017-10-12' ...
Signed-off-by: Andres Rodriguez
---
include/drm/amdgpu_
On 17.10.2017 21:53, Ville Syrjälä wrote:
On Tue, Oct 17, 2017 at 09:00:56PM +0200, Nicolai Hähnle wrote:
On 17.10.2017 16:09, Ville Syrjälä wrote:
On Tue, Oct 17, 2017 at 03:46:24PM +0200, Michel Dänzer wrote:
On 17/10/17 02:22 PM, Daniel Vetter wrote:
On Tue, Oct 17, 2017 at 12:28:17PM
On 18.10.2017 10:10, Daniel Vetter wrote:
On Tue, Oct 17, 2017 at 09:01:52PM +0200, Nicolai Hähnle wrote:
On 17.10.2017 19:16, Daniel Vetter wrote:
On Tue, Oct 17, 2017 at 5:40 PM, Michel Dänzer wrote:
On 17/10/17 05:04 PM, Daniel Vetter wrote:
On Tue, Oct 17, 2017 at 03:46:24PM +0200
, Michel Dänzer wrote:
On 17/10/17 11:34 AM, Nicolai Hähnle wrote:
Common sense suggests that there need to be two side to FreeSync / VESA
Adaptive Sync support:
1. Query the display capabilities. This means querying minimum / maximum
refresh duration, plus possibly a query for when the earliest
On 17.10.2017 16:09, Ville Syrjälä wrote:
On Tue, Oct 17, 2017 at 03:46:24PM +0200, Michel Dänzer wrote:
On 17/10/17 02:22 PM, Daniel Vetter wrote:
On Tue, Oct 17, 2017 at 12:28:17PM +0200, Michel Dänzer wrote:
On 17/10/17 11:34 AM, Nicolai Hähnle wrote:
Common sense suggests that there
Hi all,
I just sent out a patch that enables FreeSync in Mesa for the somewhat
hacked implementation of FreeSync that exists in our hybrid (amdgpu-pro)
stack's DDX and kernel module. [0]
While this patch isn't meant for upstream, that's as good a time as any
to raise the issue of how a prope
On 17.10.2017 12:28, Michel Dänzer wrote:
On 17/10/17 11:34 AM, Nicolai Hähnle wrote:
Hi all,
I just sent out a patch that enables FreeSync in Mesa for the somewhat
hacked implementation of FreeSync that exists in our hybrid (amdgpu-pro)
stack's DDX and kernel module. [0]
While this
On 18.04.2017 17:48, Rob Clark wrote:
On Fri, Apr 14, 2017 at 1:04 PM, Raghav Jajodia
wrote:
Hi there
I am Raghav Jajodia, an Engineering student from India. While going through
the X.org foundation, I felt that X.org is a great community for new Open
Source developers. I am deeply interested
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
Implement AMDGPU_GEM_CREATE_VRAM_CONTIGUOUS using TTM_PL_FLAG_CONTIGUOUS
instead of a placement limit. That allows us to better handle
On 31.03.2017 11:47, Christian König wrote:
From: Christian König
This allows drivers to specify if they need a contiguous allocation or not.
v2: use space instead of tab
Signed-off-by: Christian König
Patches 1-3:
Reviewed-by: Nicolai Hähnle
Patch 4:
Acked-by: Nicolai Hähnle
On 31.03.2017 11:47, Christian König wrote:
From: Christian König
This avoids merging them together on page fault.
Signed-off-by: Christian König
Acked-by: Michel Dänzer
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 4 +---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 16 ---
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
Acked-by: Michel Dänzer
---
driv
From: Junwei Zhang
v2: fix indent
Signed-off-by: Junwei Zhang
Reviewed-by: Nicolai Hähnle
Reviewed-by: Christian König
---
amdgpu/amdgpu_bo.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/amdgpu/amdgpu_bo.c b/amdgpu/amdgpu_bo.c
index f725bfd..8bc1ebd 100644
--- a
From: Nicolai Hähnle
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
---
include/drm/README | 4
1 file changed, 4 deletions(-)
diff --git a/include/drm/README b/i
From: Nicolai Hähnle
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
---
include/drm/amdgpu_drm.h | 56
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 mailto:mic...@daenzer.net>> wrote:
On 28/03/17 05:24 PM, Julien Isorce
On 27.03.2017 04:09, Seung-Woo Kim wrote:
In error path of drmGetBusid() and drmGetReservedContextList(),
there are memory leaks for error path. So this removes them.
Signed-off-by: Seung-Woo Kim
Reviewed-by: Nicolai Hähnle
---
xf86drm.c | 18 --
1 files changed, 12
From: Nicolai Hähnle
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 related to vm fault retries
From: Nicolai Hähnle
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
---
include/drm/ttm/ttm_bo_api.h | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a
From: Nicolai Hähnle
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 should have been fixed
by "dr
From: Nicolai Hähnle
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 Hähnle
---
drivers/gpu/drm/ttm
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
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
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
Allow callers to opt out of calling
On 15.02.2017 04:16, zhoucm1 wrote:
On 2017年02月14日 18:37, Nicolai Hähnle wrote:
From: Nicolai Hähnle
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
From: Nicolai Hähnle
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
---
include/drm/ttm/ttm_bo_api.h | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a
From: Nicolai Hähnle
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.
v2: callers of ttm_bo_init_top should use ttm_bo_unref for
From: Nicolai Hähnle
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 missing unlock should have been
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
Allow callers to opt out of calling ttm_bo_validate immediately. This
allows more
On 15.02.2017 04:16, zhoucm1 wrote:
On 2017年02月14日 18:37, Nicolai Hähnle wrote:
From: Nicolai Hähnle
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
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
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
From: Nicolai Hähnle
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 function
‘amdgpu_bo_create_restricted
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
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
From: Nicolai Hähnle
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 Hähnle
---
drivers/gpu/drm/ttm
From: Nicolai Hähnle
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
---
include/drm/ttm/ttm_bo_api.h | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a
From: Nicolai Hähnle
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 missing unlock should have been
From: Nicolai Hähnle
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 reference of the BO; never gives up
From: Nicolai Hähnle
This reverts commit 38fc4856ad98f230bc91da0421dec69e4aee40f8, which
introduces a use-after-free.
The underlying bug should be properly fixed with "drm/ttm: never add BO
that failed to validate to the LRU list".
Cc: Samuel Pitoiset
Cc: zhoucm1
Signed-off-b
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 qui
On 22.01.2017 19:48, Emil Velikov wrote:
Cc: amd-...@lists.freedesktop.org
Signed-off-by: Emil Velikov
Reviewed-by: Nicolai Hähnle
---
amdgpu/amdgpu_bo.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/amdgpu/amdgpu_bo.c b/amdgpu/amdgpu_bo.c
index d30fd1e7..c9f31587 100644
--- a
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 possi
Hi Rob,
On 19.01.2017 23:32, Rob Clark wrote:
Just a friendly reminder that now would be a good time to update the
wiki page for GSoC/EVoC ideas:
https://www.x.org/wiki/SummerOfCodeIdeas/
There are currently still some stale ideas there (and probably plenty
of missing good ideas).
Also, I'v
On 23.12.2016 11:48, Peter Zijlstra wrote:
> On Wed, Dec 21, 2016 at 07:46:33PM +0100, Nicolai Hähnle wrote:
>> diff --git a/include/linux/ww_mutex.h b/include/linux/ww_mutex.h
>> index a5960e5..b2eaaab 100644
>> --- a/include/linux/ww_mutex.h
>> +++ b/include/linux/ww_mutex.h
>> @@ -186,11 +186,6
On 22.12.2016 02:58, zhoucm1 wrote:
> On 2016å¹´12æ22æ¥ 02:46, Nicolai Hähnle wrote:
>> +static inline bool __sched
>> +__ww_ctx_stamp_after(struct ww_acquire_ctx *a, struct ww_acquire_ctx *b)
>> +{
>> +return a->stamp - b->stamp <= LONG_MAX &&
>> + (a->stamp != b->stamp || a > b)
From: Nicolai Hähnle
Document the invariants we maintain for the wait list of ww_mutexes.
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Maarten Lankhorst
Cc: Daniel Vetter
Cc: Chris Wilson
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Nicolai Hähnle
---
Documentation/locking/ww-mutex-d
From: Nicolai Hähnle
Help catch cases where mutex_lock is used directly on w/w mutexes, which
otherwise result in the w/w tasks reading uninitialized data.
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Maarten Lankhorst
Cc: Daniel Vetter
Cc: Chris Wilson
Cc: dri-devel at lists.freedesktop.org
Sig
From: Nicolai Hähnle
Lock stealing is less beneficial for w/w mutexes since we may just end up
backing off if we stole from a thread with an earlier acquire stamp that
already holds another w/w mutex that we also need. So don't spin
optimistically unless we are sure that there is no other waiter
From: Nicolai Hähnle
In the following scenario, thread #1 should back off its attempt to lock
ww1 and unlock ww2 (assuming the acquire context stamps are ordered
accordingly).
Thread #0 Thread #1
- -
successfully lo
From: Nicolai Hähnle
The wait list is sorted by stamp order, and the only waiting task that may
have to back off is the first waiter with a context.
The regular slow path does not have to wake any other tasks at all, since
all other waiters that would have to back off were either woken up when
From: Nicolai Hähnle
While adding our task as a waiter, detect if another task should back off
because of us.
With this patch, we establish the invariant that the wait list contains
at most one (sleeping) waiter with ww_ctx->acquired > 0, and this waiter
will be the first waiter with a context.
From: Nicolai Hähnle
Add regular waiters in stamp order. Keep adding waiters that have no
context in FIFO order and take care not to starve them.
While adding our task as a waiter, back off if we detect that there is a
waiter with a lower stamp in front of us.
Make sure to call lock_contended
From: Nicolai Hähnle
Keep the documentation in the header file since there is no good
place for it in mutex.c: there are two rather different
implementations with different EXPORT_SYMBOLs for each function.
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Maarten Lankhorst
Cc: Daniel Vetter
Cc: Chris
From: Nicolai Hähnle
We will add a new field to struct mutex_waiter. This field must be
initialized for all waiters if any waiter uses the ww_use_ctx path.
So there is a trade-off: Keep ww_mutex locking without a context on the
faster non-use_ww_ctx path, at the cost of adding the initializati
From: Nicolai Hähnle
The function will be re-used in subsequent patches.
v3: rename to __ww_ctx_stamp_after (Chris Wilson)
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Maarten Lankhorst
Cc: Daniel Vetter
Cc: Chris Wilson
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Nicolai Hähnle
Rev
From: Nicolai Hähnle
There's a possible race where the waiter in front of us leaves the wait list
due to a signal, and the current owner subsequently hands the lock off to us
even though we never observed ourselves at the front of the list.
Set the task state before checking our position in the
From: Nicolai Hähnle
v2: use resv->lock instead of resv->lock.base (Christian König)
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Maarten Lankhorst
Cc: Daniel Vetter
Cc: Chris Wilson
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Nicolai Hähnle
---
drivers/gpu/drm/vgem/vgem_fence.c |
On 16.12.2016 03:49, zhoucm1 wrote:
> On 2016å¹´12æ16æ¥ 01:10, Nicolai Hähnle wrote:
>> From: Nicolai Hähnle
>>
>> 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
On 16.12.2016 21:00, Peter Zijlstra wrote:
> On Fri, Dec 16, 2016 at 07:11:41PM +0100, Nicolai Hähnle wrote:
>> mutex_optimistic_spin() already calls __mutex_trylock, and for the no-spin
>> case, __mutex_unlock_slowpath() only calls wake_up_q() after releasing the
>> wait_lock.
>
> mutex_optimisti
On 16.12.2016 18:20, Peter Zijlstra wrote:
> On Fri, Dec 16, 2016 at 03:19:43PM +0100, Nicolai Hähnle wrote:
@@ -716,7 +775,20 @@ __mutex_lock_common(struct mutex *lock, long state,
unsigned int subclass,
spin_unlock_mutex(&lock->wait_lock, flags);
sche
On 16.12.2016 18:15, Peter Zijlstra wrote:
> On Fri, Dec 16, 2016 at 03:19:43PM +0100, Nicolai Hähnle wrote:
>> The concern about picking up a handoff that we didn't request is real,
>> though it cannot happen in the first iteration. Perhaps this __mutex_trylock
>> can be moved to the end of the l
On 01.12.2016 16:59, Chris Wilson wrote:
> On Thu, Dec 01, 2016 at 03:06:48PM +0100, Nicolai Hähnle wrote:
>> @@ -677,15 +722,25 @@ __mutex_lock_common(struct mutex *lock, long state,
>> unsigned int subclass,
>> debug_mutex_lock_common(lock, &waiter);
>> debug_mutex_add_waiter(lock, &w
Hi Peter and Chris,
(trying to combine the handoff discussion here)
On 06.12.2016 17:55, Peter Zijlstra wrote:
> On Thu, Dec 01, 2016 at 03:06:48PM +0100, Nicolai Hähnle wrote:
>> @@ -693,8 +748,12 @@ __mutex_lock_common(struct mutex *lock, long state,
>> unsigned int subclass,
>>
On 06.12.2016 16:36, Peter Zijlstra wrote:
> On Thu, Dec 01, 2016 at 03:06:48PM +0100, Nicolai Hähnle wrote:
>> +static inline int __sched
>> +__ww_mutex_add_waiter(struct mutex_waiter *waiter,
>> + struct mutex *lock,
>> + struct ww_acquire_ctx *ww_ctx)
>> +{
>>
On 06.12.2016 16:25, Peter Zijlstra wrote:
> On Thu, Dec 01, 2016 at 03:06:47PM +0100, Nicolai Hähnle wrote:
>
>> @@ -640,10 +640,11 @@ __mutex_lock_common(struct mutex *lock, long state,
>> unsigned int subclass,
>> struct mutex_waiter waiter;
>> unsigned long flags;
>> bool first
From: Nicolai Hähnle
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
-> amdgpu_ttm_bind
-> amdgpu_gtt_mgr_alloc
From: Nicolai Hähnle
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
-> amdgpu_ttm_bind
-> amdgpu_gtt_mgr_alloc
From: Nicolai Hähnle
Skip amdgpu_gem_va_update_vm when shadow the page directory is swapped out.
Clean up the check for non-shadow BOs as well using the new helper function.
This fixes a crash with the stack trace:
amdgpu_gem_va_update_vm
-> amdgpu_vm_update_page_directory
-> amdgpu_ttm_bind
From: Nicolai Hähnle
Signed-off-by: Nicolai Hähnle
---
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/drm/amd/amdgpu/amdgpu_object.h
index 4306b2f..15a723a 100644
--- a/drivers/g
From: Nicolai Hähnle
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 table and no other BOs were evi
From: Nicolai Hähnle
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: Nicolai Hähnle
---
drivers/gpu/drm
Fix a bunch of related crashes in amdgpu that occur when shadow page tables
are kicked out of the GART.
One of the issues was that during command submission, we rely on a
device-global evictions counter to skip some of the work of page-table
validation. The driver was never informed of evictions f
From: Nicolai Hähnle
Check the current owner's context once against our stamp. If our stamp is
lower, we continue to spin optimistically instead of backing off.
This is correct with respect to deadlock detection because while the
(owner, ww_ctx) pair may re-appear if the owner task manages to u
From: Nicolai Hähnle
Document the invariants we maintain for the wait list of ww_mutexes.
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Maarten Lankhorst
Cc: Daniel Vetter
Cc: Chris Wilson
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Nicolai Hähnle
---
Documentation/locking/ww-mutex-d
From: Nicolai Hähnle
Help catch cases where mutex_lock is used directly on w/w mutexes, which
otherwise result in the w/w tasks reading uninitialized data.
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Maarten Lankhorst
Cc: Daniel Vetter
Cc: Chris Wilson
Cc: dri-devel at lists.freedesktop.org
Sig
From: Nicolai Hähnle
Lock stealing is less beneficial for w/w mutexes since we may just end up
backing off if we stole from a thread with an earlier acquire stamp that
already holds another w/w mutex that we also need. So don't spin
optimistically unless we are sure that there is no other waiter
From: Nicolai Hähnle
The wait list is sorted by stamp order, and the only waiting task that may
have to back off is the first waiter with a context.
The regular slow path does not have to wake any other tasks at all, since
all other waiters that would have to back off were either woken up when
From: Nicolai Hähnle
While adding our task as a waiter, detect if another task should back off
because of us.
With this patch, we establish the invariant that the wait list contains
at most one (sleeping) waiter with ww_ctx->acquired > 0, and this waiter
will be the first waiter with a context.
From: Nicolai Hähnle
Add regular waiters in stamp order. Keep adding waiters that have no
context in FIFO order and take care not to starve them.
While adding our task as a waiter, back off if we detect that there is a
waiter with a lower stamp in front of us.
Make sure to call lock_contended
From: Nicolai Hähnle
We will add a new field to struct mutex_waiter. This field must be
initialized for all waiters if any waiter uses the ww_use_ctx path.
So there is a trade-off: Keep ww_mutex locking without a context on the
faster non-use_ww_ctx path, at the cost of adding the initializati
From: Nicolai Hähnle
The function will be re-used in subsequent patches.
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Maarten Lankhorst
Cc: Daniel Vetter
Cc: Chris Wilson
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Nicolai Hähnle
---
kernel/locking/mutex.c | 10 --
1 file ch
From: Nicolai Hähnle
In the following scenario, thread #1 should back off its attempt to lock
ww1 and unlock ww2 (assuming the acquire context stamps are ordered
accordingly).
Thread #0 Thread #1
- -
successfully lo
From: Nicolai Hähnle
v2: use resv->lock instead of resv->lock.base (Christian König)
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Maarten Lankhorst
Cc: Daniel Vetter
Cc: Chris Wilson
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Nicolai Hähnle
---
drivers/gpu/drm/vgem/vgem_fence.c |
From: Nicolai Hähnle
Check the current owner's context once against our stamp. If our stamp is
lower, we continue to spin optimistically instead of backing off.
This is correct with respect to deadlock detection because while the
(owner, ww_ctx) pair may re-appear if the owner task manages to u
From: Nicolai Hähnle
Document the invariants we maintain for the wait list of ww_mutexes.
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Maarten Lankhorst
Cc: Daniel Vetter
Cc: Chris Wilson
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Nicolai Hähnle
---
Documentation/locking/ww-mutex-d
From: Nicolai Hähnle
Help catch cases where mutex_lock is used directly on w/w mutexes, which
otherwise result in the w/w tasks reading uninitialized data.
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Maarten Lankhorst
Cc: Daniel Vetter
Cc: Chris Wilson
Cc: dri-devel at lists.freedesktop.org
Sig
From: Nicolai Hähnle
Lock stealing is less beneficial for w/w mutexes since we may just end up
backing off if we stole from a thread with an earlier acquire stamp that
already holds another w/w mutex that we also need. So don't spin
optimistically unless we are sure that there is no other waiter
From: Nicolai Hähnle
The wait list is sorted by stamp order, and the only waiting task that may
have to back off is the first waiter with a context.
The regular slow path does not have to wake any other tasks at all, since
all other waiters that would have to back off were either woken up when
From: Nicolai Hähnle
While adding our task as a waiter, detect if another task should back off
because of us.
With this patch, we establish the invariant that the wait list contains
at most one (sleeping) waiter with ww_ctx->acquired > 0, and this waiter
will be the first waiter with a context.
From: Nicolai Hähnle
Add regular waiters in stamp order. Keep adding waiters that have no
context in FIFO order and take care not to starve them.
While adding our task as a waiter, back off if we detect that there is a
waiter with a lower stamp in front of us.
Make sure to call lock_contended
From: Nicolai Hähnle
We will add a new field to struct mutex_waiter. This field must be
initialized for all waiters if any waiter uses the ww_use_ctx path.
So there is a trade-off: Keep ww_mutex locking without a context on the
faster non-use_ww_ctx path, at the cost of adding the initializati
From: Nicolai Hähnle
The function will be re-used in subsequent patches.
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Maarten Lankhorst
Cc: Daniel Vetter
Cc: Chris Wilson
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Nicolai Hähnle
---
kernel/locking/mutex.c | 10 --
1 file ch
1 - 100 of 126 matches
Mail list logo