[PATCH] drm/amdgpu: set bypass mode when uvd is idle.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Deucher, Alexander wrote:
>> -----Original Message----- From: amd-gfx
>> [mailto:amd-gfx-bounces at lists.freedesktop.org] On Behalf Of Andy
>> Furniss Sent: Sunday, November 06, 2016 3:31 PM To: Zhu, Rex;
>> Deucher, Alexander; amd-gfx at lists.freedesktop.org Subject: Re:
>> [PATCH] drm/amdgpu: set bypass mode when uvd is idle.
>>
>> Zhu, Rex wrote:
>>>>>> Is there any harm in just always putting it into bypass
>>>>>> mode or does it interact badly with PG?  Presumably it does
>>>>>> (otherwise we wouldn't need this patch), it would be good
>>>>>> to note why.
>>>
>>> Rex: when UVD PG enabled, DCLK/VCLK will be turn off when uvd is
>>> idle(DCLK=OFF). If we set bypass mode=1, dclk/vclk will be
>>> bypassed to an external â??Bypassâ?? clock(DCLK = 100MHz)
>>>
>>> So it is unnecessary to set bypass mode when PG enabled.
>>>
>>> +uvd_v5_0_set_bypass_mode(adev, !enable); This change is because
>>> tom's commit 72cb64c1f6a3a8129af341e90418a687c4971a40 Fix the
>>> sequence of UVD powergate function in smu7_clockgating.c.
>>
>> I was about to file a bug till I tried this which fixes UVD perf on
>> my R9285 + agd5f drm-next-4.10-wip.
>>
>> Additional unrelated question = I notice that UVD does not seem to
>> set other clocks quite high enough when used.
>>
>> For playback the vo may bump things up a bit, but even then it can
>> be a bit borderline for playing high bitrate UHD with powerplay on
>> auto.
>>
>> Pure decode benchmarks like
>>
>> ffmpeg -hwaccel vdpau -i high-bitrate-2160p60-vid -pix_fmt nv12 -f
>> null -
>>
>> go from 63 -> 81 fps, powerplay auto -> high.
>
> The UVD and gfx clocks are separate.  The gfx load for video decode
> operations is not generally great enough (CSC and maybe scaling) to
> generate enough gfx load to boost the gfx clocks to their highest
> level.  We plan to add an API to allow userspace applications to
> request a minimum floor for specific contexts, but it hasn't been
> implemented yet.  This is useful if you are trying to hit maximum
> decode rates, but may not always be the best choice for power usage.
> You really only want to set the clocks high enough to hit the target
> frame rate.
>
> Alex

OK, thanks for the info.


[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux