An error occurred fetching the project authors.
- 13 May, 2016 1 commit
-
-
Chris Wilson authored
Following a GPU hang, we break out of the request loop in order to unlock the struct_mutex for use by the GPU reset. However, if we retire all the requests at that moment, we cannot identify the guilty request after performing the reset. v2: Not automatically retiring requests forces us to recheck for available ringspace. Fixes: f4457ae7 ("drm/i915: Prevent leaking of -EIO from i915_wait_request()") Testcase: igt/gem_reset_stats/ban-* Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Tested-by:
Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by:
-
- 11 May, 2016 2 commits
-
-
Tvrtko Ursulin authored
To be used for more efficient Gen range checking. v2: Remove spurious chunk. (Chris Wilson) v3: Rebase. v4: Renamed from INTEL_GEN_RANGE and added GEN_FOREVER. Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v3) Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Dave Gordon <david.s.gordon@intel.com> Reviewed-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1462874228-6601-1-git-send-email-tvrtko.ursulin@linux.intel.com
-
Tvrtko Ursulin authored
This way optimization from a previous patch works even better. v2: Rebase. Signed-off-by:
Jani Nikula <jani.nikula@intel.com>
-
- 09 May, 2016 1 commit
-
-
Chris Wilson authored
text data bss dec hex filename 6309351 3578714 696320 10584385 a18141 vmlinux 6308391 3578714 696320 10583425 a17d81 vmlinux Almost 1KiB of code reduction. v2: More s/INTEL_INFO()->gen/INTEL_GEN()/ and IS_GENx() conversions text data bss dec hex filename 6304579 3578778 696320 10579677 a16edd vmlinux 6303427 3578778 696320 10578525 a16a5d vmlinux Now over 1KiB! Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1462545621-30125-3-git-send-email-chris@chris-wilson.co.uk
-
- 03 May, 2016 1 commit
-
-
Imre Deak authored
No need for hard-coding the register value, the corresponding fields are defined properly in BSpec. No functional change. v2: - Rebased on BXT L3 SQC tuning patch merged meanwhile. CC: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v1) Link: http://patchwork.freedesktop.org/patch/msgid/1462280061-1457-3-git-send-email-imre.deak@intel.com
-
- 29 Apr, 2016 5 commits
-
-
Chris Wilson authored
When the engine idles waiting upon a semaphore, it loses its pagetables and we must reload them before executing the batch. v2: Restrict w/a to non-RCS rings (RCS works correctly apparently). Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1461932305-14637-5-git-send-email-chris@chris-wilson.co.uk
-
Chris Wilson authored
In order for the MI_SEMAPHORE_SIGNAL command to wait until after the pipecontrol writing the signal value is complete, we have to pause the CS inside the PIPE_CONTROL with the CS_STALL bit. Signed-off-by:
-
Chris Wilson authored
With the introduction of a distinct engine->id vs the hardware id, we need to fix up the value we use for selecting the target engine when signaling a semaphore. Note that these values can be merged with engine->guc_id. Fixes: de1add36Signed-off-by:
-
Chris Wilson authored
For legacy ringbuffer mode, we need the new ordered breadcrumb emission tried and tested on execlists in order to avoid the dreaded "missed interrupt" syndrome. A secondary advantage of the execlists method is that it writes to an arbitrary address, useful if one wants to write a breadcrumb elsewhere. This fix is taken from commit 7c17d377 (drm/i915: Use ordered seqno write interrupt generation on gen8+ execlists). Signed-off-by:
-
Chris Wilson authored
At the start of request emission, we flush some space for the request, estimating the typical size for the request body. The tail is now much larger than the typical body, so we can shrink the flush slightly. Signed-off-by:
-
- 28 Apr, 2016 7 commits
-
-
Chris Wilson authored
Rather than being interrupted when we run out of space halfway through the request, and having to restart from the beginning (and returning to userspace), flush a little more free space when we prepare the request. Signed-off-by:
-
Chris Wilson authored
In the next patches, we want to move the work out of freeing the request and into its retirement (so that we can free the request without requiring the struct_mutex). This means that we cannot rely on unreferencing the request to completely teardown the request any more and so we need to manually unwind the failed allocation. In doing so, we reorder the allocation in order to make the unwind simple (and ensure that we don't try to unwind a partial request that may have modified global state) and so we end up pushing the initial preallocation down into the engine request initialisation functions where we have the requisite control over the state of the request. Moving the initial preallocation into the engine is less than ideal: it moves logic to handle a specific problem with request handling out of the common code. On the other hand, it does allow those backends significantly more flexibility in performing its allocations. Signed-off-by:
-
Chris Wilson authored
Now that we share intel_ring_begin(), reserving space for the tail of the request is identical between legacy/execlists and so the tautology can be removed. In the process, we move the reserved space tracking from the ringbuffer on to the request. This is to enable us to reorder the reserved space allocation in the next patch. Signed-off-by:
-
Chris Wilson authored
Combine the near identical implementations of intel_logical_ring_begin() and intel_ring_begin() - the only difference is that the logical wait has to check for a matching ring (which is assumed by legacy). In the process some debug messages are culled as there were following a WARN if we hit an actual error. v2: Updated commentary Signed-off-by:
-
Chris Wilson authored
Similarly to i915_gem_object_pin_map on LLC platforms, we can use the new VMA based io mapping on !LLC to amoritize the cost of ringbuffer pinning and unpinning. Signed-off-by:
-
Chris Wilson authored
Propagate the real error from drm_gem_object_init(). Note this also fixes some confusion in the error return from i915_gem_alloc_object... v2: (Matthew Auld) - updated new users of gem_alloc_object from latest drm-nightly - replaced occurrences of IS_ERR_OR_NULL() with IS_ERR() v3: (Joonas Lahtinen) - fix double "From:" in commit message - add goto teardown path v4: (Matthew Auld) - rebase with i915_gem_alloc_object name change Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Signed-off-by:
-
Chris Wilson authored
Faced with sporadic machine hangs on gen7, that mimic the issue of concurrent writes to the same cacheline and seem to start with commit 9b9ed309 (drm/i915: Remove forcewake dance from seqno/irq barrier on legacy gen6+), let us restore the spinlock around the mmio read. Fixes: 9b9ed309 (drm/i915: Remove forcewake dance from seqno/irq...) Signed-off-by:
-
- 25 Apr, 2016 2 commits
-
-
Dave Gordon authored
Because having both i915_gem_object_alloc() and i915_gem_alloc_object() (with different return conventions) is just too confusing! (i915_gem_object_alloc() is the low-level memory allocator, and remains unchanged, whereas i915_gem_alloc_object() is a constructor that ALSO initialises the newly-allocated object.) Signed-off-by:
Dave Gordon <david.s.gordon@intel.com> Reviewed-by:
-
Tim Gore authored
This patch applies a performance enhancement workaround based on analysis of DX and OCL S-Curve workloads. We increase the General Priority Credits for L3SQ from the hardware default of 56 to the max value 62, and decrease the High Priority credits from 8 to 2. v2: Only apply to B0 onwards v3: Move w/a to per engine init, ie bxt_init_workarounds Signed-off-by:
Tim Gore <tim.gore@intel.com> Signed-off-by:
Michel Thierry <michel.thierry@intel.com>
-
- 20 Apr, 2016 3 commits
-
-
Dave Gordon authored
The newly-introduced function i915_gem_object_pin_map() returns an ERR_PTR (not NULL) if the pin-and-map opertaion fails, so that's what we must check for. And it's nicer not to assign such a pointer-or-error to a structure being filled in until after it's been validated, so we should keep it local and avoid exporting a bogus pointer. Also, for clarity and symmetry, we should clear 'virtual_start' along with 'vma' when unmapping a ringbuffer. Signed-off-by:
-
Tvrtko Ursulin authored
Just two WARN_ONs followed by pointer dereference I spotted by accident. v2: Remove some more of the same. Signed-off-by:
-
Tim Gore authored
WaEnableSamplerGPGPUPreemptionSupport fixes a problem related to mid thread pre-emption. Signed-off-by:
-
- 14 Apr, 2016 4 commits
-
-
Chris Wilson authored
For reasons unknown Sandybridge GT1 (at least) will eventually hang when it encounters a ring wraparound at offset 0. The test case that reproduces the bug reliably forces a large number of interrupted context switches, thereby causing very frequent ring wraparounds, but there are similar bug reports in the wild with the same symptoms, seqno writes stop just before the wrap and the ringbuffer at address 0. It is also timing crucial, but adding various delays hasn't helped pinpoint where the window lies. Whether the fault is restricted to the ringbuffer itself or the GTT addressing is unclear, but moving the ringbuffer fixes all the hangs I have been able to reproduce. References: (e.g.) https://bugs.freedesktop.org/show_bug.cgi?id=93262 Testcase: igt/gem_exec_whisper/render-contexts-interruptible #snb-gt1 Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1460565315-7748-12-git-send-email-chris@chris-wilson.co.uk
-
Chris Wilson authored
Reporting -EIO from i915_wait_request() has proven very troublematic over the years, with numerous hard-to-reproduce bugs cropping up in the corner case of where a reset occurs and the code wasn't expecting such an error. If the we reset the GPU or have detected a hang and wish to reset the GPU, the request is forcibly complete and the wait broken. Currently, we report either -EAGAIN or -EIO in order for the caller to retreat and restart the wait (if appropriate) after dropping and then reacquiring the struct_mutex (essential to allow the GPU reset to proceed). However, if we take the view that the request is complete (no further work will be done on it by the GPU because it is dead and soon to be reset), then we can proceed with the task at hand and then drop the struct_mutex allowing the reset to occur. This transfers the burden of checking whether it is safe to proceed to the caller, which in all but one instance it is safe - completely eliminating the source of all spurious -EIO. Of note, we only have two API entry points where we expect that userspace can observe an EIO. First is when submitting an execbuf, if the GPU is terminally wedged, then the operation cannot succeed and an -EIO is reported. Secondly, existing userspace uses the throttle ioctl to detect an already wedged GPU before starting using HW acceleration (or to confirm that the GPU is wedged after an error condition). So if the GPU is wedged when the user calls throttle, also report -EIO. v2: Split more carefully the change to i915_wait_request() and assorted ABI from the reset handling. v3: Add a couple of WARN_ON(EIO) to the interruptible modesetting code so that we don't start to leak EIO there in future (and break our hang resistant modesetting). Signed-off-by:
-
Chris Wilson authored
As the request is only valid during the same global reset epoch, we can record the current reset_counter when constructing the request and reuse it when waiting upon that request in future. This removes a very hairy atomic check serialised by the struct_mutex at the time of waiting and allows us to transfer those waits to a central dispatcher for all waiters and all requests. PS: With per-engine resets, we obviously cannot assume a global reset epoch for the requests - a per-engine epoch makes the most sense. The challenge then is how to handle checking in the waiter for when to break the wait, as the fine-grained reset may also want to requeue the request (i.e. the assumption that just because the epoch changes the request is completed may be broken - or we just avoid breaking that assumption with the fine-grained resets). Signed-off-by:
-
Chris Wilson authored
This is principally a little bit of syntatic sugar to hide the atomic_read()s throughout the code to retrieve the current reset_counter. It also provides the other utility functions to check the reset state on the already read reset_counter, so that (in later patches) we can read it once and do multiple tests rather than risk the value changing between tests. v2: Be more strict on converting existing i915_reset_in_progress() over to the more verbose i915_reset_in_progress_or_wedged(). Signed-off-by:
-
- 13 Apr, 2016 1 commit
-
-
Mika Kuoppala authored
Experiments with heaven 4.0 benchmark and skylake gt3e (rev 0xa) suggest that WaForceContextSaveRestoreNonCoherent is needed for all revs. Extending this to all revs cures a gpu hang with rev 0xa when running heaven4.0 gpu benchmark. We have been here before, with problems enabling gt4e and extending up to revision F0 instead of false claims of bspec of E0 only. See commit <e238659d> ("drm/i915/skl: Default to noncoherent access up to F0"). In retrospect we should have covered this with this big blanket back then already, as E0 vs F0 discrepancy was suspicious enough. Previously the WaForceEnableNonCoherent has been tied to context non-coherence, atleast in relevant hsds. So keep this tie and extended this alongside. Cc: Abdiel Janulgue <abdiel.janulgue@linux.intel.com> Cc: Ben Widawsky <benjamin.widawsky@intel.com> Cc: Timo Aaltonen <tjaalton@ubuntu.com> Cc: stable@vger.kernel.org Reported-by:
Mike Lothian <mike@fireburn.co.uk> References: https://bugs.freedesktop.org/show_bug.cgi?id=93491Signed-off-by:
Ben Widawsky <benjamin.widawsky@intel.com> Tested-by:
Timo Aaltonen <tjaalton@ubuntu.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459860977-27751-2-git-send-email-mika.kuoppala@intel.com
-
- 11 Apr, 2016 2 commits
-
-
Chris Wilson authored
We now have two implementations for vmapping a whole object, one for dma-buf and one for the ringbuffer. If we couple the mapping into the obj->pages lifetime, then we can reuse an obj->mapping for both and at the same time couple it into the shrinker. There is a third vmapping routine in the cmdparser that maps only a range within the object, for the time being that is left alone, but will eventually use these routines in order to cache the mapping between invocations. v2: Mark the failable kmalloc() as __GFP_NOWARN (vsyrjala) v3: Call unpin_vmap from the right dmabuf unmapper v4: Rename vmap to map as we don't wish to imply the type of mapping involved, just that it contiguously maps the object into kernel space. Add kerneldoc and lockdep annotations Signed-off-by:
-
Chris Wilson authored
After we pin the ringbuffer into the GGTT, all error paths need to unpin it again. Move this common step into one block, and make the unable to iomap error code consistent (i.e. treat it as out of memory to avoid confusing it with a invalid argument). Signed-off-by:
-
- 09 Apr, 2016 3 commits
-
-
Chris Wilson authored
In order to simplify future patches, extract the lazy_coherency optimisation our of the engine->get_seqno() vfunc into its own callback. v2: Rename the barrier to engine->irq_seqno_barrier to try and better reflect that the barrier is only required after the user interrupt before reading the seqno (to ensure that the seqno update lands in time as we do not have strict seqno-irq ordering on all platforms). Reviewed-by: Dave Gordon <david.s.gordon@intel.com> [#v2] v3: Comments for hangcheck paranoia. Mika wanted to keep the extra barrier inside the hangcheck, just in case. I can argue that it doesn't provide a barrier against anything, but the side-effects of applying the barrier may prevent a false declaration of a hung GPU. Signed-off-by:
-
Chris Wilson authored
In order to ensure seqno/irq coherency, we currently read a ring register. The mmio transaction following the interrupt delays the inspection of the seqno long enough for the MI_STORE_DWORD_IMM to update the CPU cache. However, it is only the memory timing that is important for the purposes of the delay, we do not need nor desire the extra forcewake. v3: Update commentary Signed-off-by:
-
Akash Goel authored
Currently for the case where there is enough space at the end of Ring buffer for accommodating only the base request, the wrapround is done immediately and as a result the base request gets added at the start of Ring buffer. But there may not be enough free space at the beginning to accommodate the base request, as before the wraparound, the wait was effectively done for the reserved_size free space from the start of Ring buffer. In such a case there is a potential of Ring buffer overflow, the instructions at the head of Ring (ACTHD) can get overwritten. Since the base request can fit in the remaining space, there is no need to wraparound immediately. The wraparound will anyway happen later when the reserved part starts getting used. Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Akash Goel <akash.goel@intel.com> Signed-off-by:
-
- 08 Apr, 2016 4 commits
-
-
Chris Wilson authored
When we change the current seqno, we also need to remember to reset the last_submitted_seqno for the engine. Testcase: igt/gem_exec_whisper Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by:
-
Chris Wilson authored
An oversight is that when we wrap the seqno, we need to reset the hw semaphore counters to 0. We did this for gen6 and gen7 and forgot to do so for the new implementation required for gen8 (legacy). Signed-off-by:
-
Chris Wilson authored
Since we are setting engine local values that are tied to the hardware, move it out of i915_gem_init_seqno() into the intel_ring_init_seqno() backend, next to where the other hw semaphore registers are written. v2: Make the explanatory comment about always resetting the semaphores to 0 irrespective of the value of the reset seqno. Signed-off-by:
-
Chris Wilson authored
We only use drm_i915_private within the function, so delete the unneeded drm_device local. Signed-off-by:
-
- 31 Mar, 2016 1 commit
-
-
Joonas Lahtinen authored
Refer to the GGTT VM consistently as "ggtt->base" instead of just "ggtt", "vm" or indirectly through other variables like "dev_priv->ggtt.base" to avoid confusion with the i915_ggtt object itself and PPGTT VMs. Refer to the GGTT as "ggtt" instead of indirectly through chaining. As a bonus gets rid of the long-standing i915_obj_to_ggtt vs. i915_gem_obj_to_ggtt conflict, due to removal of i915_obj_to_ggtt! v2: - Added some more after grepping sources with Chris v3: - Refer to GGTT VM through ggtt->base consistently instead of ggtt_vm (Chris) v4: - Convert all dev_priv->ggtt->foo accesses to ggtt->foo. v5: - Make patch checker happy Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
- 24 Mar, 2016 1 commit
-
-
Dave Gordon authored
Equivalent to the existing for_each_engine() macro, this will replace the latter wherever the third argument *is* actually wanted (in most places, it is not used). The third argument is renamed to emphasise that it is an engine id (type enum intel_engine_id). All the callers of the macro that actually need the third argument are updated to use this version, and the argument (generally 'i') is also updated to be 'id'. Other callers (where the third argument is unused) are untouched for now; they will be updated in the next patch. Signed-off-by:
-
- 22 Mar, 2016 1 commit
-
-
Tomas Elf authored
Initialize hangcheck struct during driver load. Since we do the same after recovering from a reset, this is extracted into a helper function. v2: remove redundant hangcheck init during load as this is done when engines are initialized (Chris) Cc: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by:
Tomas Elf <tomas.elf@intel.com> Signed-off-by:
Arun Siluvery <arun.siluvery@linux.intel.com> Reviewed-by:
-
- 18 Mar, 2016 1 commit
-
-
Joonas Lahtinen authored
Refer to Global GTT consistently as GGTT, thus rename dev_priv->gtt to dev_priv->ggtt and struct i915_gtt to struct i915_ggtt. Fix a couple of whitespace problems while at it. v2: - Fix a typo in commit message. Reviewed-by:
-
