Diamond Viper 2 Z200

Особенности

• AGP 4X с Side Band Adressing (активируется перемычкой на плате);
• S3TL (пока только в OpenGL T&L, нужно включать самим);
• Битекстурирование и квадротекстурирование, возможна поддержка тритекстурирования (наложение трёх текселов на пиксел в режиме работы;
• Работает а 32-bit с 32-bit 8888 RGBA текстурами до 2048x2048;
• 24-битный z-буфер, 8-битный Stencil буфер;
• Поддержка S3TC (во всех API);
• Поддержка драйвером AGP-текстурирование в D3D и OpenGL (это очень важно в дальнейшем при тестах Q3D.DM3);
• Компенсация потока, 16-точечное масштабирование видео (для сравнения 8-ми точечное у Creative Dxr3).

S3TL - заявленный блок геометрической обработки временно не работает. S3 в третий раз наступает на грабли, выпуская на рынок продукт с драйверами, состояние которых скорее похоже на альфа-релиз чем на конечную версию. К сожалению, даже самая новая на момент написания статьи версия драйверов позволяла использовать T&L лишь в OpenGL. Так как самый большой интерес вызывает работа в DirectX7 и даже есть парочка игр, на которых можно было бы сделать тесты, то лучше просто временно забыть о том, что T&L у S2K есть. Для самых дотошных скажу, что результаты включения T&L в OpenGL конечно видны по тесту TreeMark, но учитывая синтетическую природу этого теста и относительно низкие результаты по сравнению с GeForce в Simpe тесте (никакие результаты в Complex) лучше будет не позорить S3 и подождать релиза нормальных драйверов.

Стабильность работы платы так же очень удивила. Мы уверены, что нам не достался "особый" бракованный вариант, однако поведение платы в некоторых тестах, беспричинные зависания без перегрева, сваливание большинства демо-версий игр и проблемы с прокручиванием DVD не способствуют хорошим впечатлениям о плате. Проблемы возникали не на всех платформах, но к примеру DVD через WinDVD на Athlon "не смотрелся" - смазанное изображение, белый шум на статичной картинке в меню, и подрагивания изображения при включенном MC - очень странная проблема, вероятно на уровне драйверов. Кроме WinDVD использовались ZoranSoft DVD и Cyberlink PowerDVD 2.55 trial. У каждой программы были свои ньюансы и варианты проблем,поэтому результаты тестирование всех трёх программ можно посмотреть ниже.

Кроме стабильности и скорости у платы возникали проблемы с BackFace-Culling алгоритмом. В будущих релизах драйверов это обещано поправить, но сегодня мы стоим перед фактом - плата рассчитывает то, чего мы в принципе видеть не можем. А зачем тратить на это ресурсы, Fillrate, время? Многих удивила рекордно низкая скорость Savage2000 в Direct3D приложениях. Мы думаем проблемы с куллингом могут сказаться тут - плата просто рассчитывает невидимые нами детали кадра, в результате её скорость на порядок ниже скорости конкурентных плат. Это теоретическая идея, и может быть мы не правы.

Что касается драйверов, то это фирменный набор от Diamond - пакет IncontrolTools99, Diamond Update плюс ядро драйвера. Есть один неудобный момент, хотя это на любителя - все настройки 3D задаются не для всей системы а для каждого конкретного случая, при этом система отслеживает обращение приложений к 3D функциям платы и замусоривает реестр данными о местоположении и названии файла, а так же настройках 3D под него. Не стоит об этом забывать, так опции по умолчанию не настроены на наилучшую производительность. Настройки железа в драйвере могут:

• Изменить настройки режима использования памяти для текстур (только видео память, только AGP, совмещённый режим);
• Включить режим автоматической очистки Z-Buffer;
• Включить автоматический Mip-Mapping для приложений, не знакомых с этой технологией;
• Задать режим исправления работы с текстурами;
• Отключить V-Sync (не рекомендуется для Direct3D, в нынешних драйверах вызывает огромный лаг управления);
• Активировать технологию W-Buffering.

Тестирование

Наше тестирование мы начали с производительность акселератора в OpenGL играх на ядре Q3A, массовое появление которых ожидается в течении этого года. Для проверки использовались две демки - классический Quake 3 Arena DEMO001 и написанный нами Q3D.DM3. Начиная с этого момента мы немного изменили методику тестирования - все результаты получены при максимальной детализации c небольшими изменениями для сравнения. Reference настройки:

• Трилинейная фильтрация;
• Качество текстур вывернуто на максимум;
• Освещение с использованием карт освещения (lightmaps);
• Геометрия на High;
• Используются доступные gl_extension;
• Для Savage2000 отключен r_ext_compress_textures, так как его использование приводит к некорректному отображению некоторых текстур.

После проведения тестирования в диапазоне разрешений от 640x480 до 1280x1024 при различной глубине буфера кадра и глубины цвета текстур проводится дополнительное тестирование. Результаты основного тестирования на двух графиках ниже:

Как мы видим в 16-ти битном режиме, когда на шину памяти приходится меньшая нагрузка Savage2000 отстаёт от GeForce 256. Отрыв не столь серьёзен, обе платы хорошо приспособлены для такой детализации. Другая ситуация в 32-бит режиме:

Тут мы видим уже совсем другую ситуацию - Savage2000 обгоняет GeForce SDR, причём имея более низкую частоту шины памяти. Только разогнав GeForce 256 SDR до 145/190 нам удалось получить в 1024x76832-32 цифры, близкие к производительности Savage2K. Видно, что в Savage2000 вложен хороший потенциал, однако его реализация в жизни зависит только от расторопности программистов драйверов.

Обязательно необходимо поднять вопрос о моментальном и среднем FPS. Тесты timedemo показывают среднюю производительность, моментальный FPS лучше всего измерять активацией консольной переменной cg_drawFPS 1, это позволяет увидеть минимальные значения FPS для конкретного уровня. В высоких разрешениях Savage2000 иногда падает до уровня 10-15 FPS, при этом средний результат остаётся высоким за счёт высоких значений в другие моменты. В разрешении 1600x1200 начинается просто ужасное торможение в моменты, когда игра отображает так называемые "частицы", выводит полу-прозрачные взрывы и динамическое освещение. Падение производительности при этом становится нелинейным, моментальный FPS скачкообразно изменяется в интервале от 15-20 до 2-3 FPS. Скорее всего проблема на уровне драйвера, так как с комплектными драйверами аналогичная проблема возникала в Quake 1 (!), который при отображении динамического освещения и взрывов тормозил в несколько раз больше, чем древний Voodoo Graphics. Активация полу-прозрачной воды, теней и зеркальных поверхностей убивала производительность полностью - играть становилось полностью невозможно.

После основного теста мы ввели дополнительное тестирование, целью которого является замер изменения производительности при изменении настроек игры по сравнению с reference значением. За reference производительность принимается 1024x768 при максимальной детализации, 32-бит frame buffer и 32-бит текстурах. При такой методике тестирования удаётся оценить потери в скорости при работе с полноцветными текстурами, большей нагрузке на память, использовании карт освещения и т.д. Результат дополнительного тестирования:

При Reference настройках Savage2000 существенно выигрывает у GeForce 256, однако в максимально оптимизированной ситуации, когда карты испытывают куда меньшую нагрузку GeForce существенно вырывается вперёд. Чем это вызвано? Архитектурно Savage2000 приспособлен для работы с огромными массивами текстур, драйвер оптимизирован конкретно под Quake 3 и Truecolor. GeForce имеет более отлаженный ICD, работающий правильно не только в Quake III но и в 3DMax и старых Quake. Очень показательным является скорость плат при отключенном gl_extensions - видно, что активация всех расширений прибавляет Savage2000 14 FPS (около 55% производительности), в то время как GeForce 256 получает всего 8 FPS (около 33%). Это показывает хороший уровень оптимизации драйверов платы.

Мы провели ещё одно дополнительное тестирование - известно, что карта Q3DM9 серьёзно нагружена текстурами. Мы решили проверить, как платы справляются с максимальной нагрузкой на этом уровне. В результате были получены такие результаты:

Прямо как в той рекламе - "По нашему это шок!". Как иначе можно обозвать более чем трёхкратное падение производительности GeForce 256? Даже делая скидку на SDR память и режим AGP1x, установленный по умолчанию в 3.72 драйвере на Athlon нельзя было бы обосновать такую неэффективность работы, если бы не одно НО - драйвер Savage2000 работает в OpenGL с AGP текстурированием. G256 имеет текстурный свопинг, S2K использует AGP. Наглядная польза? В принципе да. Поясню значения графиков - под Reference мы понимаем всё те же максимальные настройки качества в 1024x76832. Под L3 Texture мы подразумеваем изменение всего одной опции - полозок детализации текстур сдвигается на одну позицию левее. К сожалению мы не имеем возможности протестировать 64-х мегабайтные версии плат на Quadro, в ОЗУ которых без проблем должны были бы поместиться эти карты. Но в графе "Эффективная работа с большими массивами текстур" Savage2000 получит галочку, а G256 не заслужит даже крестика.

Из всего итого хочется сделать вывод об отличной оптимизации OpenGL ICD драйвера - высокая скорость, эффективная работа с большим количеством текстур и т.д. Не стоит спешить - мы ещё не видели результатов классических версий Quake. Для начала Quake2:

Отставание Savage около 50%. Очень странные результаты, но это говорит лишь о оптимизации драйвера под Quake 3 Arena. В этом тесте процессор акселератор загружается только в высоких разрешениях, отсутствие масштабирования в низких разрешениях показывает, что в наш Athlon 650 может показать в Quake 2 demo1 не более 200 fps. То есть он рассчитывает геометрию с такой максимальной скоростью. Вот только почему при всех архитектурных изысках у Savage этот максимальный порог на 50% ниже? Пусть это останется на совести драйверописателей, а мы взглянем на график в Truecolor:

Особенно стоит обратить внимание на результат в 1600x1200 - опять появилась эта интересная проблема, когда скорость нелинейно падала во время выстрелов при наличии динамического освещения и частиц. Внимательные читатели наверняка обратят внимание, что плата в Truecolor работает быстрее Highcolor. Не будь у нас Quake 3, эта плата получила бы приз за самые низкие потери при переходе в 32-бит. Это так же можно обьяснить заточкой платы и драйвера для работы с 32-бит графикой.

Для чего мы рассматривали Quake 2? Многие скажут что игра уже отжила своё, не демонстрирует всех возможностей акселераторов и т.д. Но мы не забываем о том, что на ядре Quake 2 построено много интереснейших конверсий, одной из которых является Half-Life и недавний Opposing Force. Кроме того на ядре Quake 2 создаётся Team Fortress 2, и если всё пройдёт по плану, то эта игра будет иметь колоссальный успех для сетевых разборок.

Так же хочется рассмотреть результаты в Quake - древняя игрушка, однако многие по сей день в неё играют. Результаты Savage2000 тут тоже не впечатляют:

Отставание от GeForce более чем в два раза, мы ожидали этого, драйвер явно оптимизирован для работы с Quake 3 Arena. Но вот чего мы не ожидали, так это одинаковой скорости в Quake 2 timedemo 1 и Quake timedemo demo1 ! Как вы обьясните одинаковую скорость игр с различной степенью загруженности текстурами, разными уровнями геометрии с учётом того, что рассчётами геометрии и освещения занимается центральный процессор системы, который просто не может рассчитывать такие обьёмы данных с одинаковой скоростью?! Нонсенс. Но размышления немного ниже. Ещё более интересные результаты получатся если установить драйверы с CD платы v1.0 - в этом случае Quake 1 начинает безбожно тормозить в 640x480. Карта на Voodoo Graphics легко обгоняет супер новый Savage2000 по субьективной скорости. Моментальный FPS порой опускается за отметку в 10 fps. Если включить полу-прозрачные текстуры воды, разрешить отрисовку всех невидимых плоскостей то скорость упадёт до неприемлемо низкого уровня. Представьте себе пошаговый Quake, и вы поймёте что мы имеем в виду.

Так вот о одинаковом FPS Quake 2 и 1. Простой рассчёт показывает, что при 640x480 и 122 fps минимально скушанный Fillrate составляет 37.478.400 пикселов, то есть 37.5 мегапикселов. Если говорить о режиме, когда S2K рисует 2 пиксела с одной текстурой на каждом, то в остатке мы имеем около 213 мегапикселов, не могут же они уйти в Overdraw? Тогда подумаем что будет если не работат один конвейер - в остатке станет 87.5 мегапикселов. Гораздо меньше. А сколько же Fillrate тратит GeForce? Он тратит около 86 мегапикселов на Quake. Кстати, Quake 1 не поддерживает мультитекстурирование а Quake 2 поддерживает. Возникает странное предположение - а не работает ли действительно в наших драйверах у Savage2000 всего один конвейер, выдающий на гора 125 мегапикселов и 250 мегатекселов? Замеры в FinalReality это подтверждают да и ладно бы FR, и 3DMark2000 выдаёт меньше ожидаемого. Пока мы отложим этот вопрос.