Quoting Matthew Auld (2019-02-19 10:22:57)
> On Wed, 6 Feb 2019 at 13:05, Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> wrote:
> > +static struct i915_request *dummy_request(struct intel_engine_cs *engine)
> > +{
> > + struct i915_request *rq;
> > +
> > + rq = kmalloc(sizeof(*rq), GFP_KERNEL | __GFP_ZERO);
> > + if (!rq)
> > + return NULL;
> > +
> > + INIT_LIST_HEAD(&rq->active_list);
> > + rq->engine = engine;
> > +
> > + i915_sched_node_init(&rq->sched);
> > +
> > + /* mark this request as permanently incomplete */
> > + rq->fence.seqno = 1;
> > + BUILD_BUG_ON(sizeof(rq->fence.seqno) != 8); /* upper 32b == 0 */
> > + rq->hwsp_seqno = (u32 *)&rq->fence.seqno + 1;
> > + GEM_BUG_ON(i915_request_completed(rq));
> > +
> > + i915_sw_fence_init(&rq->submit, dummy_notify);
> > + i915_sw_fence_commit(&rq->submit);
> > +
> > + return rq;
> > +}
> > +
> > +static void dummy_request_free(struct i915_request *dummy)
> > +{
> > + i915_request_mark_complete(dummy);
> > + i915_sched_node_fini(dummy->engine->i915, &dummy->sched);
>
> Do we need i915_sw_fence_fini() in here somewhere?
>
> While looking at something unrelated I hit something like:
> ODEBUG: init destroyed (active state 0) object type: i915_sw_fence
> hint: (null)
Yeah, a missing fw_fence_fini would account for that. We should also use
dma_fence_release if I haven't already, just in case it ends up being
RCU sensitive.
As for requiring dummy_request in the first place, I think it indicates
that the i915_request_add() api is inadequate. At the moment, the only
sore points are this particular test and later on when we have to
manually fudge the priority after submission (for heartbeat requests).
So, it's not a pressing issue, but definitely a weak point.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
