This series is still under development, getting the coordination right for async vma (having just make i915_vma refcounted, I need to actually prevent the refcycles and fixup good old userspace in ggtt, vma->open_count for everyone incl. gem_vm_ops). [PATCH 01/39] drm/i915: Discard some redundant cache domain flushes [PATCH 02/39] drm/i915: Refine i915_reset.lock_map [PATCH 03/39] drm/i915: Avoid tainting i915_gem_park() with [PATCH 04/39] drm/i915: Enable refcount debugging for default debug Endless/qos patches: [PATCH 05/39] drm/i915: Keep contexts pinned until after the next [PATCH 06/39] drm/i915: Stop retiring along engine [PATCH 07/39] drm/i915: Replace engine->timeline with a plain list [PATCH 08/39] drm/i915: Flush the execution-callbacks on retiring [PATCH 09/39] drm/i915/execlists: Preempt-to-busy [PATCH 10/39] drm/i915/execlists: Minimalistic timeslicing [PATCH 11/39] drm/i915/execlists: Force preemption Remove struct_mutex from i915_actve: [PATCH 12/39] dma-fence: Propagate errors to dma-fence-array [PATCH 13/39] dma-fence: Report the composite sync_file status [PATCH 14/39] dma-fence: Refactor signaling for manual invocation [PATCH 15/39] dma-fence: Always execute signal callbacks [PATCH 16/39] drm/i915: Execute signal callbacks from no-op [PATCH 17/39] drm/i915: Make the semaphore saturation mask global [PATCH 18/39] drm/i915: Throw away the active object retirement [PATCH 19/39] drm/i915: Provide an i915_active.acquire callback [PATCH 20/39] drm/i915: Push the i915_active.retire into a worker [PATCH 21/39] drm/i915/overlay: Switch to using i915_active tracking [PATCH 22/39] drm/i915: Forgo last_fence active request tracking [PATCH 23/39] drm/i915: Extract intel_frontbuffer active tracking [PATCH 24/39] drm/i915: Coordinate i915_active with its own mutex Up to this point, we should be solid; and removing struct_mutex around i915_active is a major milestone as it was one of the two remaining requirements for holding struct_mutex across request construction. In principle, now you just need the timeline mutex, which is taken and pinned by i915_request_create. (The remaining problem is making retirement only require the timeline mutex as well.) Remove struct_mutex from i915_address_space: [PATCH 25/39] drm/i915: Track ggtt fence reservations under its own [PATCH 26/39] drm/i915: Only track bound elements of the GTT [PATCH 27/39] drm/i915: Explicitly cleanup initial_plane_config [PATCH 28/39] initial-plane-vma [PATCH 29/39] drm/i915: Make i915_vma track its own kref [PATCH 30/39] drm/i915: Propagate fence errors [PATCH 31/39] drm/i915: Allow page pinning to be in the background [PATCH 32/39] drm/i915: Allow vma binding to occur asynchronously [PATCH 33/39] revoke-fence [PATCH 34/39] drm/i915: Use vm->mutex for serialising GTT insertion This is quite close. Major refleak in i915_vma aka finishing touches in converting it to be refcounted, and I need to take a pass over the async vma to force the worker even for ggtt if we need to allocate pages (e.g. rotation, remap, partial). At this point, we drop the struct_mutex pretty much everywhere internally. And should be free to start doing interesting things from within obj->mm workers. async get_pages: [PATCH 35/39] drm/i915: Pin pages before waiting [PATCH 36/39] drm/i915: Use reservation_object to coordinate userptr One such example. Broken across rebases and needs fixing up: async get-pages. Remove struct_mutex for i915_requests: [PATCH 37/39] drm/i915: Use forced preemptions in preference over [PATCH 38/39] drm/i915: Remove logical HW ID [PATCH 39/39] active-rings And to complete the picture to remove struct_mutex around i915_request, we need to be able to retire under the timeline alone. With that inplace, we can drop struct_mutex. This presumptiously removes it from GEM_EXECBUFFER_IOCTL, but that's a little bit premature as there are still auxiliaries that need their own locks but is the ultimate proof. Please look over and flag any more issues you can spot. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
