1. 30 3月, 2017 5 次提交
  2. 11 3月, 2017 1 次提交
  3. 10 2月, 2017 1 次提交
  4. 28 1月, 2017 2 次提交
  5. 24 1月, 2017 1 次提交
  6. 07 12月, 2016 1 次提交
  7. 11 11月, 2016 2 次提交
  8. 09 11月, 2016 1 次提交
  9. 26 10月, 2016 5 次提交
  10. 25 10月, 2016 1 次提交
    • C
      dma-buf: Rename struct fence to dma_fence · f54d1867
      Chris Wilson 提交于
      I plan to usurp the short name of struct fence for a core kernel struct,
      and so I need to rename the specialised fence/timeline for DMA
      operations to make room.
      
      A consensus was reached in
      https://lists.freedesktop.org/archives/dri-devel/2016-July/113083.html
      that making clear this fence applies to DMA operations was a good thing.
      Since then the patch has grown a bit as usage increases, so hopefully it
      remains a good thing!
      
      (v2...: rebase, rerun spatch)
      v3: Compile on msm, spotted a manual fixup that I broke.
      v4: Try again for msm, sorry Daniel
      
      coccinelle script:
      @@
      
      @@
      - struct fence
      + struct dma_fence
      @@
      
      @@
      - struct fence_ops
      + struct dma_fence_ops
      @@
      
      @@
      - struct fence_cb
      + struct dma_fence_cb
      @@
      
      @@
      - struct fence_array
      + struct dma_fence_array
      @@
      
      @@
      - enum fence_flag_bits
      + enum dma_fence_flag_bits
      @@
      
      @@
      (
      - fence_init
      + dma_fence_init
      |
      - fence_release
      + dma_fence_release
      |
      - fence_free
      + dma_fence_free
      |
      - fence_get
      + dma_fence_get
      |
      - fence_get_rcu
      + dma_fence_get_rcu
      |
      - fence_put
      + dma_fence_put
      |
      - fence_signal
      + dma_fence_signal
      |
      - fence_signal_locked
      + dma_fence_signal_locked
      |
      - fence_default_wait
      + dma_fence_default_wait
      |
      - fence_add_callback
      + dma_fence_add_callback
      |
      - fence_remove_callback
      + dma_fence_remove_callback
      |
      - fence_enable_sw_signaling
      + dma_fence_enable_sw_signaling
      |
      - fence_is_signaled_locked
      + dma_fence_is_signaled_locked
      |
      - fence_is_signaled
      + dma_fence_is_signaled
      |
      - fence_is_later
      + dma_fence_is_later
      |
      - fence_later
      + dma_fence_later
      |
      - fence_wait_timeout
      + dma_fence_wait_timeout
      |
      - fence_wait_any_timeout
      + dma_fence_wait_any_timeout
      |
      - fence_wait
      + dma_fence_wait
      |
      - fence_context_alloc
      + dma_fence_context_alloc
      |
      - fence_array_create
      + dma_fence_array_create
      |
      - to_fence_array
      + to_dma_fence_array
      |
      - fence_is_array
      + dma_fence_is_array
      |
      - trace_fence_emit
      + trace_dma_fence_emit
      |
      - FENCE_TRACE
      + DMA_FENCE_TRACE
      |
      - FENCE_WARN
      + DMA_FENCE_WARN
      |
      - FENCE_ERR
      + DMA_FENCE_ERR
      )
       (
       ...
       )
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
      Acked-by: NSumit Semwal <sumit.semwal@linaro.org>
      Acked-by: NChristian König <christian.koenig@amd.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: http://patchwork.freedesktop.org/patch/msgid/20161025120045.28839-1-chris@chris-wilson.co.uk
      f54d1867
  11. 21 10月, 2016 1 次提交
  12. 29 9月, 2016 1 次提交
  13. 15 9月, 2016 4 次提交
  14. 13 9月, 2016 1 次提交
  15. 02 9月, 2016 2 次提交
  16. 31 8月, 2016 1 次提交
    • M
      drm/amdgpu: throttle buffer migrations at CS using a fixed MBps limit (v2) · 95844d20
      Marek Olšák 提交于
      The old mechanism used a per-submission limit that didn't take previous
      submissions within the same time frame into account. It also filled VRAM
      slowly when VRAM usage dropped due to a big eviction or buffer deallocation.
      
      This new method establishes a configurable MBps limit that is obeyed when
      VRAM usage is very high. When VRAM usage is not very high, it gives
      the driver the freedom to fill it quickly. The result is more consistent
      performance.
      
      It can't keep the BO move rate low if lots of evictions are happening due
      to VRAM fragmentation, or if a big buffer is being migrated.
      
      The amdgpu.moverate parameter can be used to set a non-default limit.
      Measurements can be done to find out which amdgpu.moverate setting gives
      the best results.
      
      Mainly APUs and cards with small VRAM will benefit from this. For F1 2015,
      anything with 2 GB VRAM or less will benefit.
      
      Some benchmark results - F1 2015 (Tonga 2GB):
      
      Limit      MinFPS AvgFPS
      Old code:  14     32.6
      128 MB/s:  28     41
      64 MB/s:   15.5   43
      32 MB/s:   28.7   43.4
      8 MB/s:    27.8   44.4
      8 MB/s:    21.9   42.8 (different run)
      
      Random drops in Min FPS can still occur (due to fragmented VRAM?), but
      the average FPS is much better. 8 MB/s is probably a good limit for this
      game & the current VRAM management. The random FPS drops are still to be
      tackled.
      
      v2: use a spinlock
      Signed-off-by: NMarek Olšák <marek.olsak@amd.com>
      Acked-by: NChristian König <christian.koenig@amd.com>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      95844d20
  17. 23 8月, 2016 1 次提交
  18. 16 8月, 2016 1 次提交
  19. 08 8月, 2016 1 次提交
  20. 08 7月, 2016 7 次提交