Подписаться  на наше издание быстро и дешевле чем где-либо Вы можете прямо сейчас! Подписаться!

 

 

Казалось бы: существует OpenGL — свободно распространяемая спецификация для трехмерной графики. Нужно ли что-нибудь еще? Оказывается, да, поскольку зачастую не все и не всем довольны…


Недовольство чаще всего происходит по линии производительности: "честно" реализованные на OpenGL сцены часто не показывают нужной производительности. Конечно, скорость — это еще не все, но, тем не менее, пользователь часто бывает разочарован производительностью новых видеокарт под OpenGL.


Причина: OpenGL ничего не знает о новых возможностях этих карточек. Большинство игр и деловых приложений до сих пор используют "читинг", то есть многие эффекты реализуются не вызовами API OpenGL или DirectX, непосредственно передаваемых в видеоакселератор, а с помощью "волшебных" эффектов двух-с-половиной-мерной графики — так же как это делалось в первом Doom’е и Duke Nukem 3D.


Еще один, косвенно связанный с предыдущим, и тоже важный момент — это уровень интерфейса и доступа к возможностям GPU. Уровень OpenGL можно назвать средним: вы можете оперировать готовыми примитивами, до уровня декомпозиции включительно, и программно (средствами CPU) реализовывать остальные операции. Вопрос: насколько линия разделения "софт-хард" является оптимальной в OpenGL или DirectX? Какова степень этой неоптимальности?


Третий вопрос: как утилизировать новейшие (и не очень) специфические возможности, такие как SLI, Shader Model 3 или HDR, которые не входят (и не могут входить) в спецификацию Open GL? Понятно, что спецификация OpenGL никогда не успеет, и даже не будет стараться успеть, за всеми возможностями, появляющимися на рынке. Особенно с учетом того, что два ведущих производителя не координируют свои разработки и независимо создают различные расширения и технологии. Это противоречит концепции платформенной независимости OpenGL, так что только "фирменные" реализации OGL могут использовать фирменные секреты производительности и расширения стандартов.


Наконец, "окончательный" вопрос: как упростить жизнь самим создателям Open GL и Direct X, освободив их от копания в регистрах процессора? В этом плане две основные проблемы. Во-первых, большая удельная цена в "человекогодах" для разработки нового софтвера промежуточного уровня, такого как модули DirectX или расширения OpenGL. ВО-вторых — высокая вероятность ошибок в длинных программах на ассемблере (как известно, количество ошибок прямо пропорционально количеству строк и не зависит от уровня абстракций языка).


Ответом на все эти вопросы и запросы является уровень SDK, сопровождающий современные видеокарточки (в дальнейшем мы не будем говорить "видеокарты", а станем оперировать коротким профессиональным термином GPU — то есть графический процессор).


Рассмотрим только один из возможных инструментов этого уровня, а именно — nVidia Cg, язык высокого (относительно ассемблера) уровня для доступа ко всем возможностям GPU этого производителя. Сразу же хорошая новость: Cg доступен как на MS Windows, так и для Linux — причем компилятор для Linux доступен и в виде открытого кода.


Си для графики


Основная идея Cg (С for graphics) — с помощью C-подобного языка описывать трехмерные сцены и задействовать максимум из возможных функций данной графической карточки, не используя при этом низкоуровневых ассемблерных конструкций и обращений к портам ввода-вывода. Cg очень специализированный язык: вы не можете (или не захотите) написать на нем текстовый редактор или электронную таблицу. Что можно делать с помощью Cg, так это описывать форму, размер и положение объектов. Сами создатели называют этот язык shading language, что приблизительно можно перевести как "язык для ретуширования". На самом деле, однако, помимо собственно ретуширования с помощью Cg, можно реализовать и физическое моделирование, композицию и ряд других функций.


Поближе к "железу", подальше от ассемблера


Заметное отличие Cg от других языков — ориентированность на поток данных. В качестве данных выступают обычно вершины (vertex’ы) и фрагменты, которые последовательно проходят по конвейеру обработки.



Все же Cg — это "Бейсик", созданный больше для "срочных" прототипов.
Настоящая "пушка" — nVidia SDK — доступна по адресу developer.nvidia.com/object/sdk_home.html


Ваша программа может рассматриваться как функция обратного вызова: когда растеризатор отрисовывает очередной фрагмент, он вызывает ваш код для каждой вершины и фрагмента, чтобы узнать текущее положение и состояние последних. Мы говорим "функция обратного вызова" с тем условием, что после компиляции на CPU программа будет по мере необходимости загружаться (с помощью Cg runtime) в GPU и выполняться там непосредственно на графическом акселераторе. Так что это, конечно, callback, но в качестве вызывающей стороны выступает не операционная система, а firmware GPU. Современные GPU поддерживают истинное программирование, в отличие от "программирования" через передачу параметров в старых видеоакселераторах.


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

 

Ключ к производительности


Главным преимуществом Cg является то, что уровень абстракций и примитивы Cg полностью совпадают с таковыми для самого GPU: уровень трансляции из одной системы ценностей в другую минимален. Это является необходимым условием производительности: например, для обработки изображения типичным размером один миллион пикселей с частотой 100 fps в шести проходах (современные GPU обрабатывают каждый пиксель от двух до шести раз — в зависимости от необходимых эффектов, таких как даунсемплинг и сглаживание) потребуется 600 млн. примитивных операций, каждая из которых включает несколько машинных команд.



Измеряемые fps не отражают субъективных впечатлений: прежде чем вы увидите изображение,
оно еще может "затеряться" в операционной системе


Аналогично, векторный процессор выполняет десятки миллионов операций, до того как вершины будут преобразованы в векторы, кривые и точки и вся сцена будет должным образом скомпонована. Ясно, что центральный процессор не может адекватно помочь в реализации каждого из таких вычислений: сам CPU во время отрисовки трехмерных сцен также загружен массой работы — от логического уровня перемещения моделей до расчета ходов от имени искусственного интеллекта.


Портабельность во времени и пространстве


Хотя Cg и говорит на языке GPU — тем не менее это функциональный язык, не зависящий от конкретных аппаратных средств. Вы указываете, что делать, но не как — так что программа может работать на большинстве современных GPU, равно как и на будущих моделях. Точно так же совершенно за кадром остаются детали реализации, такие как загрузка программы в GPU посредством портов ввода-вывода и т.д.


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



Результат использования программы, скомпилированной с "завышенным" профилем: те действия,
которые могут быть выполнены, тем не менее выполняются


Возникает закономерный вопрос: как компилятор Cg на этапе компиляции может узнать возможности GPU? Ведь совсем не факт, что выполнение будет производиться на той же машине. Решение заключается в использовании профилей возможностей. Все аппаратно реализуемые возможности разделены на классы, называемые профилями: например, CG_PROFILE_VS_2_0 соответствует набору возможностей DirectX 9 vertex shaders 2. Аналогично, CG_PROFILE_ARBVP1 определяет набор OpenGL ARB vertex v.1 и т.д. Имя профиля указывается в виде параметра командной строки компилятора. Это налагает ограничения на возможности и длину программ: то, что позволительно для профиля NV30, может вызвать ошибку для NV2X. Обратите внимание, что профили относятся к встроенным в GPU блокам функций, а не к установленному на вашем компьютере софтверу: если ваша карточка не поддерживает возможности vertex shaders 2, то наличие установленного Direct X 9.0 не поможет выполнить Cg-код, скомпилированный с ключом -profile vs_2_0.


Параллельным курсом


Хотя программы Cg выполняются параллельно с работой основного процессора, сами они по своей природе также являются параллельными. Причина — наличие в современных GPU двух отдельных процессоров для обработки векторной графики (вершин) и для обработки растра (фрагментов). У вас есть любая возможность для комбинирования этих двух конвейеров — вы можете загрузить обе части кода с помощью Cg или использовать код, написанный на ассемблере для любого из процессоров. Можно вообще отключить внешнее программирование и использовать аппаратные параметризованные фильтры в духе OpenGL.


Данные: один большой поток


С точки зрения обработки данных ваши программы будут вызываться каждый раз, когда GPU нужно будет обработать вершину или фрагмент. Это техника знакома программистам на Perl, где в качестве входного потока может выступать текст, а программа выполняется для каждой строки.


Программы на Cg воспринимают фиксированные, не зависящие от отдельных элементов изображения, данные, а также переменные, связанные с конкретным элементом. Переменные и параметры, кроме имени и типа данных, дополнительно имеют еще и привязку. Грубо говоря, это отдаленно соответствует порту ввода-вывода, но не всегда так однозначно. Привязки помогают унифицировать интерфейс между приложением и GPU в целом, а также между векторным и пиксельным процессором. Если вам удобно, можете воспринимать привязки как именованные переменные из пула памяти GPU.


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


Другие особенности Cg


Мы не имеем возможности рассмотреть здесь все тонкости строения современных GPU вообще и их отображения на язык Cg в частности — документация по Cg занимает около трехсот страниц. Тем не менее отметим наличие скалярных и векторных типов данных, а также специфических предопределенных структур. Многие арифметические и логические операции в Cg имеют такое же значение, как и в C, хотя отсутствие указателей как сущности в GPU налагает свой отпечаток, например, на доступ к массивам или передачу параметров по ссылке.


Помимо привычных операторов, существует также достаточно много специфических "ускорителей": операторов, эффективно транслирующихся в машинные команды GPU или вообще реализующихся за нуль-время — например, выделение компонента из вектора или перестановка элементов вектора (команды GPU в любом случае содержат биты, указывающие, какие компоненты координат или цветности извлекать). В новых профилях доступны также такие сложные операции, как поиск текстур и т.д.


Последний компонент успеха: 3D-хакер


На этом завершаем небольшое вступление в Cg — мы не даем знаний, зато показываем возможности. На диске К+П находится текущая версия компилятора, снабженная несколькими примерами и документацией. Если у вас сравнительно новая карточка nVidia версии NV2x/3x и где-то неподалеку Visual Studio — можете сразу приступать к экспериментам. Однако для получения хоть сколько-нибудь приемлемых эффектов понадобятся, как минимум, знания в оптике и трехмерном моделировании. Для моделирования реалистической физики необходимо знание физических моделей, таких как упругие или коллоидные среды и т.п.


Лично я что-то написал, однако продемонстрировать это не решаюсь — в двух словах композиция называется "Дисперсный хаос в турбулентных потоках"J. Впрочем, синий тор из туториала блестел и отражался вполне приемлемо, как и было обещано. Короче, математику и физику придется вспомнить.


Есть и другой вариант. Правда, создатели языка всячески отказывают ему в универсальности — но настоящий хакер никогда ведь не слушает, что ему говорят, не так ли? Обидно, когда отличный процессор GPU за 200 баксов простаивает 90% времени. А не заставить ли GPU решать и другие задачи, кроме отрисовки графики? Архивирование и взлом паролей перебором — отличные кандидатуры для таких чисто вычислительных и "зацикленных" задач. Не забывайте задействовать оба процессора GPU!


(И никому не говорите, что я вам это говорил!)

2005.09.28
19.03.2009
В IV квартале 2008 г. украинский рынок серверов по сравнению с аналогичным периодом прошлого года сократился в денежном выражении на 34% – до $30 млн (в ценах для конечных пользователей), а за весь календарный год – более чем на 5%, до 132 млн долл.


12.03.2009
4 марта в Киеве компания Telco провела конференцию "Инновационные телекоммуникации", посвященную новым эффективным телекоммуникационным технологиям для решения задач современного бизнеса.


05.03.2009
25 февраля в Киеве компания IBM, при информационной поддержке "1С" и Canonical, провела конференцию "Как сохранить деньги в условиях кризиса?"


26.02.2009
18-19 февраля в Киеве прошел юбилейный съезд ИТ-директоров Украины. Участниками данного мероприятия стали ИТ-директора, ИТ-менеджеры, поставщики ИТ-решений из Киева, Николаева, Днепропетровска, Чернигова и других городов Украины...


19.02.2009
10 февраля в Киеве состоялась пресс-конференция, посвященная итогам деятельности компании "DiaWest – Комп’ютерний світ" в 2008 году.


12.02.2009
С 5 февраля 2009 г. в Киеве начали работу учебные курсы по использованию услуг "электронного предприятия/ учреждения" на базе сети информационно-маркетинговых центров (ИМЦ).


04.02.2009
29 января 2009 года в редакции еженедельника "Computer World/Украина" состоялось награждение победителей акции "Оформи подписку – получи приз!".


29.01.2009
22 января в Киеве компания "МУК" и представительство компании Cisco в Украине провели семинар для партнеров "Обзор продуктов и решений Cisco Small Business"

 

 
 
Copyright © 1997-2008 ИД "Комиздат".