1. 11 11月, 2016 1 次提交
    • M
      drm/amdgpu: Attach exclusive fence to prime exported bo's. (v5) · 8e94a46c
      Mario Kleiner 提交于
      External clients which import our bo's wait only
      for exclusive dmabuf-fences, not on shared ones,
      ditto for bo's which we import from external
      providers and write to.
      
      Therefore attach exclusive fences on prime shared buffers
      if our exported buffer gets imported by an external
      client, or if we import a buffer from an external
      exporter.
      
      See discussion in thread:
      https://lists.freedesktop.org/archives/dri-devel/2016-October/122370.html
      
      Prime export tested on Intel iGPU + AMD Tonga dGPU as
      DRI3/Present Prime render offload, and with the Tonga
      standalone as primary gpu.
      
      v2: Add a wait for all shared fences before prime export,
          as suggested by Christian Koenig.
      
      v3: - Mark buffer prime_exported in amdgpu_gem_prime_pin,
          so we only use the exclusive fence when exporting a
          bo to external clients like a separate iGPU, but not
          when exporting/importing from/to ourselves as part of
          regular DRI3 fd passing.
      
          - Propagate failure of reservation_object_wait_rcu back
          to caller.
      
      v4: - Switch to a prime_shared_count counter instead of a
            flag, which gets in/decremented on prime_pin/unpin, so
            we can switch back to shared fences if all clients
            detach from our exported bo.
      
          - Also switch to exclusive fence for prime imported bo's.
      
      v5: - Drop lret, instead use int ret -> long ret, as proposed
            by Christian.
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=95472
      Tested-by: Mike Lothian <mike@fireburn.co.uk> (v1)
      Signed-off-by: NMario Kleiner <mario.kleiner.de@gmail.com>
      Reviewed-by: Christian König <christian.koenig@amd.com>.
      Cc: Christian König <christian.koenig@amd.com>
      Cc: Michel Dänzer <michel.daenzer@amd.com>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      Cc: stable@vger.kernel.org
      8e94a46c
  2. 07 10月, 2016 1 次提交
  3. 29 9月, 2016 2 次提交
  4. 22 9月, 2016 3 次提交
  5. 20 9月, 2016 1 次提交
  6. 17 9月, 2016 2 次提交
  7. 15 9月, 2016 3 次提交
  8. 13 9月, 2016 1 次提交
  9. 02 9月, 2016 1 次提交
  10. 01 9月, 2016 5 次提交
  11. 31 8月, 2016 2 次提交
    • M
      drm/amdgpu:add switch buffer to end of CS (v2) · c2167a65
      Monk Liu 提交于
      sync switch buffer scheme with windows kmd for gfx v8,
      step1: append a switch_buffer to the end of CS
      
      v2:rebase on latest staging
      Signed-off-by: NMonk Liu <Monk.Liu@amd.com>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      c2167a65
    • 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
  12. 25 8月, 2016 3 次提交
  13. 24 8月, 2016 1 次提交
  14. 23 8月, 2016 4 次提交
  15. 20 8月, 2016 2 次提交
  16. 16 8月, 2016 5 次提交
  17. 11 8月, 2016 3 次提交