Re: "enable ctxprog xfer only when we need it to save power" introduces big performance regression

[Martin Peres <martin.peres-Iz16wY1oaNPLSKGbIzaifA@public.gmane.org>]

On 28/12/2011 22:39, Marcin Slusarz wrote:
> Heh, with page flipping enabled, regression is still there, only smaller
> (61->54, instead of 49 FPS).
>
> I want my Nouveau performance back ;)
>
> ---
> From: Marcin Slusarz<marcin.slusarz-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Subject: [PATCH] drm/nv50/gr: make "xfers only in ctxprog" optional
>
> Commit fbba036a56fe0e5c5e8c91daf3fa211f88d94a03
> "drm/nv50/gr: enable ctxprog xfer only when we need it to save power"
> introduced performance regression.
>
> So revert to previous behaviour and add module option (nv50_xfer_ctxprog=0/1)
> to restore it back.
>
> Signed-off-by: Marcin Slusarz<marcin.slusarz-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

Hi,

I'm really sorry about not following up to your many emails you sent me 
in the past.

I now have time to work on this issue and I would like a little more 
information if you don't mind. Could you do a mmiotrace and look at what 
nvidia does in their ctxprog for your specific card ?

If nVidia does the same thing as we do, well, you'll have to wait for 
something I've been thinking for some times now.

What we want is to define power consumption profiles. A simple example 
is, when on battery, you don't want to save as much power as possible 
but when you are on sector, you may want to get the full performance out 
of your card (You may also don't mind the performance loss, but one 
thing at a time).

Ben (darktama) has recently talked about introducing a kind of automatic 
reclocking kind of like what radeon does. That is to say, having 
performance profiles that are switched according to the energy source 
(battery / sector). This automatic behaviour could then be overriden by 
the user, just like radeon.

We would then turn some nobs according to the current performance 
profile. One of these nobs could be xfer on some specific cards (yours).

Would that solution suit you? Clearly, introducing a new kernel 
parameter isn't an acceptable solution to the problem.

I hope we can find a way that would suit both performance and 
battery-life while being kernel-friendly.

Martin (mupuf)