Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
válasz
julius666 #34 üzenetére
Aminek van egy jól definiált specifikációja, ami zárt, és zárt is maradt.
A Mantle shader modellje nagyon egyszerű volt az egy célarchitektúra miatt. Volt egy HLSL ext. kódod és lefordíthattad AMDIL binárisra, amit szállíthattál. Világos, hogy ez nem volt jó gyártófüggetlen formában.
Egyébként nem a shader nyelv a legnagyobb különbség, mert a SPIR-V nagyjából tudja azt, amit a HLSL ext. nyelv felkínált. Az AMD SPIR-V kiterjesztéseivel, még a szabványból hiányzó függvények is bekerültek. A fő eltérés a bekötési modell, ami a Mantle-nél pure bindless, míg a Vulkan esetében nem bindless, csak bindlessre kiterjeszthető, de ehhez már gyártói kiterjesztés kell. Annyit tudok, hogy a következő körben már lesz bindless bekötés ARB, és pure bindless AMD kiterjesztéssel. Ez igazából a Vulkan legnagyobb hátránya a DX12-höz képest, de valahogy csak túlélik majd a fejlesztők ezt az átmeneti időszakot.[link] - ebben van Vulkan driver. Bár igazából Linuxra rendes Vulkan alkalmazás nincs, viszont a The Talos Principle és a Dota2 megy rajta. Ugyanakkor mindkét programban csak tesztre van benne a Vulkan API. [link] - itt van teszt is a Dota2-ről Linux alatt.
-
julius666
addikt
míg a Vulkan a Mantle kódjára épül.
API-król beszélünk, kód nem nagyon van mögötte. Ez egy interfész.
Az meg oké, hogy a Vulkan API-ja nagyrészt a Mantle-ből lett "nyúlva", átnevezgetve, de pl. az egész lelke, a SPIR-V, az nagyon nem.
Illetve érdemes megjegyezni, hogy az általad leírtak ha igazak, az AMD-s implementáció már évekkel ezelőtt működőképes, demózható állapotban volt. Ehhez képest lásd a Mantle-ös csúszást, a release-t, vagy azt, hogy Linuxon a mai napig nincs rendes Vulkan driver pl. AMD oldalon, beelőzte mind a NVIDIA, mind az Intel.
-
TTomax
félisten
Én már azt szeretném látni,hogy ezekben az új apikban (DX12,Vulkan) működik már végre az MGPU,összeadódik a VRAM,működik a közös erőforrás kezelés stb és be is van végre építve valahol megmutatva azt hogy ez mennyivel jobb megoldás mint az AFR DX11ben...-ha -fog -lehetséges nélkül...
-
Abu85
HÁZIGAZDA
Mondjuk úgy, hogy több GPU szempontjából a DX11 és a DX12 között. Mert a DX11-nél nincs lehetőség még a több eszközerőforrás létrehozására sem. A Vulkan legalább erre lehetőséget ad.
Simán lehetséges. A driverek évek óta csinálják. Ez a rendszer AFR-friendly szinten átrakható egy programba. Teljesen mindegy a hardvernek, hogy a driver vagy az alkalmazás vezérli a VRAM-ot, ezen belül is a driver vagy az alkalmazás utasít másolásra.
De nyilván sokkal jobb a fejlesztőknek, ha a két GPU VRAM-ja összeadható logikai szinten, és ez hiányzik ma a Vulkan API-ból (erőforrások megosztása).
(#33) TTomax: Nézd meg: Ashes of the Singularity, Total War: Warhammer ... (Mantle-ben Civilization: Beyond Earth).
-
Abu85
HÁZIGAZDA
Mint írtam ez tisztán értelmezés kérdése. De hogy tisztán lásd a működést ... ha úgy tekintjük, hogy a Vulkan nem támogat több GPU-t, mert kötelezőnek vesszük az erőforrások megoszthatóságát a több GPU-s módhoz, akkor az SLI és a CrossFire sem rakható bele a több GPU-s kategóriába, mert azokból is pont ez a képesség hiányzik.
Ilyen értelmezéssel egyedül a DX12 explicit multiadapter az egyetlen több GPU-s rendszer.
A legjobb egyébként ezt úgy leírni, hogy a Vulkan a jelen formájában nem tud standard AFR-nél jobb több GPU-s módot támogatni. De egy standard AFR-t bármikor tudsz rá implementálni, ha a motor működése ezt megengedi.Ha nem lehetséges az erőforrások megosztása, akkor azt kell tenni, hogy memóriát tükrözni kell, vagyis a két GPU-hoz tartozó memóriaterületben ugyanannak kell lennie. Ezt szinkronizálnia kell a programnak (copy). Ugyanígy működik az SLI és a Crossfire csak ott a driver csinálja ezt a feladatot, mert az vezérli a VRAM-ot. De a program is ugyanígy képes erre, ha a fejlesztő megírja rá a támogatást.
-
TTomax
félisten
Igen csak az nem multiGPU support játékos szempontból,mint ahogy az első mondat állítja...tehát nincs!Pont...
Az hogy az api detektálja,önmagában egyértelműen kevés ha nem lehetséges az erőforrások megosztása.Az hogy te egyszerre két különböző dolgot tudsz számoltatni az nem MGPU support,azzal játékokban nem sokra mész... -
Abu85
HÁZIGAZDA
Kiemelem a lényeget:
"It is perfectly possible for a Vulkan implementation to expose multiple GPUs. What Vulkan currently can’t do is allow resource sharing between them."
Tehát megcsinálhatod rá a támogatást, mert képes a rendszer több GPU-t detektálni, csak azokat különállóként kell kezelni. De ha csinálsz rá egy implementációt, akkor különálló GPU-ként azt számolnak amit akarsz.
Amit a Vulkan 1.1 hoz az olyasmi rendszer, ami van a DX12-ben.Az már egyébként értelmezési kérdés, hogy mikortól tekintünk egy API-t multi GPU-t támogató API-nak. Elég ha képes több eszközerőforrást kreálni vagy ezek között kell az erőforrások megosztása is. Előbbi alapvetően elég, míg utóbbival sokkal könnyebb dolgozni, hiszen az egyik GPU elérheti a másik memóriáját, és nem kell szinkronizálni, illetve másolgatni.
-
TTomax
félisten
A linket elolvastad?Ott van leírva,nekik én jobban hiszek.
"There is no multiple GPU support in version 1.0. That was unfortunately a feature Khronos had to cut in order to preserve schedule. It is expected to be near the top of the list for Vulkan 1.1. It is perfectly possible for a Vulkan implementation to expose multiple GPUs. What Vulkan currently can’t do is allow resource sharing between them. So from a point of view of, for example, a Windows system manager, its possible to recognize multiple ways to render to a surface and then use operating system hooks to transfer that to the screen. What Vulkan doesn’t have is the ability to share a texture or a render target between multiple GPUs."
-
Abu85
HÁZIGAZDA
Légyszi olvasd már el amit írtam. A Microsoft letiltatta a Sapphire videóját, mert nem járultak hozzá, hogy ez az információ kiderüljön. Ellenben én még anno láttam, és ez volt benne. Eleve, ha megnézed a DX12-t és a Mantle-t, akkor a strukturális felépítésük a parancskreálás szempontjából ugyanaz. Nem véletlenül viccelődött vele Johan Andersson is, amikor bejelentették, hogy milyen ismerős. A Mantle-höz képest az explicit API-k a bekötési modell és az erőforrások kezelése szempontjából különböznek.
(#22) TTomax: A Vulkan API támogatja a multi GPU-t. Pont. A programok szabadon használhatják. Ellenben egy ID Tech6-ra megoldani elég nehézkes a megatextúrázás miatt. Az ID nem is igazán foglalkozik ezzel a kérdéssel, így az erőforrásaikat inkább shader intrinsicsre költötték. Nem megoldhatatlan egyébként, de azért a maréknyi felhasználóért nem éri meg dolgozni rajta.
-
Cathulhu
addikt
most lett nagykozonseg szamara is elerheto, most kezdtek el szeleskorben hasznalni, most jonnek igazan az igenyek es a fejlesztesi javaslatok. Indulo projekteknel igy szokott ez lenni.
Az androidos vilag meg ugyis ezt fogja hasznalni, igy az elterjedeset sem kell felteni. Reszemrol meg hajra Vulkan.
-
Abu85
HÁZIGAZDA
Van a Vulkan API-ban explicit több GPU-s módra támogatás. Az új verzió csak ezen javít. Például azt, hogy az egyik GPU a másik GPU memóriájában található textúrát felhasználhassa anélkül, hogy be kellene tölteni a saját memóriájába. Hasonló lesz a Vulkan Next multi-GPU-s tudása a DX12-höz.
-
Abu85
HÁZIGAZDA
2014-ben egy Sapphire által rendezett rendezvényen. Fent is volt youtube-on, de a Microsoft kérte a Sapphire-t, hogy töröljék le a videót, mert nem akarják, hogy kiderüljenek a részletek.
Maga a történek 2008-ban volt és 2009 végén mutatták meg a Microsoftnak a prototípus kódot. Ekkor a Mantle még nem is létezett, az AMD csak fejlesztgette ezt a kódot, főleg a Microsoftnak, illetve 2010-ben már a Microsofttal. A Mantle csak 2011 végén jött képbe, amikor Johan Andersson átutazott Kanadába Matt Skymerhez, hogy neki kurvára kell egy ilyen API. És nyilván tudott róla, hogy az AMD-nek van ilyen háttérprojektje, így az AMD megcsinálta a Mantle-t is. De eredetileg egyáltalán nem készített a cég egy saját API-ra. Persze utólag nagyon jó, hogy megcsinálták, hiszen felgyorsította az explicit API-k kihasználását, illetve a Khronos Group is felhasználta. -
TTomax
félisten
MultiGPU-t mikor akarnak támogatni?
-
Abu85
HÁZIGAZDA
Max és Richard egy korábbi előadáson mondta, hogy a DX12 úgy született meg, hogy az AMD rágta az MS fülét, hogy ezt lehetne jobban is. Azután az MS erre azt mondta, hogy akkor csináljátok meg. Egy évvel később az AMD megmutatott egy prototípus API-t a Microsoftnak, és ezt elkértét. Erre épülő a DX12. Illetve ennek a prototípus API-nak az eredménye lett maga a Mantle, míg a Vulkan a Mantle kódjára épül.
-
derive
senior tag
A Vulkan-OpenCL kozeledes tetszetos
Mar az OpenGLnel is hianyoltam, hogy nincs szorosabb kapcsolat.
-
arn
félisten
Az azert nem lenne rossz, ha nagyobb sikere lenne a dx elleneben, mint anno az openglnek volt.
-
imi123
őstag
Végül is már megérett a cserére a Vulcan.
Már egy játék használja.
Új hozzászólás Aktív témák
Hirdetés
ph A konzorcium beszélt az OpenGL ES-ről és az OpenGL-hez írt új kiterjesztésről is, és kifejezetten bíztató jövőképet vázolt fel.
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- Azonnali fotós kérdések órája
- Milyen széket vegyek?
- Vivo V40 5G - az első benyomás fontos
- Xiaomi 15 Ultra - kamera, telefon
- Fujifilm X
- Folyószámla, bankszámla, bankváltás, külföldi kártyahasználat
- Gyúrósok ide!
- Büszke apukák és anyukák topikja
- Asztalos klub
- További aktív témák...
- BESZÁMÍTÁS! Noctua NH-D15 chromax.black léghűtés garanciával hibátlan működéssel
- Bomba ár! Lenovo ThinkPad T470s - i5-6GEN I 8GB I 256GB SSD I 14" FHD I Cam I W10 I Garancia!
- ÁRGARANCIA!Épített KomPhone i9 14900KF 32/64GB RAM RX 9070 XT 16GB GAMER PC termékbeszámítással
- Felújított laptopok / PC-k Számlával, garanciával! Ingyen Foxpost! 05.03
- BESZÁMÍTÁS! 380GB Intel Optane 905P NVMe SSD meghajtó garanciával hibátlan működéssel
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest