Grafické karty. DirectX a OpenGL - počítačová grafika

Pýtate sa: kto sú to? Sú to mŕtva spoločnosť, ktorú považujem za skutočného vraha OpenGL. Samozrejme, všeobecné zlyhanie výboru spôsobilo, že OpenGL bol zraniteľný, keď musel trhať D3D na kúsky. Ale podľa môjho názoru sú 3D Labs možno jediným dôvodom súčasnej pozície OpenGL na trhu. Čo pre to urobili?

Vyvinuli shaderový jazyk pre OpenGL.

3D Labs bola spoločnosť zomierajúca. Ich drahé GPU boli vytlačené z trhu pracovných staníc zvyšujúcim sa tlakom spoločnosti nVidia. A na rozdiel od nVidia, 3D Labs nebolo na spotrebiteľskom trhu; Víťazstvo nVidie by pre 3D Labs znamenalo smrť.

Čo sa nakoniec stalo.

V snahe udržať sa na hladine vo svete, ktorý nepotreboval ich produkty, sa 3D Labs predviedli na konferencii Game Developer Conference s prezentáciou toho, čo nazývali „OpenGL 2.0“. Bolo to OpenGL API prepísané od nuly. A malo to zmysel, pretože v tých časoch bolo API OpenGL plné harabúrd (ktoré tam však zostávajú dodnes). Stačí sa pozrieť na to, aké je ezoterické zaťaženie a viazanie textúr.

Súčasťou ich návrhu bol shader jazyk. Áno, bol to on. Avšak na rozdiel od existujúcich rozšírení pre rôzne platformy bol ich jazyk shaderu „na vysokej úrovni“ (C je na vysokej úrovni pre jazyk shader).

Microsoft zároveň pracoval na vlastnom shader jazyku. Ktorý, vrátane všetkých svojich kolektívnych predstáv, nazvali ... High Level Shader Language (HLSL). Ale ich prístup k jazyku bol zásadne odlišný.

Najväčším problémom jazyka od 3D Labs bolo, že bol zabudovateľný. Microsoft mohol úplne slobodne definovať svoj jazyk. Vydali kompilátor, ktorý vygeneroval montážny kód pre shadery SM 2.0 (alebo vyšší), ktoré sa zase mohli načítať do D3D. Počas D3D v9 sa HLSL nikdy nedotkol priamo D3D. Bola to síce pekná, ale voliteľná abstrakcia. Vývojár mal vždy možnosť vziať výfuk kompilátora a vyladiť ho na maximálny výkon.

V jazyku od 3D laboratórií nič nebolo to. Vodičovi dáte jazyk podobný jazyku C a vytvorí sa shader. To je všetko. Žiadne montážne shadery, nič na kŕmenie niečím iným. Iba objekt OpenGL, ktorý predstavuje shader.

Pre používateľov OpenGL to znamenalo, že sa stali náchylnými k rozmarom vývojárov OpenGL, ktorí sa práve naučili kompilovať jazyky podobné assembleru. Zostavovatelia novo narodeného jazyka OpenGL Shader Language (GLSL) sa množili chýb. Aby toho nebolo málo, pokiaľ sa vám podarilo dosiahnuť, aby sa shader správne kompiloval na rôznych platformách (čo bolo samo o sebe veľkým úspechom), potom bol stále náchylný na optimalizátory tie časy, ktoré neboli také optimálne, ako by mohli byť.

To bola veľká, ale nie jediná nevýhoda GLSL. Dlho preč nie jediný.

V D3D, rovnako ako v starých montážnych jazykoch OpenGL, bolo možné všemožne kombinovať a kombinovať shadery vrcholov a fragmentov. Akýkoľvek vrchol shaderu je možné použiť s akýmkoľvek kompatibilným shaderom fragmentov, pokiaľ komunikovali cez to isté rozhranie. Navyše bola povolená dokonca aj nejaká nekompatibilita: napríklad shader vrcholu mohol vygenerovať hodnotu, ktorú shader fragmentov nepoužil.

V GLSL nič také nebolo. Vrchol a shader fragmentov sa spojili a vytvorili niečo, čo 3D Labs nazývalo „softvérový objekt“. Preto, aby ste mohli spolu použiť niekoľko shaderov vrcholov a fragmentov v rôznych kombináciách, bolo potrebné vytvoriť niekoľko softvérových objektov. Toto bol druhý najväčší problém.

3D Labs si mysleli, že sú najchytrejší. Za základ kompilačného modelu GLSL vzali C / C ++. To je, keď vezmete jeden súbor c a skompilujete ho do súboru objektov. Potom vezmete niekoľko súborov objektov a prepojíte ich s programom. Takto kompiluje GLSL: najskôr skompilujete vrchol alebo fragment shaderu do objektu shaderu, potom tieto objekty vložíte do objektu programu a spojíte ich dohromady, aby ste nakoniec vytvorili program.

Teoreticky to umožňovalo skvelé veci, ako sú shadery „knižnice“, ktoré obsahujú kód nazývaný hlavným shaderom. V praxi to viedlo k tomu, že shadery boli zostavené. dvakrát: raz v čase kompilácie a druhýkrát v štádiu prepojenia. Preslávil sa tým najmä kompilátor nVidia. Nevygeneroval žiadny prostredný objektový kód; najskôr skompiloval, zahodil výstup a znova zostavil vo fáze odkazu.

Ak chcete teda pripojiť shader vrcholu k dvom rôznym shaderom fragmentov, museli ste zostaviť oveľa viac ako v D3D. Najmä vzhľadom na to, že celá kompilácia je hotová offline, a nie pred okamžitým vykonaním programu.

GLSL mala aj ďalšie problémy. Môže byť nesprávne vyčítať všetku vinu 3D Labs, pretože ARB nakoniec schválila a začlenila shaderový jazyk do OpenGL (ale nič iné z návrhov 3DLabs). Pôvodný nápad však stále bol pre 3D Labs.

A teraz najsmutnejšia vec: 3D Labs boli správny (v podstate). GLSL nie je vektorový jazyk, akým bol v tom čase HLSL. Stalo sa tak preto, že hardvér spoločnosti 3D Labs bol skalárny (ako moderný hardvér od spoločnosti nVidia) a pri výbere smeru, ktorým sa neskôr mnohí výrobcovia hardvéru vydali, sa správali úplne správne.

Mali pravdu aj pri výbere modelu kompilácie pre jazyk „na vysokej úrovni“. Nakoniec to urobila dokonca aj D3D.

Problém je v tom, že 3D Labs mal pravdu v zlom čas... A v snahe dostať sa predčasne do budúcnosti, v snahe byť pripravení na budúcnosť, odložili prítomnosť bokom. Vyzerá to na funkčnosť T&L v OpenGL, ktorá tu vždy bola. Ibaže plynovod T&L OpenGL bol užitočné a predtým, ako sa objavil hardvér T&L, a GLSL bolo záťažou skôr, ako to dobehol zvyšok sveta.

GLSL je dobrý jazyk teraz... Čo sa však stalo v tom čase? Bol hrozný. A OpenGL tým trpelo.

Blíži sa apoteóza

Podporujem názor, že 3D Labs zasadili OpenGL smrtiaci úder, ale samotný ARB zatĺkol posledný klinec do rakvy.

Možno ste už tento príbeh počuli. V časoch OpenGL 2.1 mal OpenGL veľké problémy. Vliekol sa obrovský zaťaženie kompatibility. Používanie API už nebolo jednoduché. Jedna vec sa dala urobiť piatimi rôznymi spôsobmi a nie je jasné, ktorý z nich je rýchlejší. OpenGL ste sa mohli „naučiť“ pomocou jednoduchých návodov, ale nenaučili ste sa OpenGL, ktorý vám dáva skutočný grafický výkon a výkon.

ARB sa rozhodol urobiť ďalší pokus o znovuobjavenie OpenGL. Bolo to ako „OpenGL 2.0“ z 3D Labs, ale lepšie, pretože za týmto pokusom stála ARB. Volali to „Longs Peak“.

Čo je také zlé na tom, že som strávil trochu času vylepšovaním API? Zlou správou je, že Microsoft je v dosť vratkej pozícii. Nastal čas prechodu na systém Vista.

V systéme Vista sa spoločnosť Microsoft rozhodla vykonať dlho očakávané zmeny v grafických ovládačoch. Prinútili vodičov, aby vyhľadali virtualizáciu grafickej pamäte v operačnom systéme a ďalšie.

O výhodách tohto prístupu sa dá dlho polemizovať a či je to vôbec možné, ale faktom zostáva: Microsoft vyrobil D3D 10 iba pre Vista a vyššie. Aj na podporné Pre hardvér D3D bolo nemožné spustiť aplikáciu D3D bez systému Vista.

Možno si pamätáte, že Vista ... povedzme, že to veľmi nefungovalo. Takže sme mali pohodový OS, nové API, ktoré fungovalo iba na tomto OS, a novú generáciu hardvéru potrebné v tomto API a OS dokáže prekonať výkon nielen predchádzajúcou generáciou.

Avšak vývojári mohol používať funkčnosť na úrovni D3D 10 cez OpenGL. To znamená, že by mohli, keby ARB nebol zaneprázdnený prácou na Long Peaks.

ARB strávil dobrý rok a pol až dva prácami na vylepšovaní API. V čase vydania OpenGL 3.0 bol prechod na systém Vista ukončený, systém Windows 7 bol na ceste a vývojárom hier už viac nezáležalo na funkčnosti na úrovni D3D 10. Hardvér D3D 10 nakoniec fungoval s aplikáciami D3D 9 v pohode. konzoly (alebo s prechodom vývojárov PC na trh konzol), vývojári čoraz menej potrebovali funkcionalitu D3D 10.

Keby mali vývojári prístup k tejto funkcii aj v systéme Windows XP, vývoj OpenGL by mohol získať životodarnú podporu. ARB ale túto príležitosť premeškala. Chceš vedieť, čo je najhoršie?

ARB zlyhalo znovuobjavte API od nuly napriek tomu, že ste o to stratili dva vzácne roky. Priniesli späť súčasný stav a pridali iba mechanizmus na vyhlásenie funkčnosti za zastaranú.

Vďaka tomu ARB nielenže chýbal kľúč príležitosti, ale tiež nedokončil prácu, ktorá ich viedla k tomuto vynechaniu. Bol to epický nepodarok.

Toto je príbeh OpenGL verzus Direct3D. Príbeh premeškaných príležitostí, najväčšej hlúposti, svojvoľnej nerozvážnosti a banálnych absurdností.

Bežné sú rôzne mylné predstavy o týchto dvoch API.

Pokúsil som sa v tomto článku zhrnúť základné fakty, ktoré by vývojári aj koncoví používatelia mali vedieť.

Keďže téma je veľmi holivarská, snažil som sa udržiavať tón čo naj neutrálnejší.

Pohľad z vtáčej perspektívy

Obidve API poskytujú prístup k hardvérovej funkcii akcelerácie 3D grafiky.

Bežné mylné predstavy

OpenGL zaostáva za Direct3D a všeobecne, podľa pomalých zmien v špecifikácii, je pravdepodobne už úplne mŕtvy.

Dôvodom tejto mylnej predstavy je v skutočnosti neznalosť rozšírení. Všeobecne povedané, OpenGL môže a často predstihuje (!) Direct3D z hľadiska inovácie, pretože predajca môže pridať rozšírenie do OpenGL bez toho, aby na niekoho čakal, zatiaľ čo Direct3D môže meniť iba Microsoft.

OpenGL je určený pre profesionálne grafické programy a Direct3D je určený pre hry.

Táto mylná predstava má historickú príčinu. OpenGL bol pôvodne navrhnutý ako 3D grafická knižnica, ktorá CAN, ale NEMUSÍ byť hardvérovo akcelerovaná. To tiež vysvetľuje prítomnosť niektorých funkcií, napríklad vykresľovania stereofónnych obrázkov, ktoré hry nepotrebujú. Direct3D bol vyvinutý oveľa neskôr, okamžite s očakávaním akcelerácie na GPU. V čase objavenia sa mnohých balíkov profesionálna práca s grafikou Direct3D jednoducho neexistovala.

Spoločnosť Microsoft sa dodáva s ovládačmi systému Windows bez podpory OpenGL. OpenGL sa bude vykresľovať bez akcelerácie alebo sa bude emulovať cez DirectX. Ak teda potrebujete podporu OpenGL pre Windows, musíte si nainštalovať ovládač z webovej stránky výrobcu. Dôvody tohto odmietnutia OpenGL sú s najväčšou pravdepodobnosťou opäť čisto politické.

Čo teda robiť, ako žiť?

Poznámka: Táto časť je veľmi subjektívna.

Ak ste vývojár a rozhodujete sa, ktoré rozhranie API použijete, zvážte nasledovné:
Pre OpenGL - obrovskú platformu, najmä dostupnosť všetkých nových funkcií v systéme Windows XP, kde Direct3D 10/11 nie je a nikdy nebude.
Proti OpenGL - ovládače pre Windows nemajú podporu OpenGL hotovú, takže si ich musíte nainštalovať z webovej stránky výrobcu.

Ak ste v oblasti vývoja 3D aplikácií nováčikom a chcete si osvojiť túto oblasť, odporučil by som to: najskôr sa vysporiadajte s Direct3D (dôvod je jednoduchý - spoločnosť Microsoft poskytuje veľmi kvalitnú súpravu SDK), až potom sa vysporiadajte s OpenGL (bude to veľmi jednoduché po Direct3D). Bohužiaľ, neexistuje nič také ako SDK pre OpenGL. Preto bude ťažšie zvládnuť od nuly.

To je všetko. Úspech vo vývoji!

Zdá sa, že veľmi veľa používateľov, najmä tých, ktorí uprednostňujú inštaláciu a spustenie moderných hier náročných na zdroje pomocou počítača, vedia, že v nastaveniach grafiky môžete použiť špeciálne prostriedky na zrýchlenie zobrazenia a zlepšenie kvality obrazu OpenGL alebo DirectX. Aký je najlepší spôsob využitia všetkých skrytých zdrojov počítačového systému a maximalizácie výkonu? Táto otázka je dosť kontroverzná a zvyčajne nie je možné jednoznačne odpovedať v prospech ktorejkoľvek platformy, pretože všetko závisí od konkrétneho cieľa, ktorý si používateľ alebo vývojár stanoví, ako aj od každej konkrétnej situácie, ktorá môže čiastočne súvisieť “ hardvér „hardvér vo forme grafického akcelerátora, jeho softvérová podpora vo forme ovládačov a niektoré ďalšie aspekty. Pokúsme sa prísť na to, čo je lepšie - OpenGL alebo DirectX - s odvolaním sa na oficiálne zdroje informácií a na základe názorov používateľov a vývojárov softvéru, ktorí môžu vyžadovať podporu týchto technológií.

Čo sú OpenGL a DirectX?

Na úvod existuje medzi bežnými používateľmi mylná predstava, že tieto dve popísané súčasti sú grafické moduly. Preto vznikajú nesprávne otázky, ktorý motor je lepší - OpenGL alebo DirectX?

Faktom je, že tieto platformy súvisia s motormi iba čiastočne, pretože ide výlučne o softvér, ktorý umožňuje softvérovému enginu programu (hre) komunikovať s nainštalovaným hardvérom (najčastejšie s grafickými a zvukovými kartami) prostredníctvom ich ovládačov, ktoré fungujú ako sprostredkovatelia. OpenGL a DirectX sú v skutočnosti súčasťou aplikačných programovacích rozhraní s potrebnými sadami knižníc, tried, definícií, štruktúr, konštánt a funkcií používaných na zabezpečenie práce s externými softvérovými produktmi nainštalovanými v operačnom systéme.

Na čo sa tieto technológie používajú?

Prirodzene, veľmi často sa môžete stretnúť s otázkami, ktorá grafika je lepšia - OpenGL alebo DirectX? Toto tvrdenie je tiež čiastočne nesprávne, pretože môžeme hovoriť nielen o použití zdrojov grafických kariet, ale aj o zvuku alebo akomkoľvek inom „hardvéri“ a virtuálnych multimediálnych zariadeniach. Najčastejšie ale skutočne hovoríme o grafických akcelerátoroch. Zároveň musíte jasne pochopiť, že výber v prospech jedného alebo druhého „mosta“, ktorý zaisťuje interakciu grafickej karty s nainštalovanou hrou alebo iným programom, ak je to potrebné, môže tiež závisieť od toho, aká povinná je takáto podpora.

V moderných hrách so zložitými textúrami a dôkladne vykreslenými dynamickými scénami je takáto podpora mimoriadne nevyhnutná. Problém však je, že nie všetky grafické akcelerátory môžu túto podporu používať správne. V takom prípade všetko závisí od vodičov. Či už je karta trendy, ale so zastaraným ovládacím softvérom (ovládačmi), nebude môcť využívať všetky funkcie, ktoré výrobca pôvodne oznámil. Napriek tomu je vo väčšine hier alebo v programoch na prácu s multimédiami (napríklad na spracovanie videa) veľmi často potrebné zvoliť, ktorú podporu chcete nainštalovať v nastaveniach, ktoré sú v rozpore s jednou platformou pre druhú (v anglickej verzii to zvyčajne vyzerá ako „OpenGL vs DirectX“) ...

Hlavné rozdiely medzi DirectX a OpenGL

Pokiaľ ide o hlavné rozdiely, bez toho, aby sme sa zaoberali technickými aspektmi fungovania, je možné okamžite poznamenať, že platforma DirectX, ktorá je exkluzívnym vývojom spoločnosti Microsoft Corporation, je určená výhradne na použitie v systémoch Windows a čiastočne na zariadeniach Xbox a OpenGL je voľne distribuovaná multiplatformová technológia použiteľná. v iných operačných systémoch (dokonca aj mobilných). Licencia GNU umožňuje komukoľvek vykonať vlastné zmeny a doplnky k komponentom tohto API, pokiaľ ide o jeho vylepšenia, aby sa zlepšil výkon rovnakých grafických kariet, zatiaľ čo vylepšenia DirectX si musia počkať až po vydaní nových verzií platformy. Súčasne ani s najnovšími ovládačmi, ak sa používajú v starších verziách mosta, grafické akcelerátory nedávajú indikátory deklarované výrobcom.

Hlavné výhody a nevýhody

Keď už hovoríme o tom, čo je lepšie - OpenGL alebo DirectX 11 (12), treba osobitne poznamenať, že prvá platforma je určená iba pre grafiku a druhá sa dá použiť všeobecne na všetko, čo súvisí s multimédiami (v tomto prípade je za grafiku zodpovedná súčasť Direct3D) ...

Mnoho odborníkov navyše upozorňuje, že do veľkej miery môže výber v prospech jedného alebo druhého mosta závisieť aj od typu grafickej karty. Ak však k porovnaniu pristupujete s otvorenou mysľou, predpokladá sa, že z hľadiska pokrytia platformy vyzerá OpenGL lepšie, ale DirectX vyhráva, pokiaľ ide o hotový softvérový produkt, ako je trieda Plug & Play. Nezabudnite však, že najnovšia sada nástrojov DirectX je už k dispozícii v OpenGL, ale neexistuje spätná podpora.

OpenGL vs. DirectX: Čo je lepšie pre hranie hier?

Pokiaľ ide o hry, jednoznačná odpoveď neexistuje. Napríklad sa často môžete stretnúť s komentármi, že grafické čipy rady Radeon 9800 vykazujú najlepšie výsledky v testoch na základe DirectX a kariet GeForce 5XXX - pri použití OpenGL. DirectX má ale ešte jednu nepopierateľnú výhodu.

Pretože most OpenGL bol pôvodne vytvorený pre iné platformy, v systéme Windows sa s ním môžu objavovať najrôznejšie chyby, ale DirectX vám umožňuje hrať hry pomerne tolerantne aj na relatívne zastaraných počítačoch bez akéhokoľvek oneskorenia (živým príkladom je hra Age Of Empires).

Stáva sa to aj naopak. Niektorí používatelia si napríklad všimnú, že program DOOM 3 práve letí na kartách série Radeon X1XXX pomocou OpenGL a program Half-Life 2 sa často spomalí. Tu ale zjavne všetko závisí aj od vodičov.

Ale ak hra podporuje použitie oboch technológií, je najlepšie vidieť, aký bude výsledok grafickej karty pri striedavom používaní jednotlivých režimov. Je samozrejmé, že aby sa dosiahol optimálny výkon, musia sa platformy aj ovládače grafického akcelerátora aktualizovať na najnovšie verzie.

Čo je lepšie pre BlueStacks: DirectX alebo OpenGL?

Pomerne často sa môžete stretnúť s otázkami o používaní jedného z najpopulárnejších emulátorov systémov Android s názvom BlueStacks. Ktorú platformu preferujete na BlueStacks - OpenGL alebo DirectX? Bohužiaľ, ani tu nie je možné dať jednoznačnú odpoveď.

Ticho sa však verí, že ak sa hry inštalujú prostredníctvom tohto emulátora, je lepšie používať OpenGL, ale ak sa hra spomalí, budete musieť prejsť na DirectX. Ale opäť tu ide o grafiku hry. V prípade profesionálneho spracovania a vykreslenia videa budete musieť veľa experimentovať.

Nakoniec, ak hovoríme o tom, čo je lepšie - OpenGL alebo DirectX - pre vývojára, ktorý práve začína ovládať tieto technológie a robí prvé kroky, väčšina odborníkov v tejto oblasti poznamenáva, že je lepšie sa najskôr oboznámiť s princípmi fungovania a súborom nástrojov DirectX, pretože táto platforma pre začiatočníka vyzerá jednoduchšie a neustále sa preň vydávajú dobré sady SDK určené na zjednodušenie prispôsobenia softvérových produktov „hardvéru“ a až potom prechádzajú k učeniu OpenGL.

Veľa však môže závisieť aj od toho, aký konečný cieľ si stanovíte a aký druh funkčnosti jednotlivých platforiem sa použije v konkrétnom prípade (iba grafika, iba zvuk alebo kombinované riešenia).

Stručné závery

Zhrnutie, ako už je zrejmé, je dosť ťažké urobiť jednoznačný záver v prospech jednej alebo druhej zložky. Medzi týmito platformami existuje neustála konkurencia. Nová verzia DirectX niekedy svojimi parametrami predbieha OpenGL, ale keď zastaráva a zavádza sa inovácia OpenGL, začína sa strácať. Vo všeobecnosti by sa výber mal zakladať iba na známom princípe, že pravda sa dozvedá porovnaním. Vyskúšajte oboje! Až po získaní konkrétnych výsledkov a pre každý konkrétny prípad bude zrejmé, na ktorú stranu váh sa vaša voľba prikloní.

Zdá sa, že veľmi veľa používateľov, najmä tých, ktorí uprednostňujú inštaláciu a spustenie moderných hier náročných na zdroje pomocou počítača, vedia, že v nastaveniach grafiky môžete použiť špeciálne prostriedky na zrýchlenie zobrazenia a zlepšenie kvality obrazu OpenGL alebo DirectX. Aký je najlepší spôsob využitia všetkých skrytých zdrojov počítačového systému a maximalizácie výkonu? Táto otázka je dosť kontroverzná a zvyčajne nie je možné jednoznačne odpovedať v prospech ktorejkoľvek platformy, pretože všetko závisí od konkrétneho cieľa, ktorý si používateľ alebo vývojár stanoví, ako aj od každej konkrétnej situácie, ktorá môže čiastočne súvisieť “ hardvér „hardvér vo forme grafického akcelerátora, jeho softvérová podpora vo forme ovládačov a niektoré ďalšie aspekty. Pokúsme sa prísť na to, čo je lepšie - OpenGL alebo DirectX - s odvolaním sa na oficiálne zdroje informácií a na základe názorov používateľov a vývojárov softvéru, ktorí môžu vyžadovať podporu týchto technológií.

Čo sú OpenGL a DirectX?

Na úvod existuje medzi bežnými používateľmi mylná predstava, že tieto dve popísané súčasti sú grafické moduly. Preto vznikajú nesprávne otázky, ktorý motor je lepší - OpenGL alebo DirectX?

Faktom je, že tieto platformy súvisia s motormi iba čiastočne, pretože ide výlučne o softvér, ktorý umožňuje softvérovému enginu programu (hre) komunikovať s nainštalovaným hardvérom (najčastejšie s grafickými a zvukovými kartami) prostredníctvom ich ovládačov, ktoré fungujú ako sprostredkovatelia. OpenGL a DirectX sú v skutočnosti súčasťou aplikačných programovacích rozhraní s potrebnými sadami knižníc, tried, definícií, štruktúr, konštánt a funkcií používaných na zabezpečenie práce s externými softvérovými produktmi nainštalovanými v operačnom systéme.

Na čo sa tieto technológie používajú?

Prirodzene, veľmi často sa môžete stretnúť s otázkami, ktorá grafika je lepšia - OpenGL alebo DirectX? Toto tvrdenie je tiež čiastočne nesprávne, pretože môžeme hovoriť nielen o použití zdrojov grafických kariet, ale aj o zvuku alebo akomkoľvek inom „hardvéri“ a virtuálnych multimediálnych zariadeniach. Najčastejšie ale skutočne hovoríme o grafických akcelerátoroch. Zároveň musíte jasne pochopiť, že výber v prospech jedného alebo druhého „mosta“, ktorý zaisťuje interakciu grafickej karty s nainštalovanou hrou alebo iným programom, ak je to potrebné, môže tiež závisieť od toho, aká povinná je takáto podpora.

V moderných hrách so zložitými textúrami a dôkladne vykreslenými dynamickými scénami je takáto podpora mimoriadne nevyhnutná. Problém však je, že nie všetky grafické akcelerátory môžu túto podporu používať správne. V takom prípade všetko závisí od vodičov. Či už je karta trendy, ale so zastaraným ovládacím softvérom (ovládačmi), nebude môcť využívať všetky funkcie, ktoré výrobca pôvodne oznámil. Napriek tomu je vo väčšine hier alebo v programoch na prácu s multimédiami (napríklad na spracovanie videa) veľmi často potrebné zvoliť, ktorú podporu chcete nainštalovať v nastaveniach, ktoré sú v rozpore s jednou platformou pre druhú (v anglickej verzii to zvyčajne vyzerá ako „OpenGL vs DirectX“) ...

Hlavné rozdiely medzi DirectX a OpenGL

Pokiaľ ide o hlavné rozdiely, bez toho, aby sme sa zaoberali technickými aspektmi fungovania, je možné okamžite poznamenať, že platforma DirectX, ktorá je exkluzívnym vývojom spoločnosti Microsoft Corporation, je určená výhradne na použitie v systémoch Windows a čiastočne na zariadeniach Xbox a OpenGL je voľne distribuovaná multiplatformová technológia použiteľná. v iných operačných systémoch (dokonca aj mobilných). Licencia GNU umožňuje komukoľvek vykonať vlastné zmeny a doplnky k komponentom tohto API, pokiaľ ide o jeho vylepšenia, aby sa zlepšil výkon rovnakých grafických kariet, zatiaľ čo vylepšenia DirectX si musia počkať až po vydaní nových verzií platformy. Súčasne ani s najnovšími ovládačmi, ak sa používajú v starších verziách mosta, grafické akcelerátory nedávajú indikátory deklarované výrobcom.

Hlavné výhody a nevýhody

Keď už hovoríme o tom, čo je lepšie - OpenGL alebo DirectX 11 (12), stojí za zmienku osobitne, že prvá platforma je určená iba pre grafiku a druhá sa dá použiť všeobecne na všetko, čo sa týka multimédií (za grafiku v tomto prípade zodpovedá komponent Direct3D) ...

Mnoho odborníkov navyše upozorňuje, že do veľkej miery môže výber v prospech jedného alebo druhého mosta závisieť aj od typu grafickej karty. Ak však k porovnaniu pristupujete s otvorenou mysľou, predpokladá sa, že z hľadiska pokrytia platformy vyzerá OpenGL lepšie, ale DirectX vyhráva, pokiaľ ide o hotový softvérový produkt, ako je trieda Plug & Play. Nezabudnite však, že najnovšia sada nástrojov DirectX je už k dispozícii v OpenGL, ale neexistuje spätná podpora.

OpenGL vs. DirectX: Čo je lepšie pre hranie hier?

Pokiaľ ide o hry, jednoznačná odpoveď neexistuje. Napríklad sa často môžete stretnúť s komentármi, že grafické čipy rady Radeon 9800 vykazujú najlepšie výsledky v testoch na základe DirectX a kariet GeForce 5XXX - pri použití OpenGL. DirectX má ale ešte jednu nepopierateľnú výhodu.

Pretože most OpenGL bol pôvodne vytvorený pre iné platformy, v systéme Windows sa s ním môžu objavovať najrôznejšie chyby, ale DirectX vám umožňuje hrať hry pomerne tolerantne aj na relatívne zastaraných počítačoch bez akéhokoľvek oneskorenia (živým príkladom je hra Age Of Empires).

Stáva sa to aj naopak. Niektorí používatelia si napríklad všimnú, že program DOOM 3 práve letí na kartách série Radeon X1XXX pomocou OpenGL a program Half-Life 2 sa často spomalí. Tu ale zjavne všetko závisí aj od vodičov.

Ale ak hra podporuje použitie oboch technológií, je najlepšie vidieť, aký bude výsledok grafickej karty pri striedavom používaní jednotlivých režimov. Je samozrejmé, že aby sa dosiahol optimálny výkon, musia sa platformy aj ovládače grafického akcelerátora aktualizovať na najnovšie verzie.

Čo je lepšie pre BlueStacks: DirectX alebo OpenGL?

Pomerne často sa môžete stretnúť s otázkami o používaní jedného z najpopulárnejších emulátorov Androidu s názvom BlueStacks. Ktorú platformu preferujete na BlueStacks - OpenGL alebo DirectX? Bohužiaľ, ani tu nie je možné dať jednoznačnú odpoveď.

Ticho sa však verí, že ak sa hry inštalujú prostredníctvom tohto emulátora, je lepšie používať OpenGL, ale ak sa hra spomalí, budete musieť prejsť na DirectX. Ale opäť tu ide o grafiku hry. V prípade profesionálneho spracovania a vykreslenia videa budete musieť veľa experimentovať.

Nakoniec, keď hovoríme o tom, čo je lepšie - OpenGL alebo DirectX - pre vývojára, ktorý práve začína ovládať tieto technológie a robí prvé kroky, väčšina odborníkov v tejto oblasti poznamenáva, že je lepšie sa najskôr oboznámiť s princípmi fungovania a súborom nástrojov DirectX, pretože táto platforma pre začiatočníka vyzerá jednoduchšie a neustále sa preň vydávajú celkom dobré sady SDK určené na zjednodušenie prispôsobenia softvérových produktov hardvéru a až potom sa učia OpenGL.

Veľa však môže závisieť aj od toho, aký konečný cieľ si stanovíte a aký druh funkčnosti jednotlivých platforiem sa použije v konkrétnom prípade (iba grafika, iba zvuk alebo kombinované riešenia).

Stručné závery

Zhrnutie, ako už je zrejmé, je dosť ťažké urobiť jednoznačný záver v prospech jednej alebo druhej zložky. Medzi týmito platformami existuje neustála konkurencia. Nová verzia DirectX niekedy svojimi parametrami predbieha OpenGL, ale keď zastaráva a zavádza sa inovácia OpenGL, začína sa strácať. Vo všeobecnosti by sa výber mal zakladať iba na známom princípe, že pravda sa dozvedá porovnaním. Vyskúšajte oboje! Až po získaní konkrétnych výsledkov a pre každý konkrétny prípad bude zrejmé, na ktorú stranu váh sa vaša voľba prikloní.

Vzhľadom na súčasnú dominanciu DirectX nedobrovoľne zabúdame, že pred 10 rokmi došlo v oblasti 3D API k tvrdej vojne medzi spoločnosťami Microsoft a Silicon Graphics. Tieto dve spoločnosti sa pokúsili získať dôveru vývojárov. Spoločnosť Microsoft využila svoju silnú finančnú podporu a spoločnosť SGI využila svoje odborné znalosti a reputáciu v 3D v reálnom čase. V tejto modernej bitke „David vs. Goliath“ má malý po svojom boku jedného z najslávnejších vývojárov hier - Johna Carmacka. Bolo to čiastočne kvôli úspechu motora Quake; robustná podpora OpenGL sa stala dôležitým faktorom pri získavaní výrobcov GPU k vydaniu kompletnej sady ovládačov. V skutočnosti to poskytlo spoločnosti 3dfx jednu z jej prvých výhod a spoločnosť ATI sa dostala do situácie, keď spoločnosť riešila problémy s podporou OpenGL.

Medzitým Microsoft budoval svoje API „od nuly“, vývoj bol postupný. Po niekoľko rokov neboli možnosti Direct3D ďaleko od požadovanej úrovne, mnohým programátorom pripadalo API viac mätúce a nepochopiteľné ako OpenGL. Microsoft však nemôže nikomu vyčítať, že sa ľahko vzdal. S každou novou verziou Direct3D API postupne dobehlo OpenGL. Inžinieri v Redmonde neúnavne pracovali na tom, aby priniesli výkon na úroveň konkurenčného API.

Zlom nastal s vydaním DirectX 8, ktoré sa objavilo v roku 2001. Microsoft API po prvýkrát poskytlo viac funkcií ako iba kopírovanie SGI API. Zaviedli sme vlastné inovácie, ako je podpora shaderov vrcholov a pixelov. Spoločnosť SGI, ktorej hlavným zdrojom zisku je predaj drahých 3D pracovných staníc, bola na tom zle, pretože spoločnosť nedokázala predpovedať výbušný rast grafických kariet pre hráčov, čo spoločnosti ATI a nVidia umožnilo preniknúť na profesionálny trh za také nízke ceny (z dôvodu úspor z rozsahu) ) že SGI jednoducho nemohla konkurovať. Vývoj OpenGL komplikovali aj búrlivé debaty medzi navrhovateľmi API. Pretože ARB (skupina zodpovedná za prijatie nových verzií API) zahŕňala mnoho rôznych a často konkurenčných spoločností, bolo ťažké dosiahnuť dohodu o vlastnostiach, ktoré je potrebné pridať do API. Namiesto toho každá spoločnosť obhajovala svoje záujmy. Naproti tomu Microsoft úzko spolupracoval s ATI a nVidia a pri rozhodovaní v prípade konfliktu využil svoju váhu.

S vydaním DirectX 9 získal Microsoft rozhodujúce víťazstvo a zaujal vývojárov. Iba John Carmack a tí vývojári, ktorým záležalo na všestrannosti, zostali oddaní OpenGL. Ich autorita však bola otrasená. Nezabúdajme však, že šťastie sa môže obrátiť. To sa nakoniec stalo aj pri webových prehliadačoch. Aj keď spoločnosť prekonala náročnú cestu a obsadila v skutočnosti monopolné postavenie, nestojí za to zaspať na vavrínoch, pretože konkurencia môže doslova vzniknúť z ničoho nič. A keď skupina Khronos pred dvoma rokmi prevzala vývoj OpenGL, bola tu nádej pre mnohých a o aktuálnu konferenciu SIGGRAPH bol veľký záujem.

V auguste spoločnosť Khronos oznámila OpenGL 3, významnú aktualizáciu API, ktorá má za cieľ dobehnúť Microsoft, a softvérový gigant zase plánoval novú generáciu DirectX 11 API. Všetko sa ale ukázalo trochu inak.

Aby sme úplne pochopili polemiku okolo oznámenia OpenGL 3, musíme sa vrátiť o niekoľko rokov späť, do roku 2002. Ako sme už povedali vyššie, zhruba v rovnakom čase začala OpenGL strácať pôdu pod nohami. Do tej doby DirectX jednoducho kopíroval možnosti OpenGL. Tentokrát sa Microsoftu podarilo predbehnúť SGI API. S vydaním DirectX 9 Microsoft pridal podporu pre shaderový jazyk na vysokej úrovni, HLSL a OpenGL nemali nič porovnateľné. Je potrebné pripomenúť, že korene OpenGL spočívajú v IRIS GL, API, ktoré bolo pôvodne vytvorené spoločnosťou SGI na podporu všetkých hardvérových funkcií spoločnosti. Po dlhú dobu ATI a NVidia jednoducho nasledovali model vykresľovania SGI, to znamená, že OpenGL bol veľmi vhodný pre výrobcov grafických kariet od samého začiatku. Ale s príchodom shaderov sa nové GPU odklonili od tradičného procesu vykresľovania.

V tom čase jedna spoločnosť uznala dôležitosť rýchleho evolučného vývoja OpenGL, ak API dúfalo, že bude fungovať na moderných GPU: máme na mysli 3DLabs. To nie je prekvapujúce, pretože 3DLabs opustili herné karty po zlyhaní hry Permedia 2 a zamerali sa na profesionálny trh, kde je štandardom OpenGL. Spoločnosť 3DLabs predstavila viacbodový plán, ktorý by umožnil OpenGL posunúť sa do novej éry. Prvý bod: pridanie jazyka shaderu na vysokej úrovni GLSL. Potom bola naplánovaná úplná revízia API. Mnoho funkcií API už stratilo zmysel na moderných 3D grafických kartách, ale kvôli spätnej kompatibilite vyžadovali, aby ich vývojári GPU podporovali aspoň na softvérovej úrovni. To nielen sťažilo písanie ovládačov a tiež zvýšilo pravdepodobnosť chýb, ale vďaka starším funkciám bolo API pre začínajúcich programátorov aj dosť mätúce.

Preto spoločnosť 3DLabs chcela ponúknuť sadu funkcií, ktorá by zabezpečila efektívne vykonávanie na GPU a tiež by odstránila zastarané alebo nadbytočné možnosti. Táto sada funkcií mala názov OpenGL 2.0 Pure a bola určená pre vývojárov nových aplikácií. Kvôli spätnej kompatibilite bola do Open GL 2.0 pridaná celá sada rozšírení OpenGL 1.x.

Po nekonečných diskusiách v rámci výboru ARB bol tento plán, bohužiaľ, odmietnutý. A keď bol konečne k dispozícii OpenGL 2.0, stačilo len pridať do API podporu GLSL. Všetky ďalšie ponuky 3DLabs skončili v koši a výsledkom bolo, že OpenGL naďalej zaostával za rozhraním Microsoft API.

Potrebujete zmenu

Ďalší príklad ukazuje, že ARB nie je schopný robiť rýchle a efektívne rozhodnutia. OpenGL sa pri vykresľovaní textúr dlho spoliehala na techniku \u200b\u200bzvanú pbuffers. Všetci programátori sa zhodli na tom, že táto technika bola ťažko pochopiteľná, ťažko použiteľná a poskytovala slabý výkon. Preto spoločnosť ATI navrhla rozšírenie, ktoré by ju nahradilo - uber-buffers. Ukázalo sa, že toto rozšírenie bolo dosť ambiciózne. Okrem vykresľovania na textúru umožnilo ATI okrem iných pokročilých funkcií vykresliť aj do vrcholového poľa. Možno bolo rozšírenie dokonca príliš ambiciózne, jeho popísanie a definovanie trvalo príliš dlho, programátorom sa nechcelo dlho čakať, takže nVidia a 3DLabs nakoniec navrhli svoju vlastnú verziu, ktorá aspoň umožňovala efektívne vykreslenie na textúru. bez globálneho prístupu v riešení ATI. Trvalo niekoľko rokov, kým bolo možné vidieť výsledok všetkého tohto úsilia - v podobe rozšírenia s názvom framebuffer_object, ktoré poskytuje základné funkcie, ktoré sa objavili v DirectX 9!

V roku 2005 teda OpenGL dokázala dobehnúť Microsoft API vydané o tri roky skôr. Všetci hlavní hráči (ATI, nVidia, 3Dlabs a vývojári softvéru) sa zhodli, že to nemôže pokračovať, alebo že OpenGL postupne zmizne zo scény a skôr či neskôr bude zaslaná do zabudnutia. V tejto súvislosti spoločnosť ARB odovzdala opraty spoločnosti Khronos v roku 2006 a táto skupina sa stala zodpovednou za budúcnosť OpenGL. ATI a nVidia sa zaviazali, že sa povznesú nad svoje vlastné ambície a konkurenciu a budú účinne spolupracovať na tom, aby bol OpenGL konečne hodný 21. storočia. Vývojári boli tiež veľmi nadšení, pretože skupina Khronos sa ukázala ako veľmi efektívna pri práci na OpenGL ES, 3D API pre mobilné zariadenia.

Skupina Khronos veľmi rýchlo začala odhaľovať záhadu budúcnosti OpenGL. Opäť bol v pláne redizajn API v dvoch fázach. Prvá verzia, Longs Peak, by mala poskytnúť modelu R300 / NV30 úroveň funkčnosti na rovnakej úrovni ako Shader Model 2, ako aj nový, flexibilnejší programovací model. Ukázalo sa, že to bolo niečo ako OpenGL 2.0 Pure, ktorý spoločnosť 3DLabs navrhla o niekoľko rokov skôr, pretože skupina Khronos plánovala odstrániť staršie funkcie API a zamerať sa na malý počet moderných funkcií. Sada dostala názov OpenGL Lean and Mean. Druhou verziou s kódovým označením Mount Evans bola aktualizácia API, popri opravovaní všetkých zistených chýb, na úroveň funkcií R600 / G80 (Shader Model 4). Plán rozvoja bol veľmi tvrdý a Mount Evans sa objavil necelých šesť mesiacov po Longs Peak. Členovia skupiny Khronos si však boli istí svojimi schopnosťami.

Od ARB došlo k ďalšej zmene: skupina Khronos sa rozhodla pracovať otvorenejšie. Všetky nové informácie boli zverejnené na webových stránkach OpenGL a informovali vývojárov o novom API, aby mohli získať skorý dojem o jeho práci. Všetko šlo celkom dobre až do konca roku 2007. Hoci sa finálna špecifikácia Longs Peak očakávala v septembri, skupina Khronos oznámila, že kvôli problémom sa oneskorí - bez bližších podrobností. Rozhodnutie pracovať otvorenejšie, ktoré bolo urobené pred niekoľkými mesiacmi, bolo zabudnuté a skupina Khronos pokračovala vo svojej práci v informačnom vákuu. Neboli žiadne správy - v skutočnosti neexistovali žiadne informácie o pokroku v novom API.

Vystavenie

O OpenGL 3 nebolo nič počuť až do augusta 2008, keď sa konala konferencia SIGGRAPH. Mnohí čakali milé prekvapenie, ale správa od Khronosu sa pre nadšencov OpenGL ukázala ako sklamanie. API sa oneskorilo nielen asi rok, ale okrem iného sa na väčšinu nových aspektov Longs Peak úplne zabudlo. Po fiasku OpenGL 2.0, ktoré sa v skutočnosti stalo OpenGL 1.6 s iným názvom, OpenGL 3.0 začal vyzerať o niečo viac ako 2.2. Nepríjemné prekvapenie spojené s nedostatkom správ niekoľko mesiacov viedlo k veľmi agresívnej reakcii na kroky skupiny Khronos na všetkých fórach. Pretože bolo treba nejako zareagovať, Khronos odpovedal na oficiálnom fóre OpenGL prostredníctvom Bartholda Lichtenbelta z nVidia. On podrobná odpoveď aspoň osvetliť to, čo sa v skupine dialo. Dozvedeli sme sa napríklad, že v niektorých bodoch implementácie plánu nebolo rozhodnutie prijaté včas, a zároveň mnohí verili, že je nevyhnutné urgentne pridať podporu OpenGL pre najnovšie GPU. Preto bol plán zmenený s cieľom rozšíriť OpenGL 2 a pridať funkcionalitu Direct3D 10.

Aj po zohľadnení vyššie uvedených argumentov je možné skupine Khronos vyčítať, že nie je schopná včas oznámiť krízovú situáciu, a radšej o nej mlčať. Pretože to isté sa stalo pred šiestimi rokmi s OpenGL 2.0, nevzbudzuje to optimizmus do budúcnosti. Po dvoch sľuboch o prepísaní API - obe zlyhali - ako môžete veriť v budúcnosť OpenGL? Napokon, komentár Johna Carmacka na poslednom QuakeCone nie je nijakou úľavou. Keď sa ho pýtali na stav OpenGL 3, John bol ešte menej politicky korektný ako Lichtenbert.

Podľa Carmacka zlyhanie OpenGL 3, na rozdiel od všeobecného presvedčenia, pramení zo zlyhania niektorých vývojárov CAD / CAM, ktorí nebrali dobre Longs Peak. Báli sa problémov s kompatibilitou a ich aplikácií kvôli zmiznutiu niektorých starých funkcií. Túto verziu taktne potvrdil Lichtenbert: „Počas fázy návrhu Longs Peak sme dospeli k nezhode ohľadne funkcií, ktoré by mali byť z API odstránené ... Nezhoda bola spôsobená rôznymi potrebami trhu ... Zistili sme, že nemôžeme ponúknuť jedno API pre všetkých ...“

Takže nakoniec nebol OpenGL 3 ničím iným ako ďalšou aktualizáciou. API sa skutočne nezmenilo. Spoločnosť Khronos jednoducho opísala niektoré funkcie ako zastarané a poskytla tiež kontext, v ktorom by funkcie spôsobili chyby. To je oveľa menej, ako sme sľúbili (vývojári ovládačov budú musieť tieto funkcie stále podporovať), ale stále ide o krok vpred, pretože vývojári sa môžu pripravovať na budúce vydania, ktoré môžu konečne priniesť pravý režim Lean and Mean. OpenGL 3 taktiež predstavuje koncept profilov. Momentálne existuje iba jeden profil, ale podľa plánu sa vytvoria profily napríklad pre hry a pre CAD a každý profil bude podporovať rôzne polia funkcií.

Okrem toho je sada funkcií ponúkaná v OpenGL 3 veľmi podobná skupine ponúkanej v Direct3D 10, s výnimkou Geometry Shaders a Geometry Instancing, ktoré sa do API pridávajú ako rozšírenia. Podporované sú však aj niektoré funkcie Direct3D 10.1, ako napríklad režimy nezávislého miešania pre MRT.

S vydaním Direct3D 10 sa Microsoftu podarilo vytvoriť najrozsiahlejšiu verziu svojho API od vzniku. Všetky tieto roky interoperability samozrejme výrazne obmedzili možnosti vývoja API, takže cieľom bolo vytvoriť základ pre budúci vývoj. Nové API samozrejme dostalo zmiešané recenzie od hráčov aj vývojárov.

Microsoftu je čo vyčítať. Po toľkej chvále na svoje API niekoľko rokov pred vydaním viedlo DirectX 10 k sklamaniu, keď si hráči uvedomili, že v praxi to vlastne nič nezmenilo. Keď k tomu pridáme skutočnosť, že nové API bolo vyvinuté výhradne pre systém Vista, negatívny sentiment voči tomu, čo sa označovalo ako malá revolúcia, je pochopiteľný. Pokiaľ ide o vývojárov, veci sa ukázali byť komplikovanejšie. Prepojením Direct3D 10 a Vista spoločnosť Microsoft drasticky obmedzila počet počítačov, ktoré pracujú s novým API.

Navyše - a to nie je žiadnym tajomstvom - v posledných rokoch stratil počítač svoju úlohu hernej platformy vydaním konzol novej generácie, na ktoré prešlo niekoľko významných vývojárov z počítačov. id Software, Epic a Lionhead teraz pracujú na multiplatformových projektoch, ak nevyvíjajú hry výhradne pre konzoly. Pretože oba HD set-top boxy na trhu používajú GPU DirectX 9, vývojári majú všetku motiváciu držať sa predchádzajúceho rozhrania Microsoft API.

Prečo teraz hovoríme o Direct3D 11? Najskôr preto, že Microsoft konečne zdvihol závoj nad vlastným API. Po druhé, pretože stále čelíme udalosti, ktorá nám umožní získať predstavu o tom, čo môžeme od hardvéru očakávať v budúcom roku. Okrem toho existuje veľká šanca, že sa Direct3D 11 stane dôležitejšou stránkou v histórii tohto API ako verzia 10. Ak bola Direct3D 10 úplne prepracovanou verziou so všetkými rizikami, má Microsoft medzi verziami 10 a 11 dostatok medzery na to, aby všetko napravil. problémy spojené s prvým veľkým prepracovaním API. Direct3D 11 preto možno označiť za veľkú aktualizáciu, aj keď nie revolučnú. Nové API je postavené na rovnakých princípoch ako Direct3D 10 a je spätne kompatibilné s hardvérom predchádzajúcej generácie. Nakoniec bude API k dispozícii nielen pre Windows 7, ale aj pre Vista. Microsoft opravil najväčšie problémy s verziou 10 a medzi vývojármi sa objavujú neoficiálne fámy, že v budúcich hrách vynechajú Direct3D 10 a prejdú priamo na verziu 11.

To má zmysel z niekoľkých dôvodov. Fáza vývoja hry zvyčajne trvá dva až štyri roky. Preto v čase, keď bude vydaná dnešná vyvíjaná hra, sa Direct3D 11 už etablovala vo flotile počítačov, pretože API bude fungovať na všetkých počítačoch so systémom Windows 7, ako aj na drvivej väčšine počítačov so systémom Vista. Okrem toho je veľmi pravdepodobné, že bez ohľadu na dátum vydania budú budúce konzoly používať GPU kompatibilné s Direct3D 11 (alebo podobným produktom, napríklad Xenos v konzole Xbox 360, ktorá je doplnkom k DirectX 9). Zacielenie na taký súbor funkcií preto vývojárom umožní zachytiť trh s konzolami novej generácie. Ale nie sme tu na to, aby sme študovali trh. Čo dáva nové API z technického hľadiska?

Viacvláknové vykreslenie

Viacvláknové vykreslenie? Nepoužívame však už niekoľko rokov viacjadrové procesory a vývojári sa nenaučili, ako s nimi pracovať? Čo by mohlo byť nové v procesoroch s viacvláknovým vykresľovaním Direct3D 11? Niektorí z vás budú prekvapení, ale moderné motory stále používajú na vykreslenie iba jedno vlákno. Ostatné streamy sa používajú na zvuk, dekompresiu zdrojov, fyziku atď. Ale vykresľovanie je náročné na procesor, tak prečo to nerozdeliť medzi viac vlákien? Existuje niekoľko dôvodov, niektoré súvisia s tým, ako funguje GPU, a ďalšie súvisia s 3D API. Preto sa spoločnosť Microsoft rozhodla opraviť softvérové \u200b\u200bproblémy a tiež pomôcť vyriešiť tie hardvérové.

Na prvý pohľad vyzerá paralelizácia procesu vykresľovania atraktívne, ale ak sa pozriete bližšie, uvedomíte si, že existuje iba jeden GPU (aj keď je niekoľko GPU pripojených prostredníctvom SLI alebo CrossFire, ich účelom je vytvoriť ilúziu, že jeden, virtuálny GPU funguje), preto a existuje iba jeden príkazový buffer. Ak ten istý prostriedok používajú viaceré vlákna, technológia vzájomného vylúčenia (mutex) zabráni viacerým vláknam písať príkazy súčasne, aby si navzájom neprekážali. To znamená, že všetky výhody používania viacerých vlákien sú eliminované jednou kritickou časťou, ktorá robí kód konzistentným. Tento problém nedokáže vyriešiť žiadne API - dedí sa to zo spôsobu komunikácie CPU a GPU. Microsoft však ponúka API, ktoré by sa to mohlo pokúsiť obísť. Direct3D 11 predstavuje vyrovnávacie pamäte príkazov, ktoré je možné uložiť a použiť neskôr.

Kliknutím obrázok zväčšíte.

Preto každé vlákno má odložený kontext, kde sú príkazy zapísané do Zoznamu zobrazenia, ktorý je možné vložiť do hlavného vlákna spracovania. Je celkom pochopiteľné, že keď zoznam vyžaduje hlavné vlákno (príkaz „Spustiť“ na snímke „Viacvláknové podanie“ nižšie), musíte sa ubezpečiť, že vlákno je jeho vyplnenie hotové. Preto stále existuje synchronizácia, ale model vykonania aspoň umožňuje, aby sa niektoré vykresľovacie práce vykonávali paralelne, aj keď výslednú akceleráciu samozrejme nemožno považovať za ideálnu.

Ďalší problém s predchádzajúcimi verziami Direct3D súvisí s vytváraním prostriedkov, ako sú napríklad textúry. V aktuálnych verziách API (9 a 10) bolo potrebné vytvoriť prostriedky na vlákne vykreslenia. Vývojári tento problém vyriešili vytvorením vlákna, ktoré číta a dekomprimuje textúry z disku, a potom vyplní prostriedok (objekt Direct3D), ktorý bol vytvorený v hlavnom vlákne.

Ako však vidíte, väčšina pracovného zaťaženia je stále v hlavnom vlákne, ktoré je už preťažené. To neposkytuje optimálne vyváženie potrebné na rýchle vykonanie. Preto spoločnosť Microsoft pridala do rozhrania Direct3D 11 nové rozhranie: programátor môže vytvoriť jeden objekt „zariadenia“ na jeden prúd, ktorý je možné použiť na načítanie zdrojov. Synchronizácia funkcií objektu „Device“ je subtílnejšia ako v Direct3D 10 a oveľa ekonomickejšia z hľadiska zdrojov CPU.

Kliknutím obrázok zväčšíte.

Mozaikovanie

Hlavnou novou funkciou Direct3D 10 bol vznik shaderov geometrie, ktoré konečne umožnili GPU vytvárať alebo ničiť vrcholy. Úloha tohto bloku ale nie je vždy správne pochopená. Poskytuje nielen podporu masívnej geometrie, ale je tiež vhodnejšia na implementáciu flexibilnejších Point Sprites, Fur Shading alebo na výpočet siluety objektu pre volumetrické tieňové algoritmy. Nie je nič lepšie ako vlastný blok na vykonanie mozaikovania. Pôvodne sa plánovalo na Direct3D 10 (čo vysvetľuje prítomnosť bloku v zostave Radeon HD), ale vyzerá to tak, že Microsoft, ATI a nVidia nedokázali dosiahnuť dohodu včas, takže blok zmizol zo špecifikácií a vrátil sa iba s Direct3D 11. Preto je teselovanie novou veľkou funkciou Direct3D 11 - alebo aspoň ten, ktorý sa ľahšie predáva neodborníkom.

Kliknutím obrázok zväčšíte.

Na rozdiel od iných stupňov v procese, tieto fázy nepracujú s trojuholníkmi ako primitívmi, ale s opravami. Hull Shader prevezme kontrolné body pre patch na vstupe a potom definuje niektoré parametre Tesselatoru, napríklad TessFactor, ktorý ukazuje úroveň kvality teselace. Tesselator je blok s pevnými funkciami, takže programátor nemá žiadny vplyv na to, ako sa tessellation počíta. Blok odošle získané body do Domain Shader, ktorý na ne môže aplikovať operácie. Poviem vám príklad, ktorý vám pomôže lepšie pochopiť. Zoberme si príklad, ktorý od Matrox Parhelia prišiel s každou generáciou - mapovanie posunu.

Kliknutím obrázok zväčšíte.

Ako vstup do shadera vrcholov máme body prerušenia opráv. Programátor ich môže meniť, ako chce, pretože ich nie je toľko. Aby sme to zjednodušili, vzali sme veľmi hrubú verziu výslednej tabuľky. Transformované body sa potom odovzdajú nástroju Hull Shader, ktorý určuje, koľkokrát je potrebné rozdeliť každú rovinu opravy (napríklad ako funkcia veľkosti opravy v pixeloch displeja). Tesselator vykonáva mozaikovanie. To znamená, že vytvára geometriu, ktorá sa odosiela do shaderu domény. Blok posúva body vytvorené pre zodpovedajúci priestor (body vychádzajúce z Tesselatoru sú v priestore patchov) a vytvára klasické vrcholy, ktoré môže premiestniť ako funkcia textúry, to znamená vykonať mapovanie posunu.

Potenciál je obrovský. Vďaka mozaikovaniu môžete obísť normálnu mapu a implementovať úroveň detailov priamo na GPU, čo vám umožní používať veľmi podrobné modely (v moderných hrách niekoľko miliónov polygónov namiesto 10 000 alebo tak nejako) - aspoň teoreticky. V praxi teselovanie prináša určité problémy, ktoré bránia úplnému rozvoju tejto techniky. Dostane Direct3D 11 a kompatibilné karty úskalia a doručí funkčnú verziu? Je príliš skoro na to, aby ste niečo povedali, ale v každom prípade nie všetci boli presvedčení, že rovnaký softvér id pracuje na riešení rovnakého problému s geometriou pomocou úplne iného prístupu založeného na liatí lúčmi pomocou voxelov.

Vypočítajte shadery

Ako sme už uviedli v našom článok o CUDA Spoločnosť Microsoft nechce opustiť trh GPGPU, takže spoločnosť vytvorila svoj vlastný jazyk, aby GPU mohlo pracovať aj na iných úlohách, nielen na vykreslení pekných obrázkov. Hádaj čo? Model zvolený spoločnosťou Microsoft, ako napríklad OpenCL, je veľmi podobný modelu CUDA, čo potvrdzuje prísľub vízie spoločnosti nVidia. Výhoda oproti riešeniu nVidia spočíva v jej všestrannosti - Compute Shaders budú bežať na GPU nVidia a ATI, Intel Larrabee v budúcnosti a budú mať lepšiu integráciu Direct3D, aj keď už CUDA nejakú podporu má. Ale tejto téme sa nebudeme venovať veľa, aj keď si to zaslúži. Namiesto toho plánujeme za pár mesiacov poskytnúť samostatný článok o OpenCL a Compute Shaders.

Vylepšená kompresia textúry

Kompresia textúr DXTC, ktorá sa v DirectX 6 objavila pred desiatimi rokmi, sa rýchlo rozšírila na trh GPU a vývojári ju veľmi využívajú. Samozrejme, technológia vyvinutá spoločnosťou S3 Graphics bola efektívna a hardvérová réžia bola skromná, čo nepochybne vysvetľuje úspech. Teraz sa však potreby zmenili. DXTC nebol navrhnutý na kompresiu bežných máp a nezohľadňoval vykreslenie HDR. Preto bol cieľ Direct3D dvojaký: umožniť kompresiu HDR textúr a obmedziť „blokovosť“ tradičných režimov DXTC. Spoločnosť Microsoft za týmto účelom pridala dva nové režimy: BC6 pre textúry HDR a BC7 na zlepšenie kvality kompresie obrazu LDR.

Kliknutím obrázok zväčšíte.

Shader model 5

Microsoft sa zavedením Shader Model 5 snaží preložiť niekoľko princípov objektovo orientovaného programovania do shaderového jazyka HLSL. Na rozdiel od predchádzajúcich verzií, ktoré priniesli nové funkcie (dynamické vetvenie, podpora celých čísel atď.), Spočíva v tomto prípade cieľ uľahčiť prácu programátorov riešením spoločného problému v moderných herných enginoch: nárastu počtu shaderov v dôsledku pre veľký počet permutácií. Zoberme si konkrétny príklad: predstavte si, že motor pracuje s dvoma druhmi materiálov, plastom a kovom, a dvoma typmi osvetlenia: bodovým a rozptýleným svetlom (omni). Aby sme pokryli všetky prípady, musí programátor napísať štyri shadery:

renderPlasticSpot (): // vykreslenie plastu pomocou bodového svetla:

renderPlasticOmni (): // vykreslenie plastu pomocou všeobecného svetla:

renderMetalSpot (): // vykreslenie kovu pomocou bodového svetla ...

renderMetalOmni (): // vykreslenie kovu pomocou všeobecného svetla:

Príklad je veľmi jednoduchý, pretože existujú iba dva materiály a dva typy osvetlenia, ale v praxi ich môže byť niekoľko desiatok. Ak budete pokračovať rovnakým spôsobom, situácia sa môže rýchlo vymknúť spod kontroly. Získame obrovské množstvo duplicitného kódu a ak sa vyskytne nejaká chyba, je potrebné ju opraviť vo všetkých shaderoch. Na vyriešenie tohto problému používajú programátori takzvaný uber-shader, ktorý spája všetky kombinácie dohromady.

Svetlo a materiál sú rozhrania a kód je obsiahnutý v odvodených triedach OmniLight a SpotLight, PlasticMaterial a MetalMaterial. Preto je kód úplne umiestnený na jednom mieste, je ľahšie vykonávať zmeny. Čitateľnosť zároveň neutrpí kvôli organizácii kódu, ktorá pripomína princíp virtuálnych funkcií v objektovo orientovaných jazykoch. Túto funkciu určite privítajú programátori, aj keď je nepravdepodobné, že by hráčom niečo dala.

Iné

Ako si dokážete predstaviť, novým funkciám Direct3D 11 sme sa venovali iba krátko a Microsoft zatiaľ nezverejnil všetky podrobnosti. Medzi témy, ktoré sme nespomenuli, patrí zvýšenie maximálnej veľkosti textúry zo 4K x 4K na 16K x 16K, ako aj schopnosť obmedziť počet mip kariet načítaných do VRAM. Je tiež možné zmeniť hodnotu hĺbky pixelov bez deaktivácie funkcií, ako je skorá kontrola Z, podpora premenných s pohyblivou rádovou čiarkou s dvojitou presnosťou, zápis rozptylovej pamäte atď.

Záver

Od OpenGL 3 sme čakali veľa a ako môžete zistiť z článku, boli sme sklamaní: jednak samotným API (z ktorého zmizli sľúbené funkcie), jednak jeho vývojom (ročné oneskorenie a nedostatok informácií od skupiny Khronos). S novou verziou OpenGL sotva dokázal dobehnúť Direct3D 10, zatiaľ čo Microsoft zároveň zverejnil prvé podrobnosti o verzii 11 svojho API.

Od Microsoftu nemožno čakať nič prevratné, na rozdiel od OpenGL však Direct3D už pred dvoma rokmi prešiel kompletným redizajnom svojej architektúry. Samozrejme, nie všetko prebehlo hladko, ale dnes môže spoločnosť Microsoft zúročiť snahy o prebudovanie svojho API na silnom novom základe.

Redmond nepochybne hľadí do budúcnosti, a pokiaľ ide o OpenGL, vyzerá to, že Khronos si vystačil s podporou súčasnej generácie GPU. Dúfajme, že sa mýlime a vývoj OpenGL 3 pôjde oveľa rýchlejšie, pretože je to jediné API dostupné pre vývoj viacerých platforiem. Príliš veľa prekrytí však otriaslo našou vierou vo vývoj tohto API.