On Sun, 30 Oct 2011 18:20:54 -0700, Ben Widawsky <b...@bwidawsk.net> 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.
--
keith.pack...@intel.com
pgpxNQ836rpm0.pgp
Description: PGP signature
_______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
