1. 15 4月, 2017 1 次提交
  2. 27 3月, 2017 1 次提交
  3. 14 3月, 2017 1 次提交
  4. 03 3月, 2017 1 次提交
  5. 25 2月, 2017 1 次提交
    • K
      drm/i915: Drop support for I915_EXEC_CONSTANTS_* execbuf parameters. · ef0f411f
      Kenneth Graunke 提交于
      This patch makes the I915_PARAM_HAS_EXEC_CONSTANTS getparam return 0
      (indicating the optional feature is not supported), and makes execbuf
      always return -EINVAL if the flags are used.
      
      Apparently, no userspace ever shipped which used this optional feature:
      I checked the git history of Mesa, xf86-video-intel, libva, and Beignet,
      and there were zero commits showing a use of these flags.  Kernel commit
      72bfa19c apparently introduced the feature prematurely.  According
      to Chris, the intention was to use this in cairo-drm, but "the use was
      broken for gen6", so I don't think it ever happened.
      
      'relative_constants_mode' has always been tracked per-device, but this
      has actually been wrong ever since hardware contexts were introduced, as
      the INSTPM register is saved (and automatically restored) as part of the
      render ring context. The software per-device value could therefore get
      out of sync with the hardware per-context value.  This meant that using
      them is actually unsafe: a client which tried to use them could damage
      the state of other clients, causing the GPU to interpret their BO
      offsets as absolute pointers, leading to bogus memory reads.
      
      These flags were also never ported to execlist mode, making them no-ops
      on Gen9+ (which requires execlists), and Gen8 in the default mode.
      
      On Gen8+, userspace can write these registers directly, achieving the
      same effect.  On Gen6-7.5, it likely makes sense to extend the command
      parser to support them.  I don't think anyone wants this on Gen4-5.
      
      Based on a patch by Dave Gordon.
      
      v3: Return -ENODEV for the getparam, as this is what we do for other
          obsolete features.  Suggested by Chris Wilson.
      
      Cc: stable@vger.kernel.org
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92448Signed-off-by: NKenneth Graunke <kenneth@whitecape.org>
      Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170215093446.21291-1-kenneth@whitecape.orgAcked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      ef0f411f
  6. 22 2月, 2017 2 次提交
  7. 21 2月, 2017 2 次提交
  8. 14 2月, 2017 1 次提交
    • T
      drm/i915: Emit to ringbuffer directly · 73dec95e
      Tvrtko Ursulin 提交于
      This removes the usage of intel_ring_emit in favour of
      directly writing to the ring buffer.
      
      intel_ring_emit was preventing the compiler for optimising
      fetch and increment of the current ring buffer pointer and
      therefore generating very verbose code for every write.
      
      It had no useful purpose since all ringbuffer operations
      are started and ended with intel_ring_begin and
      intel_ring_advance respectively, with no bail out in the
      middle possible, so it is fine to increment the tail in
      intel_ring_begin and let the code manage the pointer
      itself.
      
      Useless instruction removal amounts to approximately
      two and half kilobytes of saved text on my build.
      
      Not sure if this has any measurable performance
      implications but executing a ton of useless instructions
      on fast paths cannot be good.
      
      v2:
       * Change return from intel_ring_begin to error pointer by
         popular demand.
       * Move tail increment to intel_ring_advance to enable some
         error checking.
      
      v3:
       * Move tail advance back into intel_ring_begin.
       * Rebase and tidy.
      
      v4:
       * Complete rebase after a few months since v3.
      
      v5:
       * Remove unecessary cast and fix !debug compile. (Chris Wilson)
      
      v6:
       * Make intel_ring_offset take request as well.
       * Fix recording of request postfix plus a sprinkle of asserts.
         (Chris Wilson)
      
      v7:
       * Use intel_ring_offset to get the postfix. (Chris Wilson)
       * Convert GVT code as well.
      
      v8:
       * Rename *out++ to *cs++.
      
      v9:
       * Fix GVT out to cs conversion in GVT.
      
      v10:
       * Rebase for new intel_ring_begin in selftests.
      Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Cc: Zhi Wang <zhi.a.wang@intel.com>
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Acked-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170214113242.29241-1-tvrtko.ursulin@linux.intel.com
      73dec95e
  9. 08 2月, 2017 2 次提交
  10. 04 2月, 2017 1 次提交
  11. 03 2月, 2017 1 次提交
    • C
      drm: Improve drm_mm search (and fix topdown allocation) with rbtrees · 4e64e553
      Chris Wilson 提交于
      The drm_mm range manager claimed to support top-down insertion, but it
      was neither searching for the top-most hole that could fit the
      allocation request nor fitting the request to the hole correctly.
      
      In order to search the range efficiently, we create a secondary index
      for the holes using either their size or their address. This index
      allows us to find the smallest hole or the hole at the bottom or top of
      the range efficiently, whilst keeping the hole stack to rapidly service
      evictions.
      
      v2: Search for holes both high and low. Rename flags to mode.
      v3: Discover rb_entry_safe() and use it!
      v4: Kerneldoc for enum drm_mm_insert_mode.
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Cc: Alex Deucher <alexander.deucher@amd.com>
      Cc: "Christian König" <christian.koenig@amd.com>
      Cc: David Airlie <airlied@linux.ie>
      Cc: Russell King <rmk+kernel@armlinux.org.uk>
      Cc: Daniel Vetter <daniel.vetter@intel.com>
      Cc: Jani Nikula <jani.nikula@linux.intel.com>
      Cc: Sean Paul <seanpaul@chromium.org>
      Cc: Lucas Stach <l.stach@pengutronix.de>
      Cc: Christian Gmeiner <christian.gmeiner@gmail.com>
      Cc: Rob Clark <robdclark@gmail.com>
      Cc: Thierry Reding <thierry.reding@gmail.com>
      Cc: Stephen Warren <swarren@wwwdotorg.org>
      Cc: Alexandre Courbot <gnurou@gmail.com>
      Cc: Eric Anholt <eric@anholt.net>
      Cc: Sinclair Yeh <syeh@vmware.com>
      Cc: Thomas Hellstrom <thellstrom@vmware.com>
      Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
      Reviewed-by: Sinclair Yeh <syeh@vmware.com> # vmwgfx
      Reviewed-by: Lucas Stach <l.stach@pengutronix.de> #etnaviv
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170202210438.28702-1-chris@chris-wilson.co.uk
      4e64e553
  12. 28 1月, 2017 2 次提交
  13. 19 1月, 2017 1 次提交
  14. 11 1月, 2017 1 次提交
  15. 31 12月, 2016 1 次提交
  16. 19 12月, 2016 1 次提交
  17. 06 12月, 2016 2 次提交
    • C
      drm/i915: Fix i915_gem_evict_for_vma (soft-pinning) · 172ae5b4
      Chris Wilson 提交于
      Soft-pinning depends upon being able to check for availabilty of an
      interval and evict overlapping object from a drm_mm range manager very
      quickly. Currently it uses a linear list, and so performance is dire and
      not suitable as a general replacement. Worse, the current code will oops
      if it tries to evict an active buffer.
      
      It also helps if the routine reports the correct error codes as expected
      by its callers and emits a tracepoint upon use.
      
      For posterity since the wrong patch was pushed (i.e. that missed these
      key points and had known bugs), this is the changelog that should have
      been on commit 506a8e87 ("drm/i915: Add soft-pinning API for
      execbuffer"):
      
      Userspace can pass in an offset that it presumes the object is located
      at. The kernel will then do its utmost to fit the object into that
      location. The assumption is that userspace is handling its own object
      locations (for example along with full-ppgtt) and that the kernel will
      rarely have to make space for the user's requests.
      
      This extends the DRM_IOCTL_I915_GEM_EXECBUFFER2 to do the following:
      * if the user supplies a virtual address via the execobject->offset
        *and* sets the EXEC_OBJECT_PINNED flag in execobject->flags, then
        that object is placed at that offset in the address space selected
        by the context specifier in execbuffer.
      * the location must be aligned to the GTT page size, 4096 bytes
      * as the object is placed exactly as specified, it may be used by this
        execbuffer call without relocations pointing to it
      
      It may fail to do so if:
      * EINVAL is returned if the object does not have a 4096 byte aligned
        address
      * the object conflicts with another pinned object (either pinned by
        hardware in that address space, e.g. scanouts in the aliasing ppgtt)
        or within the same batch.
        EBUSY is returned if the location is pinned by hardware
        EINVAL is returned if the location is already in use by the batch
      * EINVAL is returned if the object conflicts with its own alignment (as meets
        the hardware requirements) or if the placement of the object does not fit
        within the address space
      
      All other execbuffer errors apply.
      
      Presence of this execbuf extension may be queried by passing
      I915_PARAM_HAS_EXEC_SOFTPIN to DRM_IOCTL_I915_GETPARAM and checking for
      a reported value of 1 (or greater).
      
      v2: Combine the hole/adjusted-hole ENOSPC checks
      v3: More color, more splitting, more blurb.
      
      Fixes: 506a8e87 ("drm/i915: Add soft-pinning API for execbuffer")
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20161205142941.21965-2-chris@chris-wilson.co.uk
      172ae5b4
    • C
      drm/i915: Mark all non-vma being inserted into the address spaces · 85fd4f58
      Chris Wilson 提交于
      We need to distinguish between full i915_vma structs and simple
      drm_mm_nodes when considering eviction (i.e. we must be careful not to
      treat a mere drm_mm_node as a much larger i915_vma causing memory
      corruption, if we are lucky). To do this, color these not-a-vma with -1
      (I915_COLOR_UNEVICTABLE).
      
      v2...v200: New name for -1.
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20161205142941.21965-1-chris@chris-wilson.co.uk
      85fd4f58
  18. 24 11月, 2016 1 次提交
  19. 21 11月, 2016 1 次提交
  20. 18 11月, 2016 1 次提交
  21. 17 11月, 2016 1 次提交
  22. 11 11月, 2016 3 次提交
  23. 08 11月, 2016 1 次提交
  24. 03 11月, 2016 1 次提交
  25. 29 10月, 2016 5 次提交
  26. 18 10月, 2016 1 次提交
    • C
      drm/i915: Restrict pagefault disabling to just around copy_from_user() · ebc0808f
      Chris Wilson 提交于
      When handling execbuf relocations, we play a delicate dance with
      pagefault. We first try to access the user pages underneath our
      struct_mutex. However, if those pages were inside a GEM object, we may
      trigger a pagefault and deadlock as i915_gem_fault() tries to
      recursively acquire struct_mutex. Instead, we choose to disable
      pagefaulting around the copy_from_user whilst inside the struct_mutex
      and handle the EFAULT by falling back to a copy outside the
      struct_mutex.
      
      We however presumed that disabling pagefaults would be expensive. It is
      just an operation on the local current task. Cheap enough that we can
      restrict the disable/enable to the critical section around the copy, and
      so avoid having to handle the atomic sections within the relocation
      handling itself.
      
      v2: Just illustrate the broken error handling rather than argue why it
      is safer to ignore it, for now.
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
      Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20161018120251.25043-4-chris@chris-wilson.co.uk
      ebc0808f
  27. 14 10月, 2016 3 次提交