Kalkylator för flaskhals mellan CPU och GPU

Bildrutetiden är en användbar utgångspunkt

Antalet bildrutor per sekund är inversen av bildrutetiden. När tiden mäts i millisekunder gäller:

övre bildfrekvensgräns = 1000 / bildrutetid i ms

Det långsammare uppmätta steget bestämmer den övre gränsen för den förenklade bearbetningskedjan:

uppskattad övre gräns = 1000 / max(CPU-bildrutetid, GPU-bildrutetid)

Detta är en diagnostisk uppskattning, inte ett löfte om att spelet visar bildrutor med exakt den frekvensen. Bildfrekvensgränser, synkronisering, köer, arbete i spelmotorn, inläsning, operativsystemets schemaläggning och presentation på skärmen kan påverka den observerade bildfrekvensen. Microsoft definierar CPU- och GPU-tid per bildruta separat i sin vägledning för DirectX-profilering, eftersom båda sidor kan överskrida den tillgängliga tidsbudgeten för en bildruta.

Omvandlingen 1000 / ms ger en övre gräns för det uppmätta steget. En CPU-tid på 12 ms motsvarar till exempel cirka 83,33 FPS, medan en GPU-tid på 7 ms motsvarar cirka 142,86 FPS. I den här inspelningen är CPU-sidan långsammare och den förenklade övre gränsen är cirka 83,33 FPS.

Varför toleransen är viktig

När bildrutetiderna ligger nära varandra bör resultatet inte uttryckas med falsk säkerhet. Kalkylatorn jämför den absoluta skillnaden med bildrutetiden för den långsammare sidan:

relativ skillnad = |CPU ms - GPU ms| / max(CPU ms, GPU ms) × 100

Om skillnaden ligger inom den valda toleransen är resultatet balanserat eller obestämt för just den här inspelningen. Om den överstiger toleransen är sidan med den längre bildrutetiden den aktuella begränsningen.

Procenttalet beskriver avståndet mellan två tidsmätningar i en viss arbetsbelastning. Det visar inte hur stor andel av CPU:n eller GPU:n som går till spillo och förutsäger inte heller prestandavinsten av att byta maskinvara.

Gör inspelningen reproducerbar

För en användbar jämförelse måste arbetsbelastningen hållas stabil. Håll följande oförändrat:

• version av spelet och spelmotorn;
• sparfil, repris, prestandatestsekvens eller fasta rörelserutt;
• upplösning, renderingsskala, kvalitetsförinställning och grafik-API;
• bildfrekvensgräns samt VSync- och dynamiskt upplösningsläge;
• drivrutinsinställningar, energiläge och bakgrundsbelastning;
• uppvärmningstid och inspelningslängd.

Kör testet flera gånger och jämför representativ statistik i stället för att lita på ett enda kort mätprov. AMD:s vägledning för CPU-prestanda rekommenderar att variabler som testscen och slumptalsfrö hålls fasta. I vägledningen för Unreal Engine föreslår AMD också att upplösningen ändras som ett diagnostiskt test: om en mycket högre renderingsupplösning knappt påverkar prestandan är det en indikation som bör undersökas för en möjlig CPU-begränsning i den arbetsbelastningen. Det är fortfarande en indikation, inte ett allmängiltigt besked.

Varför nyttjandegrad inte är ett bevis

Nyttjandegraden kan stödja en diagnos men kan inte fastställa den på egen hand. Den totala CPU-användningen kan se måttlig ut även om en huvud- eller renderingstråd är fullbelastad. Låg GPU-användning kan bero på en bildfrekvensgräns, väntan på CPU:n, synkronisering eller för lite inskickat arbete. Hög GPU-användning visar att enheten var upptagen, men pekar inte ut det exakta kostsamma renderingssteget och förutsäger inte resultatet av en uppgradering.

Verktyg för tidsmätning ger bättre sammanhang. Intel PresentMon registrerar telemetri för bildrutor och GPU, NVIDIA Nsight visar bildrutornas varaktighet på CPU och GPU samt GPU-belastningens intervall, och AMD Radeon GPU Profiler visualiserar kötider och perioder då GPU:n är inaktiv. Även tröskelvärden i profileringsverktyg är tumregler: Radeon GPU Profilers klassificering av en CPU-bunden situation använder ett justerbart tröskelvärde för GPU-inaktivitet, inte en lag som gäller för alla spelmotorer.

Vad 1 % low-värden kan och inte kan säga

Ett 1 % low-värde sammanfattar den långsamma svansen i en fördelning av bildrutetider. Därför är det användbart för att hitta ojämn bildleverans som ett genomsnitt kan dölja. Det avslöjar däremot inte om CPU, GPU, strömning av resurser, kompilering av shaders, minnestryck eller ett annat stopp orsakade de långsamma bildrutorna.

Definitionerna varierar också. Vissa rapporter beräknar en bildfrekvens från bildrutetidens 99:e percentil (1000 / p99-bildrutetid), medan andra beräknar medelvärdet för den långsammaste procenten av FPS-mätningarna. NVIDIA Nsight Systems definierar bildrutelängden vid den 99:e percentilen som det värde som endast 1 % av bildrutorna är längre än. Anteckna verktyget och definitionen när du jämför resultat, och ersätt inte matchande CPU- och GPU-tider per bildruta med ett 1 % low-värde.

Varför allmängiltiga procenttal för flaskhalsar är missvisande

En dator har inte ett permanent förhållande mellan CPU- och GPU-flaskhalsar. Det begränsande arbetet kan ändras beroende på spel, scen, upplösning, inställningar, version av spelmotorn, drivrutin, bildfrekvensgräns och önskad bildfrekvens. En livlig stadsscen kan belasta simuleringen och inskickningen av renderingsanrop, medan en annan scen med högre renderingsskala kan kräva mer tid av GPU:n.

Kalkylatorer som bara använder modellnamn kan inte observera de här förhållandena. Ett resultat som ”23 % flaskhals” utan uppmätta tidsvärden från samma scen har ingen stabil teknisk innebörd. Använd den här kalkylatorn för att beskriva den inspelning du faktiskt har gjort, upprepa testet med den arbetsbelastning som är viktig för dig och använd en tidslinjeprofilerare när du behöver hitta det specifika arbete som orsakar begränsningen.

Officiella tekniska källor

• Microsoft: profilering av DirectX-program
• Intel: prestandaövervakning med PresentMon
• NVIDIA: bildrutestatus i Nsight Systems
• NVIDIA: GPU Trace i Nsight Graphics
• AMD GPUOpen: översikt över Radeon GPU Profiler
• AMD GPUOpen: prestandavägledning för Unreal Engine
• AMD GPUOpen: prestandavägledning för Ryzen-CPU