Hoppa till innehåll

CPU- och GPU-belastningar

På den här sidan

PCBenchmarkX kör sina syntetiska belastningar med en fast arbetsmängd vid varje upprepning, därför kan de jämföras mellan olika system. I sådana tester används inga inspelningar från spel, och de slutliga siffrorna är inte lika med “FPS i ett specifikt spel”. Den fullständiga mätcykeln beskrivs i metodiken.

Beskrivningen avser motorn 0.8.0. Mellan versionerna har utförandet av GPU-scenarierna ändrats, därför kan gamla mätningar inte anses likvärdiga med nya enbart efter omräkning av poäng. För att kontrollera drivrutinen eller överklockning, använd en version av motorn.

I CPU-blocket skapas 65 536 objekt med koordinater, hastigheter och flaggor. Vid varje steg räknas rörelse, studs mot gränser och synlighet om. Huvudtråden bearbetar först 8 192 objekt i följd, överför sedan den återstående delen till arbetstrådar och utför förberedelser parallellt. Därefter synkroniseras trådarna.

Antalet arbetstrådar väljs enligt regeln:

workers = clamp(physical_cores − 1, 1, 6)

Om antalet fysiska kärnor är okänt används en uppskattning baserad på logiska processorer. Kärnor för trådarna låses inte manuellt. Detta tillvägagångssätt imiterar modellen med en “ledande” tråd med begränsad hjälp, snarare än en totalt parallelliserad körning på varje kärna.

Objektens tillstånd och genomgångsordning är deterministiska. Före varje mätning av CPU-sektionen återställs den och utför 512 förberedande bildrutor utanför bedömningen, för att inte dra in kvarvarande tillstånd från föregående körning i serien.

Belastningens determinism innebär inte samma körtid: frekvenser, temperatur, schemaläggaren och bakgrundsprocesser fortsätter att påverka mätningen.

GPU-delen arbetar via Direct3D 12. De interna arbetstexturerna har en fast storlek på 1920×1080, oberoende av fönstrets och skrivbordets storlek.

Belastning Beräkningsarbete Vad den hjälper att särskilja
Geometry 6 renderingar av scenen med 9 216 instanser och 2 efterbehandlingspass Bearbetning av geometri och tillförsel av grafiskt arbete
Shader 1 rendering av scenen, 16 efterbehandlingspass, parametern för shaderkomplexitet 24 Pixel- och texturbelastning
Compute Rutnät 1920×1080, grupper 8×8, heltalsberäkningar med 96 iterationer Utförande av beräkningsshadern
Combined CPU-simulering och en fast grafisk pipeline Samverkan mellan CPU, drivrutin och GPU

Detta är separata scenarier med olika arbetsmängd. Till exempel kan 8 000 villkorliga bildrutor i Compute inte läsas som 8 000 FPS i ett spel eller direkt jämföras med 800 bildrutor i Geometry. För att sammanfoga används normering per scenario, som beskrivs i beräkningen av poäng.

Belastningarna är skrivna på en portabel nivå av funktioner: shader model 5.0 och feature level 11_0 utan leverantörsspecifika tillägg. Samma kod körs på olika generationer och tillverkare av grafikkort, utan en separat gren för en specifik leverantör.

Belastningens korrekthet kontrolleras separat från hastigheten. Vid ett fel, utgå från programmets meddelande och upprepa testet efter att orsaken har åtgärdats.

Det finns inga separata tester för diskhastighet och RAM-bandbredd i detta paket. Minnet och drivrutinen påverkar utförandet av belastningarna, men benchmarken beräknar inga separata uppskattningar av SSD och RAM.

De fem prestandabelastningarna utförs i tre omgångar med ändrad ordning:

Omgång Ordning
1 CPU → Geometry → Shader → Compute → Combined
2 Shader → Compute → Combined → CPU → Geometry
3 Combined → CPU → Geometry → Shader → Compute

Varje belastnings plats i sekvensen ändras från omgång till omgång. Detta minskar dess inverkan på jämförelsen. Uppvärmning kan fortfarande ändra resultaten, därför sparas dessutom spridningen i körhastighet och dess förändring från det första blocket till det sista för blocken.

För att bedöma ett scenario används det aritmetiska medelvärdet av throughput för dess tre block. Medianen och det geometriska medelvärdet för blocken kan ses som ytterligare diagnostik, men det slutliga värdet förblir ändå detta medelvärde.

Varför en låg upplösning inte underlättar huvudtestet

Section titled “Varför en låg upplösning inte underlättar huvudtestet”

Belastningarna CPU, GPU och Combined utförs utanför skärmbufferten. Deras väg för att skicka kommandon orsakar inte Present och väntar inte på begränsningen av visningskön. De interna texturerna förblir 1920×1080, även om skrivbordet växlas till 800×600.

Gränssnittet och latensprovet arbetar via en separat utväg. Därför underlättar en ändring av skrivbordsupplösningen i sig inte själva belastningen. Ändå kan man inte läsa ett “absolut identiskt” resultat vid vilken upplösning som helst: i utmatningsdelen deltar drivrutinen och systemets aktuella tillstånd.

Den arkiverade kontrollen av version 0.5.2 med 1920×1080, 1280×768 och 800×600 finns i artikeln om repeterbarhet. Den ersätter inte en ny serie efter ändringen av GPU-scenarierna.

Drivrutiner och jämförelse av grafikkort

Section titled “Drivrutiner och jämförelse av grafikkort”

Geometry, Shader och Compute testar olika utförandevägar. Ett grafikkort kan vara snabbare i ett scenario och långsammare i ett annat. Drivrutinens version, frekvenser, effektbegränsningar och kommandotillförsel kan ändra resultatet. En avvikande Compute är inte tillräckligt för att tillskriva skillnaden enbart drivrutinen. Jämför flera upprepningar, motorns version och varje scenario separat.

En minskning av skrivbordsupplösningen minskar inte Compute-arbetsrutnätet. Detta test använder en egen beräkningsshader, inte FPS för fönstervisning. Compute-vikten i bas-GPU Score är 10%; detaljer finns i formeln.

Verifierat för den beskrivna implementationen: 2026-10-02.