1. 09 7月, 2021 4 次提交
  2. 08 7月, 2021 2 次提交
  3. 07 7月, 2021 2 次提交
  4. 06 7月, 2021 1 次提交
  5. 03 7月, 2021 2 次提交
  6. 30 6月, 2021 7 次提交
  7. 25 6月, 2021 5 次提交
  8. 24 6月, 2021 1 次提交
  9. 21 6月, 2021 2 次提交
    • D
      drm/i915/eb: Fix pagefault disabling in the first slowpath · ca319ee9
      Daniel Vetter 提交于
      In
      
      commit ebc0808f
      Author: Chris Wilson <chris@chris-wilson.co.uk>
      Date:   Tue Oct 18 13:02:51 2016 +0100
      
          drm/i915: Restrict pagefault disabling to just around copy_from_user()
      
      we entirely missed that there's a slow path call to eb_relocate_entry
      (or i915_gem_execbuffer_relocate_entry as it was called back then)
      which was left fully wrapped by pagefault_disable/enable() calls.
      Previously any issues with blocking calls where handled by the
      following code:
      
      	/* we can't wait for rendering with pagefaults disabled */
      	if (pagefault_disabled() && !object_is_idle(obj))
      		return -EFAULT;
      
      Now at this point the prefaulting was still around, which means in
      normal applications it was very hard to hit this bug. No idea why the
      regressions in igts weren't caught.
      
      Now this all changed big time with 2 patches merged closely together.
      
      First
      
      commit 2889caa9
      Author: Chris Wilson <chris@chris-wilson.co.uk>
      Date:   Fri Jun 16 15:05:19 2017 +0100
      
          drm/i915: Eliminate lots of iterations over the execobjects array
      
      removes the prefaulting from the first relocation path, pushing it into
      the first slowpath (of which this patch added a total of 3 escalation
      levels). This would have really quickly uncovered the above bug, were
      it not for immediate adding a duct-tape on top with
      
      commit 7dd4f672
      Author: Chris Wilson <chris@chris-wilson.co.uk>
      Date:   Fri Jun 16 15:05:24 2017 +0100
      
          drm/i915: Async GPU relocation processing
      
      by pushing all all the relocation patching to the gpu if the buffer
      was busy, which avoided all the possible blocking calls.
      
      The entire slowpath was then furthermore ditched in
      
      commit 7dc8f114
      Author: Chris Wilson <chris@chris-wilson.co.uk>
      Date:   Wed Mar 11 16:03:10 2020 +0000
      
              drm/i915/gem: Drop relocation slowpath
      
      and resurrected in
      
      commit fd1500fc
      Author: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Date:   Wed Aug 19 16:08:43 2020 +0200
      
              Revert "drm/i915/gem: Drop relocation slowpath".
      
      but this did not further impact what's going on.
      
      Since pagefault_disable/enable is an atomic section, any sleeping in
      there is prohibited, and we definitely do that without gpu relocations
      since we have to wait for the gpu usage to finish before we can patch
      up the relocations.
      Reviewed-by: NMatthew Auld <matthew.auld@intel.com>
      Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      Cc: Jon Bloomfield <jon.bloomfield@intel.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>
      Cc: Matthew Auld <matthew.auld@intel.com>
      Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
      Cc: Dave Airlie <airlied@redhat.com>
      Cc: Jason Ekstrand <jason@jlekstrand.net>
      Link: https://patchwork.freedesktop.org/patch/msgid/20210618214503.1773805-1-daniel.vetter@ffwll.ch
      ca319ee9
    • T
      drm/i915: Document the Virtual Engine uAPI · 57772953
      Tvrtko Ursulin 提交于
      A little bit of documentation covering the topics of engine discovery,
      context engine maps and virtual engines. It is not very detailed but
      supposed to be a starting point of giving a brief high level overview of
      general principles and intended use cases.
      
      v2:
       * Have the text in uapi header and link from there.
      
      v4:
       * Link from driver-uapi.rst.
      Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Cc: Daniel Vetter <daniel@ffwll.ch>
      Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: https://patchwork.freedesktop.org/patch/msgid/20210618150036.2507653-1-tvrtko.ursulin@linux.intel.com
      57772953
  10. 19 6月, 2021 13 次提交
  11. 18 6月, 2021 1 次提交
    • M
      drm/i915: Add support for explicit L3BANK steering · 31939274
      Matt Roper 提交于
      Because Render Power Gating restricts us to just a single subslice as a
      valid steering target for reads of multicast registers in a SUBSLICE
      range, the default steering we setup at init may not lead to a suitable
      target for L3BANK multicast register.  In cases where it does not, use
      explicit runtime steering whenever an L3BANK multicast register is read.
      
      While we're at it, let's simplify the function a little bit and drop its
      support for gen10/CNL since no such platforms ever materialized for real
      use.  Multicast register steering is already an area that causes enough
      confusion; no need to complicate it with what's effectively dead code.
      
      v2:
       - Use gt->uncore instead of gt->i915->uncore.  (Tvrtko)
       - Use {} as table terminator.  (Rodrigo)
      
      v3:
       - L3bank fuse register is a disable mask rather than an enable mask.
         We need to invert it before use.  (CI)
      
      v4:
       - L3bank ID goes in the subslice field, not the slice field.  (CI)
      
      Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
      Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
      Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
      Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20210617211425.1943662-4-matthew.d.roper@intel.com
      31939274