UUSIMMAT

Vulkan tositoimissa: Ensimmäiset testit Talos Principlellä

21.02.2016 17:10 | Petrus Laine | 11

20160221vulkanspock

Khronos julkaisi uuden Vulkan-rajapintansa 1.0-version aiemmin tällä viikolla. Pöly julkaisun ympärillä ei ehtinyt vielä edes laskea, kun Talos Principle -pelin kehittäjä Croteam ilmoitti pelin saaneen päivityksen myötä tuen uudelle rajapinnalle.

Nyt nettiin on putkahtanut myös ensimmäiset testit Talos Principlestä Vulkan-rajapinnalla verrattuna Direct3D 11- ja OpenGL-rajapintoihin. Testituloksia katsellessa on syytä muistaa, että pelin kehittäjä Croteam on kertonut tuen olevan lähinnä proof-of-concept -tason toteutus, jota ei ole optimoitu pelin muiden tuettujen rajapintojen takia, ja vielä toistaiseksi bugisen tuen on tarkoitus vain osoittaa Vulkanin toimivan. Sama pätee sekä AMD:n että NVIDIAn Vulkan-beeta-ajureihin, jotka ovat vielä kaukana yhtiöiden muiden ajureiden tasosta. Croteam itse uskoo, että kehittyvien ajureiden ja pelin puolelta paremmin toteutetun renderöijän myötä Vulkan-suorituskyky tulee ohittamaan Direct3D 11:n myös Talos Principlessä.

20160221vulkan2gb

AnandTechin testit osoittavat saman mielenkiintoisen kehityksen, joka oli ajoittain nähtävissä myös Vulkanin aloituspisteenä toimineella Mantle-rajapinnalla: 2 Gt:n muistilla varustetut näytönohjaimet ovat enemmän tai vähemmän ongelmissa suurempimuistisiin veljiinsä verrattuna. Toistaiseksi ei ole selvää, onko ongelma itse rajapinnoissa vai kehittäjien tottumattomuudesta uusiin rajapintoihin ja niiden ominaisuuksiin. 2 Gt:n muistilla varustettujen näytönohjainten kohdalla Vulkanin suorituskyky oli 1080p-resoluutiolla noin 2,5 – 5 % heikompaa kuin OpenGL:llä.

20160221vulkanhiend

Suorituskykyisemmät näytönohjaimet pääsivät testiin myös muilla sivustoilla. Radeon R9 Fury X:n suorituskyky nousi AnanTechin ja ComputerBasen testeissä resoluutiosta riippuen noin 10 – 85 %, keskimäärin noin 44 %. GeForce GTX 980 Ti sai puolestaan samoilla sivustoilla resoluutiosta riippuen 5 – 45 % lisää suorituskykyä, keskimääräisen parannuksen asettuessa reiluun 25 prosenttiin. Vulkan-suorituskyvyllä on kuitenkin vielä pitkä matka Direct3D 11 -verrattuna. Edellä mainituilla sivustoilla Vulkan-suorituskyky oli sekä R9 Fury X:llä että GTX 980 Ti:llä noin 73 % Direct3D 11 -suorituskyvystä.

Myös GamersNexus on ajanut testit Vulkanilla, mutta näytönohjaimina toimivat Radeon R9 390X ja GeForce GTX 980 Ti, eikä OpenGL-testejä ajettu lainkaan. GamersNexuksella Vulkan rajapinta tarjosi 1080p-resoluutiolla R9 390X:llä noin 33 ja GTX 980 Ti:llä noin 23 % heikompaa suorituskykyä kuin Direct3D 11. 4K UHD -resoluutiolla erot kasvoivat entisestään, ja Vulkanin suorituskyky oli R9 390X:llä noin 39 ja 980 Ti:llä noin 27 % heikompaa kuin Direct3D 11:llä.

Ars Technica puolestaan kiinnostui muista poiketen prosessorisuorituskyvyn vaikutuksesta Vulkaniin. Sivusto ajoi testit Intelin Core i5-5930K -prosessorilla 1080p- ja 1440p-resoluutioilla Radeon R9 290X- ja GeForce GTX 980 Ti -näytönohjaimilla. Toisessa testeistä prosessorissa oli käytössä kaikki kuusi ydintä ja Hyper-threading-tuki päällä, kun toisessa simuloitiin i5-suorituskykyä ottamalla käyttöön vain neljä prosessoriydintä ilman Hyper-threading-teknologiaa. Kenties monelle pettymykseksi, prosessorilla ei ollut testeissä juurikaan merkitystä rajapinnasta riippumatta, vaan erot menivät käytännössä virhemarginaalin piikkiin. Ainut mahdollisesti virhemarginaalin ulkopuolelle sijoittunut tulos oli R9 290X:n neliydin tulos Vulkanilla, joka oli 4 FPS heikompi kuin kuudella ytimellä ja kahdellatoista säikeellä.

Linux-puolella on toistaiseksi päästy testaamaan vain NVIDIAn näytönohjaimia. Phoronixin ajamissa testeissä Vulkan-suorituskyky ei maalaa esille yhtä mairittelevaa kuvaa kuin Windows-puolella. Phoronix ajoi testit GeForce GTX 680-, GTX 960-, GTX 980- ja Titan X -näytönohjaimilla. Vulkan-suorituskyky oli jokaisella heikompi kuin OpenGL:llä eron vaihdellessa GTX 680:n noin 23 % hitaammasta Titan X:n noin 9,5 % hitaampaan.

AnandTech, Quick Look: Vulkan Performance on The Talos Principle

Ars Technica, Vulkan benchmarks: A boost for AMD and Nvidia, but there’s work to be done

ComputerBase, First benchmarks of the new API in Talos Principle (Google Translate)

GamersNexus, Initial Vulkan Benchmark vs. DirectX 11

Phoronix, Early OpenGL vs. Vulkan Linux Benchmarks With Talos Principle

Keskustelu

Helvetin tyhmää ajella 980ti refulla testejä jonka suorituskyky tippuu kun lämmöt nousee tuohon ~80c tuntumaan ja siittä asteittan kellot laskee niin paljon kun on tarve.
Jos tulosten laskeminen aloitetaan heti testin alusta, saadaan 980ti referenssillä parempi tulos kuin rasituksen jälkeen aloitettu mittaus.

Eli onko tuosta testiä 980Ti customilla, jonka suorituskyky ei ole riippuvainen paskasta jäähystä, Näkis aidot jäähystä riippumattomat tulokset paljonko Vulkanilla saadaan hyötyä Vs OpenGl

Ylipäätään vituttaa kaikki Nvidian paskat referenssi jäähyt ja niillä ajetut tetit, koska käytännössä Custom malli on aivan erikortti suorituskyvyn suhteen. (Eli 980ti custom käyttäjät eivät saa tästä edes suuntaa antavaa tietoa koska Referenssin ja Custom mallin erot ovat parhaillaan melkoisenkin hurjat.)

Nvidia saa haista V** kun on ylipäätään tuonut HighEnd ohjaimet 980/Ti TitanX markkinoille näin aneemisen paskalla jäähyllä.
Mutta nämä kaikki luumut esim 950/960/970 on kyllä varustettu alkuperäisesti kunnon custom jäähyillä.

Graffaa koodanneethan ymmärtävät, että Vulkan ei missään tapauksessa ole plug and play -vaihtoehto OpenGL:lle tai Direct3D:lle. Enginedevareiden harteille jää nyt paljon osa-alueita, joista ovat huolehtineet ennen korkeamman tason rajapintojen kehittäjät. Tulee menemään aikaa, että moottoritiimit oppivat hyödyntämään heille avautuneita mahdollisuuksia sekä räätälöimään optimointeja juuri heidän tarpeilleen sopiviksi. Suoraan sanottuna en ole lainkaan yllättynyt saaduista tuloksista.

LehdaRi

Graffaa koodanneethan ymmärtävät, että Vulkan ei missään tapauksessa ole plug and play -vaihtoehto OpenGL:lle tai Direct3D:lle. Enginedevareiden harteille jää nyt paljon osa-alueita, joista ovat huolehtineet ennen korkeamman tason rajapintojen kehittäjät. Tulee menemään aikaa, että moottoritiimit oppivat hyödyntämään heille avautuneita mahdollisuuksia sekä räätälöimään optimointeja juuri heidän tarpeilleen sopiviksi. Suoraan sanottuna en ole lainkaan yllättynyt saaduista tuloksista.

Toisaalta Direct3D 12 on antanut selvästi isompia suorituskykyparannuksia monessa kohtaa, ja kuuluu Vulkanin tavoin näihin matalan tason rajapintoihin joissa vastuuta on siirretty kehittäjille

Talos Principle varmaan surkein mahdollinen esimerkki minkään rajapinnan suorituskyvystä. Mutta ilmeisesti ainoa tällä hetkellä, eli surkeinkin on saanut kelvata.

Varsinkin kun tuo Vulkan tuki tuossa pelissä ei ole edes natiivi. Se on surkeasti toteutettu wrapperi, joka ei ilmeisesti tue edes multi-threadingia. Eli tässä käännetään DirectX käskyjä Vulkan wrapperin kanssa. Samanlailla kun heidän OpenGL toteutus, joka on wrapperi.

LehdaRi

Graffaa koodanneethan ymmärtävät, että Vulkan ei missään tapauksessa ole plug and play -vaihtoehto OpenGL:lle tai Direct3D:lle. Enginedevareiden harteille jää nyt paljon osa-alueita, joista ovat huolehtineet ennen korkeamman tason rajapintojen kehittäjät. Tulee menemään aikaa, että moottoritiimit oppivat hyödyntämään heille avautuneita mahdollisuuksia sekä räätälöimään optimointeja juuri heidän tarpeilleen sopiviksi. Suoraan sanottuna en ole lainkaan yllättynyt saaduista tuloksista.

Sepä se, ei ne vanhemmat rajapinnat olleet ihan turhaan "bloatteja ja hitaita" vaan se abstraktiokerros piilotti hyvin cpu <=> gpu -viiveitä sun muuta mistä pitää nyt osata huolehtia itse DX12/Vulkanilla. Toki vastapainona voi saada suorituskykyetuja jos tietää mitä tekee ja API overhead tai yhden säikeen submit on oikeasti ongelma. Sinällään ei yllätä yhtään nämä tulokset jos on portattu joku vanha rendaaja Vulkanille.

Suorituskykyparannuksista ja jostain draw calleista hehkuttaessa kaikki riippuu niin paljon implementaatiosta ja testien asettelusta, GL:lläkin saa miljoonia draw calleja läpi sekunnissa jos vain spämmää batcheja muuttamatta tilaa mikä ei oikeasti ole kovin realistinen tilanne koskaan. Vanhat APIt on helppo saada näyttämään naurettavan hitailta uusiin nähden jos PR-puolella niin halutaan.

Kaotika

Toisaalta Direct3D 12 on antanut selvästi isompia suorituskykyparannuksia monessa kohtaa, ja kuuluu Vulkanin tavoin näihin matalan tason rajapintoihin joissa vastuuta on siirretty kehittäjille

Jep, on tottakai antanut isompia suorituskykyparannuksia, koska kyseiset muut Direct3D 12 testit ovat olleet natiiveja. Kun taas Talos Principlen moottori ei pyöritä Vulkania vielä lainkaan (pellin alla pyörii ainoastaan D3D).

Juuna_

Jep, on tottakai antanut isompia suorituskykyparannuksia, koska kyseiset muut Direct3D 12 testit ovat olleet natiiveja. Kun taas Talos Principlen moottori ei pyöritä Vulkania vielä lainkaan (pellin alla pyörii ainoastaan D3D).

Onko sulla tälle jotain oikeaa lähdettä takana? Ihan uteliaisuudesta, tuo kuitenkin on viety myös mm. Linuxille

Kaotika

Onko sulla tälle jotain oikeaa lähdettä takana? Ihan uteliaisuudesta, tuo kuitenkin on viety myös mm. Linuxille

Kyllä. Talos Principlen kehittäjät ovat kertoneet käyttävänsä wrapperia. Tähän mennessä OpenGL ratkasu on ollut wrapperi (D3D -> OpenGL), joka tietenkin pyörii hitaammin. Koska wrapperi joutuu reaaliajassa kääntään käskyjä D3D:stä OpenGL:lle, eikä luonnollisesti voi pyöriä alkuperäistä rajapintaa nopeampaa edes ihanteellisissa olosuhteissa. Nyt he ovat toteuttaneet Vulkan tuen samalla tavalla, D3D -> Vulkan wrapperi.

D3D -> OpenGL wrapperista on tiedetty jo pitkään (ja monet firmat käyttää vastaavaa ratkaisua). Mutta tässä on lähde Vulkan wrapperin käytöstä kohdassa 1:

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

ja kohdassa 2 hän kertoo ettei Vulkan wrapperi edes tue vielä monisäikeisyyttä. Linkki vielä tuonne missä vastaus löytyy. https://steamcommunity.com/app/257510/discussions/0/412447331651559970/#c412447331651997070
Ilmeisesti natiivi Vulkan tuki tulee joskus hamassa tulevaisuudessa.

Siis eihän tuossa puhuta että käytettäisiin D3D:tä taustalla eikä siinä olisi järkeä vaan että Vulkan-rendaaja on varsin primitiivinen. Wrapper tuossa yhteydessä on lähinnä rajapinta joka sallii monisäikeisen rendaajatoteutuksen tekemisen, sellaista ei vaan vielä löydy:

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.

SuperD

…eikä siinä olisi järkeä…

Eihän siinä mitään järkeä olisikaan (vaikkakin näin on toimittu jo vuosia OpenGL porttauksien kanssa). Mutta ei kuulosta kovin lupaavalta, kun ensimmäisen isosti mainostetun Vulkan pelin kehittäjä kertoo, että pelimoottorin tämän hetkinen Vulkan toteutus perustuu kolmeen keskeiseen osaalueeseen. Jossa heti ykkös kohdassa puhutaan nykyisen moottoritoteutuksen wrappaamisesta Vulkanin ympärille. Joko kehittäjän sanavalinta oli erittäin huono kun puhuivat wrapperista, tai sitten käyttävät oikeasti wrapperia joka selittäisi susipaskan suorituskyvyn. Joka tapauksessa tuo kehittäjän kommentti on herättänyt netin keskustelualueilla aika paljon keskustelua. Ja selvennystä kaipaillaan, mikäli haluavat vakuuttaa ettei kyseessä ole wrapper purkkaviritys.

Wrapper tuossa yhteydessä on lähinnä rajapinta joka sallii monisäikeisen rendaajatoteutuksen tekemisen

Miksi käyttää wrapperia edes tuohon, kun kerran Vulkan tarjoaa monisäikeisyyttä jo natiivisti? Selvästi kehityksessä otetaan oikopolkuja, kun eivät halua lisätä Vulkanin ominaisuuksia natiiviksi osiksi pelimoottoriin, vaan purkkavirittelevät ne osittain sinne. On se tietenkin rahallisesta näkökulmasta ymmärrettävää, kun ei haluta kirjottaa pelimoottoria puoliks uusiksi.

Juuna_

Eihän siinä mitään järkeä olisikaan (vaikkakin näin on toimittu jo vuosia OpenGL porttauksien kanssa).

Joo kun halutaan halvalla & nopeasti portata jokin peli Linuxille tai Macille, tässä ei ole sama tilanne. Suorituskyvyssä ei ole mitään erikoista ihmeellistä sinällään ekaksi Vulkan-toteutukseksi.

Miksi käyttää wrapperia edes tuohon, kun kerran Vulkan tarjoaa monisäikeisyyttä jo natiivisti? Selvästi kehityksessä otetaan oikopolkuja, kun eivät halua lisätä Vulkanin ominaisuuksia natiiviksi osiksi pelimoottoriin, vaan purkkavirittelevät ne osittain sinne. On se tietenkin rahallisesta näkökulmasta ymmärrettävää, kun ei haluta kirjottaa pelimoottoria puoliks uusiksi.

Koska noiden rendaaja itse ei ole rinnakkaistettu. Rinnakkaisuuden lisääminen jälkikäteen ei tapahdu helposti, nyt niiden toteuttamisessa on enemmän pointtia nykyisillä rajapinnoilla. Graffarajapinnan kanssa keskusteleva koodi on vain osa pelin rendaajaa ja jos muu puoli (esimerkiksi näkyvien objektien hakeminen) on yhdessä säikeessä tapahtuvaa kamaa niin mikään Vulkan tai DX12 ei paljoa auta rinnakkaisuudessa.

Muropaketin uusimmat