Багато відповідей тут справді, дуже хороші. Але проблеми 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, стосувався лише двовимірної графіки: розподілення графічної пам'яті та виконання бітових проміжків між різними виділеними ділянками пам'яті.
Тож Microsoft придбала трохи проміжного програмного забезпечення та перетворила його на Direct3D версії 3. Це було повсюдно скасовано. І з розумною причиною; дивитися на код D3D v3 - це як заглянути в Ковчег завіту.
Старий Джон Кармак в програмі Id Software один раз подивився на цей смітник і сказав: "Викрутіть це!" і вирішив написати на інший API: OpenGL.
Дивіться, інша частина багатоголового звіра - Microsoft була зайнята роботою з SGI над реалізацією OpenGL для Windows. Ідея полягала в тому, щоб розробити судові розробники типових програм GL: додатків для робочих станцій. Інструменти САПР, моделювання подібних речей. Ігри були найдавнішою річчю на їхньому розумі. В першу чергу це була річ Windows NT, але Microsoft вирішила додати її і до Win95.
Як спосіб залучити розробників робочих станцій до Windows, Microsoft вирішила спробувати підкупити їх доступом до цих новомодних 3D графічних карт. Microsoft впровадила протокол встановленого драйвера клієнта: виробник графічних карт може перекрити впровадження програмного забезпечення Microsoft OpenGL на апаратному. Код може автоматично використовувати апаратну реалізацію OpenGL, якщо така була доступна.
У перші дні відеокарти на рівні споживачів не підтримували OpenGL. Це не зупинило Carmack просто перенести Quake на OpenGL (GLQuake) на його робочу станцію SGI. Як ми можемо прочитати з readme GLQuake:
Теоретично glquake працюватиме на будь-якому сумісному OpenGL, який підтримує розширення текстурних об'єктів, але, якщо це не дуже потужне обладнання, яке прискорює все необхідне, гра не буде прийнятною. Якщо йому доведеться пройти будь-які шляхи емуляції програмного забезпечення, продуктивність, швидше за все, буде значно нижче одного кадру в секунду.
У цей час (березень 97 року) єдине стандартне обладнання для opengl, яке може грати на глюкейк, - це інтергральний реалізм, який ДУЖЕ дорога карта. 3Dlabs значно покращив свою ефективність, але з наявними драйверами це все ще недостатньо добре для гри. Деякі з поточних драйверів 3dlabs для блискучих та перимедійних дощок також можуть збити 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 (ARB) є організацією, відповідальною за підтримку OpenGL. Вони випускають ряд розширень, підтримують сховище розширень та створюють нові версії API. ARB - це комітет, який складається з багатьох гравців графічної індустрії, а також деяких виробників ОС. Apple і Microsoft в різні часи були членами АРБ.
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 1.1, яка в основному була "Що б не зробила 8500".
Це може здатися збоєм з боку D3D. Але невдача та успіх - це питання ступенів. І епічна невдача сталася в OpenGL-land.
NVIDIA полюбила OpenGL, тому коли потрапила GeForce 3, вони випустили низку розширень OpenGL. Власні розширення OpenGL: лише для NVIDIA. Природно, коли 8500 з'явився, він не міг використовувати жоден із них.
Подивіться, щонайменше, на землі D3D 8, ви можете запустити шейдери SM 1.0 на апаратному забезпеченні ATI. Звичайно, вам довелося написати нові шейдери, щоб скористатися прохолодою 8500, але принаймні ваш код спрацював .
Щоб мати шейдери будь-якого типу на Radeon 8500 в OpenGL, ATI довелося записати ряд розширень OpenGL. Власні розширення OpenGL: лише для ATI. Тож вам знадобився кодовий шлях NVIDIA та кодовий шлях ATI, просто щоб мати шейдери взагалі.
Тепер ви можете запитати: "Де була ARGL OpenGL, завданням якої було підтримувати OpenGL поточним?" Там, де часто комітети закінчуються: нерозумно.
Дивіться, я згадував ARB_multitexture вище, тому що він враховує все це. ARB здавалося (з погляду сторонніх людей) хоче взагалі уникнути ідеї шейдерів. Вони подумали, що якщо вони нанесуть достатню конфігурацію на трубопровід з фіксованою функцією, вони можуть дорівнювати здатності трубопроводу шейдера.
Тож ARB випустив розширення після розширення. Кожне розширення зі словами "text_env" у ньому було ще однією спробою закріпити цей старечий дизайн. Перевірте реєстр: між розширеннями ARB та EXT було зроблено вісім таких розширень. Багато хто був просунутий до основних версій OpenGL.
Microsoft в цей час була частиною ARB; вони покинули час удару D3D 9. Тож цілком можливо, що вони якось працювали над саботажем OpenGL. Я особисто сумніваюся в цій теорії з двох причин. По-перше, їм довелося б отримати допомогу інших членів АРБ, щоб зробити це, оскільки кожен член отримує лише один голос. І найголовніше два: ARB не потребувала допомоги 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-лабораторії .
Хто вони, можете запитати? Вони є неіснуючою компанією, яку я вважаю справжніми вбивцями OpenGL. Звичайно, загальна невмілість ARB зробила OpenGL вразливим, коли він мав би володіти D3D. Але 3D-лабораторії - це, мабуть, найбільша причина, на яку я думаю, про поточний ринковий стан OpenGL. Що вони могли зробити, щоб викликати це?
Вони розробили OpenGL Shading Language.
Дивіться, 3D Labs була вмираючою компанією. Їх дорогі GPU були маргіналізовані завдяки зростаючому тиску NVIDIA на ринку робочих станцій. І на відміну від NVIDIA, 3D-лабораторії не мали жодної присутності на основному ринку; якщо виграла NVIDIA, вони померли.
Що вони зробили.
Отже, намагаючись залишатись актуальним у світі, який не хотів їхніх продуктів, 3D-лабораторії показали на конференції розробників ігор, яка проводила презентації на те, що вони називали "OpenGL 2.0". Це було б повноцінним переписанням API OpenGL з нуля. І це має сенс; У API OpenGL в той час було багато суворості (зауважте: ця суть все ще існує). Подивіться, як працює завантаження та зв'язування текстур; це напівсханний.
Частиною їхньої пропозиції була мова затінення. Природно. Однак, на відміну від нинішніх розширень ARB на міжплатформних платформах, мова їх затінення була "високорівневою" (C - високий рівень для мови затінення. Так, справді).
Тепер Microsoft працювала над власною мовою затінення високого рівня. Котрий вони, у всій колективній уяві Майкрософт, назвали ... Мова затінення високого рівня (HLSL). Але їх принципово інший підхід до мов.
Найбільша проблема мови шейдерів 3D Labs полягала в тому, що він вбудований. Дивіться, HLSL була мовою, яку визначає Microsoft. Вони випустили компілятор для цього, і він створив код складання Shader Model 2.0 (або пізніші моделі шейдерів), який ви б ввели в D3D. За D3D v9 днів D3D ніколи не торкався HLSL. Це була приємна абстракція, але вона була суто необов’язковою. І розробник завжди мав можливість піти за компілятор і налаштувати вихід для досягнення максимальної продуктивності.
Мова 3D Labs не мала нічого подібного . Ви дали водієві мову, схожу на С, і це створило шейдер. Кінець історії. Не монтажний шейдер, не те, чим ви годуєте щось інше. Фактичний об'єкт OpenGL, що представляє шейдер.
Це означало, що користувачі OpenGL були відкриті для капризів розробників, які тільки почали збирати мови, схожі на збірки. Помилки компілятора невпинно поширилися на новохрещеному OpenGL Shading Language (GLSL). Що ще гірше, якщо вам вдалося отримати шейдер для компіляції на декількох платформах правильно (не маючи на увазі подвиг), ви все ще зазнали оптимізаторів дня. Які не були настільки оптимальними, як могли бути.
Хоча це був найбільший недолік у GLSL, це був не єдиний недолік. На сьогоднішній день .
У D3D та на старих мовах асемблери в OpenGL ви можете змішувати вершини та фрагменти (пікселі). Поки вони спілкувалися з одним і тим же інтерфейсом, ви могли використовувати будь-який вершинний шейдер з будь-яким сумісним шейдером для фрагментів. І навіть існували рівні несумісності, які вони могли прийняти; вершина шейдера може записати вихід, який фрагмент шейдер не прочитав. І так далі.
У GLSL цього не було. Шейдери вершин та фрагментів були злиті разом у 3D-лабораторії, яка називається "програмним об'єктом". Отже, якщо ви хотіли поділитися вершинами та фрагментами програм, вам довелося побудувати декілька об’єктів програми. І це спричинило другу найбільшу проблему.
Дивіться, 3D-лабораторії думали, що вони розумні. Вони грунтували модель компіляції GLSL на C / C ++. Ви берете .c або .cpp і компілюєте його в об’єктний файл. Потім ви берете один або кілька об’єктних файлів і зв'язуєте їх у програму. Отже, так компілюється GLSL: ви збираєте свій шейдер (вершину чи фрагмент) в об'єкт шейдера. Потім ви розміщуєте ці об'єкти шейдерів в програмному об’єкті і зв'язуєте їх разом для формування вашої фактичної програми.
Хоча це дозволяло потенційним крутим ідеям, таким як мати "бібліотечні" шейдери, які містили додатковий код, який могли б викликати основні шейдери, на практиці це означало, що шейдери складалися двічі . Одного разу на етапі компіляції та одного разу на етапі сполучення. Зокрема, компілятор NVIDIA був відомий тим, що в основному виконував компіляцію двічі. Він не генерував якогось посередника коду об'єкта; він просто скомпілював його один раз і відкинув відповідь, а потім скомпілював її знову під час посилання.
Тож навіть якщо ви хочете пов’язати вершину шейдера з двома різними шейдерами фрагментів, вам доведеться зробити набагато більше компіляції, ніж у D3D. Тим більше, що компіляція мови, схожої на C, робилася в режимі офлайн , а не на початку виконання програми.
З GLSL були й інші проблеми. Можливо, здається неправильним покласти провину на 3D-лабораторії, оскільки ARB врешті-решт схвалила та включила мову (але більше нічого з їхньої ініціативи "OpenGL 2.0"). Але це була їхня ідея.
І ось справді сумна частина: 3D-лабораторії були праві (здебільшого). GLSL не є векторною мовою затінення, заснованої на векторі, як тоді був HLSL. Це пояснювалося тим, що обладнання 3D Labs було скалярним обладнанням (подібним до сучасного обладнання NVIDIA), але в кінцевому рахунку вони мали рацію в тому напрямку, у якому багато виробників обладнання працювали зі своїм обладнанням.
Вони мали рацію перейти з онлайн-моделлю для компіляції для мови "високого рівня". D3D навіть перейшов до цього з часом.
Проблема полягала в тому, що 3D-лабораторії були правильні в неправильний час . І намагаючись викликати майбутнє занадто рано, намагаючись бути впевненими у майбутньому, вони відкидають теперішнє . Це схоже на те, як у OpenGL завжди була можливість функціонування T&L. За винятком того, що трубопровід OpenGL T&L був ще корисним перед апаратними T&L, тоді як GLSL був відповідальним перед тим, як світ його наздогнав.
GLSL - це хороша мова зараз . Але на час? Це було жахливо. І OpenGL постраждав за це.
Падіння до апофеозу
Хоча я стверджую, що 3D-лабораторії завдали фатального удару, саме АРБ загнав останній цвях у труну.
Це історія, яку ви, можливо, чули. До моменту OpenGL 2.1 OpenGL зіткнувся з проблемою. У ній було багато спадщини. API вже не був простим у використанні. Існувало 5 способів зробити речі, і ідея, яка була найшвидшою. Ви можете "вивчити" OpenGL за допомогою простих навчальних посібників, але ви насправді не вивчили API OpenGL, який дав вам справжню продуктивність та графічну потужність.
Таким чином, ARB вирішила спробувати ще один винахід OpenGL. Це було схоже на "OpenGL 2.0" у 3D-лабораторіях, але краще, тому що ARB стояв за ним. Вони називали це "Довгий пік".
Що такого поганого в тому, щоб витратити якийсь час на покращення API? Це було погано, оскільки Microsoft залишила себе вразливими. Дивіться, це було під час переключення Vista.
З Vista, Microsoft вирішила внести деякі необхідні зміни у драйвери дисплея. Вони змусили водіїв подати в ОС для віртуалізації графічної пам’яті та інших інших речей.
Хоча можна обговорювати достоїнства цього чи чи це було насправді можливо, факт залишається фактом: Microsoft вважала D3D 10 лише Vista (і вище). Навіть якщо у вас було обладнання, здатне D3D 10, ви не можете запустити програми D3D 10, не запустивши також Vista.
Ви можете також пам’ятати ту Вісту ... гм, скажімо, що вона не спрацювала добре. Таким чином, у вас була недостатня продуктивність ОС, новий API, який працював лише на цій ОС, і нове покоління обладнання, яке потребувало цього API та ОС, щоб зробити щось більше, ніж швидше попереднього покоління.
Однак розробники могли отримати доступ до функцій 10 класу D3D через OpenGL. Ну, вони могли б, якби ARB не зайнялася роботою над Longs Peak.
По суті, ARB витратив на роботу, щоб покращити API півтора-два роки. На той момент, коли OpenGL 3.0 з'явився фактично, прийняття Vista закінчилося, Win7 був за кутом, щоб поставити Vista за ними, і більшість розробників ігор взагалі не переймалися особливостями класу D3D-10. Зрештою, апаратне забезпечення D3D 10 запустило програми D3D 9 просто чудово. І з підйомом портів на ПК на консоль (або розробники ПК, що переходять на розробку консолей. Виберіть свій вибір), розробникам не потрібні особливості класу D3D 10 класу.
Тепер, якщо розробники мали доступ до цих функцій раніше через OpenGL на машинах WinXP, то розробка OpenGL, можливо, отримала б так потрібний удар у руку. Але ARB упустила свою можливість. А ти хочеш знати найгіршу частину?
Незважаючи на те, що витратили два дорогоцінні роки на спробу відновити API з нуля ... вони все-таки зазнали невдач і просто повернулися до статусу кво (за винятком механізму депресації).
Таким чином, ARB не тільки пропустила важливе вікно можливостей, вони навіть не виконали завдання, яке змусило їх упустити цей шанс. Досить багато епосу провалюється навколо.
І це казка про OpenGL проти Direct3D. Казка про пропущені можливості, про грубу дурість, навмисну сліпоту та просту дурість.