1. 28 1月, 2016 1 次提交
  2. 21 1月, 2016 2 次提交
  3. 19 1月, 2016 1 次提交
  4. 13 1月, 2016 1 次提交
  5. 12 1月, 2016 1 次提交
    • V
      drm/i915: Use MI_BATCH_BUFFER_START on 830/845 · 9d611c03
      Ville Syrjälä 提交于
      MI_BATCH_BUFFER is nasty since it requires that userspace pass in the
      correct batch length.
      
      Let's switch to using MI_BATCH_BUFFER_START instead (like we do on
      other platforms). Then we don't have to specify the batch length
      at all, and the CS will instead execute until it sees the
      MI_BATCH_BUFFER_END.
      
      We still need the batch length since we do the CS TLB workaround
      and copy the batch into the permanently pinned scratch object
      and execute it from there. But for this we can simply use the
      batch object length when the user hasn't specified the actual
      batch length. So specifying the batch length becomes just a
      way to optimize the batch copy a little bit.
      
      We lost batch_len from a bunch of igts (including the quiesce batch)
      so without this igt is utterly broken on 830/845. Also some igts such
      as gem_cpu_reloc never specified the batch_len and so didn't work.
      With MI_BATCH_BUFFER_START we don't have to fix up igt every time
      someone forgets that 830/845 exist.
      
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1450110229-30450-11-git-send-email-ville.syrjala@linux.intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      9d611c03
  6. 05 1月, 2016 1 次提交
  7. 12 12月, 2015 1 次提交
    • D
      drm/i915: mark GEM object pages dirty when mapped & written by the CPU · 033908ae
      Dave Gordon 提交于
      In various places, a single page of a (regular) GEM object is mapped into
      CPU address space and updated. In each such case, either the page or the
      the object should be marked dirty, to ensure that the modifications are
      not discarded if the object is evicted under memory pressure.
      
      The typical sequence is:
      	va = kmap_atomic(i915_gem_object_get_page(obj, pageno));
      	*(va+offset) = ...
      	kunmap_atomic(va);
      
      Here we introduce i915_gem_object_get_dirty_page(), which performs the
      same operation as i915_gem_object_get_page() but with the side-effect
      of marking the returned page dirty in the pagecache.  This will ensure
      that if the object is subsequently evicted (due to memory pressure),
      the changes are written to backing store rather than discarded.
      
      Note that it works only for regular (shmfs-backed) GEM objects, but (at
      least for now) those are the only ones that are updated in this way --
      the objects in question are contexts and batchbuffers, which are always
      shmfs-backed.
      
      Separate patches deal with the cases where whole objects are (or may
      be) dirtied.
      
      v3: Mark two more pages dirty in the page-boundary-crossing
          cases of the execbuffer relocation code [Chris Wilson]
      Signed-off-by: NDave Gordon <david.s.gordon@intel.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Link: http://patchwork.freedesktop.org/patch/msgid/1449773486-30822-2-git-send-email-david.s.gordon@intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      033908ae
  8. 09 12月, 2015 1 次提交
    • C
      drm/i915: Add soft-pinning API for execbuffer · 506a8e87
      Chris Wilson 提交于
      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.
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      
      v2: Fixed incorrect eviction found by Michal Winiarski - fix suggested by Chris
      Wilson.  Fixed incorrect error paths causing crash found by Michal Winiarski.
      (Not published externally)
      
      v3: Rebased because of trivial conflict in object_bind_to_vm.  Fixed eviction
      to allow eviction of soft-pinned objects when another soft-pinned object used
      by a subsequent execbuffer overlaps reported by Michal Winiarski.
      (Not published externally)
      
      v4: Moved soft-pinned objects to the front of ordered_vmas so that they are
      pinned first after an address conflict happens to avoid repeated conflicts in
      rare cases (Suggested by Chris Wilson).  Expanded comment on
      drm_i915_gem_exec_object2.offset to cover this new API.
      
      v5: Added I915_PARAM_HAS_EXEC_SOFTPIN parameter for detecting this capability
      (Kristian). Added check for multiple pinnings on eviction (Akash). Made sure
      buffers are not considered misplaced without the user specifying
      EXEC_OBJECT_SUPPORTS_48B_ADDRESS.  User must assume responsibility for any
      addressing workarounds.  Updated object2.offset field comment again to clarify
      NO_RELOC case (Chris).  checkpatch cleanup.
      
      v6: Trivial rebase on latest drm-intel-nightly
      
      v7: Catch attempts to pin above the max virtual address size and return
      EINVAL (Tvrtko). Decouple EXEC_OBJECT_SUPPORTS_48B_ADDRESS and
      EXEC_OBJECT_PINNED flags, user must pass both flags in any attempt to pin
      something at an offset above 4GB (Chris, Daniel Vetter).
      
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Akash Goel <akash.goel@intel.com>
      Cc: Vinay Belgaumkar <vinay.belgaumkar@intel.com>
      Cc: Michal Winiarski <michal.winiarski@intel.com>
      Cc: Zou Nanhai <nanhai.zou@intel.com>
      Cc: Kristian Høgsberg <hoegsberg@gmail.com>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
      Reviewed-by: NMichel Thierry <michel.thierry@intel.com>
      Acked-by: PDT
      Signed-off-by: NThomas Daniel <thomas.daniel@intel.com>
      Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1449575707-20933-1-git-send-email-thomas.daniel@intel.com
      506a8e87
  9. 18 11月, 2015 1 次提交
  10. 07 10月, 2015 1 次提交
  11. 02 10月, 2015 1 次提交
    • M
      drm/i915: Wa32bitGeneralStateOffset & Wa32bitInstructionBaseOffset · 101b506a
      Michel Thierry 提交于
      There are some allocations that must be only referenced by 32-bit
      offsets. To limit the chances of having the first 4GB already full,
      objects not requiring this workaround use DRM_MM_SEARCH_BELOW/
      DRM_MM_CREATE_TOP flags
      
      In specific, any resource used with flat/heapless (0x00000000-0xfffff000)
      General State Heap (GSH) or Instruction State Heap (ISH) must be in a
      32-bit range, because the General State Offset and Instruction State
      Offset are limited to 32-bits.
      
      Objects must have EXEC_OBJECT_SUPPORTS_48B_ADDRESS flag to indicate if
      they can be allocated above the 32-bit address range. To limit the
      chances of having the first 4GB already full, objects will use
      DRM_MM_SEARCH_BELOW + DRM_MM_CREATE_TOP flags when possible.
      
      The libdrm user of the EXEC_OBJECT_SUPPORTS_48B_ADDRESS flag is here:
      http://lists.freedesktop.org/archives/intel-gfx/2015-September/075836.html
      
      v2: Changed flag logic from neeeds_32b, to supports_48b.
      v3: Moved 48-bit support flag back to exec_object. (Chris, Daniel)
      v4: Split pin flags into PIN_ZONE_4G and PIN_HIGH; update PIN_OFFSET_MASK
      to use last PIN_ defined instead of hard-coded value; use correct limit
      check in eb_vma_misplaced. (Chris)
      v5: Don't touch PIN_OFFSET_MASK and update workaround comment (Chris)
      v6: Apply pin-high for ggtt too (Chris)
      v7: Handle simultaneous pin-high and pin-mappable end correctly (Akash)
          Fix check for entries currently using +4GB addresses, use min_t and
          other polish in object_bind_to_vm (Chris)
      v8: Commit message updated to point to libdrm patch.
      v9: vmas are allocated in the correct ozone, so only check flag when the
          vma has not been allocated. (Chris)
      
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v4)
      Signed-off-by: NMichel Thierry <michel.thierry@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      101b506a
  12. 14 9月, 2015 1 次提交
    • N
      drm/i915: Split alloc from init for lrc · e84fe803
      Nick Hoath 提交于
      Extend init/init_hw split to context init.
         - Move context initialisation in to i915_gem_init_hw
         - Move one off initialisation for render ring to
              i915_gem_validate_context
         - Move default context initialisation to logical_ring_init
      
      Rename intel_lr_context_deferred_create to
      intel_lr_context_deferred_alloc, to reflect reduced functionality &
      alloc/init split.
      
      This patch is intended to split out the allocation of resources &
      initialisation to allow easier reuse of code for resume/gpu reset.
      
      v2: Removed function ptr wrapping of do_switch_context (Daniel Vetter)
          Left ->init_context int intel_lr_context_deferred_alloc
          (Daniel Vetter)
          Remove unnecessary init flag & ring type test. (Daniel Vetter)
          Improve commit message (Daniel Vetter)
      v3: On init/reinit, set the hw next sequence number to the sw next
          sequence number. This is set to 1 at driver load time. This prevents
          the seqno being reset on reinit (Chris Wilson)
      v4: Set seqno back to ~0 - 0x1000 at start-of-day, and increment by 0x100
          on reset.
          This makes it obvious which bbs are which after a reset. (David Gordon
          & John Harrison)
          Rebase.
      v5: Rebase. Fixed rebase breakage. Put context pinning in separate
          function. Removed code churn. (Thomas Daniel)
      v6: Cleanup up issues introduced in v2 & v5 (Thomas Daniel)
      
      Issue: VIZ-4798
      Signed-off-by: NNick Hoath <nicholas.hoath@intel.com>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: John Harrison <john.c.harrison@intel.com>
      Cc: David Gordon <david.s.gordon@intel.com>
      Cc: Thomas Daniel <thomas.daniel@intel.com>
      Reviewed-by: NThomas Daniel <thomas.daniel@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      e84fe803
  13. 02 9月, 2015 1 次提交
    • C
      drm/i915: Always mark the object as dirty when used by the GPU · 51bc1404
      Chris Wilson 提交于
      There have been many hard to track down bugs whereby userspace forgot to
      flag a write buffer and then cause graphics corruption or a hung GPU
      when that buffer was later purged under memory pressure (as the buffer
      appeared clean, its pages would have been evicted rather than preserved
      and any changes more recent than in the backing storage would be lost).
      In retrospect this is a rare optimisation against memory pressure,
      already the slow path. If we always mark the buffer as dirty when
      accessed by the GPU, anything not used can still be evicted cheaply
      (ideal behaviour for mark-and-sweep eviction) but we do not run the risk
      of corruption. For correct read serialisation, userspace still has to
      notify when the GPU writes to an object. However, there are certain
      situations under which userspace may wish to tell white lies to the
      kernel...
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Kristian Høgsberg <krh@bitplanet.net>
      Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
      Cc: "Goel, Akash" <akash.goel@intel.co>
      Cc: Michał Winiarski <michal.winiarski@intel.com>
      Cc: stable@vger.kernel.org
      Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      51bc1404
  14. 06 7月, 2015 1 次提交
    • A
      drm/i915: Expose I915_EXEC_RESOURCE_STREAMER flag and getparam · a9ed33ca
      Abdiel Janulgue 提交于
      Ensures that the batch buffer is executed by the resource streamer.
      And will let userspace know whether Resource Streamer is supported in
      the kernel.
      
      v2: Don't skip 1<<15 for the exec flags (Jani Nikula)
      v3: Use HAS_RESOURCE_STREAMER macro for execbuf validation (Chris Wilson)
      
      (from getparam patch)
      
      v2: Update I915_PARAM_HAS_RESOURCE_STREAMER so it's after
          I915_PARAM_HAS_GPU_RESET.
      v3: Only advertise RS support for hardware that supports it.
      v4: Add HAS_RESOURCE_STREAMER() macro (Chris)
      
      Testcase: igt/gem_exec_params
      Cc: Jani Nikula <jani.nikula@intel.com>
      Cc: Kenneth Graunke <kenneth@whitecape.org>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NAbdiel Janulgue <abdiel.janulgue@linux.intel.com>
      [danvet: squash in getparam patch since it'd break bisect, suggested
      by Chris.]
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      a9ed33ca
  15. 23 6月, 2015 19 次提交
  16. 22 6月, 2015 2 次提交
  17. 29 5月, 2015 1 次提交
  18. 21 5月, 2015 1 次提交
  19. 19 5月, 2015 1 次提交
  20. 08 5月, 2015 1 次提交