Új hozzászólás Aktív témák
-
#2
fatpingvin
őstag
#88750080
#1
fatpingvin
őstag
én inkább azt a kérdést feszegetném hogy ezt a directx nevű koloncot minek rángatja magával még mindig az ipar... régen át kellett volna már állni a teljesen nyílt API-kra...
A tipikus munkafolyamat legjobb tesztszimulációja a tipikus munkafolyamat. A "napi anti-corporate hsz"-ok felelőse :)
-
Abu85
HÁZIGAZDA
Éppenséggel a Vulkan az a nyílt API, ami zajos siker lett a Khronosnak. Rengeteg projekt épül rá, és nagyon szépen fejlődik. Van hozzá support, nagyon jó debugger, stb. Pont arra példa, hogy ezt jól is lehet csinálni, nem csak szarul, mint az OpenGL-nél.
És az Apple eszközeire szép számmal érkeznek a Vulkan játékok a MoltenVK-n keresztül. Tehát oké, hogy van Metal API-juk, de natívan azt ritkán támogatják. Ez teljesen logikus sok fejlesztő részéről. Valamelyik más platformra úgyis van Vulkan kód, ami meg fut a MoltenVK-n, ami meg kis sebességvesztés árán fut a Metal eszközökön.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
#88750080
#10
üzenetére
Meg van számos Vulkan cím Windowsra is. Ráadásul kevesen tudják, de a mai motoroknak van Vulkan és D3D12 leképezője is. Célszerű mindkettő implementálni, mert nem különbözik annyira a két API, hogy gondot jelentsen, és a Vulkan is megeszi a HLSL shadereket, hiszen lefordíthatók SPIR-V-re. Azért nem szokott általában két API-val megjelenni egy adott játék, mert az plusz karbantartási költség, de maga a leképező minden motorban támogatva van és fejlődik. Az OpenGL-nél ilyen nem volt. Az annyira különbözött, hogy nem is implementálták.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#12
fatpingvin
őstag
#88750080
#10
fatpingvin
őstag
válasz
#88750080
#10
üzenetére
elég vicces ahogy arra utalgatsz hogy baj lenne egy olyan API létezése és fejlesztése ami linuxon ÉS windowson is működik, mert hogy csakawin és csakadx a jó.
amiket te próbálsz panaszként felhozni az az OpenGL-re talán valóban igazak lehettek, az ugyanis tényleg csak egy standard keretrendszer, a Vulkanra ez viszont már rég nem igaz.
A tipikus munkafolyamat legjobb tesztszimulációja a tipikus munkafolyamat. A "napi anti-corporate hsz"-ok felelőse :)
-
Abu85
HÁZIGAZDA
válasz
#88750080
#13
üzenetére
Mitől halad a Vulkan az OpenGL felé? A kiterjesztésektől? A DirectX 12-ben is vannak képességek, amelyek meglétét előbb ellenőrizni kell, mert nem minden DirectX 12-es hardver támogatja. Aztán erre vannak feature_level összesítések, így elég csak ezt csekkolni, amire szintén van a Vulkan API-ban verziócheck, ami bizonyos kiterjesztéseket kötelezővé tesz. De ahogy a Vulkan API-ban a legmagasabb verzió sem tartalmazza az összes kiterjesztést, úgy a DirectX 12-ben a legmagasabb feature_level sem tartalmazza a legjobb képességeket, tehát mindkét oldalon van egyedi per feature és kiterjesztés szintjén ellenőrzés. Tehát a kiterjesztések ugyanúgy megvannak a DirectX 12 oldalán is, csak feature néven.
Az alapvető eltérés annyi, hogy a Vulkan lehetővé teszi már az API-hoz illesztve a gyártói kiterjesztéseket, míg a Microsoft esetében ehhez gyártói szervizkönyvtár kell. Például az AMD-féle AGS tele van DirectX 12 kiegészítésekkel. És ez nem jobb a Vulkan-féle gyártói kiterjesztéseknél, mert kell egy extra könyvtár használata az implementálásukhoz. Vulkan esetében elég csak a kiterjesztést meghívni, nem kell pöcsölni szervizkönyvtárakkal.
Az más kérdés persze, hogy a fejlesztők pöcsölnek vele, sőt, az Ubisoft éppen olyan motort írt az új Snowdrop kapcsán, aminek az alapvető működésébe is beleavatkozik az AGS, tehát nem csak egy-két effekt miatt lesz benne, hanem konkrétan máshogy számol sugárkövetést, ha az AGS be van töltve. És ez nem kis költség ám a fejlesztés oldalán, mert kell egy fix AGS specifikáció az AMD részéről, hogy az jó sok évig ne változzon, ugyanis, ha módosítják az AGS runtime-ot egy friss driverben, akkor az az Ubisoftnak szar, mert nem működik tovább a motorjuk. Ez valamivel kellemesebb a Vulkan oldalán a gyártói kiterjesztésekkel, mert specifikusak ugyan, de idővel a nagy részük át lesz emelve EXT-be, onnan pedig a KHR-be. És nem szoktak jelentősen változni, így utána lehet menni a szabványosításnak egy patch-csel. Az AGS-ből viszont tudod mikor lesz átemelve valami a DirectX 12-be? Soha. Tehát az Ubisoft AGS kódja szabványosíthatatlan, azt jól át kell írni, ha a Microsoft szíveskedik azt a képességet beépíteni a szabványba, amit az Ubisoft használni fog.
Szóval egyáltalán nem rosszabb a Vulkan a DirectX 12-nél használhatóságban és fejleszthetőségben sem. És a kiterjesztések sem teszik tönkre, mert hasonló opciók más formában a DirectX 12-höz is vannak, csak nem kiterjesztésnek hívják, hanem inkább kiegészítésnek.
#14 ervinke78 : A Vulkan API-hoz írt fejlesztőeszközöknek is van supportja. Elég jól működő. Annyira, hogy még a DirectX 12-höz is nagyon sok stúdió RenderDoc debugot használ. Egyszerűen most ez a legjobb a piacon.
Meg az Androidot, meg az Apple cuccokat a Metal miatt, meg bármi, ami esetleg jön, mert Vulkan mindenre lehet, DirectX viszont nem. Az Xboxhoz pedig úgyis van a motornak DirectX 12 leképezője. Ahogy fentebb írtam, manapság tipikus, hogy mindkét API-t támogatja egy motor, mert a Vulkan is meg tudja enni a HLSL shadereket a SPIR-V-n keresztül, tehát a két API nagyon hasonló működése miatt olcsó mindkettőt beépíteni. Az OpenGL-nél ez azért nem működött, mert nem ette meg a HLSL shadereket, és úgy már százezer sornyi kód módosítása lett volna a support, ami egyszerűen sok.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#17
fatpingvin
őstag
#88750080
#13
fatpingvin
őstag
válasz
#88750080
#13
üzenetére
nem tudom hallottál-e róla, de amilyen tájékozotnak próbálsz tűnni, elvárnám: nem csak a MS vacka létezik a világon.
that being said, abszolúte semmi bajom nem lenne a directx-szel ha a microsoft nem őrködne felette tyúkanyó módjára hogy más platformon ne lehessen normálisan natívan implementálni mint open standard.persze, csinálják ha jó nekik, otthon négy fal között, és ne erőszakolják rá az iparágra a hülyeségeiket olyan módon ami elveszi a teret a nyílt, szabadon felhasználható és implementálható megoldásoktól.
bár ezt a szempontot te láthatóan nem tudod értelmezni, szval inkább hagyjuk is. elvégre csak az üzemben lévő számítógépek nagyobb részéről beszélünk (mielőtt valami okos rákezd hogy de hát desktop: szerinted mondjuk egy GPU computing szerver mit használ?)A tipikus munkafolyamat legjobb tesztszimulációja a tipikus munkafolyamat. A "napi anti-corporate hsz"-ok felelőse :)
-
#88750080
törölt tag
válasz
#88750080
#26
üzenetére
Ezt a #15-re akartam válaszolni.
Jut eszembe, ha már felhoztad, hogy HLSL-t lehet SPIR-V-re fordítani... ez is azért van, mert ahogy mondtam, a Vulkan megjelenésekor nem volt egy épkézláb fordító. A Khronos specifikálta a bájtkódot, csak nem lehetett miről arra fordítani. Ezért szétnézett az iparágban, és már nem is emlékszem, melyik céggel csináltatott egyet, ami GLSL-ről tudott a bájtkódjukra nem túl optimálisan fordítani. Vagy generáltad kézzel a kódot, vagy volt egy egyszál glslang.exe.
A MS ezt az űrt töltötte be a saját új fordítójával, márcsak azért is, hogy a HLSL nehogy (hirtelen) teret veszítsen egy másik fordító kárára, ha esetleg előáll egy ilyennel valaki.
Új hozzászólás Aktív témák
ph A friss kiterjesztéssel közelít a DirectX 12 működéséhez a Khronos Group API-ja.