Nouveau Re-Clocking Details Discussed Further
As a follow-up to yesterday's article about an NvReclock option for the Nouveau driver, the open-source developers have been discussing the specifics behind this on the mailing list.
Friday's Phoronix article covered a patch by frequent Nouveau contributor Ilia Mirkin that would add a NvReclock option to this open-source NVIDIA DRM driver to enable/disable re-clocking support. Re-clocking support is still to be disabled by default except for the NVAA/NVAC chipsets, which are some older NVIDIA chipsets with integrated graphics where the support reportedly works well. This change isn't about any major advancement in re-clocking support, but rather about more easily exposing the experimental option for those that wish to test the feature, etc.
In response to Ilia's patch, Ben Skeggs of Red Hat who serves as the Nouveau DRM maintainer, partially agreed on the work. Skeggs agrees that the NVAA/NVAC re-clocking support can be enabled by default, but he's undecided about the Kepler support. In regards to the latest Kepler re-clocking state, Skeggs wrote, "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 re-clocking on older NVIDIA graphics cards, Ben said, "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. [Too long, didn't read] - unless you're working on the code for Tesla/Fermi, there's zero point even trying it. So, the block should stay."
Ben Skeggs is mostly interested in getting the support in order for their hardware and leaving it as a developer-only feature except for the few lucky chipsets where re-clocking pans out nicely at the moment. For those with older NVIDIA GPUs where the re-clocking once worked (albeit experimental) on older kernels, that support might no longer be in shape with the latest kernel releases. Ben said, "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."
In the end it looks right now like the support will be enabled by default for NVAA/NVAC chipsets, can be enabled via a NvReclock option for NV40 (GeForce 6/7) series and NVE0 Kepler hardware, but other NVIDIA GPUs won't be able to override the disabled state since the code is likely severely broken.
Ben also had a rant, "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)" To which all I can say is that Nouveau tests are done routinely to see the state of things because there's requests from readers quite often who are interested in the driver and want to know where things are at -- I'm honoring their requests and otherwise I get rants from others that I am not doing fair AMD vs. NVIDIA Linux coverage, etc.
Coincidentally, tomorrow I will have out new Nouveau vs. NVIDIA Linux graphics card benchmarks. Look for the latest talked about Nouveau changes to potentially land within the Linux 3.16 kernel while with the upcoming Linux 3.15 release the major Nouveau feature is initial NVIDIA Maxwell support.
Friday's Phoronix article covered a patch by frequent Nouveau contributor Ilia Mirkin that would add a NvReclock option to this open-source NVIDIA DRM driver to enable/disable re-clocking support. Re-clocking support is still to be disabled by default except for the NVAA/NVAC chipsets, which are some older NVIDIA chipsets with integrated graphics where the support reportedly works well. This change isn't about any major advancement in re-clocking support, but rather about more easily exposing the experimental option for those that wish to test the feature, etc.
In response to Ilia's patch, Ben Skeggs of Red Hat who serves as the Nouveau DRM maintainer, partially agreed on the work. Skeggs agrees that the NVAA/NVAC re-clocking support can be enabled by default, but he's undecided about the Kepler support. In regards to the latest Kepler re-clocking state, Skeggs wrote, "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 re-clocking on older NVIDIA graphics cards, Ben said, "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. [Too long, didn't read] - unless you're working on the code for Tesla/Fermi, there's zero point even trying it. So, the block should stay."
Ben Skeggs is mostly interested in getting the support in order for their hardware and leaving it as a developer-only feature except for the few lucky chipsets where re-clocking pans out nicely at the moment. For those with older NVIDIA GPUs where the re-clocking once worked (albeit experimental) on older kernels, that support might no longer be in shape with the latest kernel releases. Ben said, "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."
In the end it looks right now like the support will be enabled by default for NVAA/NVAC chipsets, can be enabled via a NvReclock option for NV40 (GeForce 6/7) series and NVE0 Kepler hardware, but other NVIDIA GPUs won't be able to override the disabled state since the code is likely severely broken.
Ben also had a rant, "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)" To which all I can say is that Nouveau tests are done routinely to see the state of things because there's requests from readers quite often who are interested in the driver and want to know where things are at -- I'm honoring their requests and otherwise I get rants from others that I am not doing fair AMD vs. NVIDIA Linux coverage, etc.
Coincidentally, tomorrow I will have out new Nouveau vs. NVIDIA Linux graphics card benchmarks. Look for the latest talked about Nouveau changes to potentially land within the Linux 3.16 kernel while with the upcoming Linux 3.15 release the major Nouveau feature is initial NVIDIA Maxwell support.
Add A Comment