Green Curve - open source curve undervolting und overclocking

[aufkrawall]

Habe gebastelt:
https://github.com/aufkrawall/green-curve

Braucht keine anderen Tools, komplett open-source und Curve-Lock durch Setzen eines Hakens. Übernimmt hier jetzt UV und Lüftersteuerung.

[Cubitus]

Hab mir den Source angeschaut, saubere und tolle Arbeit. Besonders die Verify-Logik mit Batch + Fallback und Correction Passes ist super durchdacht. Du hast quasi gezeigt dass es doch geht, Hut ab und eine Verbeugung vor dieser Leistung :)

Hast du das auch auf anderen Blackwell-Modellen außer der 5070 getestet? Du hast ja den --probe Modus eingebaut, falls hier jemand mit einer 5070 Ti, 5080 oder 5090 Lust hat das kurz laufen zu lassen und das Log zu posten, wäre das spannend zu sehen. :)

Würds selber gerne testen, bin allerdings noch im Urlaub..

[aufkrawall]

Danke, Credits gehen ans LLM. ;)
Die eigentliche Arbeit ist natürlich immer die Feinarbeit, also etwa das Zusammenspiel von globalem Offset, Curve und GUI. Konnte noch nicht viel auf anderen GPUs testen, aber das Feedback bei Guru3D ist soweit schon mal positiv.
Hatte gar nicht selbst mit CLI rumhantiert. Das hatte für die frühe Phase das LLM (da noch MiMo-V2-Pro) agentisch alles in OpenCode selbst gemacht, bis die Kurve richtig ausgelesen und im GUI angezeigt wurde. Das hatte so ca. 20 Minuten nach Bestätigung des kurzen Stichpunkte-Plans gedauert. Das Polishing und Debugging mit GPT-5.4 dann leider diverse Stunden...

[Cubitus]

Haha, schön zu hören dass auch ein LLM im Spiel war :)
Kenne das Polishing und Debugging nur zu gut, das frisst immer die meiste Zeit...

Gut zu wissen dass das Guru3D Feedback positiv ist.
Wenn das auf mehreren Modellen stabil läuft, was ich jetzt mal annehme, weil wenn du das machst hat es Hand und Fuß, ist das ein ziemlicher Durchbruch für die Community. :)

[aufkrawall]

Danke. :love:
Etwas Feinschliff bei bestimmten, weniger attraktiven Offset + Curve-Kombinationen wird noch nötig sein, + 1-2 andere Fixes für die Profilverwaltung.

[Cubitus]

Hey :)

Also NVAPI Bridge auf RTX 5090 getestet, funktioniert, VF_SET_CONTROL Reads + Writes verifiziert.

Danke für Green Curve, ohne die IDs hätte ich das nicht gehabt. :umassa:

Spannend ist: Von .NET aus kommt ret=-137, aber eine native C++ DLL als Bridge geht durch. Treiber prüft wohl den Caller-Typ, ob das bewusst Anti-Tamper ist oder einfach so funktioniert, wer weiß. :freak:
Ich erwähne Green Curve + GitHub-Link direkt in meinen Release Notes (Build 22 · Cantor). Dein Tool soll auch die verdiente Aufmerksamkeit bekommen, elegant, schlank, und für jeden der direktes Kurven-Editing mit Profilen will, genau das Richtige.

NV-UV fährt jetzt zweigleisig, AB bleibt für Profil-Persistence, NVAPI über die Bridge für Scanner und Stock-Kurve lesen.

Ich feier es richtig :tongue:

[aufkrawall]

Cool, danke für die Erwähnung und den netten Umgang. :)
Hoffe, dass es auf anderen Systemen erwartbar funktioniert. Hatte gestern noch ein paar Verbesserungen vorgenommen:
https://github.com/aufkrawall/green-curve/releases/tag/0.5

Nächste Baustelle ist dann Probing, was unter Linux geht oder nicht geht. Gibt da offenbar leider nicht NVAPI wie unter Windows, oder zumindest nicht in der Form.

[Cubitus]

Zum Thema Linux hab ich bei früheren Recherchen ein paar interessante Sachen gefunden, vielleicht ist was Neues für dich dabei :)

NVML Locked Clocks funktionieren auf Blackwell.
Es gibt z. B. ein Rust-Tool namens nvoc, das auf einer RTX 5090 mit Treiber 580.82 läuft und nvmlDeviceSetGpuLockedClocks sowie nvmlDeviceSetGpcClkVfOffset nutzt.
Auch LACT macht im Prinzip das gleiche über NVML für Power, Clock und Fan. Der Haken ist halt: NVML kann nur Lock + globalen Offset, keine Kontrolle über einzelne Punkte der VF-Kurve. Für einen simplen V-Lock Modus reicht das.

Für Punkte brauchst du die direkten NVAPI Calls (deine VF_SET_CONTROL IDs), und die laufen über die native nvapi64.dll, gibt es die unter Linux, ich glaub nicht?

Theoretisch könnte man versuchen, das über einen Wrapper auf Basis des proprietären NVIDIA-Treibers zu lösen :uponder:
Vielleicht ein Ansatz? NVML für die Basics (Lock, Offset, Telemetrie) und parallel schauen, ob man irgendwie an die undokumentierten NVAPI Calls über libnvidia-api.so rankommt. :uponder:
Ist aber bisher nur Theorie, hab ich selbst nicht weiter verfolgt.

Hier noch der PCGH-Link zum NV-UV Subforum, falls du reinschauen willst :)
https://extreme.pcgameshardware.de/forums/nv-uv.3601/

Den Cantor Preview Post hab ich auch bei mir im Discord geteilt, da sind aktuell ~90 Leute, die sich für das Thema interessieren. :)

Vielleicht kurz zur Obfuscation bei NV-UV damit Klarheit herrscht, falls es jemand wundert warum ich nicht ganz OpenSource gehe.

Ich hab Teile vom Code geschützt, aber nicht aus Eigennutzen.
Da stecken halt einfach Erkenntnisse drin, gerade aus dem Scanner und der Kurvenlogik an denen auch Tools und Leute hängen, die damit Geld verdienen
(z. B. Unwinder mit Afterburner, die ganzen VF-Kurven-Formeln oder Erkenntnisse von diversen Scanner-Tools usw)
Da steckt ne Menge "ehrlicher" Arbeit drin

Ich selbst will mit NV-UV kein Geld verdienen, das Ding bleibt free. Mir geht’s eher um Interesse und Spaß.
Aber ich will halt auch nicht der sein, der anderen unnötig ins Geschäft fährt, indem alles komplett offen ist.

Deinen Ansatz mit MIT-Lizenz und Open Source für Green Curve finde ich absolut richtig, dass ist einfach eine andere Ausgangssituation.

Die NVAPI IDs gehören eh NVIDIA, klar. Und wenn sowas offen zugänglich ist, profitiert am Ende die ganze Enthusiasten-Community davon.

Ohne uns Freaks wäre NVIDIA heute auch nicht da, wo sie sind,
ein bisschen Spaß dürfen sie uns ruhig noch lassen :D

[Gast]

Jetzt ohne geschaut zu haben, wie geht das Tool um mit Veränderung des Taktes bei Temperaturunterschieden?
Bei AB ist es bei mir so dass ich die Kurve für alle paar Grad "gradebiegen" muss damit es nicht über die davor gesetzte Spannung hinausschießt, macht man natürlich nur einmal und das Profil kann man ja auch am Ende einfach kopieren und jederzeit neu nutzen, aber dennoch.

[aufkrawall]

Zum Thema Linux hab ich bei früheren Recherchen ein paar interessante Sachen gefunden, vielleicht ist was Neues für dich dabei :)

NVML Locked Clocks funktionieren auf Blackwell.
Es gibt z. B. ein Rust-Tool namens nvoc, das auf einer RTX 5090 mit Treiber 580.82 läuft und nvmlDeviceSetGpuLockedClocks sowie nvmlDeviceSetGpcClkVfOffset nutzt.
Auch LACT macht im Prinzip das gleiche über NVML für Power, Clock und Fan. Der Haken ist halt: NVML kann nur Lock + globalen Offset, keine Kontrolle über einzelne Punkte der VF-Kurve. Für einen simplen V-Lock Modus reicht das.

Für Punkte brauchst du die direkten NVAPI Calls (deine VF_SET_CONTROL IDs), und die laufen über die native nvapi64.dll, gibt es die unter Linux, ich glaub nicht?

Theoretisch könnte man versuchen, das über einen Wrapper auf Basis des proprietären NVIDIA-Treibers zu lösen :uponder:
Vielleicht ein Ansatz? NVML für die Basics (Lock, Offset, Telemetrie) und parallel schauen, ob man irgendwie an die undokumentierten NVAPI Calls über libnvidia-api.so rankommt. :uponder:
Ist aber bisher nur Theorie, hab ich selbst nicht weiter verfolgt.

Danke, werd ich mal im Hinterkopf behalten.


Deinen Ansatz mit MIT-Lizenz und Open Source für Green Curve finde ich absolut richtig, dass ist einfach eine andere Ausgangssituation.

Ja, das hat sich das LLM mit Trial & Error komplett selbst erschlossen. Von meiner Seite gab es nur etwas Steering, was ein gewünschtes oder unerwünschtes Ergebnis war, plus Debugging.
Kein Reverse Engineering und kein Spionieren, was andere Prozesse machen etc.


Jetzt ohne geschaut zu haben, wie geht das Tool um mit Veränderung des Taktes bei Temperaturunterschieden?
Bei AB ist es bei mir so dass ich die Kurve für alle paar Grad "gradebiegen" muss damit es nicht über die davor gesetzte Spannung hinausschießt, macht man natürlich nur einmal und das Profil kann man ja auch am Ende einfach kopieren und jederzeit neu nutzen, aber dennoch.
Das ist das Verhalten der Boost-Kurve im Treiber oder Firmware, dagegen kann so ein Tool nichts (sauber) machen.
Die potenziellen fps-Unterschiede in Prozent dadurch können einen aber ruhig schlafen lassen.

[Platos]

Frage: Mit dem Tool kann man vermutlich nicht weiter untervolten wie mit dem msi afterburner oder ? Also speziell niedrigere Spannung fixieren können geht damit nicht oder ?

[aufkrawall]

Frage: Mit dem Tool kann man vermutlich nicht weiter untervolten wie mit dem msi afterburner oder ? Also speziell niedrigere Spannung fixieren können geht damit nicht oder ?
Geht nur bis maximal 875mV, ohne dass obere Teile der Kurve nicht mehr richtig angepasst werden. Habe es gerade versucht zu verbessern, ohne Erfolg. Offenbar ebenfalls ein unumstößliches Limit der API:
It’s mostly not a hard “870 mV is forbidden” API floor. In your log, the 870 mV point already got flattened to 2122 MHz, and the tail stays flat through 1190 mV. The failure starts at 1195 mV, where the curve lands at 2130 MHz because hitting 2122 MHz there would
need about -1008 MHz of curve delta, while the driver on this card reports only -1000..1000 MHz. So the pattern you saw — lower lock target => fewer higher-voltage points can follow — is exactly what a max negative offset limit looks like.

I implemented the safe improvement: Green Curve no longer hard-codes ±1000 MHz for VF-curve deltas. It now uses the best driver-reported curve range from NvAPI Pstates20, with NVML/global graphics range as fallback, and the error reporting now says explicitly when a
lock fails because it needs more offset than the supported range. So if a GPU/driver exposes more than -1000 MHz, the app can now use it automatically. On your current RTX 5070 log, though, I’d still expect full-tail locks at 800 mV to fail unless NVIDIA exposes a
wider range, because this board/driver is already showing a real -1000 MHz limit.

Bzw. es geht schon niedriger, aber du musst entsprechend um so mehr Takt drauflegen, je niedriger du gehst, was natürlich schneller instabil wird. 850mv 2,17GHz etwa gehen (falls noch stabil) bzw. sind laut API zulässig.

[MadManniMan]

Für die 4000er-Serie wird's keine Variante geben (können), oder?

Unabhängig davon: Postet mal Ergebnisse!

[aufkrawall]

Für die 4000er-Serie wird's keine Variante geben (können), oder?

Kann gut sein, dass es einfach läuft.


Unabhängig davon: Postet mal Ergebnisse!
Da es keine anderen Parameter als andere Tools wie Afterburner setzt, sind hier keine neuen Erkenntnisse zu erwarten.

[Platos]

Geht nur bis maximal 875mV, ohne dass obere Teile der Kurve nicht mehr richtig angepasst werden. Habe es gerade versucht zu verbessern, ohne Erfolg. Offenbar ebenfalls ein unumstößliches Limit der API:


Bzw. es geht schon niedriger, aber du musst entsprechend um so mehr Takt drauflegen, je niedriger du gehst, was natürlich schneller instabil wird. 850mv 2,17GHz etwa gehen (falls noch stabil) bzw. sind laut API zulässig.

Schade, aber war klar, dass nvidia da den Riegel vorschiebt.

Aber was ich nicht ganz verstehe: Warum muss ich den Takt erhöhen, damit ich eine niedrigere Spannung nutzen kann (also jetzt bei z.B 850mV)? Wie du ja sagst, wäre ja das dann sogar eher instabiler. Woher dieser Zusammenhang ?

800mV sollte aber glaube ich gehen (je nach Karte). Im Afterburner gehts bei mir aber auch nicht bis 800mV unter Last. Nur im Idle. Aber drunter wirds wohl (leider) wirklich nicht gehen. Ich glaube bei Ampere gings noch ziemlich weit runter. Da konnte man nochmals richtig an Effizienz gewinnen.

[Gast]

Schade, aber war klar, dass nvidia da den Riegel vorschiebt.

Aber was ich nicht ganz verstehe: Warum muss ich den Takt erhöhen, damit ich eine niedrigere Spannung nutzen kann (also jetzt bei z.B 850mV)? Wie du ja sagst, wäre ja das dann sogar eher instabiler. Woher dieser Zusammenhang ?

800mV sollte aber glaube ich gehen (je nach Karte). Im Afterburner gehts bei mir aber auch nicht bis 800mV unter Last. Nur im Idle. Aber drunter wirds wohl (leider) wirklich nicht gehen. Ich glaube bei Ampere gings noch ziemlich weit runter. Da konnte man nochmals richtig an Effizienz gewinnen.
Wenn man den Spannungspunkt locked dann gehen auch 800mV (getestet mit 5090), das Problem ist aber eben das selbst wenn ich die maximalen +1000MHz drauf mache der Takt zu gering ist bei mir (~1,5GHz), damit sinkt die Performance auf etwa 60-65% vs 900mV @ 2,85GHz, der Verbrauch sinkt aber auch auf ~55%. Dieses Takt Limitierung ist schon mies.

[Cubitus]

Aber was ich nicht ganz verstehe: Warum muss ich den Takt erhöhen, damit ich eine niedrigere Spannung nutzen kann (also jetzt bei z.B 850mV)? Wie du ja sagst, wäre ja das dann sogar eher instabiler. Woher dieser Zusammenhang ?

Ist im Grunde der Kern-Mechanismus, warum Undervolting überhaupt funktioniert. Die VF-Kurve hat für jeden Spannungspunkt eine Stock-Frequenz. Die GPU boosted normalerweise die Kurve hoch bis zur höchsten Spannung. Um sie bei einer niedrigeren Spannung "einzufangen", musst du an deinem gewünschten Spannungspunkt den Takt per Offset anheben und die Kurve ab dort flach machen, der Treiber nimmt dann den höchsten Punkt der Kurve als Boost-Limit und lockt die GPU dort.

Du erhöhst den Takt also nicht weil du mehr Speed willst, sondern um der GPU einen Lock-Punkt zu setzen. Das ist der "Trick" dabei, der höhere Offset ist das Werkzeug, nicht das Ziel.
Die GPU läuft dann bei niedrigerer Spannung auf einem Takt, der in der Praxis oft sogar höher ist als Stock, weil der Offset den Basis-Takt anhebt.

Konkretes Beispiel: Bei einer RTX 5090 liegt die Stock-Frequenz bei 850mV irgendwo bei ~2400 MHz. Bei der höchsten Spannung (975mV) liegt sie bei ~2850 MHz. Wenn du jetzt bei 850mV einfach nichts änderst, boosted die GPU fröhlich weiter bis 975mV weil dort der höchste Takt ist.
Setzt du aber bei 850mV einen Offset von +600 MHz, landest du bei ~3000 MHz, das ist höher als alles darüber auf der Kurve. Die GPU denkt: "Warum soll ich weiter hochklettern? Bei 850mV bin ich schon am schnellsten." Und lockt dort. Ergebnis: ~3000 MHz bei 850mV statt ~2850 MHz bei 975mV

Gehst du z.B noch weiter runter, z.B. auf 800mV, brauchst du deutlich mehr Offset (+600, +800 MHz), damit der Punkt noch über der restlichen Kurve liegt.
Die eingetragene Frequenz wird dann zur "Fantasy-Frequenz" , die GPU erreicht die unter Last nie wirklich.
Aber dem Treiber reicht es als Signal: Dieser Spannungspunkt ist der beste, hier bleiben wir. Der tatsächliche Takt liegt dann je nach Power-Limit und Temperatur deutlich darunter.

Bzgl Treiber-Limit:
Standard Blackwell-Karten haben in der Regel +1000 MHz Offset-Limit. Die Lightning, Matrix können ~1150 MHz, zumindest meine Beobachtungen, da ich Tester mit Lightning und Matrix Karten hatte.
Ob der Treiber bei höhren mV-Stufen nochmal etwas mehr Offset zulässt, ist eventuell möglich, da bräuchte es aber mehr Daten.