Hi Tvrtko,
On 06/04/26 12:09, Tvrtko Ursulin wrote:
[...]
+
static void
vc4_job_free(struct kref *ref)
{
@@ -260,6 +311,10 @@ vc4_render_job_free(struct kref *ref)
vc4->bin_alloc_used &= ~job->bin_slots;
spin_unlock_irqrestore(&vc4->job_lock, irqflags);
+ if (job->seqno)
+ xa_erase(&job->file->seqno_xa, job->seqno);
+
+ vc4_file_put(job->file);
vc4_job_free(ref);
}
@@ -428,6 +483,7 @@ vc4_submit_cl_ioctl(struct drm_device *dev, void
*data,
return ret;
exec.render = render;
+ render->file = vc4_file_get(vc4_priv);
INIT_LIST_HEAD(&render->unref_list);
ret = vc4_lookup_bos(dev, file_priv, render, args->bo_handles,
@@ -483,10 +539,20 @@ vc4_submit_cl_ioctl(struct drm_device *dev, void
*data,
vc4_push_job(&render->base);
mutex_unlock(&vc4->sched_lock);
+ ret = xa_alloc_cyclic(&vc4_priv->seqno_xa, &render->seqno,
+ render->base.done_fence,
+ xa_limit_32b, &vc4_priv->next_seqno, GFP_KERNEL);
+ if (ret < 0) {
+ /* Jobs are already queued, just skip seqno tracking. */
Why it is not better to allocate the seqno earlier and avoid the problem
of false positive waits?
Actually, right after sending this series to the mailing list, I had an
idea to solve this issue and I sent a patch implementing it for Etnaviv
[1]. I plan to do the same for vc4 in v3.
Thanks for your review!
[1]
https://lore.kernel.org/dri-devel/[email protected]/T/
Best regards,
- Maíra
Regards,
Tvrtko
+ render->seqno = 0;
+ }
vc4_attach_fences(file_priv, render, args->out_sync, render-
>base.done_fence);
drm_exec_fini(&exec_ctx);
+ /* Return the seqno for our job. */
+ args->seqno = render->seqno;
+
vc4_job_put((void *)bin);
vc4_job_put((void *)render);
