Przyszłość API Vulkan?


#1

Witam,
Od premiery API Vulkan minęły już dwa lata więc pomyślałem sobie, że można już coś na jego temat więcej powiedzieć.
Czy według was Vulkan(glNext) to następca OpenGL? Czy warto portować silniki z OpenGL na Vulkan ?
Na razie Vulkan nie zdobył większej popularności. Trudno znaleźć w języku Polskim książki, filmiki albo tutoriale na temat programowania w Vulkan. Dopiero w tym roku Vulkan pojawił się na systemach iOS i macOS. Z drugiej strony pojawiły się nowe karty graficzne RTX od nVidia, które sprzętowo wspierają RayTracing. Póki co nie znalazłem informacji, jakoby OpenGL miał wspierać ów RayTracing, natomiast znalazłem informację że RayTracing ma zawitać do Vulkan https://pclab.pl/news77807.html. Sam nie wiem co o tym wszystkim myśleć. Czy Vulkan kiedyś wyprze OpenGL i będzie miał nad nim znaczącą przewagę ? Jestem ciekaw waszej opinii.


#2

TAK.

Polecam zapoznać się z tą prezentacją.


#3

Dzięki za linka. Ciekawa prezentacja, ale na końcu jest napisane w zaletach: Inwestycja na przyszłość – zostań specjalistą w wąskiej dziedzinie! Wąskiej dziedzinie ? Czy to oznacza, że Vulkan pozostanie tylko “wąską dziedziną”, a i tak szerzej będzie używany OpenGL ?:slight_smile: No i taka niepozorna wada dla małych developerów, których nie stać na kosztowne testy na wielu platformach: – Błędny kod na jednych GPU działa, na innych nie. Czyli jeśli popełnimy błąd w Vulkan, to na naszym sprzęcie może działać i go nie wykryjemy, a u innych może już nie działać. W OpenGL jak popełnimy błąd to nie zadziała od razu u nas(choć kiedyś spotkałem się z błędem w OpenGL gdzie pewna rzecz na mojej karcie graficznej nie działała a na innej działała, ale to był błąd w sterowniku karty graficznej(notabene oryginalnie dołączonym na CD do karty graficznej), bo po aktualizacji sterownika błąd zniknął. Mimo wszystko ciekawe to API i chciałbym się z nim bliżej zapoznać, jednak przydałaby się książka/kurs w języku polskim, bo łatwiej i szybciej mi się czyta w ojczystym języku. Póki co nawet Helion nie kwapi się do wydania książki o Vulkan, a do OpenGL ma całą masę książek. O dziwo na allegro dostępna jest książka o Vulkan napisana przez Polaka ale w języku Angielskim no i ta cena 313 zł :slight_smile: https://allegro.pl/vulkan-cookbook-pawel-lapinski-i7338472427.html Może ta wąska specjalizacja właśnie tyle kosztuje :wink:


#4

Przecież ta książka była na www.packtpub.com/packt/offers/free-learning za free.

Tutaj link do wersji PDF.

I po raz kolejny zaznaczę. Język angielski to podstawa. Ważniejszy niż wszystkie inne języki C++, Javy. Przy okazji uczysz się powszechnie użwanej terminologii. Bo nikt w tej dziedzinie polskiej terminologii nie używa. A niektórych rzeczy nawet nie da się sensownie przełożyć.


#5

3 razy TAK, jest to w 100% przyszłosć bo wszyscy, nawet my przepisujemy nasze silniki na Dx12, Vulkan lub (tfu) Metal.

I ma to duzy sens, poniewaz dje ci mozliwosci lepszego scalingu niz dotychczasowe API ktore były albo single-threaded albo gdzie multi-threading był tzw. @afterthought@.
To jest jeden z powodw czemu sterowniki zbalonowały do 300mb, bo stare API wymagały od producenta karty graficznej mnostwa rzeczy typu np. ze mozesz sobie skasowac obiekt nawet kiedy jest uzywane przez kartei inneobiekty w API i ze za scena zostanie ładnie odbindowany.
Jesli sprobojesz zrobic to samo w Vulkanie to ci poprostu apka sie wywali lub bedziesz miał BSOD (musisz ustawic event na gpu i poczekac na cpuna sygnal zze obiekt jestjuz nie uzywany).

Jesli chodzi o iOS i macOS to tutaj jest winny (tfu) Apple z ich (tfu) Metal’em, oni zawsze sabotowali otwarte standarty graficzne oraz podejmowali najgorsze decyzje dla graczy. To ze Vulkan działa na Applu to zasługa tylko i wyłącznie MoltenVK który robi translacje Vulkan na Metal.

Nie możesz sie spodziewać materiału o Vulkanie po Polsku, ani jak w końcu się pojawi to że będzie on dobrej jakości. To dlatego że vulkan wymaga wiedzy z architektury typu concurrency, memory coherency, cache hierarchies, etc. które tak na dobrą sprawe nie zostały nawet dobrze przetłumaczone na polski, ja nawet nie wiem jakie jest tłumaczenie terminów z C++11 odnośnie release/acquire semantics. Problem jest taki że nawet polacy którzy znają temat nie mają zielonego pojęcia jak to wszystko sie nazywa po polsku.

Odnosnie OpenGL, mysle ze bedzie żył jeszcze przez pare lat do zachowania kompatybilności ze starym code-base i ułatwieniu przejścia na Vulkan. Wszystko inne bedzie silnikami i framework’ami na nowe API typu Dx12 i Vulkan ktoryczh ludzie beda uzywac ktorzy nie chca sie babrac bezposrednia komunikacja z GPU.
Kiedys bardzo duzo ludzi znało OpenGL i DirectX, ale wszyscy sie wystraszyli shaderów i synchro.

Czyli jeśli popełnimy błąd w Vulkan, to na naszym sprzęcie może działać i go nie wykryjemy, a u innych może już nie działać.

Od tego masz tzw. Validation Layers w Vulkanie.

W OpenGL jak popełnimy błąd

OpenGL jest gorszy, driver musi wiecej rzeczy zaimplementowac wiec jest wiecej miejsca na pomyłki po stronie GPU vendora. Najgorszym vendorem OpenGL’a oprocz Appla jest Intel na platformie Windows, tam co rusz nie trzymają sie specyfikacji albo masz hardware bug.
Po drugie, Vulkan ma lepsze conformance testy i ma kompilator do shaderów wiec jest mniej niespodzianek miedzy vendorami.

RTX’em sie nie martw, bo narazie bedzie ślamazarnie wpełzał do mainstreamu, jak popatrzysz na Battlefield V to RTX dzieje sie na rozdzielczości <1/16 i nie wystarcza na tzw. primary visibility. Poza tym NVidia miała już OptiX od prawie dekady, i RTX jest jej tylko małym rozwinieciem.
Vulkan na pewno bedzie miał ten extension, oraz być może OpenGL.
Nauka o raytracingu, spoko, ale tylko w “software” bo tzw. black-box nic cie o tym nie nauczy.
Finalnie, nigdy nie interesuj się nadmiernie tzw. Vendor Specific Features, wszystko co nie jest adoptowane “ubiquitously” wymiera, PhysX nie zawładnał swiatem, Tessellation w pierwotnej formie od AMD też nie, o NVidia APEX jest głucho, HAVOK na AMD z akceleracja na ich GPU. Nie mowie ze ich ponysły sa martwe, lub złe, tylko to są prototypy a ich zunifykowana wersja zreguły jest łatwiejsza do ogarnięcia, bardzie przejrzysta, szybsza i nie wymaga od ciebie tony pracy (specjalnego kodu dla kazdego vendora).

Popatrz sobie na ten link:
https://www.khronos.org/registry/OpenGL/index_gl.php#otherextspecs

Ile z tych extensions w pierwszej połowie zostało zastepione przez inne mechanizmy ktore przyprawiają o mniejszy ból głowy? Np. ATI_envmap_bumpmap możesz sobie teraz oraz nawet 10 lat temu łatwo zrobić samemu w shaderze, który bedzie działał nawet na kartach od AMD z 2025.
http://opengl.gpuinfo.org/gl_listreports.php?listreportsbyextensionunsupported=GL_ATI_envmap_bumpmap

P.S. Jak chcesz sie nauczyc OpenGL i Vulkan w ramach stażu i znasz C++ to sie odezwij.


#6

Dzięki. OpenGL już trochę ogarniam i trochę kodu już w nim napisałem https://www.youtube.com/watch?v=5s3EkXHds0E, ale faktycznie w wolnym czasie będę musiał poznać Vulkan, choćby dlatego, żeby lepiej poznać sposoby generowania grafiki na współczesnym sprzęcie od strony niskopoziomowej właśnie. Ekhart podesłał dobre książki więc będzie co ogarniać :slight_smile:


#7

Tymczasem na TVGRYpl, dwa dni temu pojawił się filmik o ciekawie brzmiącej nazwie: Czy DirectX 12 to porażka? https://www.youtube.com/watch?v=l2nHxKnip7s


#8

Że co? DX12 to porażka? Albo ktoś jest opłacony, albo głupi, albo robi to dla p;;;…jeb pol
Jedyne co jest w DX12 zjebane to tagowanie.


#9

no no, pierwszy raz chyba spotkałem się z określeniem ze jak w OpenGL zrobimy błąd to nie działa od razu u nas :smiley:
W zasadzie pisząc na jednym sprzęcie masz pewność jedynie zę działa CI na tym sprzęcie, nawet między kartami tego samego producenta można trafić na problemy. Dla sterowników Intela, to jest tak fajnie, że często musisz różne haksy robić bo coś nie działa w sterowniku i raczej nie będzie. Programując na Nvidii zapewne napiszesz kod który bedzie działał tylko na Nvidii, bo ich sterowniki mase błędów programistów obchodzą nawet nie mówiąc programiscie ze coś zrobił źle :smiley:
W Vulkanie Validation Layers działają zaskakujaco dobrze, ale i tak trzeba przetestować na kilku sprzętach, a chociaz poznać ich wsparcie dla Vulkana. Dla przykłądu pisząc na Intela masz tylko jeden typ pamięci, do wszystkich zasobów masz dostęp od razu, ale to w zasadzie chyba tylko na intelu. Napiszesz prosty system zarządzania zasobami, że bierzesz pierwszą dostępna pamięć i tam alokujesz, a na innych kartach nie zadziała.

Do pełnego wejścia Vulkana musi minąć trochę czasu. Samo napisanie do Vulkana sterowników wydajniejszych niż te z OGL to kupa czasu. Patrząc na Doom-a czy nawet samemu testując wydajność, prosty program na starszych kartach, np GTX750 będzie Ci działał gorzej na Vulkanie, i pewnie już lepiej nie bedzie bo to jest raczej nieopłacalne dla Nvidii wspierać stary sprzęt. Spotakłem się także z opinią (popartą testami), że shader skompilowany na OGL-a jest wydajniejszy niż shader skompilowany do SPIRV i później przez Vulkana. Sam tego nie testowałem, ale bardzo proawdopodobne że tutaj też jest sporo do usprawnienia. Odnośnie narzutu na CPU to praktycznie od początku Vulkan bije na głowę Vulkana, ba. nawet jednowątkowo zazwyczaj będzie mniej obciażać CPU.
Reszta już była napisana, powstaje sporo API zbliżających Vulkana do OpenGL-a. Jeżeli będą na podobnym poziomie co OpenGL (w kwestii prostoty użycia) to zapewne rozwijanie OpenGL-a przestanie mieć sens.
Do nauki Vulkana polecam: https://vulkan-tutorial.com/
Można tam się nauczyć podstaw. Może i nie jest tam Vulkan używany najwydajniej, ale pozwala poznać podstawowe zasady funkcjonowania API.


#10

Jeszcze miesiąc temu bym powiedział Ci, że to jest przyszłość, ale… No właśnie popatrz sobie na odpowiednika Vulkana -> DirectX 12. Liczba gier wspierających D12 spada z każdym rokiem.

Drugi ważny punkt czas. Żeby napisać coś w D12/Vulkanie trzeba poświęcić więcej czasu na produkcję. Po co komuś by się chciało wydawać więcej pieniędzy tylko po to żeby kilku graczy to uruchomiło na swoich kompach? Poza tym popatrz sobie na steam. Większość użytkowników posiada Windowsa 7.

Trzeci i najważniejszy element to wywiad z pewnym twórcą i jego słowa, że Vulkan to marzenie programisty. I co z tego jak ich gra tego nie wspiera? Także w gamedevie liczą się głównie pieniądze i czas ich ich zarobienia. Po co wydawać więcej kasy żeby przeszkolić ludzi/wdrożyć nową technologię skoro to więcej pieniędzy nie przyniesie?

Tutaj masz cały film na ten temat :slight_smile:


#11

D3D12 nigdy nie bedzie porazka jako tako, Vulkan ma ta opcje troche bardziej.

Powod jest prosty, nie ma alternatywy do D3D12 “in the long run”, w sensie jesli nie chcesz pisac na D3D12 to musisz pisac na starym D3D11 o ile nie chcesz porzucic DirectX’a. DX ma tez troche inny design niz OpenGL, nie ma extensions, wiec jesli chciałes kiedy uzywac geometry shader+depth buffer shader access+MSAA textures to musiałes sie przesiasc na dx10, a jak tessellation to trzeba było dx11, nie ma zadnego EXT extension ktore sobie właczysz i uzyjesz bez przepisania kodu.

Przy vulkanie troche ciezej bo Khronos pedzi naprzod i z OpenGL i z Vulkanem, wiec jesli chcesz miec dostep do nowych instrukcji w shaderach to mozesz robic to przez GL i Vk.

Poslugiwanie sie statystykami API usage, filimikami z magazynow i channelow gamingowych samo w sobie jest dosc ekhm, watpliwe. Szczegolnie jesli chodzi o te CNET’y, IGN’y, TVGRypl, etc. zaden z tych gosci nie jest i nie bedzie inzynierem, wiec ich wiedza o tym co robi graphics API nie jest wystarczajaca do napisania nawet małego raporciku na temat SSAO.
Az mi sie przypominaja inforgrafiki o DX10 z poczatku mojej kariery z 2007 ze dzieki DX10 bedziemy mieli “detale na ciemnej stronie gory” jakby to jakas magia nie dostepna w dx9 robiła.

Nowe instrukcje w shaderach (subgroup/wave operations i parallel reduction/scan) i nowe stage (RTX) to jedyne co posuwa adopcje API na przod, poniewaz nowe API jest wstanie dac ci gora 200% perf boost (czesciej 50%) i to tylko na CPU, jak masz juz codebase napisana za $10 millionow to sie juz troche za bardzo nie kalkuluje (naprawde, jak chcesz podniesc jakosc z 1080p do 4K to potrzebujesz 300% wiecej wydajnosci, a jak chcesz 2x wiecej detali w 3D to nagle 300% do 700%). I ten bonus moze zostac spieniezony tylko raz, bo D3D12 i Vk juz sa u granicy wydajnosci i wiekszosc i tak juz samo dzieje sie na GPU dzieki technika GPGPU.

Dlatego jesli chodzi o podnoszenie wydajnosci, wiecej zyzskasz przez zmiane algorytmu ktora wydajniej (asymptotycznie badz tez nie) bedzie sie sprawowac w wiekszej ilosci danych oraz komputacji, szczegolnie jesli w tym moga ci pomoc nowe instrukcje na GPU.

Dlatego np. tiled deferred przeskoczyło classical stencil-based deferred (dzieki compute shader), a deferred tylko przeskoczył forward bo nareszcie na ekranie pojawiło sie “wiecej” trojkatow niz pixeli (oraz depth buffer readback i MSAA textures)!

Po naszej stronie mamy np. compute shader central limit gaussian blur ktory jest szybszy niz Kawase blur na wszystkich kernel-sizes powyzej 15x15

I dzieki D3D12-level shader-intrinsics bedzie jeszcze tak z 3x szybszy niz jest teraz.

Drugi ważny punkt czas. Żeby napisać coś w D12/Vulkanie trzeba poświęcić więcej czasu na produkcję. Po co komuś by się chciało wydawać więcej pieniędzy tylko po to żeby kilku graczy to uruchomiło na swoich kompach? Poza tym popatrz sobie na steam. Większość użytkowników posiada Windowsa 7.

Z tym sie zgadzam, dlatego w release produktach jest API DX11, a w dziale R&D masz backendy na DX12 lub osobne projekty rendererow DX12 ktore czekaja na swoj dzien.

Te same argumenty toczyły sie wokoł DX10 i OpenGL 3.1 juz 10 lat temu w 2007 i dobrze je pamietam, “wszystkie gry na dx9”, “Call of Juarez działa szybciej na dx9 niz dx10”, “karty nvidii dx10 sa wolniejsze w grach dx9 bo maja wezszy bus pamieci”, etc. etc.

I zgadnij jak to sie wszystko skonczyło?

P.S. Coprawda ludzie przeskoczyli dx10 odrazu na dx11, i GL 3.1 na 3.3 ale “paradigm” (mysl/duch) programowania i API usage pozostał prawie taki sam i był tylko ewolucja poprzednika.


#12

Twoje argumenty są uzasadnione, ale nie zapominajmy o najważniejszym, że to rynek i człowiek wszystko zweryfikuje. Wejdzie nowa generacja konsol (pewnie 2020 albo 2021) to zobaczymy co się stanie, a póki co moim zdaniem nie ma sensu się to zagłębiać :slight_smile:.
Ja obstawiam, że wyjdzie D13 albo coś w ten desen tylko pod inną nazwą. Tak samo Vulkan pod inną wersją stanie się bardziej popularny. Obstawiałbym też, że prędzej czy później twórcy obu bibliotek je uproszczą przez co produkcja na te API stanie się tańsza a to już ogromny krok do tego żeby ten standard wszedł.
W gamedevie najważniejsze to jest czas i koszt produkcji, a nie finalny efekt mega super zoptymalizowanej gry. Wiem to bo w wielu firmach nauczyli mnie, że najpierw mam napisać kod tak żeby działał. Jak już działa i jest czas na zoptymalizowanie to się to robi jak nie ma to trudno. No chyba, że gra strasznie muli nawet na najlepszym sprzęcie :stuck_out_tongue:


#13

Moje 3 centy

Wejdzie nowa generacja konsol (pewnie 2020 albo 2021) to zobaczymy co się stanie

Jesli chcesz robic porta 1:1 shaderow napisanych na obecna generacje to potrzebujesz D3D12 lub Vulkana jesli nie chcesz sie zawezic do podwojnego kodu napisanego pod Nvidie i AMD na starych extensions. Na konsolach bardzo czesto uzywa sie operacji z AMD_shader_ballot i NV_shader_group_shuffle, i one naprawde daja kopa w compute shaderach od wszystkiego.

Przykład z zycia, mam funkcje w GLSL ktore sa wstanie zrobic operacje inclusive-scan na subgroupie bez uzywania shared memory w compute shaderze, efekt 400% szybciej i to na podstawowym sprzecie Nvidii.

Scan jest chlebem z masłem w dziedzinie GPGPU, od jego predkosci bezposrednio zalezy predkosc Summed-Area-Tables, Histogramming, Konwolucje, etc. , a na podstawie poprzednich algorytmow buduje sie Bokeh DoF, Soft-Shadows, Precomputed Light Scattering, Runtime Preconvolved Environment Maps do PBR, Autoexposure w Tonemappingu, Bloom, Radix Sort, GPU Particles.

Na konsolach trend GPGPU jest o wiele bardziej rozwiniety.

wyjdzie D13 albo coś w ten desen tylko pod inną nazwą. Tak samo Vulkan pod inną wersją stanie się bardziej popularny.

Absolutnie sie zgadza, tylko ze D13 bedzie miał bardziej podobne API do D12 niz D11 i bedzie jego logiczna ewolucja. Z Vulkanem tak samo, zobaczysz wiecej features, ale API sie nie “zdekomplikuje”.

Obstawiałbym też, że prędzej czy później twórcy obu bibliotek je uproszczą

Sam spec tego zabrania w pewnym zakresie (np. “dedicated memory allocations” to nie jest remedium dla braku własnego allokatora pamieci GPU), i to juz masz jasno wytłoczone w sekcji 2 Vulkan spec 1.0 i 1.1

API bedzie szedł do coraz nizszego low-levela, tak bardziej sie opłaca Vendorom, bo mniej skomplikowane sterowniki musza pisac i beda mieli mniej pracy, i o to własnie błagaja ludzie z DICE, Epic razem z Johnem Carmackiem. Przez ostatnia dekade były problemy ze standaryzacja komputacji na GPU, teraz nareszcie mamy jakies gwarancje na tym jak bedzie sie odbywac FloatingPoint-Math w shaderze!

Bilblioteki do tego sie pojawia, i juz sa BGFX, The Forge, V-EZ etc. to beda takie Boost’y do GPU tak jak mamy Boost do C++.
I tak wiekszosc game developerow bedzie kozystac z behemotow takich jak Unity lub Unreal .

Powiem tak, uczenie sie OpenGL, nie jest strata czasu bo skraca czas uczenia sie Vulkana.
Szczegolnie w zakresie GLSL jest w 99% ten sam pod VK.
Ale pisanie bilbliotek, framwork’ow oraz kodu do wykorzystania pozniej (w wiecej niz jednym duzym projekcie) jest raczej bardzo rzyzykowne (tutaj znowu ofc. wyjatkiem jest GLSL).
Jak człowiek juz duzo w OpenGL napisze to dochodzi do momentu kiedy API design bedzie sie naprzykrzał, i jak sie zacznie naprzykrzac (swoim performance, niestandardowym zachowaniem na roznych vendor’ach) to wtedy człowiek mazy o tym zeby sie przesiasc.

Vulkan i D3D12 to API dla ludzi ktorzy znaja juz OpenGL, D3D10/11 lub inne API dogłebnie lub przynajmniej napisali bardzo duzo aplikacji z uzyciem C++11 multithreading’u, Acquire/Release memory semantics oraz MPI