[RFC] drm/amd/display: add SI support to AMD DC

Mauro Rossi issor.oruam at gmail.com
Mon Oct 15 05:28:57 UTC 2018


Hi Sylvain,

Il lun 15 ott 2018, 03:25 <sylvain.bertrand at gmail.com> ha scritto:

> On Sun, Oct 14, 2018 at 11:47:18PM +0200, Mauro Rossi wrote:
> > DOUBT: I think that it would make sense to set "power level 0" i.e.
> > the "lower state" as safe default,
> > considering that powerplay smu6/hwmgr are not implemented for SI and
> > smu7 CIK functions do not work,
> > the AS-IS dpm is the only available option. (and it seams to be
> > working, looking at the framerates 250-280 in the V1 Vulkan benchmark)
>
> dpm not implemented for SI? Are you sure? Because I recall passing
> "messages"
>

dpm for SI is available, while powerplay for SI is not, but
display/amdgpu_dm uses some powerplay calls, where get_static_clock
functions not available and the *ERROR* DM_PPLIB is due to missing handling
in powerplay

to the smu6 to switch between major power modes. And currently in amdgpu I
> switch back and forth between "high" and "auto". And if I stay on "high"
> my GPU
> fans are going crazy all the time, which forces me to switch back to
> "auto" in
> order to quiet the fans.
> Any major state change for any block would have to go through the dpm block
> (smu), because it has to be accounted by this block for proper operation.
> One
> of the hard thing to code, coze no proper documentation, was to set the
> blocks
> in an initial state from a poweron/hard reset/etc which the dpm will know
> how to start/catch-up its operations from. In a perfect world, the dpm
> block
> would have the knowledge on how to program any block in an initial working
> state from any unknown state (and in case of hard block hang, would know
> how to
> hard reset it and set it in a initial state).
>
> > If freesync is about reducing the framerate rate for power saving,
> > provided that I've seen it be mentioned the first time for GCN 2nd
> generation,
> > I'm not expecting freesync as a mandatory capability for the series.
>
> Well, there are the low FPS games, and the movies. I am a regular gamer,
> and I
> know that sustained 60 fps is the very lower bound for many games on a
> desktop
> computer display.
> It does not apply to mobile size display, and "couch playing" on a TV.  The
> readibilty of the game depends directly on the amplitude of movements in
> physical distance on the display, their speed, the viewing distance, and
> the
> FPS. From my personal comfort point of view and types of games I play, on a
> desktop display (dpi, typical viewing distance, typical size), I would
> target a
> minimum of 80-100 fps (120/144 fps seems to be "perfect" targets).
> Played rise of the tomb raider (vulkan) on my tahiti part, and even with a
> blur
> effect to "smooth" the perceived fps like in movies, sub-60 fps is really
> uncomfortable. I was about to stop playing to this game even though it is a
> rather "slow" video game.
>
> > In amd-staging-drm-next dce_clock_source is generic, SI specifics are
> > not necessary anymore.
>
> If I recall properly, "bandwidths" and "watermarks" calcs had asic
> generations
> specific code paths. bandwidth is important for displayport programming or
> maybe you can presume the maximum all the time (and sacrifice some unkown
> amount of power) and watermarks, I know in my old driver I was giving the
> highest priority the the dce block anyway (something related to a "memory
> aribtrer" and "line buffer").
>
> > Any other testing tools worth a run?
>
> AAA games (vulkan: rize of the tomb raider, GL:bioshock infinite) and AAAA
> games
> (dota2(gl and vulkan), cs:go...)
>
> --
> Sylvain
>

Thanks a  lot
Mauro

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/amd-gfx/attachments/20181015/4be31814/attachment.html>


More information about the amd-gfx mailing list