On Sun, 30 Oct 2011 18:36:23 -0700 Keith Packard <[email protected]> wrote:
> On Sun, 30 Oct 2011 18:20:54 -0700, Ben Widawsky <[email protected]> wrote: > > > > The solution here is to add a new flag to the call chain which gives the > > routines the information they need to possibly defer actions which may > > cause us to recurse. > > This looks a lot nicer; it's shorter than I feared too. > > > @@ -2051,7 +2052,8 @@ i915_gem_object_wait_rendering(struct > > drm_i915_gem_object *obj) > > * it. > > */ > > if (obj->active) { > > - ret = i915_wait_request(obj->ring, obj->last_rendering_seqno); > > + ret = i915_wait_request(obj->ring, obj->last_rendering_seqno, > > + true); > > > @@ -2400,7 +2402,8 @@ i915_gem_object_flush_fence(struct > > drm_i915_gem_object *obj, > > if (!ring_passed_seqno(obj->last_fenced_ring, > > obj->last_fenced_seqno)) { > > ret = i915_wait_request(obj->last_fenced_ring, > > - obj->last_fenced_seqno); > > + obj->last_fenced_seqno, > > + true); > > if (ret) > > return ret; > > } > > @@ -2541,7 +2544,8 @@ i915_gem_object_get_fence(struct drm_i915_gem_object > > *obj, > > if (!ring_passed_seqno(obj->last_fenced_ring, > > reg->setup_seqno)) { > > ret = > > i915_wait_request(obj->last_fenced_ring, > > - > > reg->setup_seqno); > > + > > reg->setup_seqno, > > + true); > > if (ret) > > return ret; > > } > > Any reason you're changing behaviour outside of the area with the actual > problem? If so, you should stick those in a separate patch instead of > mixing them into this bug fix. > Well, I had to pick one, and looking at the call chain, it seemed there wasn't much to gain by doing retiring at this point. If you want to take the patch, and modify those vales to false - I'm okay with it. Ben _______________________________________________ Intel-gfx mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/intel-gfx
