On Mon, Aug 25, 2014 at 02:00:17AM +0200, Daniel Vetter wrote:
> On Sun, Aug 24, 2014 at 5:40 PM, Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> wrote:
> > On Fri, May 23, 2014 at 08:48:08AM +0200, Daniel Vetter wrote:
> >> - Apply the batch offset bias everywhere but mention that we've only
> >> observed it on gen7 gpus.
> >
> >> +static struct drm_i915_gem_object *
> >> +eb_get_batch(struct eb_vmas *eb)
> >> +{
> >> + struct i915_vma *vma = list_entry(eb->vmas.prev, typeof(*vma), exec_list);
> >> +
> >> + /*
> >> + * SNA is doing fancy tricks with compressing batch buffers, which leads
> >> + * to negative relocation deltas. Usually that works out ok since the
> >> + * relocate address is still positive, except when the batch is placed
> >> + * very low in the GTT. Ensure this doesn't happen.
> >> + *
> >> + * Note that actual hangs have only been observed on gen7, but for
> >> + * paranoia do it everywhere.
> >> + */
> >> + vma->exec_entry->flags |= __EXEC_OBJECT_NEEDS_BIAS;
> >
> > This actually conflicts with ilk and earlier generating EBUSY when mixed
> > with pinned buffers.
>
> Hm, now I'm confused since I seem to completely lack context. With
> what kind of pinned buffers does this conflict and how? Can you please
> elaborate?
A pinned buffer used as a batch in the low range. Depends on initial
framebuffer placement and availability of the api.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html