Názory k článku Vulkan: nástupce OpenGL je tu. Stahujte ovladače
-
PPK (neregistrovaný)
Vyrobci sice vydali ovladace i pro starsi grafiky. Ale u intelu to znamena rok 2014 a novejsi, u nvidie to pokryva grafiky od roku 2012 (ale jak vime, tak ani v nejnovejsi generaci neni podpora zdaleka adekvatni) a u amd grafiky od prosince 2011. To pro vetsinu tvurcu nejni dostatecny pokryti a chteji podporovat i starsi produkty ...
-
kutr (neregistrovaný)
S výkonem na jádro nemám problém. Dělám na tom počítači i jiné věci než hry a tam zase využiju pocesor s více jádry (za stejnou cenu s i3 dostanu o 1/3 vyšší jednojádrový výkon a přibližně poloviční paralelní, to mi moc přesvědčivé nepřipadá).
Spíš co jsem chtěl napsat, že 750TI je jedna z nejstarších karet pro kterou nvidia napsala vulcan ovladače a ta karta se pořád prodává a v poměrech cena/výkon je to pořád dobrá volba. A jen o generaci starší karty, výkonově srovnatelné nebo i lepší jsou podle lidí na které reaguju staré křápy co maj lidi hodit do šrotu.
-
Peter FodrekZlatý podporovatelv pripade AMD to musi byt grafika s GCN lubovolnej verzie
s prvymi kartami z roku 2011. So starsimi GPU to nepojde -
matej.mainus (neregistrovaný)
Vulkan má za cíl uplně opačnou věc a to přesunout zodpovědnost z molochovatých driverů na aplikace, protože ty přesně vědí co a jak chctějí renderovat, místo aby to ovladač musel hádat. Takže když se na to kouknem z tohodle pohledu tak OpenGL je vlastně nadstavba nad Vulkánem, ale nikdo asi ještě neměl "koule" na to to takhle v driverech implementovat, protože jejich komplexnost je šílena a určitě by to rozbilo spoustu aplikací a navíc by to nepřineslo kýžené zrychlení, protože by driver stále hádal.
-
Vždyť to je to, co říkám. Ovladače by mohly implementovat jenom vulkán a pro zpětnou kompatibilitu by OpenGL bylo implementované jako nadstavba nad ním. Asi by to bylo méně efektivní, než čistě nativní implementace, ale pro přechodné období by to stačilo a navíc by to motivovalo vývojáře začít u nových projektů opravdu používat vulkán. Kromě toho by pro ně jistě bylo lepší mít jednu sadu knihoven implementující opengl než současná situace, kdy je jich milion a všechny jsou rozbité, jenom každá nějak jinak.
-
Mají u mě velké plus, že se (aspoň na první pohled) dokázali zbavit kontextu v globální proměnné (případně thread-safe) jako v původním OpenGL.
Na druhé straně ještě jeden krok navíc to chtělo - místo globálních funkcí v knihovně udělat jasný interface se sadou virtuálních metod nebo pointerů na metody, pokud bychom se museli bavit o plain C.
Takhle z toho bude opět neskutečný bordel jako v temných časech OpenGL, s nejasnými pravidly kam by měl zasahovat vendor specific driver, jak řešit různé knihovny od různých vendorů na stejné mašině (on CPU vs dedicated), v takových případech nejspíš další zbytečný layer navíc atd.
-
matej.mainus (neregistrovaný)
Pokud chcete trochu komplexnejší API které půjde portovat i do jiných jazyků než C++ a i na jiné systémy tak pak bohužel C je nejlepší. Naštěstí lidi z Nvidia napsali podobný wrapper na C++ jako u OpenCL i pro Vulkán (https://developer.nvidia.com/open-source-vulkan-c-api). V tomhle je Vulkan daleko před OpenGL
-
To C jim až tak moc (z praktických důvodů) neberu, ale i v C se dá přece implementovat Factory pattern a interface. Viz drivery v linuxovém kernelu, případně v user space ncurses, které jsou snad sto let staré. Chápu, že v 80/90-tých letech byl u designu OpenGL předpoklad, že dodavatel systému je dodavatel hardwaru a se skřípěním zubů se jedna /usr/lib/libgl.so dala pochopit. Ale dneska, kdy každý druhý desktop má dvě grafiky, které se navíc v runtime střídají?!?
Ohledně linku na initialization-functionpointers - jo, takhle to některé aplikace dělaly už v OpenGL, ale je to drbání pravou rukou a levým uchem. Taky v zásadě řeší stejně jen část abstrakce - co když bude mít vendor pro různé účely různé implementace command queue?
A viz OpenGL - ve výsledku stejně většina aplikací přímo linkuje libgl.so, takže řešení bude místo vendor-specific libvulkan.so naimplementovat wrapper, který bude v zásadě vytvářet další wrapper pro každé "createObject" volání a virtualizovat funkce nad ním...
Ten C++ wrapper od Nvidia, jestli dobře vidím, neřeší problém přes abstraktní driver, pouze zapouzdřuje jednotlivé volání do metod objektů (či spíše struktur)...
-
matej.mainus (neregistrovaný)
Vulkan bych strukturou k GL vůbec nepřirovnával. Problém verzí, vendorů a layerů reší přímo loader: https://github.com/KhronosGroup/Vulkan-LoaderAndValidationLayers/blob/sdk-1.0.3/loader/LoaderAndLayerInterface.md
Navíc to na jakých GPU, s jakou verzí Vulkanu, s jakými vrstvami řeší přímo aplikace.
Ten Nvida wrapper měl být argument na plain C style.
-
Ten loader je bohužel přesně to, co jsem popisoval. Místo, aby skutečně zajistil pouze discovery a load vendor driveru, tak pronásleduje (intercepting) každé další volání, které už má jít přímo do driveru - viz obrázek na druhé a třetí stránce :-/ Zcela zbytečný overhead a navíc řešení polovičaté...
-
matej.mainus (neregistrovaný)
Kdyby volání šlo přímo do driveru, tak by API přišlo o podporu vrstev pro debug, tracing... a všechny aplikace by to musely bastlit samy (skoro nic by se tím neušetřilo). Ano overhead tam je ale malý v porovnáním co všechno se u renderingu dělá aby se vykreslila scéna. Bež těchto důležitých features, by se to ve Vulkanu velmi těžko vyvíjelo.
-
To si nemyslím, spíš právě naopak. Bavíme se samozřejmě o user space vrstvě toho driveru. Pokud budu chtít další funkcionalitu kolem, jednoduše zabalím (v případě potřeby!) do proxy. Získám tak prakticky to samé, co mi umožní zmíněný Vulkan loader, ale daleko flexibilnější a neomezený tím, co vývojář toho "oficiálního" loaderu považoval za důležité.
Ten overhead, co tam je, není v celém kontextu možná velký, ale primárně zbytečný. Nehledě na to, že vendor bude mít nejspíš rovněž potřebu vnitřní abstrakce, takže si tyhle function pointery wrapne do podobné virtualizace. Overhead roste a nic nepřináší, naopak komplikuje.
V zásadě správně to měl vyřešené Direct3D už snad před dvaceti lety, nutno dodat, že jej rovnou postavili nad COM, pro kterou je takové řešení přirozené. Nicméně viz výše, ani v C to není nijak velkou překážkou...
-
matej.mainus (neregistrovaný)
Funkcionalitu kolem budu potřebovat ve všech případech, protože bez debug/validation layeru se ve Vulkanu neda pracovat, takže by to implementovali opravdu všichni a stejně by nakonec na github vznikla knihovna která by dělala skoro to stejné, a importovali by ji úplně všichni. Takže nechť ať to naimplementujou lidi z LunarG/Khronos/Nvidia/AMD/Qualcomm.., kteří do toho vidí mnohem líp než komunita.
Navíc princip vrstev které se sypou do loaderu je "univerzální", takže místo abych patlal nejaký svůj standard (ala svoje vlastní proxy), tak bude přenositelnější (pro více projektů) to implementovat jako layer.
COM model není taky bez overheadu a taky bychom se mohli začít hádat jeslti je zbytečný a nešlo by skoro to stejné naimplementovat "lépe"/bez některých featur, a navíc jeho implementace v C by byla velká a řekněme zbytečná šílenost, která by na výkonu ušetřila/přidala "nic".
-
Ten loader může samozřejmě obsahovat běžně používané proxy, ale pořád ta možnost volby zajistí flexibilitu, lepší performance a lepší abstrakci. Nacpat to tam natvrdo přes globální funkce nic nepřinese a je to omezující. Jestli by vznikla knihovna, která by implementovala běžné funkce - proč ne? Ale pořád má ten vendor možnost volby a když přijde s lepší hardwarovou implementací, tak ji může snadno nahradit. To není ten případ, pokud Vulkan bude část řešit na horní vrstvě. Což si ani nemyslím, bo primární cíl je mít skutečně low-level přístup.
Ad Direct3D/COM - to byl jen příklad korektního abstraktního řešení. Samotný COM je zde samozřejmě kanón na vrabce, ten princip je loadnout vendor shared library, a vrátit pointer na VkDevice strukturu, která bude mít v sobě pointery na waitIdle, destroyDevice, getDeviceQueue, a opět VkQueue se submit, bindSparse atd. Na to nepotřebuju žádný overhead...
-
matej.mainus (neregistrovaný)
Na měření je ještě příliš brzo. Ovladače jsou furt ve fázi beta, a také hodně záleží na tom jak je aplikace napsaná (jak v případě OpenGL tak i Vulkan u kterého je to ještě důležitější)
Pár demo apek se dá najít (https://www.youtube.com/watch?v=P_I8an8jXuM https://www.youtube.com/watch?v=47BciFH7Dlo (ještě doporučuju dema od Nvidia) ale nebral bych to ještě jako finální benchmark, na ten bych počkal https://gfxbench.com/news_single.jsp?id=25230662
-
Jen jsem nakouk do dokumentace API a už se mi chce zvracet. Bohužel jsem zabrousil k synchronizaci a zase tam vidim starou znamou nedomyslenost, kterou známe z jiných OS
wait for events
wait for fences
wait for semaphoresNapadlo nekdy nekoho, ze synchroni wait neni vetsinou zadanej a pokud ano, tak bych treba rad cekal na vic udalosti soucasne? Co treba koncept Future/Promise? Dá se aplikovat i na completion, eventy a semafory.
Bojím se to číst dál.
-
JSH (neregistrovaný)
To chce míň se bát a víc číst. Na semafory se třeba vůbec čekat nedá :) A jak u eventů, tak u fenců se samozřejmě dá čekat na víc zároveň.
Tohle je low-level api. Úmyslně! Synchronizace u ládování grafiky slouží primárně pro řazení příkazů mezi frontami. Na klientovi se čeká jen výjimečně.
-
fe (neregistrovaný)
…Vuklán je něco jako Metal od Apple?
https://developer.apple.com/metal/
ČLÁNKY DO MAILU