[Intel-gfx] [PATCH 2/2] drm/i915: Bump pin_count to UINT_MAX.
Chris Wilson
chris at chris-wilson.co.uk
Mon May 23 15:43:06 UTC 2016
On Mon, May 23, 2016 at 05:09:05PM +0200, Maarten Lankhorst wrote:
> Op 23-05-16 om 16:25 schreef Chris Wilson:
> > On Mon, May 23, 2016 at 03:37:41PM +0200, Maarten Lankhorst wrote:
> >> With nonblocking unpin there can be many cursor pins before they're
> >> cleared by the next page flip.
> >>
> >> Fix this by extending pin_count to the full 32-bit to prevent a
> >> WARN_ON(vma->pin_count == DRM_I915_GEM_OBJECT_MAX_PIN_COUNT)
> > This is a hack that affects non-KMS paths. Being able to process binding
> > in a single operation on all architectures is something we want to
> > preserve.
> >
> > Why is every cursor movement generating an unpin work? Should I just
> > start poking registers from userspace to avoid a silly kerenl?
> > -Chris
> >
> All the unpin work gets batched till after the next vblank, it's not very efficient
> but if you want to fix it you should just add the vma to plane state already.
I still don't see where the flush will occur, or why vblanks would be
running at all for cursor updates.
> According to Ville unpin count would still be too low on BXT/SKL, so it wouldn't
> remove the need for this patch anyway..
Increasing the count is one thing, taking all 32bits as a workaround for
poor behaviour in the cursor update is another.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
More information about the Intel-gfx
mailing list