Intel komt met Linux-tool voor aanpassen kloksnelheid gpu's

Intel rolt een tool uit waarmee gebruikers die Linux draaien de kloksnelheid van gpu's van de fabrikant kunnen aanpassen. Dat was eerder al mogelijk, maar de nieuwe tool moet het proces vooral gebruiksvriendelijker maken.

De tool heet intel_frequency, zo schrijft Phoronix. Met de tool kan informatie van de Intel HD Graphics-videochips worden gelezen en kunnen frequenties worden ingesteld. Het gaat dan om de huidige, minimale en maximale kloksnelheid. De software zou nog niet aan het Intel GPU Tools-pakket zijn toegevoegd, maar er is wel een patch beschikbaar.

Intel zou de tool geen overklokopties geven en daarnaast zou er geen functionaliteit geïntroduceerd worden die momenteel nog niet beschikbaar is. De tool is vooral gericht op personen die prestatietests willen uitvoeren. Daarnaast kan intel_frequency worden gebruikt voor het controleren op stabiliteits- of andere problemen.

Reacties (25)

cat /sys/class/drm/card0/gt_cur_freq_mhz
laat de huidige frequentie zien. Zo kun je ook de minimale en maximale frequentie al uitlezen.
Het lijkt me vooral een powermanagement-tooltje.

Aan de patch te zien is het een kwestie van schrijven van een int naar bijvoorbeeld /sys/class/drm/card0/gt_min_freq_mhz of /sys/class/drm/card0/gt_max_freq_mhz

De patch ziet er brak uit, er zit weinig sanity checking in en er zal dus vaak geen zinvolle output uit komen als er iets misgaat. De assert()s geven weinig nuttige info aan de eindgebruiker. Dit is meer een proof of concept dan een feature patch.
Ik heb er sowieso mijn bedenkingen over. Je zou net zo goed echo -n "400" > /sys/class/drm/card0/gt_min_freq_mhz kunnen doen, als ik het zo zie.

Edit:
Ik heb er nog eens naar gekeken en denk dat de tool serieuze bugs bevat. Er gebeurt bijvoorbeeld een fopen met rb+, dan een rewind op die file pointer en dan een write dan een getal. Als de nieuwe waarde minder posities bevat dan de oude waarde, gaat het mis.
Als je een huidige waarde van 1150 naar 400 wilt zetten, wordt er 4000 van gemaakt. Of 9050 als je 90 MHz instelt.
Patch dus NIET GEBRUIKEN, het is troep. Nog minder dan een alfa versie. De echo die ik hierboven zette is nog veiliger omdat die de hele waarde schrijft en de oude file negeert. En ook dat zou ik niet zomaar gebruiken.

[Reactie gewijzigd door Anoniem: 26306 op 12 januari 2015 15:57]

Ik heb er nog eens naar gekeken en denk dat de tool serieuze bugs bevat. Er gebeurt bijvoorbeeld een fopen met rb+, dan een rewind op die file pointer en dan een write dan een getal. Als de nieuwe waarde minder posities bevat dan de oude waarde, gaat het mis.
Als je een huidige waarde van 1150 naar 400 wilt zetten, wordt er 4000 van gemaakt. Of 9050 als je 90 MHz instelt.
Patch dus NIET GEBRUIKEN, het is troep. Nog minder dan een alfa versie. De echo die ik hierboven zette is nog veiliger omdat die de hele waarde schrijft en de oude file negeert. En ook dat zou ik niet zomaar gebruiken.

Heb je dit ook geprobeerd en werkelijk zien gebeuren? Vergeet niet dat /sys geen normaal filesystem is maar een speciale interface naar de kernel, net zoals /proc. Wanneer je data naar een file schrijft daar zet je direct informatie in de kernel, je overschrijft niet (deels) de content van een speciale file zoals jij beschrijft. Zodra je write naar die special file klaar is zal alle data die je hebt geschreven de originele data vervangen. Waarschijnlijk zal deze tool dus prima werken, je mag toch hopen dat ze het ook redelijk fatsoenlijk getest hebben voordat ze zoiets releasen.

Je hebt daar een goed punt, ik heb dit niet getest op /sys en het is inderdaad zo dat een dergelijk filesystem zich anders gedraagt dan bijvoorbeeld ext4. Ik zal dat eens nagaan, ik ben eigenlijk ook wel nieuwsgierig naar de exacte implementatie daarvan.

Dat neemt nog niet weg dat er veel te weinig checks in deze code zitten, en dat terwijl het niet meer is dan een tooltje om wat operaties met /sys te doen. Dat kan met een bash, perl of python scriptje ook al prima.

Van een heuse tool verwacht ik heel wat meer, ondanks de disclaimer van de developer. Ik vind dat een slecht excuus. Als je de moeite doet om een tool te maken om mensen die /sys manipuleren te moeilijk vinden te helpen, doe het dan ook goed. Ik sta nog achter mijn opmerking dat deze code een rommeltje is.

Wat Squee schrijft is correct. Elke write sequentie wordt in de kernel apart afgehandeld.
Je kan dus:
[code]
f = open(...)
write(f, "10")
seek(f, 0)
write(f, "1)
seek(f, 0)
write(f,"1000")
[code]
zonder dat er ook maar 1 iets fout gaat.
Die seek is er gewoon om ervoor te zorgen dat, als de file al open was, er geen fouten gebeuren.

Uit de beschrijving die jij geeft kan ik dus geen fouten opmaken.

Intel rolt een tool uit waarmee gebruikers die Linux draaien de kloksnelheid van gpu's van de fabrikant kunnen aanpassen.

Vervolgens:
Intel zou de tool geen overklokopties geven en daarnaast zou er geen functionaliteit geïntroduceerd worden die momenteel nog niet beschikbaar is.

Wat?

Dus wat ga je dan doen met de kloksnelheid? Omlaag brengen? Want ze waren al zo lekker snel...

Stel dat de max. snelheid van die dingen 800mhz is maar ze draaien op 500, dan kun je met deze tool de snelheid dus omhoog draaien van 500 naar 800. Niet kunnen overklokken wil niet meteen zeggen dat het maar een kant op kan nog he.

Voorbeeldje, die van mij (Intel i7-4700MQ) heeft een max snelheid van "1150", maar draait nu op "200", dus daar is zeker nog wat ruimte.

Hoe ik aan die getallen kom? In volgorde:

$ cat /sys/class/drm/card0/gt_max_freq_mhz
"1150"

$ cat /sys/class/drm/card0/gt_cur_freq_mhz
"200"

Maar wat heb je daaraan?

Ik neem aan dat onder Linux de iGPU ook zelf kan bepalen dat als er een grafisch veeleisende toepassing wordt gestart, hij naar zijn maximale frequentie gaat?

Ik neem aan dat onder Linux de iGPU ook zelf kan bepalen dat als er een grafisch veeleisende toepassing wordt gestart, hij naar zijn maximale frequentie gaat?

Ja. Dit is vooral handig voor mensen die een extern scherm aansluiten op een laptop bijvoorbeeld. Ik heb dit probleem, als ik een 2e scherm (via HDMI) aansluit dan word het merkbaar trager, behalve als ik de iGP van ~200mhz naar ~500mhz knal.

Er word door "i965" (de kernel module) niet gedetecteerd dat het 2e scherm ook nog aangestuurd moet worden door dezelfde GPU, en daardoor word de snelheid niet omhoog gegooid zoals wel zou moeten. Of dat een probleem is van mijn specifieke GPU, mijn distro (ubuntu nu) of dat het een issue is van i965 weet ik niet.

Ik denk dat je de kloksnelheden vast kunt zetten op ieder gewenste frequentie, zolang die maar onder de maximale frequentie blijft. Op die manier kan je niet overklokken, maar wel, zoals ze al aangeven, prestatietests uitvoeren en op (stabiliteits-)problemen checken.

Ja, op mijn headless server! scheelt weer stroom!

Powermanagement zoals iemand hierboven al zei.

Zou mooi zijn als ze dat dynamisch kunnen doen!

Hopelijk werkt deze ook met de oude GMA900, die had veel baat bij overklokken namelijk. Helaas zie ik geen lijst met ondersteunde chipsets.

Al zou die er wel bij staan dan vang je nog bot:

Intel zou de tool geen overklokopties geven

Ik denk het niet, aangezien je hier geloof ik ook de Intel kernel modules voor nodig hebt (i965), en die support de GMA900 niet.

Nice, dit gaat zeker gebruikt worden voor madpsu!

Zoals hierboven aangegeven al (zie Anoniem: 26306 in 'nieuws: Intel komt met Linux-tool voor aanpassen kloksnelheid gpu's' en sfranken in 'nieuws: Intel komt met Linux-tool voor aanpassen kloksnelheid gpu's') kun je de clockspeeds van Intel GPU's allang aanpassen zonder deze tool. Snel voorbeeld:

$ echo -n "700" > /sys/class/drm/card0/gt_max_freq_mhz

[Reactie gewijzigd door sfranken op 12 januari 2015 16:02]

Ah, ondersteuning is dus nog níet officieel toegevoegd aan gpu-tools. Dat is vervelend, want onder een aantal verschillende platforms kun je, voornamelijk vanwege crappy DSDTs, niet (betrouwbaar of in sommige gevallen zelfs stabiel) GPU en CPU frequenties veranderen naar iedere beschikbare FID. Dat is wat me momenteel nog tegenhoudt om actieve power limiting te doen onder linux.

Ik kan het hier alleen testen met een i7 4700MQ, maar het "downscalen" van 1150 naar 600 werk hier stabiel en soepel, wel met de klassieke methode zoals beschreven in mijn vorige reactie (dus met echo i.c.m. de gt_max_freq_mhz file in /sys).

Zou liever ondersteuning voor de dev-software Unity3d zien op intel GPU's.
Desalniettemin leuk voor de achtergestelde linux community

[Reactie gewijzigd door eL_Jay op 12 januari 2015 15:27]

Dat is niet aan Intel maar aan de ontwikkelaars achter Unity3d. En op mijn machine draaien Unity3d games prima anders hoor, op een Intel GPU (integrated graphics van de i7 4700MQ)

Heb het over de dev software

offtopic:
Wil heel graag een macbook, maar 2500 voor een discrete gpu vind ik wel erg prijzig en ik ga niet hagelnieuwe hardware kopen met een bejaarde kepler.

Dat is dan helemaal niet aan Intel om dat voor elkaar te krijgen natuurlijk he. You're barking up the wrong tree zoals ze zeggen.

Dacht dat het lag aan de drivers van intel of de manier waarop zij hun GPU gedeelte opbouwen (hardware). Maar het kan inderdaad net zo goed aan laksheid/andere prio's van de crew achter unity3d liggen.

ik draai op Lubuntu met pentium D en FX5200.

maar is goede ontwikkeling dat er ook wat gebruiks vriendelijke dingen komen voor linux.
voor de meeste tweaker zijn alle command codes niet zo makkelijk. maar als je opa of oma hebt dan is da wat moeilijker. hopelijk komt de onderstuining en gebruikts vriendelijkheid ooit op het niveia van microsoft. en dan kunnen we mooi overstappen. mits ook de meeste programma's gescreven worden voor microsoft.

Ben heel benieuwd of AMD zoiets ook heeft.