Перейти до вмісту

Навантаження CPU і GPU

На цій сторінці

PCBenchmarkX запускає свої синтетичні навантаження з фіксованим обсягом роботи за кожного повтору, тому їх можна порівнювати між різними системами. У таких тестах не використовуються ігрові записи, і підсумкові цифри не дорівнюють «FPS у конкретній грі». Повний вимірювальний цикл описано в методиці.

Зараз застосовуються рушій 0.5.2 і навантаження phase4.6-dev-1. Версію потрібно тримати на увазі: зміна сценарію робить результати різних релізів напряму непорівнюваними.

У CPU-блоці створюються 65 536 об’єктів з координатами, швидкостями та прапорцями. На кожному кроці перераховуються рух, відскоки від меж і видимість. Основний потік спочатку обробляє 8 192 об’єкти підряд, потім передає решту робочим потокам і паралельно виконує підготовку. Далі потоки синхронізуються.

Кількість робочих потоків вибирається за правилом:

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

Якщо число фізичних ядер невідоме, беруть оцінку за логічними процесорами. Ядра для потоків не фіксуються вручну. Такий підхід імітує модель «одного ведучого» потоку з обмеженою допомогою, а не тотальний розпаралелений прогін на кожному ядрі.

Стан і порядок обходу об’єктів детерміновані. Перед кожним вимірюванням CPU-секції він скидається і виконує 512 підготовчих кадрів поза заліком, щоб не тягнути в серію залишковий стан від попереднього прогону.

Детермінізм навантаження не означає однакового часу виконання: частоти, температура, планувальник і фонові процеси продовжують впливати на вимірювання.

GPU-частина працює через Direct3D 12. Внутрішні робочі текстури мають фіксований розмір 1920×1080, незалежно від розміру вікна та робочого столу.

Навантаження Обчислювальна робота Що допомагає розрізняти
Geometry 6 відрисовок сцени по 9 216 інстансів і 2 проходи постобробки Обробку геометрії та подачу графічної роботи
Shader 1 відрисовка сцени, 16 проходів постобробки, параметр складності шейдера 24 Піксельне та текстурне навантаження
Compute Сітка 1920×1080, групи 8×8, цілочисельні обчислення з 96 ітераціями Виконання обчислювального шейдера
Combined CPU-симуляція і фіксований графічний конвеєр Спільну роботу CPU, драйвера і GPU

Це окремі сценарії з різним обсягом роботи. Наприклад, 8 000 умовних кадрів Compute не можна читати як 8 000 FPS у грі або напряму порівнювати з 800 кадрами Geometry. Для об’єднання застосовується нормування за сценарієм, описане в розрахунку балів.

Навантаження написані на переносимому рівні можливостей: shader model 5.0 і feature level 11_0 без вендорських розширень. Один і той самий код виконується на різних поколіннях і виробниках відеокарт, без окремої гілки під конкретного вендора.

Після вимірювань рушій перевіряє вихід кожного GPU-навантаження: для Geometry, Shader, Compute, Combined і завантаженого тесту затримки зафіксовано контрольну сигнатуру — очікуваний вигляд невеликого фрагмента результату. Прочитаний після завершення фрагмент порівнюється з очікуваним; незбіг означає, що навантаження виконалося неправильно, і робить запуск непридатним. Перевірка виконується після залікових вимірювань і на самі числа не впливає.

Окремих тестів швидкості диска та пропускної здатності RAM у цьому наборі немає. Пам’ять і драйвер впливають на виконання навантажень, однак окремих оцінок SSD і RAM бенчмарк не розраховує.

П’ять навантажень продуктивності виконуються в трьох раундах із перестановкою порядку:

Раунд Порядок
1 CPU → Geometry → Shader → Compute → Combined
2 Shader → Compute → Combined → CPU → Geometry
3 Combined → CPU → Geometry → Shader → Compute

Місце кожного навантаження в послідовності змінюється від раунду до раунду. Це зменшує його вплив на порівняння. Прогрів усе ще може змінювати результати, тому для блоків додатково зберігаються розкид швидкості виконання та її зміна від першого блоку до останнього.

Для оцінки сценарію береться арифметичне середнє throughput трьох його блоків. Медіану та геометричне середнє блоків можна подивитися як додаткову діагностику, але підсумковий показник усе одно залишається на цьому середньому.

Чому низька роздільна здатність не полегшує основний тест

Section titled “Чому низька роздільна здатність не полегшує основний тест”

Навантаження CPU, GPU і Combined виконуються поза екранним буфером. Їхній шлях надсилання команд не викликає Present і не чекає обмеження черги показу. Внутрішні текстури залишаються 1920×1080, навіть якщо робочий стіл переключено на 800×600.

Інтерфейс і тест затримки працюють через окремий шлях виведення. Тому зміна роздільної здатності робочого столу сама по собі не полегшує саме навантаження. Тим не менш зчитувати «абсолютно однаковий» результат за будь-якої роздільної здатності все одно не можна: на вихідній ділянці беруть участь драйвер і поточний стан системи.

Практична перевірка з 1920×1080, 1280×768 і 800×600 наведена в статті про повторюваність.

Перевірено для описаної реалізації: 2026-09-20.