Что лучше opengl или direct3d
OpenGL vs. Direct3D
OpenGL, создававшийся для профессионального сектора, прочно в нем закрепился во многом благодаря своей переносимости, а вот нишу PC-игр практически полностью уступил своему конкуренту. Изменится ли эта ситуация? Чтобы существенно потеснить DirectX в game-секторе, ARB необходимо вывести OpenGL на современный уровень, и, надо сказать, комитет не сидит сложа руки: грядет так долго ожидаемая вторая версия GL, ее создатели хотят снова создать стандарт на десятилетие вперед. А что же Microsoft? Попытается ли компания захватить и профессиональный сектор? Это возможно только с выходом DirectX под другие операционные системы, что вряд ли случится.
Итак, у нас две библиотеки с практически одинаковыми возможностями и быстродействием. Отличия лишь в сложности написания кода. И даже здесь явного лидерства нет. Все зависит от уровня используемых в программе эффектов. Если нам достаточно базовой функциональности OpenGL (то есть мы не используем расширений), то разумнее использовать именно GL, а если дело дошло до продвинутых эффектов, тут предпочтительнее Direct3D. Но с появлением второго GL ситуация может в корне измениться, так как переход на новую версию избавит GL от большинства недостатков. Но Microsoft тоже не будет стоять на месте, и вполне возможно, что к моменту своего выхода OGL 2.0 уже устареет. Да и в дальнейшем для успешной конкуренции с DX ARB понадобится существенно переработать механизм внесения изменений в библиотеку, чтобы сделать OpenGL более динамично развивающимся.
Так что же выбрать начинающему 3D-программисту? Молодому поколению я, скрепя сердце, посоветую DirectX. Прежде всего потому, что знание DX поможет стать создателем игр. Все российские компании, разрабатывающие игры, используют эту технологию. А вот совет программистам с опытом не так однозначен. Чтобы ваша программа работала не только на Windows, но и на других операционных системах, следует выбрать GL. Далее следует решить, какие эффекты вам необходимы: можете ли вы обойтись стандартной функциональностью GL, или вам непременно нужно использовать более «продвинутые» эффекты. И, наконец, на сцену выходят личные предпочтения: одним придется по вкусу объектная структура DirectX, другим же она покажется слишком громоздкой. И, конечно, не стоит забывать старый анекдот: «Какой дистрибутив Linux ставить? Тот, который стоит у ближайшего гуру».
Простейшая программа на OpenGL и на Direct3D
Сейчас мы подробно разберем написание простейшей программы на этих двух библиотеках. Наши программы будут делать одно и то же, а именно рисовать один-единственный треугольник c углами разных цветов. Мы сознательно опустим всю подготовительную работу и сосредоточимся на рисовании графического примитива.
Для начала очистим фон. В OpenGL для этого потребуется написать следующую строку:
Для аналогичной операции в D3D нужно написать
d3d_Device->Clear (0, 0, D3DCLEAR_TARGET, D3DCOLOR_XRGB (0, 0, 0), 0, 0);
Вот рабочее пространство и готово, можно приступать к рисованию. В OGL все примитивы для обрисовки должны находиться между вызовами glBegin() и glEnd(), некоторым их аналогом в D3D являются d3d_Device->BeginScene () и d3d_Device->EndScene (). В случае с OGL уже можно привести фрагмент кода, выполняющий нашу задачу:
В D3D перед рисованием необходимо подготовить специальную структуру данных:
Теперь напишем следующее:
d3d_Device->CreateVertexBuffer (3*sizeof(CUSTOMVERTEX),
0, D3DFVF_XYZRHW | D3DFVF_DIFFUSE, D3DPOOL_DEFAULT, &p_VertexBuffer);
VOID* pVertices;
p_VertexBuffer->Lock (0, sizeof(g_Vertices), (BYTE**)&pVertices, 0);
memcpy (pVertices, g_Vertices, sizeof(g_Vertices));
p_VertexBuffer->Unlock();
И наконец, мы готовы к рисованию:
d3d_Device->BeginScene ();
d3d_Device->SetVertexShader (D3DFVF_CUSTOMVERTEX);
d3d_Device->SetStreamSource (0, p_VertexBuffer, sizeof(CUSTOMVERTEX));
d3d_Device->DrawPrimitive (D3DFVF_XYZRHW | D3DFVF_DIFFUSE, 0, 1);
d3d_Device->EndScene ();
Что лучше: DirectX или OpenGL
Ранее в интернете активно велись споры, что лучше: DirectX или OpenGL. Сейчас данная тема уже не такая актуальная, но все же нередко пользователи ей интересуются. Мы решили собрать всю достоверную информацию и опубликовать ее в виде сравнения обоих продуктов.
Сравнение
Стоит отметить, что раньше на свет появился именно OpenGL. Кроме того, он был установлен на ранних версиях Mac OS и Linux. Пресловутая Windows в то время была еще в состоянии эмбриона и ни о каком DirectX речи даже не шло.
Однако со временем компания Microsoft выпустила собственный графический API, который стал широко известен. Его популярность связана главным образом с тем, что он используется в самой популярной ОС.
А еще именно DirectX предпочитают многие разработчики игр. Справедливости ради стоит отметить, что некоторые из них добавляют в свои творения также OpenGL и даже Vulkan. Но таких игрушек катастрофически мало.
Так чем же так хорош API от Microsoft? Мы попробуем разобраться в данном вопросе. Но сначала рассмотрим ключевые особенности обоих проектов только потом вынесем вердикт по части их «крутости».
Поддержка расширений
Естественно, у DirectX такого и близко нет, так как это проприетарный продукт и изменения в него вносятся исключительно компанией Microsoft. Так что если производитель видеокарты и добавил какую-нибудь интересную опцию в драйвер, то в этом API она появится нескоро.
А с какой периодичностью выходят обновления для Директ Икс и без того всем известно. В лучшем случае – раз в три года. Это означает, что пользователи не увидят новых фишек до тех пор, пока ребята из Microsoft не соизволят выпустить новую версию.
С OpenGL ситуация другая. Это свободный АПИ, распространяющийся под лицензией GNU/GPL и правки в него вносятся всем сообществом. В которое, кстати, входят и ключевые производители видеокарт. Корпорации AMD и NVIDIA там точно есть.
Поэтому им не нужно кого-то ждать для того, чтобы добавить поддержку нового функционала в графический API. Это значит, что ОпенГЛ может использовать новый функционал сразу после добавления его в драйверы. И это первое преимущество свободной технологии.
Кроссплатформенность
И снова DirectX становится аутсайдером. Данный API предназначен для использования исключительно на операционных системах Windows. При этом на XP используется всего лишь версия 9.0с. А вот 10 и тем более 11 на нее нет и никогда уже не будет.
Помимо Windows данный API еще можно увидеть на игровой приставке XBOX One (и разных ее ревизий). Но эта консоль – детище компании Microsoft. Поэтому ничего удивительного здесь нет. Вы не поверите, но версий DirectX нет даже для культовой Mac OS! И о чем думает компания из Редмонда?
Совсем не то с OpenGL. Этот API используется практически во всех известных операционных системах. Он без проблем работает на Windows, Linux, Mac OS и даже FreeBSD. Хотя последняя и вовсе не предназначена для «графических излишеств».
Такая кроссплатформенность сделала свое дело. К примеру, компания Blizzard выпускает свой культовый World of Warcraft для Mac OS исключительно под Опен ГЛ. Да и на PC-версии игра способна работать как под DirectX, так и под свободным API.
Работа в профессиональных программах
И здесь побеждает ОпенГЛ. Именно этот АПИ признается профессионалами. И все потому, что он поддерживает все последние фишки видеокарт, прописанные в драйверах. А это значит, что разработчики получат новые возможности.
И нова стоит поговорить о простоте данного API. Работать с ним гораздо проще, так как здесь упорядоченный код и масштабные комментарии к нему. Именно поэтому во многих ВУЗах начинают профессиональное обучение с OpenGL.
А вот с DirectX все намного хуже. Компания Microsoft по своему обыкновению наворотила в коде таких громоздких конструкций, что с ними разберутся только профессионалы высшей пробы. Простым смертным сие не дано.
Единственное преимущество ДиректХ в этом плане – богатый инструментарий SDK. Он несколько облегчает разработку. Но даже с SDK она далеко не всем по плечу. Да и для нужд профессионалов этот API никак не подходит. Слишком он тугой на обновления.
Производительность в играх
Вот здесь свободный API сильно отстает от проприетарного. Складывается такое впечатление, что DirectX даже специально создан для игр. Ведь он показывает впечатляющие результаты даже несмотря на все фишки свободного API.
К примеру, в игре The Talos Principle (не первой свежести игрушка) на видеокарте AMD Radeon R9 Fury X при разрешении 4К и ультра настройках графики получилось 643 кадра в секунду. Такой показатель FPS избыточен.
А вот OpenGL в таких же условиях и с такой же видеокартой показал намного более скромный результат. Количество кадров в секунду едва достигло 35. Это приемлемый ФПС для неискушенного геймера, но с предыдущими цифрами его не сравнить. Аналогичная ситуация и с графическими адаптерами от Nvidia.
К сожалению, свободный API оказался совершенно не готов к такому «сражение». И с чем это связано – непонятно. Вроде бы разработчики оперативно добавляют в него новые опции. И драйвера (даже самые новые) его поддерживают.
Вердикт
Так что же все-таки лучше? Директ Х или Опен ГЛ? Все зависит от того, для чего вы будете использовать графический API. Сфера применения многое значит. Ведь в профессиональной области первый продукт значительно отстает от второго.
Но среднестатистического пользователя всякий профессиональный софт не интересует. Ему важно, чтобы игры шли нормально. А наиболее высокую производительность в игрушках показал именно DirectX. Его и будут использовать миллионы.
В выборе API также огромную роль играет ОС. К примеру, та же Windows нормально не поддерживает OpenGL. Его использование возможно только при установке драйверов от производителя. А кому охота плясать с бубнами?
Вот и получается, что менее продвинутый DirectX является наиболее предпочитаемым API для тех, кто использует исключительно Windows и любит игры. А ведь таких пользователей большинство. Потому и популярность этого API зашкаливает.
Заключение
А теперь подведем итоги. Мы попытались беспристрастно выбрать лучший графический API из двух. По всем показателям получается, что в техническом плане лучше выглядит продукт, распространяемый под лицензией GNU/GPL.
И тем не менее, победителем вышел продукт от Microsoft. Потому, что он гораздо лучше оптимизирован для игр и самой операционной системы Windows. Даже несмотря на то, что в техническом плане он существенно уступает.
СОДЕРЖАНИЕ
Доступность
С точки зрения разработчика приложений Direct3D и OpenGL одинаково открыты; полная документация и необходимые инструменты разработки доступны без ограничений.
Более подробно, это два API компьютерной графики:
Портативность
Легкость использования
Direct3D
Версия 5 (вторая версия, названная так, чтобы отразить ее выпуск как часть DirectX 5) заменила буферы выполнения новым API DrawPrimitive, но все еще считалась громоздкой. В «Открытом письме в Microsoft» Криса Хеккера DrawPrimitive назван «незрелым и плохо спроектированным клоном OpenGL, в котором отсутствуют некоторые архитектурные решения, которые делают OpenGL быстрым».
Несмотря на разногласия, Microsoft продолжала развивать API. Подробная история выпусков и добавленных функций приведена на веб-страницах Microsoft Direct3D.
OpenGL
Сравнение
В общем, Direct3D предназначен для виртуализации аппаратных 3D-интерфейсов. Direct3D освобождает программиста игр от необходимости размещать графическое оборудование. OpenGL, с другой стороны, разработан как система 3D-рендеринга с аппаратным ускорением, которую можно эмулировать в программном обеспечении. Эти два API-интерфейса в основном разработаны с учетом двух разных способов мышления.
Таким образом, существуют функциональные различия в том, как работают два API. Одно функциональное различие между API-интерфейсами заключается в том, как они управляют аппаратными ресурсами. Direct3D ожидает, что приложение сделает это, OpenGL заставит реализацию сделать это. Этот компромисс для OpenGL снижает сложность разработки для API, в то же время увеличивая сложность создания реализации (или драйвера), которая хорошо работает. Используя Direct3D, разработчик должен управлять аппаратными ресурсами независимо; однако реализация проще, и разработчики могут гибко распределять ресурсы для своего приложения наиболее эффективным способом.
Представление
Вскоре после того, как Direct3D и OpenGL стали жизнеспособными графическими библиотеками (примерно в 1995 г.), Microsoft и SGI вступили в так называемую « войну API ». В основном споры вращались вокруг того, какой API обеспечивает лучшую производительность. Этот вопрос был актуален из-за очень высокой стоимости выделенных графических процессоров в то время, что означало, что потребительский рынок использовал программные средства визуализации, реализованные Microsoft как для Direct3D, так и для OpenGL.
Ранние дебаты
На основании собственных сравнений производительности этих двух программных библиотек Microsoft продвигала Direct3D как более быстрый. Дефицит производительности был связан со строгой спецификацией и соответствием, требуемым OpenGL. Это восприятие было изменено в 1996 году на конференции Специальной группы по ГРАФИКЕ и интерактивным методам ( SIGGRAPH ). В то время Silicon Graphics (SGI) бросила вызов Microsoft с их собственной оптимизированной программной реализацией OpenGL для Windows под названием CosmoGL, которая в различных демонстрациях соответствовала или превосходила производительность Direct3D. Для SGI это была критическая веха, поскольку она показала, что низкая производительность программного рендеринга OpenGL связана с эталонной реализацией OpenGL от Microsoft, а не из-за предполагаемых недостатков конструкции в OpenGL.
Напротив, программный рендеринг с помощью 3D API не имел большого значения как для Direct3D, так и для OpenGL приложений. Не многие приложения DirectX использовали программный рендеринг Direct3D, предпочитая выполнять свой собственный программный рендеринг с использованием средств DirectDraw для доступа к оборудованию дисплея. Что касается приложений OpenGL, то ожидалась аппаратная поддержка, а оборудование было настолько быстрым, что отказ от программного обеспечения с помощью приложения OpenGL стал грубым сюрпризом для разработчика OpenGL.
Маршаллинг
Поскольку драйверы Direct3D IHV работают в режиме ядра, а код пользовательского режима не находится в руках IHV, такая оптимизация невозможна. Поскольку среда выполнения Direct3D, часть пользовательского режима, реализующая API, не может иметь явных сведений о внутренней работе драйвера, она не может эффективно поддерживать маршаллинг. Это означает, что каждый вызов Direct3D, который отправляет команды на оборудование, должен выполнять переключение режима ядра, что опять же требует времени порядка микросекунд. Это привело к появлению нескольких вариантов использования Direct3D, наиболее важным из которых является необходимость отправки больших пакетов треугольников за один вызов функции.
Поскольку в драйверах OpenGL IHV есть компонент пользовательского режима, у IHV есть возможность реализовать маршаллинг, тем самым повышая производительность. Переключение режима ядра все еще существует, но теоретическое максимальное количество переключателей в реализациях OpenGL просто равно стандартному поведению Direct3D.
Гонка с нулевыми накладными расходами на водителя
Внедрение AMD Mantle привело к усилению дискуссий о модернизации API-интерфейсов и обновлении концепций абстракции, используемых всеми API-интерфейсами для отражения операций графического процессора (GPU). Поставщики Microsoft и OpenGL начали демонстрировать свои взгляды на ограничение или полное устранение накладных расходов на драйверы (объем работы, который должен выполнять ЦП для подготовки команд графического процессора).
Состав
Расширения
Когда видеокарты добавили поддержку пиксельных шейдеров (известных в OpenGL как «фрагментные шейдеры»), Direct3D предоставил один стандарт «Pixel Shader 1.1» (PS1.1), с которым GeForce 3 и выше и Radeon 8500 и выше заявляли о совместимости. В OpenGL к тем же функциям можно было получить доступ через множество настраиваемых расширений.
Такая ситуация просуществовала недолго в обоих API. Карты пиксельного затенения второго поколения функционировали гораздо более похоже, каждая архитектура развивалась в сторону одного и того же типа обработки пикселей. Таким образом, Pixel Shader 2.0 допускает унифицированный путь кода в Direct3D. Примерно в то же время OpenGL представила свои собственные расширения вершинных и пиксельных шейдеров, одобренные ARB ( GL_ARB_vertex_program и GL_ARB_fragment_program ), и оба набора карт также поддерживали этот стандарт.
Пользователи
Профессиональная графика
В прошлом многие профессиональные видеокарты поддерживали только OpenGL. Начиная с 2010 года практически все профессиональные карты, работающие на платформе Windows, также будут поддерживать Direct3D. Частично это связано с переходом на рынок профессиональной графики с оборудования на базе Unix, такого как SGI и Sun, на более дешевые системы на базе ПК, что привело к росту Windows в этом сегменте рынка и в то же время предоставило новый рынок. для программного обеспечения OpenGL в потребительских системах на базе Unix, работающих под управлением Linux или Mac OS X.
Разработчики игр обычно не требовали такого широкого API, как профессиональные разработчики графических систем. Многие игры не нуждаются в наложении плоскостей, трафаретов и т. Д., Хотя это не мешает некоторым разработчикам игр использовать их, когда они доступны. В частности, разработчиков игр редко интересует пиксельная инвариантность, требуемая в определенных частях стандартов OpenGL, которые, наоборот, очень полезны для кино и компьютерного моделирования.
Однажды SGI и Microsoft предприняли попытку объединить OpenGL и DirectX. Графики API Fahrenheit был призван объединить как высокую конечную способность OpenGL с широкой поддержкой низкоуровневой DirectX. В конце концов Microsoft отказалась от проекта, так и не выделив достаточно ресурсов для создания своей части механизма рендеринга. Этот шаг был широко распространен с целью обеспечить привязку разработчиков к платформе Windows-DirectX, которая была бы потеряна, если бы Fahrenheit API стал де-факто стандартным графическим API мира. Однако Fahrenheit привел ко многим улучшениям в DirectX, и главный архитектор Fahrenheit теперь работает в Microsoft над DirectX.
На заре игр с 3D-ускорением производительность и надежность были ключевыми критериями, и несколько карт 3D-ускорителей соревновались друг с другом за доминирование. Программное обеспечение было написано для конкретной марки видеокарты. Однако со временем OpenGL и Direct3D появились как программные уровни над оборудованием, в основном из-за поддержки промышленностью кросс-аппаратной графической библиотеки. Конкуренция между ними росла, поскольку каждый разработчик игр выбирал либо одно, либо другое.
В мире консолей доминируют собственные собственные API-интерфейсы, при этом некоторые консоли (например, PS3) предоставляют оболочку OpenGL вокруг своего собственного API. Исходный Xbox поддерживал Direct3D 8.1 как свой собственный API, а Xbox 360 поддерживает DirectX9 как свой собственный API. Большинство разработчиков консолей предпочитают использовать собственные API-интерфейсы для каждой консоли, чтобы максимизировать производительность, что делает сравнения OpenGL и Direct3D актуальными в основном для платформ ПК.
Мобильные телефоны и другие встраиваемые устройства
OpenGL ES доступен в 6 вариантах: OpenGL ES 1.0, 1.1, 2.0, 3.0, 3.1, 3.2. В выпуске 2.0 удалена обратная совместимость со старыми вариантами из-за обширных программируемых конвейерных функций, доступных в GL ES 2.0, по сравнению с фиксированными конвейерными функциями GL ES 1.0 и 1.1. OpenGL ES 3.0 нуждался в новом оборудовании по сравнению с OpenGL ES 2.0, в то время как OpenGL ES 3.1 предназначен для обновления программного обеспечения, требующего только новых драйверов.
Windows Phone 8 реализует Direct3D 11 (ограниченный уровнем функций 9_3).
Direct3D vs OpenGL: история противостояния
По сей день в Интернете можно встретить споры о том, какой же графический API лучше: Direct3D или OpenGL? Несмотря на свой религиозный характер, такие словесные баталии приносят полезный результат в виде неплохих исторических обзоров развития аппаратно-ускоренной графики.
Целью данного поста является перевод одного из таких экскурсов в историю, написанного Джейсоном МакКессоном (Jason L. McKesson) в ответ на вопрос «Почему разработчики игр предпочитают Windows». Этот текст вряд ли отвечает на поставленный вопрос, но историю развития и противостояния двух самых популярных графических API он описывает очень красочно и довольно подробно, поэтому в переводе я сохранил авторскую разметку. Текст написан в середине 2011 года и охватывает промежуток времени, начинающийся незадолго до появления Direct3D и до момента написания. Автор оригинального текста является опытным разработчиком игр, активным участником StackOverflow и создателем обширного учебника о современном программировании 3D-графики. Итак, предоставим слово Джейсону.
Предисловие
Прежде чем мы начнём, я хотел бы сказать, что знаю больше об OpenGL, чем о Direct3D. В своей жизни я не написал ни строчки кода на D3D, но писал руководства по OpenGL. Но то, о чём я хочу рассказать — вопрос не предубеждения, а истории.
Рождение конфликта
Однажды, где-то в начале 90-х, Microsoft огляделись вокруг. Они увидели, что SNES и Sega Genesis — это очень здорово, на них можно поиграть во множество экшн-игр и всего такого. И они увидели ДОС. Разработчики писали досовские игры как консольные: близко к железу. Тем не менее, в отличие от консолей, где разработчик знал, какое железо будет у пользователя, дос-разработчики были вынуждены писать под множество конфигураций. А это намного сложнее, чем кажется.
Но у Microsoft была бо́льшая проблема: Windows. Видите ли, Windows хотела полностью владеть железом в отличие от ДОС, которая позволяла разработчикам делать всё что угодно. Владение железом необходимо для взаимодействия между приложениями. Но такое взаимодействие — это в точности то, что ненавидят разработчики игр, потому что оно потребляет драгоценные ресурсы, которые они могли бы использовать для всяких крутых вещей.
Для продвижения разработки игр на Windows, Microsoft нуждалась в однородном API, который был бы низкоуровневым, работал бы на Windows без потерь производительности, и был бы совместим с различным железом. Единый API для графики, звука и устройств ввода.
Так родился DirectX.
3D ускорители появились несколько месяцев спустя. И Microsoft вляпались в неприятности. Дело в том, что DirectDraw, графический компонент DirectX, работал только с 2D графикой: выделял графическую память и делал быстрые битовые операции между различными секторами памяти.
Поэтому Microsoft купили немного стороннего ПО и превратили его в Direct3D версии 3. Его ругали абсолютно все. И было за что: чтение кода на D3D v3 выглядело как расшифровка письменности исчезнувшей древней цивилизации.
Старик Джон Кармак в Id Software посмотрел на это безобразие, сказал «Да пошло оно. », и решил писать с использованием другого API: OpenGL.
Однако другая сторона этой запутанной истории заключалась в том, что Microsoft совместно с SGI работали над реализацией OpenGL для Windows. Идея была в том, чтобы привлечь разработчиков типичных GL-приложений для рабочих станций: САПР, систем моделирования и тому подобных вещей. Игры были последним, о чём они думали. В основном это касалось Windows NT, но Microsoft решили добавить OpenGL и в Windows 95.
Чтобы сманить разработчиков софта для рабочих станций на Windows, Microsoft решили подкупить их доступом к новомодным 3D-ускорителям. Они реализовали протокол для устанавливаемых клиентских драйверов: графическая карта могла заменить программный OpenGL от Microsoft своей аппаратной реализацией. Код автоматически использовал аппаратный OpenGL, если таковой был доступен.
Однако, в те времена потребительские видеокарты не имели поддержки OpenGL. Это не остановило Кармака от портирования Quake на OpenGL на рабочей станции SGI. В readme-файле GLQuake можно прочитать следующее:
Теоретически, glquake запустится на любой реализации OpenGL, которая поддерживает расширение texture objects. Но пока вы не запустите её на очень мощном железе, которое ускоряет всё, что нужно, работать она будет непростительно медленно. Если игре потребуется работать через какие-либо программные эмуляции, её производительность скорее всего не превысит один кадр в секунду.
В настоящее время (март 1997), единственной полностью совместимой с opengl железкой, способной потянуть glquake на приемлемом уровне, является ОЧЕНЬ дорогая видеокарта intergraph realizm. 3dlabs существенно увеличили её производительность, но с имеющимися драйверами она всё ещё недостаточно подходит для игры. Некоторые из драйверов от 3dlabs для плат glint и permedia ещё и крэшат NT при выходе из полноэкранного режима, поэтому я не рекомендую запускать glquake на железе от 3dlabs.
3dfx предоставляет opengl32.dll, которая реализует все нужное для glquake, но это не полная реализация opengl. Другие opengl-приложения скорее всего с ней не заработают, поэтому рассматривайте её в основном как «драйвер для glquake».
Это было рождением miniGL драйверов. В конечном итоге они эволюционировали в полноценные реализации OpenGL, как только железо стало достаточно мощным для аппаратной поддержки этой функциональности. nVidia стала первой, кто предложил полную реализацию OpenGL. Другие поставщики всё ещё медлили, что стало одной из причин перехода разработчиков на Direct3D, поддерживаемый более широким спектром оборудования. В конце концов остались только nVidia и ATI (которая сейчас AMD), и у обеих имелись хорошие реализации OpenGL.
Рассвет OpenGL
Итак, участники определены: Direct3D против OpenGL. Это поистине удивительная история, учитывая то, как плох был D3D v3.
Совет по архитектуре OpenGL (Architectural Review Board, ARB) — это организация, ответственная за поддержание и развитие OpenGL. Они выпускают множество расширений, содержат репозиторий с расширениями, и создают новые версии API. ARB — это комитет, состоящий из большого количества игроков индустрии компьютерной графики и некоторых производителей ОС. Apple и Microsoft в разное время тоже были членами ARB.
3Dfx выходит на сцену со своей Voodoo2. Это первая видеокарта, позволяющая делать мультитекстурирование, которое не было ранее предусмотрено в OpenGL. В то время как 3Dfx была решительно против OpenGL, nVidia, следующий производитель чипа с мультитекстурированием (TNT1), были без ума от OpenGL. Тогда ARB выпустил расширение GL_ARB_multitexture, которое предоставляло доступ к множественным текстурам.
Тем временем появляется Direct3D v5. Теперь D3D действительно стал API, а не какой-то несуразицей. В чём же проблема? В отсутствии мультитекстурирования.
Но это не доставляло таких неудобств, какие могло бы доставить, потому что почти никто не использовал множественное текстурирование. Мультитекстурирование почти не вредит производительности, и во многих случаях разница незаметна на фоне многопроходности. И конечно, разработчики игр очень любят чтобы их игры уверенно работали на старом железе, которое не имело поддержку множественных текстур, поэтому многие игры были выпущены без неё.
D3D вздохнул с облегчением.
Время шло, и nVidia выкатили GeForce 256 (не путать с самым первым GeForce GT-250), прекратив борьбу на рынке графических плат на следующие два года. Главным конкурентным преимуществом этой платы была возможность делать преобразования вершин и освещение (transformation & lighting, T&L) аппаратно. Но это ещё не всё: nVidia любила OpenGL настолько, что их T&L-движок фактически и был OpenGL. Почти буквально! Как я понимаю, некоторые из их регистров получали на вход напрямую численные значения переменных типа GLenum.
Выходит Direct3D v6. Наконец то подоспело множественное текстурирование… но без аппаратного T&L. В OpenGL всегда был T&L-конвейер, хотя до GeForce 256 он был реализован программно. Поэтому для nVidia оказалось довольно просто переделать программную реализацию в аппаратное решение. В D3D аппаратное T&L появилось только к седьмой версии.
Заря эпохи шейдеров, OpenGL во мгле
Затем появилась GeForce 3. В то же самое время произошло много интересных вещей.
В Microsoft решили, что они больше не собираются опаздывать. Поэтому вместо того, чтобы смотреть, что сделает nVidia, и копировать их разработки уже пост-фактум, Microsoft приняли изумительное решение: пойти и поговорить. И они полюбили друг друга, и у них появилась совместная маленькая консоль.
Шумный развод произошёл позже, но это совсем другая история.
Для рынка PC это значило, что GeForce 3 вышла одновременно с D3D v8, и нетрудно видеть, как GeForce 3 повлияла на шейдеры D3D v8. Пиксельные шейдеры Shader Model 1.0 были очень сильно заточены под оборудование nVidia. Не было предпринято ни единой попытки сделать хоть что нибудь для абстрагирования от железа nVidia. Shader Model 1.0 стала тем, для чего предназначена GeForce 3.
Когда ATI ворвалась в гонку производительности видеокарт со своей Radeon 8500, появилась одна проблема. Пиксельный конвейер Radeon 8500 оказался более мощным, чем у nVidia. Поэтому Microsoft выпустила Shader Model 1.1, которая в основном была тем, для чего предназначена 8500.
Это звучит как поражение D3D, но успех и провал — понятия относительные. На самом деле эпический провал поджидал OpenGL.
В nVidia очень любили OpenGL, поэтому после выхода GeForce 3 они выпустили целую пачку расширений для OpenGL. Проприетарных расширений, которые работали только на nVidia. Естественно, когда появилась плата 8500, она не могла использовать ни одно из них.
Итак, на D3D 8 вы могли хотя бы запустить шейдеры SM 1.0. Конечно, чтобы использовать всю крутость 8500, приходилось писать новые шейдеры, но код хотя бы работал.
Чтобы получить любые шейдеры на Radeon 8500 в OpenGL, ATI пришлось разработать несколько расширений для OpenGL. Проприетарных расширений, которые работали только на ATI. В итоге, чтобы разработчики могли заявить, что они прикрутили к своему движку шейдеры, им приходилось писать отдельный код для nVidia и отдельный код для ATI.
Вы возможно спросите: «А где же был комитет ARB, который должен поддерживать OpenGL на плаву?». А были они там, где в конечном итоге оказываются многие комитеты: они сидели и тупили.
Обратите внимание, выше я упомянул ARB_multitexture, потому что это расширение глубоко замешано во всей ситуации. Стороннему наблюдателю казалось, что ARB вообще хочет избежать идеи шейдеров. Они решили, что если они вбухают достаточно конфигурируемости в фиксированный конвейер, то он сравняется по своим возможностям с программируемым шейдерным конвейером.
ARB выпускали расширения одно за другим. Каждое расширение со словами «texture_env» в названии было попыткой залатать этот устаревающий дизайн. Посмотрите на список расширений: таких расширений было выпущено восемь штук, и многие из них были переведены в основную функциональность OpenGL.
В то время Microsoft входила в ARB, и покинула его только к выпуску D3D 9, поэтому возможно, Microsoft саботировали OpenGL некоторым образом. Лично я сомневаюсь в этой теории по двум причинам. Во-первых, они должны были бы заручиться поддержкой других членов Комитета, потому как каждый участник имеет всего один голос. Во-вторых, что более важно, Комитету не нужна была помощью Microsoft чтобы всё запороть, свидетельства чему мы увидим далее.
В итоге ARB, скорее всего под давлением ATI и nVidia (обе являются активными участниками), наконец очнулся и ввёл в стандарт ассемблерные шейдеры.
Хотите ещё более дурацкую историю?
Аппаратное T&L. Это то, что в OpenGL было изначально. Чтобы получить максимально возможную производительность аппаратного T&L, нужно хранить данные вершин на GPU. Все-таки, GPU — это основной потребитель вершинных данных.
В D3D v7 Microsoft ввела концепцию вершинных буферов, которые выделяют куски памяти в GPU и размещают там данные вершин.
Хотите знать когда в OpenGL появилась эквивалентная функциональность? Да, nVidia, как самый большой любитель OpenGL, выпустила своё расширение для хранения массивов вершин на GPU ещё во времена выхода GeForce 256. Но когда же ARB представил такую функциональность?
Два года спустя. Это было после того, как она утвердили вершинные и фрагментные (пиксельные в терминах D3D) шейдеры. Столько времени ушло у ARB чтобы разработать кросс-платформенное решение для хранения вершинных данных в памяти GPU. И это то, что необходимо, чтобы аппаратное T&L достигло максимальной производительности.
Итак, OpenGL был сломан в течение какого-то времени. Отсутствовали кросс-платформенные шейдеры и аппаратно-независимое хранение вершин в GPU, в то время как пользователи D3D наслаждались и тем и другим. Могло ли стать ещё хуже?
Можно сказать, что могло. Встречайте: 3D Labs.
Вы спросите: кто же они? Они — мёртвая компания, которую я считаю истинным убийцей OpenGL. Конечно, общая несостоятельность Комитета сделала OpenGL уязвимым, в то время как он должен был рвать D3D в клочья. Но по-моему, 3D Labs — возможно единственная причина текущего положения OpenGL на рынке. Что они для этого сделали?
Они разработали язык шейдеров для OpenGL.
Что в итоге и случилось.
В стремлении оказаться на плаву в мире, которому были не нужны их продукты, 3D Labs заявились на конференцию Game Developer Conference с презентацией того, что они назвали «OpenGL 2.0». Это был OpenGL API, переписанный с нуля. И это имело смысл, ибо в те времена в API OpenGL было полно хлама (который, впрочем, остаётся там и по сей день). Посмотрите хотя бы на то, насколько эзотерически сделаны загрузка и биндинг текстур.
Частью их предложения был язык шейдеров. Да, именно он. Тем не менее, в отличие от имеющихся кросс-платформенных расширений, их язык шейдеров был «высокоуровневым» (C — это высокий уровень для языка шейдеров).
В это же время в Microsoft работали над своим собственным языком шейдеров. Который они, включив всё своё коллективное воображение, назвали… Высокоуровневым Языком Шейдеров (HLSL). Но их подход к языку был фундаментально иным.
Наибольшей проблемой языка от 3D Labs было то, что он был встраиваемым. Microsoft полностью самостоятельно определяла свой язык. Они выпустили компилятор, который генерировал ассемблерный код для шейдеров SM 2.0 (или выше), который, в свою очередь, можно было скармливать D3D. Во времена D3D v9, HLSL никогда не касался D3D напрямую. Он был хорошей, но необязательной абстракцией. У разработчика всегда была возможность взять выхлоп компилятора и подправить его для максимальной производительности.
В языке от 3D Labs ничего этого не было. Вы отдаёте драйверу C-подобный язык, и он создаёт шейдер. На этом всё. Никакого ассемблерного шейдера, ничего, что можно скормить чему-то ещё. Только объект OpenGL, представляющий шейдер.
Для пользователей OpenGL это означало, что они становились подвержены капризам разработчиков OpenGL, которые только научились компилировать ассемблероподобные языки. В компиляторах новорождённого языка шейдеров OpenGL (GLSL) свирепствовали баги. Что ещё хуже, если вам удавалось заставить шейдер корректно компилироваться на различных платформах (что уже само по себе было большим достижением), то он всё ещё был подвержен оптимизаторам тех времён, которые были не так уж оптимальны, как могли бы быть.
Это было большим, но не единственным недостатком GLSL. Далеко не единственным.
В D3D, как и в старых ассемблерных языках OpenGL, можно было смешивать и всячески комбинировать вершинные и фрагментные шейдеры. Можно было использовать любой вершинный шейдер с любым совместимым фрагментным шейдером, если они взаимодействовали через одинаковый интерфейс. Более того, допускалась даже некоторая несовместимость: например, вершинный шейдер мог подать на выход значение, которое не использовалось фрагментным шейдером.
В GLSL ничего такого не было. Вершинный и фрагментный шейдер сплавлялись воедино, образовывая нечто, названное компанией 3D Labs «программным объектом». Поэтому, для совместного использования нескольких вершинных и фрагментных шейдеров в различных комбинациях, приходилось создавать несколько программных объектов. Это стало причиной второй по величине проблемы.
3D Labs думали, что они самые умные. Они взяли C/C++ за основу для модели компиляции GLSL. Это когда вы берёте один c-файл и и компилируете его в объектный файл, а затем берёте несколько объектных файлов и компонуете их в программу. Именно так компилируется GLSL: сначала вы компилируйте вершинный или фрагментный шейдер в шейдерный объект, затем помещаете эти объекты в программный объект и компонуете их воедино чтобы наконец сформировать программу.
В теории это позволяло появиться таким крутым вещам, как «библиотечные» шейдеры, которые содержат код, вызываемый основным шейдером. На практике это приводило к тому, что шейдеры компилировались дважды: один раз на стадии компиляции и второй раз на стадии компоновки. В частности, этим славился компилятор от nVidia. Он не генерировал какой-либо промежуточный объектный код; он компилировал вначале, выбрасывал полученный результат и компилировал заново на стадии компоновки.
Таким образом, чтобы приделать вершинный шейдер к двум разным фрагментным шейдерам, приходилось компилировать намного больше, чем в D3D. Особенно с учётом того, что вся компиляция производится оффлайново, а не перед непосредственным исполнением программы.
У GLSL были и другие проблемы. Возможно, было бы неправильным сваливать всю вину на 3D Labs, ибо в конечном итоге ARB утвердили и включили в OpenGL язык шейдеров (но ничего больше из предложений 3DLabs). Однако, изначальная идея всё равно была за 3D Labs.
И теперь самое печальное: 3D Labs были правы (в основном). GLSL не векторный язык, каким в то время был HLSL. Так случилось потому, что железо 3D Labs было скалярным (как современное железо от nVidia), и они были полностью правы в выборе направления, которому позднее последовали многие производители оборудования.
Они были правы и с выбором модели компиляции для «высокоуровневого» языка. Даже D3D в итоге к этому пришёл.
Проблема в том, что 3D Labs были правы в неправильное время. И в попытках попасть в будущее преждевременно, в попытках быть готовыми к будущему, они отставили в сторону настоящее. Это выглядит как T&L-функциональность в OpenGL, которая была в нём всегда. За исключением того, что T&L-конвейер OpenGL был полезным и до появления аппаратного T&L, а GLSL был обузой до того как остальной мир догнал его.
GLSL — это хороший язык сейчас. Но что было в то время? Он был ужасен. И OpenGL пострадал от этого.
На подходе к апофеозу
Возможно вы слышали эту историю. Во времена OpenGL 2.1, у OpenGL были большие проблемы. Он тащил за собой огромный груз совместимости. API больше не был простым в использовании. Одну вещь можно было сделать пятью разными способами и непонятно какой из них быстрее. Можно было «изучить» OpenGL по простым руководствам, но при этом вы не изучали тот OpenGL, который даёт настоящую графическую мощь и производительность.
ARB решили предпринять ещё одну попытку изобрести OpenGL. Это было как «OpenGL 2.0» от 3D Labs, но лучше, потому что за этой попыткой стоял ARB. Они назвали это «Longs Peak».
Что такого плохого в том, чтобы потратить немного времени на улучшение API? Плохо то, что Microsoft оказалась в довольно шатком положении. Это было время перехода на Vista.
В Vista Microsoft решили внести давно напрашивающиеся изменения в графические драйверы. Они заставили драйверы обращаться к ОС за виртуализацией графической памяти и многим другим.
Можно долго спорить о достоинствах такого подхода, и о том, был ли он вообще возможен, но факт остаётся фактом: Microsoft сделала D3D 10 только для ОС Vista и выше. Даже на поддерживающем D3D железе было невозможно запустить D3D приложение без Висты.
Вы возможно помните, что Виста… скажем так, работала не очень хорошо. Итак, у нас была неторопливая ОС, новый API, который работал только на этой ОС, и новое поколение железа, которое нуждалось в этом API и ОС чтобы делать нечто большее, чем просто превосходить предыдущее поколение в производительности.
Тем не менее, разработчики могли использовать функциональность уровня D3D 10 через OpenGL. То есть могли бы, если бы ARB не был занят работой над Long Peaks.
ARB потратили добрые полтора-два года, работая над улучшением API. Ко времени выхода OpenGL 3.0 переход на Висту закончился, Windows 7 была на подходе, и разработчиков игр больше не заботила функциональность уровня D3D 10. В конце концов, оборудование для D3D 10 прекрасно работало с приложениями на D3D 9. С увеличением темпов портирования с ПК на консоли (или с переходом ПК-разработчиков на консольный рынок), разработчикам всё меньше была нужна функциональность D3D 10.
Если бы разработчики получили доступ к этой функциональности даже на Windows XP, развитие OpenGL могло бы получить живительный заряд бодрости. Но ARB упустили эту возможность. А хотите знать что самое ужасное?
ARB не смогли изобрести API с нуля несмотря на трату двух драгоценных лет на попытки сделать это. Поэтому они вернули статус-кво, добавив лишь механизм для объявления функциональности устаревшей.
В итоге ARB не только упустили ключевые возможности, но и не выполнили ту работу, которая привела их к этому упущению. Это был epic fail по всем направлениям.
Такова история о противостоянии OpenGL и Direct3D. История упущенных возможностей, величайшей глупости, умышленного безрассудства и банальных нелепостей.