Lines Matching refs:that

9 GPU's do operations that commonly involve many buffers.  Those buffers
16 there is no way to guarantee that buffers appear in a execbuf/batch in
18 userspace, and a result of the sequence of GL calls that an application
20 more complex when you consider that the kernel may need to migrate the
26 The algorithm that the TTM graphics subsystem came up with for dealing with
27 this problem is quite simple.  For each group of buffers (execbuf) that need
32 younger task) unlocks all of the buffers that it has already locked, and then
71     has a void return type. Note that since ww mutex code needs loops/retries
74   - When full debugging is enabled ww_mutex_lock_slow checks that all acquired
75     ww mutex have been released (preventing deadlocks) and makes sure that we
108 Method 1, using a list in execbuf->buffers that's not allowed to be reordered.
111 the caller as a signal that an object is twice on the list. This is useful if
157 Method 2, using a list in execbuf->buffers that can be reordered. Same semantics
216 - Due to the -EALREADY return code signalling that a given objects is already
221 Note that this approach differs in two important ways from the above methods:
226 - On the other hand the dynamic object list construction also means that the -EALREADY return
229 Note also that methods #1 and #2 and method #3 can be combined, e.g. to first lock a
239 variants, but that's outside of the scope of these examples here.
253 		/* need to do that before unlocking, since only the current lock holder is
274 			/* we have that one already, get to the next object */
299 Method 4: Only lock one single objects. In that case deadlock detection and
336    - Normal lockdep errors that can result in deadlocks.
338   Some of the lockdep errors that can result in deadlocks:
341    - 'normal' deadlocks that can occur.