On 19/03/2025 11:23, Christian König wrote:
+ *
+ * Return:
+ * 0 on success, or an error on failing to expand the array.
+ */
+int drm_sched_job_prealloc_dependency_slots(struct drm_sched_job
*job,
+ unsigned int num_deps)
+{
+ struct dma_fence *fence;
+ u32 id = 0;
+ int ret;
+
+ while (num_deps--) {
+ fence = dma_fence_get_stub();
+ ret = xa_alloc(&job->dependencies, &id, fence,
xa_limit_32b,
+ GFP_KERNEL);
So this would fill the xarr with already signaled fences which then
later will be replaced with unsignaled fences?
Yes, exactly that's the idea.
Help me out here: would it also work to add NULL instead of that stub-
fence?
Good question, idk. That's an implementation detail of the xarray.
Tvrtko also correctly pointed out that it is most likely a bad idea to
use dma_fence_is_signaled() in the critical code path.
I will try to dig through the xarray behavior up and update the patch if
possible.
I think NULL on its own is not possible, but the two low bits are
available for pointer tagging, or designating pointers vs integers,
which looks like it could work. Something like storing
xa_tag_pointer(NULL, 1) to reserved slots and at lookup time they would
be detected with "xa_pointer_tag(fence) & 1".
Regards,
Tvrtko
