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

Libovolný výrobce, technologie, informace, rady, výběr, ovladače.

Moderátoři: morke, Walker1134, PKBO, Hladis

Odpovědět
Krteq
Čestný člen
Čestný člen
Registrován: 22. dub 2005
Bydliště: Brno

Re: Khronos Vulkan (glNext): Mantle Based Low-Level Graphics

Příspěvek od Krteq »

Hladis píše: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.
K tomu snad slouží batches a instancing už od DX 9 :)

S DX 10 přibyly geometry shadery + další optimalizace.

Tady někdo snad ani netuší o co vlastně jde. :mrgreen:
Hladis
Moderátor
Moderátor
Uživatelský avatar
Registrován: 24. čer 2004
Bydliště: Varnsdorf - Athens

Re: Khronos Vulkan (glNext): Mantle Based Low-Level Graphics

Příspěvek od Hladis »

Ano, existuje batching, coz je prave optimalizace poctu volani tim, ze se třeba udela jeden velky mesh místo hromady malych a pokud se vyskytuji na scene několikrát, tak produkuji jen maly počet volani. To jsem i napsal. Ale ne všechno se takhle da delat a zalezi prave na enginu co jde a nejde batchovat a na tom jaky je tvurce prase. Dále i na tom, jak moc se autori rozmachnou a samozrejme open world hra s velkym a slozitym prostředí bude produkovat vice volani nez nejaka jednoducha koridorovka.

S tou geometrii uz to DOCovi rikal nou a myslim ze i další, ale on to ma porad nejak v pameti a ne se toho zbavit.
DOC_ZENITH
Středně pokročilý
Středně pokročilý
Uživatelský avatar
Registrován: 08. kvě 2010
Bydliště: Praha

Re: Khronos Vulkan (glNext): Mantle Based Low-Level Graphics

Příspěvek od DOC_ZENITH »

Hladis píše: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.
Já tomu Řikam geometrie protože to tak pořád je, ano máme zde optimalizací a jiné formy jak jí nanáštm ale... většina CPU limitu při renderingu byla vždy vázána na počet renderovanejch trojúhleníků. Tzn geometrie. Je tam tuna postav či oběktů s mnoha polygony = CPU nároky jdou do stropu a stanou se bottleneckem mnohem dříve než prostupnost GPU co se týče trianglerate (vyjímkou je tesealce protže to je geometrie co se vytváří až v GPU, ale bohužel s ní Engine nemůže počítat, je to defakto mrtvá geometrie jen pro okrasu/lepší vizuál). Jestli se nanášej tim či tim, jestli jen tam narvu historickou TnL nebo vertes shaderem nebo identické půjdou do meshe aby to bylo rychlejší, fajn. Takovej Cry engine 3 toho nasense mnohem více než třeba Unreal engine 2 než se zahltí. Ale... stále nakonec dojdem na CPU limit oné geometrie. Tohle myslim když řikam "geometrie" beru to prostě obecně.

Mantle tohle srazilo o +- 50%, ale že by to zmultithreadovalo se říci nedá.

Proto jsem se tehdy tak zhádal se zastánci mantle když jsem zkoušel Starswarm na 7970 + mantle na toms vém opteronu a prostě to neškálovalo. A oni na mě, máš tam málo drawcalls, kdyby jsi tam měl 1000x více drawcalls dopadlo by mantle tam lépe než Nvidie pod DX na mé hlavní I7, a pod... to je sice hezký ale už tak jsem měl pod 20fps takže ještě více drawcalls abych tam měl 5 fps a připsal si ňáké vítězství... eh....
Krteq
Čestný člen
Čestný člen
Registrován: 22. dub 2005
Bydliště: Brno

Re: Khronos Vulkan (glNext): Mantle Based Low-Level Graphics

Příspěvek od Krteq »

DOC_ZENITH píše:Já tomu Řikam geometrie protože to tak pořád je, ano máme zde optimalizací a jiné formy jak jí nanáštm ale... většina CPU limitu při renderingu byla vždy vázána na počet renderovanejch trojúhleníků. Tzn geometrie. Je tam tuna postav či oběktů s mnoha polygony = CPU nároky jdou do stropu a stanou se bottleneckem mnohem dříve než prostupnost GPU co se týče trianglerate (vyjímkou je tesealce protže to je geometrie co se vytváří až v GPU, ale bohužel s ní Engine nemůže počítat, je to defakto mrtvá geometrie jen pro okrasu/lepší vizuál). Jestli se nanášej tim či tim, jestli jen tam narvu historickou TnL nebo vertes shaderem nebo identické půjdou do meshe aby to bylo rychlejší, fajn. Takovej Cry engine 3 toho nasense mnohem více než třeba Unreal engine 2 než se zahltí. Ale... stále nakonec dojdem na CPU limit oné geometrie.
Ty jsi s tím triangle rate bottleneckem očividně zamrzl někde v DX9.

S DX10 a unifikovanými shadery přišel tzv. Geometry shader, který převzal výpočet vertexů z CPU. Teselace v DX11 využívá právě GS + Hull a Domain shader a celý proces jde mimo CPU.

Vulkan/Mantle/DX12 jdou na to uplně stejně, jen se liší přístup k "resourcům".

Ale ty jsi stále nepochopil, že jsi ten Star Swarm testoval blbě Obrázek
DOC_ZENITH
Středně pokročilý
Středně pokročilý
Uživatelský avatar
Registrován: 08. kvě 2010
Bydliště: Praha

Re: Khronos Vulkan (glNext): Mantle Based Low-Level Graphics

Příspěvek od DOC_ZENITH »

Tak to nejsou vertexy ale co? Nasvětlení? Animace? Co způsobuje že ten samej CPU limit tam stále dřepí a je fukl jestli je použito DX9 nebo 11 běží to +- stejně. A přítomnost mantle framerate v takto limitované scéně zvedne na zhruba dvojnásobek, ale udělá to jak na I3 tak na I7 a s rostoucim počtem threadů/jader obecně výkon neroste.

A stále nechápu co jsme ve Starswarmu dle tebe udělal špatně. Byl jsem nednopznačně CPU limited s mizernym framerate a žádné multithread škálování se nekonalo.
Hladis
Moderátor
Moderátor
Uživatelský avatar
Registrován: 24. čer 2004
Bydliště: Varnsdorf - Athens

Re: Khronos Vulkan (glNext): Mantle Based Low-Level Graphics

Příspěvek od Hladis »

DOC:
Ale. Muzu udelat superslozity objekt z mnoha trojuhelniku, hodim na to jednu texturu a nic me limitovat nebude, jen vykon GPU s minimem volani. To bych tech objektu musel nasekat třeba 100 a každý by musel byt jiny, nebyt staticky a byt slozen z hromady textur a vrhat stiny, etc... bez moznosti batchovani, ale to uz neni o poctu trojuhelniku, ale o poctu ruznych objektu na scene. Klidne muze byt jeden velky objekt ze stejného poctu trojuhelniku jako tech 100 malych a tech 100 malych me zacnou limitovat CPU, protoze budou produkovat kvantum draw calls. To muzu takhle nahodit i jednodusi modely, jen každý udelam jiny, nahodim na každý jiny set textur, necham je honit se po plani v poctu 100 kusu s vrhanim stinu s vlastní AI a kouzlenim efektu, trochu ty praseciny a mas klasickou CPU bottlenecklou MMO nebo strategii.
DOC_ZENITH
Středně pokročilý
Středně pokročilý
Uživatelský avatar
Registrován: 08. kvě 2010
Bydliště: Praha

Re: Khronos Vulkan (glNext): Mantle Based Low-Level Graphics

Příspěvek od DOC_ZENITH »

Ano, přesně, trefils co tim myslim, a i v těhlech situacích ňákym způsobem mantle vyškrábalo dvojnásobná minima... ale... na 1-2 threadech, když těch threadů bylo více dále to neškálovalo, viz největší benefity na mantle skrze hrami má v průměru I3ka, ne 8 jádrové FX nebo I7.

Ono je taky otázka co vše můžu batchovat ( v tomhle už se nevyznam ) můžu třeba batchovat 10 stejnejch oběktů když každej bude mít separé animace či jinou fyzikální interakci? Atd, atd....
Krteq
Čestný člen
Čestný člen
Registrován: 22. dub 2005
Bydliště: Brno

Re: Khronos Vulkan (glNext): Mantle Based Low-Level Graphics

Příspěvek od Krteq »

DOC_ZENITH píše:můžu třeba batchovat 10 stejnejch oběktů když každej bude mít separé animace či jinou fyzikální interakci? Atd, atd....
Na to slouží instancing.

Batche se používají na seskupení draw calls do vyššího celku, který pošleš ke zpracování a nezatěžuješ CPU zpracováváním jednotlivých draw calls.

Co se StarSwarm týče, tam nešlo o limitaci kvůli tomu co popisuješ, ale o právě o limit zpracování draw calls z důvodu různých efektů a množství různých jednotek na scéně. Ono by se chtělo taky podívat na countery draw calls a počtu jednotek na scéně co jsou vyobrazeny na levé straně GUI. Pak by ti došlo, že mezi nimi není přímá úměra a celé tvoje "testování" postrádalo smysl.
Hladis
Moderátor
Moderátor
Uživatelský avatar
Registrován: 24. čer 2004
Bydliště: Varnsdorf - Athens

Re: Khronos Vulkan (glNext): Mantle Based Low-Level Graphics

Příspěvek od Hladis »

DOC:
No ale tak nemluv o geometrii.

Mělo by zalezet i na enginu. Pokud někdo udela DX11 engine a jen ho prdne na Mantle, tak z toho asi moc velky multithread stále nebude stejne, jako když DX9 jen pretavim na DX11. Podle me se engine musí udelat na telo novym API.

Hmm, to dal nevim co vse se da a neda batchovat. To i zalezi co umi, neumi engine a vse samozrejme nejde. Mam pocit ze třeba animace fyziky odevu třeba u nekterych enginu nejde, pokud to neni jen genericka animace, nebo v Crysis ta trava, ale to uz je mimo me a to nevim.
DOC_ZENITH
Středně pokročilý
Středně pokročilý
Uživatelský avatar
Registrován: 08. kvě 2010
Bydliště: Praha

Re: Khronos Vulkan (glNext): Mantle Based Low-Level Graphics

Příspěvek od DOC_ZENITH »

Krtek:

Dobře, byl jsem limitovanej počtem jednotek, v tom se shodneme. Ale ne počtem drawcalls, tzn co mě tedy limitovalo? Efekty těžko ty na CPu moc neseděj, takže leda CPU driven animace, či AI či fyzika (to ale neodpovídá protože ve scénách kdy bylo zobrazeno málo jednotek byl i framerate vysokej a fyzika a AI se počítala dále u všech i těch mimo zorné pole). Jaktože ty ale nebyly teda threadované když celej starswarm byl vytvořenej jako mantle propaganda pro mass multithread... když i tech demo je optimalizovaný mizerně tak co můžeš chtít od real her.

Hladis: Jo, v tom to asi ihmo bude, všechny mantle enginy jsou zatim DX11 (občas i 9) enginy kde je nalepený mantle, nejsou to mantle/DX12/Vulcan based enginy...
Hladis
Moderátor
Moderátor
Uživatelský avatar
Registrován: 24. čer 2004
Bydliště: Varnsdorf - Athens

Re: Khronos Vulkan (glNext): Mantle Based Low-Level Graphics

Příspěvek od Hladis »

Opradu nevim, jak by zazracne mel engine byt najednou silne multithread, když zaklad někdo delal na stary DX a ještě se u toho moc nezapotil. Jen prekompilovani a je hotovo ? To asi ne. To je to samy, jako ty naroubovany DX11 na DX9 enginy. Taky to stalo za hovno. True DX11 prisla az Civilizacka V.
Krteq
Čestný člen
Čestný člen
Registrován: 22. dub 2005
Bydliště: Brno

Re: Khronos Vulkan (glNext): Mantle Based Low-Level Graphics

Příspěvek od Krteq »

DOC_ZENITH píše:Jo, v tom to asi ihmo bude, všechny mantle enginy jsou zatim DX11 (občas i 9) enginy kde je nalepený mantle, nejsou to mantle/DX12/Vulcan based enginy...
Šmarjá, ty asi opravdu nevíš o co jde.

Mantle/Vulkan/DX12 mají jiný přístup k rendering pipeline než stávající DX/OpenGL. Proto taky nejde nijak "naroubovat/nalepit" na stávající rendering část enginu. Je to prostě ten samý engine jen s jiným rendering "sub-enginem".
DOC_ZENITH
Středně pokročilý
Středně pokročilý
Uživatelský avatar
Registrován: 08. kvě 2010
Bydliště: Praha

Re: Khronos Vulkan (glNext): Mantle Based Low-Level Graphics

Příspěvek od DOC_ZENITH »

No, takže se nám onen bottleneck přesunul mimo rendering jinam, na AI, fyziku, animace modelů, atd, atd, atd. Zkrátka i s novými API nemůže bejt vývojář prase pokud chce funkční multithread.
Raikkonen
Začátečník
Začátečník
Registrován: 05. kvě 2008

Re: Khronos Vulkan (glNext): Mantle Based Low-Level Graphics

Příspěvek od Raikkonen »

Krteq píše:Mantle/Vulkan/DX12 mají jiný přístup k rendering pipeline než stávající DX/OpenGL. Proto taky nejde nijak "naroubovat/nalepit" na stávající rendering část enginu. Je to prostě ten samý engine jen s jiným rendering "sub-enginem".
Je tu ale problém v tom, že kolikrát ten nový rendering sub-engine (jak to nazýváš) nevykazuje tak velký nárůst výkonu oproti DX11, jak by se dalo očekávat. Ono nakonec v tom celém enginu totiž bude x dalších brzd, které nejsou optimalizované dostatečně a pak nám všechny ty Mantle/Vulkany/DX12 i cokoliv jiného budou k ničemu. To se určitě zlepší, jak budou přibývat nové enginy kvůli nové generaci konzolí, ale v současné době jich tu máme spoustu z éry DX9 s dalšími naroubovanými efekty díky starým konzolím. Na tohle byli třeba specialisti Activision s Call of Duty - na enginu ze dvojky z roku 2005 stavěli pak snad až do loňska (a i to je otázkou). Ono se u takových sérií, kde se pokračovaní seká jak Baťa cvičky, není ani co divit. Takže si nedělám moc iluzí o tom, že se všech benefitů brzy dočkáme, to ještě nějakou dobu potrvá. Nakonec to stejně často dopadne tak, že se zvýšený výkon zaplácne jen nějakým zbytečným efektem pro oko navíc.
Hladis
Moderátor
Moderátor
Uživatelský avatar
Registrován: 24. čer 2004
Bydliště: Varnsdorf - Athens

Re: Khronos Vulkan (glNext): Mantle Based Low-Level Graphics

Příspěvek od Hladis »

Takovym novym enginem by mel byt snad novy Unreal. Fakt neverim, ze nejaky stary enginy, který mají zaklady z dob krale klacka a dodnes se jen kolem nich nabaluje bordel, najednou provedou zazrak, když je někdo hodi na novy API. API samotny nemuze udelat z praseciny hvezdu a ze singlethreadovky multithread jak vino. Ono jak se v studiich pracuje. Udela se engine a ten je pouzivan dekádu dopředu (je to levny ze) jen s nutnyma obmenama. Programatori tehle veci jsou naprosty konzervy a tlaci je terminy. Staci jak pracuje třeba Ubisoft. Několik projektu na starsich, ale vylepsovanych enginech a všechny sdileji stejny assety a podobny postupy. Nakonec před terminem se hra poslepuje dohromady a vyhul. Třeba Titanfall je na muzejnim Source, Call of Duty stále sedi nekde na zaklade Quake......
DOC_ZENITH
Středně pokročilý
Středně pokročilý
Uživatelský avatar
Registrován: 08. kvě 2010
Bydliště: Praha

Re: Khronos Vulkan (glNext): Mantle Based Low-Level Graphics

Příspěvek od DOC_ZENITH »

Kdyby jen einginy, tam se reusujou i textury objekty a obecně všechny assety. Ti kdyby vydali COD1, invertovali barvy u všech textur a pojmenovali to LSD assault tak to ovce koupěj opět ve stejném množství. :P
Ache
Pokročilý
Pokročilý
Uživatelský avatar
Registrován: 26. zář 2006
Bydliště: Plzeň

Re: Khronos Vulkan (glNext): Mantle Based Low-Level Graphics

Příspěvek od Ache »

Hladis píše:Call of Duty stále sedi nekde na zaklade Quake......
No a ten engine se snad neměnil (renderpath)? To se rovnou může říct, že novej Unreal Tournament sedí na základě UE1. :wink:
Řekl bych že za tu dobu COD engine svůj Rederpath hodně změnil... stejně jako se postupně měnil Unreal Engine. (v základech to funguje stejně - pokud si zvládl udělat mapu pro Unreal1, pro Unreal4 to až na pár změn není problém)
AMD Ryzen 7 9800X3D | MSI X670 Tomahawk | 64GB DDR5 6000 cl30 | INNO3D RTX 4070 Ti | 500GB SSD (NVME) + 2x 3,84TB Micron 5300 PRO
Sound Blaster Z + EDIFIER S1000MKII + Beyerdynamic DT 990 | Seasonic X850 | Cooler Master HAF-X Nvidia Edition | MSI Optix MAG274QRF-QD Quantum Dot bestie
oneb1t
Začátečník
Začátečník
Uživatelský avatar
Registrován: 22. dub 2010

Re: Khronos Vulkan (glNext): Mantle Based Low-Level Graphics

Příspěvek od oneb1t »

za tuhle zaprdenost enginu muze hlavne dlouhej zivot posledni generace konzoli
tenhle rok konecne vyjdou enginy vyvijeny bez ohledu na 6 let starej HW
i7-12700K, 2x16GB DDR5-4800MHz, ASUS B660-I, 1TB WDS100T1X0E
i5-12400F@5.5GHz, 4x8GB DDR5-4800MHz CL40, Asrock B760M PG riptide, A-data 1TB XPG SX8200, Radeon MI25@WX9100 16GB, NZXT S340 Elite, X4071UHSU
HP ENVY x360 13" Ryzen 3 4300U
Hladis
Moderátor
Moderátor
Uživatelský avatar
Registrován: 24. čer 2004
Bydliště: Varnsdorf - Athens

Re: Khronos Vulkan (glNext): Mantle Based Low-Level Graphics

Příspěvek od Hladis »

Ache píše:
Hladis píše:Call of Duty stále sedi nekde na zaklade Quake......
No a ten engine se snad neměnil (renderpath)? To se rovnou může říct, že novej Unreal Tournament sedí na základě UE1. :wink:
Řekl bych že za tu dobu COD engine svůj Rederpath hodně změnil... stejně jako se postupně měnil Unreal Engine. (v základech to funguje stejně - pokud si zvládl udělat mapu pro Unreal1, pro Unreal4 to až na pár změn není problém)
Tady nejde o editor a zrovna Unreal patri mezi spicku, ale jakmile to vezme studio a zacne do starého Unreala ladovat prasacky bordel, dopadne to taky blbe. Dam priklad kde je problem. Vytahnu klasiku Skyrim (ten mam prolezlej horem dolem). To je tak neoptimalizovana srajda, az to boli a to vyrabi Bethesda a jde o AAA hru. Tam o nejaky optimalizaci Draw calls nikdy snad neslyseli. Cela hra je sestavena z tuny meshu, takze nemas barak jako jeden mesh, ale je sestaven z vicero casti jako skládačka a nemá na sobe jednu texturu, ale hromady samostatných textur. No a to produkuje kvantum volani. Když třeba spawnu hromadu identických NPC, tak normalne vidíš, jak s poctem jde vykon CPU do kopru, ikdyz ty NPC jsou všechny sejny. Tedy zapomen na batching. Ty města jsou tam vcelku chudy a když je vysperkujes modem jako JK mod, tak ten mod ti tam prida hromadu nového bordelu, tim padem meshu a textur a zvýšíš tim dramaticky pocet volani. No a opet vykon ti jde do kopru. Ted ještě v dungeonech se renderuje vesmes cely podzemi, protože autori tam nedali OCC (occlusion culling). Na povrchu sice je, ale zase ignoruje maly meshe, takze kazdou malou kravinu ti to renderuje napric celym Cellem bez ohledu zda cumis do zdi. Ted kdyz zvýšíš ugrids a renderuje se ti vice sousedních cellu, tak ti to opet pada do sklepa, protože počet objektu se zvysuje. Samozrejme Skyrim při vydani byl tezky CPU bottleneck a dodnes je, pokud tomu nalozis. Kdyby jsi to prdnul na novy API jako Khronos, tak ti to samozrejme odlehci, protože ty kvanta draw calls to prechrousta. Ale primarni problém nebylo API. Primarnim problémem byla totalni dobytcarna tvurcu. A nemysli si, ze jinde je to jinak. Naopak to povazuju skoro za "standart" dnesnich her. Mi stacila ukázka kodu ze hry na Unreal enginu, kdy se taktéž tvurci hry neobtezovali s optimalizaci a cela A4ka s tunou volani se dala optimalizovat na jeden radek. Ono muzes mit i vyborny engine, ale i s vybornym zakladem se da hra posrat. Proste primarni pruser je ve vyvojarich. Ti vezmou engine, který klidne mnoho věci ani batchovat neumi nebo na to tvurci serou, narvou do toho mraky novych věci a mas novou hru. pLacnu třeba když do Unity nasazim plno zenskych v suknich s fyzikalnim modelem (není to jen pouha animace), tak se to posere, protože to batchovat neumi. Vyvojari jsou často konzervy a mají nejaky pracovni postupy, kterých se tezce zbavuji a tlaci je terminy. Vidim to i na sobe pri praci, kdy jen nerad menim postupy :-D
ttxman
Začátečník
Začátečník
Registrován: 28. zář 2003

Re: Khronos Vulkan (glNext): Mantle Based Low-Level Graphics

Příspěvek od ttxman »

On je dost problém v tom, že se v dnešních hrách všechny "modely" neustále mění. Lidi proste chtějí animace a chtějí aby se od sebe postavy/domy/tráva/kameny lišili.

Je úplně jedno, že scéna obsahuje 1000 "stejných" postav, když každá postava je v trochu jiný fázy animace, to znamená jinej model, jinej model znamená samostatný draw cally.

Navíc už dávno nestačí aby byla postava 1 model s 1 texturou. Přehazujeme brnění, oblečení, zbraně a kdoví co ještě (včetně zuby? oči?...). Není jednoduchý programově složit několik animovaných objektů se samostatnými texturami (meshů) do jednoho objektu s jednou texturou.
A v případě nezávislých animací to výkonově není ani možný. Vemte si třeba pohyb očí, kdyby oči nebyly samostatnej objekt tak se vám každej frame pohybu oka mění ta gigantická textura na gigantickým modelu co by byla pro renderování ideální. Jenže v dnešním DX/OGL by to znamenalo to texturu nagenerovat pokaždý znova a poslat ji celou znova do grafický karty.

Tím se dostávám k materiálům: kovový zbraně mají materiál který se pro světlo chová jinak než kožené brnění atd.. V praxi to znamená, že se aplikují jiné shadery, což zase znamená, že to bude minimálně samostatná textura a takřka jistě samostatný objekt.
Nevím jestli DX/OGL umožnuje jednoduše aplikovat shader na část objektu, ale enginy ne. O tomhle bylo demo s růžně barvenou tříkolkou u tuším unreal enginu 4, takže aktuálně by to možná v nejmodernějších enginech už šlo, ale znamená to grafiky naučit pracovat s novejma metodama a v novejch nástrojích, taže zase roky zpoždění před nasazením do praxe..

Pak k tomu přihoďte fyziku, třeba povlávání vlasů, trávy a oblečení ve větru. Na základě fyziky spočítaný animace nejdou předpočítat nijak předem. Takže nejen, že přibývá spousta animací, ale ještě je každá animace z pohledu renderingu úplně jiná a musí se nestále dokola samostatně přepočítávat.

Zkuste si klidně zprogramovat některý z prastarejch (ale pořád aktuálních) tutoriálů pro OpenGL. Nejdřív Vám ukážou display listy, aby se každá krabice nemusela posílat do GPU pořád znova, a hned v další lekci je, že pak nejdou animace. Výsledkem je, že si do display listu dáte krabice bez předních stěn, ktery tam pak doděláváte samostatně. protože jim chcete měnit barvy nebo tak něco.

No a ve stávajících DX/OpenGL tohle všechno vždycky putuje na grafickou kartu jednou cestou a pouze v jednom vláknu. (Multithreaded rendering to trochu zlepšuje, ale stejně nejde rvát modely do grafiky paralelně 100% času viz dál).

Takže čím modernější hra, kde se všechno hejbe tím menší šance je na zmenšení počtu volání API funkcí (drawcalls)


V DX a OGL si driver hlídá stavy všeho v paměti GPU, takže minimálně v každym framu a spíš i při volání některých funkcí, řídící vlákno zastaví veškerou manipulaci s GPU částí systému (zjednodušeně) zkontroluje stav všeho co potřebuje pro vykonání dané funkce, případně udělá nějaký akce aby se dostalo do stavu kdy může být ta funkce provedena a práce mezi tím stojí. To je první část driver overheadu.
Další část část driver overheadu je daná přímo VDDM modelem. Aplikace běží user módu (což v podstatě znamená, že nemůže rozbít windows), ale DX/OGL grafický drivery a rendering běží v kernel módu (což znamená, že když se tam něco rozbije tak to v lepším případě končí bluescreenem). Jenže díky tomu volání funkcí mezi aplikací a driverem podléhá spoustě chaosu a zdržení, kterýmu se říká context switch. V podstatě jde o softwarovej interrupt, uložení celýho stavu procesoru: registry, stack atd. a po skonční interruptu zase obnovní zpátky. (pokud to někoho zajímá najděte si jak funguje "NT system call").
Context switch je celkem pomalá operace a Drivery DX/OGL se ji snaží elimininovat interním batchováním callů, takže když zavoláte API funkci vykoná se to někdy až driver řekne, že je čas. A je dost pravděpodobný, že se změní i pořadí vykonání toho co aplikace zavolala, protože driver ví nejlíp co engine dělá :mrgreen: . Problém batchování potom není ani tak latence samotná jako spíš to, že latence neustále a nekontrolovaně kolísá podle toho jak driver batchuje. Takže engine si v podstatě nemůžete připravit data na grafický kartě, který nepotřebuje k vykreslení aktuálního framu dopředu bez následků. Je velice pravděpodobný, že se do toho namotá driver a zdrží vám aktuální frame protože bude přenášed data co pro něj nepotřebuje.. a není nad tím žádná kontrola..

V Mantle (DX12, Vulkan) jak já sem to pochopil máte multivláknový přístup do paměti grafické karty, takže si tam můžete model, textury a jiné blbosti strkat podle libosti z libovolnýho vlákna. Ten navíc nějakým pro mě záhadným způsobem obchází velkou část context switchů. (HW virtualizace GPU paměti co je v GCN?)
Pak máte nějakou rendering frontu (nebo i víc front), která vám to všechno kreslí na display. Ta se taky vyrábí v user mode kódu (převážně?). Ale její zpracování se řídí obdobou drawcallů, které už díky WDDM prochází do kernel mode funkcí. Ale v tuhle chvíli už vy jakožto engine musíte zaručit že to co fronta použije tak všechno leží v paměti tam, kde ste řekli že bude, jinak to zkončí strašlivým rozbitím toho co se zobrazuje.
Plus nějaké další teoretické úspory času a přenosů mezi CPU a GPU, jelikož díky přístupu do GPU paměti můžete modifikovat textury a modely a nemusíte je nahrávat přež API celé znova.

Když to vezmu hodně zjednodušeně tak v Mantle/DX12/Vulkan tak příprava a přesun dat pro rendering jde multivláknově mimo grafickej driver (tak jak je znám v dnešní podobě) čímž se zbavíte jeho overheadu. Grafickej driver je podstatně jednodužší protože se už nevěnuje organizaci assetů, čímž se zase zmenší jeho overhead a stabilizují jeho latence. Na engine se přesunula práce s assets na GPU co předtím dělal driver, jenže to není velkej problém, protože si to engine stejně organizoval v CPU paměti a do GPU posílal přez API funkce a o mnoho víc toho nebude dělat ani teď.
Odpovědět

Zpět na „Grafické karty“