Масштабируемость: что это такое?

Как-то передо мной встал вопрос, что такое масштабируемость и как это связано с зависимостью/независимостью от центрального процессора? В результате, получилась небольшая статья, которую и предлагаю Вашему вниманию.

Начну с того, что постараюсь кратко объяснить, что же такое процессорная зависимость (CPU dependency), применительно к 3D-ускорителям. Дело в том, что ни один из существующих 3D-ускорителей пользовательского класса не ускоряет весь процесс обсчета трехмерной сцены (геометрические преобразования, просчет освещенности, отсечение невидимых поверхностей и т.д.). Разные ускорители ускоряют разные этапы, обычно лежащие где-то ближе к концу цепочки вычислений - растеризацию (т.е. перевод двумерного векторного изображения в двумерное растровое изображение) и наложение текстур. Вся остальная работа ложится на плечи центрального процессора (CPU). При этом для организации взаимодействия с 3D-ускорителем обычно требуется некоторое дополнительное число шагов. Процессорная зависимость, таким образом, слагается из 2-х компонент - процента вычислений, НЕ ускоряемых картой, и процента дополнительных вычислений, которые производятся уже графическим процессором.

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

Начиная с какого-то момента графический акселератор начинает все больше и больше тормозить процессор, и при неограниченном росте производительности последнего скорость рендеринга становится постоянной, стремясь к пиковой производительности ускорителя.

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

В качестве оценки предельной производительности карточки можно использовать известные характеристики количества треугольгников, которые она может обработать в секунду, и скорость закраски (fill-rate), т.е. количество текстурированных и отфильтрованных пикселов, выводимых в одну секунду. Возьмем для примера две карточки: 3Dfx Voodoo и nVidia Riva TNT.

Их параметры таковы:

• 3dfx Voodoo: 750 тыс. треуг./сек, 40Млн.пикселей/сек
• nVidia Riva TNT: 2 млн. треуг./сек, 200 Млн.пикселей/сек

• при сложности сцены в 10 тыс. треуг - 75 fps.
• при разрешении 640х480 и глубине перекрытия 4 - 32 fps.

Как видим, теоретические данные очень неплохо согласуются с практическими (эти параметры приблизительно соответствуют Quake 2).

Что же с Ривой? Получаются следующие значения:

• при сложности сцены в 10 тыс. треуг - 200 fps.
• при разрешении 640х480 и глубине перекрытия 4 - 162 fps.
• при разрешении 800х600 и глубине перекрытия 4 - 104 fps.
• при разрешении 1024х768 и глубине перекрытия 4 - 63 fps.

Что следует из этих цифр? Очень просто. Начиная с какого-то уровня, производительность 3D-ускорителя уже не играет роли (глазу все равно, 160 или 60 fps он видит). Все теперь упирается в процессорную зависимость, т.е. в то, какой процессор нужен, чтобы достичь подобных пиковых значений. Вот почему я с большим скепсисом читаю характеристики вновь появляющихся 3D-ускорителей. Также легко видеть, что приведенные ускорители (как и подавляющее большинство остальных) ограничены именно скоростью закраски, тогда как для процессора основная нагрузка исходит от процесса геометрических преобразований, т.е., усилия разработчиков сосредоточены несколько не в том месте, где надо бы.