GeForce 6: конвейеры и разгон

для раздела Лаборатория


Эта работа была прислана на наш "бессрочный" конкурс статей и автор получил приз - кулер Gigabyte 3D Cooler Ultra.


Любопытство - не порок...
Народная поговорка.

Как это обычно бывает, приобретя новую железку для компьютера, очень хочешь узнать, на что она способна. Если ты убеждённый оверклокер, то интерес куда более глубокий: как эта штука гонится, что влияет на производительность, а что влияет мало? В какую точку надо сконцентрировать усилия, чтобы получить максимум производительности? Не знаю как Вы, а я, наэкспериментировавшись, могу и вовсе оставить всё "по умолчанию", потому что уже само осознание потенциальных возможностей оставляет в душе чувство глубокого удовлетворения.

Так вышло и со свежеприобретённым GeForce 6800, открывающим просто огромный простор для исследований. Шутка ли, чип новейшей архитектуры, с четырьмя пиксельными и шестью вертексными конвейерами! Правда, по одному из них в младшей модели отключены, а ну как они заработают? Но нет, мой AXLE GeForce 6800 оказался с аппаратно заблокированными конвейерами, и включить их не удалось. Впрочем, никто особо и не надеялся, ведь для такой громадной микросхемы выход 100% годных чипов отнюдь не стопроцентный. Потому и выпускаются младшие модели, что не совсем полноценные чипы нужно куда-то девать. Благо, новая архитектура была специально разработана с прицелом на возможность отключения неработоспособных блоков. По мере отладки техпроцесса и увеличения выхода полностью годных чипов возможность включения всех "мощностей" может появиться, а пока... пока можно посмотреть, как много мы теряем при отключении тех или иных блоков.

Сразу оговорюсь, что под пиксельными конвейерами подразумевается весь блок пиксельной обработки, включающий в себя один конвейер исполнения пиксельных программ и четыре классических пиксельных конвейера с одним текстурным блоком на каждом. В целях упрощения повествования я буду периодически использовать термин "конвейер" как синоним для термина "юнит". Подробнее с архитектурой GeForce 6 вы можете ознакомиться в этом обзоре.

Итак, что мы имеем? Видеокарта референс-дизайна, 1 штука; 128 МБ видеопамяти Hynix с временем выборки 2.2 нс; частоты работы 325 МГц на ядре и 400 МГц на памяти (800 DDR). Пиксельные конвейеры: 3 штуки, вертексные конвейеры: 5 штук; их можно программно включать и отключать. Разгон не впечатляет: по ядру достигается всего 375 МГц, а память и вовсе почти не разгоняется. В чём дело, ведь старшие модели работают на заметно более высоких частотах? В том, что на ядре занижено напряжение питания (1.2 В против 1.4 и даже 1.6 В на старших моделях), а память изначально работает на завышенных относительно рекомендованных частотах. О влиянии напряжения на разгон оверклокерам, полагаю, рассказывать не надо; о каких рекордах может идти речь, когда сидишь на голодном пайке? С памятью же ситуация не очень понятна: то ли при пониженном напряжении "не тянет" контроллер памяти, то ли на неё тоже подаётся заниженное напряжение. Как бы то ни было, радиаторы на памяти остаются чуть тёплыми, но добиться работы на частоте 900 DDR МГц, соответствующей её времени выборки, не удаётся. Остаётся дело за малым - проверить влияние количества конвейеров на производительность. В качестве бенчмарка я буду использовать DooM 3 - игру, под которую и покупалась эта видеокарта. Попутно я проверю, как влияет на результаты разгон, хотя это сильно замедляет тестирование. Любопытство, чтоб его...

Тесты проводились на платформе следующей конфигурации:

  • Athlon 1800+ @ 2.20 ГГц (192х11.5)
  • EPoX 8RDA rev. 1.1
  • 512 МБ dual channel PC3500, 11-2-2-2CL @ 192 МГц

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





Загружаемся в Windows XP, запускаем DooM 3 и вводим в консоли команду timedemo demo1. Повторяем до тех пор, пока результат не перестанет расти и фиксируем максимальное значение. Обычно максимальный результат получается на третьем запуске, реже на втором или четвёртом. Более 5 запусков не производилось почти никогда. Дело в том, что с каждым запуском растёт фрагментация виртуальной памяти, что приводит к ухудшению результатов.

Разгон осуществлялся при помощи RivaTuner последней версии, его же мониторингом контролировался результат. Контроль результатов необходим потому, что все последние графические чипы NVidia имеют развитые механизмы торможения в случае перегрева, а драйверы умеют сбрасывать разгон в случае каких-либо неполадок в процедуре рендеринга. В общем, за видеокартой нужен глаз да глаз, чуть зазевался - получишь неверную цифру.

Для облегчения "надзора" игра запускалась в оконном режиме, а в фоне было открыто окно мониторинга частот чипа и ведеопамяти. Это позволило оперативно отслеживать самодеятельность драйвера и даже почти исключить зависания от переразгона, коими нередко завершались первые эксперименты. Как показали тесты, скорость рендеринга в полноэкранном и в оконном режиме совпадает, поэтому полученные результаты можно считать корректными безо всяких скидок. Более того, по каким-то причинам в оконном режиме карта гораздо острее реагировала на переразгон. Увеличивая частоту ядра по 5 МГц, я производил 4 - 5 прогона демки и, если частоты не сбрасывались, опять увеличивал частоту. До тех пор, пока не проявлялись проблемы переразгона, после чего частота опускалась с тем же шагом до их (проблем) исчезновения. Затем фиксировался полученный результат. Такой метод позволяет постепенно прогреть чип до максимально-стабильного режима и не завесить систему.

В разминочном туре, описание которого я опущу, выяснилось наличие зависимости максимальной частоты ядра от конфигурации пиксельных/вертексных конвейеров. А также полное безразличие результатов DooM 3 к частоте памяти - 800 DDR МГц с лихвой хватало для прокорма трёх пиксельных юнитов, поэтому приводить данные для разгона памяти (а он также зависит от количества задействованных модулей) я не буду до тех пор, пока не обнаружится хоть какое-то влияние на результат.

Для тестов был выбран режим графики High Quality, как максимально играбельный на видеокарте со 128 МБ видео и 512 МБ оперативной памяти. Все остальные настройки оставлены в максимальном качестве, а степень анизотропии увеличена до 16х, чтобы акселератор и не думал халтурить. Все оптимизации в драйвере отключены.

Раунд 1.

В котором мы разыщем самые разгоняемые и самые "тормозные" блоки. Для этого оставим активными по одному пиксельному и вертексному юниту. Ставим разрешение 640х480, чтобы хоть как-то ускорить процесс тестирования. После нескольких часов тестов выстроилась такая картина:

375380385390
Pixel 1 55.3
Pixel 254.7
Pixel 3 55.7
Vertex 1 55.3
Vertex 2 55.7
Vertex 3 55.2
Vertex 4 55.7
Vertex 5 55.3

В таблице представлены результаты разгона каждого пиксельного и вертексного конвейера, а также количество кадров в секунду при различных частотах. Действительно, не все конвейеры одинаково разгоняются. Большинство "отстрелялись" весьма кучно, с разницей всего в 5 МГц, а один пиксельный работал при заметно меньшей частоте.

Эти данные помогут правильно выбирать конвейеры для последующих тестов. Так, для конфигурации <1v 1p> будут включаться третий пиксельный и четвёртый вертексный юниты, затем будет добавлен вершинный конвейер номер 2 и так далее по снижению разгонябельности. Как видите, повторяемость результатов при выбранной методике очень высока, следовательно, можно смело продолжить её использование.





Раунд 2.

В котором мы посмотрим, как изменяются результаты при задействовании дополнительных конвейеров, а также выясним интересную подробность про разгоняемость.

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

Fcore 325375380385390
1v 1p49.9 55.8
1v 2p61.5 63.4
2v 1p52.957.3
2v 2p63.863.564.063.8
2v 3p64.4
3v 2p63.9
3v 3p64.3

В первой колонке приведены результаты при штатных частотах. В конфигурации <1 вертексный и 1 пиксельный> юниты разгон на 20% принёс увеличение производительности почти на 12%. Неплохая масшатабируемость. Второй блок текстурирования увеличил производительность почти на четверть, тогда как дополнительный блок геометрии "привёз" всего 6%. Тем не менее, смысл в увеличении количества вершинных конвейеров относительно пиксельных есть - один блок геометрии явно не справляется с прокормом одного блока рендеринга. Однако посмотрите, как сильно при этом упал разгон!

Налицо влияние температурных градиентов в недрах чипа: два действующих вершинных конвейера интенсивно подогревают и без того работающий "на износ" блок текстурирования, значительно снижая его разгонные способности. Это подтверждается увеличением разгонного потенциала при двух активных пиксельных юнитах. Впрочем, меньший разгон не мешает чипу показывать несколько более высокую скорость, чем в режиме 1х1, следовательно, делать количество вертексных конвейеров меньше количества пиксельных действительно нет смысла, и следующая проверяемая конфигурация будет 2х2.

Хе-хе, при двух пиксельных конвейерах дополнительный блок геометрии дал прирост скорости даже менее 4%. В чём дело? А в том, что производительность начала упираться в мощность центрального процессора. Посмотрите на последующие результаты, чтобы убедиться в этом: производительности Athlon Thoroughbred на частоте 2.2 ГГц хватает лишь на 64 кадра в секунду! Поскольку нагрузка на графический процессор снизилась, конвейеры работают в менее напряжённом режиме и уже не ограничивают разгон, как это было в предыдущем случае.

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

Раунд 3.

В котором мы изучим результаты с антиалиасингом.





4х является самым часто используемым режимом антиалиасинга, поскольку он одинаково хорошо сглаживает как близкие к вертикальным, так и близкие к горизонтальным линии и не так уж катастрофически снижает производительность. Но в DooM 3 на современных видеокартах этот режим становится абсолютно неактуальным.

Игра имеет довольно слабую геометрию, имитируя мелкие детали через bump-mapping, т.е. через дополнительные текстуры, содержащие данные не о цвете точек, а о их высоте относительно плоскости треугольника. В то же время, метод сглаживания, используемый большинством сегодняшних видеокарт (multisampling), совсем не затрагивает текстуры и обрабатывает лишь границы полигонов. В результате, режим антиалиасинга 4х в DooM 3 не приносит почти никакого визульного улучшения, а только снижает производительность.

Более "высокие" режимы сглаживания уже являются комбинациями мультисэмплинга и суперсэмплинга, поэтому дают ощутимое увеличение качества картинки, но и намного больше нагружают видеокарту. Впрочем, более высокая нагрузка - как раз то, что нам в данный момент нужно, и я решил подобрать минимальный режим, когда сглаживание становится заметным. На GeForce 6 им стал недокументированный режим 6х, в котором и проводились дальнейшие тесты.

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

325370375380385
5v 3p44.948.9
4v 3p45.1 49.4
3v 3p45.048.9
2v 3p44.748.6
3v 2p36.4 41.5
2v 2p36.3 41.441.8

Да, в таком режиме мощнейший GeForce 6 уже не хватает звёзд с неба. Даже со всеми активными (из доступных) конвейерами частота кадров оставляет желать лучшего. Что ж, тем интереснее будет отмерять разницу.

Как это ни парадоксально, но отключение одного вертексного юнита позволило даже слегка поднять результаты. Объяснение тут видится лишь одно - геометрической производительности хватает с избытком, а дополнительные вершинные конвейеры лишний раз занимают шину памяти, немного мешая работе остальных блоков. Отключив один вертексный юнит, мы также немного увеличиваем разгон (с увеличением частоты ядра на 15% производительность возросла на 9%). Видимо, немного позже придётся серьёзнее изучить вопрос достаточности геометрической производительности на примере других приложений.

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

Отключение одного пиксельного юнита катастрофически сказывается на производительности, и даже разгон не способен скомпенсировать падение результатов. В связи с этим, дальнейшее уменьшение количества пиксельных конвейеров представляется совершенно нерациональным. Однако конфигурация <2v 2p> позволяет ещё чуть-чуть увеличить разгон, в точном соответствии с данными первого раунда: разгоняемость ограничена самым слабым звеном и его устранение позволяет остальным блокам показать максимальный результат.

В заключение снова посмотрим, как количество вертексных конвейеров влияет на производительность и разгон. Отключив очередной самый медленный блок, мы на доли процентов ухудшаем производительность в номинальном режиме, но выигрываем в разгоне. Кстати, а какую пользу нам принесёт разгон памяти?





К сожалению, разгон по памяти оказался слабым, всего 830 DDR МГц. Однако, даже по такому результату видно, что польза мизерная - частота кадров возросла на доли процента. Хм, если мы не можем разогнать память (напоминаю, что на тестируемой карточке частота памяти и так выше рекомендованной NVidia), то будем её снижать.

Раунд 4.

В котором мы попытаемся выявить влияние скорости памяти на производительность. Для этого все настройки оставляем на прежнем уровне и начинаем уменьшать частоту памяти с шагом в 50 DDR МГц. Выберем ту конфигурацию конвейеров, которая показала наивысшую производительность в предыдущем тесте - четыре вертексных и три пиксельных юнита.

800750700
32545.244.744.0

Вот и всё, устанавливать частоту ниже 700 DDR МГц драйвер категорически отказался, а падение производительности оказалось мизерным: уменьшение частоты на 12% снизило производительность всего на 2%. Архитектура GeForce 6 оказалась удивительно "автономной"; в тяжелейшем режиме с 6х сглаживанием и 16х анизотропией она почти не зависит от скорости памяти! Можно предположить, что низкое разрешение (640х480) позволяет чипу выполнять всю работу во внутренних кэшах и почти не обращаться к видеопамяти. Эту гипотезу подкрепляет и знание о наличии в современных графических процессорах эффективных алгоритмов сжатия цвета, оказывающих очень сильное влияние именно на скорость сглаживания. Что ж, давайте проверим и её.

Убираем сглаживание, увеличиваем разрешение до максимально-возможных 1600х1200 точек.

800700
32542.842.0

Да, результаты немного упали, но влияние частоты памяти по-прежнему ничтожно! GeForce 6 показывает просто фантастическую независимость от памяти. Может быть в этом виновата отличительная черта DooM 3 - интенсивное использование теней? Быть может, повышенная нагрузка на буфер шаблонов не позволяет развернуться остальным блокам во всю силу?

Раунд 5.

В котором мы исследуем влияние теней на результаты GeForce 6 в DooM 3.

Конфигурацию конвейеров возвращаем в дефолтную - 5 вертексных и 3 пиксельных. Меняем разрешение и измеряем скорость с тенями и без.

1600128011521024800640
w/ shadows42.951.756.860.565.666.1
w/o shadows48.357.963.568.075.378.7

Нет, никакой особой разницы между рендерингом с тенями и без не наблюдается, масштабируемость по разрешению очень похожа, а скорость без теней увеличивается максимум на 19%.

Интересно, что в низких разрешениях мы получили уже 66 кадров в секунду. Это улучшение связано с банальным обновлением драйвера до версии 66.32. В новой версии NVidia несколько оптимизировала библиотеку OpenGL, чуть-чуть снизив нагрузку на центральный процессор.

Ну и в заключение, давайте посмотрим, как меняются результаты при разном числе задействованных конвейеров в отсутствии теней. Ради эксперимента поставим разрешение 800х600.

4v 3p3v 2p2v 1p
w/ shadows65.361.444.7
w/o shadows75.468.346.5

Хорошо видно, что с уменьшением числа пиксельных конвейеров влияние теней стремится к нулю. Это говорит о том, что блок работы со stencil-буфером у GeForce 6 один и его производительность весьма велика. По крайней мере, в разрешениях больше 800х600 он не является узким местом.

Выводы.

Выводов из данного тестирования сделано много, попробую изложить те, что вспомню. Честно говоря, самое яркое впечатление оставила независимость GeForce 6800 от частоты памяти. Возьму на себя смелость утверждать, что такого мы не видели ещё ни у одного графического акселератора за всю их многолетнюю историю. Наконец-то создана архитектура, для которой видеопамять перестала быть узким местом и, скорее всего, именно здесь кроется секрет высочайшей производительности GeForce 6, который способен легко соревноваться с Radeon X800, работающим на более высоких частотах. Без сомнения, такой результат был достигнут благодаря развитой системе кэширования данных, ведь современная технология изготовления чипов уже не ограничивает фантазию разработчиков, а, наоборот, заставляет размышлять о том, куда бы потратить все эти миллионы транзисторов. Немаловажным фактором успеха стали и технологии сжатия цвета, значительно прогрессировавшие со времён Radeon 9700/9500 и сделавшие возможным рендеринг со сглаживанием без катастрофических потерь производительности. Виват, господа инженеры, есть реальный повод для восхищения вашей работой!

Следующий вывод касается количества вертексных юнитов, которыми располагает GeForce 6. Как мы видим, для максимальной производительности их должно быть больше, чем количество пиксельных юнитов. Даже в игре с достаточно убогой по современным меркам геометрией, соотношения 1:1 оказывается недостаточно. Сколько их нужно "в пределе" мы будем выяснять в следующем материале, а пока можно заметить, что решение сделать в GeForce 6600 три вертексных юнита при двух пиксельных выглядит достаточно разумным.

Ну и, естественно, нельзя не резюмировать результаты разгона. Для трёх пиксельных юнитов вполне достаточно частоты памяти 700 DDR МГц, а увеличение частоты ядра, естественно, заметно увеличивает производительность. Но с разгоном по ядру есть два нюанса.

Во-первых, на большинстве видеокарт модели GeForce 6800 занижено напряжение питания ядра. Во всех режимах производительности (2D, Low power 3D, Performance 3D) оно одинаково и составляет 1.2 В. Надеяться на хороший разгон при столь низком напряжении не приходится, зато видеокарта потребляет относительно малый ток и почти не греется. Так что страшилки про ужасное энергопотребление относятся лишь к старшим моделям, с суффиксами GT и, особенно, Ultra. Младшие же варианты отличаются кротким нравом. Подтверждением этого факта является и появление моделей 6800LE с пассивным охлаждением, т.е. совсем без вентиляторов.

Во-вторых, из-за огромной площади ядра наблюдается влияние отдельных блоков на разгон. Например, разные комбинации пиксельных и вертексных юнитов приводят к малопредсказуемым изменениям частотного потенциала. Скорее всего, это объясняется взаимным расположением этих блоков на кристалле чипа - чем дальше они находятся друг от друга, тем легче их температурный режим и тем сильнее можно разгонять чип. Поскольку напряжение питание снижено, малейшее повышение температуры может стать причиной неработоспособности блока. К тому же, большая площадь ядра ведёт к неравномерности характеристик кремния, на котором расположены отдельные блоки чипа, соответственно может проявляться разница в их частотном потенциале. Однако, в целом, разница не так велика, чтобы из-за неё стоило убиваться. Также на разгон влияет общее количество задействованных блоков, каждый из которых потребляет свою порцию электроэнергии, увеличивая падение и без того низкого напряжения на цепях питания ядра. В совокупности это приводит к дальнейшему уменьшению частотного потолка.

PS

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


Ждём Ваших комментариев в специально созданной ветке конференции.

Telegram-канал @overclockers_news - это удобный способ следить за новыми материалами на сайте. С картинками, расширенными описаниями и без рекламы.
Страницы материала
Страница 1 из 0
Оценитe материал
рейтинг: 3.7 из 5
голосов: 34


Возможно вас заинтересует

Популярные новости

Сейчас обсуждают