Nevim. Zaostavat o 20% v alfaverzi mi neprijde zly. A pokud bude ve finale o 10% vykonnejsi, tak to muze byt rozdil mezi hratelny/nehratelny. Myslim ze je trochu brzo na to soudit jaky bude vysledek.
Navic jestli to chapu spravne, tak Vulkan muze hodne pomoct napr. lidem co maji "prilis" silne GPU v pomeru k CPU.

Hlavní výhoda Vulkanu je v tom, že má být rychlejší, pokud je úzkým hrdlem výkon procesoru.

Tady jde vidět, že úzkým hrdlem je výkon GPU, protože se výsledky mění podle rozlišení. Tudíž zde efektivita API nehraje roli, ale ukazuje se tu, jak dobře je implementováno programování GPU (např. kompilátor shaderů má významný vliv na výsledky).

Využití Vulkanu bych spíš viděl u her náročných na draw calls, jako např. strategie. Zrovna ve hře tak jednoduché na vykreslování z pohledu CPU jako Talos Principle to nemá šanci být vidět.

Začinam rozmyšlať ci nečitam stale dokola rovnaku pesničky o tom ako to treba cele od zakladu nakodit a do puntiku optimalizovat. Pretože pokial sa takto isto vyladia hry pod DX11 tak CPU limit je minimalny a hry behaju ako z praku, stači ked sa pozriem na pecky ako Zaklinač 3 alebo starši Battlefield 4 v MP. Pokiaľ bude potrebne vyvinuť maximalne usilie aby sme mali aspon o 10-15% lepsi vykon v bežných hrach oproti DX11 tak to vidim velmi biedne s novymi APIs. Taky DX12 obmedzeny navyse len na jeden OS pouzije par odvažnych hlavne tych co podporuje AMD. Inak to vidim naozaj dost biedne s rozsirenostou tychto na kodenie naročných API. Hlavne pokial tu mame uz zabehnute- odladene enginy a hry pod DX11 nevidim velku motivaciu zo strany developerov investovat obrovske množstvo usilia do niecoho čo prinesie tak maličky benefit za tak velku cenu.

Mnoho z vas tu ma skreslenu predstavu, ze hned ako zacnem pouzivat nove API tak automaticky ide vykon hore. Blbost. Vulkan aj DX12 su hodne explicitne a zlozite API. Napr. tutorial na vykreslenie jedineho trojuholnika vo Vulkane ma 2500 riadkov kodu! Podobnu vec by ste v OGL zvladli radovo na par stoviek. Takze naucit sa v tom chodit bude chciet cas, najma co sa tyka synchronizacii, spravy pamate a pod...

Myslim ze to urcite nadsenie z kazdeho noveho API alebo novsej verzie existujucich API ma na svedomi hype (to nechutne nedavno spominane slovo :-)) a tak trochu aj novinari a celkovo firmy ktore to prezentuju (teda hlavne hw vyrobcovia v tomto pripade) pretoze im to moze logicky zdvyhnut predaje. Vsetci by asi boli radi ked by stacilo na existujucom HW akurat zmenit kniznicu a zrazu by stupol vykon o 20-30-50%. Ale to by skor hovorilo bud o nejakom fakt zlom prvotnom navrhu alebo bugu pri vydani co sa predsa len tak casto nestava (teda s tak fatalnym dopadom na vykon)
Vulkan aj DX12 nieje o koncovych zakaznikoch a vlastne ani priamo o vykone. Doterejsie API limitovali pocet spominanych drawcalls ale aj napriklad komunikacia s gpu (renderview) iba z jedneho threadu (ogl). To docela komplikuje navrh enginu ako aj jeho optimalizaciu a skalovanie. Nieje to neriesitelne ale stoji to cas a tym aj financie. Vulkan a DX12 by mali toto riesit. Jednak moznostou lepsieho vyuzitia viacerych jadier na cpu a tym aj viacerych threadov na pracu s grafikou ako aj vecsieho poctu drawcalls a dalsich funkcii. Je to ale trochu aj za cenu jednoduchosti (vulkan). Toto ale umozni vyvojarom zjednodusit navrh enginu alebo pridat niektore moznosti ktore boli doteraz narocne.

Pokud to dobre chapu, Talos Principle zatim misto plne implementace pouziva jen jednoduchy jednovlaknovy wrapper. Pro vysvetleni - zde je vyjadreni vyvojare z Croteamu k tomu, proc je vykon zatim suboptimalni a co jeste zbyva udelat:
( zdroj: https://steamcommunity.com/app/257510/discussions/0/412447331651559970/#p2 )

****************
Edwin,

engine design for Vulkan is basically consited of three major parts:\

1)
Port. Make it work as fast as possible just by wrapping current engine design around Vulkan. Avoid all pitfalls and bottlenecks. This is what we did by now and released as patch for Talos.

2)
Use Vulkan for multi-threaded rendering. Our engine is designed really well for multi-threaded rendering, but we have only our wrapper for it - calls to graphics API (like Vulkan) are not multi-threaded. Yet.
That being said, this is the next step what we'll do. And probably release that also as patch for Talos. I tried to do that with Direct3D 11 long time ago (support for its deffered contexts), but it was too much pain and too little or even no gain. :( That's just one of reasons why we decided to stick with our own approach for MT renderer for that long. :/

3)
Redesign engine for Vulkan. This is the biggest step and can be split in two:

3a)
Precache all rendering states (which mostly mean materials in game) up front. This will make rendering calls much simplier and faster. So, instead of deciding at rendering time what is needed for a material to be rendered via Vulkan, do this at loading time and then when material needs to be rendered just give it to Vulkan, via one or two simple function calls.

3b)
Precache all geometry, material, textures, everything that is needed for rendering an object up front. This basically creates so called command buffer ready for Vulkan, and nothing extra needs to be set or created at render time.

3rd part of port is, obviously, the most complex one, and it'll take time to change engine design for it, step-by-step.

Hope I explained this well. :)
DEN
****************

Pre mna je studena sprcha neexistujuci vyvoj technologi za posledne roky. Toto aspon niekam smeruje. To kam este len zistime. Dufam ze nie tam kam predpokladam ..

není uz na case testovat ve 4k ? omg :(

Jestliže to jede jen na 1 threadu tak je to parádní výsledek jak proti OGL tak proti DX11 kde to jede multithread.Nebo se pletu ? Navíc je to první verze ovladače.

Na první nehotovou verzi, na které běží něco, co je od začátku počítá s DX11 je to imho výborné...