- 09 Sep, 2016 20 commits
-
-
Chris Wilson authored
Now that we have fences in place to drive request submission, we can employ those to queue requests after their dependencies as opposed to stalling in the middle of an execbuf ioctl. (However, we still choose to spin before enabling the IRQ as that is faster - though contentious.) v2: Do the fence ordering first, where we can still fail. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20160909131201.16673-20-chris@chris-wilson.co.uk
-
Chris Wilson authored
If we are waiting upon an external fence, from the pov of hangcheck the engine is stuck on the last submitted seqno. Currently we give a small increment to the hangcheck score in order to catch a stuck waiter / driver. Now that we both have an independent wait hangcheck and may be stuck waiting on an external fence, resetting the GPU has little effect on that external fence. As we cannot advance by resetting, skip incrementing the hangcheck score. Signed-off-by:
Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20160909131201.16673-19-chris@chris-wilson.co.uk
-
Chris Wilson authored
If we find a ring waiting on a semaphore for another assigned but not yet emitted request, treat it as valid and waiting. Signed-off-by:
-
Chris Wilson authored
Currently the presumption is that the request construction and its submission to the GuC are all under the same holding of struct_mutex. We wish to relax this to separate the request construction and the later submission to the GuC. This requires us to reserve some space in the GuC command queue for the future submission. For flexibility to handle out-of-order request submission we do not preallocate the next slot in the GuC command queue during request construction, just ensuring that there is enough space later. Signed-off-by:
-
Chris Wilson authored
We are about to specialize object synchronisation to enable nonblocking execbuf submission. First we make a copy of the current object synchronisation for execbuffer. The general i915_gem_object_sync() will be removed following the removal of CS flips in the near future. Signed-off-by:
John Harrison <john.c.harrison@intel.com> Reviewed-by:
-
Chris Wilson authored
Let's avoid mixing sealing the hardware commands for the request and adding the request to the software tracking. Signed-off-by:
-
Chris Wilson authored
Drive final request submission from a callback from the fence. This way the request is queued until all dependencies are resolved, at which point it is handed to the backend for queueing to hardware. At this point, no dependencies are set on the request, so the callback is immediate. A side-effect of imposing a heavier-irqsafe spinlock for execlist submission is that we lose the softirq enabling after scheduling the execlists tasklet. To compensate, we manually kickstart the softirq by disabling and enabling the bh around the fence signaling. Signed-off-by:
-
Chris Wilson authored
Update reset path in preparation for engine reset which requires identification of incomplete requests and associated context and fixing their state so that engine can resume correctly after reset. The request that caused the hang will be skipped and head is reset to the start of breadcrumb. This allows us to resume from where we left-off. Since this request didn't complete normally we also need to cleanup elsp queue manually. This is vital if we employ nonblocking request submission where we may have a web of dependencies upon the hung request and so advancing the seqno manually is no longer trivial. ABI: gem_reset_stats / DRM_IOCTL_I915_GET_RESET_STATS We change the way we count pending batches. Only the active context involved in the reset is marked as either innocent or guilty, and not mark the entire world as pending. By inspection this only affects igt/gem_reset_stats (which assumes implementation details) and not piglit. ARB_robustness gives this guide on how we expect the user of this interface to behave: * Provide a mechanism for an OpenGL application to learn about graphics resets that affect the context. When a graphics reset occurs, the OpenGL context becomes unusable and the application must create a new context to continue operation. Detecting a graphics reset happens through an inexpensive query. And with regards to the actual meaning of the reset values: Certain events can result in a reset of the GL context. Such a reset causes all context state to be lost. Recovery from such events requires recreation of all objects in the affected context. The current status of the graphics reset state is returned by enum GetGraphicsResetStatusARB(); The symbolic constant returned indicates if the GL context has been in a reset state at any point since the last call to GetGraphicsResetStatusARB. NO_ERROR indicates that the GL context has not been in a reset state since the last call. GUILTY_CONTEXT_RESET_ARB indicates that a reset has been detected that is attributable to the current GL context. INNOCENT_CONTEXT_RESET_ARB indicates a reset has been detected that is not attributable to the current GL context. UNKNOWN_CONTEXT_RESET_ARB indicates a detected graphics reset whose cause is unknown. The language here is explicit in that we must mark up the guilty batch, but is loose enough for us to relax the innocent (i.e. pending) accounting as only the active batches are involved with the reset. In the future, we are looking towards single engine resetting (with minimal locking), where it seems inappropriate to mark the entire world as innocent since the reset occurred on a different engine. Reducing the information available means we only have to encounter the pain once, and also reduces the information leaking from one context to another. v2: Legacy ringbuffer submission required a reset following hibernation, or else we restore stale values to the RING_HEAD and walked over stolen garbage. v3: GuC requires replaying the requests after a reset. v4: Restore engine IRQ after reset (so waiters will be woken!) Rearm hangcheck if resetting with a waiter. Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Arun Siluvery <arun.siluvery@linux.intel.com> Signed-off-by: -
Chris Wilson authored
Since we have a cooperative mode now with a direct reset, we can avoid the contention on struct_mutex and instead try then sleep on the I915_RESET_IN_PROGRESS bit. If the mutex is held and that bit is cleared, all is fine. Otherwise, we sleep for a bit and try again. In the worst case we sleep for an extra second waiting for the mutex to be released (no one touching the GPU is allowed the struct_mutex whilst the I915_RESET_IN_PROGRESS bit is set). But when we have a direct reset, this allows us to clean up the reset worker faster. v2: Remember to call wake_up_bit() after changing (for the faster wakeup as promised) Signed-off-by:
-
Chris Wilson authored
If a waiter is holding the struct_mutex, then the reset worker cannot reset the GPU until the waiter returns. We do not want to return -EAGAIN form i915_wait_request as that breaks delicate operations like i915_vma_unbind() which often cannot be restarted easily, and returning -EIO is just as useless (and has in the past proven dangerous). The remaining WARN_ON(i915_wait_request) serve as a valuable reminder that handling errors from an indefinite wait are tricky. We can keep the current semantic that knowing after a reset is complete, so is the request, by performing the reset ourselves if we hold the mutex. uevent emission is still handled by the reset worker, so it may appear slightly out of order with respect to the actual reset (and concurrent use of the device). Signed-off-by:
-
Chris Wilson authored
In the next patch we want to handle reset directly by a locked waiter in order to avoid issues with returning before the reset is handled. To handle the reset, we must first know whether we hold the struct_mutex. If we do not hold the struct_mtuex we can not perform the reset, but we do not block the reset worker either (and so we can just continue to wait for request completion) - otherwise we must relinquish the mutex. Signed-off-by:
-
Chris Wilson authored
We need finer control over wakeup behaviour during i915_wait_request(), so expand the current bool interruptible to a bitmask. Signed-off-by:
-
Chris Wilson authored
Access to intel_init_emon() is strictly ordered by gt_powersave, using struct_mutex around it is overkill (and will conflict with the caller holding struct_mutex themselves). Signed-off-by:
-
Chris Wilson authored
In preparation for introducing a per-engine reset, we can first separate the mixing of the reset state from the global reset counter. The loss of atomicity in updating the reset state poses a small problem for handling the waiters. For requests, this is solved by advancing the seqno so that a waiter waking up after the reset knows the request is complete. For pending flips, we still rely on the increment of the global reset epoch (as well as the reset-in-progress flag) to signify when the hardware was reset. The advantage, now that we do not inspect the reset state during reset itself i.e. we no longer emit requests during reset, is that we can use the atomic updates of the state flags to ensure that only one reset worker is active. v2: Mika spotted that I transformed the i915_gem_wait_for_error() wakeup into a waiter wakeup. Signed-off-by:
-
Chris Wilson authored
Emulate HW to track and manage ELSP queue. A set of SW ports are defined and requests are assigned to these ports before submitting them to HW. This helps in cleaning up incomplete requests during reset recovery easier especially after engine reset by decoupling elsp queue management. This will become more clear in the next patch. In the engine reset case we want to resume where we left-off after skipping the incomplete batch which requires checking the elsp queue, removing element and fixing elsp_submitted counts in some cases. Instead of directly manipulating the elsp queue from reset path we can examine these ports, fix up ringbuffer pointers using the incomplete request and restart submissions again after reset. Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Arun Siluvery <arun.siluvery@linux.intel.com> Signed-off-by:
-
Chris Wilson authored
Just rearrange the code to reduce churn in the next patch. Signed-off-by:
-
Chris Wilson authored
Similar to the issue with reading from the context status buffer, see commit 26720ab9 ("drm/i915: Move CSB MMIO reads out of the execlists lock"), we frequently write to the ELSP register (4 writes per interrupt) and know we hold the required spinlock and forcewake throughout. We can further reduce the cost of writing these registers beyond the I915_WRITE_FW() by precomputing the address of the ELSP register. We also note that the subsequent read serves no purpose here, and are happy to see it go. v2: Address I915_WRITE mistakes in changelog text data bss dec hex filename 1259784 4581 576 1264941 134d2d drivers/gpu/drm/i915/i915.ko 1259720 4581 576 1264877 134ced drivers/gpu/drm/i915/i915.ko Saves 64 bytes of address recomputation. Signed-off-by:
-
Chris Wilson authored
Rather than blindly assuming we need to advance the tail for resubmitting the request via the ELSP, record the position. Signed-off-by:
-
Chris Wilson authored
Leave the more complicated request dequeueing to the tasklet and instead just kick start the tasklet if we detect we are adding the first request. v2: Play around with list operators until we agree upon something Signed-off-by:
-
Chris Wilson authored
This is really a core kernel struct in disguise until we can finally place it in kernel/. There is an immediate need for a fence collection mechanism that is more flexible than fence-array, in particular being able to easily drive request submission via events (and not just interrupt driven). The same mechanism would be useful for handling nonblocking and asynchronous atomic modesets, parallel execution and more, but for the time being just create a local sw fence for execbuf. Signed-off-by:
-
- 07 Sep, 2016 20 commits
-
-
Carlos Santa authored
Moving all GPU features to the platform definition allows for - standard place when adding new features from new platform - possible to see supported features when dumping struct definitions Signed-off-by:Carlos Santa <carlos.santa@intel.com> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Carlos Santa authored
Make the .hws_needs_physical the exception by switching the flag on earlier platforms since they are fewer to support. Remove the flag on later GPUs hardware since they all use GTT hws by default. Switch the logic as well in the driver to reflect this change Signed-off-by:
-
Carlos Santa authored
Moving all GPU features to the platform definition allows for - standard place when adding new features from new platforms - possible to see supported features when dumping struct definitions Signed-off-by: -
Carlos Santa authored
Moving all GPU features to the platform definition allows for - standard place when adding new features from new platforms - possible to see supported features when dumping struct definitions Signed-off-by: -
Carlos Santa authored
Moving all GPU features to the platform definition allows for - standard place when adding new features from new platforms - possible to see supported features when dumping struct definitions Signed-off-by: -
Carlos Santa authored
Moving all GPU features to the platform definition allows for - standard place when adding new features from new platforms - possible to see supported features when dumping struct definitions Signed-off-by:
-
Carlos Santa authored
Introducing a GEN2_FEATURES macro to simplify the struct definitions by platforms given that most of the features are common. Inspired by the GEN7_FEATURES macro done by Ben W. and others. Use it for 830, 845g, i85x, i865g. CC: Ben Widawsky <ben@bwidawsk.net> Signed-off-by:
-
Carlos Santa authored
Introducing a GEN3_FEATURES macro to simplify the struct definitions by platforms given that most of the features are common. Inspired by the GEN7_FEATURES macro done by Ben W. and others. Use it for i915g, i915gm, i945g, i945gm, g33 and pnv. CC: Ben Widawsky <ben@bwidawsk.net> Signed-off-by:
-
Carlos Santa authored
Introducing a GEN4_FEATURES macro to simplify the struct definitions by platforms given that most of the features are common. Inspired by the GEN7_FEATURES macro done by Ben W. and others. Use it for i965g, i965gm, g45 and gm45. CC: Ben Widawsky <ben@bwidawsk.net> Signed-off-by:
-
Carlos Santa authored
Moving all GPU features to the platform struct definition allows for - standard place when adding new features from new platforms - possible to see supported features when dumping struct definitions Signed-off-by:
-
Carlos Santa authored
Introducing a GEN5_FEATURES macro to simplify the struct definitions by platforms given that most of the features are common. Inspired by the GEN7_FEATURES macro done by Ben W. and others. Use it for ilk. CC: Ben Widawsky <ben@bwidawsk.net> Signed-off-by:
-
Carlos Santa authored
Moving all GPU features to the platform struct definition allows for - standard place when adding new features from new platforms - possible to see supported features when dumping struct definitions Signed-off-by:
-
Carlos Santa authored
Moving all GPU features to the platform struct definition allows for - standard place when adding new features from new platforms - possible to see supported features when dumping struct definitions Signed-off-by:
-
Carlos Santa authored
Moving all GPU features to the platform struct definition allows for - standard place when adding new features from new platforms - possible to see supported features when dumping struct definitions Signed-off-by:
-
Carlos Santa authored
Moving all GPU features to the platform struct definition allows for - standard place when adding new features from new platforms - possible to see supported features when dumping struct definitions Signed-off-by:
-
Carlos Santa authored
Moving all GPU features to the platform struct definition allows for - standard place when adding new features from new platforms - possible to see supported features when dumping struct definitions Signed-off-by: -
Carlos Santa authored
No need for HAS_CORE_RING_FREQ as that flag is actually the same as .has_llc. Feedback from V. Syrjala. Signed-off-by:
-
Carlos Santa authored
Remove runtime PM support for SNB as it breaks hotplug support. Feedback from V. Syrjala. Signed-off-by:
-
Carlos Santa authored
Moving all GPU features to the platform struct definition allows for - standard place when adding new features from new platforms - possible to see supported features when dumping struct definitions Signed-off-by:
-
Carlos Santa authored
Introducing a GEN6_FEAUTRES macro to simplify the struct definitions by platforms given that most of the features are common. Inspired by the GEN7_FEATURES macro done by Ben W. and others. Use it for snb. CC: Ben Widawsky <ben@bwidawsk.net> Signed-off-by:
-
