Две средние видеокарты вместо одной топовой. Компьютерный ресурс У SM

Мне не нравится, когда кто-то пытается использовать созданные вручную примеры кода для оценки возможностей статического анализатора кода. Сейчас на конкретном примере я продемонстрирую, почему негативно отношусь к синтетическим тестам.

Не так давно Bill Torpey написал в своем блоге заметку "Even Mo" Static ", где рассказал, как, на его взгляд, показали себя инструменты Cppcheck и PVS-Studio при анализе проекта itc-benchmarks . Проект itc-benchmarks - это static analysis benchmarks from 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 понимает, что этот код написан сознательно и никакой ошибки здесь нет.

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

Поэтому в анализаторе 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; /*Tool should detect this line as error*/ /*ERROR:NULL pointer dereference*/ }

Функция 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; /*Tool should detect this line as error*/ /*ERROR: buffer overrun */ sink = buf; }

Пожалуй, такое можно встретить разве только в лабораторных работах студентов.

При этом я знаю, что в серьезном проекте легко встретить опечатку вида:

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 нашел в коде компилятора GCC. Два раза сравниваются одни и те же строки.

Получается, что тесты на поиск экзотического кода с rand есть, а на классические опечатки нет.

Предлагаю всем установить и попробовать мощнейший анализатор кода PVS-Studio .

База реальных ошибок , найденных с помощью PVS-Studio в открытых проектах.
Мифы о статическом анализе. Миф пятый – можно составить маленькую программу, чтобы оценить инструмент.

Я думаю, что это не так. Мое мнение - наш анализатор PVS-Studio в несколько раз мощнее, чем Cppcheck. И вообще, это не «мнение», я знаю это!

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

Так что же получается, 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; /*Tool should detect this line as error*/ /*ERROR:NULL pointer dereference*/ }
Функция rand может вернуть 0, который затем превратится в NULL. Анализатор PVS-Studio пока не знает, что может вернуть rand и поэтому не видит в этом коде ничего подозрительного.

Я попросил коллег научить анализатор лучше понимать, что из себя представляет функция rand . Деваться некуда, придётся подточить напильником анализатор, чтобы он лучше себя показывал на рассматриваемой тестовой базе. Это вынужденная мера, раз для оценки анализаторов используют подобные наборы тестов.

Я хочу, чтобы разработчики понимали, что пример с rand ничего на самом деле не оценивает. Это синтетический тест, который высосан из пальца. Не пишут так программы. Нет таких ошибок.

Кстати, если функция rand вернёт не 0, а 1400 лучше не будет. Все равно такой указатель разыменовывать нельзя. Так что разыменование нулевого указателя какой-то странный частный случай совершенно некорректного кода, который просто был выдуман и который не встречается в реальных программах.

Void overrun_st_014 () { int buf; int index; index = rand(); buf = 1; /*Tool should detect this line as error*/ /*ERROR: buffer overrun */ sink = buf; }
Пожалуй, такое можно встретить разве только в лабораторных работах студентов.

При этом я знаю, что в серьезном проекте легко встретить опечатку вида:

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

Методика тестирования

Настройки AMD Catalyst Control Center
Antialiasing	Use application settings
Anisotropic Filtering	Use application settings
Tesselation	Use application settings
Catalyst A.I., Texture Filtering Quality	Quality, Enable Surface Format Optimization
Mipmap Detail Level	Quality
Wait for V-Sync	Off, unless application specifies
Anti-Aliasing Mode	Multi-sample AA
Direct3D Settings, Enable Geomery Instancing	On
Triple buffernig	Off
Настройки NVIDIA Control Panel
Ambient Occlusion	Off
Anisotropic Filtering	Application-controlled
Antialiasing — Gamma correction	On
Antialiasing — Mode	Application-controlled
Antialiasing — Settings	Application-controlled
Antialiasing — Transparency	Off
CUDA — GPUs	All
Maximum pre-rendered frames	3
Multi-display/mixed-GPU acceleration	Multiple display performance mode
Power management mode	Adaptive
Texture filtering — Anisitropic sample optimization	Off
Texture filtering — Negative LOD bias	Allow
Texture filtering — Quality	Quality
Texture filtering — Trilinear optimization	On
Threaded optimization	Auto
Triple buffering	Off
Vertical sync	Use the 3D application settings

Набор бенчмарков
Программа	API	Настройки	Режим тестирования	Разрешение
3DMark 2011	DirectX 11	Профиль Extreme	-	-
3DMark	DirectX 11	Тест Fire Strike (не Extreme)	-	-
Unigine Heaven 2	DirectX 11	DirectX 11, макс. качество, тесселяция в режиме Extreme	AF 16x, MSAA 4x	1920х1080 / 2560х1440
Crysis Warhead + Framebuffer Crysis Warhead Benchmarking Tool	DirectX 10	DirectX 10, макс. качество. Демо Frost Flythrough	AF 16x, MSAA 4x	1920х1080 / 2560х1440
Metro 2033 + Metro 2033 Benchmark	DirectX 11	DirectX 11, макс. настройки, DOF, тесселяция, NVIDIA PhysX выкл.	AF 16x, MSAA 4x	1920х1080 / 2560х1440
Crysis 2 + Adrenaline Crysis 2 Benchmark Tool	DirectX 11	DirectX 11, макс. качество, текстуры высокого разрешения. Миссия A Walk in the Park	AF 16x, Post MSAA + Edge AA	1920х1080 / 2560х1440
Far Cry 3 + FRAPS	DirectX 11	DirectX 11, макс. качество, HDAO. Начало миссии Secure the Outpost	AF, MSAA 4x	1920х1080 / 2560х1440
Battlefield 3 + FRAPS	DirectX 11	Макс. качество. Начало миссии Going Hunting	AF 16x, MSAA 4x + FXAA	1920х1080 / 2560х1440
Crysis 3 + FRAPS	DirectX 11	Макс. качество. Начало миссии Post Human	AF 16x, MSAA 4x	1920х1080 / 2560х1440
Batman: Arkham City. Встроенный бенчмарк	DirectX 11	Макс. качество	AF, MSAA 4x	1920х1080 / 2560х1440
DiRT Showdown. Встроенный бенчмарк	DirectX 11	Макс. качество, Global Illumination вкл. Трасса Shibuya, 8 машин	AF, AA 4х	1920х1080 / 2560х1440

⇡ Производительность, синтетические тесты

Результаты всех четырех подопытных конфигураций оказались неожиданно хорошими.
Паре Radeon HD 7850 удалось превзойти Radeon HD 7970 GHz Edition.
И даже тандем HD 7790 сработал быстрее, чем HD 7950, почти что на уровне HD 7970.
Обе пары видеокарт NVIDIA оказались более производительными, чем соперники от AMD.
Двух GTX 650 Ti BOOST достаточно, чтобы побить результат GTX 680, а тандем GTX 660 справился даже с GTX 770 и подбирается к GTX 780!

По показателю Graphics Score пара Radeon HD 7790 недалеко ушла от единственного Radeon HD 7970 GHz Edition, оставив позади базовую версию этой карточки.
Тандем HD 7850 повторил этот результат с гораздо большим отрывом от HD 7970 GHz Edition.
Система на базе двух 650 Ti BOOST продемонстрировала мизерное преимущество перед парой HD 7790 несмотря на вдвое больший объем кадрового буфера. Зато уверенно побеждает GeForce GTX 680.
Разница в результатах между парой GTX 660 и HD 7850 также минимальна, хотя и в пользу GTX 660. И вновь эта конфигурация посрамила одиночный GTX 770, приближаясь к GTX 780.

Unigine Heaven 2 (DirectX 11)

Тест Unigine Heaven добавил новые достижения в актив «двухголовых» систем. Два HD 7790 работают не менее быстро, чем один HD 7970 GHz Edition.
А пара HD 7850 — даже быстрее, причем намного, на уровне GeForce GTX 770 (который здесь обходит флагманскую карту AMD).
Видеокарты NVIDIA оказались еще эффективнее конкурентов от AMD. Две GTX 650 Ti BOOST обошли систему на базе HD 7850, а также одиночный GeForce GTX 770.
Тандем GTX 660 занял позицию в промежутке между GTX 770 и GTX 780.

⇡ Производительность, игровые тесты

Crysis Warhead (DirectX 10)

Сборку HD 7790 подвел небольшой объем набортной памяти. При разрешении 1920х1080 ей удалось добиться победы над Radeon HD 7950, но в режиме 2560х1440 производительность не дотягивает даже до уровня GeForce GTX 670.
Двух гигабайт памяти и вычислительной мощности GPU на платах Radeon HD 7850 достаточно для триумфа над Radeon HD 7970 GHz Edition. Такая система недалеко ушла и от GeForce GTX 780.
Тандем GeForce GTX 650 Ti BOOST уступает двум HD 7850 в режиме CrossFireX. Но это не мешает ему иметь большую производительность, чем у одиночного GTX 770.
GTX 660 в SLI имеют результаты, близкие к показателям связки Radeon HD 7850. И соответственно, мало отличаются от GeForce GTX 780.

Metro 2033 (DirectX 11)

Тандем HD 7790 потерпел сокрушительное поражение, и все по той же причине — недостаточный объем видеопамяти. Даже при разрешении 1920х1080 совокупная производительность двух таких видеокарт позволяет выйти лишь на уровень одиночного GeForce GTX 670. При разрешении 2560х1440 фреймрейт и вовсе не превышает 1 FPS.
Система на базе Radeon HD 7850 лишена такого ограничения и с легкостью побеждает одиночный Radeon HD 7970 GHz Edition вместе с GeForce GTX 770.
Тандем GeForce GTX 650 Ti BOOST мощнее обеих «двухголовых» конфигураций AMD, а также одиночных Radeon HD 7970 GHz Edition и GeForce GTX 770.
Пара GTX 660 в состоянии бросить вызов одному GeForce GTX 780.

Crysis 2 (DirectX 11)

В связи с тем, что при разрешении 1920х1080 частота смены кадров большинства участников тестирования уперлась в присущий этой игре лимит 100 FPS, все последующие комментарии относятся к тестам в режиме 2560х1440.
Здесь сборка HD 7790 быстрее, чем HD 7950, но не достигает даже уровня базовой версии Radeon HD 7970, не говоря уже об HD 7970 GHz Edition.
Два HD 7850 уже в состоянии свергнуть с престола флагманскую видеокарту AMD.
GeForce GTX 650 Ti BOOST добился примерно того же результата, что и HD 7850. Между прочим, это уровень GeForce GTX 770.
Два GTX 660 в конфигурации SLI вновь угрожают гегемонии GeForce GTX 780.

Far Cry 3 (DirectX 11)

Тандем Radeon HD 7790 вновь страдает от недостаточного объема RAM. При разрешении 1920х1080 производительность такой конфигурации превышает уровень Radeon HD 7950 и приближается к уровню HD 7970. Но в режиме 2560х1440 на экран выводится слайд-шоу.
Два HD 7850 уже в который раз превосходят одиночный Radeon HD 7970 GHz Edition.
Сборка GeForce GTX 650 Ti BOOST работает немного быстрее, чем пара Radeon HD 7850. И даже этих двух карточек достаточно, чтобы побороть одиночный GeForce GTX 770.
И это свершилось: связка GeForce GTX 660 наконец-то смогла побить GeForce GTX 780.

Crysis 3 (DirectX 11)

В Crysis 3 имеем совершенно предсказуемый провал тандема Radeon HD 7790 при разрешении 2560х1440 и разочаровывающую производительность при 1920х1080.
Два Radeon HD 7850 вместе в очередной раз обогнали Radeon HD 7970 GHz Edition.
Результаты сдвоенных систем на базе NVIDIA снова наверху. Пара GeForce GTX 650 Ti BOOST опередила GeForce GTX 770.
Два GeForce GTX 660 практически не уступают единственному GeForce GTX 780.

Battlefield 3 (DirectX 11)

Тандем HD 7790 неплох для игры в режиме 1920х1080, где он не уступает Radeon HD 7970. Но при разрешении 2560х1440 производительность падает катастрофически.
Пара HD 7850 — достаточно мощная сборка, чтобы обойти как Radeon HD 7970 GHz Edition, так и GeForce GTX 770.
То же относится и к системе на базе GeForce GTX 650 Ti BOOST, результаты которой близки к результатам предыдущей.
Тандем GeForce GTX 660 вновь отличился, показав производительность на уровне одиночного GeForce GTX 780.

Batman: Arkham City (DirectX 11)

В Batman: AC поражение систем на платформе AMD было предопределено, поскольку технология CrossFireX в этой игре попросту не работает.
Связка GeForce GTX 650 Ti BOOST выступает не хуже Radeon HD 7970 GHz Edition. Но GeForce GTX 680 удерживает первенство в режиме 1920х1080.
Пара GTX 660 вышла на уровень GTX 770 при разрешении 2560х1440, но уступает последнему при разрешении 1920х1080.

DiRT Showdown (DirectX 11)

Два HD 7790 в режиме 2560х1440 не уступают модели HD 7970, а в 1920х1080 сравнимы с HD 7970 GHz Edition.
Тандем HD 7850 с небольшой натяжкой можно признать равным HD 7970 GHz Edition в 2560х1440, а в 1920х1080 он уже явно быстрее одиночной видеокарты.
Движок DiRT Showdown отдает явное предпочтение GPU AMD, поэтому обе двухпроцессорные конфигурации NVIDIA безнадежно отстали от конкурентов на базе AMD.
Связка GeForce GTX 650 Ti BOOST не может справиться даже с одиночным Radeon HD 7950. Зато опережает GeForce GTX 770.
Ну а тандем GTX 660 расположился на отметке между HD 7950 и HD 7970, а также мало отличается от GeForce GTX 780.

⇡ Энергопотребление

Связка Radeon HD 7790 оказалась более экономичным вариантом, чем единственный адаптер Radeon HD 7950, который ей стабильно проигрывает при условии, что тест не упирается в объем видеопамяти.
Система на базе HD 7850 также преподнесла сюрприз, на поверку оказавшись менее требовательной, чем как HD 7970, так и HD 7970 GHz Edition. Даже относительно скромный в плане энергопотребления GeForce GTX 680 и то показал большую мощность.
Система, заряженная двумя GTX 650 Ti BOOST либо двумя GTX 660, имеет неизменное энергопотребление. Что не удивительно, ибо в этих видеокартах применяется один и тот же GPU, работающий на одной и той же частоте. Обе конфигурации по максимальной мощности превосходят такие прожорливые видеокарты, как Radeon HD 7970 GHz Edition, GeForce GTX 770 и GTX 780.

⇡ Выводы

Практические замеры производительности систем с двумя видеокартами среднего класса в режиме SLI или CrossFireX нас нешуточно удивили. Честно говоря, изначально тестирование задумывалось исключительно как курьезный эксперимент, лишенный какого-либо практического смысла. А выяснилось, что средства распараллеливания нагрузки на несколько GPU при 3D-рендеринге уже настолько вылизаны, что две видеокарты из ценовой категории для прижимистых геймеров запросто опережают по производительности один мощный флагманский (или недавно бывший таковым) видеоадаптер.

Комбинация пары Radeon HD 7790, казалось, уж точно была обречена на неудачу. Ну что могут противопоставить флагманским адаптерам два GPU Bonaire, в которых совокупное количество потоковых процессоров и текстурных модулей меньше, чем у HD 7970 с чипом Tahiti XT, да еще и со скромной шиной памяти разрядностью 128 бит? Оказывается, в двух HD 7790 достаточно пороху, чтобы отбросить HD 7950 и на равных биться c HD 7970. Но только при одном важном условии, что игре достаточно скромного кадрового буфера объемом 1 Гбайт (напомним, в CrossFireX, как и в SLI, объемы памяти двух видеокарт не складываются). Ибо если его недостаточно, то всё преимущество от второго GPU сводится на нет необходимостью гонять данные из системной памяти по шине PCI-Express, пусть даже версии 3.0

Адаптеры Radeon HD 7850 избавлены от такого ярма, поскольку, согласно официальным спецификациям, комплектуются 2048 Мбайт RAM. Такого объема пока хватает для игры с самыми хардкорными настройками при разрешении 2560х1440, хоть и хватает в обрез. В результате в большинстве бенчмарков независимо от разрешения связка двух HD 7850 как минимум эквивалентна одиночной карте Radeon HD 7970 GHz Edition. Это не только совершенно неожиданный результат, но и возможность реально сэкономить деньги. Десять тысяч рублей за два самых дешевых варианта HD 7850 — это, согласитесь, заметно меньше, чем 14 тысяч за HD 7970 GHz Edition. К тому же, как ни странно, тандем потребляет меньше энергии по сравнению с одиночным флагманом AMD.

Не менее впечатляют результаты «двухголовых» конфигураций на платформе NVIDIA. Сборка двух GeForce GTX 650 Ti BOOST почти никогда не уступает бывшему флагману NVIDIA — GTX 680 — и нередко достигает уровня GeForce GTX 770. Впрочем, GTX 650 Ti BOOST и находится в более выгодном положении, чем его ближайший соперник из стана AMD — Radeon HD 7790: по количеству ядер CUDA и текстурных блоков это ровно половина чипа GK104, лежащего в основе GTX 680 и GTX 770, шина памяти — 192 бит, а объем — 2 Гбайт. Опять-таки можно сэкономить небольшую сумму, купив два GTX 650 Ti BOOST (примерно 10 500 руб.) вместо единственного GTX 680 или тем паче GTX 770.

Два GeForce GTX 660 в режиме SLI выглядели наиболее жизнеспособной из всех четырех тестовых комбинаций, ибо в совокупности два ядра GK106 с полностью функциональными вычислительными блоками по сравнению с GTX 680 имеют неплохой запас теоретической производительности. Но коль скоро даже более слабые связки составили серьезную конкуренцию одиночным видеокартам высшей категории, то неудивительно, что тандем GTX 660 стабильно опережает GeForce GTX 770 и несколько раз поравнялся с GeForce GTX 780. Увы, сменив мощный адаптер на два GTX 660, придется поступиться энергетической эффективностью, ибо две такие видеокарты потребляют больше. А стало быть, сильнее греются и наверняка сильнее шумят.

С одной стороны, за столь впечатляющие результаты надо поблагодарить программистов, которые точат и точат без устали драйверы GPU и игровые движки под SLI и CrossFireX. С другой — фактором успеха «двухголовых» систем могла стать чисто аппаратная особенность, связанная с шинами памяти. Коль скоро два GPU в тандеме работают с копиями одних и тех же данных, их можно уподобить одному процессору с количеством вычислительных блоков, примерно соответствующим оному у более крупных чипов этого же производителя. Но если GPU Tahiti имеет 384-битную шину памяти, то два GPU Pitcairn уже набирают в совокупности 512 бит. Или возьмем GK104 от NVIDIA. Он имеет 256-битную шину, а два GK106 вместе дают 384 бит. Впрочем, автор статьи не берется утверждать, что такое представление на самом деле корректно с точки зрения архитектуры SLI или CrossFireX.

Возвращаясь к практической стороне вопроса, мы все-таки не осмелимся рекомендовать две бюджетные видеокарты в качестве универсальной замены видеоадаптеров категории « для энтузиастов» . Использование SLI или CrossFireX все еще не гарантирует одинаково эффективного масштабирования производительности во всех играх. Взгляните на диаграмму Batman: Arkham City, где CrossFireX не работает по причинам либо технологического, либо политического характера. Наверняка есть и обратные примеры, когда не работает уже SLI. Кроме того, встречаются неприятные проблемы, специфические именно для CrossFireX (сильный разброс частоты смены кадров и разрывы картинки), с которыми AMD все ещё борется. Но если есть желание немного рискнуть, попробовать необычное сочетание железа и попутно сэкономить пару тысяч рублей, то пожалуйста. И конечно же, покупка второго бюджетного адаптера в дополнение к старому открывает для экономных геймеров заманчивые перспективы апгрейда малой кровью.

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

Так что же получается, PVS-Studio на этом примере слабее чем Cppcheck? Нет, он как раз сильнее!

Анализатор PVS-Studio понимает, что этот код написан сознательно и никакой ошибки здесь нет.

Разыменование переменной находится в функции, в названии которой есть одно из слов:

error
default
crash
null
test
violation
throw
exception

При этом, переменной присваивается 0 строчкой выше.

Вот из-за подобных нюансов я и не люблю синтетические тесты!

У меня есть к itc-benchmarks и другие претензии. Например, всё в том же файле, мы можем видеть вот такой тест:

При этом я знаю, что в серьезном проекте легко встретить опечатку вида:

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

Прошло довольно много времени с выхода операционной системы 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 MHz) (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.