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.

Opis dotyczy silnika 0.8.0. Między wersjami zmieniało się wykonanie scenariuszy GPU, dlatego starych pomiarów nie można uznawać za równoważne nowym tylko po przeliczeniu punktów. Do sprawdzenia sterownika lub podkręcania używaj jednej wersji silnika.

CPU: symulacja obiektów

W bloku CPU tworzone 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 obiektu pod rząd, następnie przekazuje pozostałą część wątkom roboczym i równolegle wykonuje przygotowanie. Następnie 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 rdzeni fizycznych 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 klatek przygotowawczych poza zaliczeniem, aby nie ciągnąć do serii resztkowego stanu z poprzedniego przebiegu.

Determinizm obciążenia nie oznacza takiego samego czasu wykonania: częstotliwości, temperatura, harmonogram 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 przejść postprocessingu	Przetwarzanie geometrii i podawanie pracy graficznej
Shader	1 renderowanie sceny, 16 przejść postprocessingu, parametr złożoności shadera 24	Obciążenie pikselowe i teksturowe
Compute	Siatka 1920×1080, grupy 8×8, obliczenia całkowitoliczbowe z 96 iteracjami	Wykonanie 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 warunkowych 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ę normowanie według scenariusza, opisane 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.

Poprawność wykonania obciążenia jest sprawdzana oddzielnie od szybkości. Przy błędzie kieruj się komunikatem programu i powtórz test po usunięciu przyczyny.

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

Powtarzanie bloków

Pięć obciążeń wydajnościowych jest wykonywanych w trzech rundach z przestawieniem 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 nadal 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 są wykonywane poza buforem ekranu. 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 takiego samego” wyniku przy dowolnej rozdzielczości: na końcowym odcinku uczestniczą sterownik i aktualny stan systemu.

Archiwalna weryfikacja wersji 0.5.2 z 1920×1080, 1280×768 i 800×600 jest podana w artykule o powtarzalności. Nie zastępuje nowej serii po zmianie scenariuszy GPU.

Sterowniki i porównywanie kart graficznych

Geometry, Shader i Compute sprawdzają różne ścieżki wykonania. Jedna karta graficzna może być szybsza w jednym scenariuszu i wolniejsza w innym. Wersja sterownika, częstotliwości, limity zasilania i podawanie poleceń mogą zmieniać wynik. Sam odmienny Compute nie wystarcza, aby przypisać różnicę tylko sterownikowi. Porównaj kilka powtórzeń, wersję silnika i każdy scenariusz osobno.

Zmniejszenie rozdzielczości pulpitu nie zmniejsza roboczej siatki Compute. Ten test używa własnego shadera obliczeniowego, a nie FPS pokazywania okna. Waga Compute w podstawowym GPU Score wynosi 10%; szczegóły podano w formule.

Sprawdzone dla opisanej implementacji: 2026-10-02.