OpenGL 2.0: программируемый, масштабируемый и расширяемый / Программное обеспечение

Оригинал: THG

Два графических API, OpenGL и DirectX, наглядно демонстрируют раскол, творящийся в компьютерном мире. Иногда такая ситуация тормозит прогресс, иногда – ускоряет. Появляются новые разработки, и кажется, что разрыв между двумя API сокращается.

Однажды Microsoft и SGI, разработчик OpenGL, предприняли попытку добавить OpenGL в DirectX. Проект был назван Fahrenheit, и он кончился полным фиаско. Надежды индустрии создать универсальный API, работающий как в системах Microsoft, так и в других, пошли прахом. Единый API создал бы цельную платформу для разработчиков графических приложений. Задача похожа на невозможную, и на самом деле, она такой и оказалось. Microsoft обвинили в слабохарактерности, а SGI – в поддержке порочного принципа «что не мое – чужое». В любом случае, человеческие ресурсы была потрачены, Fahrenheit остался только в памяти, а Microsoft бросила все силы на дальнейшее совершенствование DirectX API для его использования как в играх, так и в high-end графике.

В отличие от OpenGL, являющегося открытым стандартом и обладающим всеми соответствующими атрибутами, DirectX предназначен для облегчения разработки приложений под Windows.

DirectX довольно пышно расцвел, будучи не отягощенным соблюдением механизма стандартизации и призванным лишь улучшить внешний вид Windows. В то же время наблюдался застой OpenGL, а все нововведения выходили в виде OpenGL расширений. Среди расширений можно отметить такие графические возможности, как ClearCoat, мультисемплирование и инструменты для соединения видео и графики (некоторые из них разрабатывались через OpenML, в свою очередь тоже являющимся расширением OpenGL).

Расширения, к сожалению, не вызвали значительного энтузиазма у большинства разработчиков программ, нуждавшихся в цельной платформе. Вместо этого были созданы многочисленные расширения, причем некоторые из них предназначались лишь для специальных приложений. Комитет разработчиков OpenGL (ARB) не смог сделать больше по нескольким причинам, среди которых стоит упомянуть и разногласия в интеллектуальной собственности. Некоторые компании пытались войти в ARB и реализовать свою технологию, но в то же время они старались защитить свою интеллектуальную собственность. Так что много сил у ARB ушло на примирение разных интересов. Комитет разработчиков OpenGL, по сути, неплохо поработал все эти годы, однако индустрия ушла вперед огромными темпами, осуществляя весомое давление на ARB.

Не отягощенный бюрократией OpenGL, DirectX быстро впитал в себя ряд возможностей, которые когда-нибудь появятся и в OpenGL. Главное нововведение заключается в добавлении программируемости в API, такая возможность еще далека до широкого применения разработчиками программ, однако продавцам ПО и «железа» она пришлась по душе. Благодаря программируемости API талантливый разработчик может сделать графику такой, какой он ее желает видеть. Причем все эффекты и функции будут доступны на типичном «железе». Конечно же, при этом будет достигаться и желанная цель «уменьшения нагрузки на центральный процессор». Члены комитета ARB, а по большей части это компании, также разрабатывают продукты и под DirectX. Они ясно понимают необходимость дальнейшего совершенствования OpenGL для распространения своих продуктов под различные аппаратные платформы.

Но и сам DirectX отнюдь не является беспроблемным: с одной стороны, у нас есть nVidia DirectX 8 с программируемыми шейдерами версии 1.2, с другой стороны существует подход ATi, который Microsoft обозначила как DirectX 8.1 с программируемыми шейдерамии версии 1.4. Каждый подход реализует доступ к программированию чипа, однако у каждого используется своя архитектура регистров. Все это отнюдь не играет на руку разработчикам. В теории, DirectX 9 должен решить данную проблему, поскольку он предлагает полностью аппаратно-независимый подход. Но имейте в виду, что и на пути Microsoft не так все гладко, о чем говорит переименование DirectX 10 в DirectX 9.1.

К тому же, с DirectX Microsoft пытается сделать акцент на нуждах объемного потребительского рынка, отодвинув профессиональный рынок на второе место, а именно там прекрасно работал OpenGL. Учитывая консервативную природу большинства разработчиков профессиональных графических пакетов, дальнейшее развитие OpenGL весьма желанно на профессиональном сегменте, даже под Windows.

На прошлогодней выставке Siggraph кое-кто высказал мнение, что nVidia сделала прекрасный ход по искажению идеи программируемости путем убеждения Microsoft реализовать подход nVidia в DirectX 8 первым. nVidia преуспела и в обучении разработчиков использованию этих новых возможностей. Далее на сцену вышла ATi со своим подходом, и проблема стала очевидной. Разработчикам также пришлось вмешаться, поскольку они бояться опасности остаться наедине с единственным разработчиком «железа» в такой критичной области, как программирование графики. Да и сошелся ли свет клином на Windows?

Спор перешел сейчас на OpenGL, где до сих пор все попытки внести программируемость в API реализовывались через дополнения. Было создано огромное число дополнений, причем здесь возникли сходные аппаратные проблемы, к тому же усугубленные различными подводными камнями с интеллектуальной собственностью. (Всего было определено около 230 расширений OpenGL. Документация по расширениям nVidia превышает 500 страниц, в то время как сама спецификация OpenGL 1.3 умещается на 284 страницах.) Поэтому у OpenGL сейчас существует множество нерешенных проблем.

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

Ответ на поверхности, причем все не так плохо, как могло бы быть

На собрании комитета разработчиков OpenGL в сентябре 2001 года 3DLabs раскрыла свое видение OpenGL 2.0. В прошлом де-факто лидером ARB являлась SGI, следовавшая пути дальнейшего развития расширений. Но в последнее время SGI занята целиком своей реорганизацией, так что 3DLabs стала более агрессивно вести себя в комитете, заложив фундамент OpenGL 2.0 и проведя предварительную подготовку перед встречей в сентябре. Также на Siggraph представители компании показали соответствующую презентацию. Поэтому к моменту собрания ARB, члены комитета были уже подготовлены к обсуждению предложения 3DLabs.

Собрание ARB началось с наболевшей проблемы различного представления вершинных шейдеров nVidia и ATi. В результате обсуждения наметился путь решения этой проблемы, поскольку обе компании согласились выработать стратегию по созданию «переходных» вершинных шейдеров. Этому очень порадовалась и Apple, поскольку компания использует графические решения как от ATi, так и от nVidia. Поэтому ARB иногда напоминает несущийся вперед локомотив со своими целями и видением будущего.

Комитет поддержал предложение 3DLabs по разработке архитектуры OpenGL 2.0, в результате чего прояснился новый курс. Как уже говорилось выше, главной целью доработки OpenGL является поддержка программируемости графических чипов. Однако не следует забывать и другие аспекты. OpenGL был разработан в 1992 году, когда графические чипы были медленными, и вопрос об управлении памятью не поднимался. Сейчас ситуация изменилась, и для поддержки расширенной обработки пикселей в OpenGL необходимо включить управление памятью. Также OpenGL следует догнать (или обогнать) DirectX в отношении компрессии текстур, или, как называет технологию ARB, сжатия пикселей (pixel packing). Далее OpenGL должен учитывать встроенные решения. Здесь ситуация несколько отличается от обычных компьютеров, поскольку встроенная графика по своему определению фиксирована, приложения имеют свои специфические требования, да и требования эти сложными не назовешь (по крайней мере, на первой поре). Скажем, одно из направлений развития встроенных систем заключается в интеграции всех возможностей Playstation 1 в один чип.

И, наконец, группа Khronos, разработчики и покровители OpenML, надеются добавить свой стандарт в OpenGL, что позволит разрабатывать продукты, сочетающие богатую видео-функциональность и расширенные графические возможности. К тому же группа OpenML, в которую входят 3DLabs, Sun, Intel, Discreet, Evans & Sutherland, Pinnacle, RealViz и SGI, имеет свои планы на встроенные системы. Они надеются, что, развивая мультимедиа-стандарты, скажем, на Интернет-приставках, можно пойди дальше переноса игр на PDA и добиться богатых графических и видео возможностей вместе с интерактивностью.

Первая фаза развития OpenGL 2.0

Естественно, при создании нового расширенного OpenGL стандарта следует обеспечить обратную совместимость с OpenGL 1.3, при этом сохранив паритет с DirectX, включив такие возможности, как обработку вершин и пикселей и управление памятью.

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

Следующим шагом станет синтез «чистого OpenGL 2.0», который обеспечит обтекаемое API для разработчиков. Некоторые OpenGL функции будут определены как «наследственные», а разработчикам будет рекомендовано использовать более гибкие программируемые функции взамен фиксированных «наследственных». Этот шаг определен на следующей иллюстрации.

Вторая фаза развития OpenGL 2.0

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

В соответствии с планом, OpenGL сохранит фиксированную функциональность там, где не требуется гибкость и где аппаратная реализация дешевле и эффективнее. К примеру, такие функции, как область видимости (frustum clipping), отбрасывание нелицевых граней (backface culling), отображение (viewport mapping) и т.д., останутся фиксированными. Также операции с кадровым буфером, включая операции чтения/модификации/записи, продолжат быть прерогативой железа. Не забывайте, что главная цель OpenGL заключается в расширении программируемости под всеми операционными системами и аппаратными платформами.

Программируемость

Программируемость – ключевое слово в OpenGL 2.0, оно означает ориентацию API на более широкое взаимодействие с приложениями. Как и подобает подобному стандарту, программируемость графики реализуется через высокоуровневый язык программирования. Язык обладает богатой функциональностью, независим от аппаратных решений (как и подобает стандарту) и разработан специально для OpenGL. Выделим ключевые моменты языка.

Программируемая обработка вершин – про эту функцию вы еще много услышите. Она заменит трансформацию координат, наложение материала (material application), освещение и позволит выполнять произвольные операции по вершинам.
Программируемая обработка фрагментов является еще одной ключевой особенностью. Она заменит доступ к текстурам, наложение текстур и туман и позволит выполнять произвольные операции по фрагментам. Именно этого так долго ждали разработчики.
Программируемый формат изображений заменит фиксированное сжатие изображений, позволив произвольно сочетать тип и формат при отсылке/получении пиксельных данных через OpenGL.

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

Возможности

Среди других функций, включенный в новый стандарт, можно отметить следующие:

прямая поддержка многопроходных алгоритмов, управление осуществляется приложением;
более гибкая конфигурация кадрового буфера;
внеэкранный (off-screen) рендеринг с помощью OpenGL;
приложение может управлять текстурной памятью;
единое строение объектов OpenGL;
более гибкая поддержка форматов изображений при чтении и записи;
более четкие и эффективные механизмы синхронизации;
приложение управляет сменой буфера (buffer swaps);
использование любого буфера цвета (color buffer) в качестве текстуры.

Следующий график наглядно демонстрирует эволюцию OpenGL.

Преимущества нового API заключаются в стандартизации возможностей и улучшенной производительности, помимо стандартизации существующей функциональности. Большая часть опциональной области OpenGL 1.3 по обработке изображений (imaging subset) перешла в разряд стандарта OpenGL 2.0. Многочисленные расширения будут введены в стандартный состав OpenGL 2.0, что позволит выжать максимальную производительность из «железа». В результате мы выиграем в производительности при работе с графической подсистемой и добьемся большего параллелизма между процессором и графическим чипом. Схематично вид нового API можно представить следующей схемой:

Итак, когда ситуация казалась весьма мрачной, графическое сообщество доказало свою приверженность именно графике, а не своим платформам и продуктам. Даже Microsoft показала свой интерес к расширению OpenGL, но намного более воодушевляет желание основных производителей «железа» все таки открыть свою интеллектуальную собственность, хотя раннее они высказывались в противоположном направлении. И ATi, и nVidia подтвердили свое желание вместе работать над технологиями.