Hirdetés
- Silent Hill 2 Remake - Középpontban a PS5-ös kiadás
- SWORD ART ONLINE Fractured Daydream - Elindult a nyílt teszt
- Hosszabb előzetesen a Tomb Raider animációs sorozat
- Jövő év elején jön a most bejelentett Like A Dragon: Pirate Yakuza in Hawaii
- Rövid teaser trailert kapott a Splinter Cell animációs sorozat
Új hozzászólás Aktív témák
-
#32040
Abu85
HÁZIGAZDA
Petykemano
#32028
Abu85
HÁZIGAZDA
válasz
Petykemano
#32028
üzenetére
Vega 10-ből nem lesz. De ez az első Vega. Van még Vega 11, Vega 12 és Vega 20, nem számítva az IGP-s Vegát, ami van a Raven Ridge-ben. A jó ég tudja, hogy ezek milyen node-on jönnek. A Vega 10 viszont érdektelen, mert a Vega 20 majdnem ugyanaz. Felesleges két lapkát gyártani ugyanoda.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Az NV vissza akar kerülni. Eléggé sok rendszerprogramozót felvettek már, hogy újra kapjon figyelmet az Apple meghajtó. A problémát az okozza, hogy az Apple nagyon mereven döntött a gyártók limitálása mellett, és ezzel elérte azt, hogy a szoftverfejlesztések is lényegében az Intel és az AMD GPU-kra korlátozódjanak. Ezáltal hiába próbál a meghajtó szintjén javítani a helyzetén az NV, a szoftverfejlesztők nem veszik őket számításba. Ezen a ponton az NV stratégiája az eGFX rendszerek támogatásának kihasználása, ami egyelőre nem megy flottul, hiszen minden Apple-nek szánt eGFX házra jól ráírják a gyártók, hogy csak a Radeonok működésére van garancia, de ez egy olyan terület, ami nem függ az Apple döntéseitől. Mondjuk úgy, hogy nem korlátozzák azt, hogy egy GeForce működjön, csak mossák kezeiket, ha mégsem működik. Kezdésnek ez nem rossz.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Az Apple igényei az AMD-t biztosan nem érhették váratlanul. Az iMac Pro régóta be volt jelentve, és az Apple a startokra nagyon fel szokott készülni, tehát jó előre leadják a pontos darabszámra vonatkozó igényt. És nem százalékot adnak le, hanem mennyiséget. A probléma tehát önmagában nem az Apple, hanem a többi piac okozta, ahol az AMD azt hitte, hogy kisebb lesz az igény. Azt is tudhatták, hogy mennyit lesznek képesek gyártani, ez nem titok a gyártópartnereknél, hanem be van kalkulálva. Ha úgy gondolták volna eredetileg, hogy kevés lesz, akkor valamelyik sorozatot nem indítják el. Ha rossz a kihozatal, akkor csak az egyik piac lesz célozva, és nem az összes rögtön. Ha valamit hirtelen bedobnak mindenhova, akkor az azt jelenti, hogy a gyártással nincs gond, ettől persze az igényeket alulértékelhetik, ami nyilván para.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Ha minden a terv szerint menne, akkor nem kellett volna befogni egy harmadik partnert a tokozáshoz. Marhára nem megy minden a terv szerint. Nem számítottak ennyi megrendelésre. A vártnál nagyobb igényre pedig nagyon nehéz reagálni, mert nem mondhatod azt, hogy oké, akkor xy piacot mégsem szolgálom ki, annak ellenére, hogy már bejelentettem két hete, és már vittek is pár hardvert az OEM-ek. Ilyenkor a legtöbb, amit lehet tenni az a gyártási mennyiség növelése, akár egy extra partnerrel. Viszont a gyártás nem azonnali folyamat, amíg egy ilyen lapka elkészül a nulláról az van úgy 6-8 hét, mire dobozolnak belőle egy VGA-t beletelik minimum 10 hétbe.
[ 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
Shkiz0
#32070
üzenetére
A megjelenés előtt nyilván tudták az idei fix megrendelést az Apple részéről. És ez alapján számoltak egy várható igényt, vagyis úgy gondolták, hogy az RX mellett bedobhatják a Frontier, az Instinct és a Pro modelleket is, mert a számolt igények alapján az összes célpiacra tudnak majd eleget gyártani. Hát nem tudtak. Ha vissza tudnának utazni az időben, akkor ma valószínűleg nem létezne se Instinct, se a Pro verzió, és ezek majd januárban jönnének, de már nincs visszaút, most már csak kezelni lehet a problémát.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Nem számít, hogy mennyit rendelt az Apple, mert a rendeléseiket már nyáron le kellett adniuk. Ez tehát az AMD-nél is egy fix tételként szerepelt. A felmérésüket csupán a többi piacra végezték el, tudva azt, hogy az Apple pontosan mennyi hardvert kér. Itt hibázott az AMD. A többi piac igényeit rosszul mérték fel. A valós igények alapján el se kellett volna indítani az Instinct és a Pro modelleket, csak az AMD augusztusban még úgy gondolta, hogy a tervezett mennyiséggel, levonva az Apple igényét, mindent le tudnak fedni. Hát nem tudták. Az utólagos tűzoltás pedig messze nem hatékony, elvégre az ilyen komplex hardvereknél egy extra partner befogása három hónap múlva tudja éreztetni a hatást.
A negyedéves előrejelzésekből hülyeség kiindulni. Ennek a csúcs-VGA-k alig az 1%-át teszik ki, leginkább még annyit sem. Abból indulj ki, hogy a teljes GPU-piacon a 300 dollár fölötti hardverek részesedése a JPR friss kiadványa szerint 2%.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Nem írok arról, hogy mennyi a megrendelés. De az látszik, hogy a Vega még mindig sok helyen hiánycikk, tehát az AMD még mindig nem tudja kiszolgálni az igényeket. És ennek nem az Apple az oka, mert róluk már a nyáron tudtak, tehát eleve egy betervezhető tényező volt. Ennek pusztán az AMD az oka, hogy messze alámérték a várható igényt. Innentől kezdve pedig a hibák követték egymást, mert az alámérés miatt kiadták az Instinct és a Pro modelleket is, ami egy újabb hiba volt, de persze szeptember elején még nem látszott, hogy nem fogják majd tudni kiszolgálni az igényeket. És ez nem a kihozatallal kapcsolatos probléma, mert amikor ez rossz, akkor a gyártók mindig csak egy szériát adnak ki, elvégre tudják, hogy úgy sem lesz elég hardver, nem szokás minden partnert szándékosan szopatni a hiánnyal. De az AMD öt célpiacra terítette a Vega 10-et, amit csak akkor tesznek meg a gyártók, ha a kihozatal rendben van. Ez persze nem jelenti azt, hogy a gyártókapacitás elég, ezért is lett befogva egy harmadik tokozó. Eleve nem lett volna gond, ha az AMD jól méri fel az igényeket, de ez nem ment nekik. Sőt, ha úgy nézzük, akkor ez az utóbbi időben jellemző problémájuk.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Ha gyártási nehézség lenne, akkor eleve nem adta volna ki az AMD öt piacra. Az hülyeség, hogy tudod, hogy problémád van, és szándékosan beszopatod a problémáddal az összes partneredet. Ezeket nagyon nem szereti az ipar, így jellemzően íratlan szabály, hogy ha kihozatali nehézség van, akkor csak egy piacon jelenik meg a termék, aztán majd ha megoldódik a gond, akkor jöhet a többi. Így minimalizálható a nehézségek okozta kár. A HBM-ből is annyit szállít a Samsung, amennyit kért az AMD. Még többet is gyártanak, tehát ha akarnak tudnak rendelni, és nyilván rendeltek is, mert az októberben befogott harmadik tokozópartnernek kell a komponens, csak mire ő be tud szállni normálisan a gyártásba az AMD két partnere mellé, lesz kb. január közepe.
Egyszerűen arról van szó a jelenlegi adatok alapján, hogy az AMD elbénázta, és alámérte az igényt.[ 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
Raymond
#32080
üzenetére
A gyártási kihozatal látszik már előre. Az nem titok számukra. És ha az AMD látja, hogy baj van, akkor eleve nem célozza meg a kihozatalproblémás GPU-val az összes lehetséges piacot. Erre láttunk példát a múltban. Sosem volt olyan, hogy egy alacsony kihozatalú hardver azonnal megjelent volna az összes célpiacon. Ennek oka, hogy úgy se lenne elérhető, így pedig értelmetlen a saját partnereidet szopatni a problémáddal. Tudod előre, hogy rossz, így próbálod a partnereid kárait minimalizálni. A józan észnek ellentmond, hogy pontosan tudod, hogy úgy sem jó a kihozatal, de elkezded szállítani az összes támadható piacra. Ezzel nem csak a partnerek szenvednek kárt, hanem a piacok is elveszik egymástól a hardvert, tehát a probléma a szegmensekre lebontva fokozódik, holott ilyenkor pont az enyhítés a cél. Szóval a gyártási problémakor az történne, hogy létezne RX és Frontier, de nem létezne Instinct és Pro. De az, hogy gyakorlatilag a Vega elérhető mindenhova, ahova egyáltalán ezt a hardvert be lehet rakni egyértelműen arra utal, hogy a kihozatallal nincs semmi gond. Ez azt is jelzi, hogy a probléma leghamarabb szeptember második felében ütötte fel a fejét, mert addig úgy döntöttek, hogy mindegyik célzott piacra megéri kiadni a hardvert, mert lesz belőle elég az előzetes felmérésük alapján.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Ki beszél itt sikerről? Az egyáltalán nem siker, ha nem tudják kiszolgálni az igényeket. Ez egy probléma. Ráadásul nem olyan egyszerű, hogy majd gyártunk többet, mert rövid időn belül már nem először méri alá az AMD a várható igényt, tehát itt a vezetőségi döntéseknél is gond van.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#32097
Abu85
HÁZIGAZDA
Petykemano
#32092
Abu85
HÁZIGAZDA
válasz
Petykemano
#32092
üzenetére
Bétatesztet nem csinálnak öt piacra. Egy piacra lehet persze, de nem adják ki a hardvert mindenhova. Főleg nem a szerverpiacra és a professzionális területre, na meg legfőképpen nem az Apple-nek.
Ha bármi probléma lenne a kihozatallal, akkor nem is lenne árulva a Pro és az Instinct verzió, de még a Project 47 sem. Azért itt komoly elvárások vannak, nem szeretik az itteni partnerek, ha az IHV szopatja őket kihozatali problémával.
Láthatod, hogy a Tesla V100 is úgy jelent meg, hogy előbb voltak nulladik generációs megrendelők, akiknek az NV szállított hardvert, és jó háromnegyed évvel később lett maga a hardver a disztribúciós csatornákon megvásárolható. Ha tehát a gyártással nem stimmel valami, akkor nem teszik elérhetővé a hardvert eladásra, hanem a partnerek jelentkezhetnek, és majd szállítanak nekik. Ugyanezt csinálta az AMD a nulladik generációs SSG-vel is. Ott is bejelentkezhettél és kaphattál közvetlenül, de boltban vagy OEM-nél nem vehetted meg. Csak onnantól élnek a disztribúciós csatornák a professzionális hardverekre, ha a gyártással minden rendben.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A saját gyártás az igazából a TUL-nak és a PC Partnernek a gyártása volt. Azért állították le, mert a TUL és a PC Partnerk le tud hitelesíteni egy másik modellt az OEM-eknél, így szükségtelen, hogy a referenciamodellt tovább gyártsák. Cserébe minden RX sorozatba szánt lapka mehet custombe.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
TTomax
#32147
üzenetére
Azért az OGL és a DX11 szimpla sebességbeli összehasonlítása nagyon nem szerencsés. Ezek API-k. Magukban nem hordoznak teljesítményt. Azt lehet maximum mondani, hogy x játék y API-n futó módja gyorsabb a z API-val elérhető módnál.
OpenGL 4-t egyébként jellemzően azért szoktak használni a fejlesztők, mert gyorsabb leképező írható rá, mint DX11-re. Rengeteg hasznos kiterjesztése van ugyanis az API-nak. Hogy ne menjünk messzire itt van példának a multi-draw indirect, ami nem kis fegyvertény, és ehhez hasonló koncepció csak a DX12-től van a Microsoftnál.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#32152
Abu85
HÁZIGAZDA
huskydog17
#32150
Abu85
HÁZIGAZDA
válasz
huskydog17
#32150
üzenetére
Ilyenek nem lesznek. Lásd a Wolfenstein 2 esete. Abban is csak a Vulkan van, mert az OpenGL mód az új leképezővel használhatatlanul lassú lenne. A Doomra jó volt 1000 draw/frame-re, de a Wolf 2-ben ez 30000, és ez sok a régi API-knak. Hogy miért, azt meg lehet nézni a 3DMark API Overhead tesztben. Ugyanez lesz a DX11 és a DX12 esetében is, ha a fejlesztők véghezvisznek egy id tech 6->6.5 jellegű fejlesztést. Magát az OpenGL-t és a DX11-et persze lehetne szállítani, de nincs értelme energiát ölni bele, ha a legjobb gépeken sem tudna értékelhető sebességet produkálni.
Az egyetlen opció az lenne, ha az NV és az AMD hajlandó tényleg specifikus optimalizálásra egyetlen címre, amikor is a fejlesztők ugyan DX11-et használnak, de gyártói segítséggel a szervizkönyvtárakon keresztül kikerülgetik az API-t. Ezek viszont nagyon ritkák. Lényegében kimerül az AotS-ben és a Battlefront 2-ben.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Először is érdemes tisztába tenni, hogy a konzolokon sem csak egy API van. PS4-en van libGNM és GNMX. Előbbi egy alacsony szintű megoldás, míg utóbbi egy wrapper erre, amivel egyszerű portolni a DX11-re írt játékokat. Az Xbox One-on még bonyolultabb a helyzet. Ott egy ideje elérhető a libGNM-nek az elvi megfelelője, ami a mono hozzáférés, emellett van még a szabványos DirectX 12 is. Ezekre nem épül wrapper helyette konkrétan a DirectX 11-nek egy módosítása van az egyszerű portolások érdekében. Ráadásul nem mindegy, hogy a program univerzális-e, mert ha nem direkten Xbox One API-jait használja, hanem az általános UWP-t, akkor a DirectX 12 és a mono API-k jelenleg el sem érhetők. Nyilván ez később változni fog, persze valószínűleg csak a DX12-re vonatkozóan, így a mono hozzáférés mindenképpen egyedi marad.
Az, hogy megy játék melyik API-t használja döntés kérdése. A legcélszerűbb a libGNM a PS4 és a D12 az Xbox One/PC platformokra. Persze ettől eltérhetnek, ahogy el is térnek. A Wolf 2 például libGNM-et használ PS4-en, mono hozzáférést Xbox One-on, és Vulkan API-t PC-n, ezt használja majd Switchre is.
Aki amúgy általánosabb motort használ, mint például UE4, annak szar a helyzete, mert csak a legújabb verziók igazán jók a konzolokon. Ezekre pedig sokan nem frissítenek, pedig PC-n is lényegesen gyorsabb lenne a program. A régebbi verziók még a konzolokon is a magasabb szintű API-kat használják.
Az Ubisoft régebbi AC játékjai sem túl lényegesek, mert az Origintől használnak low-level hozzáférést a konzolokon. Előtte nem tették ezt. Az Origin viszont libGNM-et használ a PS4-en és mono hozzáférést az Xbox One-okon. Át is írták ennek megfelelően az AnvilNext bekötési struktúráját, ami immáron pure bindless, vagyis minden bekötés a CPU terhelése nélkül történik meg. PC-n ezt a különbséget egy wrapperrel hidalják át, így maga a motor a bekötést a CPU oldali API-t tartalmazó kiegészítéseken keresztül oldja meg a DirectX 11-es hardvereken, mert ugye ez az API ezt a modellt nem támogatja, így kell valami kompatibilitási réteg a program és az API közé.
A látótávolság növelése sem igazán megoldás. Meg lehet csinálni, de nem ez az elsődleges célja annak, hogy az explicit API-k jelentősen csökkentették a többletterhelést. A helyzet az, hogy a látótávolság egy döntési tényező. Lehet úgy optimalizálni a tartalmat, hogy ez gyér legyen, de lehet úgy is, hogy igen messze el lehessen látni. És még nem is feltétlenül kell ehhez sok rajzolási parancs, elvégre vannak alkalmazható trükkök, például GPU-driven pipeline, stb.
A rajzolási parancsok számának drasztikus emelése leginkább azért kellett, hogy értékelhető alternatívává váljanak azok a leképezőtechnológiák, amelyeket korábban csak offline alkalmaztak. A tiled/clustered forward/deferred ilyen-olyan optimalizálásokkal is rendkívül limitált. Egy vagy jobb esetben két kézen megszámolható a mai játékok döntő többségében a shadow casting fényforrások száma, holott ezek növelése kritikus lenne a grafikai minőség alapvető emeléséhez, és a kifejezetten sok hamis hatást keltő pixelfények redukálásához. Erre vannak már nem csak koncepciók, hanem létező leképezők, amelyek a texel shading valamilyen formáját használják, és nemhogy tucatnyi, hanem sok száz shadow casting fényforrással is megbirkóznak anélkül, hogy a mai hardverek, akár konzolok teljesítménye összeomlana, a megfelelő skálázódáshoz viszont mindenképpen olyan API kell, aminek a többletterhelése alacsony, így nem lesz majd limitáló a rajzolási parancsok rendszerint magas száma. És ez már egy olyan technika, ami letör olyan korlátokat, amelyek miatt ma képtelenség elérni például a WALL-E vagy a Brave grafikai szintjét, holott igazából a hardver ereje már nem lenne akkora probléma.
Persze nem csak a texel shading az egyetlen lehetséges irány. A LABS-féle Deferred+ is ígéretes, de a texel shadingben hosszabb távon több a potenciá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
Balazs_
#32185
üzenetére
Nincs hajlandóság. Indie csapat, kevés tőkével, így sok dolgot nem tesznek meg.
A GoW teljesen más. Annak az UE verziója sokkal inkább a Microsoft fejlesztése, legalábbis az eredeti motort alaposan átírták. Leghamarabb a jövőre érkező gyári UE4 verziók lesznek kb. olyan fejlettek, mint amit az MS egy ideje alkalmaz.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Azon a szinten vagyunk, amit az E3 demókban látni. Onnantól kezdve a fejlesztők művészi változásokat eszközölnek. Az E3 demók sem futnak ám más gépeken, mint amik otthon vannak a felhasználóknál.
Sokkal inkább ennek a szintnek a megugrása a cél, de nem fog menni a jelenlegi leképezőtechnológiákkal. Nyugodtan nézzétek meg, hogy miért nem:
Clustered vs. Light Trees - itt valós időben láthatod, hogy mennyivel többet számol a clustered.
Deferred+ vs. Clustered Forward - főleg amikor a tesszellációt bekapcsolja a végén, akkor óriási az előny a deferred+ javára.És a clustered amúgy nem egy lassú megoldás, ső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
bozont
#32193
üzenetére
A háttérben ez nehezebb ügy, mint ahogy ezt megéritek. A fejlesztés során vannak elgondolások, amelyekből vagy lesz valami vagy nem. És amikor nem lesz belőle semmi, akkor annak leginkább az az oka, hogy az adott leképező, vagy technika egyáltalán nem úgy működik, ahogy azt elgondolták. Ez lehet stabilitási probléma, és itt gondolok arra, hogy akár képi hibákat is eredményez, vagy szimplán teljesítményre vonatkozó, esetleg legrosszabb esetben valamilyen külső szerződés által igényelt zárt effekttel vagy effektekkel való kompatibilitási gond, stb. Ezek mind olyan tényezők, amelyek az eredeti koncepciót kiadhatatlanná teszik. Nem véletlen, hogy az utóbbi években ez főleg az Ubisoftra volt jellemző. Ők dolgoztak egy rakás zárt middleware-rel. Az sem véletlen, hogy már nem így dolgoznak, csak ez jelentős károkat okozott, amit időbe telik felszámolni.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Nem látok semmi különlegeset a Wildlands videóban. Ez az eső teljesen átlagos. Szimpla specular az egész. Ennek a megvalósítása a hardver oldalán nem probléma. Alig kerül teljesítménybe. A gondot sokkal inkább a specular aliasing jelenti, ami ellen nehéz jól védekezni, tehát hiába rohadt olcsó az effekt maga, olyan shimmering-fesztivál lesz a kép, hogy attól sírva fakadna mindenki. Emiatt szokás a dizájnokon változtatni, jelen esetben visszafogni az esőt, mert lehet, hogy videón széttömörítve nem jön át az aliasing probléma, de normál renderben már fájdalmas lehet a helyzet, és nem igazán lehet ellene védekezni.
Ennek nem sok köze van az NV middleware-jeihez. Nyilván az Ubi okkal választotta az új projektjeihez az Intel-t vagy az AMD-t, de biztos nem a Wildlands esője volt az az ok.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A Polaris nem elég okos. Vagy egyáltalán nem, vagy csak kis részben reagál olyan problémákra, mint a wave programozás limitációi, a memóriamenedzsment problémái, a futtatott wave-ek cache hitet és erőforrás-allokációt hátráltató tényezői. Ez lehet, hogy a mostani shaderekben nem fájdalmas, de mi nem tudhatjuk, hogy milyen shaderekkel készülnek a fejlesztőknek 2018-ra. A Vega limitje egészen máshova vannak helyezve, olyan dolgokat is megtehetnek vele, ami korábban csak egy nedves álom volt. Ha a szoftveres team az AMD-nél erre rájátszott, akkor nem sok haszna van a Polarisra építeni a következő évet.
A bányászatra pedig nem lehet építeni, az nem egy értékelhető tényező. Főleg úgy, hogy jelenleg egyértelműen látszik a Polaris mielőbbi kiszórása, mint stratégia.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#32263
Abu85
HÁZIGAZDA
Petykemano
#32261
Abu85
HÁZIGAZDA
válasz
Petykemano
#32261
üzenetére
Ezt nem nehéz meglátni. Az új generáció mindig arról szól, hogy a generáció élettartama alatt előtérbe kerülő problémákra a hardver már azelőtt reflektáljon mielőtt az rendkívül limitáló lenne. Emiatt az sem véletlen, hogy a Vega és a Volta architektúra gyakorlatilag egyidőben reagált a wavefront/warp erőforrás-allokációival kapcsolatos problémáira. Emiatt a Vegában már nem fixen 32 kB-os az LDS, hanem dinamikusan particionálható egy 64 kB-os tárból, míg a Volta esetében az L1 és az LDS össze lett vonva, így az LDS itt is dinamikusan particionálhatóvá vált. Ezzel reflektálnak a közeljövő egyik súlyossá váló limitjére, így az újabb architekturák biztosan ellő mennyiségű tárterületet tudnak erre fenntartani, hogy az ne korlátozza a futtatható wavefrontok/warpok számát, amivel nem lesz limitálva az elérhető sebesség. Annyira nem nehéz ezeket meglátni, még azt is tudni már, hogy az Intel Gen10-ben is dinamikusan particionálható lesz az LDS.
Az sem véletlen, hogy az AMD, az Intel és az NV ezt egyszerre látta meg. Kiüti az ember szemét ez a probléma manapság.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#32268
Abu85
HÁZIGAZDA
Petykemano
#32266
Abu85
HÁZIGAZDA
válasz
Petykemano
#32266
üzenetére
Fenéket várja meg, ha megvárnák, akkor nem vetették be a Voltában a dinamikusan particionálható LDS-t. Ugyanakkor annyira érezhető a probléma, hogy erre reagálni kell, mielőtt látható hatása lenne a teljesítményre, mert nagyon nem mindegy, hogy egy multiprocesszor a lehetséges wave-ek 80-90-100%-át futtatja, vagy csak 30-40-50%-ot.
Nem különösebben lényeges, hogy pontosan mikor jelent meg az architektúra. Az a lényeges, hogy van egy életciklusa, és ezalatt az életciklus alatt tudnia kell kezelni a futtatott programokat, ráadásul hatékonyan, tehát nem elég azt elérni, hogy a shader lefut pár wave-vel, fusson le sokkal. Nektek ezekről a dolgokról nem feltétlenül kell tudni, mert úgy sem értitek, de az AMD, az Intel és az NV érti, és reagálnak rá. Felétek, vásárlók felé elég azt közölni, hogy hatékonyabb lett, nem kell belemenni az erőforrás-allokáció statikussága által jelentkező egyre égetőbb probléma magyarázásába. Úgy sem fogná fel a vásárlók 99,9%-a a problémát, a lényeg, hogy az új dizájnok, mint a Vega és a Volta kezelik, elég jól.
Akit érdekel, azok számára itt van részletesebben: Vega és Volta[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#32276
Abu85
HÁZIGAZDA
Petykemano
#32274
Abu85
HÁZIGAZDA
válasz
Petykemano
#32274
üzenetére
Először ott, de nyilván ugyanerre reagálni fog a többi GPU is.
Még mindig a megjelenésen lovagolsz, amikor ez az életciklusról szól. A Vega életciklusa bőven belenyúlik a 2019-be, és a Voltáé is. Emiatt ezeknél már kezelni kell ezt a problémát. A Polaris és a Pascal életciklusa 2018-ban véget ér. Nem számít, hogy mennyivel rosszabb a hatékonyságuk ebből a szempontból, mert amikor ez a probléma a gyakorlatban felüti a fejét, akkorra már az üzletekben ezek csak elvétve lesznek megtalálhatók. A saját életciklusukat tehát jól teljesítették.
A fejlesztő oldalán igazából a Vega megoldását nem kell támogatni. Direkten optimalizált kódot csak a Volta igényel. Ezt sem nehéz amúgy megírni, tehát ebből nem lesz gond, szimplán ki kell kísérletezni, hogy melyik partíciós beállítás az ideális. A Vega erre vonatkozó megoldása automatikus, semmiféle program oldali kísérletezést nem igényel.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#32346
Abu85
HÁZIGAZDA
Petykemano
#32277
Abu85
HÁZIGAZDA
válasz
Petykemano
#32277
üzenetére
Nem érted a lényeget. Időpontokba kapaszkodsz, amikor látható a programokon, hogy egyre komplexebb shadereket használnak, amelyek egyre rosszabban futnak a statikus erőforrás-allokációval. Márpedig a ma létező GPU-k nem valami okos jószágok, hírből sem ismerik a dinamikus allokáció lehetőségét, hardveres támogatás erre pedig lényegében nincsen. Azt nem állítom, hogy később nem lesz, de ez még nagyon a jövő zenéje. Ergo minden egyes új generációnál el kell gondolkodni azon, hogy az egyre komplexebb shadereket az alapvetően ugyanúgy működő GPU hogyan kezeli majd le. Emiatt láthatod manapság, hogy bár maga a statikus erőforrás-allokáció mint működési elv nem változott, de egyre jobban próbálják segíteni a rendszert. Ilyen volt például az AMD Polarisban és az Intel Gen9-ben érkező utasítás-előbetöltés. Ezekkel nem volt szükség annyi wave futtatására az optimális kihasználáshoz, mint korábban. Mert ugye maga az alapprobléma az, hogy az adott hardver számára szükséges xy wave, hogy a feldolgozók dolgozzanak is, de a komplexebb shaderekkel, ezen belül is az általánosan elterjedt übershaderes megközelítéssel a szükséges wave-ek esetlegesen csak fele futhat, vagyis a feldogozók egy jó része boci szemekkel néz a memória felé, hogy küldje már azt az adatot, mert anélkül nem tud dolgozni.
Maga a probléma hardverenként eltérő. Az Intel dizájnja például ki van tömve regiszterekkel, lényegében szinte mindig képes a maximális wave-számot futtatni, mert fizikailag úgy van megtervezve, hogy legyen erre elég regiszter. Ennek a hátránya az, hogy háromszor annyi tranzisztorba kerül az Intelnek egységnyi ALU teljesítmény beépítése, mint például az AMD-nek, és az LDS limitjeit ez nem oldja meg, mert azt a rendszer statikusan csippenti le az L3-ból, ami egyrészt helyhiányhoz vezet, másrészt messze van az ALU-któl. Ezért vezették be ők is az utasítás-előbetöltést, ahogy az AMD, hogy lejjebb tudjanak menni az optimálisan futtatható wave-ek számában.
A Vega és a Volta pusztán egy újabb lépés a történetben, mert látva a fejlesztők koncepcióit abszolút nem kérdés, hogy a shaderek bonyolultabbak lesznek, így nő a register/LDS pressure, ami az Intel, az AMD és az NV SIMT elven működő architektúráinak a halála. Az más kérdés, hogy a trükkös megoldás helyett a Vega és a Volta elment a brute force felé, mert annyi trükkre már nincs lehetőség hardveresen vezérelt erőforrás-allokációvaló nélkül, ami viszont komolyabb fejlesztést igényel, nem beszélve arról, hogy sokat növelne a fogyasztáson, ha most beraknának egy bonyolultabb hardvert erre a problémára, de előbb-utóbb ez is meg fog történni. A brute force koncepció is csak egy-két generációig életképes, aztán lépni kell tovább, mert több lesz a hátránya, mint az előnye.
A Vega és a Volta dinamikus LDS allokációja még abból a szempontból szerencsés, hogy lehetővé tesz pár szoftveres trükköt. Az AMD megoldása ugyan automatikusan működik, de készül a Vulkan API-hoz egy szoftveres kontrollt lehetővé tevő kiterjesztés, amivel a fejlesztő limitálhatja az egyes shadereknél a wave-ek számát, hogy jobb legyen a cache-hit, és ez működik az összes GCN-re, de a Vegán a leghatékonyabb. A Volta esetében az direkt optimalizálás nem igazán lehetőség, hanem egy kötelező elem, mert automatikusan nem sok dologra képes az a dizájn, viszont tranyók szintjén olcsó kezelést kínál az alapproblémára, ha a fejlesztő szán rá egy kis időt, hogy jól fusson a hardveren az adott shader.A lényeg annyi, hogy az egyes architektúráknak van egy életciklusa. Ez akkor is tart, amikor már nem tudod őket megvásárolni a boltokban, és a gyártók nézőpontjából okvetlenül fontos, hogy erre az életciklusra rá legyen tervezve a hardver. És láthatóan nem egy gyártó gondolja így, mert ha úgy lenne, akkor csak egy cég vezette volna be az utasítás-előbetöltést, a dinamikus LDS allokációt, a wave-ek szoftveres kontrollját, de mit ad az ég lényegében mindegyik újítást minimum két gyártó kínálja már legalább egy, ma elérhető hardverben. Tehát nagyon egységes, amit a fejlesztőknél látnak.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Az két külön bekezdés. A második arra vonatkozik, hogy a gyártók nem látják olyan eltérően a lehetőségeket, mert nem csak egy IHV-nek van utasítás-előbetöltést, dinamikus LDS allokációt, vagy szoftveres wave-kontrollt kínáló megoldása. Tehát ezek a kezelések nem specifikusak, hanem általánosak. Reakciók arra a problémára, hogy a shaderek egyre komplexebbek, és a manapság elterjedt übershader modellel a nem a legújabb generációs hardverek dizájnja végeredményben adatra fog várni, ami nem optimális az ALI-kihasználás tekintetében. Ez ellen persze még mindig lehet tenni aszinkron compute-tal, de ebben sem olyan jók a korábbi GPU-k, mint a legújabbak. Ergo minden gyártó azok gondolkodott az új generációnál, hogy miképpen tudnák elérni azt, hogy a komplex übershaderek futtatásakor az adott dizájn tudjon elég wave-et futtatni, vagy az adat hamarabb érkezzen meg, esetleg mindkettő.
A következő lépcső már az erőforrás-allokáció hardveres menedzselése lesz, mert a trükköket lényegében a Vega és a Volta generációja bevetette, így legközelebb már muszáj nagyban gondolkodni, még úgy is, hogy az komolyan megnöveli a dizájn komplexitását.
Hosszabb távon még az OOO logika is opció a lane-ekre, mert egyre inkább arra megy a szoftverfejlesztés, hogy az aktuális shader nyelveket felváltja a C++, és ezekbe majd írhatnak kódot a tartalomkészítők is. Ez egyrészt jó, mert jelentősen megoszlik a teher egy stúdión belül, másrészt viszont rossz, mert abból indul ki az egész feltevés, hogy a CPU-k esetében a teljesítményt csak a teljes kód egy kis, mondhatni kritikus része határozza meg, így elég azt optimalizálni. A kódbázis nagy részét lehet szabadon változtatgatni anélkül, hogy az radikális mértékben rontana a programfuttatás sebességén. Egy GPU esetében ez nem így működik, mert itt lényegében minden kód kritikus, vagyis ha a shadereket a jövőben nem optimalizálják tökéletesen, akkor onnantól kezdve a hardvert kell kigyúrni rá. Ez azonban még több éves kérdés, jelenleg az regiszterekre és az LDS-ekre vonatkozó erőforrás-allokáció statikus jellege jelenti a legnagyobb problémát.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A primitive shader nem segít a multiprocesszorok allokációs problémáin. Az csak annyit tesz lehetővé, hogy még azelőtt kivághatóvá tesz számos fals pozitív háromszögeket, mielőtt eljutnának a vertex shader lépcsőig. Ez a futtatható wave-ek számára nincs hatással, azt ettől függetlenül meghatározza az adott übershader.
Az a baj, hogy nem csak az NGG jelent meg a driverben, de amúgy 30-40% a gyorsulás a 17.30 és a 17.50 batch között a Wolf 2-ben.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Az energiamenedzsmentet nem sokan értik, mert itt senki sem mérnök. A lényege ezeknek, hogy a hardvert mindig a határra helyezzék. Ezeket a dolgokat még nem is az Intel, az AMD vagy az NV találta ki. A DVFS és az AVFS elvű koncepciók már régóta léteznek, csak az elveket implementálni is kell. Kezdetben ugye mindenki dinamikus skálázást implementálta, mert azt nagyságrendekkel egyszerűbb megoldani, elvégre nem kell egy hardvert felépíteni arra, hogy a környezeti paramétereket figyelembe vegye a lapka az órajel beállításánál. Elég a hitelesítésénél megmérni a tervezett körülményekre a működést és abból pár mérnök számol egy táblázatot, amit betöltenek a lapkába, és onnantól kezdve az működik. Az adaptív megvalósítást még csak az AMD implementálta, mert nagyságrendekkel bonyolultabb a kivitelezni, ugyanis nincs fixen betáplált táblázat, egy hardver van beépítve többezer véletlenszerűen elszórt érzékelővel, és a mért adatokból számolja a rendszer a táblázatot, ami alapján működik. Itt ebben a nehézség az, hogy jó adatokat számoljon.
Az eddigi tanulmányok szerint az AVFS 10-15% pluszt jelent a DVFS-hez képest a teljesítményben. Ha ez nem lenne benne az AMD hardvereiben, akkor vonj le a teljesítményükből 10-15%-ot és ott lennének DVFS-sel. Legalábbis a Polaris bemutatójakor azt mondták, hogy a méréseik ennyi különbséget adnak.Azt is tegyük hozzá, hogy az AMD GPU-tervezőinek nagyon egyszerű dolguk volt ezzel. Gyakorlatilag a CPU-s tervezők tálcán szállították nekik az AVFS-t, ezt csak be kellett konfigurálni, és működik. Az NV-nek sokkal nehezebb dolga van, mert nekik senki sem szállít tálcán ilyet. Nekik ott kell ülni a tervezőasztalnál, és megcsinálni az implementációt, amit aztán jó másfél évig tesztelnek, stb. Mire az egy tömeggyártható lapkába eljut jó 4-5 évről beszélünk. Az AMD sem AVFS-ezne a GPU-knál, ha nem osztaná meg a CPU-s és a GPU-s részleg a technológiákat.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Ez simán igaz lehet, hogy az általános AIB-k keveset kapnak. Az AIB-k között van kiemelt és általános. Az AMD-nél a rendeléseket hierarchia szerint teljesítik, tehát vannak az olyan kiemelt megrendelők, mint az Apple és az exkluzív partnerek, és van a többi. A többi például addig nem kap nagyobb mennyiséget, amíg a kiemeltek igényeit nem teljesítették. Ebből úgy lehet kikerülni, hogy átmegy az általános AIB kiemelt státuszú megrendelőbe, de ez azzal jár, hogy a megrendelőnek vagy 75%-ban AMD GPU-t kell vásárolnia, és csak 25% lehet NV GPU, vagy vállalnia kell, hogy évente egy minimum meghatározott mennyiséget rendel az AMD GPU-iből. Például a PowerColor/Sapphire az előbbit választja, míg az ASUS az utóbbit.
Nyilván nem véletlenül fogták be a harmadik tokozó üzemet, mert egyszerűen akkor az igény, hogy a tervezett két üzemmel nem tudják kielégíteni. A harmadik üzem pedig még nem igazán működik teljes gázzal. Ez az általános AIB-k számára kellemetlen, mert hiába rendelnek, hiába van feléjük is megrendelés a kereskedőpartnereik oldaláról akkor is kevés lapkát kapnak.(#32388) oliba: A részesedést az ilyen drága hardverek kimutathatatlan mértékben növelik vagy csökkentik. A friss JPR jelentés szerint a 400 dollárnál drágább VGA-k összesen nem tették ki a teljes eladás 0,1%-át. 0,07% volt csak, és itt az AMD+NV együtt értendő. A részesedésre leginkább a 150 dollár alatti grafikus vezérlők vannak hatással, azok teszik ki az eladások 83%-át.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
0,1% az éves szinten úgy ~420-450 ezer eladás a GPU-piacon. Gyártókra itt ez nincs lebontva, illetve a professzionális nincs benne. Az egyébként kb. ugyanennyi, legrosszabb esetben úgy 300 ezer mindenképpen megvan ebből is.
Az AMD és az NV nem igazán a 400+ dolláros gaming piacból él, hanem a 100-400 dollár közöttiből. 400 dollár alatt ugrásszerűen megnő az eladott termékek száma.(#32390) Petykemano: Lekérdezik az eladási adatokat.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#32403
Abu85
HÁZIGAZDA
Petykemano
#32402
Abu85
HÁZIGAZDA
válasz
Petykemano
#32402
üzenetére
Nincs semmiféle új termékvonal. Egyszerűen csak oda lett írva, hogy "for Blockchain Pioneers". De amúgy se az ára nem változott, se semmi más. Az, hogy a kereskedők mennyiért adják nem az AMD-re tartozik, amíg kifizetik az AMD felé a megbeszélt pénzt, továbbra is 1500 dollárért van benne a havi szinten küldött árlistában.
Vannak ilyenek néha, hogy a webáruház vág gyorsan rajta, és azt hiszi a piac, hogy az AMD vágott. A tél elején teleküldték a mailboxomat olyan közleményekkel, hogy nem történt hivatalos Ryzen árcsökkentés, csak xyz webáruház magánakciójáról van szó.
Az árcsökkentés előtt egyébként két héttel szólnak, tehát a következő két hétben tuti nem megy le 1500 dollárról a Frontier hivatalos ára.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
-
#32408
Abu85
HÁZIGAZDA
cskamacska
#32407
Abu85
HÁZIGAZDA
válasz
cskamacska
#32407
üzenetére
Egyik sem megoldás.
A DX9 SDK azért nem, mert az csak egy SDK. A runtime-mal is telepítve vannak a fontos dll-ek. A Steam mindig telepíti az első futtatás előtt.
A shader cache kikapcsolása csak azoknál a játékoknál számít, amelyek nem kompatibilisek vele és az AMD még nem adta hozzá ezeket a feketelistához.Van egyébként egy ultimate megoldás, amit kipróbáltunk már és működik. A hírben benne lesz.
Ez egyébként nem driverhiba. Visszatérő jelenség a hosszabb távú terméktámogatás során. Az okozza az egészet, hogy az AMD és az NVIDIA régen sokáig elfogadta, ha egy fejlesztő butaságot írt a programba. Egyedül az Intel kötötte magát ahhoz igen sokáig, hogy a szabvány világosan fogalmaz, és nem hajlandók a programhibákra meghajtó oldali kerülőutakat írni. Ezzel ugyanis magát a programhibát legalizálnák, amibe később bármelyik fejlesztő belefuthat, méghozzá úgy, hogy nem is tudja, hogy nem szabványos kódot írt. Ha mindhárom cég meghajtója működi, akkor nincs semmi gond a kóddal ugye...
Ez a modell üt akkor vissza, amikor egy nagyobb fejlesztés végbemegy, és pusztán a nem szabványosan megírt játékok miatt a régi fejlesztőeszközöket frissíteni kell, hogy újra implementálni tudják a megfelelő rutint. Ezek a programok most azért nem működnek, mert egy szabványos D3D9 implementációra vannak kényszerítve, de olyan dolgokat csinálnak, amiket az API meg sem enged. Időnként ez elő szokott jönni.
Sajnos ma is rengeteg illegális dolgot legálisnak tekintenek az egyes meghajtók, akár az újabb API-kban is, lásd Vulkan. Például az inline subpass simán meghívja a vkCmdExecuteCommands függvényt, amikor az API meg sem engedi. Ilyenkor az alkalmazásokat nem a szabványos layeren keresztül kell kezelni, mert olyan dolgot tesznek, amit az API nem tart legálisnak. Erre vannak különböző modulok a meghajtókban.
[ 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
TTomax
#32418
üzenetére
A professzionális piacon ez nem egyedi jelenség. Volt aki tudott szerezni 2000 dollárért 7000 dolláros Radeon Pro SSG-t is. Vannak ilyen dealek, ezekre le kell csapni, amíg él az ajánlat. Az egyes áruházak szoktak olyat csinálni, hogy nagy mennyiségben vesznek hardvert, és akkor alámehetnek listaárnak, mert tudnak alkudni a gyártóval. Ha mondjuk 100 Frontiert veszel, akkor valszeg 1100 dollár alá nem adja az AMD sem, de mondjuk ha 2000-3000-et kérsz, akkor ott már bőven a listaár alá mennek egy mennyiségi kedvezménnyel.
Az Intelről is vannak vicces sztorik. A 160 dolláros Pentiumot 30 dollárért is eladják, ha 10k-t rendel a partner. A listaár ilyen szempontból értelmetlen náluk.
Az NV-nek is vannak mennyiségi kedvezményei.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#32491
Abu85
HÁZIGAZDA
->Raizen<-
#32490
Abu85
HÁZIGAZDA
válasz
->Raizen<-
#32490
üzenetére
Single-ben is próbáld ki AI nélkül. Akkor biztos nincs olyan terhelés a kernel felé, ami az új OS struktúrát annyira túráztatja, hogy tényleg érezhető negatív hatása legyen a teljesítményre. Ha így single-ben is problémás, akkor nem a meltdownra vonatkozó OS frissítés okozza.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#32494
Abu85
HÁZIGAZDA
->Raizen<-
#32493
Abu85
HÁZIGAZDA
válasz
->Raizen<-
#32493
üzenetére
Te ismered, hogy milyen sűrűn csinálja multiban.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#32497
Abu85
HÁZIGAZDA
->Raizen<-
#32495
Abu85
HÁZIGAZDA
válasz
->Raizen<-
#32495
üzenetére
Világos, de az oka még nem tisztázott. Nyilván a Meltdown javítás okozhat ilyet multiplayer szinten, hiszen ott bejön a hálózati adatforgalom a képbe, amit pont érint az OS új struktúrája. Viszont single-ben, AI nélkül (ami ugye a Forza esetében szintén lehet szerver oldali) ettől a terheléstől majdnem megfosztod a rendszert, tehát minimalizálod az új OS struktúra hatását. Ergo, ha a kellemetlenséget a Meltdownra adott javítás okozza, akkor annak nem igazán kell jelen lennie AI nélküli single módban, de minimum erősen csökkennie kell a jelenségnek.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#32500
Abu85
HÁZIGAZDA
->Raizen<-
#32499
Abu85
HÁZIGAZDA
válasz
->Raizen<-
#32499
üzenetére
A meltdown OS szinten javítható és tegnap jött is Windows frissítés rá. Erre az Intel prociknak szüksége van.
A spectre bonyolultabb. Egyrészt OS szinten lesz rá reakció, de ahhoz, hogy ezek hatásosak is legyenek, szükség van a BIOS frissítésére is. Itt az első támadási variációt elég OS-ben foltozni, de a második variációnál az egyes platformok igényelhetik az újabb firmware-t. Én még abban sem vagyok biztos, hogy a spectrét ennyivel megússzuk. Szerintem ez fejlődni fog, és újabb foltozások kellenek majd a jobban kidolgozott támadási variációkra.[ 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
Valdez
#32503
üzenetére
AMD-re a meltdown elleni patch azért kell, mert ha nincs fent, akkor nem frissíthető tovább az OS. Ez egy biztonsági protokoll, hogy az MS és az Intel biztos legyen abban, hogy mindenki befrissíti. Ettől függetlenül, amelyik procinak nem kell, azon nincs használva az új struktúra. A spectre ellen pedig szükséges az AMD-nek is védekeznie az első támadási variáns ellen.
(#32504) solfilo: Hardverfüggő, hogy mikor lesz frissítve. Előbb-utóbb ott lesz minden gépen maga a patch. Mondjuk úgy két héten belül. Hogy aktív lesz-e minden eleme az attól függ, hogy érintett-e a hardver, vagy megtalálható-e a kompatibilis firmware.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Arra egyébként érdemes figyelni, hogy a spectre elleni harc közel sem ért véget. A második támadási variáció nagyon veszélyes és nagyon elméletben a branch target injectionnek az AMD-re is hatásosnak kellene lennie. Ugyanakkor a gyakorlat mást mutat, amit azzal magyaráznak most, hogy az aktuális implementáció nem elég gyors ahhoz, hogy az AMD procikba épített védelmeket kijátssza. De ha érkezik egy újabb implementáció, ami gyorsabb, akkor lehet, hogy az ellen már az AMD is kénytelen lesz firmware-rel védekezni. A kérdés, hogy mennyire hatékony a hardverbe épített védelem, mennyire optimalizált implementáció kell a kijátszásához. Ezekre még nincs válasz. Tehát az, hogy az AMD immunis a branch target injection ellen, bőven lehet, hogy csak egy ideiglenes állapot. És akkor még a jó ég tudja, hogy milyen támadási variánsokat lehet bevetni a spectre-re, amit megint foltozni kell OS-firmware szinten
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#32575
Abu85
HÁZIGAZDA
Petykemano
#32574
Abu85
HÁZIGAZDA
válasz
Petykemano
#32574
üzenetére
1) Igazából Vega olyan szinten grafikai fókuszú, hogy az már fáj. Nem igazán lehet compute-nak nevezni valamit, ahol komplett, kompatibilitást megvágó shader lépcsőt, és ezen belül nyilván a szükséges hardverállapotokat vezetnek be egy olyan problémára, amire 2006 óta egy csomó megoldás készült, de egyik sem tetszett a fejlesztőknek. Ami persze marha nagy pech, hiszen már rég nem csak irányként beszélnénk a GPU-driver pipeline-ról, ha a Microsoft és a Khronos nem ragaszkodna makacsul a teljes pipeline kompatibilitáshoz.
2) A Vega 20 elég sokban fog különbözni. Az, hogy natív lesz a DP egy dolog, illetve a duplázott sávszél is az, viszont PCI Express 4.0 lesz, ami egy nagyon fontos lépés. Iszonyatosan korlátozó a 3.0 is manapság. Na meg ebben lesznek GMI-k is, ami az AMD saját memóriakoherens interfésze. Utóbbi hatalmas különbség, hiszen összerakhatnak olyan x86/AMD64-es szerverplatformot, ahol a PCI Express korlátjai nem jelentenek többé problémá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
lezso6
#32577
üzenetére
Ezek a szerverekben hasznosak. Ott már nagyon kevés a PCI Express 3.0. Még a 4.0 is az lesz, nem véletlen, hogy ott lesz még a GMI is, ami még a PCI Exressnél is több/jobb/gyorsabb.
A játékosok nyilván nem lényegesek. Ott eleve nagyon limitált maga a munkafolyamat, már a program tervezése szintjén nagyon round trip van bekalkulálva. Emellett a játékoknál lehet játszani az aszinkron compute-tal. Nem baj, ha egy frame-et késik a szimuláció, ez csak játék.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#32583
Abu85
HÁZIGAZDA
Petykemano
#32581
Abu85
HÁZIGAZDA
válasz
Petykemano
#32581
üzenetére
1) De nagyon HEDT grafikai fókuszú. Nem sorolhatod máshova, ha más hardver még be sem tudja tölteni a Vega 10 által kezelt részletesség egyszázadát sem. Egyszerűen out-of-memory információval kilépnek.
2) Nem akarok jósolni, de nem nagyon hiszem, hogy Vega 20-as Radeon Instinctet fognak a játékosok vásárolni. Egy kártya 10000 dollár lesz.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#32585
Abu85
HÁZIGAZDA
Petykemano
#32584
Abu85
HÁZIGAZDA
válasz
Petykemano
#32584
üzenetére
1) A Vegának nem is a Pascal ellen kell teljesítenie, hanem a Volta ellen. Ezért lett lényegesen okosabbra tervezve az előző generációs architektúráknál. Amikor még Vegát és Voltát tudsz venni az üzletekben, akkor a Pascal már rég nem lesz elérhető. Ennek a fejlesztésénél nem számítottak olyan kérdések, mint például az occupancy limit kitolása, ami a Vega és a Volta egyik fő fejlesztése. Amikor ezek még tudnak konkurens lane-t indítani a multiprocesszoron, akkor a Pascal már rég azt mondja, hogy nincs több LDS/regiszter/L1. Ez ugyanez igaz lesz a Polarisra is.
2) Éppenséggel lehet, de az nem Radeon Instinct néven jön.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
solfilo
#32586
üzenetére
Egyszerű. Végy egy shadert, ami Vegán 60 kB LDS-t használ, és ezzel 10 wave-et futtat. Ugyanez a shader Polarison 5 wave-et tud futtatni. Hiába ugyanaz a CU-kban az ALU-k száma a Vega legalább háromszor gyorsabban futtatja ugyanazt a kódot. Ez hasonlóan igaz a Pascal-Volta vonatkozásában az új L1 struktúra miatt. Több warpot tud futtatni ugyanazzal a shaderrel a Volta. Amennyire PBR-ezünk a shadereknél nagyon el lehet majd szállni, ha végre nem a Polaris és a Pascal lesz célozandó a felső limit, hanem a Vega és a Volta. A Polaris/Pascal tulajok majd kiválasztják a medium grafikát.
És az olyan kis finom részletekről még nem is volt szó, mint a wave-limit, ami szintén egy érdekes optimalizálási lehetőség a Vega/Volta vonalra. Ezzel lehet a cache-hitre optimalizálni.
Az ALU-k száma mindig csalóka volt. Lehet, hogy ott nem látszik a Vega és a Volta előnye, de multiprocesszor struktúrájában komoly előrelépés mindkettő.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
-
#32594
Abu85
HÁZIGAZDA
Petykemano
#32591
Abu85
HÁZIGAZDA
válasz
Petykemano
#32591
üzenetére
Ezt ne így képzeljétek el. Megpróbálom leegyszerűsítve elmagyarázni. Most vegyünk egy tök teoretikus dizájnt, ami teszem azt 10 konkurens wave-et futtat maximum. A számok ilyen hasraütésszerüek, csak a lényeget próbálom velük átadni. Ennek a dizájnnak van mondjuk 80 blokk regisztere és 20 blokk helyi adatmegosztása. Ezen a multiprocesszoron futtatsz egy shadert, a mai igencsak pazarló dispatch alapján, aminél a statikus allokáció lefoglal 72 blokk regisztert és 18 blokk helyi adatmegosztást. Ilyen formában 8 wave futhat egymás mellett a multiprocesszoron (feltételezve, hogy egy wave 9 és 2 blokk/wave, ami egy tipikus helyzet lenne a mai programokat nézve), ami még belefér a jó hatékonyságba. De lehet komplexebb shadereket is írni, ami egyre inkább nem lehetőséggé, hanem követelménnyé válik, ahol például elég nagy probléma lesz a helyi adatmegosztás 20 blokknyi mérete. Mondjuk két-három dispatches übershader már fájhat is komolyabb anyagmodellek mellett, és előfordulhat, hogy az LDS-nél már jóval többet igényel a shader wave-enként, mint 2 blokk, akár 7 blokkot is, és ez nem extrém helyzet, hanem egyre inkább a realitás. Ilyenkor a mi kis teoretikus multiprocesszorunk alaposan bajban van, mert LDS szintjén 7 blokk/wave mellett tud 2 wave-et futtatni a 10-ből. Ezzel a hatékonysága alaposan megzuhan, mert ha az egyik wave adatra vár, akkor betölti a másikat, ami szintén adatra fog várni egy idő után, viszont nincs egy harmadik wave, amit betölthetne dolgozni, ergo az egész multiprocesszor csak áll. Ez most a probléma. A Vega lényegében úgy védekezik ellene, mintha a mi kis teoretikus multiprocesszorunknál megnöveltük volna a 20 blokknyi helyi adatmegosztást 40-re. Így már 5 wave is futhat az adott shaderrel, amivel jóval kisebb lesz a feldolgozás során az üresjárat, mert nagyságrendekkel megnő az esélye annak, hogy lesz futtatható wave, ha a többi adatra vár. Persze trükközhetnénk még olyannal, mint az utasítás-előbetöltés, de az a baj, hogy ennek a hatékonysága egy statikus allokációkra épülő hardvernél nem valami jó. Segít, de nem annyit, hogy nagymértékben lehessen rá építeni.
A Volta is hasonló irányba lépdel azzal, hogy közös az L1 és az LDS (helyi adatmegosztás). Ez ugyan nem annyira brute force megközelítés, mint a Vegáé, de a lényeg itt is az, hogy egy nagyobb fokú konfigurálhatóság lehetőségével a futtatható wave-ek száma ideális legyen a legtöbb shadernél.
Aztán persze a kihasználtság növelésére számos szoftveres trükk is van, ez érkezhet a program oldaláról, vagy akár a shader fordító is beállítható úgy, hogy kifejezetten a kihasználtságra fordítson, de utóbbival az szokott lenni a baj, hogy ezzel a cache-hit nem lesz túl kedvező, tehát vesztesz is vele. A legtöbb cég ezért inkább egyfajta köztes konfigurációban fordít, ahol lesz is elég wave, és a cache-hit sem lesz a padlón. Ugyanakkor a shaderek egyre bonyolultabbak, így hiába a Polaris és a Pascal dizájnja nem túl ideális a következő körre, ezért is váltott a Vega és a Volta. Ezekkel a hardverekkel kevésbé kell azon filóznia az AMD-nek és az NV-nek, hogy melyik kezét vágja le (a cache-hitet vagy a sok wave-et).
Aztán persze a Vega és a Volta is inkább egy áthidaló megoldás. Nyernek velük úgy két-három évet, de idővel úgyis elő kell venni a hardveresen erőforrás-allokáció kérdését. A mostani, egyelőre még next-genként hirdetett fejlesztések már mindenképpen dinamikusra cserélhetik a statikus modellt. Ezzel a fenti probléma végleg megszűnik, a hardver önmagától képes dönteni az ideális futtatásról.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#32603
Abu85
HÁZIGAZDA
huskydog17
#32597
Abu85
HÁZIGAZDA
válasz
huskydog17
#32597
üzenetére
Az Unreal Engine 4-nek rengeteg változata van. A PUBG egy 2016-ost használ, ezért is van tonnányi technikai problémája, ami miatt már csak vegyesre értékelik a játékosok a Steamen, mert hiába mondják rá, hogy ki van adva, ugyanúgy fagy és akad a netkód, mint a korai kiadásban. Viszont a modernebb Unreal Engine-t nehéz bepatchelni egy ilyen játéknál. Sok pénzt és időt igényel, és a PUBG Corporation nincs eleresztve. Nekik még szerverbővítéseken is gondolkodniuk kell a Meltdown para miatt. Hiába tervezték meg a megjelenésre a terhelést, a Meltdown patch befrissítésével még legalább 30%-nyi extra erőforrás kell, ami rengeteg pénzbe fog kerülni. Ugyanígy járt az Epic is: [link] - itt látszik, hogy mikor kúszott fel a Meltdown patch. Ez eléggé átszabja majd az idei évet, mert sokkal fontosabb lesz a patch hatását új szerverekkel ellensúlyozni, mint magára a fejlesztésre költeni a pénzt.
Unreal Engine 4 a 4.17 óta van úgy fordítva, hogy az AMD-re is optimalizált az Epic. A 4.18 is ilyen köztes motor lesz, azzal a különbséggel, hogy az új default debugger már a RenderDoc. A profilozó szempontjából még az Xbox One PIX marad a default, de a 4.19-nél már váltanak Radeon GPU Profilerre. Ez azzal az előnnyel jár az Epicnek, hogy nem kell a PC-s motor fejlesztéséhez Xbox One-t használni. Hátrányt is hoz viszont, ugyanis amint dobják a PIX-et, onnantól minden fejlesztői gépbe Radeont kell használni, viszont nem kell mindenhova Xbox One, ami megint előny. De a hardverváltás időbe telik, ezért csinálják szakaszosan.
Szóval az Unreal Engine-nek valójában nincs hardverpreferenciája. Az egyes verzióknak van. A régebbi verzióknál még NVIDIA Nsight-ot használtak, viszont az a 4.17-ben eldobták. Ez amúgy egy tipikusan rossz átállás az Epic számára, mert gyakorlatilag átszenvednek egy köztes időszakot, amíg eljutnak a RenderDoc+Radeon GPU Profilerhez. De persze a motort programozó Rolando Caloca magyarázata is igaz, hogy megéri váltani, mert így a PC-s profilozás is hardveres nyomkövetővel történik. Korábban csak teljesítményszámlálót használtak erre a célra, tehát az új fícsőrök teszteléséhez kellett egy konzol. Gondolom a VR és a Vulkan miatt fontossá vált a nagyobb rálátás, az nyilván nonszensz hosszabb távon, hogy a PC-re is az Xboxos PIX alapján dolgozzanak.[ 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.
Állásajánlatok
Cég: Ozeki Kft
Város: Debrecen
Cég: Ozeki Kft
Város: Debrecen