Názory k článku Vulkan: představení a první jednoduchá aplikace
-
Hm, to zní jako výzva pro tento tutoriál - ukázat alespoň v obrysech, jak to dělat. Podle mé zkušenosti nejkomplikovanější otázky efektivity jsou kolem synchronizace, např. kolem pipelineBarrier(), což je peklo ze specifikace pochopit. Pokud bychom se čistě ptali, jak rychle rendrovat trojúhelníky - to je také výzva. Možná by se tomuto mohl věnovat jeden z dílů tutoriálu.
-
A jsou k Vulkan API k dispozici nejake pokrocilejsi matematicke knihovny, aby se to dalo pouzivat podobne elegantne jako CUDA pro vedoecko-technicke vypocty?
Zatim to vypada jako extremne flexibilni, ale soucasne extremne low-level prostredi, kde vyvoj aplikace bude vyzadovat hramadu prace a zkusenosti, aby to pocitalo optimalne rychle.
1. 7. 2021, 09:24 editováno autorem komentáře
-
Existuje konverze OpenCL skriptů pro Vulkan a SPIR-V. Google to dokonce doporučuje jako náhradu za RenderSript pro Android 9 a výše. Mel jsem k tomu krasný materiál, ale nemůžu ho najít. Chtěl jsem ověřit OpenCL pro mobily a při té příležitosti jsem na to narazil. Jak moc je to použitelné zatím nevím. https://github.com/google/clspv
-
To by me taky docela zajimalo, predpokladam, ze Vulkan by mohl mit mensi problemy, kterymi trpi OpenCL -> drivery ruzne kvality a starsich verzi. Na druhou stranu nemyslim si, ze nekdo pro Vulkan zatim napsal neco jako thrust nebo VexCL/ArrayFire/BoostCompute, protoze i kdyz pouzivam i vlastni kernely, tak musim rict, ze tohle mi docela usetri praci a ta je obcas drazsi nez dosazene zrychleni na GPU :)
-
Článek má pravdu, že mainstreamové grafické karty byly před 25 lety jen zobrazovadla. Ale konstruktéři, architekti, grafici a další, kdo potřebovali rychlou grafiku, už v té době používali grafické akcelerátory. Například low-endová TurboGXplus karta od Sun Microsystems byla vydaná v roce 1993 (http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.29.3716&rep=rep1&type=pdf). Zrychlovala 2D i 3D operace prostřednictvím neprogramovatelného ASICu. První verze GX akcelerátorů se objevily v roce 1989 a do roku 1993 se jich prodalo asi 300 000. Pro srovnání: první verze OpenGL (1.0) byla vydaná v roce 1992. Integraci s X Window System zajišťovalo rozšíření GLX. OpenGL byla inspirovaná proprietární IrisGL knihovnou od Silicon Graphics. Předtím se používala knihovna PHIGS. (PEX rozšíření v X).
-
Myslim, ze pravdu moc nema. V roku 1996 (2021-25) uz bolo uplne bezne a ziadane, aby graficka karta vedela minimalne zakladny blitting - 2D akceleraciu. Graficke karty mozno za hlupe zobrazovadla povazovat tak cca do prelomu 80. a 90. rokov, aj to uz VESA pracovala aspon na zakladnej 2D akceleracii a pomerne bezne bola poskytovana.
-
Váš komentář o roce 1996 bude určitě pravdivý, vždyť v tom roce byla vydána i karta Voodoo 1, která byla čistě 3D akcelerátor.
Má věta však mínila rok 1991, kdy sotva přišel na trh ATI Mach 8 a S3 se teprve nově objevila na trhu. Ale rád se nechám poučit, kolik 2D akcelerace uměly tehdejší ATI Wonder VGA/EGA/CGA/MGA, či jiné karty, které byly již na trhu. Jsme v době, kdy se teprve rozšiřuje procesor 486 na trhu a profesionální 3D grafiku reprezentuje firma Silicon Graphics.
-
Pochybuji, že TIGA (Texas Instruments Graphics Architecture) byl v té době mainstream. Sun Microsystems použil grafický akcelerátor TMS34010 (https://en.wikipedia.org/wiki/TMS34010) ve své pracovní stanici Sun386i (https://en.wikipedia.org/wiki/Sun386i). Ta měla procesor 80386 a stála asi 5000 USD. Ty samé čipy (TMS34010) se používaly v TIGA akcelerátorech pro PC .
-
V te dobe nebyl mainstream ani drazsi Tseng nebo ATI s Machem a sebestovou ci Matrox.
Většinou clovek mel Trident,Oak ,Realtek, Cirrus atd.
Troufam si rici ze puvodni otazka úplně nesmerovala na mainstream. Kdo pouzival pocitac pro seriozni grafickou praci tak mel lepsi grafickou kartu.
Chudy student s ukradenym CADem mohl maximalne jeste rozsirit paměť graficke karty.
5. 7. 2021, 08:34 editováno autorem komentáře
-
Akcelerácia blittingu začala byť dôležitá s windows 3.1, a potom s WinG, Windows 95 a DirectX.
Ale okrem toho začiatkom 90-tok existovali akcelerátory, ktoré vedeli akceleráciu 2D grafiky - kreslenie rozličných typov čiar, stippling, apod. Ich využitie bolo v CAD-och, 3D modelároch (wireframe) apod.
-
Nehovorím o kóde,ktorý používa tento vulcan wrapper, ale z poľadu výkonu, podmienky sa len skryli do medzivrstvy, ten wrapper je plný takýchto podmienok:
if ( result != VULKAN_HPP_NAMESPACE::Result::eSuccess )
{
throwResultException( result, "vkCreateAccelerationStructureKHR" );
}Je to v poriadku, len si nemyslím, že vďaka tomu je výsledný kód rýchlejší, ako to je uvedené v článku.
-
Ale ono jde práve o ten kód, co ten wrapper používá. Ten wrapper sám o sobě tu chybu nemá jak ošetřit. Takže je na výběr ji propagovat ven výjimkou nebo skrz nějaké chybové kódy. A u těch chybových kódů bude na každé (nebo skoro každé) vrstvě test.
Jde o to porovnávat jabka s jabkama. Má smysl dívat se na celou cestu chyby od místa vzniku až do místa, kde se ošetří. A to už výjimky můžou (ale taky nemusí) být výrazně rychlejší. Optimalizovat jednu vrstvu odděleně má smysl jen pokud ty optimalizace do ostatních vrstev nezasáhnou. A to u propagace chyb rozhodně neplatí.
-
Přesně!
Pokud uděláme pět úrovní zanoření, pak bez výjimek testujeme pro kód chyby na všech pěti úrovních. Vždy se ptáme zda nám zavolaná funkce vrátila success nebo nějakou chybu. Pokud použijeme výjimky, tak porovnání zůstává pouze na nejvyšší úrovni zanoření, kde otestujeme, co nám vrátilo cizí API (třeba Vulkan) a podle toho vyhodíme výjimku nebo ne. Z této funkce už pak už nemusíme vracet chybový kód a nadřazená funkce už nemusí nic testovat. Test tedy zůstal jen na páté úrovni zanoření a ze zbylých čtyřech byl eliminován. Dá se tedy předpokládat, že méně instrukcí porovnání a skoků způsobí rychlejší běh kódu. Toto mi potvrdil i jednoduchý experiment na g++ a s MSVC. V kódu, který velmi intenzivně volal funkce a vracel chyby, přineslo použití výjimek i dvojnásobné zrychlení. Budete-li mít jinou zkušenost, sem s ní.
-
Vynimky su nahodou velmi uzitocne. Tazsie sa potom pise spagetak a ulahci to pracu ludom ktori to musia opravovat. Funkcia ktora tu vynimku vyhodi spracovava len svoju ulohu, a funkcia ktora tu vynimku odchyti a spracuje riesi zase svoju ulohu...
Teda ak nejakeho blazna nenapadne ze pouzije vynimky pre riadenie behu programu, aj to uz som videl na vlastne oci...
-
To jsi ještě neviděl veci... a lidé mi pak vyčítají že jsem sprostý když to pak rozmotavaji lidi celý rok a já přicházím o volný čas.
Když ti devel co vylezl z univerzity napíše takove "kreativni" exkrementy a je pak ještě ve vedení projektu je téměř nemožné ho vykydlit.
Nemůžeš ho pak prevelet ani do energy divize protože by chudáček nepřežil code review.
3. 7. 2021, 19:18 editováno autorem komentáře
-
S těma špagetama je to těžké. Výjimky jsou dvojsečná zbraň. Výjimečné stavy programu jsou taky stavy programu. Akorát jsou díky své vzácnosti nejmíň promyšlené a otestované.
A výjimky k tomu jako bonus přidají to, že zrovna ty problematické cesty v kódu nejsou při čtení zdrojáku vůbec vidět. Psát kód tak, aby jeho invarianty přežily když uprostřed vyletí nějaká neočekávaná výjimka, není vůbec jednoduché. -
Díky za článek. Co mě potěšilo je, že příklady používají CMake. Instalace ovladačů na mém pracovním notebooku s Windows bez problému; kompilace bez problémů. Nedávno jsem si hrál s Vulkanem v Pythonu, protože jsem potřeboval jen rychle experimentovat s API/shadery. Obalit C API není problém, ale některé featury tam nejdou viz https://gabdube.github.io/python/vulkan/2019/01/10/python-and-vulkan-01.html Oproti OpenGL se mi zdá (se kterým jsem vždy bojoval s kompilací na různých systémech, protože potřebujete GLEW, GLAD a spol.), že to celé rozběhnout je mnohem lehčí.
Zdravím a těším se na další články!
ČLÁNKY DO MAILU