GPU niet op 100%: hoe je een CPU-flessenhals van iets anders onderscheidt

Je overlay zegt dat de videokaart op 60% zit en je framerate is lager dan je had verwacht. Iemand zegt dat het een CPU-flessenhals is, en je begint over processors te lezen.

Misschien. Maar "GPU onder 100%" heeft minstens acht verklaringen, de meeste kosten niets om te controleren, en een echte CPU-limiet is er maar één van. Deze pagina sluit ze één voor één uit.

Eerst: wat dat percentage werkelijk is

GPU-gebruik is het aandeel van de tijd dat de GPU werk onderhanden had — niet hoe hard hij werkte. Een kaart die een triviale belasting met gemak afwerkt kan 100% aangeven omdat er altijd iets in de wachtrij stond, en een kaart die alles doet wat er van hem gevraagd wordt kan 60% aangeven omdat de wachtrij steeds leegliep. Een eerste aanwijzing en niets meer: op zichzelf kan het je niet vertellen waar de GPU op wachtte.

Het experiment dat het in twee minuten beslist

Doe dit voordat je iets anders doet, want het kost niets en het beslist.

1. Noteer je framerate in een herhaalbare scène.
2. Verlaag de resolutie fors — niet één stapje, een grote stap.
3. Meet dezelfde scène opnieuw.

Beweegt de framerate nauwelijks, dan was de GPU niet je limiet. Je hebt het grootste deel van zijn werk weggenomen en er niets voor teruggekregen, dus iets anders bepaalde het tempo.

Stijgt de framerate ongeveer evenredig, dan zat je toch tegen de GPU aan en misleidde het gebruikspercentage je.

Dat is de hele diagnose, en er is geen gereedschap voor nodig. Alles hieronder bepaalt wát dat andere dan is.

De goedkope verklaringen, op volgorde

1. Je zit aan een limiet

Is het getal waar je op uitkomt precies je verversingsfrequentie, je framelimiet in de game, een limiet van de driver of de automatische limiet van een latencyfunctie, dan zit er nergens een flessenhals — de GPU staat stil omdat je hem hebt gezegd te stoppen. Een loos alarm, en in tien seconden uit te sluiten.

2. De kaart wordt tegengehouden, niet met rust gelaten

Een GPU die niet doorklokt is niet hetzelfde als een GPU zonder werk. Onder belasting noemt de driver zelf waarom hij de klok laag houdt: hittebescherming, een vermogenslimiet die onder de fabrieksinstelling is gezet, een programma dat hem heeft gevraagd terug te klokken, of een PCIe-voedingsstekker die ontbreekt of niet goed vastzit. Dat laatste is een kaart die weigert door te klokken tot hij fatsoenlijk is aangesloten — een kabelprobleem, geen instelling. De stotterscan vraagt dit onder een korte belasting aan de driver en meldt de redenen die hij noemde.

3. De game was tot een deel van de processor beperkt

Onzichtbaar tenzij je ernaar zoekt. Een versmald affiniteitsmasker of een standaard CPU-set op het gameproces betekent dat alles wat de game doet op díé processors moet passen terwijl de rest van de machine niets doet. Bronnen zijn onder meer een oud optimalisatiescript, een van een forum gekopieerde snelkoppeling met start /affinity, of een procestool die ooit is ingesteld en daarna vergeten.

Hoe je het ziet: Taakbeheer → Details, rechtsklik op de game, Affiniteit instellen. Staan niet alle processors aan, dan heb je je antwoord — zet ze daar allemaal aan, of haal de regel weg in het programma dat hem heeft geschreven.

4. De game draait op de verkeerde videokaart

Op een laptop, of op een desktop waar de geïntegreerde grafische kern aanstaat, kan een game op de zwakkere adapter belanden. De losse kaart meldt dan eerlijk een laag gebruik: hij doet niets. Op welke videokaart een game draait legt uit hoe je een voorkeur per game weghaalt.

5. De PCIe-verbinding is smaller dan ze zou moeten zijn

Eén keer het controleren waard, en het waard om in verhouding te blijven zien. De helft van de lanes op dezelfde generatie kan het ontwerp van het moederbord zelf zijn — een M.2-schijf die uit de lanes van de processor wordt gevoed, splitst het grafische slot — en een gehalveerde verbinding halveert je framerate niet; hoeveel het op jouw kaart kost, is hier niet gemeten. Het geval waar je iets aan moet doen, is een verbinding die lager is opgetraind dan beide kanten aankunnen: een riser, een matig contact, een lane die niet opkwam. Haal de kaart eruit en zet hem opnieuw vast.

6. De GPU wacht op gegevens, niet op de CPU

Een frame dat nog niet is samengesteld, laat de GPU stilstaan, en de reden kan een trage asset-lees zijn, een shader die wordt gecompileerd, of pagina's die van schijf terugkomen. In een gebruiksgrafiek ziet dat er precies zo uit als een CPU-limiet en het is een ander probleem — zie Plotselinge FPS-drops in games.

7. Iets anders bezet de kern die de renderthread nodig heeft

Het totale CPU-gebruik is hier het verkeerde getal. Eén volledig verzadigde kern op een achtkernsmachine leest als een bescheiden totaal, en een achtergrondtaak die die kern vasthoudt, komt vóór de renderthread in de wachtrij.

Hoe een echte CPU-limiet eruitziet

Is de lijst hierboven uitgeput, dan is het overgebleven geval echt en heeft het een herkenbare vorm:

• De resolutietest deed niets. Dit is de voorwaarde, niet één signaal tussen andere.
• Eén thread zit tegen de verzadiging aan terwijl het totaal onopvallend is. Kijk per kern; het totaal laat je dit nooit zien.
• Het wordt erger van de simulatie, niet van het beeld. Drukte, physics, aantallen spelers, kijkafstand — niet textuurkwaliteit of schaduwresolutie.
• De frametijden zijn stabiel maar liggen op een bodem. Een CPU-limiet is een plafond op de doorvoer, geen bron van uitschieters; zijn uitschieters je probleem, lees dan Hoge gemiddelde FPS maar slechte 1% lows.

Een opname legt ook vast hoeveel van de run geblokkeerd is doorgebracht in de presentatie-aanroep — dat is druk op de GPU en op de wachtrij, en hoe hoger dat is, hoe minder een verandering in de gemiddelde FPS zegt over wat dan ook aan de CPU-kant. De benchmark lezen behandelt de rest.

Wat je aan een echte CPU-limiet kunt doen

Het eerlijke antwoord is dat dit grotendeels geen softwareprobleem is, en pagina's die doen alsof dat wel zo is, zijn de reden dat mensen bij registerlijsten uitkomen.

• Zet het geheugenprofiel aan in de firmware (XMP bij Intel, EXPO bij AMD) als het uitstaat. Van alles op dit terrein is dit het enige punt met echte gepubliceerde metingen erachter, en een machine die zijn geheugen op de terugvalsnelheid draait is een veelvoorkomende bevinding. Schone installatie voor stabiele 1% lows behandelt het met bronnen — inclusief waarom sneller geheugen kópen een andere bewering is dan aanzetten wat je al hebt.
• Geef de ruimte uit in plaats van erachteraan te jagen. Veranderde de resolutie verlagen niets, dan kosten hogere beeldinstellingen je niets.
• Verlaag de instellingen aan de simulatiekant, want dat zijn de instellingen die je werkelijk iets kosten.
• Zorg dat niets het proces beperkt — de affiniteitscontrole hierboven, en elk achtergebleven job object of elke achtergebleven prioriteitsregel.

Wat niet helpt

Simultaneous multithreading of de efficiëntiekernen uitzetten: de getallen achter dat advies komen van bronnen die geen methode hebben gepubliceerd, dus je ruilt bekende meerkernscapaciteit in voor een ongecontroleerde winst. Kernelwaarden voor geheugenbeheer en het overschrijven van de timerresolutie: hier botweg geweigerd, overal ongemeten. Geheugenopschoners: op een machine die geen geheugen tekortkomt, verandert méér vrijmaken niets meetbaars.

Gerelateerd

• Plotselinge FPS-drops in games
• Hoge gemiddelde FPS maar slechte 1% lows
• Op welke videokaart een game draait
• Schone installatie voor stabiele 1% lows