| Наши проекты: Скачать программы | Экспорт новостей (RSS) |
| Главная | Domino | Статьи | Computer FAQ | Download | T0P-100 Software | Форум |
 |
Подписка на рассылку
Реклама у нас, Контакты |
|
|
|
||||||||||
|
||||||||||
 |
Автор: Иван Колганов aka FerZ http://www.guide3d.ru/
Итак, данная статья представляет собой краткий экскурс в историю развития видеокарт, а так же описание общего алгоритма построения трёхмерного изображения Вашим ускорителем трехмерной графики. Начнём традиционно с истории. Первые видеокарты не были даже не 3D-ускорителями, а не были ускорителями вообще. Они служили лишь как ЦАП (цифро-аналоговый преобразователь) – преобразовывали данные, рассчитанные центральным процессором (представляющий собой цифровой код) в аналоговый сигнал, доступный для отображения на мониторе. Но сложность изображений росла, и дальше так продолжаться не могло. Тенденция усложнения изображений привела к появлению 2D- ускорителя – видеокарты, имеющий свой собственный, пусть и простейший процессор, бравший на себя часть функций, разгружая центральный процессор. Но когда появилась необходимость строить 3D изображения – ситуация осложнилась. Чтобы построить, скажем, простой фрагмент стены, процессору нужно было выполнить следующие операции: сначала необходимо выделить грани этого объекта, затем наложить текстуры, добавить освещение... а когда таких объектов сотни, их форма сложна, они движутся и перекрываются, отбрасывают тени и т.д. задача становится невероятно сложной. Для помощи процессору в решении этой задачи и были созданы ускорители трёхмерной графики, о работе которых и пойдёт речь в этой статье. Для начала выясним – а что нам, собственно, нужно, чтобы построить трёхмерное изображение. Необходимо сказать, что видеоакселератор НЕ занимается расчётом того, какую сцену он должен сейчас строить. Определением 3D сцены – объектов, точки наблюдения и т.п. занимается центральный процессор. Как только все необходимые данные собраны – они передаются видеокарте, которая начинает построение сцены. Построение сцены происходит следующим образом:
Отметим, что всё это непрерывная очередь. Всем желающим подробнее узнать про алгоритм построения сцены современными ускорителями я рекомендую изучить великолепный материал под названием DirectX Current, подготовленный нашими коллегами с iXBT. Итак, каждая стадия построения изображения очень ресурсоемка, требует множества расчётов. Вполне логичным выглядит шаг вынесения их из CPU и переправка на специализированный процессор видеокарты. Особенно если учитывать, что графические данные имеют потоковый характер, и вычислительную потребность значительно большую, чем логическую. Каждый новый виток развития ускорителей представляет собой некое поколение, поэтому для начала введём стандартизацию поколений (понимать поколения можно по-разному – я приведу лишь один вариант):
Теперь, определившись с общим устройством конвейера и поколениями видеокарт, мы более подробно рассмотрим вершинный и фрагментный процессоры, а также определимся в отличиях версий соответствующих шейдеров. Причиной появления шейдеров стало отсутствие какой-либо гибкости у фиксированного TCL блока. Быстро стало понятно, что ждать момента, когда производители внесут очередную порцию функций в TCL блок видеокарт – не лучший выход. Такой подход не устраивал никого. Разработчикам не нравилась мысль, что для того, чтобы внести в, например, игру новый эффект им надо годик подождать выхода нового ускорителя. Производителям тоже не светило ничего хорошего – им бы пришлось постоянно увеличивать как сами чипы, так и драйверы к ним. Это и стало причиной появления шейдеров – программ, способных настраивать ускоритель так, как того требует следующая сцена. Шейдер – это программа, которая загружается в ускоритель, и конфигурирует его узлы для обработки соответствующих элементов. Теперь нет ограничения заранее заданным набором способов обработки эффектов. Теперь стало возможно составлять из стандартных инструкций любые программы (ограниченные спецификациями используемой версией шейдера), задающие необходимые эффекты. Шейдеры делятся по своим функциям на вершинные и фрагментные (пиксельные): первые работают с вершинами и треугольниками, заменяя собой функциональность TCL блока (сейчас он практически исчез – в случае необходимости он эмулируется специальным вершинным шейдером). Фрагментные же шейдеры служат для создания программ обработки фрагментов размеров 2х2 пикселя – квадов. Они необходимы для реализации некоторых текстурных эффектов. Шейдеры также характеризуются номером версии - каждая последующая добавляет к предыдущим всё новые и новые возможности. Наиболее свежей спецификацией фрагментных и вершинных шейдеров на сегодняшний день является версия 3.0, поддерживаемая через API DirectX 9с, - на нее и будут ориентироваться как производители акселераторов, так и разработчики новых игр. На их поддержку аппаратурой стоит обращать внимание и пользователям, желающим приобрести современную игровую видеокарту. Обратим внимание на главное отличие шейдеров 3.0 от предыдущих версий (кроме 2.0а) – это DFC – Dynamic Flow Control – динамическое управление потоком. С одной стороны – это великолепная возможность, позволяющая заметно повысить скорость построения сцены, с другой – лишние транзисторы, и как вытекающие побочные эффекты, лишнее тепло и ниже максимальные частоты. Давайте более подробно опишем эту возможность. Представим себе ситуацию, когда для какой-либо вершины (или фрагмента) шейдер нужно выполнить не весь, а только 12% от него. В случае применения DFC мы выполним лишь те необходимые 12%, основываясь на параметрах объекта. Без DFC мы вынуждены выполнить шейдер целиком. Легко заметить, что с DFC мы получим выигрыш без малого в 10 раз, при этом, заплатив пониженной производительностью на вершинах, для которых нужно выполнить все 100% шейдера. Именно по этому в сети до сих пор не утихают споры – хорошо это или нет. Я не буду проводить сравнения – тут каждый сам делает выбор, а лишь отмечу, что я лично сторонник третьей шейдерной модели. Первые шейдеры состояли всего из нескольких команд, и их нетрудно было написать на низкоуровневом языке ассемблера. Хотя сложность отладки ассемблерного кода поначалу отпугнула от шейдеров многих разработчиков… Но с ростом сложности шейдерных эффектов, насчитывающих иногда десятки и сотни команд, возникла необходимость в более удобном, высокоуровневом языке написания шейдеров. Их появилось сразу два: NVIDIA Cg (C for graphics) и Microsoft HLSL (High Level Shading Language) - последний является частью стандарта DirectX 9. Достоинства и недостатки этих языков, и прочие нюансы будут интересны только программистам, так что подробнее на них мы останавливаться не станем. Отметим только, что Cg не получил широкого распространения, ввиду появления нового, более продвинутого GLSL – аналога HLSL для API OpenGL. Не будем проводить сравнения этих языков, а лишь отметим, что, как и в любой другой области, применение языков высокого уровня значительно сокращает объём необходимых работ по написанию и отладке кода. Теперь давайте посмотрим, что необходимо для того, чтобы получить все те возможности, которые дает столь полезная технология, как шейдеры последнего поколения. А нужно следующее:
Особенно хочется отметить последнее обстоятельство – обычно на внедрение новых технологий уходит 2 - 3 года, но благодаря высокоуровневым языкам создания шейдеров это время заметно сократилось. Уже в ближайшее время мы ожидаем появления новых продуктов, использующих шейдеры 3.0 – Stalker, DooM 3, Serious Sam 2 и др. А не сей веселой ноте, позвольте завершить наше изложение.
*** Смотрите также:Все статьи рубрики Hardware |
|
||||||||||||
