Многие из ответов здесь действительно хороши. Но проблема OpenGL и Direct3D (D3D), вероятно, должна быть решена. И это требует ... урока истории.
И прежде чем мы начнем, я знаю гораздо больше об OpenGL, чем о Direct3D . Я никогда не писал ни строчки кода D3D в своей жизни, и я написал учебники по OpenGL. Так что то, что я собираюсь сказать, не является вопросом предвзятости. Это просто вопрос истории.
Рождение Конфликта
Однажды, в начале 90-х, Microsoft огляделась вокруг. Они увидели, что SNES и Sega Genesis великолепны, запускают множество экшенов и тому подобное. И они увидели DOS . Разработчики закодировали DOS-игры, такие как консольные игры: прямо на металл. Однако, в отличие от консолей, когда разработчик, создавший игру SNES, знал, какое оборудование будет у пользователя, разработчикам DOS приходилось писать для нескольких возможных конфигураций. И это сложнее, чем кажется.
И у Microsoft была большая проблема: Windows. Видите ли, Windows хотела владеть оборудованием, в отличие от DOS, который в значительной степени позволял разработчикам делать что угодно. Владение оборудованием необходимо для того, чтобы взаимодействовать между приложениями. Сотрудничество - именно то, что ненавидят разработчики игр, потому что оно требует драгоценных аппаратных ресурсов, которые они могли бы использовать, чтобы быть крутыми.
Чтобы способствовать разработке игр для 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 решила добавить его и в Win95.
Чтобы привлечь разработчиков рабочих станций к Windows, Microsoft решила попытаться подкупить их доступом к этим новомодным 3D-картам. Microsoft внедрила протокол Installable Client Driver: производитель видеокарт мог бы заменить программную реализацию Microsoft OpenGL аппаратной. Код может автоматически использовать аппаратную реализацию OpenGL, если она доступна.
В первые дни видеокарты потребительского уровня не имели поддержки OpenGL. Это не помешало Кармаку просто портировать Quake на OpenGL (GLQuake) на своей рабочей станции SGI. Как мы можем прочитать из readme о GLQuake:
Теоретически, glquake будет работать на любом совместимом OpenGL, который поддерживает расширения текстурных объектов, но если это не очень мощное аппаратное обеспечение, которое ускоряет все необходимое, игра не будет приемлемой. Если ему придется пройти через любые пути программной эмуляции, производительность, скорее всего, будет ниже одного кадра в секунду.
В настоящее время (март '97) единственное стандартное оборудование opengl, которое может разумно воспроизводить glquake, - это реализация intergraph, ОЧЕНЬ дорогая карта. 3dlabs значительно улучшила свою производительность, но с доступными драйверами она все еще недостаточно хороша для игры. Некоторые из существующих драйверов 3dlabs для glint и permedia-платформ могут также приводить к сбою NT при выходе из полноэкранного режима, поэтому я не рекомендую запускать glquake на оборудовании 3dlabs.
3dfx предоставил opengl32.dll, который реализует все, что нужно glquake, но это не полная реализация opengl. Другие приложения opengl вряд ли будут работать с ним, поэтому считают его «драйвером glquake».
Это было рождение водителей miniGL. В конечном итоге они превратились в полные реализации OpenGL, поскольку аппаратное обеспечение стало достаточно мощным для реализации большей части функциональности OpenGL в аппаратном обеспечении. nVidia была первой, кто предложил полную реализацию OpenGL. Многие другие поставщики боролись, что является одной из причин, почему разработчики предпочли Direct3D: они были совместимы с более широким спектром оборудования. В конце концов остались только nVidia и ATI (теперь AMD), и оба имели хорошую реализацию OpenGL.
OpenGL Ascendant
Таким образом, сцена установлена: Direct3D против OpenGL. Это действительно удивительная история, учитывая, насколько плохим был D3D v3.
OpenGL Architectural Review Board (ARB) - это организация, ответственная за поддержку OpenGL. Они выпускают несколько расширений, поддерживают репозиторий расширений и создают новые версии API. ARB - это комитет, состоящий из многих игроков графической индустрии, а также некоторых производителей ОС. Apple и Microsoft в разное время были членами ARB.
3Dfx выходит с Voodoo2. Это первое оборудование, которое может выполнять мультитекстурирование, чего раньше OpenGL не мог сделать. В то время как 3Dfx был категорически против OpenGL, NVIDIA, создатели следующего мультитекстурированного графического чипа (TNT1), полюбили его. Поэтому ARB выпустил расширение: GL_ARB_multitexture, которое позволило бы получить доступ к мультитекстурированию.
Между тем, Direct3D v5 выходит. Теперь D3D стал настоящим API , а не чем-то, что может вызвать рвота у кошки. Проблема? Нет мультитекстурирования.
К сожалению.
Теперь это не повредит почти так же, как следовало бы, потому что люди не слишком много использовали мультитекстурирование. Не напрямую. Мультитекстурирование сильно ухудшает производительность, и во многих случаях оно того не стоит по сравнению с многопроходной передачей. И, конечно, разработчики игр любят, чтобы их игры работали на старом оборудовании, у которого не было мультитекстурирования, поэтому многие игры поставлялись без него.
Таким образом, D3D получил отсрочку.
Проходит время, и NVIDIA развертывает GeForce 256 (а не GeForce GT-250; самую первую GeForce), что в значительной степени положит конец конкуренции в видеокартах в течение следующих двух лет. Основным преимуществом является возможность выполнять вершинное преобразование и освещение (T & L) в аппаратном обеспечении. Кроме того, NVIDIA настолько сильно любила OpenGL, что их движком T & L по сути был OpenGL. Почти буквально; насколько я понимаю, некоторые из их регистров фактически использовали счетчики OpenGL непосредственно в качестве значений.
Direct3D v6 выходит. Мультитекстура наконец, но ... без аппаратного T & L. OpenGL всегда имел конвейер T & L, хотя до 256 он был реализован в программном обеспечении. Поэтому NVIDIA было очень легко просто преобразовать свою программную реализацию в аппаратное решение. Так будет до D3D v7, пока у D3D наконец не появится аппаратная поддержка T & L.
Рассвет Шейдеров, Сумерки OpenGL
Затем вышла GeForce 3. И много чего произошло одновременно.
Microsoft решила, что они больше не опаздывают. Таким образом, вместо того, чтобы смотреть на то, что делала NVIDIA, а затем копировать ее после факта, они заняли удивительную позицию, обращаясь к ним и разговаривая с ними. А потом они влюбились и собрали небольшую консоль.
Грязный развод последовал позже. Но это в другой раз.
Для ПК это означало, что GeForce 3 вышла одновременно с D3D v8. И нетрудно понять, как GeForce 3 повлияла на шейдеры D3D 8. Пиксельные шейдеры Shader Model 1.0 были чрезвычайно специфичны для аппаратного обеспечения NVIDIA. Не было никаких попыток абстрагировать аппаратное обеспечение NVIDIA; SM 1.0 был просто тем, что делал GeForce 3.
Когда ATI начала участвовать в гонке видеокарт с Radeon 8500, возникла проблема. Трубопровод обработки пикселей 8500 был более мощным, чем у NVIDIA. Таким образом, Microsoft выпустила Shader Model 1.1, которая в основном была «Что бы ни делал 8500».
Это может звучать как провал со стороны D3D. Но неудача и успех - это вопросы степени. И эпический провал происходил на OpenGL-земле.
NVIDIA очень понравилась OpenGL, поэтому, когда появилась GeForce 3, они выпустили множество расширений OpenGL. Проприетарные расширения OpenGL: только для NVIDIA. Естественно, когда появился 8500, он не смог использовать ни один из них.
Видите ли, по крайней мере, на D3D 8, вы можете запускать свои шейдеры SM 1.0 на оборудовании ATI. Конечно, вы должны были написать новые шейдеры, чтобы воспользоваться преимуществами 8500, но по крайней мере ваш код работал .
Чтобы иметь какие-либо шейдеры на Radeon 8500 в OpenGL, ATI пришлось написать несколько расширений OpenGL. Запатентованные расширения OpenGL: только для ATI. Таким образом, вам нужен был NVIDIA codepath и ATI codepath, просто чтобы иметь шейдеры вообще.
Теперь вы можете спросить: «Где был OpenGL ARB, чья работа состояла в том, чтобы поддерживать OpenGL в актуальном состоянии?» Там, где часто заканчиваются многие комитеты: глупость.
Видите, я упомянул ARB_multitexture выше, потому что это сильно влияет на все это. Казалось, ARB (с точки зрения постороннего) хочет вообще избежать идеи шейдеров. Они полагали, что, если бы они наложили достаточную конфигурируемость на конвейер с фиксированной функцией, они могли бы равняться способности шейдерного конвейера.
Таким образом, АРБ выпустил расширение после расширения. Каждое расширение со словами "texture_env" было еще одной попыткой исправить этот устаревший дизайн. Проверьте реестр: между расширениями ARB и EXT было сделано восемь таких расширений. Многие были повышены до основных версий OpenGL.
Microsoft была частью ARB в это время; они ушли в то время, когда D3D 9 ударил. Так что вполне возможно, что они каким-то образом саботировали OpenGL. Я лично сомневаюсь в этой теории по двум причинам. Во-первых, они должны были бы получить помощь от других членов АРБ, чтобы сделать это, поскольку каждый член получает только один голос. И что самое важное, АРБ не нуждался в помощи Microsoft, чтобы все испортить. Мы увидим дальнейшие доказательства этого.
В конце концов, ARB, вероятно находящийся под угрозой как со стороны ATI, так и NVIDIA (оба активных участника), в конечном итоге вытащили свою голову достаточно долго, чтобы предоставить реальные шейдеры в стиле сборки.
Хотите что-то еще глупее?
Аппаратное обеспечение T & L. Что-то OpenGL было первым . Ну, это интересно. Чтобы получить максимально возможную производительность от аппаратного T & L, вам нужно хранить ваши данные вершин на GPU. В конце концов, именно GPU действительно хочет использовать ваши данные вершин.
В D3D v7 Microsoft представила концепцию буферов вершин. Это выделенные участки памяти GPU для хранения данных вершин.
Хотите знать, когда OpenGL получил свой эквивалент этого? О, NVIDIA, будучи любителем всех вещей OpenGL (если они являются проприетарными расширениями NVIDIA), выпустила расширение диапазона массивов вершин, когда GeForce 256 впервые появилась. Но когда АРБ решил предоставить аналогичную функциональность?
Два года спустя . Это было после того, как они утвердили вершинные и фрагментные шейдеры (пиксель на языке D3D). Вот так много времени понадобилось ARB для разработки кроссплатформенного решения для хранения данных вершин в памяти GPU. Опять же, то, что аппаратному T & L нужно для достижения максимальной производительности.
Один язык погубит их всех
Таким образом, среда разработки OpenGL была на некоторое время разрушена. Нет кросс-аппаратных шейдеров, нет кросс-аппаратного хранилища вершин графического процессора, в то время как пользователям D3D нравилось и то и другое. Может ли быть хуже?
Вы ... вы могли бы сказать это. Войдите в 3D Labs .
Кто они, спросите вы? Это несуществующая компания, которую я считаю истинными убийцами OpenGL. Конечно, общая неспособность ARB сделала OpenGL уязвимой, когда она должна была владеть D3D. Но 3D Labs - это, пожалуй, единственная главная причина моего нынешнего состояния рынка OpenGL. Что они могли сделать, чтобы вызвать это?
Они разработали язык затенения OpenGL.
Видите, 3D Labs была умирающей компанией. Их дорогие графические процессоры оказались в стороне от растущего давления NVIDIA на рынке рабочих станций. И в отличие от NVIDIA, 3D Labs не имела никакого присутствия на массовом рынке; если NVIDIA выиграла, они умерли.
Что они и сделали.
Таким образом, в стремлении сохранить свою актуальность в мире, где не нужны их продукты, 3D Labs приняли участие в конференции разработчиков игр, на которой были представлены презентации под названием «OpenGL 2.0». Это будет полное переписывание OpenGL API с нуля. И это имеет смысл; в то время в API OpenGL было много разногласий (обратите внимание: этот развод все еще существует). Просто посмотрите, как работают загрузка и привязка текстур; это полу-тайное.
Частью их предложения был язык затенения. Естественно. Однако, в отличие от текущих кроссплатформенных расширений ARB, их язык шейдинга был «высокоуровневым» (C - высокоуровневый язык шейдинга. Да, действительно).
Теперь Microsoft работала над собственным языком высокоуровневого шейдинга. Что они, во всем коллективном воображении Microsoft, назвали ... Язык высокого уровня затенения (HLSL). Но у них был принципиально другой подход к языкам.
Самая большая проблема с шейдерным языком 3D Labs заключалась в том, что он был встроенным. Видите ли, HLSL был языком, определенным Microsoft. Они выпустили для него компилятор, и он сгенерировал ассемблерный код Shader Model 2.0 (или более поздних моделей шейдеров), который вы будете передавать в D3D. В дни D3D v9 HLSL никогда не касался D3D напрямую. Это была хорошая абстракция, но это было не обязательно. И у разработчика всегда была возможность пойти за компилятором и настроить вывод для максимальной производительности.
В языке 3D Labs этого не было . Вы дали драйверу C-подобный язык, и он создал шейдер. Конец истории. Не сборочный шейдер, не то, что вы кормите чем-то другим. Фактический объект OpenGL, представляющий шейдер.
Это означало, что пользователи OpenGL были открыты для капризов разработчиков, которые только начинали создавать компиляционные языки. Компилятор ошибок побежал безудержной в недавно окрестил OpenGL Shading Language (GLSL). Что еще хуже, если вам удалось заставить шейдер правильно компилироваться на нескольких платформах (не значит, подвиг), вы все равно были подвержены оптимизаторам дня. Которые были не так оптимальны, как могли бы быть.
Хотя это был самый большой недостаток в GLSL, это был не единственный недостаток. По далеко .
В D3D и в более старых языках ассемблера в OpenGL вы могли смешивать и сочетать вершинные и фрагментные (пиксельные) шейдеры. Пока они взаимодействуют с одним и тем же интерфейсом, вы можете использовать любой вершинный шейдер с любым совместимым фрагментным шейдером. И были даже уровни несовместимости, которые они могли принять; вершинный шейдер может записать вывод, который фрагментный шейдер не прочитал. И так далее.
У GLSL ничего этого не было. Вершинные и фрагментные шейдеры были объединены в то, что в 3D Labs называли «программным объектом». Поэтому, если вы хотите поделиться вершинными и фрагментными программами, вам нужно создать несколько программных объектов. И это вызвало вторую по величине проблему.
Видите, 3D Labs думали, что они умны. Они основали модель компиляции GLSL на C / C ++. Вы берете .c или .cpp и компилируете его в объектный файл. Затем вы берете один или несколько объектных файлов и связываете их в программу. Вот как GLSL компилирует: вы компилируете свой шейдер (вершину или фрагмент) в объект шейдера. Затем вы помещаете эти шейдерные объекты в программный объект и связываете их вместе, чтобы сформировать реальную программу.
Несмотря на то, что это позволяло создавать потенциальные интересные идеи, такие как наличие «библиотечных» шейдеров, содержащих дополнительный код, который могут вызывать основные шейдеры, на практике это означало, что шейдеры компилировались дважды . Один раз на этапе компиляции и один раз на этапе компоновки. Компилятор NVIDIA, в частности, был известен тем, что в основном запускал компиляцию дважды. Он не генерировал какой-то посредник объектного кода; он просто скомпилировал его один раз и выбросил ответ, затем снова скомпилировал его во время соединения.
Поэтому, даже если вы хотите связать свой вершинный шейдер с двумя различными фрагментными шейдерами, вам придется выполнять намного больше компиляции, чем в D3D. Тем более, что компиляция C-подобного языка была сделана в автономном режиме , а не в начале выполнения программы.
Были другие проблемы с GLSL. Возможно, кажется неправильным возлагать вину на 3D Labs, так как ARB в конечном итоге одобрил и включил язык (но не более того, в свою инициативу "OpenGL 2.0"). Но это была их идея.
И вот действительно печальная часть: 3D Labs были правы (в основном). GLSL не является векторным языком затенения, каким был HLSL в то время. Это было связано с тем, что оборудование 3D Labs было скалярным (аналогично современному оборудованию NVIDIA), но в конечном итоге они были правы в том направлении, в котором многие производители оборудования использовали свое оборудование.
Они были правы использовать модель компиляции онлайн для языка «высокого уровня». D3D даже переключился на это в конце концов.
Проблема заключалась в том, что 3D-лаборатории оказались не в то время . И, пытаясь вызвать будущее слишком рано, пытаясь быть уверенным в будущем, они отбрасывают настоящее . Это похоже на то, как в OpenGL всегда была возможность использовать T & L. За исключением того, что конвейер T & L OpenGL был еще полезен до аппаратного T & L, в то время как GLSL был пассивом, прежде чем мир его догнал.
GLSL хороший язык в настоящее время . Но на время? Это было ужасно. И OpenGL пострадал за это.
Падение к апофеозу
Хотя я утверждаю, что 3D Labs нанесли смертельный удар, именно ARB вбил последний гвоздь в гроб.
Это история, о которой вы, возможно, слышали. Ко времени OpenGL 2.1 в OpenGL возникла проблема. У него было много устаревших вещей. API больше не был прост в использовании. Было 5 способов сделать что-то, и никто не знал, что было самым быстрым. Вы могли «изучить» OpenGL с помощью простых учебных пособий, но вы на самом деле не изучали API OpenGL, который дал бы вам реальную производительность и графическую мощь.
Поэтому ARB решила предпринять еще одно изобретение OpenGL. Это было похоже на «OpenGL 2.0» в 3D Labs, но лучше, потому что за ним стояла ARB. Они называли это «Пик Лонгс».
Что плохого в том, чтобы потратить некоторое время на улучшение API? Это было плохо, потому что Microsoft оставила себя уязвимой. Видите, это было во время переключения Vista.
В Vista Microsoft решила внести некоторые необходимые изменения в драйверы дисплея. Они заставляли драйверы подчиняться ОС для виртуализации графической памяти и многого другого.
Хотя можно спорить о достоинствах этого или о том, возможно ли это на самом деле, факт остается фактом: Microsoft считала D3D 10 только Vista (и выше). Даже если у вас было оборудование, поддерживающее D3D 10, вы не могли запускать приложения D3D 10, не имея также Vista.
Возможно, вы также помните эту Vista ... ну, скажем так, она не сработала. Таким образом, у вас была недостаточно эффективная ОС, новый API, который работал только на этой ОС, и новое поколение оборудования, которое нуждалось в том, чтобы этот API и ОС выполняли что-то большее, чем было бы быстрее, чем предыдущее поколение.
Тем не менее, разработчики могут получить доступ к функциям класса D3D 10 через OpenGL. Ну, они могли бы, если бы АРБ не был занят работой над Лонгс-Пиком.
По сути, ARB потратил полтора-два года на то, чтобы улучшить API. К тому моменту, когда OpenGL 3.0 фактически вышел, переход на Vista уже начался, Win7 уже не за горами, чтобы поставить Vista позади себя, и большинство разработчиков игр все равно не заботились о возможностях класса D3D-10. В конце концов, аппаратное обеспечение D3D 10 прекрасно работало с приложениями D3D 9. И с ростом количества портов ПК-консоль (или разработчиков ПК, которые стремятся к разработке консолей. Сделайте свой выбор), разработчикам не понадобились функции класса D3D 10.
Теперь, если разработчики имели доступ к этим функциям ранее через OpenGL на машинах WinXP, тогда разработка OpenGL могла бы получить столь необходимый шанс. Но АРБ упустил свою возможность. И ты хочешь знать худшую часть?
Несмотря на то, что они потратили два драгоценных года, пытаясь восстановить API с нуля ... они все же потерпели неудачу и просто вернулись к статус-кво (за исключением механизма устаревания).
Таким образом, АРБ не только упустили важный момент , но и не выполнили задачу, которая заставила их упустить этот шанс. В значительной степени эпический провал вокруг.
И это история OpenGL против Direct3D. Сказка о упущенных возможностях, грубой глупости, преднамеренной слепоте и простой глупости.