1. 13 Mar, 2014 23 commits
  2. 05 Mar, 2014 1 commit
    • Dave Airlie's avatar
      Merge branch 'drm-next-3.15' of git://people.freedesktop.org/~deathsimple/linux into drm-next · 786a7828
      Dave Airlie authored
      this is the second pull request for 3.15 radeon changes. Highlights this time:
      - Better VRAM usage
      - VM page table rework
      - Enabling different UVD clocks again
      - Some general cleanups and improvements
      
      * 'drm-next-3.15' of git://people.freedesktop.org/~deathsimple/linux:
        drm/radeon: remove struct radeon_bo_list
        drm/radeon: drop non blocking allocations from sub allocator
        drm/radeon: remove global vm lock
        drm/radeon: use normal BOs for the page tables v4
        drm/radeon: further cleanup vm flushing & fencing
        drm/radeon: separate gart and vm functions
        drm/radeon: fix VCE suspend/resume
        drm/radeon: fix missing bo reservation
        drm/radeon: limit how much memory TTM can move per IB according to VRAM usage
        drm/radeon: validate relocations in the order determined by userspace v3
        drm/radeon: add buffers to the LRU list from smallest to largest
        drm/radeon: deduplicate code in radeon_gem_busy_ioctl
        drm/radeon: track memory statistics about VRAM and GTT usage and buffer moves v2
        drm/radeon: add a way to get and set initial buffer domains v2
        drm/radeon: use variable UVD clocks
        drm/radeon: cleanup the fence ring locking code
        drm/radeon: improve ring lockup detection code v2
      786a7828
  3. 04 Mar, 2014 1 commit
  4. 03 Mar, 2014 14 commits
  5. 28 Feb, 2014 1 commit
    • Alex Deucher's avatar
      drm/radeon: use variable UVD clocks · 14a9579d
      Alex Deucher authored
      Now that Christian fixed the performance problems with
      the feedback buffer in mesa, we can enable variable UVD
      clocks.  There are multiple UVD power states associated
      with different types and numbers of streams.  This uses
      the appropriate state based on that information rather
      than always using the fastest UVD clocks which saves some
      power.  One possible downside is that this may adversely
      affect decode benchmarks since these power states target
      specific playback requirements rather than maximum
      performance.  If that becomes an issue, we can add a
      sysfs attribute to force the max UVD state.
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Reviewed-by: default avatarChristian König <christian.koenig@amd.com>
      14a9579d