CPU- og GPU-belastninger

PCBenchmarkX kører sine syntetiske belastninger med et fast arbejdsomfang ved hver gentagelse, så de kan sammenlignes på tværs af forskellige systemer. I sådanne tests bruges der ikke optagelser fra spil, og de endelige tal er ikke lig med “FPS i et bestemt spil”. Den fulde målecyklus er beskrevet i metodikken.

I øjeblikket anvendes motoren 0.5.2 og belastningen phase4.6-dev-1. Versionen skal man holde sig for øje: et skift af scenarie gør resultater fra forskellige udgivelser direkte usammenlignelige.

CPU: simulering af objekter

I CPU-blokken oprettes 65 536 objekter med koordinater, hastigheder og flag. Ved hvert trin genberegnes bevægelse, afvisning fra grænser og synlighed. Hovedtråden behandler først 8 192 objekter i træk, overfører derefter den resterende del til arbejdstrådene og udfører samtidig forberedelsen. Derefter synkroniseres trådene.

Antallet af arbejdstråde vælges efter reglen:

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

Hvis antallet af fysiske kerner er ukendt, bruges et skøn ud fra logiske processorer. Kerner til trådene fastlåses ikke manuelt. Denne tilgang efterligner modellen med “én førende” tråd med begrænset hjælp, frem for en totalt paralleliseret kørsel på hver kerne.

Objekternes tilstand og gennemløbsrækkefølge er deterministiske. Før hver måling af CPU-sektionen nulstilles den og udfører 512 forberedende billeder uden for bedømmelsen, for ikke at trække resttilstand fra den forrige kørsel ind i serien.

Belastningens determinisme betyder ikke ens udførelsestid: frekvenser, temperatur, planlæggeren og baggrundsprocesser bliver ved med at påvirke målingen.

Tre GPU-belastninger

GPU-delen arbejder via Direct3D 12. De interne arbejdsteksturer har en fast størrelse på 1920×1080, uafhængigt af vinduets og skrivebordets størrelse.

Belastning	Beregningsarbejde	Hvad den hjælper med at skelne
Geometry	6 gengivelser af scenen med 9 216 instanser og 2 efterbehandlingspas	Håndtering af geometri og levering af grafisk arbejde
Shader	1 gengivelse af scenen, 16 efterbehandlingspas, shader-kompleksitetsparameter 24	Pixel- og teksturbelastning
Compute	Gitter 1920×1080, grupper 8×8, heltalsberegninger med 96 iterationer	Udførelse af compute-shader
Combined	CPU-simulering og fast grafisk pipeline	Samspillet mellem CPU, driver og GPU

Dette er separate scenarier med forskelligt arbejdsomfang. For eksempel kan 8 000 betingede billeder i Compute ikke læses som 8 000 FPS i et spil eller direkte sammenlignes med 800 billeder i Geometry. Til at sammenlægge anvendes normering pr. scenarie, beskrevet i beregningen af point.

Belastningerne er skrevet på et portabelt funktionalitetsniveau: shader model 5.0 og feature level 11_0 uden leverandørspecifikke udvidelser. Den samme kode udføres på forskellige generationer og producenter af grafikkort, uden en separat gren til en bestemt leverandør.

Efter målingerne kontrollerer motoren outputtet fra hver GPU-belastning: for Geometry, Shader, Compute, Combined og den indlæste latenstest er der fastlagt en kontrolsignatur — det forventede udseende af et lille fragment af resultatet. Fragmentet, der læses efter afslutningen, sammenlignes med det forventede; en afvigelse betyder, at belastningen blev udført forkert, og gør kørslen ubrugelig. Kontrollen udføres efter de bedømte målinger og påvirker ikke selve tallene.

Der er ingen separate tests af diskhastighed og RAM-båndbredde i dette sæt. Hukommelse og driver påvirker udførelsen af belastningerne, men benchmarken beregner ikke separate vurderinger af SSD og RAM.

Gentagelse af blokke

De fem ydelsesbelastninger udføres i tre runder med ombytning af rækkefølgen:

Runde	Rækkefølge
1	CPU → Geometry → Shader → Compute → Combined
2	Shader → Compute → Combined → CPU → Geometry
3	Combined → CPU → Geometry → Shader → Compute

Hver belastnings placering i sekvensen ændres fra runde til runde. Det mindsker dens indflydelse på sammenligningen. Opvarmning kan stadig ændre resultaterne, derfor gemmes der for blokkene desuden spredningen i udførelseshastighed og dens ændring fra den første blok til den sidste.

Til vurdering af scenariet bruges det aritmetiske gennemsnit af throughput for dets tre blokke. Medianen og det geometriske gennemsnit af blokkene kan ses som ekstra diagnostik, men det endelige tal forbliver alligevel på dette gennemsnit.

Hvorfor en lav opløsning ikke letter den primære test

Belastningerne CPU, GPU og Combined udføres uden for skærmbufferen. Deres vej til at sende kommandoer udløser ikke Present og venter ikke på begrænsning af visningskøen. De interne teksturer forbliver 1920×1080, selv hvis skrivebordet er skiftet til 800×600.

Brugerfladen og latenstesten arbejder via en separat outputvej. Derfor letter en ændring af skrivebordets opløsning ikke i sig selv selve belastningen. Ikke desto mindre kan man alligevel ikke læse et “absolut identisk” resultat ved enhver opløsning: i outputdelen deltager driveren og systemets aktuelle tilstand.

En praktisk prøve med 1920×1080, 1280×768 og 800×600 er givet i artiklen om reproducerbarhed.

Verificeret for den beskrevne implementering: 2026-09-20.