Option "Coolbits" is not used | Optimus-enabled laptop running an RTX 2070 | Manjaro Linux

No problem, thanks for clearing it up! I ended up switching to nvidia-only from my bios to check and there’s not a lot I can do on my laptop even with Coolbit set. So no point for me to pursue this course further. Thanks anyways!

1 Like

Exactly. Coolbits doesn’t work in offload mode but it’s pointless on notebook gpus anyway because those are locked by the vendor most if not all times.

Coolbits on notebook GPUs is not pointless. For instance, I have an old notebook where I can apply an offset of 398 MHz on memory clock and 200 MHz on graphics clock. I would not call that pointless. Please, avoid making such statements that could lead people (specially NVIDIA employees) to ignore the actual problem. I see no technical reason for Coolbits to not work with PRIME Render Offload. Yes, the option is currently tied to an X screen, but why should it be? If I revert to a setup with NVIDIA’s card only (old PRIME setup), I can set Coolbits. It is a software limitation, and the patch previously posted here is a proof that it is indeed possible to fix it. Will NVIDIA do it? That is the question that remains unanswered.

2 Likes

I need this feature as well. It seems the issue to be simple enough for NVIDIA to fix. So why aren’t they doing something about it? Why put your customers thru the misery of manually having to patch a binary?

I filed internal bug request 3188001 to track adding a way to do this without using sketchy-looking binary patches of dubious origin. :)

The bug tracker is not public but you can refer to this number in the future to make it easier for us to look it up.

3 Likes

In the meantime, I found a cleaner way of overclocking without sacrificing the use of NVDIA’s PRIME Render Offload. It consists of:

  1. launch Xorg with normal PRIME;
  2. assign the desired clock offsets through nvidia-settings;
  3. close the current Xorg session;
  4. relaunch Xorg with PRIME Render Offload.

The key idea is that the clock offsets are not lost between Xorg sessions. In step 4 you will not be able to change the offsets, but they will still have the same values you assigned in step 2.

I created a simple script to automate two calls of startx. The first call only executes nvidia-settings to assign the offsets and subsequently closes. The second call properly starts the window manager. Some changes in .xinitrc are also required, as well as a symbolic link in /etc/X11/xorg.conf.d/ to the proper configuration file for each startx call. I have no idea how to achieve the same level of automation using a login manager (sorry).

If anyone is interested, I can share my scripts here.

1 Like

I would like to see your scripts. I have made some before and it worked on a Debian-based distro, but does not with Manjaro. Maybe I would be able to use yours… Mine was quite weird - on boot, a systemd service. A script starts that changes tty to tty7 (some systemd way), and there changes xorg config (file copy), starts X, runs prime-offload, runs GWE app (that applies the OC), sleeps for a bit, kills the session and then switches back to tty1 plus reverts xorg.conf. That was spaced out between 5 bash scripts because of my noobish bash skills (basically wouldn’t work otherwise). I bet your implementation is cleanier.

Btw, I am able to apply +400mhz memory offset and +200mhz graphics offset without a hitch. These high memory offsets manage to overpower my laptops charger, so while the laptop is mining (both CPU and GPU), it has to draw up to ~1A (~15W) from battery, which is a bit sketchy, but fun to see. Because of repasting (and CPU undervolt) it manages a very good sustained load.
I always use prime render offload, AND overclock. But it is unnecessarily complicated, as you say.
To be fair, graphics OC makes significant difference in gaming. Memory offsets increase hashes quite well, but I only turn on miners when it is cold at my dorm (heaters are not permitted, so a bit of a workaround). And prime render offload then is the only way to have a smooth desktop experience.

Alright, here we go: nvidia-startx-oc.zip (4.1 KB)
I zipped all required files and included a README with instructions of how to use them. If you have any questions or problems, feel free to contact me (although I can not guarantee I will be able to help). It is a very basic script, you may need to add more options to match your needs.

I’ve never seen my laptop draw energy from both, charger and battery. That is a bit weird. You changed the power limit or overvolted the gpu?
I did not stress my system too much beyond gaming, perhaps on a heavier, sustained workload it also would show this peculiar behavior. Well, I hope my 120W power supply has enough headroom to overclock without this… trick?
And nice workaround to the heaters prohibition. XD

1 Like

Thats a perfect script, the only big change is going to be the last command in shell script. Instead of “startx” it’ll be “systemctl start sddm”. Though considering that most often use-case is a single-user system, startx makes a lot of sense.

About the power draw – I believe the GTX1050 in my laptop is underclocked a bit:
By default it shows max graphics frequency of ~1950mhz, but it only ever reaches ~1750mhz. So I overclock it by 200mhz and then it shows max frequency of ~2150mhz, while actually maxing out at ~1950mhz.
No overvolting or powerlimit changes. The power draw outpaces the charger when fiddling with memory frequency going from ~3500/7000 to ~3700/7400. For some reason the GPU gets really hungry. I guess it increases voltage automatically (maybe the default memory frequency is also higher?).

The charger is 135W, btw :D
It was fun to watch, but I am not sure the laptop is happy with this above-design power consumption. I doubt GPU would kick off (die), but I am less confident of “suporting” circuitry (MOSFETs, etc).

To be honest, I love abusing electronics, but I’ll take some caution with the laptop.
I also have a PC with GT430, and the fermi GPU is too old for mining (just to get the idea how old the PC is). CPU is good enough, though it has no AES acceleration.
A bit of fiddling with fancontrol and I have a second, silent heater. The PSU cable connectors to the CPU are a bit toast, so there are some stability issues on sustained load.
It also makes some vruum vruum sounds when restarting fancontrol service (as OS loses fan control momentarily).

PS.: Thank you for the script and the extensive documentation.

1 Like

+1
On my Razer Blade 15 Advanced (2080 Super MaxQ) I’d like to stay with Hybrid graphic mode on PopOS and using Coolbits options if possible.
Currently running 460.32.03 on PopOs! 20.10

Any news about this bug?

2 Likes

Hello, any news about this bug request? It would be really cool to use the CoolBits option without needing to start a separate Xorg server.

Any news about that bug request?

I tried to apply the same workaround posted earlier (by whitequark) for the driver version 455.45 and it’s been working well for me.

Original 455.45 driver sha1sum: 8a6d257829fab0266508df64b776a066763e04d4

Then follow the same instructions as the original post, except changing the offsets:

  • at offset 47F20, replace 6 bytes with B801000000C3,
  • at offset 47FFB, replace 2 bytes with 9090,
  • at offset 48036, replace 10 bytes with B8010000004883C408C3,
  • at offset 4CF08, replace 1 byte with EB.

Patched driver sha1sum: dd6000cd0ac41019bbe322a1fc0ce18331b4fa43

The drivers version 460 and higher have different assembly and I’m not confident in trying to patch those. I was hoping the changes in those versions had the purpose of fixing this bug and verify before upgrading.

Disclaimer: Use at your own risk. I did not do my best to verify if further changes were needed compared to the earlier instructions - which also warns to patch the driver at your own risk.

Hello @aplattner! Any news about the bug request 3188001?
Or do we still need to buy expensive hardware just to need to manually debug and patch the binary driver before using it?

Fix should be available in future driver release, I will update once respective driver is released publicly.

3 Likes

Hello @aplattner! Any news about the bug request 3188001?
I imagine it was not possible for the 470 series, maybe 475 then?

Hi @pedro.nariyoshi, while it is still not possible to set Coolbits on GPU Screens on 470, the fan control is possible with 470+ even without Coolbits. From https://forums.developer.nvidia.com/t/linux-solaris-and-freebsd-driver-470-42-01-beta/181536:

Updated GPU fan control to be available by default in nvidia-settings and NV-CONTROL, for GPU boards that support programmable fan control. Previously, this was only available when bit 2 was set in the “Coolbits” X config option.

Too bad my machine has a single fan, so it doesn’t really help me, but at least it is a step in the right direction. (;