Új hozzászólás Aktív témák
-
#32895
Abu85
HÁZIGAZDA
Petykemano
#32894
Abu85
HÁZIGAZDA
válasz
Petykemano
#32894
üzenetére
Alapvetően erről van szó. De ez normális. Ha egy probléma megoldására van egy dedikált utasításod, akkor az mindig nagyságrendekkel gyorsabb lehet, mintha magára a problémára a megoldást le kellene programoznod általánosan. Az nem csak sokkal több utasítás, de esetleg jelentős terhelés a memóriaműveleteknél is. Ezért hozta a Microsoft PC-re a Wave programozást, mert hatalmas extrákat lehet ezzel nyerni. Ezek ugyan kis shaderek, tehát csak a frame töredékén futnak, de sok ilyen optimalizálást lehet alkalmazni, és ez a teljes frame-re vonatkozóan akár 10-30% is nyerhető. Sőt, akár több is.
A GameWorksnek semmi köze ehhez. Ez csak egy effektgyűjtemény. Ha te mondjuk konzolon préselést használsz direkt intrinsics függvénnyel, akkor semmi sincs az NV-nél, amivel ezt te ki tudod váltani. De még az AMD-nél és az Intelnél sem. Neked kell megírni egy működő algoritmust alternatívának. Azért nem érted szerintem, mert folyamatosan kevered a szezont a fazonnal. Behozol olyan middleware-eket, amelyeknek megközelítőleg sincs semmi közük az alapproblémához.
-
#32892
Abu85
HÁZIGAZDA
Petykemano
#32891
Abu85
HÁZIGAZDA
válasz
Petykemano
#32891
üzenetére
Azért jó, mert nem véletlenül hívják ezeket gyors kódoknak. Ugyanis beépített függvényeket használnak, amiket a GPU kevés vagy akár egy utasítással is végre tud hajtani. Nem mindegy, hogy egy algoritmusra speciális op-kód van, vagy egy rakás atomi művelettel kell megoldani. Utóbbit hiába optimalizálod, már az alternatív megközelítés sokszázszor vagy sokezerszer lassabb. Ezért hozta be a Microsoft a shader modell 6-ban a wave intrinsicset, mert nem tudsz pár hét alatt ezerszeresére gyorsítani egy eljárást, nincs hol nyerni ennyit. Maximum 10%-ot hozol, és akkor már csak például ~9990x lassabb a speciális op-kód nélküli shader.
Nem tudom, hogy milyen debuggerről beszélsz. Van elég sok. Szerintem te a profilozóra gondolsz. A Radeon GPU Profiler alapvetően nem elengedhetetlenül szükséges a PC-s játékok fejlesztéséhez, csak annyit lehet nyerni vele, hogy nem kell konzolon profilozni a PC-s kódot. Ami egyébként elég sok előny, hiszen egy PC-s portolással foglalkozó stúdiók számára időpocsékolás, hogy a PC-s portot át kell vinni egy olyan platformra, amin van hardveres nyomkövető. Ez azért elég sok munka, ahhoz képest, hogy a Radeon GPU Profilert négy kattintással aktiválni lehet. Nem véletlenül cserélte le a fejlesztői hardverparkját Radeonra az Epic. Egyszerűen rengeteg időt takarítanak meg ezzel a módszerrel, ami a Vulkan API-ra való átállás szempontjából nagyon fontos. -
#32890
Abu85
HÁZIGAZDA
Petykemano
#32889
Abu85
HÁZIGAZDA
válasz
Petykemano
#32889
üzenetére
Mert minden gyártó számára hátrányos, hogy a PC-s shader nyelvekben és IR-ekben nincsenek olyan beépített függvények, amelyek konzolokon. Az AMD viszont fogta magát és megcsinálta ezeket magának. Ezáltal egy eljárást szimplán lehet portolni, nem kell bizonyos problémákra más, esetenként lassabb megoldásokat keresni, csak használni kell a függvény PC-s megfelelőjét, aminek ráadásul sok esetben a neve is megegyezik a PSSL függvény nevével. Ennek viszont az a hátránya, hogy csak az AMD-re olcsóbb a portolás. Intelre és NV-re ugyanúgy meg kell csinálni a munkás részt.
A jövőben ez olyan lesz a Microsoft modelljével, hogy fogják az Xbox One-ról a HLSL shadert, és lefordítják ugyanazt PC-n DXIL-re vagy SPIR-V-re. Egyszerűen ezzel a problémával nem kell többet foglalkozni a shader modell 6-nak hála. Ebben az a biznisz, hogy az egész munka csupán egy fordítás, és a kapott sebesség jobb, mint amit ma tudnak biztosítani, esetenként sokáig tartó portolással. Ergo rengeteg pénzt meg lehet spórolni a shaderek platformszintű egységesítésével. -
Abu85
HÁZIGAZDA
válasz
imi123
#32879
üzenetére
Mint írtam az előz évben is sokan áthozták (id tech, Frostbite team, Eidos Labs, Rebellion). Az oka ennek az, hogy olcsóbb. Bármennyire is meglepő, olcsóbb szimplán lefordítani a meglévő PSSL kódot AMD-re, mint a PC-s IR-ekben nem támogatható intrinsics függvényekre külön alternatívát keresni az AMD-re is. Elég az, ha az Intelre és az NV-re kidolgozzák az alternatívákat. De a shader model 6 mellett erre sem lesz szükség.
Ez igazából a spórolásról szól. Akkor hatékony a PC-s portolás, ha a lehető legköltséghatékonyabb módon hozod át a konzolos kódot, miközben megpróbálod a legjobban megőrizni a sebességét. A legtöbb shader teljesítménye ugyanis nem jól portolható a PC-s szabványos IR-ekre, tehát a sebesség megőrzéséhez más eljárásokat kell keresni ugyanarra a problémára. Ez pedig költséges. Sokkal költségesebb annál, mint fogni a kész kódot a konzolról és módosítás nélkül lefordítani egy ehhez írt fordítóval. -
Abu85
HÁZIGAZDA
válasz
imi123
#32876
üzenetére
Pont nem kaptak nagy támogatást. Ennek a modellnek az a lényege, hogy a PS4-re vannak jól optimalizált PSSL shaderek, amelyeket lefordítanak nem szabványos IR-re PC-n. Ezáltal a szabványos IR-nél nem kell foglalkozni az AMD hardvereivel, így az Intel és az NV megoldásainak megfelelő alternatív eljárások választhatók, viszont korlátozó marad a shader modell. Ezt alapvetően az id software mellett alkalmazza a Frostbite team, az Eidos Labs részlege, pár indie (pl.: Rebellion), és most már az Ubisoft is.
Hosszabb távon a shader modell 6.x lesz a sztenderd. Az nagyjából képes ugyanarra, amire az AMD kiterjesztései, és támogatható vele az Xbox One is. Ergo végeredményben szabványos DXIL vagy SPIR-V IR-re hozod át a konzolról a sebességet, amit így megkap az Intel és az NV is. -
#32875
Abu85
HÁZIGAZDA
->Raizen<-
#32874
Abu85
HÁZIGAZDA
válasz
->Raizen<-
#32874
üzenetére
A GPUOpen a nyílt forráskódot jelenti. De ne érjen senkit meglepetésként, hogy a Far Cry 5 esetében az id tech játékokhoz hasonlóan kétféle shader IR path lesz szállítva. Egy speciális gyors kód az AMD-nek és egy szabványos kód az Intel/NV-nek.
-
Abu85
HÁZIGAZDA
válasz
TTomax
#32860
üzenetére
Valami durva erőforrás-kezelési gond van. Nem igazán értem, hogy mit csinál, de furcsán sokszor van cache-flush, még úgy is, hogy előtte közvetlenül volt egy, tehát egy másodiknak/harmadiknak/sokadiknak aztán semmi értelme, de ott van.
Ezek nagyon nagy akadásokat nem okozhatnak. Csak hülyeséget csinál a rendszer. -
Abu85
HÁZIGAZDA
Távol álljon tőlem, hogy ezt védjem, de alapvetően borzasztóan nehéz zárt middleware-eken keresztül effekteket építeni egy játékba úgy, hogy azok az effektek probléma nélkül is fussanak és még gyorsak is legyenek. Jellemzően csak a problémamentesség sikerül, vagy az sem. Ezért hülyeség már a GameWorks koncepciója is, hiszen nyílt formában ugyanaz sokkal gyorsabb lehetne.
Az pedig, hogy a kamera megjelenít valamit, nem biztos, hogy valóban ki is lesz számolva a benchmarknál. Persze itt az Ansel bezavarhat, ez nem véletlenül egy kritikus tényező a játékoknál. Ennek az integrálását ugyanis kegyetlenül el lehet rontani (és hajlok afelé, hogy az FFXV esetében kötöttek kompromisszumokat a működés érdekében), és ha az adott motor nincs igazán felkészítve erre, akkor rengeteg olyan kényszerű döntést igényel, amely még az Ansel nélküli futtatás sebességét is radikálisan csökkenti. És itt visszatérünk oda, hogy nem volt idő vagy szimplán humánerőforrás normális portot tervezni. Mert ezek a problémák kezelhetők, csak programozókat kell ráállítani, amely programozók persze a Square Enixen belül már az EIDOS Labs részlegén dolgoznak. Egy csak konzolokon jártas csoport nem feltétlenül tud jó minőségű PC-s portot kreálni. Ez pedig nem feltétlenül az NV hibája, hiszen a Square Enix hülyeséget csinál azzal, hogy a PC-ben valamennyire is jártas szakembereket elviszi nyugatra, de a keleti játékok portolását már nem adja oda nekik. Az NV-nek maximum annyi esze lehetett volna, hogy nem csak middleware-eket ad, hanem szakembereket is, de a GameWorks modellben beálltak arra, hogy a szakemberek már nem kellenek, mert könnyen integrálható formában szállítják az effekteket. Az a kommunikáció megy félre a médiában, hogy ettől mindenki jól optimalizált, gyors portokat várt, holott már magába a koncepcióba van kódolva a rossz sebesség.
Persze rácsodálkozunk megint, hogy jött egy GameWorks cím, és az effektek bekapcsolása után egyáltalán nem olyan, amilyenre számítottak a PC-s játékosok. Persze értem én, a remény hal meg utoljára, de alapvetően maga a zárt kód lehetetleníti el az egész rendszert attól, hogy gyorsan fusson. Nem véletlen, hogy amíg a Far Cry 4 tele volt GameWorksszel, addig a Far Cry Primal csak azért csúszott egy hetet PC-n, hogy lejárjon a szerződés, így ne kelljen GameWorksöt rakni bele. A Far Cry 5 pedig már ott tart, hogy GPUOpennel készül. Persze oké, az Ubisoft más kategória, azért nekik még mindig elég nagy a tapasztalatuk a PC-ben, míg mondjuk az Square Enix keleti stúdiói kizárólag konzol fókuszúak. Ők egyszerűen nem feltétlenül képesek többre önmaguktól.
-
Abu85
HÁZIGAZDA
válasz
nonsen5e
#32846
üzenetére
Dehogy. Igazából a multiplatform játékok sosem céloznak egy platformot sem direkten, annak ellenére sem, hogy jellemzően előjönnek a fejlesztők és azt mondják, hogy x vagy y platformra építették az egészet. De ez hülyeség. Azért multiplatform, mert több célzott gépre vonatkozó döntéseket hoztak.
A Gameworks csak middleware. Biztos módosítani kell pár dolgot, hogy működjön, és látszólag módosítottak is, elvégre a motor régebben rendkívül barátian bánt még a Quad SLI-vel is, míg mára az AFR-t le van tiltva. Itt nyilván valamelyik kívülről kapott eljárás kavar be, amit a forráskód ismerete nélkül nem tudnak módosítani, így bukja a motor az egyes képességeit. De ez aligha lehetett ismeretlen tényező, mindenki tisztában van vele, hogy a zárt middleware-ek sebességáldozattal járnak. Sokszor egész komollyal. Az viszont semmiképpen sem a Gameworks hibája, hogy rengeteg időt van a képkockaszámítás erőforrás-korlátozás mögött. Ez valószínűleg amiatt van, mert bizonyos konzolra írt optimalizálásokat nem hoztak át valamiért, és a helyükre alternatívákat írtak, de azokban az alternatívákban jóval kevesebb munka volt (sürgető idő, kevés humánerőforrás, stb.), így sokkal rosszabb hatásfokkal működnek. -
Abu85
HÁZIGAZDA
És most pont a fusson jól nem valósul meg.
Ennél sokkal jobban futhatna, ha optimalizálva lenne. 
Ráadásul ennek speciel a GameWorks-höz sincs sok köze. Standard grafikával sem javultak az arányok. Elképesztően igénytelen egy-egy fejlesztőstúdió, bár tudom én voltam a bolond, hogy elhittem a Square Enix ígéreteit. -
Abu85
HÁZIGAZDA
Azt hiszed, hogy csak AMD-re nincs optimalizálva? Egy képkocka a számítási idő 19%-át tölti erőforrás-korlátozás mögött. Csak, hogy képben légy, általános javaslat az iparágon belül, hogy ez az érték ne legyen nagyobb 3-4%-nál, különben valami rosszul működik a rendszerben. Persze ezt egy átlag vérpisti nem fogja kimérni, éli a saját álomvilágát.
-
Abu85
HÁZIGAZDA
válasz
imi123
#32789
üzenetére
Maximum akkor, ha ugyanazt az API-t használja. De az FF15 PC-n DX11-et használ, PS4-en GNM, míg Xbox One-on a D3D12Mono API-t. Gondolom a PC-re is portolható lett volna egy DX12-es mód, elvégre a mag a motor már futott DX12-ben pár éve, viszont gondot jelent, hogy egy csomó felhasznált NV middleware-nek nincs stabil D3D12-es portja. És mivel a forráskód is titok, ezért nem is tudják megoldani, és akkor az lenne, mint a Rise of the Tomb Raidernél, hogy a DX12-ben kevesebb effekt kapcsolható be. Gondolom a szervizkönyvtárakkal kizárt AFR is csak egy mellékhatás, elvégre az SLI már működött ezzel a motorral korábban.
Igazából nem az a gond, hogy ilyen lett, hanem az, hogy nem ez volt ígérve.
Abban pedig nem vagyok biztos, hogy az NV fizet azért, hogy az SLI ne működjön. Ez egy olyan kellemetlenség, amit be kell nyelniük a GameWorks modellel, lévén bizonyos kódokat a fejlesztők nem láthatnak, így nem tudnak rájuk reagálni. Lehet, hogy a motor tökéletesen kompatibilis az AFR-rel, de rengeteg kódot hoz be maga a middleware, ami viszont számukra egy feketedoboz, és megtörhet egy rakás korábban működő dolgot. -
Abu85
HÁZIGAZDA
válasz
nonsen5e
#32787
üzenetére
Teljesen érthetetlen, hogy a Square Enix miért nem használja az EIDOS Labs csoportját. Annyi technikailag képzett embert áthelyeztek oda az elmúlt években, igazán segíthetnének a keleti fejlesztőstúdióknak is. De a Nixxes is simán bevethető, ők is közel vannak a Labshoz. Erre olyanok portolnak, akik elsődlegesen konzolra dolgoztak mindig is. Ki gondolta, hogy ebből ez lesz.
(#32785) Habugi: Igen csak az előző részeknél nem ment a marketing, hogy faszántos lesz a PC port. Mindenki tudta, hogy olyan szar lesz, mint az előző, így nem kellett végül csalódni.
-
-
Abu85
HÁZIGAZDA
válasz
nonsen5e
#32775
üzenetére
Az AFR-nek fáj a GameWorks. Az új DRM nem kompatibilis a driverből kényszerített több GPU-val. Ennek megint nagyon fognak örülni a hardcore PC-sek. Pedig maga a motor támogatja, elvégre korábban négy GPU-n futott még az eredeti demó.
-
Abu85
HÁZIGAZDA
Itt eleve ott hibázol, hogy százalékban mérsz és nem ms-ban. A fejlesztők utóbbit használják, vagyis egy adott feladat hány ms a CPU-n és hány ms a GPU-n. Amelyik kisebb az a jobb. Ez azért fontos, mert a százalékos érték nagyon becsapós, ugyanis nem azt méri, hogy mennyire volt terhelve a proci, hanem azt, hogy meddig nem futtatta az idle folyamatot. Ettől még könnyen lehet, hogy az adott program terhelése abból a 88%-ból csak 20-30% volt, és akkor rögtön teljesen hibás feltételezésből indulsz ki, hogy a prociban már nincs több, holott ha performance counterrel néznéd, akkor látnád, hogy mennyi szabad erőforrás van még. Az persze az API-któl függ, hogy kihasználható-e vagy sem.
-
Abu85
HÁZIGAZDA
A Battlefront 2 a PC-n is 40 játékost enged. Az oka ennek a balance. A motor tudna 80-at is kezelni, de a tervezett pályák nem feltétlenül jók ennyi játékosnak. Azt meg ne hidd, hogy itt a játékosok felé egyenként szinkronizálnak minden multiplayer elemet. Ha így tennének, akkor rég nem működne a játék semmin.
A konzolon nem a 60 fps a cél. Bőven el tudnák érni, mert csak paraméterezés kérdése, de az a helyzet, hogy a játékosbázis sokkal inkább szereti a grafikát, mint a 60 fps-t. Ezért optimalizálnak 30 fps-re, mert úgy jobb grafikát tudnak biztosítani.
Nehogy azt hidd, hogy a következő kör más lesz. Itt vannak a konzolok lassan öt éve, és végre minden stúdió olyan motort írt, ami rengeteg CPU-s számítást átrakott a GPU-ra. Még az Ubisoft is a Far Cry 5 új Dunia motorjával, aminél a LOD-olást, a cullingot, a stitchinget, vagy a height field terrain leképezését már nem a CPU csinálja, hanem a GPU. És nem csak részben, hanem 100%-ban GPU compute a kód, zéró a kifejtett terhelése a CPU-ra. Innen nem fognak visszafordulni, hogy akkor inkább legyen a CPU erős, és ne a GPU, mert akkor megint lesz egy öt éves ciklus, amikor mindent vissza kell írni a CPU-ra. Ez ráadásul értelmetlen, mert sokkal rosszabb hatásfokú egy processzormag egy multiprocesszornál.
-
Abu85
HÁZIGAZDA
válasz
Televan74
#32712
üzenetére
A konzolokba speciális GCN kell. A Vegából már egy rakás korábbi utasítást kivágtak. Most képzeld el mi történne azzal a programmal, amelynek a szállított binárisa arra épít. Egyébként még nincs szó a következő körről. Nagyon messze vannak attól a fejlesztők, hogy a mostani gépeket kihasználják. A Naughty Dog persze egész jól áll: [link] - de ez még mindig nem a vége.
-
Abu85
HÁZIGAZDA
Nem érted, hogy miért választották azt a CPU-t konzolba. A lényeg az volt, hogy legyen egy kis fogyasztású komponens, ugyanis a CPU rengeteg feladatra rossz hatásfokú részegység. Túl általános ahhoz, hogy jó GFLOPS/watt mutatót mutasson fel. Emiatt került a választás a Jaguar magokra, mert kellően gyorsak ahhoz képest, hogy mennyire keveset fogyasztanak, és még a lapkaterület szintjén is nagyon kevés helyet igényelnek. Azzal, hogy itt spóroltak, több multiprocesszort tudtak beépíteni. Ezt a témát jól körbejárta az Ubisoft még a megjelenéskor, amikor megmutatták, hogy a régi ruhafizikájuk az új konzolokon lassabb, mint az előző generációs gépeken. De átrakták a kódot a multiprocesszorokra, és tízszer gyorsabb lett. Ugyanarra alkalmas a GCN CU is, mint a Jaguar CPU, csak nagyságrendekkel, tényleg úgy bő 20x hatékonyabban működik. Ha ezt a teljesítményt az aktuális konzolok CPU-ból hoznák, akkor a fogyasztásuk nem 200 watt alatt lenne, hanem 600 watt felett. Szóval nem pont az ár kötötte a kezüket, a problémát a fizika törvényei jelentették. Egészen pontosan az, hogy még mindig nem jöttük rá arra, hogy egy bizonyos, relatíve alacsony elektronszámot miképp lehet statisztikailag olyan nagy tömegként kezelni, hogy ne a kvantummechanika törvényei vonatkozzanak rájuk.
-
Abu85
HÁZIGAZDA
válasz
mormota79
#32693
üzenetére
Lehet, csak nem érdemes addig, amíg ez egy bevezetés előtt álló irány. Az Egyesült Királyságban ezt csak pár egészségügyi szervezet teszteli. Persze kapnak rá kormányzati támogatást, de a rendszer nem éles. Amint persze egy ország bejelenti, hogy átrakja blokkláncra az egészségügyi rendszerét, jönni fognak a dedikált gyorsítók rá. De itt azért számít a szoftver, amivel a gyártók le tudják láncolni a kormányokat. Olyan dolog ez, mint a gépi tanulás. Ma ezt főleg GPU-val csinálják, pedig vannak erre sokkal jobb hardverek is. Ahogy látod, maga a gépi tanulás kezd beindulni, és jött is az Intel Knights Crest, ami azért jól beledöngöli a betonba az összes GPU-t, majd hátranéz és megnézi, hogy élnek-e még. Nyilván a blokkláncnál is így lesz, amint erőre kap a piac, jönnek GPU-t kiváltó, sokkal hatékonyabb hardverek.
-
Abu85
HÁZIGAZDA
Egyik cég sem támogatja a bányászatot. A blokklánc technológiákat támogatják, mert a helyzet az, hogy ez nem csak bányászatra való. Egy évtizeden belül szinte az összes tehetősebb kormány átrakhatja blokkláncra az egészségügyi rendszerét. Ez gyakorlatilag azzal fog járni, hogy a professzionális VGA-piac legnagyobb felvásárlói az kormányok lesznek. Tonnaszámra fogják rendelni az 1000-3000 dolláros GPU-kat ehhez. Viszont nagyon fontos, hogy ki az aki ebben jobb támogatást tud adni, mert az viszi majd nagyrészt a piacot. Amikor valaki a driverben blokkláncra optimalizál, akkor nem a bányászok miatt teszik, hanem például az egészségügyi átalakításra lőnek. Írtam a hírben, hogy az Egyesült Királyságban ez már működik. Az AMD is erre lő, mert gondolj bele, hogy itt egy Egyesült Királyság kaliberű terület egy élesre állított rendszerben azért kétévente rendelni fog úgy százezer gyorsítót az egészségügyi blokklánchoz. Ha minden nagyobb ország átáll erre, akkor az éves szinten bő 2 milliárd dolláros piac.
-
Abu85
HÁZIGAZDA
válasz
Televan74
#32685
üzenetére
Akkor eladod és veszel konzolt. Nem tudnak vele mit kezdeni. Ha olyan egyszerű lenne a megoldás, hogy most jól letiltom, akkor már rég letiltották volna. De itt nem a bányászatról van szó, hanem a blokklánc alkalmazási területeiről. Se az AMD, se az NV nem akarja elengedni a formálódó piacokat, és ahhoz a bányászatot meg kell tűrni. Majd havonta tesznek egy nyilatkozatot, hogy megmondták a kereskedőknek, hogy a játékosoknak adják el a hardvert. Mossuk kezeink, ha nem így tesznek. Esetleg kiadnak egy általános ajánlást, hogy milyen szövegek gyanúsak: "sok kártya kell, nagy a család", "a szomszédoknak is én veszem", "multi-GPU-t akarok, mind a tíz gépembe" ...
-
Abu85
HÁZIGAZDA
válasz
Televan74
#32683
üzenetére
Nem tudják korlátozni a bányászatot. Pont ez a baj. A blokklánc támogatása kritikus fontosságú, mert az hatalmas piac lesz később, de amelyik gyártó korlátozza szoftveresen a blokklánc kódok teljesítményét, erről a piacról automatikusan kiesik. Szóval attól, hogy a bányászatra az AMD és az NV magasról tesz, a blokklánc technológiákat árgus szemekkel figyelik és optimalizálnak rájuk. Célpiac például: smart contracts, smart property, smart appliance, blockchain healthcare, blockchain music, blockchain government, blockchain identity, stb-stb-stb. Az nem megoldás a cégek számára, hogy kizárják magukat a formálódó dollármilliárdos piacokról, csak azért mert sokan bányásznak, amiből megjegyzem, hogy veszteségük nincs, sőt.
-
#32619
Abu85
HÁZIGAZDA
huskydog17
#32616
Abu85
HÁZIGAZDA
válasz
huskydog17
#32616
üzenetére
A GTA5 sem volt megosztó, mégis népszerű volt. A probléma az, hogy ez a játék nincs kész. Egyszerűen multi technikai szinten nem működik, ami elég nagy baj egy multis játéknál. Nem csodálkozok rajta, hogy sokan lehúzzák. Én is csak vasárnap reggel tudtam vele játszani egy órát, délután már dobált le a szerver.
Ha a BF4-ben nem élted át a korai multis gondokat, akkor nem tudod mihez hasonlítani a PUBG helyzetét.
Igazából a fejlesztőknek jönne jól, mert rákényszerítené őket a nyilvánvalóan hibás netkód átírására.
A sokmillió játékos is elküldi őket a fenébe, mert sokszor nem lehet játszani. Vedd meg, próbáld ki, és te is rájössz, hogy pre-béta szinten áll a játék. Amikor egyébként valamilyen isteni szerencsével összejön, hogy tudsz egy órát játszani, akkor egyébként nagyon jó, csak jó lenne, ha ezt akkor tehetném meg, amikor én akarom, nem pedig akkor, amikor a szerverek jónak látják.
A legfontosabb prioritás szerintem a netkód és a szerverek. A játék sebességével nekem nincs bajom, igaz bűn ronda, de a CS sem volt szép, mégis jól szórakoztam vele.
-
#32612
Abu85
HÁZIGAZDA
huskydog17
#32607
Abu85
HÁZIGAZDA
válasz
huskydog17
#32607
üzenetére
Egyáltalán nem természetes a vegyes értékelés. Főleg, ha játszol vele és látod, hogy milyen gondokkal küzd. Egyszerűen ez a játék kb. pre-beta szinten áll. Emlékszel még a Battlefield 4 esetében a kezdeti multis gondokra. Na kb. olyan a PUBG, csak még ezerszer rosszabb. Idővel játszható játék lesz, de optimista esetben is kb. egy év múlva. Bár a mai nap után azt mondom, hogy két év, mert az elmúlt pár órában minden meccspróbálkozásomnál ledobott a fenébe a szerver.
A PUBG fejlesztőinek a legkisebb gondjuk is nagyobb annál, hogy új UE4 verzióra álljanak át. Alig működik a játék 1.0-s verziójának a netkódja. Nagyon instabil az egész, és még szerverparájuk is lett a Meltdown patch miatt. Ha sikerült is játszanom az elmúlt héten, akkor is durván laggolt az egész.
Ha fizettem volna érte, most visszakérném a pénzem, mert ez egy fostenger. A játék maga jó, de nem megyek vele semmire, ha csütörtök óta nem tudok rajta játszani. Szerencsére promócióban kaptam kódot, így leszarom, hogy nem működik. A poén az, hogy tesóm péntek reggel tudott rajta játszani másfél órát, marha nagy pechem van, hogy pont akkor nem működik, amikor ráérek, de milyen már ez, hogy nekem kell alkalmazkodni a terhelésükhöz. Menjenek már a... -
#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. -
#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. -
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ő.
-
#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.
-
#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.
-
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.
-
#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.
-
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
-
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.
-
#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. -
#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.
-
#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.
-
#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.
-
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. -
#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.
-
#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. -
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.
-
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.
-
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.
-
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.
-
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. -
#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.
-
#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.
-
#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 -
#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. -
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.
-
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.
-
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.
-
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...
-
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. -
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. -
#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.
-
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. -
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.
-
#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. -
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.
-
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.
-
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. -
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.
-
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%.
-
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.
-
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.
-
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.
-
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.
-
#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.
-
Abu85
HÁZIGAZDA
Az Apple mindenképpen így tervezte, de az AMD valószínűleg nem gondolta azt a nyáron, hogy be kell állítani egy harmadik tokozóüzemet is, hogy majd decemberben egyáltalán ki tudják szolgálni az Apple-t. Valószínűleg úgy számoltak, hogy két partner is tud majd elég Vega 10-et gyártani. Ez lehet, hogy az iMac Pro esetében nem érezteti a hatását, mert elég nagy megrendelő ahhoz az Apple, hogy az AMD ne packázzon velük, de más területeken visszavágta a terveket, lásd az egyedi Vegák.
-
Abu85
HÁZIGAZDA
Attól, hogy fut egy 3rd party program még nem szabad hibát generálnia. Ezért ellenőrzik le. Viszont az NV és az AMD addig tud eljutni, hogy kiderítik a hiba okát. Ha van és nem náluk van, akkor például a Trixxnél van support, megy a ticket a Sapphire-nak, a Precisionnál megy a ticket az EVGA-nak. Az Afterburnernél nincs hova ticketezni. Van a Guru3D fórum, ami közösségiként működik.
Nem sok érdek van emögött. Amíg a Sapphire és az EVGA úgy gondolja, hogy megéri a programjaik mögé annyi pénzt rakni, hogy legyen hivatalos support, addig az MSI úgy gondolja, hogy nem. Nem nyernének vele annyit, hogy megérje. Igazából a Sapphire és az EVGA számára is csak a kiemelt státusz miatt éri meg. -
Abu85
HÁZIGAZDA
válasz
Raggie
#31966
üzenetére
Nekik nem ez a problémájuk. Ha ez lenne, akkor nem kínálnának gyári szinten tuningfelületet feszültségemeléssel.
A probléma az, hogy xy felhasználó használja az Afterburnert, amivel hibája van, és megírja az adott gyártó supportra, mert az Afterburner supportjára nem lehet, elvégre olyanja ennek a programnak nincs is. Innentől kezdve leesik zw hónapos szinten úgy százezer hiba erre vonatkozóan, aminek kb. az 1%-a adódik a meghajtó oldaláról, de mindet ki kell vizsgálni, elvégre a hiba beérkezésekor még nem tudni, hogy hol a gond. Vagyis az AMD-nek és az NV-nek nem azzal van a baja, hogy ez a program létezik, hanem azzal, hogy már a program létezése is havi szinten elképesztően magas tesztelési költségekbe kerül nekik a hibabejelentések kivizsgálása miatt.
A Sapphire Trixx és az EVGA Precision például azért nem annyira fájdalmas az AMD-nek és az NV-nek, mert ezekre a Sapphire és az EVGA saját supportot tart fent. Van saját hivatalos csatornája, és nem egy Unwindernek kell/lehet írni a Guru3D fórumára.
Semmi probléma nem lenne, ha az MSI felvállalná az Afterburner supportot, belerakná a szükséges pénz abba, hogy a felhasználók panaszainak legyen hivatalos helye, hivatalos formája, nem a Guru3D-n, vagy a világ egy másik eldugott fórumában... na meg legyen egy csapat, ami elvégzi a tesztelést a panaszokra. Ja, hogy úgy egy nullát hozzá kellene írni a költségekhez... az már nem tetszik, jó a Guru3D is. -
Abu85
HÁZIGAZDA
válasz
Habugi
#31963
üzenetére
Én már az egész alapproblémát nem értem. A gyártók biztosítanak egy meghajtót a hardverhez, ami megenged maga mellé bizonyos 3rd party programokat bizonyos funkciókra. Ezt a lehetőséget támogatják bizonyos API-kkal. Viszont nem vállalnak garanciát azért, hogy a 3rd party program működik, mert nem ők írták őket. De ők a hibásak, amiért xy 3rd party program nem működik. Ráadásul tuningprogram, ami eleve nem arra való, hogy stabil alapot adjon.
Én alapvetően csodálkozom azon, amikor hallom az OEM csatornákról, hogy az AMD és az NV is nagyon ki akarja végezni az Afterburnert. De a fentiek alapján már értem, hogy miért. Más hibájáért nem akarják a felelősséget vállalni. Elmagyarázni pedig nem tudják az embereknek, hogy az Afterburnerre nem vállalnak garanciát.
-
Abu85
HÁZIGAZDA
Muszáj az új API-t használniuk, mert másképp nem lehetne 2nd gen Polarist és Vegát tuningolni.
Egyébként a probléma alapvetően az, hogy az új API sokban különbözik. Már maga az alapkoncepció más. Az AMD egyszerűen felkínál lehetőségeket a programnak, hogy hívja meg a meghajtó egyes funkcióit. Ezek ugye be vannak építve a Wattmanba. Az új API ilyen formában egy olyan megoldás, amivel a gyártók fel tudnak húzni egy alternatív felületet a Wattmanra. Na most nyilván a régi API-ra írt programokat erre lehetetlen portolni, mert az jóval komplexebb volt, nem csak abból állt, hogy a driverben már kész van az alapszolgáltatás, amire kvázi elég csak egy másik UI-t húzni, illetve betáplálni a megengedett paramétereket. Aki a régi kódját akarja portolni el fog bukni, de megértem, hogy egy csomó programozó ebből a régi kódból él, mert ezért fizet nekik xy gyártó, akiknek nincs okuk többet fizetni, ha már csak egy UI-t kell felhúzni.
-
Abu85
HÁZIGAZDA
válasz
Raggie
#31957
üzenetére
A gyártók többi tuningappja. Mindegyik verzió már az új API-t használja. Elvégre a régit a második generációs Polaris, illetve Vega nem is támogatja, tehát ezek nem is lennének tuningolhatók egy külső programból az új API nélkül. A régi API-val hiába állítgatsz bármit, a meghajtó nem tudja értelmezni az adatokat.
Az egész mögött pénz húzódik. A gyártók számára az AMD új API-ja azért jó, mert egy csomó dolgot az AMD elvégez helyettük, így ők csak beletenyereltetik magukat a tutiba egy saját külső programmal. Ergo nincs többé szükségük például Unwinderre, vagy a többi ma még fizetett fejlesztőre, mert az AMD megcsinálja a munkájukat ingyen, és erre még gyártói garanciát is vállalnak. De persze csodálkozunk, hogy Unwinder nem kompatibilis egy olyan új API-val, ami hosszabb távon megszünteti a munkahelyét. Azért néha ránéz na.
-
Abu85
HÁZIGAZDA
válasz
Habugi
#31952
üzenetére
Szegény kicsi Unwinder, csak neki nem sikerült megoldania, a Sapphire az ASUS, az XFX, mindenki sikeresen átállt.
Elmorzsoltam egy könnycseppet a hatalmas erőfeszítéseiért. 
Respect neki, hogy néha ránéz, ha már a többiek támogatják. Az egészhez biztos nem volt semmi köze annak, hogy az MSI másik tuningappot fejlesztett az Afterburner mellé (amiben meglepetésre szintén megoldották a támogatást), így az After felé csúnyán elzárták a pénzcsapot.
-
Abu85
HÁZIGAZDA
válasz
Habugi
#31949
üzenetére
Egy éve az AMD kiadott egy új API-t, amin keresztül ezek működnek. Na most a régi API-ra a támogatás megszűnt. Ezáltal a 3rd party programfejlesztőknek át kellene térni az új API-ra, mert a régi API bizonyos funkciói már nem találhatók meg a meghajtóban, vagy nem jól lesznek ezek lereagálva. A 3rd party programfejlesztők pedig sírnak, hogy ezekre áttérni nekik drága, mert az rendben van, hogy az új hardvereknél ezt muszáj, de a régieknél is újra kell írni mindent, ráadásul egyre kevesebb pénzt kapnak a gyártóktól is, hogy ezeket a programokat fejlesszék, mert egyre inkább gyári szintre emeli a felkínált szolgáltatásokat az AMD, ami a gyártóknak jobb, mert nem garázspista írja, hanem egy garanciát vállaló cég. Szóval itt ütköznek a dolgok. A gyártók nem adnak már elég pénzt a garázspistáknak, akik elég pénz nélkül nem akarnak dolgozni.
-
Abu85
HÁZIGAZDA
válasz
Drizzt
#31917
üzenetére
Nem a VGA-kra. Az Intel csak reagálni akar egy eseményre. A PCI Express egyre korlátozóbb lesz és a Microsoft már dolgozik egy olyan strukturális átalakításon a Windowst érintően, ami gyakorlatilag megszünteti azt, hogy a GPU kernelek csak rendszerhívásokon keresztül legyenek futtathatók. Ergo a GPU a CPU-val közös logikai szintre kerül, és ha ezt egy gyors memóriakoherens interfésszel be tudják kötni a CPU mellé, akkor az új konfiguráció tökéletesen megfelel a Microsoft új irányának. Raja ezért ment oda, mert ő igazából már részt vett ilyen projektekben, és persze ismeri az AMD hardvereit, addig amíg az Intelnek nem lesz sajátja a CPU mellé a tokozásba. Az Intel VGA-kat nem akar, ezt nem is értékelik jövőképnek (a teljes piac 90%-a lefedhető nélkülük), de mondjuk a zárt vagy nyitott, memóriakoherens interfészen bekötött GPU a CPU-val közös tokozásban már igen kedvező jövőkép számukra. Nem beszélve, hogy tudják, hogy az AMD is erre megy, elvégre ott van nekik a GMI, az Infinity Fabric, a HBCC, mind-mind olyan technológia, ami erre való. És az Intelnek mindene megvan ahhoz, hogy ezeket lemásolják, és kövessék az irányt, csupán kellett egy szakember, aki ezt le tudja vezényelni. Nyilván első körben puhatolózással, de 4-5 év múlva úgyis lesz saját hardverük.
Azt nem tudni, hogy ebben a jövőképben a PCI Express-es VGA-knak milyen szerep jut. Simán elképzelhető, hogy az Intel és az AMD úgy dönt, hogy nincs tovább, és lelövik az egész VGA-piacot. Persze sokkal valószínűbb, hogy valami alternatív irányt dolgoznak ki, mert a VGA-k azért gyorsak, még akkor is, ha buták. Tehát például lehet olyan opciót kidolgozni, hogy a Microsoft vagy a Khronos csinál egy olyan specifikációt, amivel az árnyalást általánosan átrakják az objektumtérbe, és ekkor magát az árnyalási feladatokat a VGA-k még el tudják végezni, ráadásul ilyen modellel akár 2-3-4-5-6... VGA-t is beköthetsz, azok skálázódni fognak. A többi feladatot pedig elvégzi a CPU melletti GPU.Aztán egyébként az is lehet még, hogy az Intel, az AMD és az NV megegyezik arról, hogy a PCI Express helyett csináljanak egy új csatolót a nyílt CCIX-re építve, de ettől nagyon messze állunk, mert az NV a saját NVLinkjét erőltetné, de az Intelnek ez nem kell, sőt a Intelnek az lenne a jó, ha a PCI Express helyett nem jönne semmi, mert az fájna leginkább a VGA-knak, amit ugye ők nem is gyártanak. Az AMD érdekei is igazából az NV szívatásához fűződnek, tehát ők se biztos, hogy egy ilyen egyezményt támogatnának.
-
Abu85
HÁZIGAZDA
-
Abu85
HÁZIGAZDA
-
Abu85
HÁZIGAZDA
Leginkább az a baj, hogy nagyon sok piacra megy a Vega 10. Ott a gamer, ott a félprofesszionális, ott a szerver, ott a professzionális, ahol ráadásul van az SSG, ami ugye pont egy olyan dolog, amire a filmkészítők nagyon buknak, mert 2 TB memóriába már elég sok adat belefér, így nem kell darabjaira szabdalni a tartalmat a vizualizáláshoz. És akkor még ott az Apple, aki adná ki az iMac Prót. Ez az egész egyébként tisztán az AMD hibája. Egyszerűen elszámolták magukat az igényekkel kapcsolatban, és amikor nagyobb az igény, mint amennyire számítottak, akkor az már eleve egy hátrányos helyzet, mert lassan lehet rá reagálni. Sokkal célszerűbb lett volna a professzionális modellek kiadását csúsztatni, de persze gondolom kellett a Project 47-be is a hardver, tehát belekergették magukat ebbe az ellátási problémába. És hiába hoznak be egy harmadik partnert a tokozásra, az is jó két hónap, mire ténylegesen tudja éreztetni a nagyobb kapacitást. Jobban ki kellett volna számolni, hogy mik a piac igényei.
-
Abu85
HÁZIGAZDA
Az FE és a referencia RX verzió az ugyanaz. Két külön partner tokozza a GPU-t és a memóriát, de ugyanaz a hardver. Időközben már lett egy harmadik cég is, aki beszállt a tokozásba, de ők csak az Apple rendeléseit szolgálják ki. Utóbbi miatt lassan tényleg utoléri majd a kínálat a keresletet. A referenciák gyártását is leállítják, hogy minden lapka+memória mehessen a custom modellekre.
Most azzal a harmadik partnerrel jóval többet gyártanak a tervezetthez képest. Eredetileg úgy tervezték, hogy az Apple igényit is ki tudják majd szolgálni két tokozó partnerrel. Emiatt csúszik az iMac Pro hivatalos bejelentése, de persze az sem segít, hogy az Apple sokat kér, első batch-re mindig szokásuk nagy készletet rendelni.
-
#31877
Abu85
HÁZIGAZDA
Petykemano
#31867
Abu85
HÁZIGAZDA
válasz
Petykemano
#31867
üzenetére
Sokkal olcsóbb. Ennyi. Az Mi25-nek is megvan az előnye, ahogy a Teslának is, de például az egyedi support előnye egy csomó potenciális vásárlónak nem kell, ezért jobb nekik a Titan és a Frontier.
(#31874) Petykemano: Kiderült már, hogy a Wolf 2-ben működnek. Nem általános, hanem per game alapú jelenleg a profilozás.
Csodadriver egyébként nem létezik. Ezek nem csodák.(#31876) Szaby59: Relax, az Adrenalin meghajtóval nem fogod megnyitni a vezérlőpultot. Majd az ágyból átállítod, amit szeretnél.
-
#31856
Abu85
HÁZIGAZDA
Petykemano
#31854
Abu85
HÁZIGAZDA
válasz
Petykemano
#31854
üzenetére
Igazából a ROCm nem akarja áttörni a CUDA-t. Ennek a konstrukciónak a CUDA egy fontos eleme, amivel fel tudják használni az AMD GPU-kra az eddig megírt CUDA kódokat. Emiatt van az, hogy az AMD manapság nem arról beszél, hogy a CUDA rossz, annak mennie kell, hanem arról, hogy a CUDA az jó, használjátok a HIP-en keresztül, és tudjátok célozni az NV, illetve az AMD hardvereit. A CUDA tehát ma a stratégia része lett, amit még reklámoznak is, mert már megvan az eszköz (HIPify), amivel ezeket a kódokat lehet futtatni a saját GPU-ikon.
[link] - itt bővebben beszélnek a CUDA-HIP kapcsolatáról.
-
Abu85
HÁZIGAZDA
Pontosan.
És akkor tételesen. HIP-re van ugyanolyan gyors Tensorflow, mint a CUDA-ra. Dedukcióban egy Vega tud neked adni ~25 TFLOPS-ot, míg egy Titan Xp ~10 TFLOPS-ot. Miért is éri meg a Titan Xp-t, ha az alternatívája két és félszer gyorsabb és nincs szoftveres hátránya?
Most pedig jött a Titan V, ami már képes ~25 TFLOPS-ra, sőt igazából többre is, erről majd a hírben, tehát ez már egy nagyon is megfontolandó alternatíva.
-
Abu85
HÁZIGAZDA
Miért törném magam azon, hogy provokáljalak titeket? Szimplán önmagatoktól képesek vagytok olyan dolgokat látni a hírekbe, amelyek benne sincsenek.
Láthatod most is. Szó se volt itt arról, hogy mennyire szuper a Vega. Egyszerűen csak leírtam, hogy picit gyorsabb nála FP16-ban a Titan V, és pont azért jött, mert a korábbi Titan Xp nem tudott 25+ TFLOPS-os FP16-os tempót felmutatni. Ebből a tényből sikerül azt leszűrni, hogy mennyire szuper a Vega. Ez itt a szövegértelmezési problémát tipikus esete, amit "provokációzással" palástoltok. -
Abu85
HÁZIGAZDA
Az én lelkem nem bántja. Örülök neki, hogy van miről írni, és nektek lesz mire sivalkodni.
(#31845) ÁdiBá: Igen csak az a hardver marha drága. Van egy réteg, ami nem tudja megfizetni az annyira drága hardvert, így az NV és az AMD ide vezette be a Titan és a Frontier opciókat. Nem annyira durvák a terméktámogatásban, de elég jól működnek, és relatíve olcsók. Ez a réteg amúgy sem a Tesla vagy az Instinct verziót venné, hanem választana GeForce-ot és Radeont, ha nem lenne Titan és Frontier.
-
Abu85
HÁZIGAZDA
Nem hiszem, hogy ez géming kártya. Azt írták páran, hogy az NV azért titkolja a ROP-ok számát, mert 48 van benne. Ezért sem esett szó a géming felhasználásról, csak a gépi tanulásról. Én próbáltam rákérdezni a ROP-ok számára, de csak az volt a válasz, hogy ez nem géming hardver, így ezek száma lényegtelen. Ez igazából megkerülése volt a kérdésnek.
-
Abu85
HÁZIGAZDA
Az lesz kiemelve a hírben. Hova készült és mit tud. És ha visszaolvasol egyedül én hoztam számokat, szóval rajtam számon kérni ezek hiányát finoman fogalmazva is vicces.
(#31840) Locutus: A tényeket nem lehet tálalni. Azok tények. Az már más kérdés, hogy mit képzeltek bele, de ez nem rám tartozik.
-
Abu85
HÁZIGAZDA
válasz
Raymond
#31838
üzenetére
Sokkal többen választják. A problémát az adja az NV számára, hogy a Tensorflow HIP konverziója pöcre ugyanolyan gyors, mint a CUDA kód. Csak amíg utóbbit nem tudod futtatni olyan hardveren, ami ~10 TFLOPS-nál többre képes, addig a HIP konverzió fut 25+ TFLOPS-os hardvereken is. És mit ad isten, az NV kihozott egy 25+ TFLOPS-os hardvert. Ha ezt nem tudjátok összerakni, akkor az nem az én gondom.
Ezek nagyon nagy akadásokat nem okozhatnak. Csak hülyeséget csinál a rendszer.
Ennél sokkal jobban futhatna, ha optimalizálva lenne. 
Igazi minőségi munka lett ez a port is. 
Milyen jó dolog manapság, hogy írnak egy AFR-rel kompatibilis motort, ami régebben négy GPU-ra is skálázódott, majd elcsúszik a támogatás a middleware-eken. 
Elmorzsoltam egy könnycseppet a hatalmas erőfeszítéseiért. 
Respect neki, hogy néha ránéz, ha már a többiek támogatják. 
Ú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.
- Yettel topik
- Nikon DSLR topik
- BestBuy topik
- Samsung kuponkunyeráló
- Mikrotik routerek
- Okos Otthon / Smart Home
- NVIDIA GeForce RTX 5080 / 5090 (GB203 / 202)
- Andras-G: Az internet veszélyei [2. rész] - Facebook Marketpalce
- Parfüm topik
- Intel Dual Core 2000 felhasználók barátságos offolós topikja
- További aktív témák...
- AKCIÓ!!! Sosemhasznált! HP OmniBook 5 i7-1355U 16GB 1TB 16" FHD+ Gar.: 1 év
- ÚJ HP EliteBook 6 G1a Ryzen 5 PRO 230 4.9GHz 16GB DDR5 512GB FHD+ 16:10 már jobbik kijelző, gar 2028
- AKCIÓ! Apple Macbook Air 15 2025 M4 16GB 256GB SSD macbook garanciával hibátlan működéssel
- ÚJ Lenovo ThinkPad X13 Gen 5 - 13.3" WUXGA IPS - Ultra 5 135U - 16GB - 512GB - Win11 - 2 év garancia
- 218 - Lenovo ThinkBook 16p (G5 IRX) - Intel Core i9-14900HX, RTX 4060
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest