Khronos Vulkan (glNext) - info a vše okolo

[Krteq]

Ono prave jde o to, ze to musí fungovat s veskyrym HW, takze uplne low to proste byt nemůže. Anand treba psal

Mantle goes as low as is reasonably possible, with minimal levels of abstraction between the code and the hardware. Mantle is for all practical purposes an API for doing bare metal programming to GCN.

Kazdopadne pokud to ma byt univerzalni, tak proste není mozny jit az tak low, tedy psat to primo na telo.

Však píše že tam nějaká ta mezivrstva je, minimálně tam musí být driver

[Hladis]

No a k tomu se dostavame Není to uplne low-level jako byl třeba Glide. Ten se musel updatovat dle HW a nekdy to dělalo neplechu i mezi Voodoo kartami navzajem. Zde to je vice low-level nez starsi OGL nebo DX, ale stále to není tak low, viz. nou. Logicky nemůže, protože to není na konkretni HW.

[Krteq]

Co máš porád s tím psaním přímo na HW (bare metal)? I Glide potřeboval driver a knihovny, tzn. mezivrstvu.

Ani Mantle nebyl přímo vázán na konkrétní HW, jádro samotné je stejné. Mante obsahoval jen některé funkce/optimalizace vzužívající GCN, které Khronos odstranil.

[nou]

Hej Khronos odstranil napriklad multi-queue pre jedno GPU. Podla prezentacii bolo Mantle definovalo viacero queue pre jedno GPU ako je vidno tu http://imgur.com/AHajVkA Teda Graphics, DMA, Compute. Vulkan pokial viem definuje iba jednu queue per device teda nie je az tak specificky.

Hladis: programoval si niekedy pre DX/OGL alebo aj vseobecne v nejakom jazyku? lebo sa mi zda ze ma len teoreticky prehlad ale nevies ako to realne funguje.

[DOC_ZENITH]

Co máš porád s tím psaním přímo na HW (bare metal)? I Glide potřeboval driver a knihovny, tzn. mezivrstvu.

Později ano, ze začátku ne. Early glide aplikace šahaly rovnou na kartu bez ohledu na driver, některé i bez ohledu na OS, třeba GTA1 byla 16-bit aplikace co dovedla používat glide pod dosem bejz jakéhokoliv driveru. Nebo i některé novější programy, třeba unreal engine 1 když jsi spustil win v nouzáku tzn nenačetly se žádné drivery ale v systému byla stále glide 2x a ve hře jsi měl glide tak ti normálně naběhla s akcelerací.

Jednim dechem ale dodam, že sama 3DFX toho později litovala a fungovalo to jen na voodoo1/2. Už rush s tim měla problémy a pozdější karty\jely vše přes glide knihovny driveru a nativní to metal glide už tam nebyl vůbec, byl tam jen přes glide2x a 3x knihovny driveru. Tzn na voodoo3+banshee (a novějších) už neběžely některé early glide 16 hry. Nejvíc za to asi mohl přechod k unifikované paměti u 3DFX. Early glide karty totiž měly neunifikovanou paměť s pevně vyhrazenými bloky pro framebuffer a textury, v driverech pro voodoo2 se dokonce dalo aktivovat omezení na 2MB blok aby se i paměť chovala jak na voodoo1 pro legacy hry). Výhodou toho bylo že v SLI se oblast paměti pro framamebuffer sčítala, pro textury ale ne.

Inu mantle, ono GCN only mantle, pokud by dále pokračovalo ve vývoji, by za pár let potkalk stejnej osud v momentě kdy AMD od GCN odejde. Tak karty novejch architektur už pravděpodobně early mantle hry pod mantle nerozjedou.

AMd si podle mě s mantle myslela, že když už má GCN v konzolích že vývojáři budou portovat ony optimalizace odtamtud rovnou do mantle, protože by byly víceméně kompatibilní, CPU jsou také x86, atd, atd. Ale to se jaksi dít nezačalo a asi ani nezačne.

[Hladis]

Hladis: programoval si niekedy pre DX/OGL alebo aj vseobecne v nejakom jazyku? lebo sa mi zda ze ma len teoreticky prehlad ale nevies ako to realne funguje.

Dost amatersky a bez radce se neobejdu. Veskrze dost obecne. Není to muj obor a nikdy nebyl, takze to je jen takova amaterina. Ale třeba wrapper pro Skyrim jsem byl schopen trochu pochopit a upravovat si nektery efekty a nejak si s tim vyhrat. Kdysi daaaavno jsem byl schopen udelat i funkcni driver pro Voodoo Rush a to se dostavam.....

Později ano, ze začátku ne. Early glide aplikace šahaly rovnou na kartu bez ohledu na driver, některé i bez ohledu na OS,Jednim dechem ale dodam, že sama 3DFX toho později litovala a fungovalo to jen na voodoo1/2. Už rush s tim měla problémy a pozdější karty\jely vše přes glide knihovny driveru a nativní to metal glide už tam nebyl vůbec, byl tam jen přes glide2x a 3x knihovny driveru. Tzn na voodoo3 už neběžely některé early glide 16 hry.

Presne tak.

[nou]

Tak DOS aplikacie mali ten "driver" priamo v sebe. Driver je v tomto pripade kod ktory priamo zapisuje do nejakych registrov/pamete na HW. Tym ze bol priamo v aplikacii sa nemohol zmenit. Ved na novu kartu je treba novy driver.

Toto v Mantle/Vulkan nehrozi. Podstatou tychto novych API je to ze na CPU strane sa vytvory command buffer. Teda popis co ma GPU robit. Toto sa da robit pekne multithreadovo. Nasledne sa tento command buffer (prakticky kus pamete) nakopiruje niekam do GPU pamete. Nasledne sa spusti program na GPU ktory zacne tento command buffer interpretovat. GPU je dnes totiz uz plnohodnotny CPU ktory vie vykonavat komplexne programy. Taky program potom moze interpretovat command buffer, spustat dalsie podprogrami a teda vobec nezatazovat CPU. Toto je cielom Vulkan/DX12 aby potom co nahrajte GPU datami, a potom staci len GPU povedat: "zacni strotit a povedz mi ked skoncis".

V systeme je stale pritomny Mantle/Vulkan driver ktory riesi naozaj low level veci ako nahratie toho programu na kartu ktory bude na GPU interpretovat command buffer, na aku adresu sa ma nahrat ten command buffer ci preklad SPIR-V do instrukcii konkretneho GPU. Signalizacia dokoncenia vykonavana cez nejake IRQ, DMA prenosy a podobne. Az toto je naozaj low level a pisanie on metal.

Podstatou pisania on metal pri Vulkan bude skumanie ake SPIR treba podhodit driveru aby vyprodukoval co najoptimalnejsi IL. Popripade ak budu extension so specifickymi instrukciami na konkretne GPU. To potom je bare metal.

[Krteq]

Tak DOS aplikacie mali ten "driver" priamo v sebe. Driver je v tomto pripade kod ktory priamo zapisuje do nejakych registrov/pamete na HW. Tym ze bol priamo v aplikacii sa nemohol zmenit. Ved na novu kartu je treba novy driver.

Přesně

Ohledně SPIR-V, začíná se mi to líbit čím dál tím víc

[Thorton]

Inu mantle, ono GCN only mantle, pokud by dále pokračovalo ve vývoji, by za pár let potkalk stejnej osud v momentě kdy AMD od GCN odejde. Tak karty novejch architektur už pravděpodobně early mantle hry pod mantle nerozjedou.

AMd si podle mě s mantle myslela, že když už má GCN v konzolích že vývojáři budou portovat ony optimalizace odtamtud rovnou do mantle, protože by byly víceméně kompatibilní, CPU jsou také x86, atd, atd. Ale to se jaksi dít nezačalo a asi ani nezačne.

Jak někdo ještě dnes může plácat takové nesmysly, když už při uvedení v roce 2013 AMD tvrdilo, že Mantle je připraveno na budoucnost a není striktně vázáno na GCN.
http://cdn4.wccftech.com/wp-content/upl ... tled11.jpg

[DOC_ZENITH]

AMD o mantle tvrdilo mnoho věcí které nakonec nikdy nebudou. Dokud neuvidim mantle běžet na non GCN kartě bude to GCN only. Dokud jej neuvidim na jiné platformě bude win only, je fuk co AMD řekně, to samé že je open, kde si můžu stahnout devkity a zdrojáky, a to jste je slibovali už x měsíců dozadu.... nejsou důležité řeči ale skutky. Jedna z prvních věcí co se změnilo mezi Mantle a Vulkenem bylo právě to odstranění na svázání s GCN.

[Thorton]

AMD o mantle tvrdilo mnoho věcí které nakonec nikdy nebudou.

No, teď když je Mantle 1.0 součástí API Vulkan, tak už mnoho věcí nebude stejných jak AMD původně plánovalo. Ale nic to nemění na tom, že kód poskytlo Khronosu a z jejich spolupráce vzniklo otevřené API Vulkan.

Dokud neuvidim mantle běžet na non GCN kartě bude to GCN only. Dokud jej neuvidim na jiné platformě bude win only, je fuk co AMD řekně, to samé že je open, kde si můžu stahnout devkity a zdrojáky, a to jste je slibovali už x měsíců dozadu.... nejsou důležité řeči ale skutky. Jedna z prvních věcí co se změnilo mezi Mantle a Vulkenem bylo právě to odstranění na svázání s GCN.

Chceš zdrojáky API Mantle, tak se zaregistruj jako ostatní vývojáři, kteří to udělali už před více než rokem. Tak dlouho si opravdu čekat nemusel.

Chceš vidět jak jede hra pod API Mantle/Vulkan na non-GCN architektuře, tak se podívej:
https://www.youtube.com/watch?v=0Hth4u65zfc
Místo toho, aby jsi byl rád, že proprietární DX12 bude mít konkurenci, tak spíš hledáš problémy, tam kde nejsou a jen prudíš a kopeš okolo.

[DOC_ZENITH]

Já je nehledám, jsem za Vulkan rád. Ale Neni to mantle a mantle je dead protože bylo uzavřené a pro konkrétní HW, nevim proč se o tom stále hodláš hádat. Tyto nová API si z mantle hodně vzala, ale již nebudou vyvíjená pod taktovkou AMD.

[Hladis]

Chceš vidět jak jede hra pod API Mantle/Vulkan na non-GCN architektuře, tak se podívej

To samozrejme nebezi pod Mantle. Zadnym okecavanim nikdo nezmeni, ze Mantle je pouze GCN a dodnes není ani open, ani na jiny systém. Vulkan není Mantle. Vulkan je pouze na bazi Mantle. Jsou to dve ruzny API.

Místo toho, aby jsi byl rád........

Kde řekl ze není rad za tyhle API ? Koukam dva prispevky a hned najezd na flame.

[Thorton]

Já je nehledám, jsem za Vulkan rád. Ale Neni to mantle a mantle je dead protože bylo uzavřené a pro konkrétní HW, nevim proč se o tom stále hodláš hádat. Tyto nová API si z mantle hodně vzala, ale již nebudou vyvíjená pod taktovkou AMD.

Mantle bylo, tak straaaaáááášně moc uzavřené pro konkrétní HW (GCN), že Khronos/Valve bylo schopno ho během pár měsíců přepsat, předělat hru DOTA2 a ještě napsat driver pro Intel grafiky. Z těchto 3 věcí vyplývá, že ta vázanost API Mantle na GCN nebyla tak velká, jak někteří tvrdili a stále se snaží tvrdit.
A znova opakuji: AMD otevřela Mantle tím, že ho dala k dispozici Khronosu.

[Thorton]

Koukam dva prispevky a hned najezd na flame.

Rozhodně nechci vyvolávat flame, ale opravdu nevím na co a proč si DOC_ZENIT v tomto na AMD a jak naložilo s Mantle stěžuje.
Poskytli ho Khronosu a na jeho základě vznikl Vulkan. Nic víc, nic míň.

[flyer]

http://diit.cz/clanek/khronos-podekoval-amd-za-mantle


//Krteq - promaz OT. Proprietární technologie tu mají vlastní vlákna.

[Raikkonen]

Já to chápu tak, že Vulkan = Mantle 2.0. Vulkan má v Mantle (1.0) základ, ale zároveň už některé části kódu jsou nahrazeny a vývoj ještě dále probíhá a bude i v budoucnu. Tedy Mantle a Vulkan nelze brát jako jedno a totéž, je to prostě předchůdce a následovník. Teprve Vulkan se vlastně stane tím, co AMD původně plánovalo s Mantle, tedy univerzálnost a otevřenost. Původní Mantle se prakticky nedostalo přes beta fázi, zůstalo svázané s GCN a nebylo vydáno finální otevřené SDK. S Vulkanem se tedy Mantle stává mrtvým, maximálně se ještě dočkáme pár rozdělaných her a konec. IMHO AMD takto udělala nejlépe, jak mohla. Jak Mantle zpočátku vypadalo hodně zajímavě, tak mu dost vítr z plachet vzala nvidia se svými optimalizovanými drivery a Microsoft s oznámením DX12. Sice her s podporou Mantle vzniklo celkem dost, ale z nich snad žádná neudělala pořádnou díru do světa, aby Mantle pořádně prorazilo. Pravděpodobně by tedy s vydáním DX12 přestal být Mantle absolutně zajímavý a AMD by ani nebyla schopná poskytovat takovou podporu. Předáním dokumentace Khronosu tak zajistila budoucnost a uvidíme, jestli se Vulkan dokáže s DX12 popasovat, nebo DX zůstane nadále absolutně dominantní...

[DOC_ZENITH]

Po technické stránce bude Vulkan lepší volbou, + za nim stojí a budou jej podporovat všichni důležití partneři/ výrobci GPU světa.

Problém je v microsoftu a jeho tlačení DX. DX technicky vzato nemá žádné výhody, nic, ale marketing a peněženka MS možná bude stačit na to aby mu zajistila dominanaci.

Co se mantle týče, tak v kombinaci s Hawaiii ve vybranejch hrách předvedlo dobré věci. Nepřineslo moc onen slibovanej multithread do renderingu, ale nanášení geometrie a obedně CPU část renderingu, tam klesl overhead na polovic což byl obrovskej posun a učinil spousu her naprosto plynulejch třeba an I3 a hratelnejch na Core2 či K10. Jedinym špatnym tahem mantle marketingu bylo možná na jaké hry se soustředili. Většinou to byly hry kde CPU limit nebyl devastující. Tzn třeba Battlefield 4, kde NV se svy driverem dosahla obdobného stavu že CPU limitace prostě ihmo neni. Kdyby mantle netlačili do her co jsou nejvíce populární ale kde se tolik neprojeví, ale místo toho do her kde by se projevil hodně (CPU limited MMO a RTS hry).

[Krteq]

Nepřineslo moc onen slibovanej multithread do renderingu, ale nanášení geometrie a obedně CPU část renderingu, tam klesl overhead na polovic což byl obrovskej posun a učinil spousu her naprosto plynulejch třeba an I3 a hratelnejch na Core2 či K10.

Ba naopak, MTR je v Mantle na vynikající úrovni hlavně díky přeložení různých calls (třeba shadow rendering atd. - viz. prezentace Unity 5 na GDC) mimo hlavní rendering vlákno. Na stejné úrovni je MTR i v DX12 i Vulkan.

A co máš porád s tou geometrií? Můžeš to pls nějak vysvětlit? Nikde totiž není ani zmínka o tom, že by tahle nová API řešila "geometrii" principiálně jinak než ta předchozí. A co myslíš pod pojmem CPU část renderingu?

[Hladis]

S geometrii si to DOC porad plete. On to tak nazyva, ikdyz mu to uz bylo vysvetlovano Problém neni geometrie. Problém je počet objektu a textur etc... na nich. Cim vice, tim vic volani. Například muzu mit krasny barak, geometricky hodne slozity a detailni jako jeden mesh a problém bude, kdyz bych na kazdou kravinu toho baraku hodil samostatnou texturu. Tim zvysim počet volani. Zredukuju to třeba tim, ze na barak použiju jen jednu velkou texturu, která se aplikuje na ruzny mista toho baraku. Placnu, mrsknu na to 16K texturu místo hromady 1K textur. Takhle muzu nasekat několik stejnych baraku a bude to mit maly počet volani (placnu 10 baraku, 10 volani), ikdyz jich bude na scene vice. Pruser bude, pokud ten barak bude slozen z vice meshu s mnoha texturami a hodim je na scenu ve vetsim poctu s tim, ze každý bude jiny........ to stoupa počet volani strme nahoru (10 baraku, 100 volani). To neni o geometrii, ale prave poctu objektu a jejich diverzifikaci.