On Fri, May 16, 2014 at 11:54 PM, Ben Skeggs <skeggsb@xxxxxxxxx> wrote: > On 17 May 2014 13:39, "Ilia Mirkin" <imirkin@xxxxxxxxxxxx> wrote: >> >> On Fri, May 16, 2014 at 11:17 PM, Ben Skeggs <skeggsb@xxxxxxxxx> wrote: >> > On 17 May 2014 02:43, "Ilia Mirkin" <imirkin@xxxxxxxxxxxx> 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
