Przygotowuję prezentację tego API "for dummies" ( niestety nie publiczna ) i tak szukałem, czy nie ostały mi się gdzieś na dysku moje pierwsze eksperymenty z Vulkanem i znalazłem poniższe. Po kliknięciu w grafikę przeniesie na pastebin, ale grafikę zostawiam, by zamęczyć wasze myszory scrollowaniem ( jakieś ~970 linii kodu ) Jak doskrolujecie do końca, to dowiecie się, co zajebistego za pomocą Vulkana ten kod robi



Teraz odkrycie wielkiej tajemnicy: ten kod otwiera okno 640x360 i... czyści je na czerwono ( no dobra, co klatkę animuje kolor, ale to 3 dodatkowe linie ) Prawie 1000 linii by wyczyścić okno na czerwono i w dodatku nic nie narysować

i na uj sie tak meczyc ?

:uczulony po to by taki Doom mógł wyciągnąć te 2000FPS A poważnie, to jest spory "game changer" w świecie gier oraz w świecie producentów sprzętu. Do tej pory z każdą większą grą AAA nVidia czy AMD wypuszczały nowy driver, który zawierał hacki dla tej konkretnej gry. Teraz nie będzie to odpowiedzialnością producenta sprzętu. Każdy deweloper może zrobić dokładnie to, co producent karty graficznej wcześniej implementował na poziomie drivera. To powinno odchudzić nieco drivery i dać kopa silnikom graficznym, które wcześniej miały problem z powodu opóźnień na driverze. To też wymaga kompletnej zmiany w architekturze silników ( postawienie na wielowątkowość, DoD, skalowalność itp. ). Akurat szlaki przetarte tu zostały kilka lat temu za sprawą PS3 - ta maszyna wymusiła na deweloperach korzystanie z wielowątkowości i multirdzeniowej architektury.

Teraz to się wkrada do świata PC ( obecna generacja konsol została już u podstaw zaprojektowana pod kątem maksymalnego wykorzystania zasobów sprzętowych ). Jeszcze niedawno ignorowało się to czy CPU ma być 4 czy 8 rdzeniowy, jaka jest wielkosć cachu w CPU itd. Dziś to ma coraz większe znaczenie, bo o ile nowoczesna karta graficzna robi swoje dosyć szybko, to jeśli gra jest "cpu-bound" to szybkie GPU w niczym tu nie pomoże ( no nie do końca, ale tu znów trzeba odpowiednio zmodyfikować architekturę silnika ).

tl;dr

PS Po co scrollować, gdy na klawiaturze jest przycisk End? :P

Leży i czeka. Jakoś mnie efekt końcowy (ponad 1000 linii kodu) zniechęca

https://av.dfki.de/~jhenriques/development.html

Swoją drogą, to to ma bindingi do Pythona?

Nie wiem czy ma binding do Pythona, ale nic nie stoi na przeszkodzie, by miało. Na pewno nie bedzie to pochodziło od Khronosa. Co do tego tutoriala, który podlinkowałeś, to po prostu jest to przejechanie po przykładowym kodzie z SDK. Problem leży gdzie indziej - masa rzeczy nie jest w ogóle udokumentowana i na razie deweloperzy zgadują co i jak. Ja jestem w nieco lepszej sytuacji, bo mam pod ręką ludzi, którzy to projektowali ( choć nie bywają w biurze często ). W każdym razie jutro jadę do Cambridge posłuchać nieco więcej o Vulkanie od ludzi z nVidii, ARMa, no i od nas Najbardziej mnie interesuje, kiedy wypełnią pustą dokumentację. Zastanawia mnie też to, że np. nVidia nie podąża za specyfikacją i to może prowadzić do problemów ( w stylu "a u mnie działa" ). No ale pisania w **uj, żeby cokolwiek pojawiło się na ekranie

:Uczulony Jak jest płacone od godziny, to nikt nie mówi o żadnym męczeniu.

Zaś 1000 linii do zrobienia byle gówna idealnie wpisuje się w standardy Enterprise Grade Software