CPU- och GPU-belastningar

PCBenchmarkX kör sina syntetiska belastningar med en fast mängd arbete 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.

För närvarande används motorn 0.5.2 och belastningen phase4.6-dev-1. Versionen måste man ha i åtanke: ett byte av scenario gör resultat från olika releaser direkt ojämförbara.

CPU: simulering av objekt

I CPU-blocket skapas 65 536 objekt med koordinater, hastigheter och flaggor. Vid varje steg räknas rörelse, studsningar mot gränser och synlighet om. Huvudtråden bearbetar först 8 192 objekt i följd, överlämnar sedan den återstående delen till arbetstrådarna och utför samtidigt förberedelser. 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.

Tillståndet och ordningen för genomgången av objekten är deterministiska. Före varje mätning av CPU-sektionen återställs det och utför 512 förberedande bildrutor utanför mätningen, för att inte dra in resttillstå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.

Tre GPU-belastningar

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 till att särskilja
Geometry	6 renderingar av scenen med 9 216 instanser och 2 efterbehandlingspass	Bearbetning av geometri och tillförsel av grafikarbete
Shader	1 rendering av scenen, 16 efterbehandlingspass, shaderkomplexitetsparameter 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 fast grafikkedja	Samverkan mellan CPU, drivrutin och GPU

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

Belastningarna är skrivna på en portabel funktionsnivå: 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.

Efter mätningarna kontrollerar motorn utdata från varje GPU-belastning: för Geometry, Shader, Compute, Combined och det laddade latenstestet är en kontrollsignatur fastställd — det förväntade utseendet på ett litet fragment av resultatet. Fragmentet som läses efter avslutningen jämförs med det förväntade; en avvikelse innebär att belastningen utfördes felaktigt och gör körningen oanvändbar. Kontrollen utförs efter de mätningar som räknas och påverkar inte själva siffrorna.

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

Upprepning av block

De fem prestandabelastningarna utförs i tre omgångar med permuterad 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 utförandehastighet 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 ligger ändå på detta medelvärde.

Varför 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änsning av visningskön. De interna texturerna förblir 1920×1080, även om skrivbordet är växlat till 800×600.

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

En praktisk kontroll med 1920×1080, 1280×768 och 800×600 ges i artikeln om repeterbarhet.

Verifierat för den beskrivna implementationen: 2026-09-20.