Nouveau - May 2014 - [PATCH] clk: allow config option to enable reclocking

On Fri, May 16, 2014 at 11:17 PM, Ben Skeggs <skeggsb at gmail.com>
wrote:
> On 17 May 2014 02:43, "Ilia Mirkin" <imirkin at
alum.mit.edu> wrote:
>>
>> Adds a NvReclock boolean option to allow the user to enable (or
disable)
>> reclocking. All chipsets default to off, except NVAA/NVAC, which are
>> reportedly complete.
> Hey Ilia,
>
> I think I've expressed my thoughts on this previously via IRC, but let
me
> stick them here too so there's a record of the current state...
>
> For nvaa/nvac, yes, let's enable it by default. It should, apparently,
be
> good enough that it has a decent chance of working.  It's not like
we're
> attempting anything automatic yet, so, this won't break anything for
people
> who aren't trying..
>
> I'm on the fence about Kepler. It actually might work to some extent in
a
> decent number of cases already, there's potentially some severe issues
even
> with engine clocks on some  boards that I'm aware of, so it's not
just a
> memory reclocking worry here.
>
> That said, it has a good chance of working for some people. So. Thoughts?
> I'm also talking making "NvMemExec" default on here too. 
Again, causing a
> fuck-up will still require direct user action.
>
> For the rest (Hm, except maybe nv40, a lot will probably be ok..)
There's
> *very* little chance memory reclocking will work, even on the systems where
> it used to. The code is far less complete, as it was broken in general, and
> I haven't yet had the time to *properly* reverse engineer the sequence
> needed to stably reclock memory.  Kepler is the only implementation where
> that's even been started.  Tl;dr - unless you're working on the
code for
> Tesla/Fermi, there's zero point even trying it. So, the block should
stay.
Meh. It works on my G98, for one of the perf levels. I'm sure there
are lots of tesla's where it totally wouldn't work, but as long as it
works on some of them, why not let people try?
>
> Personally, as you know, I'm more comfortable leaving it developer-only
> still (except nvaa/nvac) until it at least works on all our own boards
> without any major known missing bits..  But yeah, for the ones mentioned
> above, I guess it's a possibility if people *really* want...
I'm of the opposite opinion... if it works on _some_ of our boards, we
should let people play with it. Why lock it away? Unless there's a
real danger of it bricking the card. I've never heard of our code
doing that, and given the way that you were RE'ing this stuff, I doubt
that there's anything we can do (within reason) to brick the card.
>
> I can only envision that if we allow this even just in the places it's
known
> to be partially broken, certain sensationalist, er, people, will feel the
> need to test and complain about how broken it all really is... And then
> retest on a regular basis, despite there having been *zero* work done
> because no-one has the time, and then complain about the exact same thing
> AGAIN! (WHOA.. I'm done ranting now :p)
I would prefer to avoid our decisions being directed by a small number
of loud complaining users, and instead to try to do things that will
serve the real users. Those complaints are only as loud as you think
they are -- you can also think of them as an automated tester that
puts its results into prose. Prior to 3.13, we allowed people to try
reclocking on nv40 and nv50, and I didn't see some huge quantity of
complaints about how it didn't work perfectly. Perhaps you saw those
at first, but I think the expectation by now is that it won't work.
Especially if it's behind a config option.

I have no idea what NvMemExec _really_ is doing, so I left it alone. I
assume that the majority of what my patch enables is actually engine
reclocking, not memory reclocking. So to get both, people would have
to flip both flags? Or is there more to it?

  -ilia

On 17 May 2014 13:39, "Ilia Mirkin" <imirkin at alum.mit.edu>
wrote:
>
> On Fri, May 16, 2014 at 11:17 PM, Ben Skeggs <skeggsb at gmail.com>
wrote:
> > On 17 May 2014 02:43, "Ilia Mirkin" <imirkin at
alum.mit.edu> wrote:
> >>
> >> Adds a NvReclock boolean option to allow the user to enable (or
disable)
> >> reclocking. All chipsets default to off, except NVAA/NVAC, which
are
> >> reportedly complete.
> > Hey Ilia,
> >
> > I think I've expressed my thoughts on this previously via IRC, but
let
me
> > stick them here too so there's a record of the current state...
> >
> > For nvaa/nvac, yes, let's enable it by default. It should,
apparently,
be
> > good enough that it has a decent chance of working.  It's not like
we're
> > attempting anything automatic yet, so, this won't break anything
for
people
> > who aren't trying..
> >
> > I'm on the fence about Kepler. It actually might work to some
extent in
a
> > decent number of cases already, there's potentially some severe
issues
even
> > with engine clocks on some  boards that I'm aware of, so it's
not just a
> > memory reclocking worry here.
> >
> > That said, it has a good chance of working for some people. So.
Thoughts?
> > I'm also talking making "NvMemExec" default on here too.
Again,
causing a
> > fuck-up will still require direct user action.
> >
> > For the rest (Hm, except maybe nv40, a lot will probably be ok..)
There's
> > *very* little chance memory reclocking will work, even on the systems
where
> > it used to. The code is far less complete, as it was broken in
general,
and
> > I haven't yet had the time to *properly* reverse engineer the
sequence
> > needed to stably reclock memory.  Kepler is the only implementation
where
> > that's even been started.  Tl;dr - unless you're working on
the code for
> > Tesla/Fermi, there's zero point even trying it. So, the block
should
stay.
>
> Meh. It works on my G98, for one of the perf levels. I'm sure there
> are lots of tesla's where it totally wouldn't work, but as long as
it
> works on some of them, why not let people try?
Because we don't even *try* to handle timing changes, which, for the vast
majority perflvl changes, will not end well.

This is more than a "mere" bug or slight bit of missing handling.
It's a
*very* important chunk of the process that's simply missing.

This is the difference between the Kepler code. Kepler might work, this
probably will not, unless you're very very lucky.
>
> >
> > Personally, as you know, I'm more comfortable leaving it
developer-only
> > still (except nvaa/nvac) until it at least works on all our own boards
> > without any major known missing bits..  But yeah, for the ones
mentioned
> > above, I guess it's a possibility if people *really* want...
>
> I'm of the opposite opinion... if it works on _some_ of our boards, we
> should let people play with it. Why lock it away? Unless there's a
> real danger of it bricking the card. I've never heard of our code
> doing that, and given the way that you were RE'ing this stuff, I doubt
> that there's anything we can do (within reason) to brick the card.
This is why I'm "Hmm, maybe" on Kepler's code.  Again, the
rest isn't even
expected to work at all yet.  I'm surprised it did for you.. Were the
clocks you chose close to the boot clocks by chance?
>
> >
> > I can only envision that if we allow this even just in the places
it's
known
> > to be partially broken, certain sensationalist, er, people, will feel
the
> > need to test and complain about how broken it all really is... And
then
> > retest on a regular basis, despite there having been *zero* work done
> > because no-one has the time, and then complain about the exact same
thing
> > AGAIN! (WHOA.. I'm done ranting now :p)
>
> I would prefer to avoid our decisions being directed by a small number
> of loud complaining users, and instead to try to do things that will
> serve the real users. Those complaints are only as loud as you think
> they are -- you can also think of them as an automated tester that
> puts its results into prose.
Yes, this was more of a rant than an argument against the idea.

Prior to 3.13, we allowed people to try
> reclocking on nv40 and nv50, and I didn't see some huge quantity of
> complaints about how it didn't work perfectly. Perhaps you saw those
> at first, but I think the expectation by now is that it won't work.
> Especially if it's behind a config option.
Yes, but now, the code is lacking the huge chunk of functionality and
probably won't work.  Nv40 is probably in a similar state to before,
however. So, again with the "maybe" there too.
>
> I have no idea what NvMemExec _really_ is doing, so I left it alone. I
> assume that the majority of what my patch enables is actually engine
> reclocking, not memory reclocking. So to get both, people would have
> to flip both flags? Or is there more to it?
I use it during development to allow independent testing or engine clock
code without the more faulty memory code causing problems. The option
prevents the memory recording scripts from being executed.

Ben.
>
>   -ilia
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20140517/e623893a/attachment.html>

On Fri, May 16, 2014 at 11:54 PM, Ben Skeggs <skeggsb at gmail.com>
wrote:
> On 17 May 2014 13:39, "Ilia Mirkin" <imirkin at
alum.mit.edu> wrote:
>>
>> On Fri, May 16, 2014 at 11:17 PM, Ben Skeggs <skeggsb at
gmail.com> wrote:
>> > On 17 May 2014 02:43, "Ilia Mirkin" <imirkin at
alum.mit.edu> wrote:
>> >>
>> >> Adds a NvReclock boolean option to allow the user to enable
(or
>> >> disable)
>> >> reclocking. All chipsets default to off, except NVAA/NVAC,
which are
>> >> reportedly complete.
>> > Hey Ilia,
>> >
>> > I think I've expressed my thoughts on this previously via IRC,
but let
>> > me
>> > stick them here too so there's a record of the current
state...
>> >
>> > For nvaa/nvac, yes, let's enable it by default. It should,
apparently,
>> > be
>> > good enough that it has a decent chance of working.  It's not
like we're
>> > attempting anything automatic yet, so, this won't break
anything for
>> > people
>> > who aren't trying..
>> >
>> > I'm on the fence about Kepler. It actually might work to some
extent in
>> > a
>> > decent number of cases already, there's potentially some
severe issues
>> > even
>> > with engine clocks on some  boards that I'm aware of, so
it's not just a
>> > memory reclocking worry here.
>> >
>> > That said, it has a good chance of working for some people. So.
>> > Thoughts?
>> > I'm also talking making "NvMemExec" default on here
too.  Again, causing
>> > a
>> > fuck-up will still require direct user action.
>> >
>> > For the rest (Hm, except maybe nv40, a lot will probably be ok..)
>> > There's
>> > *very* little chance memory reclocking will work, even on the
systems
>> > where
>> > it used to. The code is far less complete, as it was broken in
general,
>> > and
>> > I haven't yet had the time to *properly* reverse engineer the
sequence
>> > needed to stably reclock memory.  Kepler is the only
implementation
>> > where
>> > that's even been started.  Tl;dr - unless you're working
on the code for
>> > Tesla/Fermi, there's zero point even trying it. So, the block
should
>> > stay.
>>
>> Meh. It works on my G98, for one of the perf levels. I'm sure there
>> are lots of tesla's where it totally wouldn't work, but as long
as it
>> works on some of them, why not let people try?
> Because we don't even *try* to handle timing changes, which, for the
vast
> majority perflvl changes, will not end well.
>
> This is more than a "mere" bug or slight bit of missing handling.
It's a
> *very* important chunk of the process that's simply missing.
>
> This is the difference between the Kepler code. Kepler might work, this
> probably will not, unless you're very very lucky.
>
>>
>> >
>> > Personally, as you know, I'm more comfortable leaving it
developer-only
>> > still (except nvaa/nvac) until it at least works on all our own
boards
>> > without any major known missing bits..  But yeah, for the ones
mentioned
>> > above, I guess it's a possibility if people *really* want...
>>
>> I'm of the opposite opinion... if it works on _some_ of our boards,
we
>> should let people play with it. Why lock it away? Unless there's a
>> real danger of it bricking the card. I've never heard of our code
>> doing that, and given the way that you were RE'ing this stuff, I
doubt
>> that there's anything we can do (within reason) to brick the card.
> This is why I'm "Hmm, maybe" on Kepler's code.  Again,
the rest isn't even
> expected to work at all yet.  I'm surprised it did for you.. Were the
clocks
> you chose close to the boot clocks by chance?
Yep, they were.
>
>>
>> >
>> > I can only envision that if we allow this even just in the places
it's
>> > known
>> > to be partially broken, certain sensationalist, er, people, will
feel
>> > the
>> > need to test and complain about how broken it all really is... And
then
>> > retest on a regular basis, despite there having been *zero* work
done
>> > because no-one has the time, and then complain about the exact
same
>> > thing
>> > AGAIN! (WHOA.. I'm done ranting now :p)
>>
>> I would prefer to avoid our decisions being directed by a small number
>> of loud complaining users, and instead to try to do things that will
>> serve the real users. Those complaints are only as loud as you think
>> they are -- you can also think of them as an automated tester that
>> puts its results into prose.
> Yes, this was more of a rant than an argument against the idea.
>
> Prior to 3.13, we allowed people to try
>> reclocking on nv40 and nv50, and I didn't see some huge quantity of
>> complaints about how it didn't work perfectly. Perhaps you saw
those
>> at first, but I think the expectation by now is that it won't work.
>> Especially if it's behind a config option.
> Yes, but now, the code is lacking the huge chunk of functionality and
> probably won't work.  Nv40 is probably in a similar state to before,
> however. So, again with the "maybe" there too.
>
>>
>> I have no idea what NvMemExec _really_ is doing, so I left it alone. I
>> assume that the majority of what my patch enables is actually engine
>> reclocking, not memory reclocking. So to get both, people would have
>> to flip both flags? Or is there more to it?
> I use it during development to allow independent testing or engine clock
> code without the more faulty memory code causing problems. The option
> prevents the memory recording scripts from being executed.
OK, so it really should be getting enabled in order for reclocking to
"work". If you're really sure that it won't work for the
majority of
tesla cases --fine. I definitely know that it _used_ to work before
3.13 too, e.g. some ~nva8 user needed to clock it up to get video
decoding engines to be fast enough.

So... fine. Let's do the full enable for nvaa, override-able enable
for nv40, nve0 (including defaulting NvMemExec to on if NvReclock is
set), and leave nv50/nva3/nvc0 alone.

Thoughts?

  -ilia