Új hozzászólás Aktív témák
-
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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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ó.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
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.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
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.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
-
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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
-
Abu85
HÁZIGAZDA
válasz
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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#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.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
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.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
GeryFlash
#40824
üzenetére
De azóta a forint is a romokban, tehát sokat ez az összehasonlítás nem ér. Olyan mértékű a valós infláció, hogy ma a 220 ezer forint érezhetően kevesebbet ér, mint 2013-ban 151 ezer forint.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Ezekre a javítás ott a 442.50-ben. Vagy más hardvereken más driverben, de mindre van valami kiadott frissítés. A 442.50-es driverről készült hírben benne is van, hogy tartalmaz biztonsági frissítéseket.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Senki sem építette le a dGPU üzletágat, de ha megnézed a DoE számára készülő gépeket, ott heterogén rendszerek vannak az exascale szintre rendelve. Egy komplett Intel és egy komplett AMD gép.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
GeryFlash
#40889
üzenetére
Futtatni lehet a kódot bármin, maga a DXR úgy van felépítve, hogy ha van implementáció rá, akkor nem kellenek neki gyorsítást biztosító hardverek. Az a kérdés, hogy lesz-e 30 fps az új effektekből a mai hardvereken. Erre azért ne nagyon számítsatok. De lefutni lefut a kód.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Nagyon nem dolgoztak rajta. Egyszerűen mindenre szokatlanul nagy felbontású textúrákat használnak. Ebben a tömörítésnek nincs szerepe. A DirectX API-ban eléggé szabványosítva van, hogy milyen BC formátumok vannak az egyes problémákra. Ha nagyon akarnának erre gyúrni, akkor használtak volna ASTC-t az AGS-en keresztül, de nem tették, mert ugye kétszer kellene szállítani a tartalmat. És annyira sokat ezzel amúgy nem nyernének, maximum -20%-ot, miközben a játék telepített mérete majdnem megduplázódna.
A játék és a 3rd party programok kijelzése között az a nagy különbség, hogy a játék eléri a VRAM-ot, míg a 3rd party programok nem is látják. Emiatt egy nagy kövér hasraütéses tippelés, amit csinálnak. Én ezeket szoktam nézni RGP-vel, és a közelében sincs a valóságnak DX12-ben vagy Vulkan API-ban az afterburner. A legközelebb a Windows 10 feladatkezelőjében beépített mérő jár. Nem annyira pontos az sem, mint egy profilozó, de tényleg nincsenek 50-60%-os eltérések, inkább 3-5%. Az meg ugye reális, mert a profilozó az mégis egy frame-ről ad információt, míg a Windows 10 mérője nem.
Az RE2 Remake egyszerűen ennyit kér. Az volt a koncepciója a Capcomnak a memóriamenedzsmenttel, hogy nyugodtan rá lehet adni az maxot, a játék maximum nem tölti be a legnagyobb textúrákat, ha nincs hozzá elég nagy memória. Ehhez egyébként az is kellett, hogy ne csökkentsék mesterségesen a textúrák felbontását, hanem úgy voltak vele, hogy leszállítják a natívot, ahogy elkészültek. A legtöbb játék esetében tudni kell, hogy messze nem kapják meg azt a minőséget, amin amúgy elérhető lenne. Egy csomó olyan döntést hoznak a kiadás előtt, hogy bizonyos textúrákból csak a megalkotott felbontású verziónak a felezett minőségét szállítják. Emiatt férnek bele a játékok jórészt a 8-12 GB-ba. De ha ezzel nem akarnak törődni, akkor ki lehet adni a tervezett minőséget, az bizony zabál rendesen. Ha jól működik a memóriamenedzsment, és képes kezelni ezt a problémát, akkor tulajdonképpen miért ne, akinek megvan a VRAM-ja élvezheti tényleg maximumon, akinek pedig nincs meg, annak a memóriamenedzsment megoldja a minőségcsökkentést.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Én egy oldalt se láttam, ami megnézte volna profilozóval. Más nem látja a memóriát, csak tippel.
A 3rd party cuccoknak DX12/Vulkan API-ban ne higgyetek, magának az operációs rendszernek is elvették azt a jogát, hogy lássa a VRAM-ot. Hogy látná már azt egy olyan alkalmazás, amely azt se tudja, hogy a meghajtó mit csinál?Várják meg amúgy az RGP 1.5-öt. Abban a világon elsőként lesz memóriakép. Nem csak leírja, hogy mi van a memóriában, hanem le is rajzolja, hogy miképpen van benne, hogyan helyezkednek el az allokációk, azaz milyen a fragmentáció. Az már egy eléggé pontos adat lesz, hogy egy program mennyi memóriát igényel valójában.
Ha az RGP nem opció, akkor a Windows beépített mérője a legjobb. Nem pontos, de nagyságrendekkel pontosabb, mint egy Afterburner, meg a többi jósda.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Tényleg elhiszed amiket ezek a programok kiírnak? Maga az operációs rendszer nem képes rá, mert az API nem támogat kernel szerver szálakat. De egy garázsban egy kisgyerek ír egy alkalmazást, ami kijelzi a VRAM-használatot, miközben az explicit API-k megjelenése után több évvel jön végre egy olyan profilozó, ami memóriaképet tud adni a fejlesztőknek. Ha ez a probléma olyan egyszerű lenne, akkor a fejlesztők nem könyörögnének a jobb, akár memóriaképet adó profilozókért, hanem izzítanák az Afterburnert, és hiba nélküli memóriamenedzsmenteket építenének a játékaikba, mert az Afterburner megmondja. De nem ez történik, mert rohadtul nem mond meg semmit. Maximum félrevezet.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Ezernyi cikk van arról, hogy a homeopátia hatásos. Most akkor az?
Gondolkodj mielőtt elhiszel valamit. Majdnem öt év telt el a DirectX 12 megjelenése óta, és még nem kapott az API memóriaképet biztosító profilozót. Ehhez képest gondolod, hogy egy csomó program, mindenféle komoly anyagi háttér nélkül, dokumentációk nélkül megmondja, hogy mi van a VRAM-ban, amikor az AMD-nek ez öt évbe telt, úgy hogy ők tervezték a hardvereiket, és a drivert is hozzájuk, vagyis ismerik a forráskódot. Eközben az Intel és az NV még nem kínál ilyen lehetőséget. Még nem, de majd egyszer fognak. Persze nem is értem, hogy miért nem szerződtetik az Afterburner programozóját, fenéket ölne ebbe éveket és egy rakás pénzt, amikor kint van egy ember, aki tudja és megmondja.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Ezek szerint valószínűbb, hogy az AMD/Intel/NVIDIA nem képes erre. Istenem de hülyék, hogy a saját rendszereiket sem tudják, hogy miképp működnek, és azokat sem szerződtetik, akik tudják ezt.
Úgy keverednek ide, hogy ha egy kicsit is pontosak lennének, akkor használhatók lennének fejlesztésre is, de megközelítőleg sem pontosak. Csak félrevezetésre alkalmasak. Emiatt az AMD/Intel/NVIDIA pontos megoldásokat fejleszt, csak azok sok-sok ideig készülnek, mert nem triviális a probléma, még azoknak sem, akik tervezték az adott rendszert. Ne hidd, hogy akik ebben a folyamatban részt sem vettek, azok okosabbak náluk.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Könnyen elérhető módszerként legközelebb a Windows 10 feladatkezelőjébe beépített mérő áll. Nem annyira pontos, mint egy profilozó, de tapasztalataim szerint annyira sokat nem téved. +/-5% kb. ami elmegy.
Ha nagyon pontos adat kell, akkor RGP.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Igen. A föntire. Ott kell nézni a GPU memóriáját, ami 1.0/16.0 GB éppen. A grafikus egység megosztott memóriája nagyon pontos. A dedikált kiírás sajnos nem annyira pontos, innen származnak az eltérések a profilozókhoz képest. Ez az a rész, amit az OS nem igazán lát explicit API-val, és kb. semmi.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
keIdor
#41011
üzenetére
Annyival már nem limitáltabb az API. Ez a mostani generáció elején nagy gond volt, de manapság már nem az. Természetes persze, hogy konzolon esetleg lehetnek olyan hozzáférési módok, amelyek egy rajzolási parancsot talán 5-10 DWORD-ből is megoldanak, de annyival többe PC-n sem kerül már, így alig van különbség. Szóval az API gyakorlatilag már nem jelent problémát.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Locutus
#41065
üzenetére
De éppenséggel pont az lesz a célja. Az, hogy lesz Switch port leginkább annak köszönhető, hogy maga az új CryEngine már támogatja azt a konzolt is. A grafika pedig nagymértékben skálázható.
(#41066) b. : Nem tudnak régi CryEngine-t használni. A portolásnál pont az a lényeg, hogy az új verziókba építik bele a supportot. Mert grafikailag eléggé széles skálán lehet mozogni, elvégre PC-n is szoktak lenni very low és ultra high végletek, viszont ha a motor nem támogatja a célzott konzolt, akkor ennek nincs haszna. A Switch portot pont az teszi lehetővé, hogy az új CryEngine már támogatja. Szóval itt mindegyik platform ugyanazt a motorverziót kapja, de persze a szállított modellek, textúrák, illetve az általános grafikai minőség eltérhet. De ez már a dolog könnyebbik oldala.
(#41068) huskydog17: Meg lesz még egy csomó minden, elvégre a mostani CryEngine-ben már van SVOTI is, egy rakás effekt compute shaderre van portolva, ésatöbbi. Ez bőven elég a komoly grafikai szintlépéshez. Már az SVOTI az önmagában.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
-
Abu85
HÁZIGAZDA
Bármire, amire 7 nm-t írnak, kétségekkel érdemes nézni, mert az NV-nek jelenleg egyetlen 7 nm-es lapkája van a TSMC-nél, az pedig a legnagyobb. A többi a Samsungnál látható egyelőre, és 8 vagy 10 nm-es node-on. Nem valószínű, hogy ezek pár hónapon belül portolhatók 7 nm-re. Azért az egy teljes full node. Egy ilyen portoláshoz kell legalább másfél év. A TSMC ugye nem a Common Platform része, teljesen más technológiával dolgozik, mint a Samsung.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
-
Abu85
HÁZIGAZDA
Nem érné meg nekik, mert az AMD-től csak dizájnt kapnának és nem x86/AMD64 licencet. Ez nagyon fontos a semi-custom divízióban, hogy IP-t az AMD nem licencel a megrendelő felé, csak egyedi kérésre gyártat valamit.
Az RDNA2 7 nm-t használ. A 7 nm+ félreérthető. Ugye volt eredetileg az első 7 nm. Annak lett egy EUV-s verziója, de van egy nem EUV-s továbbfejlesztett 7 nm is. Tehát három node-ja van a TSMC-nek. Az AMD most az első, nem EUV-s 7 nm-es node-ot használja, míg az új lapkák a továbbfejlesztést, de nem az EUV-s verziót.
Az Advanced Node egyébként azt jelenti, hogy a TSMC egyedi node-ot tervez az AMD-nek. Ugye idén már ők számítanak a legnagyobb megrendelőjének a 7 nm-es node-ra, így a speciális igényeiket teljesítik. A proci kap egy 5 nm-es egyedi node-ot, és a GPU-k is egyedi gyártástechnológiát fognak használni.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Ú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 14 PRO - Arany - Gyönyörű
- iPhone 14 PRO MAX - 2026.10ig Garancia - Független
- Microsoft Surface Book 2in1 Érintős Szétszedhető Laptop Tablet 13,5" -60% i5-7300U 8/256 QHD+ Win 10
- Lenovo Thinkpad T490, 14" FHD IPS, I5-8365U, 16GB DDR4, 256GB SSD, WIN 10/11, Számla, garancia
- Féláron! Új Dell XPS 13 9315 Prémium Érintős Profi Ultrabook 13,4" -50% i7-1250U 16/512 UHD+ Iris Xe
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Alpha Laptopszerviz Kft.
Város: Pécs