On Sat, Jun 04, 2011 at 09:55:43AM +0100, Chris Wilson wrote:
> + ret = pin_and_fence_object(obj, ring);
> + if (ret) {
> + int ret_ignore;
> +
> + /* This can potentially raise a harmless
> + * -EINVAL if we failed to bind in the above
> + * call. It cannot raise -EINTR since we know
> + * that the bo is freshly bound and so will
> + * not need to be flushed or waited upon.
> + */
> + ret_ignore = i915_gem_object_unbind(obj);
> + (void)ret_ignore;
> + WARN_ON(obj->gtt_space);
> + break;
> }
Chris clarified my confusion about this piece of the patch on irc: It's
required to ensure the "valid gtt_space implies that execbuffer_reserve
holds a pin count ref on this object" invariant, which is used later on in
the unwind loop. I think this should be mentioned in the comment. [The
confusion mostly stemmed from the second (slightly different) unwind loop
which is used in an earlier error path.]
I couldn't poke any other holes into this (and I don't have clear ideas
for straightening out the code-flow in execbuffer_reserve) so:
Reviewed-by: Daniel Vetter <[email protected]>
--
Daniel Vetter
Mail: [email protected]
Mobile: +41 (0)79 365 57 48
_______________________________________________
Intel-gfx mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
