Перед тем как мы начнём, скажу: я знаю об OpenGL гораздо больше чем о Direct3D. Я в жизни не написал ни одной строки кода для D3D, и я писал руководства по OpenGL. Так что то что я тут расскажу, не вопрос предвзятости. Теперь это просто история.
Однажды, в начале 90-х, Microsoft огляделась вокруг. Они увидели замечательные Super Nintendo и Sega Genesis, на которых было много отличных игр. И они увидели DOS. Разработчики писали для DOS так же как для консолей: прямо на железе. Но, в отличии от консолей, где разработчик точно знал каким железом располагает пользователь, разработчики для DOS вынуждены были писать в расчёте на множество различных конфигураций оборудования. А это гораздо сложнее, чем кажется на первый взгляд.
У Microsoft в то время была ещё большая проблема: Windows. Windows хотела единолично распоряжаться оборудованием, в отличие от DOS, позволявшей разработчику делать всё что ему заблагорассудится. Владение оборудованием было обязательно для того чтобы упорядочить взаимодействие между приложениями. Взаимодействие-то и не нравилось разработчикам игр, потому что забирало ценные ресурсы, которые они могли использовать для своих замечательных игр.
Чтобы привлечь разработчиков игр в Windows, Microsoft нужен был единый API который был бы низкоуровневым, работал в Windows и при этом не страдал от тормозов и, самое главное, абстрагировал бы от разработчика оборудование. Единый API для графики, звука и пользовательского ввода.
И так родился DirectX.
3D ускорители появились на свет несколько месяцев спустя. И перед Microsoft встало сразу несколько проблем. Видите ли, DirectDraw, графический компонент DirectX, работал только с 2D графикой: выделением графической памяти и побитовым копированием между разными выделенными секциями памяти.
И Microsoft купили некий промежуточный драйвер и сделали из него Direct3D версии 3. Его ругали все и повсюду. И не просто так; одного взгляда на код было достаточно чтобы отшатнуться в ужасе.
Старый Джон Кармак из Id Software взглянул на этот мусор, сказал: «К чёрту!», и решил писать под другой API — OpenGL.
Другая часть этого клубка проблем состояла в том что Microsoft были очень заняты совместной работой с SGI над реализацией OpenGL для Windows. Идея была проста — привлечь разработчиков типичных рабочих GL-приложений: систем автоматического проектирования, моделирования, всего такого. Игры были последним, о чём тогда думали в Microsoft. Это всё предназначалось для Windows NT, но Microsoft решили добавить эту реализацию и в Win95.
Чтобы привлечь внимание разработчиков профессионального софта к Windows, Microsoft попробовали подкупить их доступом к новым функциям ускорителей трехмерной графики. Microsoft сделали протокол Installable Client Driver: производитель графического ускорителя мог перегрузить программную реализацию OpenGL аппаратной. Код просто автоматически использовал аппаратную реализацию если она была доступна.
Итак, расклад сил был определён: Direct3D против OpenGL. Это действительно интересная история, учитывая насколько ужасен был D3D v3.
Комитет Архитектурных Решений OpenGL («Architectural Review Board», ARB) был организацией, ответственной за поддержку стандарта OpenGL. Они выпустили много расширений, следили за репозиторием расширений и создавали новые версии API. В Комитет входили многие влиятельные игроки графической индустрии и разработчики ОС. Apple и Microsoft в своё время тоже входили в этот комитет.
Потом появился 3Dfx с Voodoo2. Это было первое устройство, способное выполнять мультитекстурирование, чего OpenGL делать раньше не мог. Хотя 3Dfx совершенно не вписывался в стандарт OpenGL, NVIDIA, разработчик последующих графических чипов с мультитекстурированием (TNT1), положили глаз на эту реализацию. ARB пришлось выпустить расширение: GL_ARB_multitexture, которое давало доступ к мультитекстурированию.
В это же время вышел Direct3D v5. Теперь D3D стал настоящим API, а не странным куском кошачьей рвоты. Проблема? Отсутствие мультитекстурирования.
Упс.
По большому счёту, это было не так важно как должно было быть, потому что люди особо не использовали мультитекстурирование. По крайней мере напрямую. Мультитекстурирование сильно ухудшало быстродействие, и во многих случаях просто не было смысла использовать его вместо multi-passing. И, естественно, разработчики игр старались убедиться что их игры заработают на старом железе, в котором мультитекстурирования не было, и многие игры его просто не использовали.
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 аппаратный T&L появился только к седьмой версии.
Потом вышел GeForce 3 и одновременно произошло много вещей.
Microsoft решили что теперь-то они уж точно не опоздают к празднику. И вместо того чтобы смотреть что делают NVIDIA и копировать это постфактум они пришли к NVIDIA и поговорили. Потом они полюбили друг друга и от этого союза появилась маленькая игровая приставка.
Потом был болезненный развод. Но это совсем другая история.
Для PC это значило что GeForce 3 вышел одновременно с D3D v8. И несложно увидеть насколько GeForce 3 повлиял на шейдеры в восьмерке. Пиксельные шейдеры в Shader Model 1 были очень сильно привязаны к железу 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. Проприетартных расширений, подходящих только для NVIDIA. Естественно, когда вышел 8500, он не мог использовать ни одно из них.
Видите ли, в D3D v8 вы по крайней мере можете запустить шейдеры SM 1.0 на железе ATI. Естественно, чтобы использовать вкусности 8500 Вам придётся написать новые шейдеры, но Ваш код по крайней мере работал.
Чтобы получить хоть какие то шейдеры на 8500 в OpenGL, ATI пришлось написать несколько расширений OpenGL. Проприетартных расширений, подходящих только для ATI. Итак, Вам приходилось писать два пути выполнения кода, для NVIDIA и для ATI, чтобы иметь хоть какие то шейдеры.
Сейчас Вы наверняка спросите: «А чем занимался OpenGL ARB, чьей работой было поддержание OpenGL в актуальном состоянии?». Да тем же, чем занимаются большинство комитетов: тупил.
Видите ли, выше я упомянул ARB_multitexture потому что это тоже часть этой истории. С точки зрения внешнего наблюдателя ARB пытался вообще избежать добавления шейдеров. Они посчитали что если создать достаточно конфигурируемый конвеер с фиксированными фунцкиями он сможет сравняться по возможностям с шейдерными конвеерами.
И 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. Но когда ARB решил официально предоставить подобный функционал?
Два года спустя. Это случилось после того как они одобрили вертексные и фрагментные шейдеры (пиксели в языке D3D). Вот сколько времени заняла у ARB разработка кроссплатформенного решения для хранения данных в памяти GPU. Именно то, что нужно чтобы выжать максимум из аппаратного T&L.
Итак, разработка OpenGL была раздроблена. Нет единых шейдеров, нет единого хранилища в GPU, когда пользователи D3D уже наслаждались и тем, и другим. Могло ли стать ещё хуже?
Ну… можно сказать и так. Встречайте: 3D Labs.
Кто они такие, спросите Вы? Это разорившаяся компания которую я считаю настоящими убийцами OpenGL. Естественно, общая вялось ARB сделала OpenGL уязвимым, когда он должен был бить D3D на всех фронтах. Но 3D Labs это возможно самая большая причина текущего рыночного положения OpenGL. Что они могли сделать такого?
Они разработали Язык Шейдеров OpenGL.
Дело в том что 3D Labs была умирающей компанией. Их дорогие ускорители стали ненужными когда NVIDIA усилили давление на рынок рабочих компьютеров. И, в отличие от NVIDIA, у них не было никакого присутствия на общем рынке; если бы NVIDIA победила, они бы исчезли.
Так и получилось.
И, в попытке остаться на плаву в мире, которому не нужна была их продукция, 3D Labs появились на Game Developer Conference с презентацией того что они назвали «OpenGL 2.0». Это должно было стать полностью переписанным с нуля API OpenGL. И это имело смысл; в API OpenGL было немало шероховатостей (примечание: они есть и сейчас). Просто посмотрите на что похожа загрузка и привязка текстур; это просто какая то чёрная магия.
Частью их предложения был язык шейдеров. Вот так. Однако, в отличие от текущих кросс-платформенных расширений ARB, их язык шейдеров был «высокоуровневым» (C это высокоуровневый язык для шейдеров. Нет, правда).
Итак, Microsoft в это время работали над своим собственным высокоуровневым языком шейдеров. Назвали они его, по своей давней привычке, «Высокоуровневым Языком Шейдеров» (HLSL). Но подход к языку был в корне другим.
Самая большая проблема языка шейдеров от 3D Labs была в том что он был встроенным. Видите ли, HLSL был языком, определённым Microsoft. Они выпустили для него компилятор, который генерировал ассемблерный код для Shader Model 2.0 (и последующих версий), который Вы вставляли в D3D. В дни D3D v9, HLSL никогда не вызывался из D3D напрямую. Он был удобной абстракцией, но совершенно необязательной. У разработчика всегда оставалась возможность отложить компилятор и доработать код до максимальной производительности.
В языке 3D Labs ничего этого не было. Вы скармливали драйверу код на C-подобном языке, и он возвращал шейдер. Всё, конец истории. И не ассемблерный шейдер, не то что можно вставить куда нибудь. Настоящий объект OpenGL, представляющий шейдер.
Это означало что пользователи OpenGL были беззащитны перед ошибками разработчиков, которые только начали разбираться с компилируемыми ассемблеро-подобными языками. Баги компилятора в новом языке шейдеров OpenGL (GLSL) ходили просто табунами. Что еще хуже, если Вам удавалось правильно скомпилировать шейдер для нескольких платформ (само по себе непростая задача), Вам всё равно приходилось иметь дело с оптимизаторами того времени. Которые были не так оптимальны, как могли бы.
Хотя это было главной проблемой GLSL, но не единственной. Далеко не единственной.
В D3D, как и старых ассемблерных языках OpenGL, можно было смешивать вертексные и фрагментные (пиксельные) шейдеры. Пока они использовали единый интерфейс, можно было использовать любой вертексный шейдер с любым совместимым фрагментным шейдером. Кроме того были уровни несовместимости, которые в принципе можно было терпеть; вертексный шейдер мог выдавать данные, которые фрагментный шейдер просто не читал. И так далее.
В GLSL ничего такого не было. Вертексные и фрагментные шейдеры были собраны в единую абстракцию, которую 3D Labs назвали «программный объект». И если Вам хотелось использовать вместе вертексные и фрагментные программы, Вам приходилось строить несколько таких программных объектов. И это было причиной второй проблемы.
Видите ли, 3D Labs думали что поступают очень умно. Они основали модель компиляции в GLSL на C/C++. Вы берёте .c или .cpp и компилируете в объектный файл. Потом Вы берете один или несколько объектных файлов и линкуете их в программу. Вот так и происходит компиляция в GLSL: вы компилируете шейдер (вертексный или фрагментный) в объект шейдера. Потом Вы помещаете этот объект шейдера в программный объект и связываете их вместе чтобы получить программу.
Хотя это позвляло делать некоторые потенциально крутые вещи вроде «библиотек» шейдеров, содержащих дополнительный код, который совместно использовали основные шейдеры, на практике это означало что шейдеры компилировались дважды. Один раз на этапе компиляции, один раз на этапе линковки. Не создавалось никакого промежуточного объектного кода; шейдер просто компилировался, результат компиляции выбрасывался и компиляция повторялась во время линковки.
Так что если Вы хотели связать Ваш вертексный шейдер с двумя разными фрагментными шейдерами, Вам приходилось компилировать куда больше кода, чем в D3D. Тем более что вся компиляция C-подобных языков происходила при разработке, а не при запуске программы.
У GLSL были и другие проблемы. Возможно неправильно винить во всём 3D Labs, потому что ARB в конце концов одобрила и приняла этот язык (но ничего кроме него из их предложения «OpenGL 2.0» не прошло). Но идея была именно их.
А вот действительно печальная часть. 3D Labs по большому счёту были правы. GLSL это не векторный язык шейдеров, каким всегда был HLSL. Так случилось потому что железо 3D Labs было скалярным железом (так же как современные карты NVIDIA), но в целом они были правы по части направления развития ускорителей.
Они также были правы с «compile-online» моделью для «высокоуровневых» языков. D3D впоследствии тоже на неё перешёл.
Проблема была в том что 3D Labs оказались правы в неправильное время. И в попытке призвать будущее слишком рано, в попытке его предугадать, они отбросили настоящее. Это также как OpenGL всегда имел возможность делать T&L. Если не считать того что конвееры T&L в OpenGL были полезны ещё до выхода аппаратной реализации, а GLSL был просто обузой прежде чем мир оказался готов его принять.
Сейчас GLSL — хороший язык. Но для своего времени он был ужасен. И OpenGL пострадал за это.
Хотя я и утверждаю что 3D Labs нанесли смертельный удар, именно комитет ARB забил последний гвоздь в крышку гроба OpenGL.
Эту историю вы наверняка слышали. Во времена OpenGL 2.1, OpenGL встал перед проблемой. У него было много старых неровностей. API было сложно использовать. Для каждого действия существовало по пять способов и никто не знал, какой окажется самым быстрым. Можно было «изучить» OpenGL по простым руководствам, но никто не говорил Вам какое API даст Вам максимум производительности.
И ARB решил сделать ещё одну попытку изобрести OpenGL заново. Это было похоже на «OpenGL 2.0» от 3D Labs, но лучше, потому что за ней стоял ARB. Попытку назвали «Longs Peak».
Что было не так с попыткой исправить старые API? Плохо было то что Microsoft в то время были уязвимы. Это было время выхода Vista.
В Vista Microsoft решили ввести давно необходимые изменения в драйверах дисплея. Они заставили драйверы обращаться к ОС для виртуализации видеопамяти и многих других вещей.
Хотя можно сомневаться в том было ли это необходимо, но факт остаётся фактом: Microsoft решили что D3D 10 будет только для Vista (и последующих ОС). Даже если у Вас было железо, способное выполнять функции D3D 10, Вы не могли запускать D3D 10 приложения без запуска Vista.
Вы также наверное помните, что Vista… ну, скажем просто что она получилась не очень. Итак, у Вас была тормозная ОС, новое API, работающее только на этой ОС, и новое поколение ускорителей которым было нужно API и ОС чтобы превзойти предыдущее поколение ускорителей.
Однако, разработчики могли бы получить доступ к фунциям уровня D3D 10 через OpenGL. Ну, смогли бы, если бы ARB не были так заняты работой над Longs Peak.
По большому счёту, ARB потратил полтора-два года на то чтобы сделать API лучше. Когда вышел OpenGL 3.0, время Vista уже заканчивалось, на горизонте появилась Win7, и большинство разработчиков уже не интересовались фунцкиями D3D-10. В конце концов, железо для которого предназначался D3D 10 замечательно работало с D3D 9. А с расцветом портов с PC на приставки (или PC-разработчиков, занявшихся разработкой для приставок) функции класса D3D 10 оказались невостребованы.
Если бы у разработчиков был доступ к этим функциям раньше, через OpenGL на машинах с WinXP, разработка OpenGL получила бы так необходимый импульс. Но ARB упустил эту возможность. И знаете что самое плохое?
Несмотря на то что два ценных года были потрачены на разработку API с нуля… они всё равно провалились и вынуждены были вернуться к предыдущей версии.
То есть, ARB не только упустили замечательную возможность, но и не сделали ту задачу, ради которой возможность была упущена. Просто полный провал.
Это и есть история борьбы OpenGL и Direct3D. История упущенных возможностей, огромной глупости, слепоты и просто безрассудства.
Зарождение конфликта
Однажды, в начале 90-х, Microsoft огляделась вокруг. Они увидели замечательные Super Nintendo и Sega Genesis, на которых было много отличных игр. И они увидели DOS. Разработчики писали для DOS так же как для консолей: прямо на железе. Но, в отличии от консолей, где разработчик точно знал каким железом располагает пользователь, разработчики для DOS вынуждены были писать в расчёте на множество различных конфигураций оборудования. А это гораздо сложнее, чем кажется на первый взгляд.
У Microsoft в то время была ещё большая проблема: Windows. Windows хотела единолично распоряжаться оборудованием, в отличие от DOS, позволявшей разработчику делать всё что ему заблагорассудится. Владение оборудованием было обязательно для того чтобы упорядочить взаимодействие между приложениями. Взаимодействие-то и не нравилось разработчикам игр, потому что забирало ценные ресурсы, которые они могли использовать для своих замечательных игр.
Чтобы привлечь разработчиков игр в Windows, Microsoft нужен был единый API который был бы низкоуровневым, работал в Windows и при этом не страдал от тормозов и, самое главное, абстрагировал бы от разработчика оборудование. Единый API для графики, звука и пользовательского ввода.
И так родился DirectX.
3D ускорители появились на свет несколько месяцев спустя. И перед Microsoft встало сразу несколько проблем. Видите ли, DirectDraw, графический компонент DirectX, работал только с 2D графикой: выделением графической памяти и побитовым копированием между разными выделенными секциями памяти.
И Microsoft купили некий промежуточный драйвер и сделали из него Direct3D версии 3. Его ругали все и повсюду. И не просто так; одного взгляда на код было достаточно чтобы отшатнуться в ужасе.
Старый Джон Кармак из Id Software взглянул на этот мусор, сказал: «К чёрту!», и решил писать под другой API — OpenGL.
Другая часть этого клубка проблем состояла в том что Microsoft были очень заняты совместной работой с SGI над реализацией OpenGL для Windows. Идея была проста — привлечь разработчиков типичных рабочих GL-приложений: систем автоматического проектирования, моделирования, всего такого. Игры были последним, о чём тогда думали в Microsoft. Это всё предназначалось для Windows NT, но Microsoft решили добавить эту реализацию и в Win95.
Чтобы привлечь внимание разработчиков профессионального софта к Windows, Microsoft попробовали подкупить их доступом к новым функциям ускорителей трехмерной графики. Microsoft сделали протокол Installable Client Driver: производитель графического ускорителя мог перегрузить программную реализацию OpenGL аппаратной. Код просто автоматически использовал аппаратную реализацию если она была доступна.
Восход OpenGL
Итак, расклад сил был определён: Direct3D против OpenGL. Это действительно интересная история, учитывая насколько ужасен был D3D v3.
Комитет Архитектурных Решений OpenGL («Architectural Review Board», ARB) был организацией, ответственной за поддержку стандарта OpenGL. Они выпустили много расширений, следили за репозиторием расширений и создавали новые версии API. В Комитет входили многие влиятельные игроки графической индустрии и разработчики ОС. Apple и Microsoft в своё время тоже входили в этот комитет.
Потом появился 3Dfx с Voodoo2. Это было первое устройство, способное выполнять мультитекстурирование, чего OpenGL делать раньше не мог. Хотя 3Dfx совершенно не вписывался в стандарт OpenGL, NVIDIA, разработчик последующих графических чипов с мультитекстурированием (TNT1), положили глаз на эту реализацию. ARB пришлось выпустить расширение: GL_ARB_multitexture, которое давало доступ к мультитекстурированию.
В это же время вышел Direct3D v5. Теперь D3D стал настоящим API, а не странным куском кошачьей рвоты. Проблема? Отсутствие мультитекстурирования.
Упс.
По большому счёту, это было не так важно как должно было быть, потому что люди особо не использовали мультитекстурирование. По крайней мере напрямую. Мультитекстурирование сильно ухудшало быстродействие, и во многих случаях просто не было смысла использовать его вместо multi-passing. И, естественно, разработчики игр старались убедиться что их игры заработают на старом железе, в котором мультитекстурирования не было, и многие игры его просто не использовали.
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 аппаратный T&L появился только к седьмой версии.
Рассвет шейдеров, сумерки OpenGL
Потом вышел GeForce 3 и одновременно произошло много вещей.
Microsoft решили что теперь-то они уж точно не опоздают к празднику. И вместо того чтобы смотреть что делают NVIDIA и копировать это постфактум они пришли к NVIDIA и поговорили. Потом они полюбили друг друга и от этого союза появилась маленькая игровая приставка.
Потом был болезненный развод. Но это совсем другая история.
Для PC это значило что GeForce 3 вышел одновременно с D3D v8. И несложно увидеть насколько GeForce 3 повлиял на шейдеры в восьмерке. Пиксельные шейдеры в Shader Model 1 были очень сильно привязаны к железу 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. Проприетартных расширений, подходящих только для NVIDIA. Естественно, когда вышел 8500, он не мог использовать ни одно из них.
Видите ли, в D3D v8 вы по крайней мере можете запустить шейдеры SM 1.0 на железе ATI. Естественно, чтобы использовать вкусности 8500 Вам придётся написать новые шейдеры, но Ваш код по крайней мере работал.
Чтобы получить хоть какие то шейдеры на 8500 в OpenGL, ATI пришлось написать несколько расширений OpenGL. Проприетартных расширений, подходящих только для ATI. Итак, Вам приходилось писать два пути выполнения кода, для NVIDIA и для ATI, чтобы иметь хоть какие то шейдеры.
Сейчас Вы наверняка спросите: «А чем занимался OpenGL ARB, чьей работой было поддержание OpenGL в актуальном состоянии?». Да тем же, чем занимаются большинство комитетов: тупил.
Видите ли, выше я упомянул ARB_multitexture потому что это тоже часть этой истории. С точки зрения внешнего наблюдателя ARB пытался вообще избежать добавления шейдеров. Они посчитали что если создать достаточно конфигурируемый конвеер с фиксированными фунцкиями он сможет сравняться по возможностям с шейдерными конвеерами.
И 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. Но когда ARB решил официально предоставить подобный функционал?
Два года спустя. Это случилось после того как они одобрили вертексные и фрагментные шейдеры (пиксели в языке D3D). Вот сколько времени заняла у ARB разработка кроссплатформенного решения для хранения данных в памяти GPU. Именно то, что нужно чтобы выжать максимум из аппаратного T&L.
Один язык чтобы всё разрушить
Итак, разработка OpenGL была раздроблена. Нет единых шейдеров, нет единого хранилища в GPU, когда пользователи D3D уже наслаждались и тем, и другим. Могло ли стать ещё хуже?
Ну… можно сказать и так. Встречайте: 3D Labs.
Кто они такие, спросите Вы? Это разорившаяся компания которую я считаю настоящими убийцами OpenGL. Естественно, общая вялось ARB сделала OpenGL уязвимым, когда он должен был бить D3D на всех фронтах. Но 3D Labs это возможно самая большая причина текущего рыночного положения OpenGL. Что они могли сделать такого?
Они разработали Язык Шейдеров OpenGL.
Дело в том что 3D Labs была умирающей компанией. Их дорогие ускорители стали ненужными когда NVIDIA усилили давление на рынок рабочих компьютеров. И, в отличие от NVIDIA, у них не было никакого присутствия на общем рынке; если бы NVIDIA победила, они бы исчезли.
Так и получилось.
И, в попытке остаться на плаву в мире, которому не нужна была их продукция, 3D Labs появились на Game Developer Conference с презентацией того что они назвали «OpenGL 2.0». Это должно было стать полностью переписанным с нуля API OpenGL. И это имело смысл; в API OpenGL было немало шероховатостей (примечание: они есть и сейчас). Просто посмотрите на что похожа загрузка и привязка текстур; это просто какая то чёрная магия.
Частью их предложения был язык шейдеров. Вот так. Однако, в отличие от текущих кросс-платформенных расширений ARB, их язык шейдеров был «высокоуровневым» (C это высокоуровневый язык для шейдеров. Нет, правда).
Итак, Microsoft в это время работали над своим собственным высокоуровневым языком шейдеров. Назвали они его, по своей давней привычке, «Высокоуровневым Языком Шейдеров» (HLSL). Но подход к языку был в корне другим.
Самая большая проблема языка шейдеров от 3D Labs была в том что он был встроенным. Видите ли, HLSL был языком, определённым Microsoft. Они выпустили для него компилятор, который генерировал ассемблерный код для Shader Model 2.0 (и последующих версий), который Вы вставляли в D3D. В дни D3D v9, HLSL никогда не вызывался из D3D напрямую. Он был удобной абстракцией, но совершенно необязательной. У разработчика всегда оставалась возможность отложить компилятор и доработать код до максимальной производительности.
В языке 3D Labs ничего этого не было. Вы скармливали драйверу код на C-подобном языке, и он возвращал шейдер. Всё, конец истории. И не ассемблерный шейдер, не то что можно вставить куда нибудь. Настоящий объект OpenGL, представляющий шейдер.
Это означало что пользователи OpenGL были беззащитны перед ошибками разработчиков, которые только начали разбираться с компилируемыми ассемблеро-подобными языками. Баги компилятора в новом языке шейдеров OpenGL (GLSL) ходили просто табунами. Что еще хуже, если Вам удавалось правильно скомпилировать шейдер для нескольких платформ (само по себе непростая задача), Вам всё равно приходилось иметь дело с оптимизаторами того времени. Которые были не так оптимальны, как могли бы.
Хотя это было главной проблемой GLSL, но не единственной. Далеко не единственной.
В D3D, как и старых ассемблерных языках OpenGL, можно было смешивать вертексные и фрагментные (пиксельные) шейдеры. Пока они использовали единый интерфейс, можно было использовать любой вертексный шейдер с любым совместимым фрагментным шейдером. Кроме того были уровни несовместимости, которые в принципе можно было терпеть; вертексный шейдер мог выдавать данные, которые фрагментный шейдер просто не читал. И так далее.
В GLSL ничего такого не было. Вертексные и фрагментные шейдеры были собраны в единую абстракцию, которую 3D Labs назвали «программный объект». И если Вам хотелось использовать вместе вертексные и фрагментные программы, Вам приходилось строить несколько таких программных объектов. И это было причиной второй проблемы.
Видите ли, 3D Labs думали что поступают очень умно. Они основали модель компиляции в GLSL на C/C++. Вы берёте .c или .cpp и компилируете в объектный файл. Потом Вы берете один или несколько объектных файлов и линкуете их в программу. Вот так и происходит компиляция в GLSL: вы компилируете шейдер (вертексный или фрагментный) в объект шейдера. Потом Вы помещаете этот объект шейдера в программный объект и связываете их вместе чтобы получить программу.
Хотя это позвляло делать некоторые потенциально крутые вещи вроде «библиотек» шейдеров, содержащих дополнительный код, который совместно использовали основные шейдеры, на практике это означало что шейдеры компилировались дважды. Один раз на этапе компиляции, один раз на этапе линковки. Не создавалось никакого промежуточного объектного кода; шейдер просто компилировался, результат компиляции выбрасывался и компиляция повторялась во время линковки.
Так что если Вы хотели связать Ваш вертексный шейдер с двумя разными фрагментными шейдерами, Вам приходилось компилировать куда больше кода, чем в D3D. Тем более что вся компиляция C-подобных языков происходила при разработке, а не при запуске программы.
У GLSL были и другие проблемы. Возможно неправильно винить во всём 3D Labs, потому что ARB в конце концов одобрила и приняла этот язык (но ничего кроме него из их предложения «OpenGL 2.0» не прошло). Но идея была именно их.
А вот действительно печальная часть. 3D Labs по большому счёту были правы. GLSL это не векторный язык шейдеров, каким всегда был HLSL. Так случилось потому что железо 3D Labs было скалярным железом (так же как современные карты NVIDIA), но в целом они были правы по части направления развития ускорителей.
Они также были правы с «compile-online» моделью для «высокоуровневых» языков. D3D впоследствии тоже на неё перешёл.
Проблема была в том что 3D Labs оказались правы в неправильное время. И в попытке призвать будущее слишком рано, в попытке его предугадать, они отбросили настоящее. Это также как OpenGL всегда имел возможность делать T&L. Если не считать того что конвееры T&L в OpenGL были полезны ещё до выхода аппаратной реализации, а GLSL был просто обузой прежде чем мир оказался готов его принять.
Сейчас GLSL — хороший язык. Но для своего времени он был ужасен. И OpenGL пострадал за это.
Приближается апофеоз
Хотя я и утверждаю что 3D Labs нанесли смертельный удар, именно комитет ARB забил последний гвоздь в крышку гроба OpenGL.
Эту историю вы наверняка слышали. Во времена OpenGL 2.1, OpenGL встал перед проблемой. У него было много старых неровностей. API было сложно использовать. Для каждого действия существовало по пять способов и никто не знал, какой окажется самым быстрым. Можно было «изучить» OpenGL по простым руководствам, но никто не говорил Вам какое API даст Вам максимум производительности.
И ARB решил сделать ещё одну попытку изобрести OpenGL заново. Это было похоже на «OpenGL 2.0» от 3D Labs, но лучше, потому что за ней стоял ARB. Попытку назвали «Longs Peak».
Что было не так с попыткой исправить старые API? Плохо было то что Microsoft в то время были уязвимы. Это было время выхода Vista.
В Vista Microsoft решили ввести давно необходимые изменения в драйверах дисплея. Они заставили драйверы обращаться к ОС для виртуализации видеопамяти и многих других вещей.
Хотя можно сомневаться в том было ли это необходимо, но факт остаётся фактом: Microsoft решили что D3D 10 будет только для Vista (и последующих ОС). Даже если у Вас было железо, способное выполнять функции D3D 10, Вы не могли запускать D3D 10 приложения без запуска Vista.
Вы также наверное помните, что Vista… ну, скажем просто что она получилась не очень. Итак, у Вас была тормозная ОС, новое API, работающее только на этой ОС, и новое поколение ускорителей которым было нужно API и ОС чтобы превзойти предыдущее поколение ускорителей.
Однако, разработчики могли бы получить доступ к фунциям уровня D3D 10 через OpenGL. Ну, смогли бы, если бы ARB не были так заняты работой над Longs Peak.
По большому счёту, ARB потратил полтора-два года на то чтобы сделать API лучше. Когда вышел OpenGL 3.0, время Vista уже заканчивалось, на горизонте появилась Win7, и большинство разработчиков уже не интересовались фунцкиями D3D-10. В конце концов, железо для которого предназначался D3D 10 замечательно работало с D3D 9. А с расцветом портов с PC на приставки (или PC-разработчиков, занявшихся разработкой для приставок) функции класса D3D 10 оказались невостребованы.
Если бы у разработчиков был доступ к этим функциям раньше, через OpenGL на машинах с WinXP, разработка OpenGL получила бы так необходимый импульс. Но ARB упустил эту возможность. И знаете что самое плохое?
Несмотря на то что два ценных года были потрачены на разработку API с нуля… они всё равно провалились и вынуждены были вернуться к предыдущей версии.
То есть, ARB не только упустили замечательную возможность, но и не сделали ту задачу, ради которой возможность была упущена. Просто полный провал.
Это и есть история борьбы OpenGL и Direct3D. История упущенных возможностей, огромной глупости, слепоты и просто безрассудства.
