fix reading of graphics and memory clocks #271
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This pull request is a fix for reading clock frequencies with NVML that was accidentally broken by a previous commit. The interface we have around NVML is a bit tricky, there are many instances of 'clocks', whether they are the current clock used by the GPU, the target clock frequency the user requested, the supported clocks as reported by the GPU, the applications clock, the locked clock, it's easy to make mistakes.
With this fix, the NVML interface remembers what the last clock setting was that the user has set (if any) during this run. When attempting to set the clock, we use this local copy to check if we need to set the clocks given the user requested clock settings.
Reading the clock using the NVML interface, so using nvml.gr_clock or nvml.mem_clock should always return the current clock as observed as it's being used by the device.