Zátěž CPU a GPU

PCBenchmarkX spouští své syntetické zátěže s pevným objemem práce při každém opakování, proto je lze srovnávat mezi různými systémy. V takových testech se nepoužívají herní záznamy a výsledné hodnoty se nerovnají „FPS v konkrétní hře“. Celý měřicí cyklus je popsán v metodice.

Nyní se používají engine 0.5.2 a zátěž phase4.6-dev-1. Verzi je třeba mít na paměti: změna scénáře činí výsledky různých vydání přímo nesrovnatelnými.

CPU: simulace objektů

V CPU bloku se vytváří 65 536 objektů se souřadnicemi, rychlostmi a příznaky. Při každém kroku se přepočítávají pohyb, odrazy od hranic a viditelnost. Hlavní vlákno nejprve zpracuje 8 192 objektů za sebou, poté předá zbývající část pracovním vláknům a souběžně provádí přípravu. Následně se vlákna synchronizují.

Počet pracovních vláken se volí podle pravidla:

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

Pokud není počet fyzických jader znám, použije se odhad podle logických procesorů. Jádra pro vlákna se nepřiřazují ručně. Tento přístup simuluje model „jednoho vedoucího“ vlákna s omezenou pomocí, nikoli totální paralelizovaný průchod na každém jádře.

Stav a pořadí procházení objektů jsou deterministické. Před každým měřením CPU sekce se resetuje a provede 512 přípravných snímků mimo hodnocení, aby se do série nepřenášel zbytkový stav z předchozího průchodu.

Determinismus zátěže neznamená stejnou dobu provádění: frekvence, teplota, plánovač a procesy na pozadí nadále ovlivňují měření.

Tři zátěže GPU

GPU část pracuje přes Direct3D 12. Vnitřní pracovní textury mají pevnou velikost 1920×1080, nezávisle na velikosti okna a pracovní plochy.

Zátěž	Výpočetní práce	Co pomáhá rozlišovat
Geometry	6 vykreslení scény po 9 216 instancích a 2 průchody postprocessingu	Zpracování geometrie a dodávání grafické práce
Shader	1 vykreslení scény, 16 průchodů postprocessingu, parametr složitosti shaderu 24	Pixelovou a texturovou zátěž
Compute	Mřížka 1920×1080, skupiny 8×8, celočíselné výpočty s 96 iteracemi	Provádění výpočetního shaderu
Combined	CPU simulace a pevný grafický pipeline	Spolupráci CPU, ovladače a GPU

Jde o samostatné scénáře s různým objemem práce. Například 8 000 podmíněných snímků Compute nelze číst jako 8 000 FPS ve hře nebo přímo srovnávat s 800 snímky Geometry. Pro sjednocení se používá normování podle scénáře, popsané ve výpočtu skóre.

Zátěže jsou napsány na přenositelné úrovni možností: shader model 5.0 a feature level 11_0 bez vendor rozšíření. Stejný kód se provádí na různých generacích a výrobcích grafických karet, bez samostatné větve pro konkrétního výrobce.

Po měřeních engine kontroluje výstup každé GPU zátěže: pro Geometry, Shader, Compute, Combined a načtený test latence je zaznamenán kontrolní podpis — očekávaná podoba malého fragmentu výsledku. Přečtený fragment po dokončení se porovná s očekávaným; neshoda znamená, že zátěž proběhla nesprávně, a činí spuštění nepoužitelným. Kontrola se provádí po hodnocených měřeních a na samotná čísla nemá vliv.

Samostatné testy rychlosti disku a propustnosti RAM v této sadě nejsou. Paměť a ovladač ovlivňují provádění zátěží, avšak samostatné hodnocení SSD a RAM benchmark nepočítá.

Opakování bloků

Pět zátěží výkonu se provádí ve třech kolech s přeskupením pořadí:

Kolo	Pořadí
1	CPU → Geometry → Shader → Compute → Combined
2	Shader → Compute → Combined → CPU → Geometry
3	Combined → CPU → Geometry → Shader → Compute

Místo každé zátěže v posloupnosti se mění kolo od kola. To snižuje jeho vliv na srovnání. Zahřívání stále může měnit výsledky, proto se pro bloky navíc ukládá rozptyl rychlosti provádění a její změna od prvního bloku k poslednímu.

Pro hodnocení scénáře se bere aritmetický průměr throughput tří jeho bloků. Medián a geometrický průměr bloků lze zobrazit jako doplňkovou diagnostiku, ale výsledný ukazatel stále zůstává na tomto průměru.

Proč nízké rozlišení neulehčuje hlavní test

Zátěže CPU, GPU a Combined se provádějí mimo obrazový buffer. Jejich cesta odesílání příkazů nevyvolává Present a nečeká na omezení fronty zobrazení. Vnitřní textury zůstávají 1920×1080, i když je pracovní plocha přepnuta na 800×600.

Rozhraní a test latence pracují přes samostatnou výstupní cestu. Proto změna rozlišení pracovní plochy sama o sobě neulehčuje samotnou zátěž. Přesto nelze číst „naprosto stejný“ výsledek při jakémkoli rozlišení: na výstupní části se podílejí ovladač a aktuální stav systému.

Praktická kontrola s 1920×1080, 1280×768 a 800×600 je uvedena v článku o opakovatelnosti.

Ověřeno pro popsanou implementaci: 2026-09-20.