On 5/4/23 13:51, Christian König wrote:
This adds the infrastructure for an execution context for GEM buffers
which is similar to the existing TTMs execbuf util and intended to replace
it in the long term.
The basic functionality is that we abstracts the necessary loop to lock
many different GEM buffers with automated deadlock and duplicate handling.
v2: drop xarray and use dynamic resized array instead, the locking
overhead is unecessary and measurable.
v3: drop duplicate tracking, radeon is really the only one needing that.
v4: fixes issues pointed out by Danilo, some typos in comments and a
helper for lock arrays of GEM objects.
Signed-off-by: Christian König <christian.koenig@xxxxxxx>
...
+/**
+ * struct drm_exec - Execution context
+ */
+struct drm_exec {
+ /**
+ * @interruptible: If locks should be taken interruptible
+ */
+ bool interruptible;
+
+ /**
+ * @ticket: WW ticket used for acquiring locks
+ */
+ struct ww_acquire_ctx ticket;
+
+ /**
+ * @num_objects: number of objects locked
+ */
+ unsigned int num_objects;
+
+ /**
+ * @max_objects: maximum objects in array
+ */
+ unsigned int max_objects;
+
+ /**
+ * @objects: array of the locked objects
+ */
+ struct drm_gem_object **objects;
Hi, Christian. Did you consider using a list here with links embedded in
gem objects, now that only locked objects are to be put on the list / array.
That should work as only the process owning the lock may access the list
link. Apart from getting rid of reallocing this is beneficial for the
more general types of ww transactions that are used by i915 (and to a
minor extent xe as well, I think).
In those cases we would want to unlock a temporary held object within
the while_not_all_locked() loop and would then have to search the entire
array for the correct pointer. Instead one could just remove it from the
list of locked objects.
Thanks,
Thomas
