Obciążenia CPU i GPU

PCBenchmarkX uruchamia swoje syntetyczne obciążenia ze stałym wolumenem pracy przy każdym powtórzeniu, dlatego można je porównywać między różnymi systemami. W takich testach nie są używane nagrania z gier, a końcowe liczby nie są równe „FPS w konkretnej grze”. Pełny cykl pomiarowy opisano w metodyce.

Obecnie stosowane są silnik 0.5.2 i obciążenie phase4.6-dev-1. Wersję trzeba mieć na uwadze: zmiana scenariusza czyni wyniki różnych wydań bezpośrednio nieporównywalnymi.

CPU: symulacja obiektów

W bloku CPU tworzonych jest 65 536 obiektów ze współrzędnymi, prędkościami i flagami. Na każdym kroku przeliczane są ruch, odbicia od granic i widoczność. Główny wątek najpierw przetwarza 8 192 obiekty pod rząd, następnie przekazuje pozostałą część wątkom roboczym i równolegle wykonuje przygotowanie. Potem wątki są synchronizowane.

Liczba wątków roboczych wybierana jest według reguły:

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

Jeśli liczba fizycznych rdzeni jest nieznana, brana jest ocena na podstawie procesorów logicznych. Rdzenie dla wątków nie są przypisywane ręcznie. Takie podejście imituje model „jednego prowadzącego” wątku z ograniczoną pomocą, a nie totalny zrównoleglony przebieg na każdym rdzeniu.

Stan i kolejność przechodzenia obiektów są deterministyczne. Przed każdym pomiarem sekcji CPU jest on resetowany i wykonuje 512 przygotowawczych klatek poza zaliczeniem, aby nie ciągnąć do serii resztkowego stanu z poprzedniego przebiegu.

Determinizm obciążenia nie oznacza jednakowego czasu wykonania: częstotliwości, temperatura, scheduler i procesy w tle nadal wpływają na pomiar.

Trzy obciążenia GPU

Część GPU działa przez Direct3D 12. Wewnętrzne tekstury robocze mają stały rozmiar 1920×1080, niezależnie od rozmiaru okna i pulpitu.

Obciążenie	Praca obliczeniowa	Co pomaga rozróżnić
Geometry	6 renderowań sceny po 9 216 instancji i 2 przebiegi postprocessingu	Przetwarzanie geometrii i podawanie pracy graficznej
Shader	1 renderowanie sceny, 16 przebiegów postprocessingu, parametr złożoności shadera 24	Obciążenie pikselowe i teksturowe
Compute	Siatka 1920×1080, grupy 8×8, obliczenia całkowitoliczbowe ze 96 iteracjami	Wykonywanie shadera obliczeniowego
Combined	Symulacja CPU i stały potok graficzny	Wspólną pracę CPU, sterownika i GPU

To osobne scenariusze o różnym wolumenie pracy. Na przykład 8 000 umownych klatek Compute nie można czytać jako 8 000 FPS w grze ani bezpośrednio porównywać z 800 klatkami Geometry. Do łączenia stosuje się normalizację według scenariusza, opisaną w obliczaniu punktów.

Obciążenia są napisane na przenośnym poziomie możliwości: shader model 5.0 i feature level 11_0 bez rozszerzeń producentów. Ten sam kod wykonuje się na różnych generacjach i producentach kart graficznych, bez osobnej gałęzi pod konkretnego producenta.

Po pomiarach silnik sprawdza wyjście każdego obciążenia GPU: dla Geometry, Shader, Compute, Combined i załadowanego testu opóźnienia zapisana jest kontrolna sygnatura — oczekiwany wygląd niewielkiego fragmentu wyniku. Odczytany po zakończeniu fragment jest porównywany z oczekiwanym; niezgodność oznacza, że obciążenie wykonało się nieprawidłowo, i czyni uruchomienie nieprzydatnym. Sprawdzenie wykonywane jest po zaliczonych pomiarach i nie wpływa na same liczby.

Osobnych testów szybkości dysku i przepustowości RAM w tym zestawie nie ma. Pamięć i sterownik wpływają na wykonywanie obciążeń, jednak osobnych ocen SSD i RAM benchmark nie oblicza.

Powtarzanie bloków

Pięć obciążeń wydajności wykonywanych jest w trzech rundach z przestawianiem kolejności:

Runda	Kolejność
1	CPU → Geometry → Shader → Compute → Combined
2	Shader → Compute → Combined → CPU → Geometry
3	Combined → CPU → Geometry → Shader → Compute

Miejsce każdego obciążenia w sekwencji zmienia się z rundy na rundę. To zmniejsza jego wpływ na porównanie. Rozgrzewka wciąż może zmieniać wyniki, dlatego dla bloków dodatkowo zapisywane są rozrzut szybkości wykonania i jego zmiana od pierwszego bloku do ostatniego.

Do oceny scenariusza brana jest średnia arytmetyczna throughput trzech jego bloków. Medianę i średnią geometryczną bloków można obejrzeć jako dodatkową diagnostykę, ale końcowy wskaźnik i tak pozostaje na tej średniej.

Dlaczego niska rozdzielczość nie ułatwia głównego testu

Obciążenia CPU, GPU i Combined wykonywane są poza buforem ekranowym. Ich ścieżka wysyłania poleceń nie wywołuje Present i nie czeka na ograniczenie kolejki prezentacji. Wewnętrzne tekstury pozostają 1920×1080, nawet jeśli pulpit jest przełączony na 800×600.

Interfejs i test opóźnienia działają przez osobną ścieżkę wyjścia. Dlatego zmiana rozdzielczości pulpitu sama w sobie nie ułatwia samego obciążenia. Niemniej jednak nie można odczytywać „absolutnie identycznego” wyniku przy dowolnej rozdzielczości: w końcowym odcinku uczestniczą sterownik i bieżący stan systemu.

Praktyczna weryfikacja z 1920×1080, 1280×768 i 800×600 podana jest w artykule o powtarzalności.

Sprawdzone dla opisanej implementacji: 2026-09-20.