Wiele odpowiedzi tutaj jest naprawdę bardzo dobrych. Ale prawdopodobnie należy rozwiązać problem OpenGL i Direct3D (D3D) . A to wymaga ... lekcji historii.
I zanim zaczniemy, wiem znacznie więcej o OpenGL niż o Direct3D . Nigdy w życiu nie napisałem wiersza kodu D3D i napisałem samouczki na temat OpenGL. Więc to, co zamierzam powiedzieć, nie jest kwestią uprzedzeń. To po prostu kwestia historii.
Narodziny konfliktu
Pewnego dnia, na początku lat 90., Microsoft rozejrzał się. Widzieli, że SNES i Sega Genesis są niesamowici, uruchamiają wiele gier akcji i tym podobne. I widzieli DOS . Programiści kodowali gry DOS, takie jak gry konsolowe: bezpośrednio do metalu. Jednak w przeciwieństwie do konsol, gdzie twórca gry SNES wiedział, jaki sprzęt będzie posiadał użytkownik, programiści DOS musieli pisać dla wielu możliwych konfiguracji. A to jest trudniejsze niż się wydaje.
A Microsoft miał większy problem: Windows. Widzisz, Windows chciał mieć sprzęt, w przeciwieństwie do DOS, który praktycznie pozwala programistom robić wszystko. Posiadanie sprzętu jest niezbędne do współpracy między aplikacjami. Współpraca jest tym, czego nienawidzą twórcy gier, ponieważ pochłania cenne zasoby sprzętowe, których mogliby używać, aby być niesamowitym.
Aby promować tworzenie gier w systemie Windows, Microsoft potrzebował jednolitego interfejsu API, który był niskiego poziomu, działał w systemie Windows bez spowalniania go, a przede wszystkim między sprzętem . Jeden interfejs API dla całej grafiki, dźwięku i sprzętu wejściowego.
Tak narodził się DirectX .
Akceleratory 3D urodziły się kilka miesięcy później. Microsoft napotkał kłopoty. Zobacz, DirectDraw, komponent graficzny DirectX, zajmował się tylko grafiką 2D: alokacją pamięci graficznej i robieniem bitów pomiędzy różnymi przydzielonymi sekcjami pamięci.
Tak więc Microsoft kupił trochę oprogramowania pośredniego i przekształcił go w wersję Direct3D 3. To było powszechnie oczerniane. I nie bez powodu; patrzenie na kod D3D v3 jest jak wpatrywanie się w Arkę Przymierza.
Stary John Carmack z Id Software rzucił okiem na śmieci i powiedział: „Pieprzyć to!” i postanowiłem napisać w kierunku innego API: OpenGL.
Zobacz, inna część bestii z wieloma głowami, jaką jest Microsoft, była zajęta pracą z SGI przy implementacji OpenGL dla Windows. Chodziło tutaj o to, by osądzić twórców typowych aplikacji GL: aplikacji na stacje robocze. Narzędzia CAD, modelowanie, tego typu rzeczy. Gry były najdalszą rzeczą, jaką mieli na myśli. Było to przede wszystkim kwestia systemu Windows NT, ale Microsoft postanowił dodać go również do Win95.
Aby zachęcić deweloperów stacji roboczych do systemu Windows, Microsoft postanowił przekupić ich dostępem do tych nowych kart graficznych 3D. Microsoft wdrożył protokół Installable Client Driver: producent kart graficznych może zastąpić implementację OpenGL oprogramowania Microsoft wersją sprzętową. Kod może automatycznie użyć sprzętowej implementacji OpenGL, jeśli jest dostępna.
Na początku karty wideo na poziomie konsumenckim nie obsługiwały OpenGL. To nie powstrzymało Carmacka przed przeniesieniem Quake'a na OpenGL (GLQuake) na jego stacji roboczej SGI. Jak możemy przeczytać w pliku Readme GLQuake:
Teoretycznie glquake będzie działał na każdym zgodnym OpenGL, który obsługuje rozszerzenia obiektów tekstur, ale jeśli nie jest to bardzo wydajny sprzęt, który przyspiesza wszystko, czego potrzeba, gra nie będzie akceptowana. Jeśli będzie musiał przejść przez dowolną ścieżkę emulacji oprogramowania, wydajność będzie prawdopodobnie znacznie mniejsza niż jedna klatka na sekundę.
W tym czasie (marzec 97) jedynym standardowym sprzętem opengl, który potrafi rozsądnie grać w glake, jest realizacja międzygraph, która jest BARDZO drogą kartą. 3dlabs znacznie poprawił swoją wydajność, ale dzięki dostępnym sterownikom nadal nie jest wystarczająco dobry do gry. Niektóre z obecnych sterowników 3dlabs dla kart glint i permedia mogą również zawieszać system NT podczas wychodzenia z trybu pełnoekranowego, więc nie polecam uruchamiania glquake na sprzęcie 3dlabs.
3dfx dostarczył plik opengl32.dll, który implementuje wszystko, czego potrzebuje glquake, ale nie jest to pełna implementacja opengl. Inne aplikacje OpenGL raczej nie będą z nim współpracować, więc rozważ to w zasadzie „sterownik glquake”.
To narodziny sterowników miniGL. W końcu przekształciły się one w pełne implementacje OpenGL, ponieważ sprzęt stał się wystarczająco silny, aby zaimplementować większość funkcji OpenGL w sprzęcie. nVidia jako pierwsza zaoferowała pełną implementację OpenGL. Wielu innych producentów miało problemy, co jest jednym z powodów, dla których programiści woleli Direct3D: byli kompatybilni na szerszej gamie sprzętu. Ostatecznie pozostały tylko nVidia i ATI (obecnie AMD) i oba miały dobrą implementację OpenGL.
Ascendent OpenGL
Zatem ustawiono scenę: Direct3D vs. OpenGL. To naprawdę niesamowita historia, biorąc pod uwagę, jak zły był D3D v3.
OpenGL Architectural Review Board (ARB) jest organizacją odpowiedzialną za utrzymanie OpenGL. Wydają szereg rozszerzeń, utrzymują repozytorium rozszerzeń i tworzą nowe wersje interfejsu API. ARB to komitet złożony z wielu graczy z branży graficznej, a także niektórych twórców systemów operacyjnych. Apple i Microsoft były w różnym czasie członkiem ARB.
3Dfx wychodzi z Voodoo2. Jest to pierwszy sprzęt, który może wykonywać multiteksturowanie, czego OpenGL nie mógł zrobić wcześniej. Podczas gdy 3Dfx zdecydowanie sprzeciwiał się OpenGL, NVIDIA, twórcy kolejnego wieloukładowego układu graficznego (TNT1), pokochali go. ARB wydało więc rozszerzenie: GL_ARB_multitexture, które pozwoliłoby na dostęp do multiteksturowania.
Tymczasem wychodzi Direct3D v5. Teraz D3D stał się faktycznym API , a nie czymś, co kot może zwymiotować. Problem? Bez multiteksturowania.
Ups
Teraz nie zaszkodziłoby to tak bardzo, jak powinno, ponieważ ludzie nie używali wielu metod multiteksturowania. Nie bezpośrednio. Multiteksturowanie trochę pogorszyło wydajność, aw wielu przypadkach nie było tego warte w porównaniu z wielokrotnym podaniem. I oczywiście twórcy gier lubią zapewniać, że ich gry działają na starszym sprzęcie, który nie miał funkcji multiteksturowania, więc wiele gier jest dostarczanych bez niego.
D3D otrzymało zatem ulgę.
Czas mija, a NVIDIA wdraża GeForce 256 (nie GeForce GT-250; pierwszy GeForce), prawie kończącą się konkurencję na kartach graficznych przez następne dwa lata. Główną zaletą jest możliwość transformacji wierzchołków i oświetlenia (T&L) w sprzęcie. Mało tego, NVIDIA tak bardzo kochała OpenGL, że ich silnik T&L skutecznie był OpenGL. Niemal dosłownie; jak rozumiem, niektóre z ich rejestrów faktycznie przyjmowały enumeratory OpenGL bezpośrednio jako wartości.
Wyjdzie Direct3D v6. Nareszcie multitekstura, ale ... żadnych sprzętowych T&L. OpenGL zawsze miał potok T&L, chociaż przed 256 był zaimplementowany w oprogramowaniu. Dlatego NVIDIA bardzo łatwo przekonwertowała swoją implementację oprogramowania na rozwiązanie sprzętowe. Byłoby to dopiero w wersji D3D v7, dopóki D3D nie będzie w końcu obsługiwać sprzętowej specyfikacji T&L.
Dawn of Shaders, Twilight of OpenGL
Potem pojawiła się GeForce 3. I wiele rzeczy wydarzyło się jednocześnie.
Microsoft zdecydował, że już się nie spóźnią. Zamiast więc patrzeć na to, co robi NVIDIA, a następnie kopiować to po fakcie, zajęli zdumiewające stanowisko, że poszli do nich i rozmawiali z nimi. A potem zakochali się i mieli małą konsolę razem.
Później doszło do niechlujnego rozwodu. Ale to na inny czas.
Dla PC oznaczało to, że GeForce 3 pojawił się jednocześnie z D3D v8. I nietrudno zobaczyć, jak GeForce 3 wpłynął na shadery D3D 8. Shadery pikseli w Shader Model 1.0 były wyjątkowo specyficzne dla sprzętu NVIDIA. Nie podjęto żadnej próby wyodrębnienia sprzętu NVIDIA; SM 1.0 był dokładnie tym, co zrobił GeForce 3.
Gdy ATI zaczęło wskakiwać do wyścigowej karty graficznej z Radeonem 8500, pojawił się problem. Procesor przetwarzania pikseli w 8500 był potężniejszy niż NVIDIA. Microsoft wydał Shader Model 1.1, który w zasadzie brzmiał „Cokolwiek robi 8500”.
To może brzmieć jak awaria ze strony D3D. Ale porażka i sukces są kwestiami stopni. A epicka porażka miała miejsce w krainie OpenGL.
NVIDIA uwielbiała OpenGL, więc kiedy trafiła GeForce 3, wydała mnóstwo rozszerzeń OpenGL. Zastrzeżone rozszerzenia OpenGL: tylko NVIDIA. Oczywiście, kiedy pojawił się 8500, nie mógł użyć żadnego z nich.
Zobacz, przynajmniej na ziemi D3D 8, możesz uruchomić swoje shadery SM 1.0 na sprzęcie ATI. Oczywiście, musiałeś napisać nowe shadery, aby skorzystać z chłodu 8500, ale przynajmniej twój kod działał .
Aby mieć jakiekolwiek shadery na Radeon 8500 w OpenGL, ATI musiało napisać wiele rozszerzeń OpenGL. Zastrzeżone rozszerzenia OpenGL: tylko ATI. Potrzebna była więc ścieżka kodowa NVIDIA i ścieżka kodowa ATI, żeby w ogóle mieć shadery .
Teraz możesz zapytać: „Gdzie był OpenGL ARB, którego zadaniem było utrzymywanie aktualności OpenGL?” Tam, gdzie często kończy się wiele komitetów: głupota.
Widzicie, wspominałem o ARB_multitexture powyżej, ponieważ ma to głęboki wpływ na to wszystko. ARB wydawało się (z zewnątrz), że chce całkowicie uniknąć pomysłu shaderów. Doszli do wniosku, że jeśli narzucą wystarczającą konfigurowalność na potok o stałej funkcji, mogą równać się możliwości potoku cieniującego.
Tak więc ARB wydało rozszerzenie po rozszerzeniu. Każde rozszerzenie ze słowami „texture_env” było kolejną próbą załatania tego starzejącego się projektu. Sprawdź rejestr: między rozszerzeniami ARB i EXT wykonano osiem takich rozszerzeń. Wiele z nich awansowało do podstawowych wersji OpenGL.
Microsoft był w tym czasie częścią ARB; opuścili go w chwili uderzenia D3D 9. Jest więc całkiem możliwe, że pracowali w jakiś sposób nad sabotażem OpenGL. Osobiście wątpię w tę teorię z dwóch powodów. Po pierwsze, musieliby uzyskać pomoc od innych członków ARB, ponieważ każdy członek otrzymuje tylko jeden głos. A co najważniejsze dwa, ARB nie potrzebował pomocy Microsoftu, żeby coś zepsuć. Zobaczymy dalsze tego dowody.
W końcu ARB, prawdopodobnie zagrożone zarówno przez ATI, jak i NVIDIA (obaj aktywni członkowie) ostatecznie wyciągnęło głowę na tyle długo, aby zapewnić rzeczywiste shadery w stylu asemblera.
Chcesz coś jeszcze głupszego?
Sprzętowe T&L. Najpierw coś OpenGL . Cóż, to interesujące. Aby uzyskać maksymalną możliwą wydajność ze sprzętowych T&L, musisz przechowywać dane wierzchołków na GPU. W końcu to procesor GPU rzeczywiście chce użyć danych wierzchołków.
W D3D v7 Microsoft wprowadził koncepcję buforów wierzchołków. Są to przydzielone obszary pamięci GPU do przechowywania danych wierzchołków.
Chcesz wiedzieć, kiedy OpenGL ma ich odpowiednik? Och, NVIDIA, będąc miłośnikiem wszystkich rzeczy OpenGL (o ile są zastrzeżonymi rozszerzeniami NVIDIA), wydała rozszerzenie zakresu macierzy wierzchołków, gdy GeForce 256 po raz pierwszy uderzył. Ale kiedy ARB zdecydował się zapewnić podobną funkcjonalność?
Dwa lata później . Było to po tym, jak zatwierdzili shadery wierzchołków i fragmentów (piksele w języku D3D). Tyle czasu zajęło ARB opracowanie wieloplatformowego rozwiązania do przechowywania danych wierzchołków w pamięci GPU. Znowu coś, czego sprzętowe T&L potrzebuje, aby osiągnąć maksymalną wydajność.
Jeden język, który ich zrujnuje
Tak więc środowisko programistyczne OpenGL zostało na pewien czas złamane. Żadnych shaderów między urządzeniami, żadnych sprzętowych magazynów wierzchołków GPU, podczas gdy użytkownicy D3D cieszyli się obydwoma. Czy może być gorzej?
Ty ... możesz to powiedzieć. Wejdź do 3D Labs .
Kim oni są, możesz zapytać? Są nieistniejącą firmą, którą uważam za prawdziwych zabójców OpenGL. Jasne, ogólna nieudolność ARB sprawiła, że OpenGL jest podatny na ataki, kiedy powinien był posiadać D3D. Ale 3D Labs to chyba największy powód, dla którego mam na myśli obecny stan rynkowy OpenGL. Co mogliby zrobić, aby to spowodować?
Zaprojektowali język cieniowania OpenGL.
Zobacz, 3D Labs była umierającą firmą. Ich drogie procesory graficzne zostały zmarginalizowane przez rosnącą presję firmy NVIDIA na rynek stacji roboczych. I w przeciwieństwie do NVIDIA, 3D Labs nie były obecne na głównym rynku; jeśli NVIDIA wygra, umrą.
Które zrobili.
Dlatego, chcąc pozostać aktualnymi w świecie, który nie chciał swoich produktów, 3D Labs pojawiło się na Game Developer Conference, w której prezentacje prezentowano pod nazwą „OpenGL 2.0”. Byłoby to kompletne, od podstaw przepisanie API OpenGL. I to ma sens; w tym czasie w API OpenGL było dużo cruft (uwaga: cruft nadal istnieje). Wystarczy spojrzeć na działanie ładowania i wiązania tekstur; jest częściowo tajemny.
Częścią ich propozycji był język cieniujący. Naturalnie. Jednak w przeciwieństwie do obecnych rozszerzeń ARB na wiele platform, ich językiem cieniowania był „wysoki poziom” (C jest wysokim poziomem dla języka cieniowania. Tak, naprawdę).
Teraz Microsoft pracował nad własnym językiem cieniowania wysokiego poziomu. Które, zgodnie ze wspólną wyobraźnią Microsoftu, nazwali ... High Shading Language (HLSL). Ale ich podejście do języków było zupełnie inne.
Największym problemem z językiem shadera 3D Labs było to, że był on wbudowany. Zobacz, HLSL był językiem zdefiniowanym przez Microsoft. Wydali dla niego kompilator, który wygenerował kod asemblera Shader Model 2.0 (lub nowsze modele shaderów), który zostałby przekazany do D3D. W D3D v9 dni D3D nigdy nie dotknął HLSL bezpośrednio. To była ładna abstrakcja, ale była całkowicie opcjonalna. Deweloper zawsze miał okazję pójść za kompilatorem i dostosować wydajność, aby uzyskać maksymalną wydajność.
Język 3D Labs tego nie miał . Nadałeś kierowcy język podobny do C, a on wytworzył moduł cieniujący. Koniec opowieści. Nie moduł cieniujący asemblera, nie coś, co karmisz czymś innym. Rzeczywisty obiekt OpenGL reprezentujący moduł cieniujący.
Oznaczało to, że użytkownicy OpenGL byli otwarci na kaprysy programistów, którzy dopiero zaczynali kompilować kompilowanie języków podobnych do asemblera. Błędy kompilatora szalały w nowo ochrzczonym OpenGL Shading Language (GLSL). Co gorsza, jeśli udało ci się poprawnie skompilować moduł cieniujący na wielu platformach (nie lada wyczyn), nadal podlegałeś optymalizatorom dnia. Które nie były tak optymalne, jak mogłyby być.
Chociaż była to największa wada w GLSL, nie była to jedyna wada. Jak dotąd .
W D3D oraz w starszych językach asemblera w OpenGL można mieszać i dopasowywać shadery wierzchołków i fragmentów (pikseli). Tak długo, jak komunikują się z tym samym interfejsem, można używać dowolnego modułu cieniującego wierzchołków z dowolnym zgodnym modułem cieniującym fragmentów. Były nawet poziomy niezgodności, które mogli zaakceptować; moduł cieniujący wierzchołek mógłby zapisać dane wyjściowe, których moduł cieniujący fragmentów nie odczytał. I tak dalej.
GLSL tego nie miał. Shadery wierzchołków i fragmentów zostały połączone w coś, co 3D Labs nazwał „obiektem programu”. Więc jeśli chcesz współdzielić programy wierzchołków i fragmentów, musisz zbudować wiele obiektów programu. A to spowodowało drugi największy problem.
Widzisz, 3D Labs uważało, że są sprytni. Oparli model kompilacji GLSL na C / C ++. Bierzesz .c lub .cpp i kompilujesz w plik obiektowy. Następnie bierzesz jeden lub więcej plików obiektowych i łączysz je w program. Tak właśnie kompiluje się GLSL: kompilujesz moduł cieniujący (wierzchołek lub fragment) w obiekt modułu cieniującego. Następnie umieszczasz te obiekty cieniujące w obiekcie programu i łączysz je ze sobą, aby utworzyć rzeczywisty program.
Chociaż pozwoliło to na potencjalne fajne pomysły, takie jak posiadanie „bibliotekowych” modułów cieniujących, które zawierały dodatkowy kod, który mogły wywoływać główne moduły cieniujące, w praktyce oznaczało to, że moduły cieniujące były kompilowane dwukrotnie . Raz na etapie kompilacji i raz na etapie łączenia. Szczególnie kompilator NVIDIA był znany z tego, że w zasadzie dwukrotnie uruchomił kompilację. Nie wygenerował jakiegoś pośredniego kodu obiektowego; po prostu go skompilował i wyrzucił odpowiedź, a następnie skompilował ponownie w czasie łączenia.
Więc nawet jeśli chcesz połączyć swój moduł cieniujący wierzchołki z dwoma różnymi modułami cieniującymi fragmentów, musisz wykonać dużo więcej kompilacji niż w D3D. Zwłaszcza, że kompilacja języka podobnego do C była wykonywana offline , a nie na początku wykonywania programu.
Były inne problemy z GLSL. Być może niewłaściwe jest obwinianie 3D Labs, ponieważ ARB ostatecznie zaakceptowało i włączyło język (ale nic więcej z ich inicjatywy „OpenGL 2.0”). Ale to był ich pomysł.
A oto bardzo smutna część: 3D Labs miał rację (głównie). GLSL nie jest wektorowym językiem cieniowania takim, jak wtedy HLSL. Stało się tak, ponieważ sprzęt 3D Labs był sprzętem skalarnym (podobnym do nowoczesnego sprzętu NVIDIA), ale ostatecznie byli w dobrym kierunku, w którym wielu producentów sprzętu poszło ze swoim sprzętem.
Mieli rację, wybierając model kompilacji online dla języka „wysokiego poziomu”. D3D nawet przeszedł na to ostatecznie.
Problem polegał na tym, że 3D Labs miały rację w niewłaściwym czasie . Starając się przywołać przyszłość zbyt wcześnie, starając się być przyszłościowym, odrzucają teraźniejszość . Brzmi podobnie do tego, jak OpenGL zawsze miał możliwość korzystania z T&L. Tyle tylko, że potok R&L OpenGL wciąż był przydatny przed sprzętowymi RCP, a GLSL był odpowiedzialnością, zanim świat go dogonił.
GLSL jest teraz dobrym językiem . Ale na razie? To było okropne. A OpenGL cierpiał z tego powodu.
Spadanie w kierunku apoteozy
Podczas gdy utrzymuję, że 3D Labs zadało śmiertelny cios, to sam ARB wbił ostatni gwóźdź do trumny.
To historia, o której słyszałeś. Do czasu OpenGL 2.1 OpenGL miał problem. Miał dużo starszego crufta. Interfejs API nie był już łatwy w użyciu. Było 5 sposobów na robienie rzeczy i nie ma pojęcia, który był najszybszy. Możesz „nauczyć się” OpenGL za pomocą prostych samouczków, ale tak naprawdę nie nauczyłeś się interfejsu API OpenGL, który dał ci prawdziwą wydajność i moc graficzną.
ARB postanowił więc spróbować ponownie wymyślić OpenGL. Było to podobne do „OpenGL 2.0” 3D Labs, ale lepiej, ponieważ ARB za tym stoi. Nazwali to „Longs Peak”.
Co jest takiego złego w tym, że poświęca się trochę czasu na ulepszenie API? To było złe, ponieważ Microsoft naruszył się. Widzisz, to było w momencie przejścia na system Vista.
W systemie Vista Microsoft zdecydował się wprowadzić bardzo potrzebne zmiany w sterownikach ekranu. Zmusili sterowniki do poddania się systemowi operacyjnemu w celu wirtualizacji pamięci graficznej i różnych innych rzeczy.
Chociaż można dyskutować o zaletach tego lub o tym, czy było to faktycznie możliwe, fakt pozostaje taki: Microsoft uznał, że D3D 10 to tylko Vista (i wyżej). Nawet jeśli posiadasz sprzęt zdolny do obsługi D3D 10, nie możesz uruchomić aplikacji D3D 10 bez systemu Vista.
Możesz również pamiętać, że Vista ... um, powiedzmy, że nie wyszło dobrze. Miałeś więc słabo działający system operacyjny, nowy interfejs API, który działał tylko w tym systemie operacyjnym, oraz nową generację sprzętu, który wymagał tego interfejsu API i systemu operacyjnego, aby zrobić coś więcej niż być szybszym niż poprzednia generacja.
Jednak programiści mogli uzyskać dostęp do funkcji klasy D3D 10 za pośrednictwem OpenGL. Cóż, mogliby, gdyby ARB nie był zajęty pracą nad Longs Peak.
Zasadniczo ARB spędził dobry rok i pół do dwóch lat pracy, aby ulepszyć API. Do czasu, gdy faktycznie pojawiła się OpenGL 3.0, zaczęła się adaptacja Vista, Win7 był już tuż za nimi, a większość twórców gier nie dbała o funkcje klasy D3D-10. W końcu sprzęt D3D 10 działał dobrze z aplikacjami D3D 9. Wraz ze wzrostem liczby portów PC-na-konsolę (lub deweloperów PC przeskakujących z platformy na konsolę. Wybieraj), programiści nie potrzebowali funkcji klasy D3D 10.
Teraz, jeśli programiści mieli dostęp do tych funkcji wcześniej za pośrednictwem OpenGL na maszynach WinXP, to rozwój OpenGL mógł zostać bardzo potrzebny. Ale ARB stracił okazję. A chcesz poznać najgorszą część?
Pomimo spędzenia dwóch cennych lat na odbudowie API od zera ... nadal nie powiodły się i po prostu wróciły do status quo (z wyjątkiem mechanizmu amortyzacji).
Dlatego ARB nie tylko przegapiło kluczowe okno okazji, ale nawet nie wykonało zadania, które sprawiło, że stracili tę szansę. Dość duża epicka porażka dookoła.
I taka jest opowieść o OpenGL vs. Direct3D. Opowieść o utraconych szansach, rażącej głupocie, celowej ślepocie i zwykłej głupocie.