On Wed, Jul 19, 2017 at 02:04:25PM +0100, Chris Wilson wrote: > Quoting Daniel Vetter (2017-07-19 13:54:57) > > Blocking in a worker is ok, > > but needlessly inefficient, > > > that's what the unbound_wq is for. And it > > unifies the paths between the blocking and nonblocking commit, giving > > me just one path where I have to implement the deadlock avoidance > > trickery in the next patch. > > For reference, I did that the other way by moving it all over to fences. Yeah the commit message fails to explain this here: "I first tried to implement the following patch without this rework, but force-completing i915_sw_fence creates some serious challenges around properly cleaning things up. So wasn't a feasible short-term approach. Another approach would be to simple keep track of all pending atomic commit work items and manually queue them from the reset code. With the caveat that double-queue in case we race with the i915_sw_fence must be avoided. Given all that, taking the cost of a double schedule in atomic for the short-term fix is the best approach, but can be changed in the future of course." Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
