Завдяки початку продажу процесорів AMD Ryzen 5 раніше запланованого терміну (11 квітня) перші огляди даних процесорів з'являються вже зараз. Ми вже розповідали коротко про продуктивність 4-ядерного процесора Ryzen 5 1400 у синтетичних тестах та сучасних іграх. Тепер наші іспанські колеги з El Chapuzas Informatico опублікували огляд 6-ядерного процесора AMD Ryzen 5 1600.

Цей процесор має шість фізичними ядрамина кожне з яких припадає по два обчислювальні потоки, що в результаті дає дванадцять потоків. Базова частотапроцесора становить 3.2 ГГц, і може динамічно підвищуватися до 3.6 ГГц. Обсяг загальної кеш-пам'яті третього рівня у AMD Ryzen 5 1600 складає 16 Мбайт (8+8 Мбайт), а на кожне ядро ​​припадає по 512 кБайт кешу другого рівня та по 64 і 32 кБайт кешу інструкцій та даних першого рівня відповідно. Як і інші процесор Ryzen, цей чіп виконаний у корпусі Socket AM4, яке TDP становить 64 Вт. Рекомендована вартість новинки для ринку США складає $219.

Конфігурація тестового стенду, використаного нашими колегами, представлена ​​такими комплектуючими:

• Материнська плата: MSI X370 XPower Gaming Titanium;
• Оперативна пам'ять: G.Skill TridentZ DDR4 3600 МГц, що працює на частоті 2400 МГц;
• Відеокарта: MSI GeForce GTX 1070 Gaming Z;
• Блок живлення: Be Quiet! Dark Power Pro11 1200 В;
• Твердотільні накопичувачі: Kingston SSDNow KC400 128 Гбайт та Corsair LX 512 Гбайт;
• Система охолодження: Wraith Spire;
• Операційна система: Windows 10 64 біт.

Продуктивність одного ядра процесора Ryzen 5 1600 очікувано не сильно відрізняється від продуктивності одного ядра Ryzen 7 1700X, оскільки вони побудовані на одних і тих же кремнієвих кристалах, тільки у шестиядерного процесора відключено два ядра.

У багатопотокових же тести CPU-Zі wPrime 2.1 (32M) новинка показала цілком очікувані результати, продемонструвавши вельми непоганий рівень продуктивності.

У Cinebench 15 новинка випередила не тільки розігнаний до 4.9 ГГц та доповнений більше швидкою пам'яттю(3600 МГц) дорожчий чотириядерний Intel Core i7-7700K, а й шестиядерний Intel Core i7-5930K. А ось у кодуванні відео останній виявився швидшим.

З пам'яттю процесор Ryzen 5 1600 працює не найкращим чином, хоча і трохи краще, ніж Ryzen 7 1700X.

У деяких синтетичних тестах новинка AMD показує найкращі результати, В порівнянні з Ryzen 7 1700X, а в деяких незначно програє йому. У більшості синтетичних тестів процесор Intel Core i7-6700K виявляється швидше обох представників AMD.

Що стосується ігрової продуктивності, вона дуже вражає. У більшості тестів у дозволі Full HD (1920 х 1080 пікселів) новинка не сильно відстає, від дорожчого Intel Core i7-6700K, а в деяких і випереджає його. Цікаво відзначити, що в іграх Doom (при використання OpenGL) та Rise of Tomb Raider (при використанні DirectX 11) процесор Ryzen 5 1600 значно випереджає Ryzen 7 1700X.

У роздільній здатності 4K UHD (3840 x 2160 пікселів) ситуація приблизно так само, і у випадку з більшістю ігор все вперлося в продуктивність відеокарти.

З штатною системоюохолодження частоту процесора вдалося підняти до 3.9 ГГц, при цьому напруга на ядрі склала 1.36 В. Цікаво буде подивитися, наскільки вдасться розігнати новинку з охолодженням рідини, і які частоти її підкоряться в екстремальному розгоні.

Температура процесора AMD Ryzen 5 1600 у простої складає 39 градусів за Цельсієм, а під навантаженням 62 – 65 градусів за Цельсієм. Споживання системи на базі новинки в іграх склало 245 Вт, що дорівнює споживанню системи на базі Intel Core i7-6700K, яке дорівнює 250 Вт.

Синтетичні тести

В оригінальному огляді всі тести йдуть на різних сторінках, я їх об'єдную для зручності, але поділю на синтетику та ігрові.

Wprime 2.0

Відома утиліта для тестування багатоядерних процесорів визначає їх потужність, виробляючи певні обчислення. Чим менше часу витрачено на виконання тесту – тим кращий результат.

Найбільш спритним (що не дивно - з його тактовою частотою) виявився головний процесор сьогоднішнього тесту. Неприємно здивувало, що Core i5 2300 відстав майже на секунду від i5 760 (при однаковій частоті). Напевно позначився менший розміркеша третього рівня.

Fritz Chess Benchmar

А це тест, що визначає продуктивність процесора шляхом обробки різних шахових алгоритмів. У даному бенчмарку, чим більше очок - тим кращий результат.

"Старенька" Core i5 760 обігнали всі представники сімейства Sandy Bridge.

WinRAR 3.92

Даний архіватор не потребує представлення. Продуктивність визначатиметься кількістю КБ/с при стисканні певних файлів. Чим більше тим краще.

Картина як і в першому тесті, лідирує 2500К, за ним з великим відставанням йде 760-й, за два кроки від якого - i5 2300.

7-Zip 9.13

Ще один відомий архіватор, який я особисто багатьом порекомендував (тисне набагато краще, ніж RAR і ZIP, добре дружить з багатоядерними процесорамиі ОСями х64, плюс повністю безкоштовний) свого часу. Продуктивність розраховується так само, як у попередньому тесті.

Тест проходив у режимі компресії (перший графік) та декомпресії (другий) файлів. Добре видно, хто лідирує і наскільки.

Adobe Photoshop CS5

Знаменитий пакет для обробки графічних файлів Я не вловив як конкретно тестувалися процесори (є ідеї - висловіться), але давайте подивимося на результати:

Мабуть, результат за секунди. Чим менше тим краще. Лідирують "Піщані мости"

POV-Ray 3.7

POV-Ray - популярна програмаз відкритим кодом для тестування процесорів в операціях з точкою, що плаває. Кількість очок у тесті – це кількість відрендерених пікселів за секунду, чим їх більше, тим краще.

Ситуація із попереднього тесту повторюється. Зверніть увагу, яка перевага у i5 2300 перед i5 760 (нагадаю, що тактова частота у обох процесорів однакова)! Безперечно, нова архітектурапоказує характер. Чи допомагає Turbo-режим?

CineBench R11.5

"Синебенч" не потребує представлення, відмінний тест продуктивності процесора (як у режимі 1 потоку, так і кількох) в умовах 3Д рендерингу.

Картинка точнісінько така сама, як у попередніх кількох тестах. "Мости" попереду, 760-й – позаду. І перевага новинок дуже солідна.

H.264 Encoder V2

Кодування відео - завдання, для якої часто беруть потужні процесори. Чим менше часу йде на кодування відео в h264, тим краще.

Бідолаха 760-й! Sandy Bridge" і не дають йому ні шансу на перемогу. Вже хочу такий процесор (тільки хексакор, хоча б), краще відразу розігнаний до 4.5-5ГГц.

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

На жаль, не всі користувачі знають, що таке рейтинг AnTuTu, навіщо він потрібен і що означають дані в таблицях. Тим часом ця інформація дуже корисна і може надати вам реальну допомогупід час вибору нового пристрою. Що таке рейтинг AnTuTu, як ним користуватися та про що говорять результати проходження тесту – вам розкажуть експерти НОУ-ХАУ, поїхали!

Спочатку розберемо, що таке «синтетичні тести» і навіщо вони потрібні. Подібні програмиявляють собою перевірочні програми. Завантажити їх можна абсолютно безкоштовно фірмових магазинахдодатків для найпопулярніших мобільних ОС – Android та iOS.

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

Результати тестування відображаються у балах, чим більше балів – тим краще продуктивністьконкретного девайса і, відповідно, тим вища його позиція в загальному рейтингупристроїв.

Бали - це чудово, але виникає цілком логічне питання - як за їхньою кількістю визначити приблизну продуктивність девайсу?

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

Природно, що краще продуктивність пристрою – то вище його вартість, недарма флагманські рішення займають ТОП 10 рейтингу. Але є й інші категорії девайсів, у тому числі бюджетних, які забезпечують оптимальну продуктивність для виконання практично будь-яких завдань.

Умовно можна виділити кілька категорій за результатами тестування, що виражаються в діапазонах балів AnTuTu, які наведені в таблиці нижче.

Зведена таблиця оцінок AnTuTu та продуктивності

Підбиття підсумків

Синтетичний тест та рейтинг пристроїв AnTuTu – це прості та дуже зручні інструменти, які дозволяють визначити реальну продуктивність та можливості конкретного пристрою. Ці дані стануть в нагоді в процесі вибору нового смартфона або планшета.

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

Крім AnTuTu існують інші синтетичні тести для перевірки можливостей гаджетів. Але саме AnTuTu є найбільш популярним варіантом серед аналогічних програмзавдяки своїй простоті, універсальності, доступності та величезній базіданих, на основі яких регулярно коригуються таблиці рейтингу. Тому, якщо вам необхідно дізнатися про реальну продуктивність пристрою – синтетичний тест AnTuTu стане найкращим виборомдля перевірки можливостей девайсу.

Сподобалось?
Розкажіть друзям!

Пройшло досить багато часу з виходу операційної системи Microsoft Windows Vista та оновленого DirectX 10 API у її складі. Поступово з'являються ігрові програмиз підтримкою нової версії Direct3D 10, правда, поки це лише трохи перероблені D3D 9 додатки, активного використання нових можливостей D3D 10 у них немає. Та й ті ігри, що вже вийшли, дивують полярними результатами на відеокартах двох основних чіпмейкерів, використовувати їх у такому вигляді для порівняння, звичайно, можна, але дуже обережно.

Багато пакетів синтетичних і ігрових тестів з підтримкою Direct3D 10 поки теж не спостерігається, той же Futuremark так і не випустив черговий 3DMark. Але сайт має свій пакет синтетичних тестів, і ми давно планували оновити RightMark3D, щоб мати можливість оцінити пікову продуктивність D3D10-прискорювачів в різних завданнях. Остаточна версія RightMark3D 2.0 призначена Direct3D 10 сумісних прискорювачів в операційній системі MS Windows Vista, з'явилася нещодавно, і ми одразу приступаємо до її використання у наших матеріалах.

Деякі раніше відомі тестиу складі оновленого пакету було переписано під DX10, додалися нові види синтетичних тестів: модифіковані тести піксельних шейдерів, переписані під SM 4.0, тести геометричних шейдерів, тести вибірки текстур з вершинних шейдерів. Ця стаття буде першою за RightMark3D 2.0, вона включає великий набір протестованих відеокарт, далі ми почнемо використовувати новий тестта у своїх базових матеріалах.

Потрібно відзначити, що всі наші випробування - суто синтетичні, зазвичай вони використовують лише певні блоки відеочіпа, вплив продуктивності інших навмисно зменшено до мінімуму. У всіх тестах центральний процесорне задіяний, все вважається виключно відеочіпом. Приступимо до довгоочікуваних DirectX 10 тестів!

Умови тестування

Версія пакету синтетичних тестів RightMark3D 2.0, що використовується нами коротким описомтестів доступна для скачування по (4,5 Мбайт)

Для роботи RightMark3D 2.0 потрібно встановлений пакет MS Visual Studio 2005 runtime, а також останнє оновлення DirectX runtime.

Примітка: на скріншоті зображено спеціальну версію RightMark3D 2.0 з можливістю тестування в пакетному (batch) режимі. Вона призначена для внутрішнього використання та буде доступна пізніше.

Конфігурація тестового стенду:

• Комп'ютер на базі Intel Core 2 Duo (Socket 775)
  • процесор Intel Core 2 Duo Extreme X6800 (2930 МГц) (L2 = 4096K);
  • системна плата EVGA nForce 680i SLI на чіпсеті Nvidia nForce 680i;
  • оперативна пам'ять 2 GB DDR2 SDRAM Corsair 1142MHz (CAS (tCL) = 5; RAS to CAS delay (tRCD) = 5; Row Precharge (tRP) = 5; tRAS = 15);
  • жорсткий диск WD Caviar SE WD1600JD 160GB SATA;
  • блок живлення Tagan 1100-U95 (1100W).
• операційна система Windows Vista Ultimate 32-bit; DirectX 10;
• монітор Dell 3007WFP (30").
• драйвери ATI CATALYST версії 8.3891; Nvidia ForceWare версія 158.45.

Синтетичні тести проводились на відеокартах:

• RADEON HD 2900 XTзі стандартними параметрами
• RADEON HD 2600 XTзі стандартними параметрами
• RADEON HD 2600 PROзі стандартними параметрами (версія з GDDR3 відеопам'яттю)
• RADEON HD 2400 XTзі стандартними параметрами
• Geforce 8800 Ultraзі стандартними параметрами
• Geforce 8800 GTXзі стандартними параметрами
• Geforce 8800 GTSзі стандартними параметрами (версії з 320 та 640 Мбайт відеопам'яті показують близьку продуктивність)
• Geforce 8600 GTSзі стандартними параметрами
• Geforce 8600 GTзі стандартними параметрами
• Geforce 8500 GTзі стандартними параметрами

Для порівняння відеокарт один з одним будуть використовуватися пари моделей AMD і Nvidia, що збігаються за позиціонуванням на ринку: HD2900XT GF8800GTS, HD2600XT GF8600GT, HD2600PRO GF8500GT. Деяких із відеокарт на ринку ще немає, і якщо їх реальні цінибудуть іншими, потрібно робити виправлення до висновків статті. Ціни також змінюються, і з висновків статті справедливі лише час її виходу. Звичайно, це не стосується теоретичного порівняння молодших і старших чіпів однієї компанії, оцінка їхньої відносної продуктивності від цін не залежить.

Опис та результати тестів

Нагадуємо, що результати синтетичних тестів уніфікованих DirectX 10 архітектур потрібно аналізувати обережно, навантаження в них часто лежить лише на одному або двох типах шейдерів: вершинних, геометричних, піксельних. І якщо на звичайній архітектурі при збалансованому навантаженні на всі перераховані блоки продуктивність не знизиться, то на уніфікованій сумарна робота ляже відразу на все, і швидкість рендерингу впаде.

Тести піксельних шейдерів PS 4.0 (текстурування, цикли)

У нову версію RightMark3D 2.0, що використовується в цій статті, увійшли два вже знайомі нам PS 3.0 тести, найскладніші з наших синтетичних тестів піксельних шейдерів для Direct3D 9, а також два повністю нові тести. Перші були переписані під DirectX 10, також у них додалися самозатінення і можливість включення суперсемплінга, що ще більше збільшує і так чимале навантаження на відеочіпи.

• Furпроцедурний шейдер, що візуалізує хутро
• Steep Parallax Mapping«важкий» різновид техніки parallax mapping, що поки що не застосовується в іграх, раніше описана в статті

Ці два тести вимірюють продуктивність виконання піксельних шейдерів із циклами, при великій кількості текстурних вибірок (у найважчому режимі до кількох сотень вибірок на піксель!) та порівняно невеликому завантаженні ALU. Іншими словами, у них вимірюється швидкість текстурних вибірок та ефективність розгалужень у піксельному шейдері.

Першим тестом піксельних шейдерів буде Fur. При самих низьких налаштуванняху ньому використовується від 15 до 30 текстурних вибірок з карти висот та дві вибірки з основної текстури. Режим Effect detail "High" збільшує кількість вибірок до 40-80, включення "шейдерного" суперсемплінга - до 60-120 вибірок, а режим "High" спільно з SSAA відрізняється максимальною "вагою" - від 160 до 320 вибірок з карти висот. Виглядає це так:

Дуже складний тест, навіть судячи лише з опису. Подивимося, як із ним справляються всі доступні нам DirectX 10 відеокарти. Перевіримо спочатку режими без увімкненого суперсемплінгу, вони відносно прості, і співвідношення результатів у режимах Low і High повинно бути приблизно однаковим.

Перші тести процедурної візуалізації хутра з множинними текстурними вибірками зі складних шейдерів із циклами показують величезну перевагу відеокарт Nvidia над рішеннями AMD. Навіть чіпи середнього рівня Nvidia показують результати нарівні з топовим рішенням AMD, не кажучи про карти на чіпах G80, конкурентів яких тут немає взагалі. Отже, з цього тесту всі рішення Nvidia швидшевідповідних їм відеоплат AMD. Враховуючи те, що такого відставання не повинно бути теоретично, можна припустити, що в низьких результатах AMD великою мірою винні недороблені драйвери.

Цифри, показані в різних режимах, непогано співвідносяться один з одним результати в «High» приблизно в півтора рази нижче, ніж в «Low». Що стосується співвідношення продуктивності між топовими картами та картами середнього рівня, то можна сказати, що урізання виконавчих блоків досить сильно б'є по чіпах середнього та нижнього рівніву обох виробників, особливо це відноситься до рішень Nvidia (та й до AMD, якщо припущення про недоліки поточних версій драйвера вірно) G84 відстає від G80 рази в три, а G86 показує результат ще в два рази нижче. Судячи з цих цифр, продуктивність даного тестузалежить не тільки від кількості та швидкості блоків TMU, інакше різниця була б меншою.

Подивимося на результат цього тесту, але з включеним «шейдерним» суперсемплінгом, який збільшує обсяги робіт ще в чотири рази:

Така складність тесту під силу тільки топовим чіпам, показані значення частоти кадрів за секунду красномовно говорять про це. Загалом картина вимальовується приблизно така ж, що й у попередньому випадку, але явно видно, що в міру збільшення складності шейдера та навантаження на відеочіп рішення AMD починають наздоганяти відеокарти Nvidia. Geforce 8600 вже не виграє у HD 2900 XT, хоча і близький до нього, а Geforce 8500 GT починає навіть трохи програвати своєму конкуренту за ціновим діапазоном HD 2600 PRO.

Включення суперсемплінга теоретично збільшує навантаження рівно в чотири рази, але на відеокартах сімейства G8x воно знижує швидкість більш ніж у 5 разів, а на R6xx лише в 3 з невеликим, за рахунок чого останні в таких умовах і отримують поліпшені відносні результати. Швидше за все, при відповідному доопрацюванні драйверів Nvidia зможе знизити падіння продуктивності при включенні SSAA, але й у AMD є подібні можливості щодо покращення.

Другий тест, який вимірює продуктивність виконання складних піксельних шейдерів з циклами при великій кількості текстурних вибірок Steep Parallax Mapping. При низьких налаштуваннях він використовує від 10 до 50 текстурних вибірок з карти висот та три вибірки з основних текстур. При включенні важкого режиму з самозатінення число вибірок зростає вдвічі (від 20 до 100), суперсемплінг збільшує це число в чотири рази (від 40 до 200 вибірок). Найбільш складний тестовий режим із суперсемплінгом та самозатіненням використовує від 80 до 400 текстурних вибірок, тобто у вісім разів більше, порівняно з простим режимом.

Те ж саме перевіряємо спочатку прості варіантибез суперсемплінгу:

Другий тест більш цікавий з практичної точки зору, так як різновиди parallax mapping вже застосовуються в іграх, а важкі варіанти, на кшталт нашого steep parallax mapping, скоро будуть використовуватися. І в цьому тесті, окрім суперсемплінгу, можна включити самозатінення, яке збільшує навантаження на відеочіп приблизно вдвічі. Такий режим називається «High», а звичайний «Low».

У наших Direct3D 9 тестах parallax mapping, рішення ATI (а потім і AMD) традиційно були сильні, на цей раз виграшу не вийшло, навпаки, без включення суперсемплінгу чіпи Nvidia справляються із завданням швидше. Відразу відзначаємо і дещо більше падіння продуктивності при переході від режиму Low до High у відеокарт AMD. Зміна результатів при включенні самозатінення у рішень Nvidia дорівнює приблизно 1.5 рази, а у AMD більше двох разів. За рахунок цього результати в режимі High у останніх і виявляються відносно низькими. Загалом за результатами проведених тестів можна ще раз відзначити перемогу рішень Nvidia у всіх цінових діапазонах, особливо помітний виграш у верхньому сегменті.

Чіпи середнього та нижнього цінового діапазонівв цьому тесті показують себе приблизно так само або трохи краще: середні відстають від топових більш ніж удвічі, і в стільки ж разів відстають від середніх найслабкіші. Подивимося, що змінить включення суперсемплінга, у минулому тесті він викликав більше падіння швидкості на Nvidia, а це може покращити положення карт AMD.

За цифрами FPS вкотре можна оцінити складність наших завдань навіть для high-end рішень. Подивіться на отриману частоту кадрів в секунду при включених суперсемплінгу і самозатінення (останній графік), спільне включення їх збільшує навантаження майже у вісім разів, викликаючи катастрофічне падіння продуктивності. Різниця між швидкістю відеокарт із різних цінових сегментівзберігається.

Включення суперсемплінга позначається майже як і в попередньому випадку карти на чіпах AMD R6xx покращують свої показники щодо Nvidia G8x. Дивно, що у Nvidia вийшло падіння в 4 рази (рівно теоретичному), а у AMD тільки в 3 рази. Незважаючи на це, загальної перемоги AMD не виходить, хіба що в нижньому ціновому сегменті Geforce 8500 GT (G86) звично програє HD 2600 PRO (RV630). В решті пар констатуємо ще одну перемогу рішень Nvidia.

Тести піксельних шейдерів PS 4.0 (обчислення)

Наступна пара тестів піксельних шейдерів містить мінімум текстурних вибірок, це зроблено зниження впливу швидкості блоків TMU на загальну швидкість. Зате використовується дуже велика кількість арифметичних операцій(sin, cos, зведення у ступінь тощо). Ці тести вимірюють саме математичну продуктивність відеочіпів, швидкість виконання арифметичних інструкцій у піксельному шейдері. Вплив решти виконавчих блоків зведено до мінімуму.

Перший математичний тест - Mineral. Його можна назвати тестом складного процедурного текстурування, у ньому використовуються лише дві вибірки з текстурних даних та 65 інструкцій типу sin та cos, всього понад тисячу інструкцій на піксель.

Відповідно до результатів наших досліджень за допомогою минулої версіїпакета Direct3D 9 синтетичних тестів, у обчислювально складних задачах архітектура AMDпоказує себе дуже добре, всі їхні рішення випереджають конкурентів. Але Nvidia G8x відстають не так вже й сильно. Так, рішення AMD виявляються швидше у всіх цінових сегментах, але в high-end, найважливішому стратегічно, випередження невелике, особливо враховуючи, що Nvidia має і дорожчі рішення. Ось у нижньому та середньому сегментах рішення на чіпі G86 не може протистояти натиску нижнього RV630 і приблизно відповідає рішенню на основі RV610, а швидкий варіантна основі G84 відстає від верхнього RV630. Загалом, якщо враховувати реальні та передбачувані ціни всіх рішень, перемога цього разу за AMD.

Продуктивність рішень середнього рівня обох виробників у цьому тесті приблизно вдвічі нижча за швидкість найближчих топових, low-end чіпи виступають гірше ще вдвічі. Спостерігається традиційне співвідношення вже вкотре, у повній відповідності до урізання з погляду теорії, враховуючи і тактові частоти. Загалом, не все так погано у DirectX 10 чіпів середнього та нижчого рівнів… Хоча, в жодному разі не йдеться про максимальні налаштування майбутніх D3D 10 ігор, в них і high-end карт буде несолодко.

Другий тест цього блоку носить назву Fire, і він ще важчий для ALU. У ньому текстурна вибірка є лише одна, проте кількість інструкцій типу sin і cos збільшена до 130, всього більше тисячі інструкцій.

Дивимося, що змінилося зі збільшенням навантаження:

Відразу відзначаємо, що повноцінного порівняння в тесті «Fire» не виходить явна помилка в драйверах AMD, яка не дозволяє їх продукції показувати відповідні реальній силі результати. Перш ніж робити висновки, дочекаємось виправлень у драйверах.

Різниця між молодшим варіантів G80 і старшим G84 в черговий раз вийшла трохи більше двох разів, що відповідає різниці в частотах і кількості виконавчих блоків. Те саме стосується і low-end чіпа Nvidia.

Тести геометричних шейдерів

У пакет RightMark3D 2.0 включені два тести швидкості геометричних шейдерів різних умовах. Перший варіант носить назву Galaxy, техніка аналогічна point sprites з попередніх версій Direct3D. У ньому анімується система частинок на GPU, геометричний шейдер із кожної точки (всього від 0.5 до 2.0 мільйонів) створює чотири вершини, що утворюють частинку (quad expansion). Зважаючи на все, подібні алгоритми широко використовуватимуться в майбутніх DirectX 10 іграх, тому показані результати в тесті особливо цікаві.

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

Розглянемо перший варіант тесту Galaxy, з обчисленнями у вершинному шейдері, для трьох рівнів геометричної складності:

Видно, що співвідношення швидкостей за різної геометричної складності сцен вийшло приблизно однаковим для всіх умов, відрізняються тільки абсолютні значення. Продуктивність, що показується всіма рішеннями, повністю відповідає кількості точок, з кожним кроком падіння FPS становить близько двох разів. Відеокарти Nvidia в таких умовах почуваються трохи краще, показуючи великі результати у всіх порівнюваних парах: Geforce 8800 GTS швидше за HD 2900 XT, Geforce 8600 GT швидше за HD 2600 XT, Geforce 8500 GT швидше за HD 2600 PRO. Різниця хоч і невелика, але вона є.

Завдання не таке вже складне для сучасних відеокарт, Топові рішення трохи обігнали відеокарти середнього рівня, різниця не досягає і двох разів. Хоча low-end відстають від mid-end все в ті ж двічі. Можливо, при перенесенні частини обчислень до геометричного шейдера ситуація зміниться, як при порівнянні рішень різних виробників, і цінових сегментів. Нині ми це перевіримо.

Справді, відбулися певні зміни. Тепер рішення на базі чіпів G8x не завжди виграють у рішень на основі R6xx у всіх випадках із різною кількістю геометрії. Хоча Geforce 8600 GT все одно випереджає RADEON HD 2600 XT, а Geforce 8500 GT трохи випереджає HD 2600 PRO, топова відеокарта AMD виривається вперед. Цікаво, що між цифрами Geforce 8800 GTX та GTS майже немає різниці, хоча кількість активних виконавчих блоків у цих чіпів відрізняється. У результаті, AMD продовжує програвати, що трохи дивно, враховуючи високу ефективність виконання вершинних шейдерів їхніми чіпами. Подивимося, може бути у другому тесті результат зміниться.

«Hyperlight» - це другий тест геометричних шейдерів у новій версії RightMark3D, який демонструє використання відразу кількох цікавих технік: instancing, stream output, buffer load. У ньому використовується динамічне створеннягеометрії за допомогою малювання в два буфери, також цей тест використовує нову можливість DX10 stream output. Перший шейдер, що використовується, генерує напрямок променів, швидкість і напрямок їх зростання, ці дані поміщаються в буфер, який використовується другим шейдером для малювання. По кожній точці променя будуються 14 вершин по колу, до мільйона вихідних точок.

Новий тип шейдерних програм використовується для генерації «променів», а з параметром «GS load», виставленим у «Heavy» ще й для їх відмальовування. Тобто, в режимі "Balanced" геометричні шейдери використовуються тільки для створення і "зростання" променів, виведення здійснюється за допомогою "instancing", а в режимі "Heavy" виводом також займається геометричний шейдер. Спочатку розглядаємо легкий режим:

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

Велика перевага відеокарт Nvidia спостерігається і цього разу, коли навантаження на геометричні шейдери не таке велике. RADEON HD 2900 XT поступається навіть Geforce 8600 GT, а нижнє рішення Nvidia трохи випереджає HD 2600 XT. Про G80 і говорити не варто вони далеко попереду, і їх продуктивність явно обмежена чимось іншим, оскільки в порівнянні з G84 вони не дуже багато виграють.

Цікаво, що продуктивність HD 2400 XT майже дорівнює швидкості HD 2600 PRO і обидві цифри сильно відстають від HD 2600 XT, минулого разу такого не було. Всі ці цифри можуть змінитися в нашому тесті, де геометричні шейдери використовуються ще активніше. Особливо цікаво буде порівняти цифри, отримані в Balanced і Heavy режимах один з одним.

Погодьтеся, ситуація вийшла зовсім іншою! Можна чітко сказати, що чіпи серії AMD R6xx виконують таку роботу значно швидше. чіпів Nvidia G8x, маючи перевагу у 2 рази і навіть більше. Продуктивність даних тестів дуже залежить від складності роботи для геометричних шейдерів. Чіпи AMD виконують роботу не просто швидше рішень Nvidia, з ускладненням геометрії ця різниця зростає. Виходить, що чим складнішою є робота для геометричного шейдера, тим швидше будуть R6xx у порівнянні з G8x.

Але, порівнюючи результати у різних режимах, коли висновком займаються різні типиШейдерів, слід зазначити, що у Nvidia результати у «Balanced» вийшли краще, ніж у «Heavy» у AMD. При тому, що картинка, що виводиться, не відрізняється. Це в черговий раз загрожує розробникам 3D додатків тим, що їм доведеться оптимізувати свій код для двох різних архітектур, щоб домогтися максимальної продуктивності від обох.

При переході від використання «instancing» до геометричного шейдера при виведенні відеокарти Nvidia сильно втрачають у продуктивності від 2 до 6 разів. Причому чим молодший чіп, тим більша різниця у швидкості рендерингу між двома режимами. У AMD все навпаки, результати в режимі використання геометричного шейдера для виведення більше, ніж з «instancing», хай і не в рази. Виходить, що самі по собі геометричні шейдери при збільшенні роботи (кількості вершин, що генеруються) працюють краще на чіпах AMD, але реальність тим і відрізняється від синтетичних тестів, що розробники вільні вибирати свій шлях самі, і якщо використання для їх завдань вершинних шейдерів буде вигідніше, вони можуть так і зробити.

Вкрай цікава і різниця між швидкістю в режимах «Balanced» та «Heavy» для різних чіпіводнієї лінійки. Кумедна ситуація з порівнянням HD 2400 XT і HD 2600 PRO посилилася - тепер молодший чіп навіть виграє у старшого. І «винна» тут, швидше за все, більше висока частотамолодшого рішення та обмеження швидкості triangle setup. У Nvidia такого не спостерігається, всі чіпи показали результати строго по лінійці G84 повільніше G80 в 2-3 рази, а G86 в 4-6 рази. З HD 2600 PRO пов'язана ще одна загадка, пояснити яку не виходить тільки ця відеокарта виробництва AMD втрачає в продуктивності при зміні режиму з «Balanced» на «Heavy» в режимі з великою кількістю геометрії.

Потрібно відзначити і помилку в драйверах AMD, яка проявляється тільки на HD 2900 XT, викликаючи в найбільш складному режимі тесту «Hyperlight» відсутність картинки, що виводиться, і аномально високий результат, який не можна прийняти за коректний. Тому в останній діаграмі результату цієї відеокарти немає.

Головний висновок цієї частини - різні тести геометричних шейдерів можуть давати різні результати, в одних будуть лідирувати рішення Nvidia, в інших AMD. При зростанні складності роботи геометричного шейдера вперед виходить AMD, але потрібно пам'ятати, що це все синтетичні тести, про реальної продуктивностіможна буде судити лише з ігрових тестів, яких поки що вкрай мало, на жаль.

Швидкість вибірки текстур із вершинних шейдерів

У тестах Vertex Texture Fetch вимірюється швидкість великої кількостітекстурних вибірок із вершинного шейдера. Тести схожі один на одного, теоретично, співвідношення між швидкостями тестів «Earth» та «Waves» має бути приблизно однаковим. В обох тестах використовується виходячи з даних текстурних вибірок. Відмінність у цьому, що у тесті «Waves» використовуються умовні переходи, а «Earth» ні.

У першому тесті («Earth») робиться 32 (для режиму «Effect detail Low») або 48 («Effect detail High») білінійних текстурних вибірок на кожну вершину. Кількість вершин також можна змінювати, для трьох можливих режимівці числа відповідають: 30000, 124000 та 280000.

Розглянемо режим "Effect detail Low":

Усі три графіки показують приблизно однакову картину продуктивності відеокарт щодо один одного, хіба що продуктивність Geforce 8500 GT при збільшенні навантаження "просідає" швидше, ніж продуктивність конкуруючого HD 2600 PRO, якщо в "Low" виграє перша відеокарта, то в "High" попереду вже рішення AMD. У пари HD 2600 XT і Geforce 8600 GT все з точністю до навпаки, при невеликому навантаженні попереду рішення AMD, а в High воно вже трохи відстає. Серед топових рішень боротьби не вийшло, всі варіанти G80 швидше за R600.

Співвідношення між продуктивністю верхніх рішень і відеокарт середнього і нижчого рівнів залишається незмінним, до 2-3 разів між першими і 2-3 рази між другим. Цікаво лише занадто велика відмінність у продуктивності між HD 2600 PRO і HD 2600 XT, його не пояснити різною кількістю текстурних модулів (TMU), оскільки використовуються однакові чіпи. На результати тесту може впливати та пропускна здатністьпам'яті, яка у PRO та XT варіантів сильно відрізняється.

Подивимося на результати цього тесту зі збільшеною кількістю текстурних вибірок:

У цьому варіанті відеокарти AMD трохи втратили у швидкості щодо своїх суперників. У всіх конкуруючих парах переможцями стають рішення Nvidia, що мають більшу кількість текстурних модулів, що ефективно працюють. Різниця між AMD та Nvidia у зазначених умовах становить до 1.5-2 разів. Відеочіпи Nvidia явно ефективніше виконують вибірку текстурних даних, якщо виходити з тестів і вершинних та піксельних шейдерів.

Подивимося результати другого тесту VTF, цікаво, чи виявляться там подібні проблеми? Тест «Waves» відрізняється меншою кількістю вибірок, проте використовуються умовні переходи. Кількість білінейних текстурних вибірок у разі до 14 («Effect detail Low») чи до 24 («Effect detail High») на кожну вершину. Складність геометрії змінюється аналогічно попередньому тесту, загальна кількість вершин може дорівнювати приблизно 124000, 498000 і 1122000 для режимів «Polygon count Low», «Medium» і «High», відповідно.

«Waves» не показує нам чогось нового, приблизно так само, як і в попередньому тесті «Earth». Видно, що деякі чіпи Nvidia (G80 і G86) втрачають кадри в секунду зі зростанням складності геометрії трохи швидше, ніж конкуренти від AMD (R600 і RV630), але найкращими в більшості випадків все одно є рішення Nvidia.

Останні результати також приблизно відповідають показаним у попередніх випадках, лише перевага рішень Nvidia видно трохи краще. В цілому добре видно, що відеокарти на основі чіпів Nvidia G8x виконують наші тести текстурних вибірок з вершинних шейдерів швидше, ніж рішення AMD на основі архітектури R6xx. Це і є основний висновок із цієї серії VTF тестів.

Висновок та висновки щодо синтетичних тестів

Отже, дебют застосування RightMark3D 2.0 для досліджень на нашому сайті відбувся. Тести в його складі торкаються майже всіх аспектів нововведень в Direct3D 10, вони гнучко налаштовуються, дозволяючи нам оцінити порівняльну продуктивність всіх лінійок Direct3D 10 чіпів від AMD та Nvidia. Обидві уніфіковані архітектури цих компаній показали себе в нових Direct3D 10 тестах цілком непогано, великих провалів продуктивності не виявлено, за винятком пари випадків з явними помилками в драйверах AMD. Обидва сімейства: R6xx і G8x відрізняються високою обчислювальною та текстурною продуктивністю, вони добре справляються зі складними шейдерами всіх типів.

• Якщо брати результати в цілому, то рішення Nvidia мають деяку перевагу перед конкурентами від AMD, на Наразіїх відеокарти виявляються попереду здебільшого. Але в деяких тестах чіпи AMD показують найкращі результати, наприклад, у складних тестах геометричних та піксельних шейдерів. Перевага чіпів AMD у таких тестах зі збільшенням навантаження навіть зростає. Отже результат битви в DirectX 10 іграх поки що не визначений, не можна сказати однозначно, хто з суперників його виграє. Можна лише припустити, що там будуть аналогічні нашим результати в основному додатків R6xx і G8x будуть близькі один до одного, в деяких будуть лідирувати рішення на основі рішень компанії Nvidia, в інших AMD. І залежатиме це багато в чому від розробників і від методів і алгоритмів, що використовуються.
• Тести піксельних шейдерів версії 4.0 показали, що з множинними текстурними вибірками за порівняно невеликого завантаження ALU краще справляються відеочіпи Nvidia. Рішення AMD, своєю чергою, випереджають конкурентів у обчислювальних тестах піксельних шейдерів. В одному з них відеокарти на основі чіпів архітектури R6xx показали дуже непогані результати і випередили конкурентів зі стану Nvidia, а ситуація в другому тесті поки не зрозуміла через помилки в драйверах.
• Як ми вже зазначали, тести геометричних і вершинних шейдерів дають різні результати, в одних лідирують рішення Nvidia, в інших AMD. Так як при зростанні складності роботи для геометричного шейдера вперед виходять відеокарти AMD, то можна припустити, що в додатках з активним використанням геометричних шейдерів, якщо з'являться найближчим часом, будуть лідирувати чіпи цієї компанії.
• Остання пара тестів RightMark3D 2.0 - тести на швидкість вибірки текстур з вершинних шейдерів. Показані в них результати чітко свідчать, що відеокарти на основі чіпів Nvidia G8x виконують наші тести текстурних вибірок з вершинних шейдерів швидше, ніж рішення AMD на основі архітектури R6xx. Це з традиційно різним балансом між текстурними і обчислювальними можливостями у чіпів двох конкуруючих компаній.
• «Урізання» кількості шейдерних блоків, блоків TMU та ROP досить суттєво вдарило по рішенням середнього та нижчого рівнів, значно знизивши їхню продуктивність. Недорогі відеокарти відстають від топових в рази, найкращі з mid-end в 2-3 рази (від HD 2900 XT і Geforce 8800 GTS), а low-end ще більше - до 4-8 разів. Що підтверджується і результатами ігрових тестів поки що тільки Direct3D 9.
• Судячи з отриманих нами результатів, драйвери AMDдля Vista явно гірше доопрацьовано в порівнянні з драйверами Nvidia. Якщо у продукції другої компанії у наших тестах жодних помилок не було виявлено, то у рішень AMDспостерігалися дві явні проблеми: у всієї лінійки чіпів у другому обчислювальному тесті піксельних шейдерів (Fire), а також у топового рішення HD 2900 XT в найбільш складному режимі тесту на швидкість вибірки текстур з вершинних шейдерів Earth. Дуже хотілося б вірити, що ці недоліки будуть усунуті у найближчих версіях драйверів CATALYST.

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

Нещодавно Bill Torpey написав у своєму блозі замітку "Even Mo" Static ", де розповів, як, на його погляд, показали себе інструменти Cppcheck і PVS-Studio при аналізі проекту itc-benchmarks. Проект itc-benchmarks - це static analysis benchmarks від Toyota ITC.

Мені не сподобалося, що після прочитання статті складається враження, що аналізатори Cppcheck та PVS-Studio приблизно рівні у своїх можливостях. Зі статті випливає, що один аналізатор показує себе краще в одному, другий в іншому, але в цілому їх діагностичні можливості схожі.

Я гадаю, що це не так. Моя думка - наш аналізатор PVS-Studio у кілька разів потужніший, ніж Cppcheck. І взагалі, це не «думка», я знаю це!

Однак, якщо з боку не видно, що PVS-Studio в 10 разів краще за Cppcheck, то треба спробувати зрозуміти причину. Я вирішив подивитися на цей itc-benchmarks і розібратися, чому PVS-Studio показав себе на цій тестовій базі не найкращим чином.

Чим далі я розбирався, тим більше роздратування я відчував. А один приклад зовсім вивів мене з рівноваги, і про нього розповім трохи нижче. Мої висновки такі: я не маю претензій до Bill Torpey. Він написав добру, чесну статтю. Дякую, Bill. Натомість у мене є претензії до Toyota ITC. Моя особиста думка: їхня тестова база - хрень. Це, звичайно, гучна заява, але я вважаю, що маю достатню кваліфікацію та досвід, щоб міркувати про статичні аналізатори коду та способи їх оцінки. На мою думку, itc-benchmarks не може бути використаний для адекватної оцінки можливостей того чи іншого аналізатора.

А ось власне тест, який остаточно вивів мене із душевної рівноваги.

Так що ж виходить, PVS-Studio на цьому прикладі слабше, ніж Cppcheck? Ні, він якраз сильніший!

Аналізатор PVS-Studio розуміє, що цей код написаний свідомо, і ніякої помилки тут немає.

Бувають ситуації, коли аналогічний код пишуть спеціально, щоб домогтися виникнення виключення під час розіменування нульового покажчика. Таке можна зустріти у тестах чи специфічних ділянках коду. Подібний код ми зустрічали неодноразово. Ось, наприклад, як таке може виглядати в реальному проекті:

Void GpuChildThread::OnCrash() ( LOG(INFO)<< "GPU: Simulating GPU crash"; // Good bye, cruel world. volatile int* it_s_the_end_of_the_world_as_we_know_it = NULL; *it_s_the_end_of_the_world_as_we_know_it = 0xdead; }
Тому в аналізаторі PVS-Studio в діагностиці V522 реалізовано кілька винятків, щоб не лаятися на такий код. Аналізатор бачить, що null_pointer_001є несправжньою функцією. Не буває в реальному коді помилок у функціях, коли нуль записують в покажчик і відразу розіменовують. Та й ім'я функції говорить аналізатору, що «нульовий покажчик» тут недарма.

Для подібних випадків у діагностиці V522 реалізовано виняток A6. Під нього ж потрапляє синтетична функція null_pointer_001. Ось як небезпечний виняток A6:

Розіменування змінної перебуває у функції, у назві якої є одне із слів:

• error
• default
• crash
• null
• test
• violation
• throw
• exception

У цьому, змінної присвоюється 0 рядком вище.

Синтетичний тест повністю підійшов під цей виняток. По-перше, у назві функції є слово "null". По-друге, привласнення нуля змінної відбувається якраз на попередньому рядку. Виняток виявило несправжній код. І код справді не справжній, це синтетичний тест.

Ось через подібні нюанси я і не люблю синтетичні тести!

У мене є itc-benchmarks та інші претензії. Наприклад, все в тому ж файлі, ми можемо бачити такий тест:

Void null_pointer_006 () ( int *p; p = (int *)(intptr_t)rand(); *p = 1;
Функція randможе повернути 0, який потім перетвориться на NULL. Аналізатор PVS-Studio поки що не знає, що може повернути randі тому не бачить у цьому коді нічого підозрілого.

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

Але не бійтеся. Я заявляю, що ми, як і раніше, працюватимемо над справжніми хорошими діагностиками, а не займатимемося припасуванням аналізатора під тести. Мабуть, ми трохи підретушуємо PVS-Studio для itc-benchmarks, але у фоновому режимі і тільки в тих місцях, які мають хоч якийсь сенс.

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

До речі, якщо функція randповерне не 0, а 1400 краще не буде. Все одно такий покажчик розіменовувати не можна. Отже розіменування нульового покажчика якийсь дивний окремий випадок абсолютно некоректного коду, який просто був вигаданий і який не зустрічається в реальних програмах.

Мені відомі справжні програмістські біди. Наприклад, це друкарські помилки, які ми виявляємо сотнями, скажімо, за допомогою діагностики V501. Що цікаво, в itc-benchmarks я не помітив жодного тесту, де перевірялося, чи може аналізатор виявити друкарську помилку виду «if (a.x == a.x)». Жодного тесту!

Таким чином, itc-benchmarks ігнорує можливості аналізаторів пошуку помилок. А читачі наших статей знають, як це поширені помилки. Натомість містить, на мою думку, безглузді тестові кейси, які в реальних програмах не зустрічаються. Я не можу уявити, що в цьому серйозному проекті можна зустріти такий код, який призводить до виходу за кордон масиву:

Void overrun_st_014 () ( int buf; int index; index = rand(); buf = 1;
Мабуть, таке можна зустріти хіба що у лабораторних роботах студентів.

При цьому я знаю, що в серйозному проекті легко зустріти друкарську помилку:

Return (!strcmp (a->v.val_vms_delta.lbl1, b->v.val_vms_delta.lbl1) && !strcmp (a->v.val_vms_delta.lbl1, b->v.val_vms_delta.lbl1));
Цю помилку аналізатор PVS-Studio