Closed Boria138 closed 1 month ago
@Boria138 you can pass that on the command line:
envycontrol -s hybrid --rtd3 1 ...
I am not sure this is an ideal solution. Obviously, someone needed the default of 2.
For example, my laptop has an Ampere chip where 3 might be a better default.
@bayasdev what do you think about introducing an environment variable - something like ENVYCONTROL_OPTS - that would allow the user to customize the defaults for the command line options?
I.e., the contents of that env var would be concatenated to sys.argv so as to override any defaults. Note that parser.parse_args takes an optional first argument as the list of str's to process. It uses sys.argv if called with no args.
So we could do something like (pseudo-code):
args = [*sys.argv, *ENV_VAR.split()]
parser.parse_args(args)
The user would just arrange for the env var to be set before calling envycontrol.
This is a some what common technique used by things like: BASHOPTS FZF_TMUX_OPTS RESOLV_OPTS SAMBAOPTIONS SHELLOPTS UNBOUND_OPTIONS etc.
@Boria138 you can pass that on the command line:
envycontrol -s hybrid --rtd3 1 ...
I am not sure this is an ideal solution. Obviously, someone needed the default of 2.
For example, my laptop has an Ampere chip where 3 might be a better default.
@bayasdev what do you think about introducing an environment variable - something like ENVYCONTROL_OPTS - that would allow the user to customize the defaults for the command line options?
I.e., the contents of that env var would be concatenated to sys.argv so as to override any defaults.
Note that parser.parse_args takes an optional first argument as the list of str's to process. It uses sys.argv if called with no args.
So we could do something like (pseudo-code):
args = [*sys.argv, *ENV_VAR.split()] parser.parse_args(args)
The user would just arrange for the env var to be set before calling envycontrol.
This is a some what common technique used by things like:
BASHOPTS
FZF_TMUX_OPTS
RESOLV_OPTS
SAMBAOPTIONS
SHELLOPTS
UNBOUND_OPTIONS
etc.
Or you can just set an alias like switch-hybrid
, with an env variable you still have to modify you .zshrc
or /etc/profile
unless you want to put MY_ENV=something mycommand
This is true if executing from the command line. And both GUI extensions allow customizing the options.
@Boria138 why do you need to change this default? What are you running into that precludes you from passing --rtd3 1
on the command line?
This is true if executing from the command line. And both GUI extensions allow customizing the options.
Yup, I set the default RTD3 value to 2 as many distros do (Manjaro and Ubuntu IIRC).
But you're right that 3 is the recommended value for Ampere and newer GPUs, however you can always customize the parameters to your needs ;)
PD: Personally, I use fzf along with oh-my-zsh to search across all my command history and pick the one that I need.
This is true if executing from the command line. And both GUI extensions allow customizing the options.
Yup, I set the default RTD3 value to 2 as many distros do (Manjaro and Ubuntu IIRC).
But you're right that 3 is the recommended value for Ampere and newer GPUs, however you can always customize the parameters to your needs ;)
PD: Personally, I use fzf along with oh-my-zsh to search across all my command history and pick the one that I need.
It turns out that one is the optimal value for Turing, and three for Ampere and Ada Lovelace, probably it should be written somewhere, because it is not known to everyone
This is true if executing from the command line. And both GUI extensions allow customizing the options.
Yup, I set the default RTD3 value to 2 as many distros do (Manjaro and Ubuntu IIRC).
But you're right that 3 is the recommended value for Ampere and newer GPUs, however you can always customize the parameters to your needs ;)
PD: Personally, I use fzf along with oh-my-zsh to search across all my command history and pick the one that I need.
It turns out that one is the optimal value for Turing, and three for Ampere and Ada Lovelace, probably it should be written somewhere, because it is not known to everyone
@Boria138 do you have the source so we can link it on the README? As well you can directly edit it and push it to this branch, that would help a lot.
@bayasdev these values are documented in the README: RTD3 allows the dGPU to be dynamically turned off when not in use
Available choices for the --rtd3 flag (based on the [official documentation](http://us.download.nvidia.com/XFree86/Linux-x86_64/530.30.02/README/dynamicpowermanagement.html))
0 disabled
1 coarse-grained
2 fine-grained (default value if you don't provide one)
3 fine-grained for Ampere and later
Only works in Turing and later
And there is a link to the official docs ...
OH! And I am fine passing --rtd3 3 from the command line when I might need to do that (I might need 3 to use HDMI - haven't tried.). I was passing 1 when testing hybrid.
@bayasdev these values are documented in the README: RTD3 allows the dGPU to be dynamically turned off when not in use
Available choices for the --rtd3 flag (based on the [official documentation](http://us.download.nvidia.com/XFree86/Linux-x86_64/530.30.02/README/dynamicpowermanagement.html)) 0 disabled 1 coarse-grained 2 fine-grained (default value if you don't provide one) 3 fine-grained for Ampere and later Only works in Turing and later
And there is a link to the official docs ...
I'm reading the latest docs and it says
Driver Settings This feature is enabled by default on supported Ampere or newer notebook computers. In all other configurations, it is disabled by default.
It can be enabled or disabled via the NVreg_DynamicPowerManagement nvidia.ko kernel module parameter.
It also mentions
Option "NVreg_DynamicPowerManagement=0x03" This is the default setting.
For Ampere or later notebooks with supported configurations, this value translates to fine-grained power control. For pre-Ampere notebooks, this value disables runtime D3 power management features. For desktop computers, irrespective of the GPU(s) used, this value disables runtime D3 power management features.
Following that logic the default should be 3 but then someone with a Turing GPU would say that RTD3 flag does nothing.
@bayasdev
Following that logic the default should be 3 but then someone with a Turing GPU would say that RTD3 flag does nothing.
The default is fine for me. I like to explicitly pass things like this explicitly. So, I wouild never rely on the envyvcontrol CLI opt default value. Just the way I am ...
Too many years getting bit by default values in config files.
The last serious issue was a project I did with the FIX protocol. Our initial implementation relied on "our understanding" - which was faulty it turns out - about client config defaults. We broke the FIX server as a result.
To resolve it we got a team of people together and analyzed every option and set our own values explicitly.
The sting of that defect is still fresh ... (sigh).
See https://github.com/openSUSE/SUSEPrime/issues/52