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.

Beskrivelsen gælder for motoren 0.8.0. Mellem versioner er udførelsen af GPU-scenarier ændret, så gamle målinger kan ikke betragtes som ækvivalente med nye alene efter en omregning af point. Til kontrol af driver eller overclocking skal du bruge én version af motoren.

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, derefter overdrager den den resterende del til arbejdstrådene og udfører samtidig forberedelse. 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, snarere end en totalt paralleliseret kørsel på hver kerne.

Tilstanden og rækkefølgen for gennemgang af objekter er deterministisk. Før hver måling af CPU-sektionen nulstilles den og udfører 512 forberedende billeder uden for optællingen, så resttilstand fra den forrige kørsel ikke trækkes med ind i serien.

Belastningens determinisme betyder ikke ens udførelsestid: frekvenser, temperatur, planlæggeren og baggrundsprocesser fortsætter 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 postprocesseringspas	Håndtering af geometri og levering af grafisk arbejde
Shader	1 gengivelse af scenen, 16 postprocesseringspas, parameter for shader-kompleksitet 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 Compute-billeder ikke læses som 8 000 FPS i et spil eller direkte sammenlignes med 800 Geometry-billeder. Til sammenlægning bruges normering pr. scenario, som er beskrevet i beregningen af point.

Belastningerne er skrevet på et portabelt niveau af muligheder: 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.

Korrektheden af belastningens udførelse kontrolleres separat fra hastigheden. Ved en fejl skal du orientere dig efter programmets meddelelse og gentage testen efter at have afhjulpet årsagen.

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 reducerer dens indflydelse på sammenligningen. Opvarmning kan stadig ændre resultaterne, derfor gemmes der desuden spredningen i udførelseshastighed og dens ændring fra den første blok til den sidste for blokkene.

Til vurdering af et scenario 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 udgangsvej. Derfor letter en ændring af skrivebordets opløsning i sig selv ikke selve belastningen. Ikke desto mindre kan man alligevel ikke aflæse et “absolut identisk” resultat ved enhver opløsning: i udgangsdelen deltager driveren og systemets aktuelle tilstand.

Den arkiverede kontrol af version 0.5.2 med 1920×1080, 1280×768 og 800×600 er givet i artiklen om repeterbarhed. Den erstatter ikke en ny serie efter ændringen af GPU-scenarierne.

Drivere og sammenligning af grafikkort

Geometry, Shader og Compute tester forskellige udførelsesveje. Et grafikkort kan være hurtigere i et scenario og langsommere i et andet. Driverversion, frekvenser, strømbegrænsninger og kommandolevering kan ændre resultatet. Et enkelt afvigende Compute er ikke nok til at tilskrive forskellen udelukkende til driveren. Sammenlign flere gentagelser, motorversionen og hvert scenario separat.

En reduktion af skrivebordets opløsning reducerer ikke Computes arbejdsgitter. Denne test bruger sin egen compute-shader, ikke FPS for visning af vinduet. Computes vægt i den grundlæggende GPU Score udgør 10%; detaljer er givet i formlen.

Verificeret for den beskrevne implementering: 2026-10-02.