Op 23-05-16 om 17:43 schreef Chris Wilson: > 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. Next page flip. All cursor updates are added to flip_work list and are cleared on vblank. >> 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 > _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
