Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
A Vulkan az 1.2 óta eleve támogatja a HLSL-t. A shader modell 6.2-ig minden le van fedve a SPIR-V 1.5-ben. [link]
Egyébként új hardver nem kell. Az új DXR fejlesztések minden tudnak szoftveresen futtatni, ha az új lépcsőknek nincs hardveres háttere. Az egész DXR-nek meg van írva a teljes fallback compute shaderre. Ugyanígy a Vulkan API-ban is lesz egy compute shader fallback, ha a hardver nem alkalmas az egyes lépcsők gyorsítására. Vagy azért, mert nincs benne megfelelő célhardver, vagy mert az elavulttá vált.
-
Abu85
HÁZIGAZDA
Eleve nem lesz két memória a játékhoz. A másik arra szolgálhat, hogy a segédprocesszor futtassa az OS-t.
A konzolokon pedig van közvetlen memóriavezérlés. A PC-n azért kell sok RAM, mert az OS menedzseli az allokációt, elég rosszul. Egy konzolon az alkalmazásnak a feladata ez, és az sokkal hatékonyabb, mert alkalmazáshoz szabott allokáció van töredezettségmentesítéssel. -
Abu85
HÁZIGAZDA
Ennél sokkal több kell az exascale szintű skálázhatósághoz. Nem véletlen, hogy háromból egyben sincs NVIDIA. Ilyen méretben óriási hátránnyá válik a gyártók keverése, amíg nincs egy igazán jól működő szabványos megoldás a skálázhatóság problémájára.
Az IBM-mel pedig azért gyorsabb az NV, mert máshogy lehet összekötni a gyorsítókat ilyen formában, de ez nagyon kevés az exascale rendszerekhez. Ilyet tudni fog a Milan+CDNA is az AMD-nél, de mégsem erre építi a DoE az exascale megrendeléseit, mert úgy kell kialakítani a konfigurációt, hogy minden gyorsító össze legyen kötve a procival, és a gyorsítók is legalább egy gyűrűs kapcsolatra fel legyenek fűzve.
Ha tényleg csak annyi lenne, ahogy leírod, akkor a sok CUDA kód nyerné az NV-nek a tendereket, de baromira bonyolultabb a probléma ekkora méretben, ami más hardveres dizájnt követel, és ezért bevállalják a kódkonverziót is. Ugye nincs más választásuk. Nyilván nekik is sokkal egyszerűbb lenne az Intel és AMD procik mellé NV gyorsítókat kérni, csak a tervezett méretben sajnos nem működik.
-
Abu85
HÁZIGAZDA
Sajnos nem. Az exascale skálázhatósághoz nem elég csupán a GPU-kat összekötni egy gyors memóriakoherens interfésszel. Szükséges az is, hogy a CPU-kkal is meglegyen ez a kapcsolat. Na most a szuperszámítógépekbe használatos node-oknál nem igazán használnak ilyen megoldást, mert például az IBM-nek nincs nagy haszna abból, ha csak egy gyorsítóra korlátozza le a processzoraik használhatóságát, annyira általánosra tervezik a procit, amennyire lehet. Az Intel és az AMD azért tudja ezt megcsinálni, mert saját maguk csinálnak CPU-t és GPU-t is. Egyszerűen arra koncentrálnak, hogy legyen meg az általános gyorsító használatának a lehetősége, de azért hoznak kompromisszumokat, hogy a saját interfészeik előny élvezzenek. Ráadásul a többséget az is akadályozza, hogy a piac nagyon-nagyon-nagy része x86/AMD64.
Ha annyira egyszerű lenne ez, hogy mehetne az IBM/NV, akkor nem maradtak volna ki háromból három exascale projektból. Azért korábban ezeket az SC tendereket rendre behúzták. Ehhez képest az egyik projekt konkrétan kockáztat az Intel GPU-val, nincs más választás, ha a CPU is Intel.
-
Abu85
HÁZIGAZDA
Ez a szerverpiac. Az AMD CDNA-ba rak csak IF-et. Az RDNA nem valószínű, hogy valaha megkapja, legalábbis nem annyi linkkel, amennyivel a CDNA.
A lényeg itt az Intelnél és az AMD-nél is az, hogy csináljanak egy saját interfészt, amivel összekötik a CPU-ikat és a GPU-ikat. Ettől persze megmarad a PCI Express, de az nem lesz memóriakoherens. Majd talán a PCI Express 6.0-tól, de ez nagyon talán. Annyi viszont látszik, hogy máris nyerik az Exascale tendereket, és ehhez csak annyi kellett, hogy csináljanak egy-egy specifikus összeköttetést, amit csak ők támogatnak, és ettől a CPU kiválasztása eldönti a GPU kérdését is. -
Abu85
HÁZIGAZDA
válasz
wjbhbdux
#40767
üzenetére
Nem igazán. A professzionális piacon kívül semmiképpen. Túl drága az SSD, és a szükséges NYÁK is. A koncepció azonban platformszinten létezik az AMD-nél, csak az alaplapgyártók hozzák be, vagyis oda kell majd berakni az SSD-t, és azokat tudják majd címezni a Radeonok. De ez az AMD megoldása, nekik egyszerűbb, mert nem csak VGA-kat árulnak, így az olcsó megoldást is választhatják.
(#40768) Shing: Már ma sem nehéz olyan hardvert összerakni, amit leírtál. Egyszerűen megveszed a legjobb, vagy a második legjobb Threadrippert, és abba raksz 128 GB memóriát. Még a 6-7 GB/s-os PCIe4-es SSD sem probléma. Nem nagy kunszt tehát ilyen gamer PC-ket építeni, csak baromira drága. A konzol ára után legalább egy extra nulla, ami azért nem mindegy.
A mai játékok eleve a streamingre épülnek. Az összes modern motor ilyen, az hogy most ötször dob egy loadingot egy pályán vagy 50-szer, a technikai működés szempontjából teljesen mindegy. Ez egy rendkívül jól paraméterezhető működés, tehát nem szükségszerű a PC-be 6-7 GB/s-os SSD, maximum nem egy, hanem 10 loading screen lesz. De a futtathatóság szempontjából egyáltalán nem probléma.
-
Abu85
HÁZIGAZDA
Nem csak. Ott van még más is tárolva, például a geometria.
De fog fejlődni a grafika. Ma már eleve nem férnek bele a mai tipikus VRAM mennyiségbe a játékok. Emiatt a motorok régóta streaminget alkalmaznak. A töltés itt nem annyira fontos, az nem csak ettől függ, de a nagyobb részletességhez a több VRAM, vagy ennek a hatékonyabb kihasználása hozzájárul.
A konzolon nem az alacsonyabb API miatt jobb a memória felhasználása, hanem amiatt, hogy az alkalmazások memóriaelérése közvetlen. PC-n ez nem lehetséges, mert nincs két ugyanolyan rendszer, de konzolon mindegyik gép ugyanaz, tehát az alkalmazás bátran hozzáférhet fizikai szinten is a memóriához. A PC-n ezt mindig az OS fogja kezelni, az alkalmazás csak fölötte tud menedzselni. Ez olyan nagy hátrányt egyébként nem okoz, mert veszel a PC-be kétszer-háromszor több memóriát, mint ami a konzolban van, és nem baj, ha az OS pazarol.
(#40746) b. : Most ha a konzolt mindenképpen idekeverjük, akkor a next-gen fő attrakciója az a szupergyors SSD. A PS5-nek van egy olyan módja, hogy maga az alkalmazás lesz a memória. Úgy veszi a rendszer, hogy az SSD-n elfoglalt hely a fizikai memória, és onnan cache-sel a valós fizikai memóriába, ami alapvetően gyorsítótárként működik. Ennek egy része leválasztható, így az valóban gyorsan elérhető memóriaként funkciónál. Ennek az egyetlen haszna, hogy olyan világokat lehet létrehozni, amelyek a mostaninál sokkal-sokkal nagyobbak, de mégsem lesz egyetlen töltőképernyő sem a játék kezdetétől a végéig. De a PC-ben ez sem jelent problémát, mert a streaming rendszerek nem újdonságok, annyi fog történni, hogy a PC-s port időközönként bedob egy loading feliratot, tölt egy-két percig, majd mehet a játék tovább. Ez igazából a konzolon is előfordulhatna, csak úgy tervezik meg az alkalmazást, hogy ismerik a gép adottságait, lényegében tudják, hogy milyen gyors az SSD és a memória, és ehhez tudják tervezni az egész játékot. A PC-n is előhozható ez a működés, ha beledobsz egy mondjuk egy 6-7 GB/s-os SSD-t a proci vezérlőjére kötve, plusz jó sok memóriát használsz. Valószínűleg ilyenkor egy PC-s portnál is eléggé minimális lenne a loading felirat.
(#40749) Ragnar_: Annyira sok VRAM annak nem kell. Az lényegében ugyanazokból a tartalmakból él, mint a raszterizáció. A létrehozott pufferek, amik fogyasztják extraként a VRAM-ot.
(#40755) b. : A mostani és az új konzoloknak is lesz olyan módja, amikor az OS fog babáskodni a memória felett, ahogy ez PC-n is működik. A legtöbb kis gépigényű cím konzolokon is így működik, mert ez a legegyszerűbb fejlesztői szempontból. A jövőben sem lesz ez másképp. A többi mód igényelhető. A PS5-nek megmarad a közvetlen hozzáférésre vonatkozó módja, ahogy ilyen a PS4-ben is van (5,x GB-ot kaphat közvetlenül az app és a maradékon ott az OS), illetve lesz még egy új mód, ami a memória egy részét cache-ként használja, és az SSD-n lévő tartalmat is memóriának tekinti. Valószínűleg az új Xboxban is lesz hasonló. Utóbbi egyébként úgy leszimulálható PC-n, hogy SSD-t raksz a VGA-ra, lásd a Radeon Pro SSG. Ha nagyon nagy adatmennyiségről lenne szó, és túlzottan sok lesz a loading felirat, akkor lehet, hogy elmennek erre a cégek.
-
Abu85
HÁZIGAZDA
válasz
Crytek
#40359
üzenetére
Messze van a csúcsok csúcsától.
Akinek a legjobb kell, eleve a zsebébe nyúl. Sokba kerül a Nitrous, de az kétségtelenül a legjobb, valóban licencelhető videojáték-motor. Csak nagyon drága, emiatt annyira azért nem használják. Az olcsó megoldások közül a Unity a legjobb. Csak ugye ez is úgy olcsó megoldás, hogy drágább, mint egy UE. Ha mondjuk grafikailag kell jó, és alapból jól futó motor, akkor ott a CryEngine, de annak más nyűgjei vannak, tehát az se leányálom.
Egyre jobb megoldásnak tűnik egyébként a Lumberyard, valószínűleg ez lesz leginkább az ellenfele a Unity-nek. Ha az AWS Gaminget jól kötik vele össze, akkor az baromira nagy előny lesz ám. -
Abu85
HÁZIGAZDA
Eleve nincs olyan, hogy kész engine. Az UE például folyamatosan fejlődik. Sosincs kész. Alapvetően az UE esetében nagyon kell vigyázni az egyes verziókra, mert kifejezetten rossz lehet a sebesség, ha nem jól van használva. Ez az Unreal Engine hátránya, rohadt szarul fut, mert abszolút nem teljesítményorientáltra tervezik a motort, ellenben tud egy rakás olyan dolgot, amit más motor meg nem. Autós analógiával élve az Unreal Engine egy Landrover, csak sokszor neked nem Landroverre van szükséged, mert versenypályára mész, ahol full sima az aszfalt, így többet ér egy túraautó, amilyen a Unity, vagy egy együléses nyitott versenyautó, amilyenek az egyedi motorok, mint a Nitrous vagy a Frostbite. Ezeknél viszont arra kell vigyázni, hogy földútra nem jók, de aszfalton úgy helybenhagyják az UE-t, hogy megéri ilyenekben utazni.
Egyébként ha valaki indie, tehát nyilván nem fognak tudni valami szuper motort venni, mert akkora a licencköltség, hogy esélytelen abba beleugrani, akkor a legjobb választás a Unity. Az UE-nek csak a marketingje jó. Valójában messze elmarad a Unity mögött technikailag. De az is igaz amúgy, hogy a Unity meg drágább, és sokaknak még erre sincs extra pénz, hiába sokkal jobb.
-
#40338
Abu85
HÁZIGAZDA
huskydog17
#40337
Abu85
HÁZIGAZDA
válasz
huskydog17
#40337
üzenetére
Ha elolvastad volna a hsz-t, akkor láthatnád, hogy a 4.21-es verziót azért jelölte meg, mert annak van egy specifikus problémája, ami korábban nem volt, és a 4.22-re meg is oldódott. Egyszerűen a 4.21-es verzió ritka körülmények között működik hatékonyan. Ha nem úgy használod, akkor sok sebesség megy a levesbe.
Nem is kell alapvetően programozó. A motort kell beállítani. Például 4.21-en a Vulkan API-t érdemes használni, vagy ha a DX11 fontos, akkor a 4.22-re kell frissíteni legalább. Egyébként meg alapvetően a 4.21-es verziót érdemes kerülni.
-
#40336
Abu85
HÁZIGAZDA
huskydog17
#40335
Abu85
HÁZIGAZDA
válasz
huskydog17
#40335
üzenetére
Nem ezen múlik. Nem a motor a lényeg, hanem az RHI. Az UE4 a 4.21 óta kétféle konfigurációt kínál, mert már támogatja a Vulkan API-t is. De a Vulkan API-val az eredeti RHI lassú, viszont a motort annyira átírták, hogy ezzel az eredeti RHI-val lassú lett maga a feldolgozás. De gond egy szál se, mert ennek a problémának a kezelésére jött az explicit parallel RHI, amivel lényegében az RHI-k skálázhatók lesznek a többmagos processzorokon. Viszont a DirectX 11-nél ezt a módot külön kérni kell, és a tapasztalat azt mutatja, hogy nem igazán működik vele jól. De ezt a gondot is orvosolták a 4.22-ben, csak a 4.21-es még lassú vele. Így gyakorlatilag a 4.21-es motor egy fura hibrid lett, amivel a DirectX 11 azért lassú, mert az explicit parallel RHI kezelésével gondja van, de a motort meg nem a fallback módra optimalizálták. A legegyszerűbb megoldása egyébként ennek a 4.22-es verzióra való ugrás, de az Obsidian is mondta szeptemberben, hogy egyszerűbb DirectX 12-re váltani, mint verziót cserélni.
Ez a probléma egyébként meglátszik a motor általános teljesítményét. A 4.21-es verzióval dolgozó játékok (Star Wars Jedi: Fallen Order, The Outer Worlds) nagyon lassúak ahhoz képest, ahogy kinéznek. Például egy Gears 5 alapja nagyjából ugyanaz, de mégis nagyságrendekkel jobban néz ki, és jobban is fut. Viszont a Gears 5 jelentősen átírta az RHI-t.
-
Abu85
HÁZIGAZDA
válasz
FLATRONW
#40333
üzenetére
Nincs baja vele, ha az engine verziót a target RHI-vel használod. Vagy esetleg módosítod, hogy működjön az explicit parallel RHI. A Respawn nem módosította, illetve a fallback RHI-t használja. A 4.21 óta az UE4 target RHI-ja a VulkanRHI. Működik a fallback DX11, de már magát az RHI-t nem erre az API-ra írták. Ez jelentősen befolyásolja a feldolgozást, mert az Unreal Engine a 4.21 óta explicit parallel RHI-ra van optimalizálva, és fallback mellett ez nem használható.
Ugye itt nagy kérdés, hogy mi lesz, mert a The Outer Worlds is így jelent meg, de ott ugye kapásból mondták, hogy hoznak egy DirectX 12 módot később, amivel lesz explicit parallel RHI, amivel sokkal gyorsabban fut az Unreal Engine 4.21-es verziója.
-
Abu85
HÁZIGAZDA
válasz
keIdor
#40303
üzenetére
Bocs, de amúgy kap optimalizálást a Pascal. Azt kell megérteni, hogy ami jó a Pascalnak, az igazából nem éppen jó a Turingnak, illetve a GCN/RDNA-nak. Működnének mondjuk azzal, ha az erőforrások nem éppen úgy vannak lehelyezve, ahogy az API előírja, mert van némi rugalmasság a D3D12-ben és a Vulkánban is, de jobban szereti a Turing/GCN/RDNA, ha szépen a specifikációnak megfelelően van megírva a program (az erőforrások a halmazokba vannak bedobva, stb.). Ettől gyorsabbak lesznek, nem sokkal, pár százalékkal, de számít. A Pascal viszont nagyon nem szereti, ha így van megírva az alkalmazás, egyszerűen lassul tőle, és amíg mondjuk aközött kellett választani, hogy a GCN lassul mondjuk 1-2%-ot, vagy a Pascal 8-12%-ot, addig ez egyértelmű volt. Ma viszont már nem az, főleg azért, mert a Turing az erőforrások nem specifikációknak megfelelő elhelyezését nem csak -1-2%-kal tolerálja, mint a GCN/RDNA, hanem -4-5%-kal is. És így már inkább megéri a Pascalra rakni -8-12%-ot, hogy a Turing mehessen normális tempóval. De ez nem azt jelenti, hogy a Pascal nem kap optimalizálást, csak a fontos döntéseket inkább a kárára hozzák meg. Viszont az optimalizálásnál valószínűleg nagyon figyelnek arra, hogy ami a Turing/GCN/RDNA hardvereknek nem káros, ott a Pascal legyen előnyben, hogy visszahozzák, amit elvesztenek az erőforrások elhelyezésénél.
-
Abu85
HÁZIGAZDA
Persze tudja. Az RTX-es dolgok csak extra részegységek bizonyos extrákhoz, de az architektúra alapvető működése mindegyik Turing GPU-ban egyforma. Ez látszik a tesztekben a 16-os sorozat teljesítményén is. Ha megnézitek igazából csak a Pascal szenved, a többi hardver nagyjából a helyén van. Ez nem azt jelenti, hogy nem lehet ezen még javítani, mert valószínűleg lehet még találni "up to" 3-4%-nyi szunnyadó tempót.
-
Abu85
HÁZIGAZDA
válasz
Locutus
#40289
üzenetére
Tudják hozni a teljesítményt most is. A Pascallal van gond, de ott eleve arról van szó, hogy a hardver nagyon limitált, mivel képtelen egy halmazba helyezni a különböző erőforrás-kategóriákat. Ez az RDR2-nél fontos, és nyilván ezen hardveres módisítás nélkül nem fognak felülkerekedni. De láthatod, hogy a Turing már tudja ezt a képességet, és annak az architektúrának a teljesítménye a megfelelő szinten van. +/- 3-4%, de ezek származhatnak szoftver oldali tényezőkből. A Pascalnak a problémáján egyszerűen szoftveresen nem tudnak felülkerekedni, ahhoz nagyon mélyen át kellene dolgozni a motornak a működését, de ha ezt megcsinálják, akkor az meg negatívan érintené a Turing/GCN/RDNA teljesítményét, amelyek kifejezetten kedvelik azokat a szituációkat, amiket a Pascal tulajdonképpen utál.
-
Abu85
HÁZIGAZDA
válasz
Locutus
#40266
üzenetére
Természetes, hogy a Vulkan API alatt megy valamivel jobban. Ahogy írtam az erre vonatkozó hírben is, a fejlesztést a Stadián végezték, ami a Vulkan API-t támogatja. Ez a Google számára egy teszt volt, hogy egy ekkora projekt PC-re portolásához alkalmas-e a Stadia. Emiatt elsődleges API a Vulkan, de van támogatás a DirectX 12-re is, mert alapvetően a két API nagyon hasonló, tehát nem jelent komoly munkát egyszerre támogatni őket, főleg olyan költségvetésnél, amivel a Rockstar dolgozik. Viszont maga az RDR2 a memóriamenedzsmentre nagyon egyszerű megoldást használ. Egyszerűen az AMD memory allocation library komponenseire építenek, viszont ez sokkal régebb óta van Vulkan API-n, és sokkal többet tud, mint a D3D12-es verziója, tehát valamivel gyorsabb. Nem mellesleg van már Stadia optimalizált verziója is. Sokkal egyszerűbb ezeket a headereket csak bedobni a projektbe, aztán működik out-of-box, mint írni egy sajátot, de az egyszerű copy-paste módszerrel sajnos másolod a D3D12-es verzió gyengeségeit is. Végeredményben amúgy mindegy, a Vulkan API-t kell használni, ez is a default.
-
Abu85
HÁZIGAZDA
válasz
keIdor
#40261
üzenetére
Nem csak annak a kérdése. A trükk alapvetően a wave programozás. A mai PC-s játékok többsége még mindig az elavult shader programozást követi, nagyrészt a legacy kódok miatt, amit nyilván elfogadnak az API-k, de a mai hardverekre ezek nem optimálisak. Viszont ha mondjuk két explicit API-t célzol, akkor azt nyilván egy shader nyelvből akarod megtenni, jelen esetben a HLSL-ből, és ott például olyan kód kell, amit a SPIR-V-re elég jól le tud fordítani a Glslang. Ez nagyjából a shader modell 5.x-et foglalja magába. Ennél jobb shader modellre a Spiregg kellene, ami ugyan létezik, de még messze nem olyan jó, mint a Glslang, tehát egy nagyobb projektnél meggondolandó, hogy a wave programozást, mint lehetőséget választod, vagy azt, hogy legyen egy stabil rendszer a HLSL kódok D3BC-re és SPIR-V-re fordítására. Utóbbi kifizetődőbb, mert kevesebb lesz vele a szopás. Viszont a shader modell 5.x nem definiálja a wave-level operációkat, vagyis effektíve csak egy szálra levetített feldolgozási modellt kínál, amit ugyan megesznek a mai GPU-k, de explicit erőforrás-korlátozások kellenek ahhoz, hogy a feldolgozás párhuzamosítása garantálható legyen. Emiatt jött be a shader modell 6, aminél már erre nincs szükség, pusztán a wave terminológia garantálja, hogy a lane-ek egymás mellett futhatnak, és ehhez semmilyen direkt beavatkozás nem szükséges. Na most konzolon ez egyszerű, már a kezdeti évek óta így lehet ezeket a gépeket programozni. PC-n is lehetséges, de legalább HLSL shader nyelv 2016-os specifikációja kell, ami nem lenne nagy gond, ha a program csak DirectX 12-t támogatna, ugyanis csak annyi változna, hogy a bájtkód nem D3BC-ben, hanem DXIL-ben lenne szállítva. Viszont azzal, hogy a Vulkan is támogatott, már át kellene konvertálni a wave terminológiát is az újabb SPIR-V-re. Maga az API támogatja ezt, a subgroup utasítások néven fut a funkció, és a World War Z már használja is: [link]. Csak ehhez ők elég sok shadert direkten módosítottak, és valószínűleg az RDR2 annyira nagy projekt, hogy ez önmagában nem éri meg. De abszolút nem a konzol fixfunkciós hardvere dönt jelenleg, hanem az, hogy a Rockstar nem akar a Spireggre menni, így a PC-re szállított shaderek jóval lassabbak, mint a konzolon futók.
-
Abu85
HÁZIGAZDA
válasz
Habugi
#40246
üzenetére
A probléma a Pascal esetében a hardverben keletkezik. Rakhatsz akármennyi időt az optimalizálásba, ha maga a motor úgy van megírva, hogy erősen épít arra, hogy az egymástól megkülönböztetett erőforrás-kategóriákat egy halmazban kezeli. A Pascal erre nem képes, így külön halmazok kellenek neki minden csoportosított erőforrásra, és ezt ugyan lehetővé teszik az API-k, de sebességben hátrány. Esélytelen, hogy ezt a hátrányt bármilyen szoftveres optimalizálással visszahozd.
-
Abu85
HÁZIGAZDA
Ezt korábban is írtad, és írtam rá, hogy rendelhetők, szállítják még idén: [link]
Azóta már a Dell is eldöntötte, hogy hozzák a cuccukat.
Az meg nem vita tárgya, hogy rárúgták a szerverpiacra az ajtót. [link] - az ilyen alázás ritka a szerverpiacon. Nem véletlen, hogy a Sapphire Rapids gyorsabban jön, mert addig nem tud az Intel a Rome közelébe sem kerülni. De egyébként a gyártói doksikban még a Sapphire Rapids-re sem mondják egyértelműen azt, hogy meg tudják verni vele a Rome-ot, ami azért kellemetlen, mert a Genoa lesz a versenytársa, ami a Milan utáni nagyobb fejlesztés. Azt nehéz meghatározni, hogy a Genoa mire lesz képes. A Milan némileg egyszerűbb, nagyjából ugyanezek a paraméterek, nagyobb lesz a cache, az órajel, kb. találhatnak +20-30%-ot, maximum, de ennyi. Szóval az nem lesz ilyen Naples-Rome közötti hatalmas ugrás. Ellenben a Genoa esetében sok a nehezen helyrerakható infó, ami jön a gyártóktól, például a sokkal több szál, az in-package HBM3 a CPU chipletek mellett, utóbbi nehézzé teheti a teljesítmény belövését. Viszont nem lenne újdonság. A Fujitsu is ezt csinálja a Post-K-val, és eléggé jól döntöttek, mert még a DDR5 is kevés lenne etetni azt a 48-magos szörnyet.
-
Abu85
HÁZIGAZDA
válasz
Yutani
#40116
üzenetére
Van egy rakás shaderjük HLSL-ben gondolom. Azért bizonyos HLSL kódokat SPIR-V-re fordítani még mindig nem túl kedvező.
Emellett a toolok tekintetében sokkal kényelmesebb a DirectX 12. A PIX pokolian jól összerakott fejlesztőeszköz, és az AMD, az Intel, illetve az NVIDIA is nagyon jól kezelhető vele. Vulkan API-n hasonló képességet a Renderdoc+RGP ad, de ez csak az AMD hardvereket támogatja. Az Intel és az NVIDIA hardvereit nem tudod mivel profilozni, fényévekre járnak az eszközeik a Renderdoc+RGP lehetőségeitől. -
Abu85
HÁZIGAZDA
válasz
FLATRONW
#40114
üzenetére
[link] - ezen ne csodálkozzunk, az Unreal Engine 4 DirectX 12 leképezője sok szempontból nagyon elavult. Az Epic a Vulkanba rakja a pénzét, és a DirectX 12-t nem fejlesztik vele, vagyis ezt a licencelőknek kell megcsinálni. Ha erre nincs erőforrás, akkor inkább ajánlott a Vulkan leképezőt használni, mert azzal foglalkozik az Epic.
-
Abu85
HÁZIGAZDA
válasz
Kolbi_30
#40101
üzenetére
A Pascal sem kamu DirectX 12. A Pascal architektúra problémája ennél az API-nál az, hogy bizonyos erőforrásokat el kell szeparálni a memóriahalmazokban, míg a Turingnál, illetve a GCN/RDNA-nál erre nincs szükség. Ez a memóriavezérlés tekintetében problémás, mert utóbbira érdemes optimalizálni, az előbbit pedig csak lekezelni, viszont ha ezt a problémát csak kezeled, akkor az gond a Pascal teljesítményére, mivel ilyenkor az történik a kódban, hogy az egyes erőforrások a leíróhalmazokban kerülnek, csak a szeparálás miatt több ilyen lesz a kelleténél. Emiatt van az az ajánlás, hogy az erőforrásokat ne is rakják a fejlesztők leíróhalmazba, hanem dobják be a root signature-be, de ugye ez nem olyan egyszerű, mert a root signature-t nem buffer viewekre találták ki, tehát számos formátum így nem is támogatott, vagyis végeredményben a leíróhalmazok alkalmazása elkerülhetetlen. A problémát tehát ezek idézik elő, és ezt kell kitesztelni a Pascal esetében. De ha ez a kód nem jó, akkor instabil lesz a Pascal. Viszont maga az API nem instabil, eleve nem is támogatja azt, hogy a buffer viewek a root signature-be kerüljenek, ezt csak beleerőszakolják oda a fejlesztők, csak ezt a Microsoft nem ajánlja, mert nem erre tervezték az API-t. Inkább érdemes elviselni, hogy a Pascal lassul a leíróhalmazokba pakolt buffer viewektől, mert az igazodik az API működéséhez. Az újabb játékok, például a Control már ilyen. No persze ott meg a barrierek és a szinkronizálás van elcseszve, ez a másik problémás rész.
-
Abu85
HÁZIGAZDA
válasz
Yutani
#40098
üzenetére
Semmi baj nincs vele. Maga az API tényleg nagyon átgondolt, meg a Vulkan is, nagyjából 95%-ban ugyanaz, mindkettő. Kicsit bonyolultabb a Vulkan a memóriamenedzsment tekintetében, ami abból adódik, hogy a DirectX 12 az már teljesen bindless, de ez igazából nem vészes, annyit jelent a program oldalán, hogy kb. pár száz sorral hosszabb lesz egy Vulkan leképező memóriamenedzsmentje.
Ami fontos a fejlesztők tekintetében, hogy ha vesznek valami általános motort, pl. Unreal Engine 4 vagy Unity, akkor azt az explicit API-t használják, ami nagyobb támogatást élvez. Mindkét esetben a Vulkan az, ha viszont DirectX 12-t használnak, akkor ami nincs megírva ezekben a motorokban, azt írják meg, vagy ott az AMD-nek a MA header, és akkor elég a copy-paste is.
A meghajtóknál pedig nem igazán éri meg játékspecifikus fordítót csinálni, mert ezt egy programverzióra rá lehet optimalizálni, de amint kap az alkalmazás egy frissítést, rögtön hasztalan lesz minden módosítás, és írni kell egy újít, vagy jönnek a crash-ek. De ennek nem az API vagy a játék az oka, hülyeség +4-6%-ért ilyen optimalizálásokat csinálni, amikor havi egy alkalommal van frissítés az egyes online játékokhoz. Lehet, hogy az a +4-6% teljesítmény a tesztekben jól mutat, de a gyakorlatban csak probléma lesz. -
Abu85
HÁZIGAZDA
válasz
Raggie
#40089
üzenetére
Nem az API a hibás. A Borderlands 3 esetében a memóriamenedzsment a gond. Ezt úgy fogják orvosolni, hogy az egészet úgy ahogy van kicserélik az AMD által írt D3D12 Memory Allocatorra. Viszont ezt nem tudják csak úgy kiadni, mert utolsó pillanatban hozott döntés, és nincs elég teszt erre vonatkozóan.
A probléma onnan származik, hogy az Unreal Engine 4 DirectX 12-re írt memóriamenedzsmentje nem thread-safe. Tehát nincs garantálva, hogy többszálú feldolgozásnál hibátlanul működik. Ellenben a Borderlands 3 többszálú parancsgenerálást használ, amivel az erőforrások létrehozása is többszálú. Na most a thread safety probléma kezelésére van beépítve a motorba egy olyan rutin, amely ellenőrzi folyamatosan, hogy az adott erőforrás használatban van-e, és ez okozza a rendkívül rossz működést. Ennek a megoldása az Unreal Engine 4 esetében az, hogy a rendszer csak erősen korlátozottan használjon többszálú parancsgenerálást, úgy, hogy ne kelljen alkalmazni ezt a rossz hatásfokú rendszert. A másik lehetőség a Vulkan, ugyanis a Vulkan API tekintetében az Unreal Engine 4 már thread-safe memóriamenedzsmentet használ, csak az erre vonatkozó fejlesztések, még nem kerültek visszaportolásra a motor DirectX 12 leképezőjébe.
A harmadik lehetőség írni egy egyedi DirectX 12-es memóriamenedzsmentet az Unreal Engine 4-be, vagy beépíthető az AMD D3D12 Memory Allocator, ami eleve thread-safe megoldás. Viszont az Unreal Engine 4 miatt ebbe is lehet, hogy módosítás kell, mert ezt a memóriamenedzsmentet az AMD az erőforráshalmazra vonatkozó specifikációknak a tier_2-es szintjére írta, és ugyan kezeli a tier_1-et is automatikusan, csak szimplán olyan egyszerű megoldást alkalmaz rá, hogy elszeparálja az erőforrásokat és kész. Szóval valószínűleg lesznek itt is módosítások még, bár kiindulásnak jó.
-
Abu85
HÁZIGAZDA
Igazából, ha HDMI 2.1 van a kijelzőn, akkor működnie kell, mert a HDMI 2.1 VRR az szabványos, és a szoftver, amit az NV csinált az ezt célozza. Persze nem mondhatják rá, hogy tutibiztos, de mivel nem HDMI-s FreeSync-féle zárt rendszerről van szó, így egyik gyártó sem csinál eltérő dolgokat, amelyeket külön le kellene kezelni.
-
Abu85
HÁZIGAZDA
válasz
Locutus
#40073
üzenetére
Egyszerű. A HDMI 2.1-es bemenet mellett már rá lehet tervezni a kijelzőket a VRR-re, és ezt igazából ki lehet használni HDMI 1.4-es vagy HDMI 2.0-s VGA-val is. Az egész egy szoftver. Hasonló az AMD-nek a HDMI-s FreeSync-jéhez, csak ott az a különbség, hogy nem kötelező a HDMI 2.1-es bemenetű, VRR-t támogató kijelző, mert az AMD kiegészítette magának a HDMI-t, míg az NV egyszerűen felhasználja a HDMI 2.1 specifikációját. Utóbbi miatt szükséges a HDMI 2.1-es bemenetű, VRR-t támogató megjelenítő, de a VGA oldalán ennek nincs igazán hardveres követelménye, 5-6 generációra is vissza lehet portolni. Ugyanakkor a régi hardverekre már nem éri meg. Nem hoznak már pénzt, miközben a szoftverimplementáció portolása viszonylag drága lenne.
-
#40062
Abu85
HÁZIGAZDA
Petykemano
#40061
Abu85
HÁZIGAZDA
válasz
Petykemano
#40061
üzenetére
Attól függ, hogy a benchmarkot tesztelték-e. Az szándékosan lett a GPU-ra kiélezve. A 3 player co-op részét pedig nem igazán lehet tesztelni egy benchmarkkal, de persze annak a terhelése elsődlegesen a procira esik rá, mert a GPU ugyanazt számolja, mint single módban.
A parancsgenerálás nem áll meg 6 szálnál. Mivel explicit, ezért ez lényegében addig skálázódik, ameddig csak lehet, viszont az Unreal Engine 4-nél 20 szál a limit. De ez csak mesterségesen van meghúzva, mert azért nem csak az API lehetőségei számítanak itt. Viszont például az Ashes a legújabb patch-csel már 80 szálig skáláz.
-
Abu85
HÁZIGAZDA
Picit igen. A legtöbb játék eddig úgy csinálta az aszinkron compute-ot, hogy egy-két compute futószalag futott egy grafikai mellett. A Gears 5-nél akár 12 futószalag is futhat párhuzamosan. Ezzel a stateless compute architektúráknak nincs baja, de az NVIDIA még mindig hardverállapothoz köti a compute shadereket, nem tudja akármilyen állapotban lefuttatni ezeket a kódokat. Ilyenkor a hardver ugrálni fog az állapotok között. Ez kevés compute futószalagnál is előfordul, de ott nincs annyi állapotváltás, hogy az aszinkron compute hatása negatív legyen. Az AMD-nél ez a terhelés azért nem számít, mert a GCN és az RDNA is stateless compute, vagyis a feldolgozás alatt sosem vált hardverállapotot, így nem tud lelassulni. Önmagában ez egyébként olyan nagyon sok problémát nem okoz, mert a GeForce-ok lassulása ettől egészen minimális, a GCN viszont sokat tud gyorsulni az ilyen dizájntól. Az RDNA-nak sincs túl nagy hasznára ez a fajta megoldás, mert az idle buborékokat fel tudja a hardver tölteni, viszont van priority tunneling, és ettől ez a hardver is gyorsul, de csak nagyon picit.
-
Abu85
HÁZIGAZDA
válasz
GodGamer5
#40043
üzenetére
A Pascallal nem lehet mit kezdeni. A DirectX 12 API bekötése nem úgy épül fel, hogy jó legyen a hardvernek. A Pascal akkor működik, ha a buffer viewek (CBV/SRV/UAV) a root signature-be vannak bekötve. Ezzel szemben a DirectX 12 specifikációja pont úgy lett kialakítva, ha a root signature a konstansok mellett csak leírótáblákat tartalmazzon. Így viszont a Pascal nem működik jól. Meg lehet amúgy csinálni a buffer viewek direkt bekötését is, de mivel ezeknek a leírótáblákban a helye, így a formátumok tekintetében a root signature csak a konstansokra van szabva. Ezen nem fog változtatni semmilyen konzol. Olyan architektúrájú hardvert kell venned, amely megfelel ennek a működésnek, például: Turing, GCN, RNDA, Gen9.5-11. Ettől függetlenül fut a Pascalon egy DirectX 12-es játék, csak a pixelé shader teljesítménye visszaesik, ha a buffer viewek leírótáblákban vannak. Turing, GCN, RNDA és Gen9.5-11 mellett nincs ilyen hatása az API-nak.
-
-
Abu85
HÁZIGAZDA
válasz
FLATRONW
#40022
üzenetére
Ez a játék DX12-ben tele van furcsa dolgokkal. Az erőforrás-korlátozásoknál iszonyatos, hogy mik vannak. A szinkronizáció ránézésre is eléggé rossz, mert sok a fences, ami azért baj, mert minden ilyen művelet az összes cache ürítését vonja maga után, legalább egyszer, de bizonyos esetekben további szinkronizációs műveletek szükségesek. Itt veszik valószínűleg el a sebesség a DirectX 11-hez képest, mert ugyan a fences fontos funkció, de a túlzott használata nagyon káros. A képi hibák DirectX 12 alatt valószínűleg a rosszul felépített szinkronizációhoz kötődnek, mert az erőforrás-korlátozások nem megfelelő használata bőven okoz hasonló grafikai bugokat, és minden bizonnyal a fences is emiatt van sűrűn használva, mert valamennyire kezelik vele az alapból rosszul felépített szinkronizálást. Csak ez teljesítményben drága, és minden amit nyernek a DirectX 12-n, azt elvesztik itt, plusz még grafikai hibák is vannak.
Ezt rendbe lehet egyébként hozni, bár ez a DirectX 12 legnehezebb része. A legtöbb programot így ki sem adják DirectX 12-vel, mert lerí róla, hogy szarul működik a leképezője, és ez a mód inkább jön egy patch-ben.
A QB ehhez képest sokkal jobb volt, nem tudom, hogy mi ment félre, de gondolom a motort is átírták rendesen.
-
Abu85
HÁZIGAZDA
Ami rossz az rossz, ami jó az jó. Ennyire egyszerű. Itt nincsenek oldalak.
Az, hogy a kiadó sürgeti őket már önmagában egy probléma, mert ettől a végeredmény sokszor lesz rossz. És a kiadó számára nem egy opcionálisan bekapcsolható effekt lesz a fontos, hanem a játék maga. Ehhez tényleg kellenek a konzolok, mert ott akár az is előfordulhat, hogy maga a játék van úgy felépítve, hogy az AI upscaling a leképezés fontos eleme, és akkor az nem csak úgy lesz kezelve, hogy meh... hanem rászánják az időt, hogy jó is legyen, és arra már a kiadó sem mondhatja, hogy baszki nincs több idő, adjátok ki, mert dizájnból úgy tervezték a játékot, hogy az AI upscaling nélkül nem jó a sebesség és a végeredmény. Tehát a Microsoft megoldása nem azért más, mert másképp csinálják, hanem egyrészt ott az Azure, amely összesített számítási kapacitásban mérföldekkel több, mint ami az NV-nek van, és ennek egy jó részét pusztán oda tudják adni a fejlesztőknek, hogy Xboxra jól megcsinálják. Aztán persze lehet ezt hozni PC-re, valószínűleg a Microsoftot nem fogja érdekelni, de mivel a DirectML ugyanaz lesz a következő Xboxon, mint PC-n, ezért az egész fejlesztés egy az egyben másolható.
Az NV megoldása is lehetne jó, csak láthatóan nem érdekeltek abban, hogy ebbe pénzt fektessenek, mert ha azok lennének, akkor teleszórnák a fejlesztőket szerverekkel, hogy csinálják a neuronhálót, de nem csinálják ezt. A DLSS szerintem egy nagyon gyors ötlet volt arra, hogy van egy rakás sötét szilícium a hardverben a Tensor magok által, és azokat nem tudták mire használni. Kitalálták, hogy jó lesz az AI upscalingra, meg is csinálták, mert nem nagy művészet ennek a szoftveres háttere, csak azzal nem számoltak, hogy itt a minőség kulcsa nem a hardveren műlik, ami nálad van, hanem azon, hogy mekkora erőforrást hajlandó a minőségért befektetni a játék fejlesztője. Jelen állás szerint nem sokat, mert a DLSS minősége a játékokban a ritka ronda és a - jó szándékkal - közepes szint között van. És ez ellen nem tud tenni az NVIDIA, mert nem érdekeltek abban a fejlesztők, hogy a legalább jó szinthez szükséges erőforrást belefektessék. Szóval ez alapvetően nem az NVIDIA hibája, látható, hogy a 3DMark DLSS tesztje jól működik (sőt kiválóan), csak az egy 3 perces jelenet, arra nem művészet ezt megcsinálni. Egy 10-20 órás játékra már sokkal körülményesebb. Úgy mondanám ezt, hogy a 3DMark bemutatta, hogy maga a DLSS alapvetően tudja azt, amire tervezték, csak a játékoknál fejlesztők szarnak bele, hogy ezt kihozzák, egyszerűen se erőforrásuk, se pénzük rá, hogy egy korlátozott usernél bekapcsolható fícsőrre koncentráljanak. Emiatt lesz más a konzolnál, mert ott aztán minden usernél működni fog, tehát megéri ebbe pénzt és erőforrást rakni, mert optimalizálásként lehet majd felfogni, és ha már működik, akkor mehet copy-paste PC-re is.
-
Abu85
HÁZIGAZDA
Viszonyítás kérdése. Ahhoz képest jó, hogy pár játék milyen szar képet rak eléd DLSS-sel, de az elvárható minőségtől fényévekre van.
Ugyanaz a probléma mindig. A jó eredményhez jó neuronháló kell, de mivel alapvetően ez csak egy kikapcsolható fícsőr, így nincs értelme belerakni a gépidőt. És itt elcsúszik az egész, mert nem úgy tekintenek rá a fejlesztők, hogy ezzel optimalizálnak, hanem csak megvásárolja tőlük a funkció beépítését az NVIDIA, de eközben a fejlesztői oldalon kb. semmi kedvük arra, hogy ebbe erőforrást rakjanak. A pénz jól jön, aztán szarnak az egészre, miközben a probléma megoldása kellően bonyolult ahhoz, hogy ha ehhez így állnak hozzá a fejlesztők, akkor annak nagyon felemás eredményei lesznek.
Ezen az segíthetne, ha a Microsoft beállnak az egész mögé a következő generációs Xboxnál, és kb. odatolná az Azure-t a fejlesztők segge alá. Tessék ott egy rakás ingyen számítási kapacitás a felhőben, és csináljátok meg az Xboxra jóra, aztán az a neuronháló vihető PC-re is. Az NV-nél ugye a számítási kapacitás nincs ingyen, hiába a reklámszerződés a funkcióra. Ha kifogy az erre szánt büdzsé, akkor ez van, otthagyják szarul a funkciót. Szóval az iszonyatosan sokat jelentene, ha a fejlesztőknek a Microsoft adna ingyen gépidőt.
-
Abu85
HÁZIGAZDA
válasz
Habugi
#39981
üzenetére
Nem a felhasználó informálása a lényeg. Megtehetné az AMD, hogy átlagolja az összes mért adatot, és azt jelzi vissza a szoftvernek, vagy ahogy a procinál csinálják, burkolati hőmérsékletet jeleznek vissza a lapka hőmérséklete helyett, aztán a BIOS számol egy burkolati hőmérsékletet az asztali gépeknél. A lényeg a hardver informálása, ami alapján az képes lesz eldönteni, hogy milyen órajelet lehet beállítani. Ha ki tudod mérni pontosan, akkor rá lehet menni a határra. Ha nem tudod kimérni elég, akkor feltételezni kell, hogy a lapka egy ponton forróbb, mint amit a dióda mér, és nem lehet nagyon a határra menni.
-
Abu85
HÁZIGAZDA
Nagyjából azt jelentené, igen. Bár itt számít az is, hogy mennyire van közel a dióda a legforróbb ponthoz. Általában nem a lapka közepére szokás rakni, hanem valamelyik shader tömbbe, méghozzá abba a tömbbe, amely közel van az egyes multimédiás blokkokhoz. De ettől persze bőven elképzelhető, hogy a lapka másik végében jóval nagyobb a hőmérséklet egy specifikus munkafolyamat miatt. A Navi 10-nél ez mindegy, ott már teljes hőtérkép van, tehát konkrétan meg tudja mondani a rendszer, hogy hol van a legforróbb pont, és az milyen hőmérsékletű.
Az órajel-szabályozáshoz nem elég, ha csinálsz egy ilyen rendszert, azt is el kell érned, hogy finom szemcsézettségű legyen a paraméterezhetőség. Ezért jött a finomszemcsés DPM mechanizmus és a hőtérképes mérés együtt. Külön-külön nem sokat érnek.
-
Abu85
HÁZIGAZDA
Minden eladott hardver úgy van beállítva, hogy bírja a terhelést. Az hogy képes-e kimérni a szilícium legforróbb pontját, vagy nem lényegében csak azt befolyásolja, hogy képes-e minden pillanatban beállítani a lehetséges legmagasabb órajelet, vagy nem. Tehát attól sincs igazából gond, ha egy hardver nem képes meghatározni a lapka legforróbb pontját, hanem esetleg 10-15°C-szal kisebb hőmérsékletet mér a diódával, mert a tesztek során be lett állítva erre a helyzetre is, és stabilan, a hardver károsodása nélkül átvészeli az egészet. Csak nem akkora órajelen fog futni, mint amekkorával futhatna, ha pontosabb lenne a mérés.
-
Abu85
HÁZIGAZDA
A szilícium hőmérsékletét ezzel nem fogod látni.
Az órajel-szabályozás esetében tipikusan az jelenti a problémát, hogy a szilícium nem minden pontján ugyanolyan hőmérsékletű, viszonylag nagy különbség is lehet két pont között, és egy-egy ponton, akár egy másodperc alatt hevülhet vagy hűlhet ~10-15°C-t. Ezeket sehogy sem lehetett eddig mérni. Teszttapasztalatok alapján lehetett rá következtetni, de gyakorlatban mérhetetlenek voltak. A Navi 10 az első GPU, ami mérni tudja ezeket. Valószínűleg nem az utolsó GPU, mert a legnagyobb teljesítményt akkor tudod kihozni a GPU-kból, ha a beépített rendszer tényleg kiméri a legforróbb pontot.
-
Abu85
HÁZIGAZDA
Belsőleg ilyen dolgokat sosem jellemeznek ilyen kódnévvel. A kódnév esetében a legfontosabb tényező, hogy rá se lehessen jönni, hogy az a valami, amit fejlesztenek hova jön.
Az egyébként valóban igaz, hogy az AMD a sugárkövetést máshogy csinálja, de ugye ők már nem csak a mostani nulladik generációs DXR-re terveznek, hanem arra is, amit a Microsoft csinál a DXR utánra. Arra meg az aktuális hardverek nem jók. Az meg nyilván sokkal-sokkal-sokkal... gyorsabb, ha a geometirára vonatkozó információt voxelekben tárolják, csak ezt a megoldást a mostani DXR nem támogatja, de nem marad ez örökké így.
-
Abu85
HÁZIGAZDA
A ReShade verzió megy minden DX11/OGL játékon. De amúgy nem ugyanez van a driverben, mert ez a CIS portja, a driveres pedig egy módosított CIS, ezért nem ugyanaz a neve. Az eredmény tekintetében a driveres RIS verzió két dologban különbözik a CIS-től:
- egyrészt a PAL szintjén van írva (ez a hardver fölötti legalsó réteg, vagyis szinten assembly szintű kódolásról van szó), tehát több nagyságrenddel gyorsabb, ami mondjuk az effekt jellege miatt elfogadható így is, mert maga a CIS shader 4K-ban 400 mikromásodperc alatt fut 5700XT-n, tehát a ReShade verzió kb. tudni fog 600-900 mikromásodpercet a kevésbé erős hardvereken. Ez így is 2-3 fps mínuszt jelent csak, a felbontás csökkentésével még kevesebbet.
- másrészt a RIS annyiban módosítva van a működést tekintve, hogy erősebb élesítés mellett se adjon túl sok képi hibát. Ez a CIS-ben nem létezik, mivel itt a fejlesztők eleve rászabhatják a működést az adott játékra, ami a RIS esetében ugye nem lehetséges, tehát külsőleg kényszerített eljárásnál általánosan kell jónak lenni, nem pedig specifikusan. A CIS-nél az is lehetséges, hogy csak a kép egy részére alkalmazzák, a motorba történű direkt beépítésnél nagyon sok opció van.DX12/Vulkan játékokra az AMD megoldása kell. Itt a memória vezérlésének jellegzetessége miatt még maga a meghajtó sem tudja segítség nélkül, hogy hol vannak módosításra kijelölt pufferek. Ezt az AMD például úgy csinálja, hogy van a meghajtóba építve egy RGP rutin, ami feltérképezi a memóriát a DX12/Vulkan játékoknál. Na most ezt egy külső programmal marha nehéz megoldani, gyakorlatilag játékonkénti optimalizálás kell hozzá, és ha jön egy patch, akkor jól ki is végzi a működést, vagyis mindent lehet a nulláról kezdeni.
A ReShade egyébként nekifutott megint a DX12 támogatásának, immáron másodjára, de tényleg kellene nekik úgy 150-200 ember, hogy ezt reálisan meg lehessen oldani a meghajtón kívülről. -
Abu85
HÁZIGAZDA
válasz
Milka 78
#39758
üzenetére
Hogy az ügyfél a xy gyártmányú szervert tőletek rendeli-e meg, vagy elmennek személyesen az Intelhez...
Illetve ha már aktív tapasztalatod van. Szállítotok-e Cascade Lake-AP szervert egy ügyfélnek, ha ilyen igénnyel áll elő, vagy esetleg aminek nincs mainstream supportja, azzal nem is foglalkoztok...
-
Abu85
HÁZIGAZDA
válasz
Raymond
#39755
üzenetére
No offense most, de én jelenleg azt látom, hogy tapasztalathiányból eredően félremagyarázol.
Nem baj az, ha nem volt még gyakorlatod a kereskedelemből. Az a gond, hogy olyannak írsz, akinek volt. 
Amikor a tényeket nehéz megcáfolni, akkor jön a személyeskedő "badarság", illetve az, hogy meguntad. Ez önmagáért beszél. Inkább írsz egy hosszú posztot a semmiről, minthogy válaszolnál a kérdésre, hogy dolgoztál-e IT boltban valaha... Én szívesen beleállok a vitákba, de úgy nehéz, hogy jellemzően az az összes érved, hogy "badarságokat" írok. Ez olyan, mintha boldog karácsonyt kívánnál egy kérdésre.
-
Abu85
HÁZIGAZDA
Az Intelnek ez csak a papír miatt kell. Amúgy elég drága a rendszer, elég sok pénzt emésztene fel szoftveres szinten, és eközben nagyon sokat is fogyaszt. Kétszer többet, mint az új EPYC. Krzanich egy csomó fejlesztést kinyírt, ezeket nem lehet visszahozni és most fejvesztve legóznak össze mindenféle töltelékterméket, hogy legalább a versenyképesség halvány látszatát fenntartsák, de ugyanakkor ezekkel már nem akarnak foglalkozni kereskedelmi szinten, mert ott már nyűg lenne.
Csak azt vedd figyelembe, hogy 2020-ban három, azaz három eltérő szerverplatformjuk lesz, amikor a gyártók számára egy platformra is sok-sok millió dolláros tétel felkészülni. Ez a kapkodás jele, hogy számos, hirtelen elindított projekt egyszerre ér be, de ők sem tudják eldönteni, hogy melyik a jó, így kiadják mindet. -
Abu85
HÁZIGAZDA
Persze, csak nincs ugye forgalmazó.
Alapvetően a Cascade Lake-AP esetében az Intel követelményei csak arra szolgálnak, hogy a termék ne legyen vonzó egyetlen komolyabb partner számára sem. Gyakorlatilag csináltak egy processzort, amire úgy rakták össze a rendszerszintű igényeket, hogy a Dell EMC, HPE, Inspur, Lenovo, QCT, Huawei, Supermicro, ésatöbbi, semmiképpen se akarjon erre terméket piacra dobni. És ha megnézed, akkor ez bejött, mert egyik komoly szervergyártó vagy OEM nem kínál az érintett modellekre terméket. -
Abu85
HÁZIGAZDA
válasz
Raymond
#39744
üzenetére
A Xeon a király, az EPYC pedig szar. Így jó lesz? Ettől nyilván a tények nem változnak meg, de nekem mindegy, hogy ki mire építi az álomvilágát.
Őszintén remélem azt is, hogy sikerül majd mainstream support nélkül Cascade Lake-AP Xeont szereznie valakinek. Izgalmas lesz az biztos.
-
Abu85
HÁZIGAZDA
Akkor rendeljetek Cascade Lake-AP-ket. Mindenki kíváncsian fogja várni az eredményt, merthogy marhára nincs mainstream supportja, az is biztos. Nem véletlenül ír erről a ServeTheHome, ami egyébként egy eléggé elismert média a szerverek tekintetében.
Lehet, hogy nektek a Xeon a jobb. Tehát nem feltétlenül azért rendeltek olyanokat, mert hülyék dolgoznak nálatok, hanem ahogy írtam fentebb, nem mindenhol van az első helyen az alacsony fogyasztás és a magas teljesítmény, esetleg a TCO, a licencköltségek, stb. Ha ezeknél fontosabb az IOPS teljesítmény és az adattároló elérési késleltetése, akkor jobb a Xeon (nem a papírsárkány 9200-as, mert az ezeket nem támogatja, hanem a 8200 vagy kisebb verzió megfelelő), mert hiába lassabb maga a processzor, hiába fogyaszt többet, hiába rosszabb a TCO, ha a feladat miatt a szűk keresztmetszet eleve nem a számítási teljesítmény lenne, hanem az adattároló.
Ha mondjuk jelen pillanatban van egy olyan adatbázisod, amire nagyon kell az Optane késleltetése, illetve az IOPS képességek, akkor arra az AMD-nek nincs válasza. Tudnak a PCI Express 4.0-val gyilkos teljesítményű SSD-ket, de van egy olyan teljesítményszint, amit ezzel nem érnek el a véletlenszerű adatelérés tekintetében. Minden másra viszont jobb a Rome. -
#39738
Abu85
HÁZIGAZDA
Petykemano
#39727
Abu85
HÁZIGAZDA
válasz
Petykemano
#39727
üzenetére
Ez a piac nem csak csíkokat néz, hanem TCO-t is, illetve licencköltségeket, magszámot, illetve interfészeket. Ez nem játék, hanem itt komoly költségelemzések zajlanak, már aki pénzt akar látni a befektetésekből.
(#39728) b. : Sokkal bonyolultabb a szervereknél ez a kérdés. Ez jellemzően úgy működik, hogy egy adott boltnak van erre vonatkozóan olyan szakembere legalább partneri szinten, aki képes felmérni, hogy milyen igényekhez milyen hardver való. Mert nagyon nem egyértelmű ám, hogy egy adott problémakörre milyen szerverrel nyersz a legtöbbet. Például, ha virtualizált környezet van, akkor nyilván most rá se nézem semmi másra, csak a Rome platformra, mert annak a TCO-ja egyutas szinten annyira alacsony, hogy gyakorlatilag minden korábbi konfigurációnál kedvezőbb üzemeltetést ad, kedvezőbb licencfeltételekkel, és nagyobb teljesítménnyel. Semmi más nem kínál ilyet. De ha mondjuk a tipikus problémád inkább az adatbázis kezelése, ott keletkezik egy szűk keresztmetszet, mondjuk a random IOPS-nál, akkor nem igazán a processzorerőbe kell fektetned a pénzt, hanem inkább érdemes elgondolkodni a Samsung Z-SSD-n, vagy ha az sem elég jó, akkor az Optane-en. Utóbbit meg ugye nem is támogatja a 9200-as Xeon sorozat, csak a kisebb x200-as modellek. Itt nem hardveres probléma van, egyszerűen az Intel nem akar eladhatatlan papírsárkányokkal szoftveres szinten foglalkozni, mert pénzt úgysem lát az -AP vonalból, jövőre nem is folytatják, de mondjuk az Optane támogatása vinné a pénzt.
A Krzanich éra alatt az Intel felégette a kereskedelmi hidakat. Ezekre már nem volt szükségük saját hardver nélkül, hiszen mindent a partnerek adtak a boltok felé. Ezzel bő 5000 embert ki tudtak rúgni. Tehát alapvetően közvetlen kereskedelmi kapcsolat már csak akkor építhető az Intel felé, ha a megrendeléseid tízezres nagyságrendűek.
A boltok a szerverek szintjén a nagy szervergyártókkal ápolnak kapcsolatot. Valamelyik boltnak van preferenciája, mert teszem azt a Dell vagy a HP fizet nekik, hogy őket ajánlják, de valszeg a nagyobb gyártók platformjai mindenhol beszerezhetők. Ezért baj, hogy nincs -AP vonal a nagyobb gyártóknál, mert ugye így a vásárlóktól ez a lehetőség el van vágva. Nagyjából azt tudják felkínálni, amit a Dell vagy a HP ad, ha valami speciális az igény, ami nehezen beszerezhető, azt inkább visszamondják, már csak a support miatt is. Ha mégis kell, rendezze le az ügyfél a gyártóval, és utaztassa a supportot át a fél világon, ha problémája van. Ezek a tényezők egy boltnak csak nyűgök lennének.
Mindemellett az Intel szervereknek az egyetlen előnye most az Optane. Ha egy adott feladatnál nem keletkezik olyan szűk keresztmetszet, amihez Optane kellene, akkor a Rome gyorsabb, kevesebbet fogyaszt, és még a TCO-ja is alacsonyabb. Optane-t pedig az -AP sorozat nem támogat.
(#39734) hokuszpk: Na most az -AP vonalra az Intel sem kínál olyan garanciális hátteret, mint a normál Xeonokra. Ha valami probléma van, akkor kicserélik, de nincs határidőhöz kötve a csere, mint a kisebb Xeonoknál. Ez is egy probléma, mert a csere tarthat hetekig, vagy hónapokig is, szemben a kisebb Xeonok akár egy napon belüli garanciájával.
(#39737) b. : Csak jelen esetben pont arról van szó, hogy ezek a helyi szinten letelepített supportokat biztosító cégek nem árulnak -AP vonalat.
Szerintem az Intel eleve azért alakította ki ennyire partnerellenesként ezt az -AP vonalat, hogy ne is rendelje majd senki. Gyakorlatilag mindent bevetettek, ami a partnereiknek és a kereskedőknek rossz, plusz elvágták az Optane-től. Nekik igazából egy papírsárkány kellett, mert a Rome-ra egyszerűen nincs normális válaszuk, de még nem készültek fel arra, hogy erre a részvényesek rájöjjenek. De nem csak a Rome jelent nekik veszélyt, hanem a Xilinx Versal is. Ezt Krzanichnak kellett volna észrevennie pár éve, csak alkalmatlan volt erre a feladatra. -
#39726
Abu85
HÁZIGAZDA
Petykemano
#39725
Abu85
HÁZIGAZDA
válasz
Petykemano
#39725
üzenetére
Azért mert nem tudod megvenni a kereskedelmi csatornáidon keresztül. Attól mert te mondjuk egy ilyen szervert akarsz, nem fog az adott bolt (akinél szoktad ezeket vásárolni a kiépített supporttal a háta mögött) ilyet rendelni. Azt fogják mondani, hogy rendeld meg az Inteltől, kb. fél év mire elkészítik, aztán hagyd őket békén, ha valami baj van, majd intézel szakembert hozzá a világ másik tájáról. Plusz 23%-ért, mert ennyit ígér maximum az Intel a Rome platformhoz képest extrában, senki sem fog egy sokszor nagyobb TCO-val rendelkező rendszert kérni, és ez az oka annak, amiért a nagy szervergyártók nem jelentettek be hozzá gépeket.
Ez egy papírnak készült termék, semmi több. Ha igazi termék lenne, akkor egyrészt nem szűnne meg a következő generációban ez az egész -AP vonal, másrészt építenének rá szervereket a partnerek. Ezek számítanak a szerverpiacon.
-
#39724
Abu85
HÁZIGAZDA
Petykemano
#39723
Abu85
HÁZIGAZDA
válasz
Petykemano
#39723
üzenetére
[link] - enélkül az kirakatnak van csak.
Az AMD is papírra vethet egy új tokozást, rá 256 magot, és mi történik? Semmi. A gyártók ugyanúgy nem fogják kérni, ahogy az Intelé sem kell nekik. -
Abu85
HÁZIGAZDA
válasz
-FreaK-
#39720
üzenetére
2022-ig lehetnek nyugiban. A Sapphire Rapids már esélyes, hogy verni fogja a Rome platformot. Aki biztonságra játszik, és vesz részvényt 2021 végén kell eladnia. Az más kérdés, hogy mi lesz 2022-ben, de a Cooper és az Ice Lake egyáltalán nem veszélyes a Rome-ra, a gyorsabb Milan, majd 2021-ben a még gyorsabb Genoa pedig még jobban elhúz. Az az igazi kérdés, amit a részvényeseknek szem előtt kell tartani, hogy a Sapphire Rapids csak a Rome-ot tudja-e ütni, vagy esetleg jó lesz a tényleges konkurens Genoa ellen is.
-
Abu85
HÁZIGAZDA
válasz
schwartz
#39699
üzenetére
Nem mondva semmit, de itt nem olyan faszságra használják, amit megcsinálsz ezerszer olcsóbban, egy hangyafasznyit gyengébben raszterizációs megoldással, amit aztán játék közben úgy sem veszel észre. Olyan dolog lesz benne, aminél végre tényleg haszna van a sugárkövetésnek.
-
Abu85
HÁZIGAZDA
Nincs külön GPU. IGP van.
Jelen állás szerint nincs eDRAM. De ez igazából normális, az előző generációban se működött, teljesen felesleges egy rakás pénzt kidobni az ablakon nem működő technológiára.
Átlag 18% a Skylake-hez képest. Itt az Intel szálat hasonlított szállal ugyanolyan órajelen.
Az a déli vezérlőhíd.
-
#39691
Abu85
HÁZIGAZDA
huskydog17
#39690
Abu85
HÁZIGAZDA
válasz
huskydog17
#39690
üzenetére
Exkluzív esetén nem. Ezért az AMD fizetett nekik egy nyolc számjegyű összeget.
Nem kell. A Zenimax engedélye kell, mert ők adják ki a Bethesdán keresztül. De ezek kiadói szerződések, míg az AMD nem kiadói szintre szerződött, hanem fejlesztői szintre, ahol gyakorlatilag az R&D egy részét látják el. Azért tudott az id tech 6 egy csomó mindenben első lenni, például Vulkan és zárt SPIR-V intrinsics, mert az AMD írta meg nekik a kódok egy részét.
A Zenimaxon belül nincs átfogó motorfejlesztés. Az id Software biztosít egy adott verziót az id techből, és azt a leányvállalatok eltérően fejlesztik tovább. Az id Software már rég az id tech 7-et írja, és az id tech 6.x-szel már nem foglalkoznak, viszont a forráskód ott van a Zenimax leányvállalatainál, azt úgy alakítják, ahogy akarják. Ennek az a legnagyobb előnye, hogy az id Software nem felel semmi másért, csak a saját házon belüli projektekért, így minden problémát helyben kezel a többi stúdió, az id Software segítsége nélkül.
Évente többször kell találkozni az NV és az AMD emberével, és akkor sok dolgot meg lehet ám tudni tőlük.
-
#39689
Abu85
HÁZIGAZDA
huskydog17
#39688
Abu85
HÁZIGAZDA
válasz
huskydog17
#39688
üzenetére
A MachineGames-szel van szerződésük. Az Bethesda (id software-rel) exkluzív szerződése van az AMD-nek még három évig. Őket ki kell vásárolni belőle, ami elég drága lenne. Viszont a MachineGames és az Arkane abból a szempontból szabad préda, hogy az ő anyacégük a Zenimax, és nincs közük az id-hez és a Bethesdához, vagyis nem érinti őket az AMD-s szerződés.
A kérdés egyébként az, hogy az id software-re mi vonatkozik, mert az AMD nekem azt mondta, hogy a Bethesdával kötöttek szerződést, és abba belevették az id-t. Nem tudni, hogy az alapszerződés exkluzivitását örökölték-e.
-
Abu85
HÁZIGAZDA
Ettől még elnevezhetik 3080-nak, ha akarják. Mint írtam ez csak egy szám. Az NVIDIA majd beperelheti őket, ha a világon elsőként képesek lesznek egy számot levédetni.
(#39675) Televan: Na igen. Nagyjából ez a gond a számok levédésével, és ezért dobják vissza ezeket a kérelmeket.
-
Abu85
HÁZIGAZDA
Számot nem lehet levédeni. A Naviból minden le van védve, amit le lehet, de úgy nem fogadják majd el a beadott kérelmet, hogy RX 3080. A számot visszadobják. Elnevezhetik annak, de az RX részét leszámítva nem védethetik le. Az NV is hiába adta be az RTX 3080-4080-at, a számot vissza fogják dobni belőle.
Ezeket például úgy lehetne védeni, ha így írnák ki: 30∞0. Ez levédhető, de a 3080 nem. -
#39651
Abu85
HÁZIGAZDA
szmörlock007
#39649
Abu85
HÁZIGAZDA
válasz
szmörlock007
#39649
üzenetére
Lesz, csak átalakult teljes Ice Lake előzetessé. De a Computex után befejezem.
-
Abu85
HÁZIGAZDA
Az Intel és az AMD is keres pénzt a datacenteren, nem az a lényeg a cégeknek, hanem az, hogy mennyit kell befektetniük, hogy sokkal-sokkal több pénzt keressenek abból a zsíros piacból.
Emiatt értékes a szerver és a mobil PC-k piaca, mert vagy stabilan tartják magukat, és nem várható olyan változás a jövőben, ami nagyon más útra terelné a felhasználóbázist, sőt, még növekedés is lehetséges, főleg a szervernél.A dGPU-piacon az is egy elég nagy kérdés manapság, hogy a 7 nm-es EUV-re hogyan fognak reagálni a felhasználók, mert ott a középkategóriát simán 400-450 dollárra kell emelni, hogy egyáltalán megérje az egész. Szóval egy olyan tényező van ebben benne, amivel nagyon nehéz számolni, és lehet, hogy felhasználókat fognak veszteni, mert mondjuk xy gémer azt mondja, hogy a 300 dollár is sok volt, de a 400-450 már egyenesen rablás, de ugyanakkor az AMD és az NV se tud nagyon mit tenni, mert a teljesítmény növeléséhez új memóriatechnológiákra van szükség, amelyek a kezdetekben mindig drágák, illetve egy tape-out a 12-16 nm-es tape-out árának a hatszorosa lesz 7 nm-es EUV-n. És még a wafer is nagyon drágul. Ezek olyan kérdések, amelyek az egész piacot nagyon kiszámíthatatlanná teszik, nem lesz rossz a piac, csak a jó ég tudja megjósolni, hogy egy eddig 250 dolláros szinten vásárló PC-gamer mit fog szólni a 450 dolláros árcédulákhoz. Megvásárolja? Megy konzolra? Esetleg Stadia? Nem nagyon van még válasz, mert ugye azt is bele kell számolni, hogy a korábbinál sokkal több alternatíva is lesz.
-
Abu85
HÁZIGAZDA
Nem érted a cégek működését. A dGPU-k piaca éves szinten nagyjából 5 milliárd dollár, és ez inkább fölé van lőve a valóságnak, mert ugye az elmúlt évben azért még a bányászat éreztette a hatását. Ami viszont például az AMD-nek inkább értékes az a datacenter, ami éves szinten úgy 30 milliárd dollár, vagy a mobil, ami szintén nagyjából 30 milliárd. Most te cégvezetőként mit csinálnál? Pacsiznál az NV-vel, és mennél arra az 5 milliárdra, ami ráadásul egy szűkülő piac, vagy megcéloznád a 30+30 milliárdot, ami inkább növekvő? Na ugye. Nyilván, ha a dGPU-k piaca annyira fasza lenne, akkor az NV sem költene az önvezető autókra, a datacenterre, és a többi professzionális területre, de mivel ez a piac messze van a faszától, így ők is inkább a növekvő, 10+ milliárdos területeket üldözik.
(#39641) Petykemano: Tíz év múlva biztos.
-
Abu85
HÁZIGAZDA
Az a baj, hogy a dedikált GPU-k piaca nem kritikus fontosságú. Amikor döntéseket hoznak a cégek, például az egymással való együttműködésről, akkor azt egy olyan piacért hozzák, ami vagy rendkívül nagy, vagy rendkívül dinamikus növekedés előtt áll. Na most a dGPU-kra egyik sem igaz. Ilyen szempontból se az AMD, se az Intel nem fogja különösebben keresni az NV-vel való együttműködést itt, nem tényező, amit ezzel nyernének. Nyilván nem fogják tiltani a kombinált konfigurációkat, ha valami bug van, azt egymás felé is javítják, mert a bug az nekik is para, de kb. ennyi.
-
Abu85
HÁZIGAZDA
Az AMD-nek igazából nem annyira kritikus, hogy a GPU a Ryzen mellett Radeon legyen, ahogy az NV-nek is gyakorlatilag mindegy, hogy a GeForce Intel vagy AMD proci mellé kerül. Azért jönnek a Ryzen+GeForce notebookok, mert a gyártók nem bíznak az Intelben, hiszen hónapok óta azt hallgatják, hogy minden fasza lesz, aztán semmi sem történik. Kb. két-három negyedévig vársz, de van egy pont, amikor el kell azon gondolkodni, hogy az Intel képes-e a problémáit javítani. Bizonyos gyártók úgy döntöttek, hogy jobb biztosra menni, és Ryzent rakni a GeForce-ok mellé. Ennek semmi köze annak, hogy az AMD vagy az NV együttműködne, egyszerűen nekik tényleg mindegy.
A data center az le van játszva. Látható, hogy az új fejlesztésű HPC klasztereknél nem igazán kombinálják a gyártókat. Nem is nagyon tudják, mert itt például az NV az NVLINK-et használja, az AMD az IF-et, és az Intelnek is lesz majd egy saját zárt megoldása.
-
#39636
Abu85
HÁZIGAZDA
Petykemano
#39634
Abu85
HÁZIGAZDA
válasz
Petykemano
#39634
üzenetére
Hát nem kedvező a helyzet. Ha FPGA-t akarsz, akkor egyszerűen a Xilinx kínálata most jobb, és ezt úgy, hogy még nincs itt a Versal. GPU-ja csak lesz egyszer az Intelnek, míg a Nervana az alapvetően jó, csak mondjuk a nagy megrendelők inkább maguknak terveznek ilyen lapkát, illetve a piac alapvetően még nem olyan nagy. Az Intelnek is a bevétel nagy része a szervereknél is a CPU-kból jön. Ez kb. 80-85%.
A CPU-nál és a GPU-nál előny lehet az integráció, de az FPGA és az NNU esetében nem annyira.
A CXL-lel az a gond, hogy oké érkezik, de addigra mindenki kiadja a hardverét a CCIX-re, amivel aztán a CXL marhára nem fog működni. Tehát az Intel majd bejelenti, hogy "Drága ipar itt a CXL-es platformunk!" ... az ipar meg visszakiáltja, hogy "Fasza, de mikor lesz CCIX-es, amiben a régóta piacon lévő hardvereink is működnek?"Az adatközpont az alapvetően CPU-fókuszú. Erre kapcsolódnak a gyorsítók.
Egyrészt az Ice Lake előnyeit leginkább az AVX-512-re adja meg az Intel, mert anélkül azért nem lesz akkora ugrás, másrészt az alapórajel tekintetében egységnyi fogyasztás mellett 30-50%-kal kevesebbre képes, mint a Comet Lake. Hogy ezt az órajelhátrányt kompenzálják, legalább 40-60%-os IPC-növelés kellene. Nem véletlen, hogy az Ice Lake-SP is a Cooper Lake alá jön, mert egyszerűen nem gyors a mag. Semmit sem tudnak vele kezdeni.
-
Abu85
HÁZIGAZDA
Valószínűleg nem döglenek ki, az azért túlzás, persze kérdés, hogy költői-e.
Viszont azért nem sok jóval kecsegtet az, amit mondjuk megosztanak a cukormáz mögött. Hogy a Sapphire Rapids-ig nem lesz válaszuk az EPYC 2-re, hogy a Xilinx Versalra még el se kezdték tervezni a választ, hogy nem lesz CCIX-es platformjuk, miközben a CCIX-es gyorsítók az év végén jönnek, hogy a OneAPI alapvetően a SYCL-re épít, (stb.). Utóbbi mondjuk véleményem szerintem pont a legjobb döntés, de nem egy gyártótól hallottam már, hogy nem örülnek annak, hogy az Intel nem csinál saját szoftverplatformot, mint az NV és az AMD, hanem inkább a Khronos Grouptól teszi függővé magát, illetve közvetve ugye magukat a gyártókat. -
#39616
Abu85
HÁZIGAZDA
huskydog17
#39603
Abu85
HÁZIGAZDA
válasz
huskydog17
#39603
üzenetére
Na szóval semmi komoly para nincs. Arról van csak szó, hogy a memóriamenedzsmenthez egy nem módosított AMD VMA-t használnak, ami ugyan működik, de némelyik puffert elér a CPU és a GPU is. Na most ezeket a VMA a Radeonokon a videomemóriába helyezi, és itt éri el őket a CPU és a GPU, viszont GeForce-on ilyen memóriatípus csak a rendszermemóriában van ezért itt a rendszermemóriában lesznek ezek a pufferek. Emiatt a GeForce nem csak a VRAM-ig megy értük, hanem a sokkal távolabbi rendszermemóriáig. Ugyanakkor igen pici adatokról van szó, tehát annyira erősen ez nem befolyásolja az élményt, de persze mérhető lesz, hogy nincsenek ott a VRAM-ban.
A megoldás lényegében annyi, hogy a VRAM-ba kell őket menteni más memóriatípusba, és kell írni rá egy módosított menedzsmentet, ami kimásolja a puffereket a rendszermemóriába, majd vissza. Erre jó az aszinkron transzfer az API-ban, csak az AMD VMA eléggé általános middleware, így nagyon specifikus igényekre nem kínál megoldást, de a nyílt forráskód miatt átírható. -
#39604
Abu85
HÁZIGAZDA
huskydog17
#39603
Abu85
HÁZIGAZDA
válasz
huskydog17
#39603
üzenetére
Estére ígértek választ, hogy miért ilyen a GeForce frame time. Annyit mondtak, hogy van magyarázata és javítható is, csak nem tudta elmagyarázni a marketinges.
-
Abu85
HÁZIGAZDA
Amikor az NV-nek van egy játékkal gondja - volt már ilyen, lásd Tomb Raider, Doom, stb. -, akkor azt csinálják, hogy nem beszélnek róla, amíg nincs driver. Mindig így csinálták, és ha megnézed, akkor most se reagálnak a World War Z-re. Majd megteszik akkor, ha már lesz hozzá driverük.
Ennek a fejlesztésnek semmi köze az AMD-hez. Ez gyakorlatilag a shader modell 6.0 Vulkan megfelelője.
Hogy mihez mennyi idő alatt jön javítás, nagyban függ attól, hogy mi a probléma. Például egy memóriamenedzsmenten belüli allokációs problémát sokkal egyszerűbb javítani, mint egy fordítási gondot.
Amiről szó van egy új képessége a Vulkan API-nak. Lényegében lehetővé teszi, hogy az egymástól független feladatok párhuzamos futtatását egy multiprocesszoron. Korábban ezek futtatása csak egymás után volt megvalósítható, ezért vezették be ezt az új képességet, így már egymás mellett is futhatnak. Az, hogy a driver oldalán mi a gond ezzel... kb. ezernyi oka lehet. Nagyon röviden, amikor shader fordítás történik, akkor a meghajtó a hardverre vonatkozó adatok birtokábak kialakítja a megfelelő wave-eket. Lesz egy kép arról, hogy a shader mennyi regisztert (compute esetén LDS-t is) használ, és a multiprocesszor képességeit figyelembe véve lesz egy szám, amennyi wave-et a multiprocesszor tud futtatni. Itt minden harver statikus particionálást használ, vagyis betöltenek minden adatot a regiszterekbe, még akkor is, ha sose nyúlnak hozzá. Minden gyártónak van egy jól kialakított képe arról, hogy az adott hardver multiprocesszora mire képes, hol van az a minimum/maximum határ, ami már rontja cachinget, vagy nem fedhető el a memóriakésleltetés, stb. és a fordító is próbál határokon belüli kódot fordítani, amennyire ez lehetséges persze. És itt van az a pont, amikor leginkább az segít, ha kitapasztalod, hogy mi a jó hardvernek. Általában ezért van az, hogy amikor kiadnak egy új architektúrát, akkor az első driverek nem valami gyorsak, mert még nem értik annyira a hardvert, de aztán írnak jobb shader fordítókat, és egyre jobb lesz gyakorlatilag ugyanannak a shadernek a hardveren való működése. Persze csodát nem lehet tenni, de problémás helyeken +20-30% is benne lehet, átlagban pedig simán meglesz a +5%. A probléma az új subgroup/wave terminológia esetében az, hogy független feladatok párhuzamos futtatása megvalósítható, tehát a wave-ekre vonatkozóan ugyan a hardver működése nem változott, de az új funkcióval a szálak, illetve inkább lane-ek képesek adatokat megosztani egymással, ráadásul nem csak shader lépcsőn belül, hanem shader lépcsők között is. A kérdés az, hogy a lane-ek közötti adatmegosztás tekintetében mi az optimális a hardvernek, érdemes-e változtatni a tipikusan jól működő wave mennyiségekre való optimalizálást. Ezekre nehéz felkészültni tesztshaderekből.
Ami biztos, hogy nem az NV-nél dolgoznak hülyék, hanem nincs elég adat ahhoz, hogy mindig jó döntést hozzanak, mert a PC-piacon ez egy újdonság, illetve a Nintendo Switch által használt API-k sem tartalmaznak subgroup/wave terminológiát. Ergo még nem volt igazán igény egyetlen ügyfél részéről sem arra, hogy a hardver működjön ilyen körülmények között is. Ezzel szemben az AMD-nél már a Sony eleve wave terminológiát kért a PS4-hez, aztán követte őket a Microsoft is, tehát a GCN-nél már 2012-ben felmerült az igény arra, hogy a hardver így működjön. PC-n pedig ugyanezt bevetették 2016-ban a Doom Vulkan portjában, akkor még nem szabványosan, de ahhoz is kell fordító. Ergo amíg az NV-nél egyetlen ügyfél sem kért subgroup/wave terminológiára optimalizált fordítót, addig az AMD-nél ez két ügyfélnél már lassan 7-8 éve igény, a PC-s partnerstúdiók tekintetében pedig három éve. Ennyi idő alatt azért elég jól rá lehet jönni arra, hogy az adott hardver mit szeret, ha a lane-ek között adatmegosztás lehet shader lépcsőktől függetlenül. Alapvetően egy év alatt ki lehet ezt tapasztalni, csak nem elég tesztkódokat futtatni, hanem kellenek a production ready cuccok.
Ilyen különbségek azért nem történnek meg sűrűn, mert általában a piac az újdonságokra egyszerre lép rá, tehát úgymond valami nagy változás bevezetésénél egyszerre szarok a driverek, amelyek egyszerre fejlődnek majd. Manapság az eltérések azért szaporodtak meg, mert az AMD mindent évekkel hamarabb megcsinált szoftveres szinten. Az explicit API-kra vonatkozó implementációt a Mantle-lel, ebből él a Vulkan és a DX12 is. Szimplán van egy PAL rétegük, ami egységes, és fölé húznak egy API-tól függő részimplementációt. Szoftveres szinten azért marha nagy előny, hogy már a DX12 és a Vulkan bemutatására van egy működő absztrakciós réteged a hardveren, amire csak húzol egy kvázi wrappert, és már megy is az egész. Eközben az Intelnek és az NV-nek semmije nem volt a DX12 és a Vulkan API-hoz. Ők nulláról indultak, nem több év tapasztalatból, illetve több tízezer sornyi gyakorlatilag 99%-ban hasznosítható kódról. Ugyanez a shader fordítónál. Az AMD-nek rég megvan, rég működik, míg az Intelnek és az NV-nek megint a nulláról kell felépíteni.
Azt értsétek meg, hogy itt nem a hardver a rossz, vagy az API, vagy bármi az iparágon belül, hanem az a különbség csak, hogy az AMD-nek voltak olyan megrendelői, akik igényt formáltak ezekre az újításokra, már azelőtt, hogy a PC-n szabványosítva megjelentek volna, míg az Intel és az NV esetében ilyen megrendelő nem volt, így nekik értelmetlen volt korábban ebbe erőforrást rakni. Most persze raknak, már megvan az igény, csak a bevezetés szempontjából már nem azt látod, hogy mindenki nulláról indul szoftveres szinten.
A VMA-nak pedig semmi köze a fentiekhez. Az csak egy menedzsment lib. Leginkább abban van jelentősége, hogy mennyi VRAM-ot használ a program, az allokációk törlése hogyan zajlik, van-e defragmentálás, ha igen, akkor hogyan, stb. Ez minden hardvert kb. ugyanúgy értint. Az, hogy bekapcsolták valószínűleg abból adódott, hogy a saját megoldásuk túl agresszív volt, így talán a kelleténél többször törölt allokációkat, ami akadozáshoz vezethetett. Inkább választották azt, hogy legyen több VRAM-igény. Ezt leszámítva más problémát nem fog okozni egyetlen hardvernek sem. A VMA-t nagyon sokan használják a piacon belül, mert időigényes ~13-15 ezer sornyi kódot magadnak bepötyögni, és a végén kb. ugyanott leszel, ahol az AMD megoldása. Inkább érdemes ezt módosítani az igényeknek megfelelően. Valaki persze nem módosítja. Például az Ubisoft elmondta az idei GDC-n, hogy bekapcsolták az Anvil Vulkan portján, és out of box működött az egész, sose kapcsolták ki többet. A Quantic Dream PC-s portjai is ezt használják majd, az új Wolfenstein is ezt fogja használni, bár tudtommal az id software módosít rajta, mert annál a motornál vannak igen specifikus igények, amit egy általános lib azért nem fed le, vagy nem elég jól.
-
Abu85
HÁZIGAZDA
Mindenki távolodik már a Windows gamingtől. Valamelyik cég ebben sikeresebb, valamelyik kevésbé, de senki sem akar egy lábon állni, pláne úgy, hogy jelentősen drágul a chipgyártás.
(#39531) Loha: Az NV a mobil piacot feladta. Abból kiszedték a pénzt.
A konzolok ellen nem volt esélyük. Az AMD egy csomó mindent azért nyert meg, mert a GCN lett a de facto standard a fejlesztőstúdiókon belül. Amikor jönnek az explicit API-t használó címek, akkor nem pont azért kedvez az AMD-nek, mert az NV drivere gyengébb, hanem azért is, mert a fejlesztést AMD-n végzik. Lásd az Ubisoft is a Vulkan portját az Anvilnak AMD-re csinálta meg, és most kezdenek hozzá a GeForce optimalizálásnak.
Ezt látjátok ti is a teszteknél. Nálunk ugye zömében explicit API-t használó játék van, és mások az eredmények, mint azoknál az oldalaknál, akik az explicit API-t mellőzik. Ez a konzol és a driver előnye. Nem a hardver a jobb.A cloud gaminget az NV sajnos bebukta. Nagyon jó volt a koncepció, amit még 2010-es évek elején kezdtek, csak 2019 van és még mindig nincs SR-IOV support a hardverükben. Ez ugyanakkor teljesen az ő piacuk volt, mindenkinél hamarabb léptek, mindenkinél hamarabb értették meg fontosságát, viszont kilenc év alatt az AMD fejlesztett SR-IOV-s hardvert, és ennyi elég volt. Ezt ők cseszték el, pedig lehetne most a Microsoft és a Google a partnerük ebben. A Tencent is Intelre megy, pedig ők aztán kivártak elég sokáig, ami számukra versenyhátrány, de beszédes, hogy végül nem az NV-t választották.
-
Abu85
HÁZIGAZDA
De ez egy álomvilág. Oké, az NVIDIA felfogta, hogy kijött az első játék, ami subgroupot használ, és kellene hozzá a driver. Nem lesz meg holnapra, a következő hétre sem, talán még a következő hónapban is dolgozni fognak rajta. Természetesen csinálnak hozzá drivert, de van az amit akarsz, hogy holnapra legyen jó a sebesség, és van az ami a realitás, hogy talán tavasz végére jó lesz (nagyon talán).
Ilyenkor egyébként az van, hogy az NV a fölét-farkát behúzza. Lásd az első Tomb Raider, a Doom Vulkan portja, stb. A marketing ilyenkor annyi, hogy nem vesznek tudomást a jelenségről, mintha meg sem történt volna. Ez tart addig, amíg nem tudják mondani, hogy van hozzá driver, ti balfékek, milyen problémáról beszéltek?
![;]](//cdn.rios.hu/dl/s/v1.gif)
-
Abu85
HÁZIGAZDA
De, ahogy írtam ennek a játéknak nem is igazán a Vulkan implementáció a gondja, hanem a shader fordító. Amíg azon nem változtatnak, addig nehéz sokat nyerni.
Egyébként ez egy befektetési kérdés. Rengeteg dolgot lehet még ma is javítani a meghajtókban az explicit API-knál is, csak kérdés, hogy hova rakod az erőforrásod. Például, ha úgy látod, hogy a saját fejlesztőpartnereid nem fogják használni a subgroupot, akkor ugye miért is költenél rá?
-
Abu85
HÁZIGAZDA
Eleve semmit sem jósoltam az említett cikkben. Írtam egy programot, amivel lekérdeztem, hogy mit tudnak a hardverek, és azt írtam le.
(#39521) b. : Igazából az a kérdés, hogy mi a problémád. Ha az, hogy az NV-n rosszul fut, akkor azzal van gondod, hogy a játék subgroup shadereket használ, és arra még nem mindenkinek van hatékony fordítója. Ha az, hogy akadozott, akkor arra a patch kell, ami átrakta a memóriamenedzsmentet a gyári rendszerről, az AMD VMA-ra.
-
Abu85
HÁZIGAZDA
válasz
#26681856
#39518
üzenetére
Nem sok köze van ezeknek az API-hoz. Jön egy újdonság, és kell driverrel támogatni. Ennyi az egész.
Felőlem összemérhetitek az NV sebességét az AMD-vel az első wave terminológiát szabványosan használó játékban, de igazságtalan, mert az AMD ezt már kiterjesztésekkel ekkor bevezette: [link] Effektíve az AMD-nek magára a wave terminológiára van fordítója lassan három éve. Az első játék, ami ezt használta a Doom volt, ami szintén majdnem három éves. [link]
Most az van, hogy az AMD fejleszt valamit három éve, folyamatosan optimalizál rá, majd ebből lett nekik szabványos kódokra is fordítójuk. És akkor megy a csodálkozás, hogy három év és másfél-két tucat production ready cím után az AMD fordítója jobban működik, mint az NV-é egy évvel, illetve nulla production ready címmel a háta mögött. Nem normális, amilyen elvárást támasztotok az NV felé. Nagyjából egy hete láttak production ready subgroup shadert, de már az az elvárás velük szemben, hogy a három év tapasztalattal rendelkező AMD fordító sebességét legalább hozzák. Ez egyszerűen nem realitás. Kell az NV-nek egy kis idő, hogy elkészítsék a változásokat a meghajtóba.
Ezektől egyébként az NV nem megy csődbe, csak erőforrást kell rakniuk a shader fordítóra, amit majd optimalizálnak, és kb. egy éves távlaton belül a sebessége jó lesz a wave terminológiát szabványosan használó shaderekkel is.
Az erőforrás-menedzsment szempontjából pedig érdemes megjegyezni, hogy a Turing már az NV-nél is olyan lett, hogy nincs limitálva bekötés olyan mértékben, ahogy a Pascal esetében. Szakszóval a Turing is pure bindless, ahogy a GCN vagy a Gen9+. Ha annyira jó a Pascal szimplán bindless bekötése, akkor nem cserélték volna le.
-
Abu85
HÁZIGAZDA
válasz
runingman
#39512
üzenetére
Ez nem Vulkan specifikus. Mindegy maga az API. Maga a shaderek programozási terminológiája változik. A Vulkan esetében a subgroup megjelenésével, mint a DX12-nél a shader modell 6.0-val. Annyi a különbség, hogy ezt a wave/subgroup terminológiát először egy Vulkan API-t használó játék alkalmazta szabványos formában. Ugyanez lenne a helyzet shader modell 6.0-val, mert a Microsoft és a Khronos megoldása gyakorlatilag megegyezik az átalakítás szempontjából. [link]
(#39513) Petykemano: Nem. Egyszerűen nincs meg az akarat a fejlesztői oldalon. Azt vedd számításba, hogy a shaderek azért igen sok kódsort jelentenek. Egy AAA játéknál már 200 ezer sort is. Jó persze nem ez a legjobb módja az összehasonlításnak, de a lényeget mutatja, kurva sok kódról van szó. A fejlesztők olyan megoldást akarnak, aminél elég 200 ezer egységes sort megírni, és azzal fut minden hardver. Persze pár shaderre megoldható, hogy csinálnak alternatív kódokat, lásd az AMD kiterjesztéseit, de azok is azért lettek leginkább sikeresek, mert lényegében a PS4-es PSSL kódokkal tudtad őket etetni, tehát végeredményben extra karbantartási költséget jelentettek csak. De már emiatt is húzzák a fejüket sokan, tehát az ultimate megoldás a szabványosság.
Binárisok szállításával elsődlegesen az assembly szintű optimalizálás lehetőségét nyered, ami természetesen sebességre váltható. Viszont költség szintjén akkora kiadás, hogy csak konzolokra éri meg alkalmazni. Hosszabb távon egyébként mindegyik gyártó fel tudott eddig mutatni elég jó shader fordítókat, tehát nem kell attól megijedni, hogy valaminek a bevezetésének az elején vannak fennakadások. Persze, hogy vannak, újít az ipar, de ezekre emlékezni se fog a piac nagyjából egy év múlva.
-
Abu85
HÁZIGAZDA
A kernel driver szűnt meg, de a user mód oldali dolgok megmaradtak, és ide tartozik a shader fordítás. PC-n a bináris képtelenség. Tegyük fel, hogy megadják rá a lehetőséget. A fejlesztők lefordítják a shadereket binárissá, majd azokat szállítják. Addig jó lesz, amíg nem jön egy új GPU-család, amitől kezdve viszont a játék nem fog elindulni. Arra megint fordítani kell binárisokat, majd a következőre ismét, és így tovább. De egy idő után a játékokat nem támogatják, tehát be fog következni egy olyan pont, amitől kezdve az adott játék nem futtatható többet PC-n, az új hardverekkel. Ezért van a shader fordító a meghajtókban, hogy a játékok tudjanak IR-t szállítani, ami akármeddig fordítható az új hardverekre. Persze ennek megvannak a maga hátrányai, például az, hogy ha sokat változik a shader modell, mint mondjuk a Vulkan esetében a subgroup terminológia, akkor oda elég sok munkát újra kell kezdeni, és egy új shader fordító kell az újabb IR-ekhez. Hasonló váltások voltak régen is, és az egyes gyártók jobban felkészültek rá, mint mások.
Nem biztos, hogy azonnal sok javulást kell várni, azért shader fordítót fejleszteni nem egyszerű. Az a baj, hogy az NV-t ahhoz a szinthez méritek, amit az AMD képvisel szoftveresen az explicit API-k szempontjából, és ez borzasztóan igazságtalan ám velük szemben, amikor az AMD-nek ebben a programozási terminológiában van már lassan két évnyi tapasztalata, míg az NV-nél kb. most látták az első production ready kódokat, amik ugye szabványosak, tehát tudnak velük mit kezdeni. Két év tapasztalati háttérrel nagyon könnyű ám jobb shader fordítót fejleszteni.
-
Abu85
HÁZIGAZDA
Ha a shader fordító nem fordít egy hardverre jó kódot, akkor minden felborul. Mindegy, hogy Turing az architektúra, a probléma már ott felütötte a fejét, hogy a driver nem tudott a hardvernek hatékony kódot adni, amit a hardver természetesen nem tud javítani. Annyit tehet, hogy lefuttatja a rossz hatékonyságú lefordított kódot. Ugye PC-n nem lehet binárist szállítani, tehát minden optimalizálást a IR szintjéig kell betervezni, alatta már minden a driverben található shader fordító feladata.
(#39508) b. : A VRAM-ra vonatkozó idény nem az API-tól függ. Alapvetően most se gond a 6 GB VRAM, amíg nem mész 4K-ra, illetve nem használod a felbontásskálázást. A 4 GB-os VGA-kkal simán elvan a játék a legjobb alatti textúrarészletességgel.
-
Abu85
HÁZIGAZDA
Ezért jobb saját memóriamenedzsmentet csinálni. Az AMD sem azt javasolja, hogy kapcsoljátok rá a VMA-t, úgy ahogy van, hanem írják át az igényekre. Ennek az oka, hogy a VMA általánosan fedi le a memóriamenedzsment problémáját, vagyis sosem lesz olyan hatékony a memória kímélése szempontjából, mintha módosítva lenne, vagy a nulláról írna valaki egy saját menedzsmentet. Az előnye annyi, hogy kapsz ~15000 sornyi kódot készen, ami azért elég nagy előny.
A WWZ esetében volt a VMA és a saját menedzsment. A sajáttal jött a játék, majd a patch-ben átkapcsolták a VMA-ra. Na most a saját kóddal hiába törekedtek arra, hogy a 6 GB-os VGA-kba férjen be a játék full részletességgel, ez a VMA-nál már nem igaz, mert a DX11-hez hasonló a memóriaigénye, szemben a korábbi, saját kóddal, ami a DX11-nél is kevesebb VRAM-ot evett. Ez van, picit jobban működik a VMA, de ez nem azt jelenti, hogy NV-n rossz, mert minden hardveren megnőtt egy picit memóriaigény. Aztán, persze később visszakapcsolhatják a saját menedzsmentet, bár kétséges, hogy ebbe akarnak-e erőforrást fektetni.(#39504) Yutani: Jelen esetben a meghajtó fordítója a legnagyobb gond. A WWZ az első játék, ami subgroupokat használ, ehhez nem jók az eddigi fordítóoptimalizálások. De egyébként nem hiszem, hogy az NV hibázott volna, egyszerűen csak másra koncentrálták az erőforrásaikat, mert az elmúlt időszakban azt tapasztalták, hogy az AMD külön kódot kapott, tehát logikusnak tűnt azt feltételezni, hogy az AMD mindenképpen ragaszkodik a saját kiterjesztéseihez. Valószínűleg ez így is van, csak a Saber nem különösebben rajonghat a pluszmunkáért, így nem akarnak két kódbázist karbantartani, hanem mindenki kap szabványos subgroup shadereket. Mivel az NV és az Intel ezekkel először találkozik, így nyilván nem olyan hatékony itt a driver, mint az AMD-nél, akik már az irányt tekintve másfél-két tucat külön kódos kalandon túl vannak.
(#39505) cain69: Az önvezetésbe sokkal több érdekes szolgáltatás belefér, mint a váltóba.
-
Abu85
HÁZIGAZDA
A VMA-t és az RSL-t nem kell támogatni. Mindkettő teljesen szabványos header az érintett API-khoz. Semmit nem kell tennie az NV-nek és az Intelnek, hogy működjön, mert az RSL és a VMA is minden szabványos, rendre DX12 és Vulkan implementációval üzemképes. Ezért használják ezeket a fejlesztők, mert sokkal könnyebb egy már megírt alapra építeni, mint nulláról írni egy csomó kódot, és szabványos rendszerekről lévén szó a piac összes implementációján működnek.
Az NV és az Intel azért nem ír ilyeneket, mert lényegében ugyanazt tudnák megírni, amit a Microsoft és az AMD. Értelmetlen ezekbe erőforrást ölni, amikor az iparágon belül már van a problémára nyílt forráskódú megoldás.(#39501) cain69: Igény nem lesz erre. Az a gond, hogy a Bosch számára nem elég jó, hogy a Mercedes igényeit kiszolgálja. Költ egy rakás pénzt egy olyan platformra, aminél a Mercedes biztos jogot akar a szoftver birtoklására, hogy azt a Bosch ne tudja eladni másnak, vagyis a Mercedes megoldása megkülönböztethető legyen. Így viszont a Bosch számára az a gond, hogy egyrészt drága egy gyártót szolgálni, másrészt nem tudják, hogy a Mercedes mikor mondja nekik, hogy oké, ezt mi is meg tudjuk csinálni házon belül. Jó volt nálatok égetni a pénzt, de inkább megtartjuk...
-
Abu85
HÁZIGAZDA
Csak a VMA az AMD megoldása a WWZ-ben. Minden más a Saber technológiája. Persze használtak ProRendert lightmap bakinghez, de itt csak arról van szó, hogy nem nagy stúdióról van szó, így egyszerűbb számukra venni négy Radeon VII-et, mint ezer CPU-t, így világos, hogy az olcsóbb megoldást választják. Ettől a végleges program sebessége nem módosul, mert a számításokat előre elvégzik, és azt a programfuttatás során már csak megjeleníteni kell.
A VMA egyébként minden Vulkan játékba be van építve, egyszerűen ehhez viszonyítanak a fejlesztők, mert egy általános megoldásról van szó, ami gyakorlatilag lefed szinte minden menedzsmenttel kapcsolatos problémát. A gond vele az, hogy általános, tehát nem feltétlenül működik annyira hatékonyan specifikus környezetben, mint amennyire hatékonyat tudna egy fejlesztő írni az adott motorba. Viszont így is hasznos, mert ha mondjuk a kiadásig nem sikerül a saját menedzsmented megírni, akkor megpróbáltad, VMA-t aktiválni, és mehet ki a játék. Jó persze van olyan opció is, amikor kiadod a saját menedzsmented, aztán egy patch-csel cseréled a VMA-ra. Attól függő döntések ezek, hogy melyik működik jobban.
A Microsoftnak is van egyébként a DX12-re egy RSL-je, aminek hasonló célja van, csak az RSL-nél tudni kell, hogy a Microsoft ezt kiindulópontnak szánja, így csak úgy natúran nem feltétlenül hatékony. Az AMD a VMA-t, elsősorban kiindulópontnak, másodsorban pedig annak szánja, hogy aki nem akar saját memóriamenedzsmentet írni, az egyszerűen betölti a headert, és bamm, működik is.
Más gyártó is csinálhat hasonlót, csak különösebb hasznát senki sem látja, mert az RSL és a VMA is open source.(#39498) cain69: Olyan nem lesz soha. Maximum a hardvert megcsinálja nekik, de a sokkal nagyobb költséget jelentő szoftveres résszel nem éri meg vesződni csak egyetlen megrendelő igényeinek való megfelelés szintjén. Egy NVIDIA számára például anyagilag csőd, ha a Tesla igényeire szabnak egy teljes platformot. Egyrészt nem tudják az NVIDIA hardvereire lezárni, másrészt csak a Teslára költenek egy rakás pénzt, amiből alig látnak majd valamit vissza. Vagy mindenki viszi ugyanazt a platformot, vagy csak a hardvert fogják gyártani, és a nagy költséget jelentő szoftvert mindenki megoldja maga. Egyik cég sem a saját pénze ellensége.
-
Abu85
HÁZIGAZDA
válasz
velizare
#39492
üzenetére
Igazából minden autógyártó ezt fogja csinálni. Egyszerűen a saját zárt rendszerben érdekeltek, amit aztán licencelnek egymás között. Mondjuk a hardvert részben vagy egészben ettől még terveztethetik valakivel, de a szoftver az biztosan saját lesz.
(#39487) huskydog17: Most jelent meg a játék. Még nagyjából csak saját tapasztalatok léteznek. Majd ha bevesszük a tesztcsomagba, akkor már lesz róla teszttapasztalat is.
Magát a subgroup alapproblémát nem tudja megoldani patch. A fordítók a bűnösök, és azt a gyártók meg fogják oldani. Például az Intel legújabb meghajtója 30%-ot is gyorsított helyenként.
A memóriára vonatkozó dolgokat viszont gyorsan kezelték a játékban. Bekapcsolták az AMD VMA-t, és ez vezérlő a VRAM-ot a saját kódjuk helyett. Ez így egyébként jobb, mert stabilabb. Cserébe egy picit több VRAM kell a működéséhez, de igazából ahol a 8 GB elég, volt az elég marad, míg ahol a 4 GB kevés volt, az így is kevés lesz. A 6 GB-os VGA-k jártak rosszul, arra a határra volt belőve a motor.
-
#39486
Abu85
HÁZIGAZDA
huskydog17
#39475
Abu85
HÁZIGAZDA
válasz
huskydog17
#39475
üzenetére
Azért én használom, mert lényegesen jobb, mint a DX11-es leképező. Igaz 4 GB VRAM miatt nem tudok maximális textúrával menni, de csak abból kell visszavenni, és sokkal jobb sebességet kapok Vulkan alatt.
Én Vulkanon is azt látom, hogy jó minden. Igaz GeForce-szal még nem próbáltam. Annyi van, hogy van egy másfél-két perces periódus, amin át kell esni az akadásokat tekintve, és utána nincs egy szál se. Ez minden programindításnál így van, de két perc alatt megszűnik. Kivéve max grafikán, ott sajna kevés a 4 GB VRAM. De ez van, DX11 alatt is kevés.
Abszolút nem fut szarul, ha a 19.4.2-es meghajtótól használod. Én már egy újabbat használok, de az még béta, van nem kevés egyéb problémája, viszont még a 19.4.2-nél is újabb a Vulkan implementáció, és a WWZ-ben úgy kb. még gyorsul 5-10%-kal.
Amikor olyan újításokat használ egy program, mint mondjuk a subgroup arra azért nehéz tökéletes drivert csinálni a startra. Az AMD a saját meghajtóit a saját kiterjesztéseire írta, de ezek ugye eleve nem szabványos shaderek a program oldalán, tehát csak AMD-re tesztelik őket, és nyilván egy gyártóra jól lehet ezeket optimalizálni. A WWZ már nem használ gyártónként eltérő shadereket, hanem szimplán a subgroup függvényeket hívja meg, amely szabványos megoldás, viszont így már nem tudsz a shaderből nagyon gyártóspecifikus lenni, vagyis figyelembe kell venni az AMD mellett az NV-t és az Intelt is. Ezeket a shadereket viszont nem teljesen úgy kell fordítani, mint a régieket, mert régebben az történt, hogy egy shader a GPU-n csak egy szállal futottak. Itt a szál nem ugyanaz, mint a CPU-nál, inkább lane-nek szokás hívni, de a lényeg az volt, hogy csak a lane volt definiálva program szintjén, miközben a GPU-k szálszintű párhozamosságra tervezett megoldások, vagyis alapvetően képesek arra, hogy több lane-t futtassanak egy wave-ben (a wave-et a Vulkan subgroupnak hívnak, igazából mindegy a név). Tehát a legacy shadereknél a GPU-k még nem mondták meg az alkalmazás felé, hogy egy waveben/subgroupban hány lane-t képesek futtatni párhuzamosan, vagyis a shader fordító nem tudott más tenni, mint logikailag egy lane-re fordítani, és utána összefűzni a munkákat. Ez viszont nem igazán hatékony, mert a meghajtó számára nincs túl nagy mozgástér arra vonatkozóan, hogy egy shadert milyen GPU ISA-hoz közeli kóddá fordít. Ezért vezetik be az újabb nyelvek a szálszintű párhuzamosságot. Ezt ugyan az AMD már jó ideje elérhetővé teszi kiterjesztésekkel, de mint írtam, ilyenkor a fejlesztőknek specifikus shadert kellett írni AMD-re, aminek vannak karbantartási költségei is. Persze akkora gond ez nem volt, mert az AMD kiterjesztései gyakorlatilag úgy lettek megírva, hogy kis módosítással megegyék a PS4 kódjait, tehát akkora munka ebből így sem volt, viszont egyrészt a karbantartás így is költség, másrészt ezekkel a kódokkal az NVIDIA és az Intel semmit se tudott kezdeni. A szabványos megoldás ugyan picit kevesebbet tud, mint az AMD-é, pár függvény hiányzik belőle, de ezeket amúgy sem használták annyira, illetve a szabványosság nagy előnye, hogy az Intel és az NVIDIA is célozható. Viszont annyira más shader fordítót igényel, hogy elég sok munkát újra kell kezdeni, ugyanis már logikailag több lane-re kell fordítani, mivel a korábbi szálszinten soros feldolgozást felváltotta a szálszinten párhuzamos (a szál itt megint inkább lane-t jelent). Emiatt hiába írtak a gyártók akármilyen hatékony shader fordítót az elmúlt években, azt a know-how-t nagyrészt dobhatják ki, mert teljesen más fordító kell erre az új modellre. Az AMD is a saját kiterjesztéseihez írt fordító módosítását használja, míg az Intel és az NVIDIA számára ez nagyon új terület, ők nem igazán foglalkoztak ezzel a kérdéssel kiterjesztés szintjén, tehát nem sok tapasztaltuk van arról, hogy mi az optimális. Az AMD-nek pedig hiába van itt tapasztalata, más szabványos shaderről fordítani, illetve olyan shaderről, aminél a kiterjesztés specifikációját te magad írtad. Tehát ezzel nekik is lesz munka, csak némileg jobb teljesítményszintről indulnak a GPUOpen intrinsics miatt.
Egyébként valakinek mindig kell lennie elsőnek. A Doom amikor elsőként bevetette a Vulkan API-t, ugyanígy csak az AMD-nek kedvezett, mert akkoriban az NV drivere sokszor OpenGL alól hívogatta a Vulkan API-t, az meg persze, hogy nem gyors. A Doomnak persze probléma volt az allokációval is, de arra ugye jött egy NV kiterjesztés (NV_dedicated_allocation), amiből később szabvány (VK_KHR_dedicated_allocation) lett. Itt a Khronos Group nagyon sok dolgot csak átmásolt a Mantle-ből, aztán túl későn derült ki, hogy ez nem jól mappelhető GeForce-ra, és ezt az előbb említett kiterjesztéssel korrigálták. De akkor is a Doom az első Vulkan cím volt, és az első problémába bele is futott, pedig nem a Doom leképezőjével volt a gond, hanem csak azzal, hogy úttörők voltak, és az úttörők találják meg az adott ökoszisztéma gondjait is. De aztán jöttek az új NV driverek, és elkezdett gyorsulni a játék. Eltelt a megjelenéstől nagyjából egy év, és elég szépen teljesítettek a GeForce-ok is. Most a WWZ fejlesztői bevetették a subgroupot. Bevállalták az úttörő szerepet, és mint mindig beleütköztek a problémákba. Ettől a Vulkan implementációjukkal, ugyanúgy nincs gond, ahogy a Doomnak se volt, de a driverek nem állnak készen. De ettől az NV nyilván meg fogja írni jól a fordítót. Ezen eleinte elég sokat is lehet javítani. Lehet, hogy beletelik négy-öt hónapba, de ugyanúgy meglesz a támogatás, ahogy a Doomnál, mert nem ez az utolsó játék idén, ami subgroupot használ. Például a Quantic Dream is subgroupra tudja portolni a PS4 intrinsics függvényeit. Más lehetőségük nem igazán van, mert az AMD SPIR-V kiterjesztései csak Radeonon működnek.
-
Abu85
HÁZIGAZDA
válasz
TTomax
#39468
üzenetére
A PCI Express 4.0 nem elég. Az csak sebességet biztosít, de memóriakoherenciát nem. CCIX vagy CXL kell. Előbbit az AMD, míg utóbbit az Intel fogja támogatni. Ők hoznak is hozzá majd GPU-kat.
Nem nagyon érdekli a szoftvereket, hogy mi az általános nézet. Ha fizikát akarsz a GPU-n, akkor ahhoz bizony gyorsabb adatkapcsolat kell.
-
Abu85
HÁZIGAZDA
válasz
TTomax
#39466
üzenetére
A Microsoft azért vette meg a Havokot, hogy beépítse azt a DirectX-be. Ezzel kapcsolatban már javában mennek a munkálatok, de idén a DirectML lesz a nagy újdonság. A probléma egyébként itt a hardver. A PCI Express túl lassú, illetve nem is koherens, hogy normálisan lehessen gyorsítani a fizikát. De ugye az AMD és az Intel már tervez olyan platformszintű rendszert, ahol ezt megoldják, és arra veti majd be a Microsoft a saját szoftveres hátterét.
-
Abu85
HÁZIGAZDA
válasz
TTomax
#39463
üzenetére
Az akadások azért vannak, mert a benchmark elején még vannak fordítási munkák. Egy idő után jó is lesz, ha megnézed. Nagyjából 10-12 perc játék után ezek megszűnnek, illetve jelentősen megritkulnak. Ez is részben a driverekből eredő gond. Emiatt dolgozik még mindig ezeket az AMD és az NV, mert van egy rakás kihasználatlan teljesítmény.
-
Abu85
HÁZIGAZDA
válasz
TTomax
#39461
üzenetére
Ennek utánakérdeztem, mert a GDC-n már halottam, hogy ez az első játék, ami Vulkan 1.1-es képességeket használ. Mindenki elmondta, hogy kellenek még frissebb driverek, mert nagyon új kiterjesztéseket használnak. Az AMD a kiadás előtti utolsó héten javított +10-15%-ot. Ha a driverek rendben vannak, akkor last minute ennyi nincs benne.
Valamikor mindig van olyan, aki bevállalja az elsőt. A Doomon is rossz a Vulkan NVIDIA-n, aztán jöttek a driverek és javult. Ugyanez a helyzet most. Azt nem tudni, hogy mennyi idő kell hozzá. Tudtommal az NV-t nagyon váratlanul érte a subgroupra vonatkozó igény, de már ráhelyezték az erőforrásokat. Időpont még nincs, viszont dolgoznak rajta. Mivel alapvetően másképp működnek a subgroup shaderek, így beletelhet némi időbe, mire megoldják. Az biztos, hogy az AMD és az NV is mondja, hogy van még teljesítmény, ami nincs kiaknázva, de ez normális akkor, amikor elsőként nyúl egy játék az új kiterjesztésekhez. Egyébként egyik gyártó sem varrta eddig a fejlesztők nyakába, hogy új Vulkan képességeket használnak. Sőt, örülnek neki, még akkor is, ha munkájuk lesz vele. -
Abu85
HÁZIGAZDA
válasz
TTomax
#39456
üzenetére
Nem erről van szó. Ez az első játék, ami egyáltalán wave/subgroup terminológiát használ, ráadásul szabványos formában. Eddig ilyet csak úgy használtak a fejlesztők, hogy az AMD-nek a kiterjesztései alapján specifikus shadereket írtak, míg az Intel és az NVIDIA kapott szabványos shadereket. Mivel a shader modell 6-tal, illetve a Vulkan esetében a subgroup kiterjesztéssel lehetővé vált ennek a szabványos formája is, így nem kell az Intel és az NVIDIA hardvereire külön kódot írni, hanem minden gyártó kapja ugyanazt, erre való a szabvány. Viszont amíg az AMD már túl van hozzávetőleg egy tucat wave/subgroup terminológiát használó játékot, még akkor is, ha nem volt szabványos a shader, addig az Intel és az NVIDIA most találkozik az elsővel, és nyilván nem annyira van erre kigyúrva a shader fordító, mint az AMD-nél.
Nincs igazán különbség itt a hardverek között, legalábbis nem ekkora. Az AMD előnye csak abból ered most, hogy nagyjából másfél éve optimalizálnak erre, míg az Intel és az NVIDIA számára ez nem volt kritikus szempont, mert egyetlen fejlesztő sem volt hajlandó nekik nem szabványos shader szállítani. Most már ugyanez a lehetőség áll szabványos formában is, tehát jönnek majd a driverek tőlük. Bizonyos idő múlva nyilván tudni fogják ők is azt a sebességet, amit ma tud az AMD Vulkan implementációja, csak ez nem megy egyik napról a másikra. Hetek és hónapok munkájáról van szó.
-
Abu85
HÁZIGAZDA
válasz
rumkola
#39451
üzenetére
Shader fordító kell, és a subgroup pont egy shader nyelvre vonatkozó fícsör. PC-n ugye nem tudsz binárist szállítani, mint konzolon. Muszáj IR-t használni, és azt még le kell fordítani gépi kódra.
Ezekkel nehéz bánni, mert maga a shader intrinsics egy nagy fícsőr a DX12 és a Vulkan API-ban is, és nyilván tudták a cégek, hogy eljön az első játék, ami ezeket szabványos formában használja, csak közben van egy fix anyagi kereted, amit megpróbálsz a lehető legjobban elkölteni, például nem dobod el az erőforrást subgroupra, ha annak nincs hatása semmilyen játékban. Aztán persze amikor van, akkor majd gőzerővel odarendeled az erőforrást, hogy hozd a sebességet.
Nem baj az, ha nem volt még gyakorlatod a kereskedelemből. Az a gond, hogy olyannak írsz, akinek volt. 
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
A topikban az OFF és minden egyéb, nem a témához kapcsolódó hozzászólás gyártása TILOS!
Megbízhatatlan oldalakat ahol nem mérnek (pl gamegpu) ne linkeljetek.
- iPhone 13 mini 128GB Green -1 ÉV GARANCIA - Kártyafüggetlen, MS4052, 94% Akkumulátor
- Corsair gamer fejhallgató HS80 MAX
- Eredeti Lenovo 300W töltők - ADL300SDC3A
- Bomba áron eladó Asus Vivobook S433EA /i7-1165G7/16GB/512 GB SSD/FHD/IPS
- Samsung Galaxy Tab A9+ 128GB,Újszerű,Dobozaval,12 hónap garanciával
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest