1. 02 9月, 2016 2 次提交
  2. 01 9月, 2016 1 次提交
  3. 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
  4. 25 8月, 2016 2 次提交
  5. 23 8月, 2016 1 次提交
  6. 11 8月, 2016 1 次提交
  7. 09 8月, 2016 1 次提交
  8. 08 8月, 2016 1 次提交
  9. 30 7月, 2016 1 次提交
  10. 08 7月, 2016 7 次提交
  11. 18 5月, 2016 2 次提交
  12. 14 5月, 2016 1 次提交
  13. 12 5月, 2016 1 次提交
  14. 05 5月, 2016 3 次提交
  15. 04 5月, 2016 1 次提交
  16. 30 3月, 2016 1 次提交
  17. 09 3月, 2016 1 次提交
  18. 28 2月, 2016 1 次提交
    • O
      drm/amdgpu: Return -EPROBE_DEFER when amdkfd not loaded · efb1c658
      Oded Gabbay 提交于
      amdgpu must load only after amdkfd's loading has been completed. If that
      is not enforced, then amdgpu's call into amdkfd's functions will cause a
      kernel BUG.
      
      When amdgpu and amdkfd are built as kernel modules, that rule is enforced
      by the kernel's modules loading mechanism. When amdgpu and amdkfd are
      built inside the kernel image, that rule is enforced by ordering in the
      drm Makefile (amdkfd before amdgpu).
      
      Instead of using drm Makefile ordering, we can now use deferred loading
      as amdkfd now returns -EPROBE_DEFER in kgd2kfd_init() when it is not yet
      loaded.
      
      This patch defers amdgpu loading by propagating -EPROBE_DEFER to the
      kernel's drivers loading infrastructure. That will put amdgpu into the
      pending drivers list (see description in dd.c). Once amdkfd is loaded,
      a call to kgd2kfd_init() will return successfully and amdgpu will be able
      to load.
      Signed-off-by: NOded Gabbay <oded.gabbay@gmail.com>
      Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
      efb1c658
  19. 11 2月, 2016 3 次提交
  20. 08 2月, 2016 1 次提交
  21. 03 2月, 2016 1 次提交
  22. 22 12月, 2015 3 次提交
  23. 15 12月, 2015 1 次提交
  24. 22 10月, 2015 2 次提交