Quoting Tvrtko Ursulin (2019-03-01 11:38:11) > > On 01/03/2019 11:05, Chris Wilson wrote: > > diff --git a/drivers/gpu/drm/i915/selftests/mock_timeline.c b/drivers/gpu/drm/i915/selftests/mock_timeline.c > > index d2de9ece2118..416d85233263 100644 > > --- a/drivers/gpu/drm/i915/selftests/mock_timeline.c > > +++ b/drivers/gpu/drm/i915/selftests/mock_timeline.c > > @@ -14,6 +14,7 @@ void mock_timeline_init(struct i915_timeline *timeline, u64 context) > > timeline->fence_context = context; > > > > spin_lock_init(&timeline->lock); > > + mutex_init(&timeline->mutex); > > > > INIT_ACTIVE_REQUEST(&timeline->barrier); > > INIT_ACTIVE_REQUEST(&timeline->last_request); > > > > So hard to predict if this will be okay in the future and keep a mental > image of the endgame in ones head. Yeah, it'll change anyway as soon as we meet the enemy. At the moment, it seems a fundamental mutex that we can't avoid, the timeline must be serialised (for access to the ring and seqno, request construct must be sequential) and from there we extend it to cover retirement and activity tracking. It may be that we can split the mutex further (allow for parallel construction and retirement? but that seems an unlikely win since timeline == client and so we expect to parcel work up into timeline/client bundles), but for now timeline->mutex seems like a solid plan of action. (At least it gets us as far as allowing clients to submit requests independently, after that my crystal ball is cloudy.) -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
