Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
Nem. Az egészet még az ATI találta fel, és 2006-ban szabadalmaztatták. Az összes ilyen technológia erre épül, a G-Sync is. A VESA Adaptive-Sync azért tud ingyenes lenni, mert a szabadalom ingyenesen felhasználható a VESA-tagoknak.
(#37762) HSM: Értsd meg, hogy Jensen zabos, amiért dobhatják a kukába a rendszerüket. Ezek után a gyártókat nem fogja érdekelni, viszont az is baj nekik, hogy kb. semmi erőforrást raktak eddig a VESA Adaptive-Sync-be, tehát gyakorlatilag most el kell kezdeniük felépíteni a gyártókkal a partnerkapcsolatot, hogy végre odakerülhessen a G-Sync matrica a FreeSync mellé. És eközben még hozni kell a szoftveres hátteret, ami például nem annyiból áll, hogy átmásolod a G-Sync programkódját, hanem elég sok munka lesz ezt megint megírni, csinálni egy LFC-hez hasonló megoldást, aztán még a FreeSync 2 HDR-re is jó lenne reagálni, mert az a lilás Windows 10 pipeline nagyon nem akar javulni, a Microsoft kvázi szarik bele, mert az Xbox úgyis az AMD pipeline-ját használja. Ez nekik most egy probléma, mert elköltöttek egy rakás pénzt egy olyan területre, amit most le kell cserélniük.
(#37763) Petykemano: A FreeSync 2 technológiailag csak a HDR-ről szól. Valójában a VRR része ugyanaz, mint a FreeSync 1-nek, csak mások a követelmények. De a FreeSync 2 lényege az, hogy megkerüljék a Windows szar HDR pipeline-ját és a kijelzők beépített tone mappingját.
-
Abu85
HÁZIGAZDA
Nem sokat. De ők akkor sem dobhatnak rá plecsnit. Akkor a saját tesztjeiket értéktelenítenék. Ezt úgy kell elképzelni, hogy néha a frissítés változása egyes színek megjelenítésén változtathat, de annyira picit, hogy nem túl észrevehető, viszont létezik, és erre tesztel a FreeSync, illetve a G-Sync. Viszont ez a "kiveszi ezt észre" dolog a tesztek szintjén nem létezik. Ott mérés van, és jó vagy nem. Nyilván arra is fel kell készülni, hogy a kijelző nem tudja a specifikációban írt, sokszor FreeSyncre szabott tartományt, hanem valamivel szűkebb lesz az. Ettől még szar nem lesz, csak nem lesz olyan jó, mint lehetne, ha ezt nem most lépik meg ~600 létező kijelzővel a piacon, hanem már helyből felültek volna a vonatra.
-
Abu85
HÁZIGAZDA
Maga a certifikáció egy képminőségteszt:
A szimpla validáció csak a VESA tesztje, ami vizsgálja a variálható frissítési frekvencia működését. Az NV esetében tudni kell, hogy ők későn léptek be ide, tehát nekik az a specifikáció a meghatározott, amit a monitorgyártó megjelölt minimumnak. Ha ők azt nem képesek elérni a G-Sync implementációval, akkor nem tudják certifikálni a monitort G-Sync-re. És nagyon sok monitorgyártó a FreeSync tartományt adja meg, nem pedig a biztonságos VESA tartományt, ami szűkebb. Abban már működik a GeForce is, ezért írják rá, hogy kompatibilis, csak nem tudják azokkal az értékekkel működtetni, ami a monitor kézikönyvében van. Ellenben van 12 monitor, ahol van certifikáció, és az garantált élmény. Ez az NV-nek nehéz amúgy. Úgy kell támogatni valamit, hogy a támogatandó hardver firmware-ét sose optimalizálták GeForce-ra. Sosem hoztak olyan döntést, aminél mérlegelték volna, hogy az NV-nek ez és az jó-e, mert nem volt érdekes a hardver hiányában. Utólag ezt így lehet kezelni. Majd jönnek az új kijelzőm, amiket már a tervezés szintjén is megnéznek GeForce-szal.
Az, hogy az NVIDIA ezt hogyan adja el marketingként az ő dolguk, engem ugye nem azért fizetnek, hogy felmondjam a marketinget.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#37550
üzenetére
Nem szigorúbbak. Az a probléma, hogy a FreeSync monitorokat nem a GeForce-okra szabták. A szabvány az rendben van, hogy működik, de a VRR-nél vannak olyan problémák, hogy a frissítés változásával változik a képminőség, amire például a szabvány nem tér ki. Tehát egy kijelző 30 Hz-en nem biztos, hogy ugyanolyan jó képminőséget ad, mint 60 Hz-en, esetleg 120 Hz-en. Ezért van az AMD-nek és az NV-nek képminőségtesztje, amelyekkel garantálják, hogy a kijelző a kijelölt tartományon belül a képminőség tekintetében jól működik. Mivel a FreeSync kijelzőket az AMD-re szabták, így logikus, hogy ezek náluk jól működnek, míg az NV-nél 12 ment át ebből a szempontból a 400 teszteltből. De ez normális, amikor ezeket a kijelzőket kiadták, még nem tudták GeForce-szal tesztelni, a firmware-t se rájuk optimalizálták, stb. Meg ugye eleve a VESA szabvány nem igazán szabja meg a képminőséget, ez csak az AMD döntése volt, hogy ez alapján is tesztel, és csak így ad FreeSync plecsnit. Az NV-nek a certifikációja is lényegében a VESA tesztből, illetve az extra képminőségtesztből áll.
-
Abu85
HÁZIGAZDA
Technológiailag nem sok előny, hogy a TSMC-nek van EUV nélküli 7 nm-es node-ja. Maximum annyiban, hogy a partnerek számára a gyártástechnológiai portfólió szélesebb. Ami persze előny lehet az eladások szempontjából, de haszna ennek nem sok van az EUV-s node-ra vonatkozóan.
Itt az fog dönteni, hogy a TSMC-nek az árazási rendszere elég sok cégnek nem kedvez. Szóval menni fognak a Samsunghoz, amely bérgyártó megrendelőket akar, és ezért hajlandó árban alámenni a riválisnak. Kb. az Apple, a Qualcomm és az AMD fogja a TSMC-t megfizetni. Ők céloznak olyan piacokat, ahol ki lehet termelni a magas waferárat.
-
-
#37405
Abu85
HÁZIGAZDA
Petykemano
#37362
Abu85
HÁZIGAZDA
válasz
Petykemano
#37362
üzenetére
Amit RT magnak hívunk az valójában nagyrészt speciális gyorsítótár. Valójában ez csak azért van elnevezve magnak, mert jobban hangzik, mint a cache. De a hardver mögötte nem igazán "mag". Ez kicsit olyan, mintha a raszterizálót magnak hívnánk.
-
Abu85
HÁZIGAZDA
válasz
imi123
#37079
üzenetére
Mivel az AMD csak OEM szinten gondolkodik, így alapvetően a megrendelőnek a 3rd party és a saját IP-ket kell állnia. A többit majd a kész lapkával fizeti a megrendelő, normál OEM-hez hasonló szerződés keretében. Akkor van általában jelentős támogatás a megrendelő részéről, ha valós licencelés történik, de az AMD semi-custom üzletága nem erre épül. Itt az AMD viseli a kockázatokat, cserébe a megrendelő jóval többet fizet majd a kész termékért.
-
Abu85
HÁZIGAZDA
válasz
imi123
#37072
üzenetére
Amúgy sem írná rá szvsz.
Mike-nak ugyan megvan ehhez az iskolája, de a legtöbb munkahelyén leginkább gazdasági, illetve menedzseri pozíciót töltött be. Az RTG-nél is David Wang a mérnöki csapat vezetője. Ugye korábban mindkettőt Koduri vezette, de az AMD két emberre osztotta ki. Így lett Rayfield a "General Manager", míg Wang az "Engineering" fejes, miközben mindkettő titulusa Senior Vice President volt. Ennek valószínűleg az volt az oka, hogy túlzottan sok munka a pozíció egy embernek, illetve talán az is közrejátszik, hogy Wangról azt hallottam, hogy talán az egyik legnagyobb koponya a világon mérnöki szinten (ez igaz lehet, elvégre 25 éve lapkákat, meg GPU-kat tervez), de gazdasági szempontból nincs azért a toppon. -
#36964
Abu85
HÁZIGAZDA
huskydog17
#36959
Abu85
HÁZIGAZDA
válasz
huskydog17
#36959
üzenetére
Én értem a különbséget a kettő között. De ettől mindkettő nyílt forráskódú. Tulajdonképpen az elérhetőség, illetve gyakorlatilag a licenc változott meg, nem a nyílt forráskód létezése. Ez fontos persze, hiszen amíg a 3.3.3-ből volt NVIDIA bináris, addig a 3.4-ből már nincs, ergo nyilván ha nem akarják a bináris supportjának költségeit többet felvállalni, akkor a korábbi, regisztrációhoz kötött elérhetőség nem elég jó, mert úgy nem tudja bárki azonnal elérni a PhysX-et. Így viszont azonnali az elérés, hiszen a forráskódból bárki lefordíthatja, ha már az NVIDIA ezzel többet nem foglalkozik.
(#36962) korcsi: A korábbi verzió is a GitHubon volt megosztva. Itt az a lényeg, hogy amíg neked mondjuk nem volt hozzáférésed ehhez, addig nem jelentett problémát elérni az NVIDIA előre lefordított binárisát. A 3.4-nél ez gondot jelentene, hiszen ilyet az NVIDIA többet nem csinál, tehát muszáj megosztani a forráskódot más formában, hiszen akinek kell a PhysX, annak az egyetlen esélye a beszerzésre a forráskódból való fordítás. És nyilván ha így kellene mondjuk várni az NV engedélyére, az már nem lenne kedvező.
-
Abu85
HÁZIGAZDA
válasz
#48613632
#36836
üzenetére
Igazából a Witcher 3 csak a legelső verzióban tartalmazott GPU-s PhysX-et. Egy elején kiadott patch-ben kivették, amivel gyorsultak is a GeForce-ok 10-15%-ot. Azóta CPU-n megy.
Egyébként tök hasztalan ma már a társkártyás PhysX. Eleve az új PhysX környezetek nem is támogatják, még akkor sem, ha GeForce mellé rakod. Ezért sem fejlődik a hibrid PhysX csomag, hiszen már maga az API nem támogatja a tárkártyás megoldást. A legújabb verziókban pedig a CPU-s kód annyira gyors, hogy a GPU-s kódot játszva lehagyja, illetve ezek a verziók már nem is CUDA-t használnak, hanem DirectCompute-ot. Viszont a fejlesztők nem építik be őket a játékokba, mivel nagyon rövid lett a PhysX életciklusa. Az NVIDIA rendre lövi le a supportot a nemrég megjelent verziók mögül, ami miatt például a Warframe is arra kényszerült, hogy dobja a PhysX-et. Nyilván az NV láthatóan nem akar erre költeni, egy játékfejlesztőnek pedig baj, ha van egy bug a rendszerben és nem tudja hova jelenteni, így le is váltották a rendszert. Több fejlesztő megragadt egy elég régi verziónál, ahol még volt lehetőség a forráskód megszerzésére. Azt nem valószínű, hogy frissítik, mivel az újabb verziókhoz más licenc tartozik, ami kisebb kontrollt ad. Ennek az egésznek úgy lenne értelme, ha az NV fejlesztené és támogatná is.
Az egyik jó megoldás az lenne, ha az NV kihúzza a supportot egy verzió mögül, akkor hozza nyilvánosságra a forráskódját. Az sokat segítene, de igazából az NV-nek különösebben nem számít, hogy csak korlátozott ideig működnek az effektek a játékokban, főleg úgy, hogy a működésük nekik folyamatos költség. -
Abu85
HÁZIGAZDA
A konzol az egy fix gép. Arra sokkal könnyebb optimalizálni.
A szinkronizálás eljárás kérdése. Ez lehet vertikális szinkron is, de némelyik játék afféle fast/enhanced synchez hasonló megoldást használ, míg van olyan is, ami scene pacinget, és ott limitálják a sebességet, majd arra szinkronizálnak. Az egész hardver szabadon elérhető, így eléggé sok dolgot meg lehet tenni. PC-n ezek azért korlátozottabbak, mert itt azért sok múlik a Microsofton, a gyártók driverein, illetve azon, hogy egy gyártó mondjuk hajlandó-e specifikus megoldásokra pénzt áldozni, mert a driverfunkciók nem olcsó dolgok ám. -
#36738
Abu85
HÁZIGAZDA
Petykemano
#36724
Abu85
HÁZIGAZDA
válasz
Petykemano
#36724
üzenetére
Ennek megközelítőleg sincs semmi köze a Chillhez. A Chill az egy scene pacing eljárás, míg az Adaptive Shading-féle megoldások amolyan vizuálisan veszteségmentes trükkök a képszámítás hatékonyabbá tételére. Ettől még ugyanúgy van parancslista, ugyanúgy nincs inputhoz ütemezve a képszámítás, ugyanúgy nem paraméterezhető a célzott képkockaszám, stb. Sokkal inkább a VR-ben alkalmazott Variable Rate Shadinghez van köze, csak nem úgy csökkenti a részletességet, hogy a kép fix részeit számolja kisebb részletességgel, hanem figyelembe veszi a tartalmat is.
-
Abu85
HÁZIGAZDA
Éppenséggel sok munka van vele. Az egy dolog, hogy a PSSL hasonló a HLSL-hez, de nem ugyanaz. A HLSL-nek is vannak verziói, tehát az sem mindegy, hogy melyik HLSL-hez hasonlít.
Az valóban lehetséges amúgy, hogy PSSL kódot fordíts PC-s hardverre, de ez nem szabványos. Az AGS szervizkönyvtár tartalmaz olyan függvényeket, amelyek ezzel kompatibilisek, és igen ezzel némelyik fejlesztő él is, de ha így csinálják, akkor ezek a kódot PC-n csak GCN-es Radeonon futnak, tehát szabványos HLSL kódokra így is szükség van, mert valamit futtatni kell Intel és NV hardvereken is. Szóval jól hangzik, amit a Sony mond, és van is benne igazság, csak nem úgy, ahogy azt elgondoljátok. -
Abu85
HÁZIGAZDA
A gyártás az gyártás. Nekik aztán tökmindegy, hogy ki veszi meg őket. Amíg van megrendelés, addig gyártják. És nem nyilatkoztam mást, hanem egyszerűen a média kavar, de valójában még mindent gyártanak, mert Turingból nem tudnak annyit gyártani, mint a GTX 1080 Ti-ből. Ez egy mennyiségi probléma. Ha a megrendelőnek az NV nem szállítja le az igényelt mennyiséget, akkor vásárolnak Vegát és kész, mert a megrendelő el akarja adni a kész gépeket.
Ugyanez van most az Intelnél. Minden terméket átcsoportosítanak OEM-re és mobilra. A dobozos asztali termékekből mostantól sokkal kevesebb lesz. Arról is jönnek majd a cikkek, hogy az Intel nem gyártja őket? Az a baj, hogy a média jó része buta. És ezt nem én mondom, hanem a gyártók, mert ránéznek az árlistára és látják, hogy mi hogyan változik, de a legtöbben bele sem gondolnak, hogy ez csak a teljes kép egy kis része. És az, hogy az OEM-ek léteznek igencsak befolyásolja az asztali kínálatot is, ugyanis nem a tízezer VGA-t vásárló megrendelőnek mondják majd azt, hogy bocs, de Mancika és Józsi rendelt 500-500-at, ezért csak 9000-et tudnak szállítani. -
#36685
Abu85
HÁZIGAZDA
Petykemano
#36683
Abu85
HÁZIGAZDA
válasz
Petykemano
#36683
üzenetére
Fogják még egy darabig mindkettőt gyártani. Idővel persze már csak a 12 nm-es verziót, mert az kompatibilis a 14 nm-essel.
(#36684) b. : Az NV még minden aktuális Pascal GPU-t gyárt. Egy év múlva is gyártani fogják őket. Még Fermi GPU-kat is gyártanak.
-
Abu85
HÁZIGAZDA
A Vegán sincs meg a memória-sávszélesség hozzá. A Pascalt el tudja verni benne, de akkor is lassú lesz. A DirectX Raytracing egy olyan terhelés, ahol a mai poligonszám mellett a szükséges mély BVH zabálja a sávszélt. Ami most van a VGA-kon 300-600 GB/s, az ehhez kevés. 1 TB/s fölött lehet elérni valamit, de egyébként még az sem sok.
-
#36519
Abu85
HÁZIGAZDA
FollowTheORI
#36518
Abu85
HÁZIGAZDA
válasz
FollowTheORI
#36518
üzenetére
Az új fejlesztéseket nem kapták meg. Az SE a nyugati címeknél a LABS részleget tartja az R&D-re. Ők gondoskodnak arról, hogy minden játék motorja kapjon javításokat, fejlesztéseket, ami kell. De mivel az IO és az SE szakított, így az IO kénytelen volt a Hitman 1 motorjának finomításánál maradni, vagyis minden, amit a LABS fejlesztett nekik maradt a kiadón belül. Ez van. Annyira nem rossz, de persze látszik rajta, hogy vannak hiányosságok.
-
#36516
Abu85
HÁZIGAZDA
FollowTheORI
#36515
Abu85
HÁZIGAZDA
válasz
FollowTheORI
#36515
üzenetére
Nem igazán. Inkább technológiai. De ugye a Hitman 2-nél számolni kell azzal, hogy a stúdió és a kiadó különvált, vagyis minden, amit a Hitman 2-höz fejlesztett a LABS, azt az IO Interactive végül nem kapta meg. Saját R&D részlegük pedig nyilván a LABS miatt nem volt. Azt majd később állítják fel, hiszen mostantól nem férnek hozzá a LABS technológiáihoz. Emiatt hozhattak olyan döntéseket is, mint a DX12 hiánya, stb. Nincs meg rá a kapacitás a Square Enix nélkül.
(#36513) b. : Persze lehet mondani, hogy a karakterek szarul néznek ki, meg alapvetően nem sokat változott a játék az előző részhez képest, de tekintve, hogy válás volt, így nem hiszen, hogy nagyon kockáztatni akartak technológiailag. Nekik ez most szarul jött ki.
-
#36476
Abu85
HÁZIGAZDA
FollowTheORI
#36457
Abu85
HÁZIGAZDA
válasz
FollowTheORI
#36457
üzenetére
[link] - ez a kép bemutatja, hogy miről van szó. A parancslistába csomagokban lesznek berakva a képkocka leképezéséhez szükséges jelenetinformációk. Ezeknek a csomagnak a maximális méretét határozza meg a beállítás. Ha 0, akkor alapvetően maga a parancslista nem létezik, legalábbis klasszikus értelemben, mert mindig az aktuális csomagot dolgozza csak fel a GPU. Ha mondjuk 3, akkor a csomag 3 képkocka leképezéséhez szükséges jelenetinformációt tartalmazhat maximum, ez még nem jelenti azt, hogy ennyit fog tartalmazni, például lehet, hogy csak egyet, de maga a csomag ennyit megenged. A kép az ilyen illusztráció, és most a Chillt ne is keverjük ide, mert az eléggé speciális abból a szempontból, hogy ez a parancslista a hagyományos értelemben nem is létezik, meg ugye eleve van rajta scene pacing, míg a hagyományos feldolgozásnál ez hiányzik, de a lényeget le lehet belőle szűrni.
-
Abu85
HÁZIGAZDA
válasz
Raymond
#36438
üzenetére
Furi, hogy nekem ezt Off-on jelzi. Lehet, hogy az új frissítéssel már On.
Alapvetően ugyanarról van szó. Elvégre, ha nem készít elő több jelenetet a CPU, akkor a GPU nem tudja megkezdeni az extra képkockák számítását.
A profilokban régóta módosítják ezeket a beállításokat a gyártók. Az, hogy a driver alapértelmezett beállítása az NV-nél 3, míg az AMD-nél 1, nem jelenti azt, hogy minden egyes játékra igaz. A BF5-nél a profilban megadott default mindkét gyártónál 1 volt a korábbi meghajtókban. Ez az AMD-nél nyilván nem jelent változást az általános defaulthoz képest, de az NV-nél igen. Az, hogy ez változott-e a legújabb GeForce driverrel? ...kötve hiszem, de persze lehetséges.
Ha a profilban ezt konfigurálja az adott gyártó egy játékra, akkor nem sokat számít, hogy a driver ténylegesen alapértelmezett beállítása mi.
(#36440) b. : A DX12-höz is ugyanúgy más kódot kap az AMD. Az a baj a shader modell 6-ös kóddal, hogy csak egy shader modell 5-ból konvertált alap, amiben egy csomó új függvény nincs is használva. Egyszerűen még nem volt rá idő, de a DXR miatt ugye muszáj az új shader modellt is használni. Az AMD csak azért kap más kódot, mert arra a production pipeline máshogy van kialakítva. Régóta van már egy jól működő eszköz, amivel a PS4-hez megírt kódokat be lehet nyomni a PC-be, és az futhat a Radeonokon. Ez API-tól független. Ezt majd idővel ejtik, mert nyilván az lenne itt mindenkinek az érdeke, hogy ezeket a kódokat egy szabványos felületen biztosítsák, ami a shader modell 6, csak a portoláshoz idő kell. Meg ugye itt a shader modell 6 az direkten a DICE munkája, az AMD arra nem ad nekik embereket, hogy ezt megcsinálják, mert nekik, a saját specifikus kódjaik birtokában nincs szükségük a shader modell 6-ra.
Szóval az, hogy a DX11-ben fura az eredmény, meg furán gyorsa a Radeon, annak köszönhető, hogy van egy rakás olyan kód, amelyek gyorsabban a szabványosnál, és azt csak egy Radeon tudja futtatni. Semmiféle drivertrükk, mágia, vagy csoda nincs mögötte, egyszerűen évekig ezen dolgoztak a DICE-szal, és ennek ez az eredménye.A DX12-es lassulásnak és dadogásnak pedig ez az oka: [link] - vagy kiütöd a problémát blokkalapú vezérléssel, vagy marad a DX11. Persze a megoldás az lenne, ha újraterveznék, de szerintem az EA-nek nem ér meg annyit, hogy ezzel törődjenek az új generációs konzolok előtt.
-
Abu85
HÁZIGAZDA
Ez nem keverendő a szinkronizálással. Leginkább azt határozza meg, hogy a GPU egyszerre hány képkockát számolhat előre az aktuálison túl. Persze ez leginkább egy elvi adat, de amúgy lehetséges, hogy a driverek BF5-re beállított default egy extra képkockájához képest, ha mondjuk három van megadva, akkor a jobb sebességet eredményez. Főleg, ha ez a szoftverben direkten van szabályozva.
A szinkronizáció emellett még kell, ha nem akarsz képtörést. Az Enhanced adja a legkisebb késleltetést.
Az FRTC nagyrészt hasztalan a Chill óta, mert utóbbi is képes a sebességet korlátozni. A Chill egyébként sose számol az aktuálison túl extra képkockát, de azt nem tudom, hogy miképpen reagál erre a beállításra a BF5-ben, mert ez elméletben nem kompatibilis a Chill lényegében.(#36435) Raymond: Én úgy néztem, hogy ki van. Kajak az a default. Vagy ez most megváltozott?
-
#36433
Abu85
HÁZIGAZDA
Petykemano
#36411
Abu85
HÁZIGAZDA
válasz
Petykemano
#36411
üzenetére
Eleve nem ugyanazt a kódot futtatják. Az AMD-hez mér az SW: BF óta a direkten PS4 PSSL kódokból fordít bizonyos shadereket a DICE. NVIDIA-hoz és Intelhez nyilván ezt nem teszik meg, hiszen ezek ezzel a módszerrel nem is kompatibilisek, szóval itt szimplán az Xbox One HLSL kódjait portolják a shader modell 5.0-hoz. A BF5 annyiban változott, hogy már shader modell 6.0-hoz is portolnak. Utóbbi szükségtelenné tenné a PS4-es shadereket is, hiszen megvannak benne ugyanazok a függvények, csak ugye a DX11 miatt nem szerencsés túlságosan építeni ezekre, mert akkor sok shader nagyon eltérne az 5.0-s és a 6.0-s változat tekintetében. Viszont a PS4 PSSL-re már megvan több címben is jól kitesztelt program, amivel egyszerűen konvertálható AGS-re specifikus shader, ergo ezt megéri alkalmazni.
(#36421) PuMbA: Annak a beállításnak nem csak előnye, hanem hátránya is van. Ha bekapcsolod, akkor nő a késleltetés. Nem mellesleg azért van ez alapértelmezetten kikapcsolva, mert a gyártók szeretik ezt maguk szabályozni a driverek, adott játékhoz tartozó profiljában. Szóval ez valami egyezmény lehet, aztán ott az opció bekapcsolni.
(#36412) b. : Ennek nem sok köze van magához a DX11-hez. Tényleg csak annyi történik, hogy más shadereket futtatnak. Az AMD nagyon sokáig a DICE legfőbb technológiai partnere volt, kidolgoztak az elmúlt években több olyan eszközt is, amivel egyszerűen gyorsabb kódokat lehet írni a Radeonokra. Az NVIDIA ezzel nem törődött, mert jött a shader modell 6, ami úgyis szabvány, csak itt is számolni kell azzal, hogy még ha a BF5 már megy is ebbe az irányba, akkor sem fog azonnal mindent kihasználni a shader modell 6-ból, mert még kompatibilisnek kell lenni a DX11-es shader modell 5-tel is. És azért ennyiféle kódot karbantartani tényleg nem szerencsés ám.
-
Abu85
HÁZIGAZDA
válasz
#59036672
#36393
üzenetére
És mit kezdünk vele olyan DX12 módban, ami dadog? Ez nem működik DX11 alatt, ami a folyamatos élményt adja.
(#36396) Erdei88: Mindegy. A DICE nem javította a Frostbite 3 memóriamenedzsmentjét. [link]
Jó mondjuk nem tettem volna kis tétet sem arra, hogy javítani fogják.![;]](//cdn.rios.hu/dl/s/v1.gif)
-
Abu85
HÁZIGAZDA
válasz
Crytek
#36391
üzenetére
"You may run the game in either DirectX 11 or DirectX 12, with DX12 showing a little bit more stuttering in general—Battlefield 1 was and still is the same, looks like EA is having difficulties getting this fixed."
Szóval még mindig dadog a DX12 mód.
Itt buktuk az réjtrészinget.
Komolyan mondom a Halcyonnak része az új memóriamenedzsment. Szépen át lett portolva a VMA-ról. Annyira adná magát, hogy erre térjenek át a Frostbite esetében. Lehet, hogy buknának pár fps-t, de legalább nem dadogna, és nem kellene HBCC ennek a kiütésére.
Az egésznek így semmi értelme, mert az új funkciók csak a dadogós módban érhetők el.
-
#36390
Abu85
HÁZIGAZDA
Petykemano
#36388
Abu85
HÁZIGAZDA
válasz
Petykemano
#36388
üzenetére
Elviszik az OEM/ODM-ek. Ugyanaz van vele, mint az 1080 Ti-vel. Nem lehet mit csinálni.
-
Abu85
HÁZIGAZDA
Pontosan. Tehát az OEM/ODM first modell pont karácsony előtt okoz gondot a kiskereskedelmi piacon, amikorra minő véletlen az OEM/ODM-ek feltöltik a készleteiket. Lehet erre azt mondani, na most akkor tuti nem gyártják (mínusz a PC Partner ugye
), meg lehet azt is, hogy a nyáron rosszul mérték fel az 1080 Ti-re az ünnepi igényeket. Sajnos van ilyen. Nem is kell messzire tekinteni: khm...Intel...khm -
Abu85
HÁZIGAZDA
Ez a baj, mert ez a lényeg. A piacnak nem a kiskereskedelmi réteg az első. Ha itt nincs holmi, akkor az OEM/ODM igény nagy. Márpedig a gyártópartner nem a HP-nek mondja majd, hogy nem tud tízezer VGA-t vagy CPU-t szállítani ebből, mert kell Pistinek a tanyára, hanem a nagykereskedőknek, ami miatt a kiskereskedők is szopcsiznak. Nem beszélve szegény Pistiről.
-
Abu85
HÁZIGAZDA
"GamersNexus has heard through multiple industry sources that US-based supply of GTX 1080 Tis is dwindling, with manufacturers running low on inventory of the previous flagship."
Tehát a multiple industry sources az NV új neve?
Felőlem egyébként hihetitek azt, hogy nem gyártják, de szerintem sértő az NV számára, hogy ennyire hülyének nézitek őket.
Érdekes egyébként, hogy rengeteg Intel CPU-t sem lehet elérni. Azokat sem gyártja az Intel? Ő kérdezte. Ha zavar, akkor ne olvasd el.
-
Abu85
HÁZIGAZDA
válasz
TTomax
#36370
üzenetére
Rendszermemória kell, de anélkül eleve nem működik a gép. A HBCC kijelöli a RAM-ban a CPU és a GPU által elérhető részt, amit a GPU-hoz illeszt, így annak menedzsmentjéről hardveresen gondoskodik a normál szoftveres forma helyett.
(#36371) NewHope88: A Middle-earth: Shadow of War többet kér bizonyos beállításokkal 8 GB-nál. Durván kimaxolva 18 GB-ot, de ott már a felbontás miatt az erővel is gond lenne.
-
Abu85
HÁZIGAZDA
válasz
NewHope88
#36362
üzenetére
Az csak premium, de nem csúcskategóriás. Leginkább a memória mennyisége a probléma. Amikor választanak az OEM/ODM-ek egy gépet, akkor azért érdemes észben tartaniuk, hogy vannak olyan címek, amelyekben a 8 GB memória elfogy. Például a Middle-earth: Shadow of War. Ott a GTX 1080 Ti-nek ebből nincs gondja a 11 GB VRAM-jával, míg a Vega esetében ez az egész csak egy csúszka, ha akarsz és van kellő RAM-od, akkor 64 GB-ot is beállíthatsz neki, és akkor a játék 64 GB-osnak detektálja.
(#36363) b. : Az RTX-nél nem a kihozatal a probléma, hanem a komponensek száma. Még a 2070 is bonyolultabb, mint az 1080 Ti. A Vega 56/64 pedig kb. egy GTX 1070/1080 bonyolultságú hardver a felhasznált komponenseket tekintve. Na most minél több komponensed van, annál tovább tart a gyártási folyamat. Ergo egy napon belül kevesebb hardvert tudsz gyártani. Emiatt az 1080 Ti-t nem igazán éri meg eldobni, mert az a saját kategóriájában relatíva nagy napi mennyiségben gyártható a partnerek számára. Az meg, hogy eltűnik a polcokról... Persze, amikor a nyáron leadták a rendeléseket, akkor azért bőven arra számítottak az érintettek, hogy a vásárlók az RTX-ekre fognak bökni a vásárláskor és nem a GTX 1080 Ti-re. Az, hogy inkább az utóbbit választják azt jelenti, hogy az eredetileg tervezett mennyiség nem elég. Ilyenkor pedig jön az OEM/ODM first, vagyis először a hiány kiskereskedelemben csapódik le, nem azokon a csatornákon, ahol tízezres nagyságrendű rendelésekkel kalkulál az adott partner. És persze lehet ütni a fejed a falba, hogy gondolni kellett volna arra, hogy a vásárlóbázis mégsem eszi majd meg az RTX-et, de ilyenkor már hiába. Mire ezen változtatni tudnak jövő tavasz lesz.
(#36364) Petykemano: Van egy számtekboltod. Száz PC-t építesz karácsonyra a jellemző megrendelésekhez. Ebből teszem azt 50-be rendelsz RTX-et, mert az előző év azt mutatja, hogy nagyjából ilyen arányban érdeklődnek a potenciális vásárlók az újdonság iránt. 50-be pedig 1080 Ti-t, mert lesz olyan, akinek nem fog kelleni az új. De 1080 Ti teszem azt nincs, vagy legyen mondjuk csak 20 gépbe. Mit csinálsz? Inkább lemondod a többi komponenst, és beletörődsz, hogy idén karácsonykor csak a korábbi évek bevételének a 70%-a jön be, vagy inkább rendelsz 30 Vega 64-et, hogy hozd a korábbi évek pénzmennyiségét? Ez így működik alapvetően. Az OEM/ODM-ek fix gépszámra mennek, ha az NV nem tudná kiszolgálni ezt, akkor elmennek az AMD-hez, mert nem realitás a jelenlegi világban, hogy lemondj a saját bevételedről.
(#36367) TTomax: Mindenki látja. Egy nyári hibás döntés eredménye. De ettől még nem állt le a gyártásuk. Bizonyos Intel processzorok is alig kaphatók, mégis gyártják őket gőzerővel. Beszopták ennyi, ahogy tudják próbálják korrigálni, csak ez nem megy egyik napról a másikra. Egy ilyen VGA nagyon sok hétig készül, vagyis még ha el is tudják intézni, hogy egy hiánycikk szériára több alkatrészt szerezzenek be, akkor is legalább 3-4 hónap, mire változik a helyzet. Ha ez nem így lenne, akkor az Intel már teleöntötte volna procival a boltok polcait.
-
Abu85
HÁZIGAZDA
Mert mit tudnak még rendelni a csúcskategóriában? Ha leállítják az 1080 Ti-t, akkor lesz kb. feleannyi RTX, és a rendelések másik felével mit csinálsz? Lemondod? Nyilván nem, rendelsz bele hardvert a konkurenciától. Ezért nem úgy működik a VGA-k gyártásának leállítása, ahogy azt itt sokan gondolják. Ha nincs 1080 Ti, akkor az még nem jelenti azt, hogy több lesz az RTX-ek eladása, mert túl sok komponensből épülnek fel ahhoz, hogy olyan mennyiségben lehessen őket gyártani, mint mondjuk az 1080 Ti-t vagy a Vega 64-et.
-
Abu85
HÁZIGAZDA
válasz
NewHope88
#36358
üzenetére
Az egész abból indult ki, hogy felment az 1080 Ti ára, de ez ezernyi októl lehet még. Az valóban egy létező probléma, hogy az NV nem azzal az arányokkal számolt, amit most tapasztal a piacon. RTX-ekből nagyobb keresletet várt, míg a régi szériából kevesebbet. Erre is készültek, de az embereknek még tetszik az 1080 Ti. Na most erre hirtelen nem lehet reagálni, ez nem úgy megy, hogy akkor holnaptól kétszer több 1080 Ti készül. Majd ki kell számolni újra a tavaszi igényeket, mert akkorra lehet több 1080 Ti-t készíteni, de ugye azok az igények megint változhatnak. Ami most van azok leginkább nyáron számolt tényezők, és persze valószínűleg senki sem tagadja, hogy nyáron még nem azt várták, hogy az RTX-ek helyett inkább a GTX-eket rendelik a játékosok.
Talán furcsának tűnhet, de például az NVIDIA még gyárt Keplert, az AMD is gyárt még Terascale 2 GPU-t. Tehát ez a kivezetés nem olyan, hogy itt az új sorozat, és akkor VISZLÁT
vagy abrakadabra van a réginek. Ezek nagyon sokáig megmaradnak még, főleg az elején mert az is egy nagyon fontos tényező, hogy egy adott VGA-ból mennyit lehet naponta gyártani. Amíg az új széria nem tudja megközelíteni az elődöt, addig hasztalan azt kivezetni, mert csak az árak mennének fel, illetve alapvetően nem lenne elég eladható termék.Majd valamikor jövő nyáron frissülnek az OEM/ODM gépparkok, amikor már úgy alakítják ki a partnerek a termékeiket, hogy a GTX 1080 Ti-t bele se rakják a rendelhető komponensek közé. Na ott lesz vége a dolognak, de amíg egy OEM/ODM-en keresztül tudsz ilyen VGA-t választani, addig ez marad.
-
Abu85
HÁZIGAZDA
válasz
NewHope88
#36343
üzenetére
Fake news! A PC Partner még gyártja. Azért ment fel az ára, mert az RTX sorozat megjelenésével megnőtt rá az igény, miközben az NVIDIA azzal számolt, hogy a piac az RTX-et fogja vinni nem a GTX 1080 Ti-t. De ettől a gyártása még nem állt le. Nagyon nehéz úgy lelőni ezeket a termékeket, hogy az OEM/ODM-ek még most is rengeteg ilyen gépet szerelnek össze. Előbb itt szokott megszűnni a rendelés, és utána kap az adott széria EOL-t. Az is nagyon fontos, hogy a GTX 1080 Ti-ből 50%-kal is többet tudnak naponta gyártani, mint az RTX 2070/2080-ból. Tehát már csak a mennyiségi tényező miatt sem lehet teljesen kivezetni. Ha mondjuk teszem azt lelövik, akkor sem tudnak több RTX-et gyártani, viszont amelyik OEM/ODM még rendelne GTX 1080 Ti-t már nem tudja megtenni, így a helyére Vega 64-et fog kérni, ergo az NV saját magát lőné vele lábon.
-
#36332
Abu85
HÁZIGAZDA
Petykemano
#36327
Abu85
HÁZIGAZDA
válasz
Petykemano
#36327
üzenetére
A GPU-architektúrák ott pukkadnak ki, ha a hardveres szálkezelés már nem tudja etetni a multiprocesszorokat. Az NV és az AMD is ennek a határán van az aktuális dizájnnal, de még van benne egy-két generáció. Főleg úgy, hogy a WinML eléggé megváltoztatja az igényeket. Nem igazán az lesz a lényeg, hogy több teljesítményt építs be a hardverbe, hanem az, hogy az AI-ra tervezett részhardver gyors legyen, illetve a DXR-nek gyakorlatilag a sávszélhiánytól szenved. Ergo mindegy, hogy a mostani AMD és NV dizájnoknak közel a határa, a következő API-k igazából nem az ALU-kra hajtanak, hanem a sávszélre, illetve specializált AI hardverre.
-
Abu85
HÁZIGAZDA
Sok függ attól ahogy tervezik a drivert. Nagyon fura az a tényező, hogy régen az AMD több csapattal csinálta a havi Catalysteket, majd leálltak vele, mert látták, hogy az NV-nek jobban működik az egycsapatos fejlesztés, na meg ugye hotfixelés volt végig. Erre mit ad isten az NV fogta magát és ráment a Game Ready marketingre, amivel beleálltak a több csapatos tervezésbe, ahogy az AMD csinálta a Catalyst érában, hozta is magával a hotfixelést.
Az egész nagyrészt egy menedzsment szintjén behatárolható kérdés. És úgy néz ki, hogy több csapat párhuzamos fejlesztését, gyártótól függetlenül nehéz optimálisan "összeolvasztani". A marketing más kérdés. Ott ugye régen az AMD verte a mellét a sok WHQL-re, most pedig az NV teszi. Csak hát ugye mennyi minőségvesztést ér meg az évi sok WHQL, na ez az ultimate kérdés. Ha a marketingest kérdezed, akkor valószínűleg azt mondja, hogy sokat, mert ez egy újabb dia, amit el lehet adni. Ha egy rendszerprogramozó véleménye számít, akkor ő azt fogja mondani, hogy nem éri meg a sok WHQL, inkább legyen jól menedzselhető a szoftver tervezése. És kb. ez a két álláspont ütközik a cégeken belül. A teljesítménykényszer miatt pedig előbb-utóbb előnybe kerül az egyik. -
Abu85
HÁZIGAZDA
Részben azért, mert a DXR aktuális verziójában az egyedüli, minőséget is adó vertex formátum 32 bites lebegőpontos, ami egy háromszögre 48 bájtos terhelés. Ennél sokkal jobb 32 bites snorm, mert kapásból kevesebb memóriaigénnyel tárolsz majd egy háromszöget, miközben alig rontottál a képminőségen. Ez amúgy tervben van egy későbbi DXR frissítésre, tehát nyilván meg lesz oldva a probléma, de legalább fél, vagy inkább egy év kell hozzá.
A másik gond a BVH. Ebből az NV-nek az egyik megoldása van használva, ami egyrészt jól skálázódó, másrészt borzasztóan sászélpazarló, így egy hét szintű mély BVH struktúra simán megvan ~80 bájt/blokk. Ez egyszerűen nagyon sok komplex geometria mellett, márpedig a mai játékok nem kevés háromszögszámból állnak. Ezért van megcélozva a programoknál az 1080p/60 fps a 2080 Ti-vel. Egyszerűen nincs meg a sávszél, hogy ebből több legyen. Persze egy-két generáció múlva, 1-2 TB/s-os sávszéllel már egészen más a történet, és addigra maga a DXR is fejlődni fog. Emellett ugye a Microsoft dolgozik a WinML-en, és valójában ezt a DXR mellé tervezték. Ezzel a környezettel nem kell 4K-s felbontást számolni, egyszerűen elég a Full HD is, és onnan mehet az AI felskálázás 4K-ba, illetve fölé. Tehát a helyzet csak most tűnik reménytelennek, de mondjuk két év múlva már igen reális lehetőség lesz ez az irány. -
#36272
Abu85
HÁZIGAZDA
Petykemano
#36271
Abu85
HÁZIGAZDA
válasz
Petykemano
#36271
üzenetére
Valósnak valós, csak nem reprezentatív. Kb. olyasmi, mint a Steam. A teljes piachoz képest egy eléggé szűk minta, ami nincs is korrigálva.
-
Abu85
HÁZIGAZDA
válasz
Csupingo
#36265
üzenetére
Nem, mert a probléma a komplexitás. Mindegyik RTX modellből egy bizonyos mennyiséget tudnak gyártani, és például még a 2070-ből is kevesebb készülhet egy nap, mint mondjuk az 1080 Ti-ből. A 2080 Ti-ből pedig sokkal kevesebb. Ez határozza meg az árat, mert hiába viszik le azt, akkor sem tudnak belőle többet gyártani.
(#36257) Keldor papa: Nem feltétlenül az ígéreteket kell nézni, de azért a Turing az NVIDIA első architektúrája, amely pure bindless, illetve még az erőforráshalmaz szempontjából is többféle különböző erőforrástípus lehet ugyanazon a halmazon belül. Ennek azért van haszna, hiszen így nem a processzormagokat zabálja le a bekötés, hanem a hardver gyakorlatilag el tudja végezni kvázi a processzor segítsége nélkül. Jó nem 100%-ban, mert a Turing még nem memóriaalapú, de nagyon nem mindegy, hogy a bekötést egy CPU-n futó binding modul csinálja, vagy pusztán a hardver a mintavételezőben, és onnan már csak egy másolás kell a multiprocesszorig. Erre azért már ma is találni programot, például a Forza Horizon 4-et.
Azt mindenki érti, hogy ezeken a VGA-kon nincs TB/s feletti sávszél, tehát RT-re azért nem sok babér terem, figyelembe véve, hogy ~140 bájt/háromszög körüli a terhelés. Tehát kellene hozzá úgy 2 TB/s kezdésnek, de azért a pure bindless és a memóriahalmaz optimális kezelése sokat jelent ám, még akkor is, ha még mindig slotalapú a dizájn. Azt is értem, hogy ezt korábban is meg lehetett volna tenni, hiszen az Intel és az AMD is évek óta hasonló dizájnokat kínál, de ezen kár vitázni. -
Abu85
HÁZIGAZDA
válasz
syberia
#36159
üzenetére
Nem. Alig kimutatható eladásért felel az RTX sorozat. A teljes termékskála 1%-át sem éri el. Ilyen kis volumenű termékek nem befolyásolják ennyire a tőzsdét. Sokkal inkább a bányászláz vége az, amiért megy lefele a részvényár. De ez nem valószínű, hogy tartós tényező lesz.
-
Abu85
HÁZIGAZDA
A fejlesztési költséget nem igazán szorította le egyik cég sem. A változás ahhoz kell, hogy a pénzt hasznosan költsd el. Nem mindegy, hogy funkciókba rakod, vagy az évek óta felpumpált kód megfelelő fejlesztésébe és tesztelésébe.
Kb. én is így voltam a driverekkel régen. Viszont a Chill annyira bejön, hogy már nem tudok nélküle élni. Nagyon sokat javít a késleltetésen, a fogyasztás csökkenése pedig csak extra. Én amúgy bízom abban, hogy a Microsoft ezt szabványosítja. Meg lehetne oldani. De valószínű, hogy egy nagyobb váltásnál az NV és az Intel is lemásolja, mert túl komoly előnyt jelent a fogyasztásra nézve.
(#36095) Zsébernardo: Szerintem messze az volt a legrosszabb. Ezt a vonalat nem véletlenül hagyták. A Radeon Software végre egy értékes fejlesztési irány, ami az Adrenalin verzióban eléggé odarakta. Az Omegához képest ez ég és föld.
-
Abu85
HÁZIGAZDA
válasz
#00137984
#36092
üzenetére
Szerintem az Omega az egy mélypont volt. Ott dönthették el, hogy ez nem mehet tovább, mert rengeteg volt a panasz, és nagy volt az elégedetlenség. Amióta Radeon Software-re váltottak azóta ugrott meg az elégedettség, ami mára stabilat 4,5/5 fölött van. Ez különösen igaz szerintem az Adrenalin sorozatra. Az egy egészen más szint.
Minden beállítást átmentettek a Settings vezérlőpultba, ami ott volt a Catalystben.
-
Abu85
HÁZIGAZDA
Nem mellékesek. Minél kevesebb pénzből biztosítja a meghajtó alapfunkcióit egy gyártó, annál több pénzt tud elkölteni ilyen-olyan fejlesztésekre.
Vulkan API-ra nincs RGP-hez hasonló, kihasználtságlimitet is mutató profilozója az NV-nek. Ha lenne, akkor nem váltották volna le a Unity és az UE4 fejlesztésének gépparkját Radeonra. Viszont mivel az NV egy hasonlót még be sem jelentett, máig sem, így nem volt sok választásuk. Az API-ra fejleszteni kell, tehát szerezni kellett olyan hardvereket, amin ezt meg lehet tenni. Nyilván a konzolos workflow eléggé időgyilkos, még ha ideig-óráig meg is éri. Egyébként az NSightba bele lehetne rakni, mert DX12-re például van, de Vulkan API-ra nincs. Valószínűleg nincs elég erőforrás erre, mert a hasznosságát nem lehet vitatni.
A Chill bármin segíteni tud. Az internetkávézók legnagyobb problémája az, hogy a gépeket működés közben hagyják ott az emberek. Ha fél óra múlva állították le, akkor addig csak úgy működött a rendszer és ugyanazt a képet kiszámolta mindig másodpercenként akár 140-150-szer. Emiatt van a Chillben input szerinti számítás. Vagyis, ha nincs input, akkor másodpercenként csak 30-szor is elég ha számol, hiszen ugyanaz lesz a kép mindig. Ezzel az átlagos fogyasztást igen durván csökkenti, szimplán hardver erre nem képest. Itt láthatod, hogy mekkora különbség van aközött, hogy ha áll a gép és úgy számol, illetve ha áll és aktív a Chill. [link] - ez az internetkávézóknak spórolást jelent.
-
Abu85
HÁZIGAZDA
Ők a driverben és az eszközökben látták lemaradást. Ezért kezdtek bele a Radeon Software-be és a GPUOpen kezdeményezésbe.
Egészen egyszerű dolgok történtek anno pár éve. A Catalyst vonalból kivették a pénzt. Teljesen átcsoportosították a rendszert, mert maga a Catalyst egy dinoszaurusz volt, és önmagában a legacy kódok fenntartása rengeteg pénzt elvitt. Ezt konkrétan elmondták nekem régebben. Figyelembe kell venni, hogy bár a kódbázis megtartása logikus döntés lehet, de bizonyos esetekben nagyon drága is. Emiatt úgy döntöttek, hogy dobják a Catalystet. Helyére jött egy jóval alacsonyabb költségből fejleszthető szoftver, aminek a karbantartására már nem kell annyi ember. A másik tényező pár éve az volt, hogy amikor az explicit API-t behozták, akkor úgy építették fel a drivert már a Mantle-re is, hogy két részre vágták. Lett egy hardverhez közeli, illetve API-hoz közeli része, és az előbbi implementáció megmaradt a DX12/Vulkan API-ra is, míg a kliensoldali kódot gyorsan át lehet írni. Ezen is rengeteg pénzt spórolnak, miközben nagyon gyors az összes explicit API-hoz az implementáció. És ezek nagyon kritikus döntések voltak, mert be is lehetett volna vele fürödni, viszont azzal, hogy a költségeket és az erőforrásigényt ezeknél a részeknél levágták, felszabadult egy rakás humán- és anyagi erőforrás extrákat csinálni, plusz még megvették a HiAlgót. Tehát effektíve az történt, hogy a Catalyst érához képest nem költenek igazán többen a driverre, mégis fejlesztettek pár olyan, általánosan működő szolgáltatást, amelyhez hasonlót más nem kínál, pl.: Radeon Chill, Radeon Overlay vagy AMD Link. Hasonlót egyébként pusztán elviekben tudna más is, de ez nem egy eldöntendő kérdés, mert ehhez elő kell teremteni a szükséges erőforrást, mind humán, mind anyagi szinten. Ha még ma is dinoszaurusz lenne a driver, akkor egyszerűen ezek a szolgáltatások csak elégetnék a pénzt. Olyan szinten megbonyolítanák a fejlesztést, hogy anyagilag nem éri meg beleinvesztálni az erőforrást. Amíg az Intel és az NV nem nyom egy resetet, addig például egy Chillhez, illetve egy bonyolult Overlayhez hasonló megoldás kigazdálkodhatatlan. És ez volt a legfőbb tényező, amiért az AMD megvált a Catalyst nevű dinoszaurusztól, ami nagy, agyontuningolt, éppen működő kódbázissá vált az évek során, ami lehet, hogy tette a dolgát, de ehhez olyan mennyiségű pénzt kellett elégetni, hogy az egész kontraproduktívvá vált. Az Intel és az NV még ragaszkodik a saját megoldásához, bár az NV ugye bevezetett egy külön programot a GeForce Exprience-szel, hogy nem az elavult kódbázisba építsék be az újdonságokat. Ez amolyan "nem is harapok a saját kezembe, de nem is nyalogatom meg" elvű döntés. Ugyanakkor a jövőben az Intel és az NV is váltásra lesz kényszerítve, mert egyre nagyobb gond nekik, hogy az AMD hozza be a faszántos funkciókat (nyilván tudják, hogy idén is lesz frissítés, ami megint hoz valami nagy újítást), amelyek nem is jelentenek nekik jelentős nagy terhet, viszont ezt nem tudják követni az elavult kódokra épülő csomagjaikkal. Ez volt az egyik tényező, amiben az AMD a gondot látta, és mára teljesen újjáépítették a meghajtót.
A másik tényező az volt, hogy hogyan kerüljenek be a fejlesztők gépeibe. Na ez egy nehezebb ügy volt, de itt alapvetően kihasználták azt, hogy az általánosan licencelhető motorok Vulkan API-ra váltanak. Ez egyrészt jó, de vannak olyan tényezők, amelyek nehézséget jelentenek. Például az, hogy a Vulkan API-hoz nem igazán van jól működő általános profilozó. Olyan semmiképpen, amely meg is mutatja a wave-ekre vonatkozó kihasználtságlimiteket. Ez baj, mert enélkül nem lehet a mai SIMT architektúrákra optimalizálni. És persze a konzolról át tudod valamennyire emelni a kódokat, de egyrészt mi van akkor, ha egy játéknak nincs konzolportja, másrészt azért nem egy ideális workflow egy PC-s játékot a konzolra lefordítani, az alapján optimalizálni, majd visszaportolni PC-re. Itt történt a másik váltás az elmúlt években, hogy a profilozók helyzete nagyon ramaty PC-n. Az AMD azt csinálta, hogy beleintegrált egy explicit API-hoz való profilozót a driverbe. Ilyet korábban senki sem csinált, viszont így egy külön csapat csak azon dolgozik, hogy amit az adott driver tud, ahhoz már legyen egy működő profilozó is azonnal. Egyszerűen csak aktiválni kell a devmódot, és ennyi. Ez az a pont, amiért a Unity és az UE4 fejlesztését átvitték Radeonra, mert így gyakorlatilag nincs szükséged a konzolokra ahhoz, hogy PC-re optimalizálj. És ez azért nagyon fontos, mert a Vulkan már elérhető egy jó ideje, de még ma is kizárólag az AMD kínál olyan profilozót, amivel tudsz kihasználtságlimitet elemezni. Ha GeForce vagy Intel GPU-t használsz, akkor ehhez a munkához szükség van egy X1-re vagy egy PS4-re.
Szóval alapvetően az AMD ebben a két dologban látta a problémát. A driver természetesen a saját portájuk volt, nyilván nem egy iparági gondról beszélünk, de persze számít, hogy a legacy kódok miatt mennyi pénzt égetsz el, amit el lehetne költeni hasznosan is. Viszont a profilozók helyzete egészen elhanyagolt, és ez már iparági léptékű jelenség.Volt egy harmadik tényező is, ami a kínai piac, kifejezetten az internetkávézók nézőpontjából, mert ott aztán van kereslet. Talán kevesen tudják, de a HiAlgót csak emiatt vették meg. A Chill kellett hozzá, hogy levigyék a fogyasztást igen alacsony szintre, miközben még javítják is a input lagot, illetve a látott élményen nem rontanak észrevehetően, ami a kínai internetkávézók kritikus szempont. Az persze más kérdés, hogy ha már kész volt a rendszer, akkor belerakták a normál driverbe is, de az üzleti döntés nem ez volt mögötte. Csak a végfelhasználói piacnak nem érte volna meg lefejleszteni. Nemrég ugye direkt erre jött hardver, csak az internetkávézóknak, és elég nagy az érdeklődés is, mert 100 gépnél már jócskán le tud faragni a villanyszámlából ez a funkció.
-
Abu85
HÁZIGAZDA
válasz
lezso6
#36004
üzenetére
Ha az ütemezést leszámítjuk, akkor kb. igen.
A skalárfeldolgozó igazából implementációs szabadságot biztosít leginkább. A jelenlegi API-kban az AMD azért érzi jól magát, mert benne van ez az egység a hardverbe, így nem kényszerülnek arra, hogy állandóan módosítsanak az implementációkon. Egyszerűen minden programozási eljárás alatt működik a hardver.
Hát, az igazából nem nagy különbség, hogy most vektormotort használ a hardver, vagy különálló streaming ALU-kat. A működési elv így is lényegében ugyanúgy SIMT.
(#36013) t72killer: Nagyon pici az az esély. Ha kiadás előtt nem léptek 4.20-as verzióra, akkor annak valami olyan akadálya van, ami túl drágává teszi a motor frissítését. Sok függ attól, hogy mennyire nyúltak bele.
-
Abu85
HÁZIGAZDA
válasz
t72killer
#35997
üzenetére
Ez azért van, mert az egyik legrégebbi UE4 verzió volt az alap, tehát alapvetően a technika alatta majdnem fél évtizedes. Ha mondjuk frissítenének 4.20-as verzióra, akkor sokkal jobban nézhetne ki, de nem tudom, hogy mennyi minden nem kompatibilis a játékukban az új UE4-gyel.
Ezeket érdemes figyelembe venni, mert az UE4 jelenthet igen régi kódbázist, vagy nagyon modernt is, utóbbi sokkal gyorsabb és sokkal jobban is néz ki. -
Abu85
HÁZIGAZDA
válasz
lezso6
#35970
üzenetére
Ez azért nem olyan pontos. Az ütemezés valójában egyik architektúrában sem 100%-ban hardveres, valamekkora mértékben van befolyása a drivernek is rá. A különbség annyi, hogy az NV a Keplerben sok dolgot átrakott szoftverbe, amit lassan visszaépítenek hardverbe. De ettől nem lesz teljesen hardveres.
Az LDS/L1 esetében is vannak elég nagy különbségek. A nyers számok önmagukban nem jelentenek sokat, mert a gyorsítótár elérése lehet lassú vagy gyors is. Emellett azért a Turing és a GCN manuális interpolációt használ, ami szintén az LDS-be lesz mentve, illetve a GCN-nél is csak a Vega, ami képes is használni a 64 kB-ot, míg a többinél ez 32 kB-ra volt statikusan korlátozva. Emellett itt még bejön a prefetch, mert az sem mindegy, hogy van-e előbetöltés, vagy nincs.
-
#35963
Abu85
HÁZIGAZDA
Petykemano
#35960
Abu85
HÁZIGAZDA
válasz
Petykemano
#35960
üzenetére
Rajanak ehhez semmi köze, ő nem igazán a grafikai divíziót vezeti az Intelnél, hanem a peremhálózati rendszerek menedzsere, amellett persze, hogy az alelnöke a "Core and Visual Computing" csoportnak, illetve a vezető mérnök.
Akik mennek (Darren McPhee, Tungler Antal, stb.), Chris Hook után mennek. Gondolom az AMD sem nagyon akarta marasztalni a "Mr. Poor Volta" teamet.Raja Gregory Stonert vitte magával, ő felelt az AMD-nél a ROCm-ért. Eközben viszont probléma volt, hogy le se szarta a SYCL-t, és emiatt az AMD több embere elment más céghez, hogy foglalkozhasson a SYCL-lel. Valószínűleg emiatt őt se nagyon marasztalta a cég, hiszen nem túl célravezető stratégia csak csőlátásban a ROCm-öt tolni.
Hardveres és driveres arcok maradtak az AMD-nél, őket nehéz robbantani onnan.
-
#35680
Abu85
HÁZIGAZDA
huskydog17
#35679
Abu85
HÁZIGAZDA
válasz
huskydog17
#35679
üzenetére
CPU. A VGA-teszt párhuzamosan ment. Ott 1080p, 1440p és 4K lesz. Viszont a CPU-tesztben látottak miatt átváltottunk Ryzen 7 2700X-re. Meg eleve gyorsabb a nyolcmagos Haswellünkhöz képest, és jövőre csak procicserével megoldható a 16 mag, tehát sok szólt a váltás mellett.
Úgy jön ide, hogy nem csak az RTX 20 jelent meg, hanem ugye jöttek CPU-k is. Az most más kérdés, hogy szívás, hogy mindet ideöntötték a gyártók gyakorlatilag ugyanakkor, de ez van.
Az a baj, hogy a mi játékainkkal abszolút nem látszik Full HD-ben a CPU-limit. Egyszerűen annyira máshogy skálázódnak a játékaink motorjai, hogy az lenne, ami a korábbi tesztekben, felsorakoznak a procik egymás alá. Persze választhatnánk nem túl jól skálázódó játékokat, ahogy a CB, de most 6-8 magos procikról van szó, pont a skálázódás a lényeg.
Ha kiadom a sajtótermék nevét, akkor tudod a személyt. De amúgy ezek közül egyik sem.
Voltak nagyobb különbségek is. Nem szimpla felsorakozás.
-
Abu85
HÁZIGAZDA
válasz
Raymond
#35673
üzenetére
De azt azért tudod, hogy alig tesztelünk DX11-es játékkal? Ez a múlt, mi pedig sosem kergettük a múltat. Írtam, hogy DX11-ben ez a probléma nem létezik, csak DX12 és Vulkan API-val jön elő. Itt is úgy néz ki, hogy azokban a motorokban, ahol nem épít a program root/layout leírókra. Legalábbis ezeket szűrjük le abból, amilyen eredményeket mi mértünk, illetve kaptunk ellenőrzésképpen.
Eleve nem tudjuk, hogy mi a probléma. Elképzelhető, hogy függ a Windows 10 októberi frissítéstől, vagy a 2080 Ti hozza elő, mert Pascallal nem tudta még megnézni senki. Mi sem. Csak annyit látunk, hogy az Intel processzorok 2080 Ti-vel, HD felbontásban, főleg Hyper-Threadinggel nem működnek jól. Ellenben a Ryzen kifogástalan. Nem tudjuk miért, de a Hyper-Threadinges dolgot RTX 20-ra más is jelezte. Persze talán nem volt szerencsés alig működő driverrel rendelkező GPU-val mérni, de a mérések előtt honnan tudhattuk volna, hogy valami gubanc lesz?
(#35674) huskydog17: Írsz nekik és kész. Mondtam. Nem zavar, ha válaszolnak, de én nem rakom ki a magánlevelezéseket. Nem érdekel, hogy nem tetszik, én sem örülnék, ha egy másik média munkatársa kiadná, hogy írt xy ügyben nekem, és beszélgettünk. Ez ránk tartozik, de ha mással beszél az ügyben, az szabad.
Senki sem mondta, hogy Full HD alá fog menni a játékos, de múltkor arra panaszkodtak az olvasók, hogy miért tesztelünk magas felbontáson procitesztet, ugyanis itt nincs köztük különbség. Most visszatértünk a régi modellhez, hogy akkor hozzuk ki a különbséget. De ha ez sem jó, akkor most már döntsétek el, hogy mi legyen.
Kérdés mit értesz engine limit alatt. Pár százalékot arra fognék, de nem 40%-ot. Vagy az Intelre külön be van írva, hogy alacsonyabban legyen az engine limit?
-
Abu85
HÁZIGAZDA
válasz
NewHope88
#35665
üzenetére
Az a baj, hogy sehol sem tesztelnek Full HD alatt. Ahogy mész a GPU-limites beállítás felé, annál kisebb a probléma hatása. Emellett nagyon fura, hogy nem minden játékban jelentkezik. Ahogy eddig kivettük leginkább azok a motorok érzékenyek rá, amelyek az explicit API-nál nem építenek a root/layout leírókra. Az is tök fura, hogy DX11-ben semmi jele a problémának. A RotTR pedig egy elszigetelt eset, ez a játék ugye kapott egy Ryzen patch-et, és az abba épített optimalizálásokat nem portolták vissza Intelre. Nyilván gyorsabb kódból gyorsabb egy proci, tiszta sor.
-
#35664
Abu85
HÁZIGAZDA
huskydog17
#35662
Abu85
HÁZIGAZDA
válasz
huskydog17
#35662
üzenetére
Magánlevelezésekre vagy kíváncsi. Kérdezzél rá egyenként a tesztelőknél. Olvasod a tesztjeiket. Ha ők elárulják neked, akkor nekem oké.
Egyrészt mi 1366x768-ban teszteltünk és 2080 Ti-vel. És még a Ryzen 5 2600 is nagy falat volt az i7-8700K-nak. Persze addig, amíg le nem tiltottuk a HTT-t. Utána rendbe is jött. De majd elolvasod a tesztben.
-
#35660
Abu85
HÁZIGAZDA
huskydog17
#35659
Abu85
HÁZIGAZDA
válasz
huskydog17
#35659
üzenetére
A játékosok közül nem sok embert érint. Ahogy mész a GPU-limites beállítás felé megszűnik a gond. Nekünk ez a CPU-tesztnél ütött nagyon szemet, mert ott HD-hez közeli volt a felbontás, és az CPU-limites beállítás több játékban is. Azt sem tartjuk alapvetően kizártnak, hogy az egészhez köze van az októberi Windows 10 frissítésnek.
Várd meg a CPU-tesztünket, ott ki lesz elemezve. A VGA-tesztet a biztonság kedvéért átraktuk Ryzenre, nem akarjuk, hogy emiatt az esetleges hátrány halvány esélye is felmerüljön a GeForce-okon. Lövésünk sincs, hogy miért viselkedik néha furán Intel procin a driver, így inkább nem kockáztatunk.
-
Abu85
HÁZIGAZDA
válasz
Raymond
#35647
üzenetére
A világ nem fekete-fehér, még akkor sem, ha ezt egyeseknek nehéz elképzelni. Attól, hogy valaki nem felkészült, még nem szükségszerűen hülye. Joker csak azt publikálta, amit mért. Az, hogy nem gyanakodott valami gondra a háttérben, és nem ellenőrizte az eredményeit, maximum jóhiszeműségre, illetve általános tapasztalatlanságra vall, de ettől nem lesz kötelezően hülye vagy troll. Szerintem eleve betegesen szélsőséges világlátás kell ahhoz, hogy ezt mondjuk valakire, aki csak videókat tölt fel a Youtube csatornájára.
-
Abu85
HÁZIGAZDA
válasz
Raymond
#35645
üzenetére
Pont a bla-bla-bla a lényeg.
Akivel kapcsolatban vagyok és kapott RTX 20-at. Egyszerűen nem tartottuk túl normálisnak, hogy a Hyper-Threading bizonyos játékokban, bizonyos beállításokkal, bizonyos magszám mellett és bizony órajelszinten csökkenti a teljesítményt. Emiatt ahol tudtam utánakérdeztem, hogy találkoztak-e ilyen furcsasággal. Minő véletlen találkoztak, de nem tudták hova rakni. Mi se, de legalább nem vagyunk egyedül. Arra próbálok rávilágítani, hogy a Joker Production is ebbe eshetett bele. Emiatt nem feltétlenül kell rögtön letrollozni egy embert, aki amúgy valószínűleg sokat tesz abba, hogy YouTube videókat készítsen a hardverek teljesítményéről, ugyanis lehet, hogy nem az ő hibája az, hogy az RTX 2070 nála nem teljesített. Vagy egy másikat, mert teljesítménycsökkenésről számol be a 399-ről 415-os driversorozatra váltva.
Mint írtam, ha nálunk problémamentes lenne a 416.33, vagy nem kaptam volna visszajelzéseket furcsaságokról, akkor azt mondanám, hogy az ő hibájuk, de így azért sanszos, hogy a driverrel nem stimmel valami. Hogy mi azt nem tudom, de van pár konfiguráció és szituáció, ahol nem azt hozza, amit kellene. Ezek a legrosszabb bugok, mert túl specifikusak ahhoz, hogy a kiadást megelőző teszten elkaphatók legyenek. Idővel persze úgyis kiszűrik, aztán lehet újratesztelni mindent.
-
Abu85
HÁZIGAZDA
válasz
NewHope88
#35642
üzenetére
Úgy egyszerű, hogy kapnak is hardvert, nem kell utánarohanni. Az a régió, ahova Magyarország tartozik nem célpiac. Ezt korábban kifejtettem már. Ilyenkor meg kell várni, hogy az NVIDIA partnerei hozzanak motyót.
(#35643) Raymond: Ja, csak éppen gyenge 4,7 GHz-re tuningolva, amire írtam, hogy nem mindegy a probléma szempontjából.
A helyzet az, hogy senki sem lóg ki a sorból. Másokkal is beszéltem erről, és hasonló furcsaságokról számoltak be. A különbség az, hogy a komolyabb médiáknak van lehetősége 5 GHz közelébe lőni a hatmagos prociját, vagy berakni egy nyolcmagos Intelt, esetleg váltani Ryzenre, míg valakinek van egy szem i7-7700K-ja, és abból él. Mit csináljon? Akassza fel magát? A bizniszt attól még pörgetnie kell, hogy a driver furán viselkedik.
Nem is tudom mi köze van hozzá... A 415-os sorozat tempóvisszaesését mutatja a videó egy Hyper-Threadinges procival egy 399-es driverhez képest. Nálunk furán viselkedik Hyper-Threadinggel a 416.33. Fura eredmények jönnek ki a Joker Productionnak egy Hyper-Threadinges procival. A saját eredményeinket látva, más médiát felkeresve hasonlók adatokat kaptunk. Áhhh... biztos csak véletlen, illetve "közismert trollok".
Amúgy félreértés ne essék valóban nem azt hozza Jokernek a 2070, amit kellene, de abban kételkednék, hogy ez 100%-ban az ő hibája. Ha nálunk nem lennének fura jelenségek a 416.33-mal, akkor elhinném, hogy troll, de most inkább azt hiszem, hogy van egy picike bugocska a driverben.
-
Abu85
HÁZIGAZDA
válasz
Raymond
#35639
üzenetére
Alapvetően nincs baj vele, csak vannak olyan fura szituációk, amikor egyszerűen lassít a Hyper-Threading. Nem minden játékban, nem minden beállításon, de valami gondja van. És ez látványosan kiütközik, ha a procinak nincs legalább nyolc magja, aktív a Hyper-Threading, nincs nagyon meghúzva, illetve Full HD vagy ez alatti a felbontás, de sajnos a gond WQHD-ben is mérhető. Fingunk nincs mi okozza, de a lassulás a Hyper-Threading kikapcsolásával megszűnik, vagy akkor, ha nyolcmagos az Intel proci, illetve hat maggal legalább 4 GHz fölé van húzva alapból. Biztos valami szoftveres probléma, mert túl specifikusan lép fel ahhoz, hogy a hardver okozza.
Azt se tudjuk, hogy szimplán az Intel proci mennyit árt. Az biztos, hogy Ryzennel mérhetően jobban érzi magát a 416.33. Lehet, hogy csak picit, de a 2080 Ti VGA-val a Ryzen egyeduralkodó lett a CPU-s game tesztekben, holott nem ez volt korábban a kialakult kép. Valami nem tiszta még a 2000-es GeForce-ok és a 415-ös driversorozatnál. Mondjuk mindegy, most ebből kell élni, de azért a VGA-tesztet átraktuk Ryzenre, hogy ott menjenek az új GeForce-ok, ahol jobban érzik magukat.
Ilyen szempontból viszont aki mondjuk nem tudja a 7700K-t lecserélni a teszthez, talán a Joker Production, akkor sajnos beleütközhet a problémába. Tehát nem 100%-ban az ő hibája ez. Sajnos új a hardver, új a meghajtó, lehetnek benne fura bugok. Egy-két hónap múlva jó lesz. Szóval nem tegyünk úgy, hogy először látunk helyenként nehezen értelmezhető teljesítményt az új VGA-któl. Az a ritka, ha minden rögtön flottul megy.
Az sem feltétlenül lehet vétetlen, hogy a Youtube-on megjelentek a videók, amelyek a 415-ös driversorozat lassulását mutatják. Például ez: [link] - hatalmas meglepetésre Hyper-Threadinges a procija.
-
Abu85
HÁZIGAZDA
válasz
Raymond
#35635
üzenetére
Vagy csak az a problémája, ami nekünk a 415-ös driversorozattól. Bizonyos játékokban, bizonyos beállításokkal az aktív Hyper-Threading 6 maggal vagy alatta, normál órajelen lassít. Full HD alatt látványosan megmutatkozik a probléma, Hyper-Threading off és rögtön jön a tempó a 2080 Ti-nek. A VGA tesztgépnél húztunk is Ryzenre, hogy alapvetően ne legyen gond, mert furcsa mód az AMD SMT-jével semmi baj nincs.
-
Abu85
HÁZIGAZDA
válasz
keIdor
#35604
üzenetére
Ez ilyen. Hiába "turn up the light and just works" jellegű a dolog, azért a tartalom szempontjából igazodni kell hozzá, és a nem igazodsz, akkor néhol túlságosan fura jellege lesz az egésznek. Márpedig egy játék kiadás előtt pár hónappal nem fogják a újrakreálni a tartalmat, hogy egy effekthez jobb legyen. Örülnek, ha befejezik a fejlesztést időre.
(#35606) t72killer: Amiatt hibázna máshol is, de csak a Wolfi 2-re jellemző, ott is ritkán. Szerintem valami apró szoftveres gebasz lesz, csak nem tudni, hogy a driver vagy a játék.
-
Abu85
HÁZIGAZDA
-
Abu85
HÁZIGAZDA
Abból is.
Új konzolok még sokáig nem lesznek, és azokra sem úgy fognak átállni, hogy dobják a régieket. Tehát nagyjából 5 év múlva jön olyan Assassin's Creed, amiből már nem lesz PS4 és X1 port, vagyis tényleg lehet az új konzolokra tervezni.
Egyébként nem csak jövőre nem lesz új AC. Egy csomó kiegészítés lesz most legalább két évig. Ez még abból a szempontból is érdekes, hogy ilyen munkafolyamat mellett kialakítható lenne egy tényleg használható multiplayer. A játékban megvan erre a lehetőség, csak a sok rész tervezése mellett rendkívül kevés erőforrást kapott mindig is. -
#35373
Abu85
HÁZIGAZDA
huskydog17
#35372
Abu85
HÁZIGAZDA
válasz
huskydog17
#35372
üzenetére
Mert a primitive shaderre kérdeztek rá, amire azt válaszolta Corpus, hogy mostanában jönnek majd a játékok.
Az Assassin's Creed azért van képben, mert eleve a primitive shaderre az ötletet az Assassin's Creed Unity adta. Az ugyan compute shadert használt, de a primitive shader nem sokkal másabb, mint az Ubisoft által kitalált pipeline némileg hardveres formába öntve. Emiatt alakult át az új AnvilNext, ami az Odyssey alatt dolgozik, és emiatt kér kevesebb CPU-t, mint az Origins. Viszont az átalakítást hardveresen csak akkor lehet megtámogatni, ha lesz hozzá driver. Az Ubi ezért vitte eleve az Odyssey-t az AMD-hez, mert amit a Unity-ben régen kitaláltak, azt végre át akarják ültetni compute-ról hardveres szintre. Ez az ő ötletük, nyilván roppant módon örülnek, hogy van hardver is az ötletükre, és előbb-utóbb ki akarják használni.
A másik, hogy lehet erről még nem beszéltek, de az Odyssey nem igazán egy játék. Erre az Ubisoft egy alapként tekint, és 2-3 évig is ez lesz AZ!! Assassin's Creed. Tehát nem jön új cím, hanem tartalmat kap az Odyssey, évente többet is, méghozzá igen sokáig. Ez egy újszerű modell, mert érdemes kipróbálni, hogy mi a jobb. Évi egy AC, vagy egy AC több évig, és akkor annak a fejlesztése, kb. úgy, ahogy egy MMO-nál szokás. Ezt több forrásból is hallottam már.
-
#35369
Abu85
HÁZIGAZDA
huskydog17
#35367
Abu85
HÁZIGAZDA
válasz
huskydog17
#35367
üzenetére
Nem az AMD választotta az Ubisoftot, hanem az Ubisoft az AMD-t. Az előző évben az Ubi kötött egy megállapodást, hogy mindhárom IHV-nek megadják a lehetőséget, hogy dolgozzanak egy-egy címen. Ez döntötte el, hogy kivel lépnek partneri viszonyba. Az NV dolgozott a Ghost Recon Wildlandsen, az Intel az Assassin's Creed Originsen, míg az AMD a Far Cry 5-ön. A Far Cry 5 tetszett a legjobban az Ubinak, így az AMD maradt talpon. Eredetileg is az AMD címe lett volna a Assassin's Creed Odyssey, hiszen ennél dolgoztak a primitive shaderen. Ugye Richie Corpus a TGS-en mondta, hogy a primitive shaderes játékok mostantól jönnek, erre gondolt. De ugye ez nem működik automatikusan, kell hozzá a driver, hogy ez a fejlesztés aktív lehessen.
A korábbi döntés a jövőre érkező játékokat változtatta meg. A Divisiont például elvették az NV-től, és megkapta az AMD, illetve van még egy PC-re be nem jelentett űrhajós cím, amin az Intel dolgozott volna, de végül nem ők fognak. Ennek a PC-s portja el lett tolva. -
-
Abu85
HÁZIGAZDA
válasz
Crytek
#35342
üzenetére
A CPU-val nem lesz baj. Kevesebbet kér, mint az Origins, mert teljesen átrakták a cullingot GPU-ra. Ezzel a korábbi rendszer akadásait is eltüntették, de emiatt erősebb a GPU oldali terhelés, mert DX11-ben nincs aszinkron compute, ami itt nagyon kellene, illetve még nem érkeztek meg azok a meghajtók, amelyekkel a beépített újításokat aktiválhatják. Erre még heteket kell várni. Nagy kérdés, hogy ez hogyan fog működni, mert ilyet még soha senki nem csinált.
-
#35326
Abu85
HÁZIGAZDA
zovifapp111
#35308
Abu85
HÁZIGAZDA
válasz
zovifapp111
#35308
üzenetére
Nem teljesen ugyanannyit ér a VRAM más Resource heap szinten. Itt magának a játéknak nem igazán kell 2 GB-nál több VRAM, de egy Tier_1-es beállítással sokkal jobban szemetel, mint a Tier_2-essel, emiatt GeForce-on inkább 6 GB az a limit, ami kb. kezd jó lenni, míg Radeonon 4 GB-hoz közeli, de itt annyira a határon van, hogy számít a DCC hatékonysága is. Emiatt jók 4 GB-tal a Polarisok, és kevésbé az a többi Radeon.
Jó, hát ez az első játék, amit már dizájnban is a legmagasabb Resource heap és Resource binding szintekre optimalizáltak, tehát alapvetően természetes, hogy nem hozza a megszokott sorrendet, ahol messze nem volt ennyire extrém a terhelés az API felé.
(#35306) FLATRONW: Valamennyi optimalizálási lehetőség van a driverben is, de közel sem annyi, mint régen. Az a baj, hogy nagyban meghatározza ezeket a lehetőségeket az is, hogy az alkalmazást hogyan írták meg. Mennyire követték a Microsoft ajánlásait, ami például köztudottan rossz az NV-nek (kivéve a Turingnak), és innen nagyon nehéz kiszakítani a rendszert, mert csak szívnának vele, amikor jönnek a patch-ek a játékhoz. Nem véletlen, hogy a Turingot már a Microsoft ajánlásaihoz tervezték, elvégre nem mindig van lehetőség az NV saját ajánlásaihoz írni egy játékot.
-
Abu85
HÁZIGAZDA
válasz
lezso6
#35298
üzenetére
Meg másképpen is csinálják, ahogy az AMD. De a Turing esetében már jó. Ott az AMD-hez hasonló az NV megoldása is. A Pascal és a régebbi hardverekkel van gond csak. A Turing persze abból a szempontból nem szerencsés, hogy még eléggé kezdetleges az implementáció, elvégre ehhez a hardverhez megint egy új csomagot használnak.
-
#35073
Abu85
HÁZIGAZDA
Petykemano
#35071
Abu85
HÁZIGAZDA
válasz
Petykemano
#35071
üzenetére
Igen. De mint írtam, a hardveren belül ez egy kis áramkört igényel, plusz egy extra hardverállapotot. Tranzisztor szintjén nem igazán lehet több százezernél, ami elenyésző a mai sokmilliárd tranyós lapkáknál. Ilyenkor többet jelent a tesztelhetőség, mint a tranyóval való spórolás, mert ha először van hardvered rá, akkor először tesztelheted, és elsőként is jössz rá olyan limitekre, amelyek a második generációnál számítani fognak. A DX12 és a Vulkan API-ra sem azért az írja az AMD a leghatékonyabb drivereket, mert náluk okosabbak a programozók, hanem azért, mert nekik volt egy Mantle-jük, és mindenki előtt két évig tesztelhették, hogy mi az ideális stratégia erre. Bizonyos projekteknél fontos az idő, mint tényező, amikor egy újítást teljesítményét nem olyan nehezen befolyásolható tényezők határozzák meg, mint a compute, vagy a memsávszél. Utóbbi két esetben nyilván nem sokat lehet nyerni az idővel, hiszen eleve egy olyan tényező limitál, amivel nehéz mit kezdeni az általános fejlődésen túl. Egy primitive shader olyan dolog, amit nem igazán a compute vagy a sávszél fog limitálni, hanem sokkal inkább a szoftveres háttér, illetve a hardverállapotra vonatkozó optimális paraméterezés. Itt az idő sebességet jelent.
-
Abu85
HÁZIGAZDA
válasz
imi123
#35066
üzenetére
Másképp ezt aligha lehet megoldani. Ha a Khronos és a Microsoft nem vevő erre, akkor az egyetlen opció a Mantle átírása, mert az még egy elfekvőben lévő modern grafikus API, aminek lehet módosítani a grafikus futószalagját, elvégre az AMD kezében van a specifikáció. De amúgy a Khronos és a Microsoft miért ne lenne vevő erre? Persze a szabványosítás miatt ez egy kicsit időbe kerül, hiszen nincs semmiféle szoftveres fallback, de alapvetően a Vega és a Turing adott, amint megegyeznek a specifikációban a többiek, akkor szállítható rájuk egy alternatív grafikus futószalag. Meg ugye azokra a hardverekre is, amelyek még támogatni fogják. Hardveres szinten ez nem egy nagy varázslat egyébként, csak egy extra hardverállapot az egész, illetve egy kis extra áramkör a setupban (ami rém egyszerű is), de feldolgozók gyakorlatilag ugyanazok maradnak, ahogy eddig is.
-
Abu85
HÁZIGAZDA
válasz
imi123
#35062
üzenetére
Befizetni bárki be tudja. Az API-kkal van a baj. Nem engedik meg a futószalag ilyen mértékű módosítását egy szimpla kiterjesztésen keresztül. Szóval meg kell várni amíg a Khronos és a Microsoft kihozza azokat az API-kat, amelyek ezeket az újításokat már kezelik a futószalag szintjén is. Ez valószínűleg annyira nem lehet messze, ha az AMD-nek és az NV-nek is van már rá hardvere. Az eléggé valószínűtlen, hogy a két cég egymás, és az API-kat fejlesztő konzorciumok tudta nélkül csinált tök hasonló fejlesztéseket. Sokkal inkább esélyes, hogy már régóta megy ezekről a diskurzus a háttérben, és a Vega, illetve a Turing architektúra ezek hardveres alapján elkezdte bevezetni. Az csak pech, hogy ezek olyan módosítások, amelyek az amúgy eléggé érinthetetlen grafikus futószalagot módosítják, és ezekre nem reagált még a Khronos és a Microsoft.
-
Abu85
HÁZIGAZDA
Nyersen a számok alapján több a különbség, mint amit a 7-es és a 8-as mutat a nanométer előtt. De egy teljes lapka azért nem csak ezen múlik, sőt, ma már egyre kevésbé függ ettől. Szerintem az van, hogy az AMD és az NV is a legjobb nem EUV-s node-ot keresi. A TSMC viszont nehézkessé vált, mert ott a Qualcomm, az Apple, a HiSilicon, stb. Az NV-nek ez csupa olyan cég, amely ráígérhet az ajánlataikra, még az AMD is, hiszen nekik ott a marha nagy haszonnal árulható EPYC, ami még nagy piacot is céloz. Emiatt érdeklődhetnek inkább a Samsungnál, ahol a 8 nm-es opció a legjobb nem EUV-s node, és jóval kisebb a verseny a gyártókapacitásért.
Jó, de ezt nem értetek csinálják. Amikor a döntéseket meghozzák, akkor a legfontosabb szempont a legnagyobb haszon.
Valószínű, hogy az EUV elkerülhetetlen, de jelenleg úgy értékelhetik sokan, hogy még túl rossz hatásfokkal működhetnek a gépek, aminek a költsége ugye benne lesz a waferáraban. Talán másfél év múlva jobb lesz a helyzet. Igazából az NV nem kockáztat nagyot, hiszen a Samsungnál is van 7 nm-es EUV. -
Abu85
HÁZIGAZDA
Lehet, hogy nem a TSMC lesz az NV fő partnere a jövőben. Azt pletykálják, hogy a Samsung 8 nm-es node-jára utaznak, ami a 10 nm-es half node-ja. Bár nem új generációs node, mint a 7 nm, de sokkal olcsóbb rajta gyártani. Szvsz a 7 nm-t túl drágának tarthatják, főleg EUV-vel.
Szerk.: Extra érdekesség, hogy úgy néz ki a Navi sem az EUV-s 7 nm-t használja a TSMC-nél, hanem az EUV nélkülit, amit a Vega 20.
-
Abu85
HÁZIGAZDA
válasz
imi123
#34996
üzenetére
A konzol még mindig jelentősen másképp működik, mint egy PC. Akármennyire is megold dolgokat a DX12 és a Vulkan, nagyon messze vannak attól, amire egy konzol képes a legalacsonyabb szintű hozzáféréssel. Az Explicit API tehát csak segít a régi limitek feloldásában, de nem viszi le az elérést konzolszintűre. Azt nem lehet megcsinálni fix hardver nélkül. Meg ugye az Xbox One konzolokban is vannak olyan trükkök, mint a dupla parancsmotor, ami a PC-s hardverekben nincs, illetve az Xbox One X-ben a CPU ki van egészítve olyan fixfunkciós blokkokkal, ami egyszerűen tipikus grafikai szempontból fontos munkákat gyorsít. A PC-s processzorokból ezek is hiányoznak. Lehet, hogy egyszer lehozza ide a Microsoft ezeket, de amíg konzolon csak a saját hardverednek kell megfelelni, addig PC-n egyeztetni kell az összes gyártóval egy esetleges szabványról, mert anélkül csak állna a tranzisztor ebben a hardverben.
(#34997) imi123: Nem tudni. Annyira speciális a konzol, hogy akármit választhatnak rá a cégek. Szerintem a 7 nm már nem hoz annyit, hogy ezt erőből csinálják, ahogy mondjuk PC-n, szóval úgy gondolom, hogy a next-gen már igen sok olyan módosítást vihet a hardverbe, amelyek egy-egy tipikus feladatot gyorsítanak. Már a PS4Pro és az X1X esetében is egyre kísérletezőkedvűbb volt a Sony és a Microsoft, így megpakolták őket saját IP-kkel, amik sehol sem találhatók meg. Mivel ezt az AMD különösebb gond nélkül megoldotta, így szerintem a következő konzoloknál még több saját IP-t építenek be, vagyis még inkább egyediek lesznek a dizájnok. Ezzel azért a 7 nm mellett sokat lehet nyerni, mert arányaiban a fixfunkciós blokk a leghatékonyabb. Konzolon ez nem is probléma, fix a hardver, arra szabják a játékokat.
-
Abu85
HÁZIGAZDA
válasz
imi123
#34992
üzenetére
Nem azért lett fontos a proci, hanem azért, mert egyre több az explicit API-t nem csak használó, hanem kihasználó cím. Világos volt, hogy amikor ezt bevezették, akkor az volt a cél, hogy a többmagos rendszereket elkezdjék használni. Az Intel is hozza a mainstream nyolcmagosát, tehát nem egyedi dolog az, amit az AMD csinál. A következő szint majd a 16 mag lesz. Az Intel is nyomná ezt már 2019-ben, ha meglenne hozzá a gyártástechnológiája
-
Abu85
HÁZIGAZDA
Pont az, hogy ott nem limites. Direkt megnézettem egy Threadripperrel rendelkező emberrel a Forza Horizon 4 demóját, mert furának tűnt, hogy az AMD négymagossal teszteltette. Egy 16-magos Threadripperrel már a vizes Vega 64 nyakán volt az 1080 Ti még 1080p-ben is, nem kellett hozzá 4K. Szimplán 8-magos procival az 1080 Ti inkább a Vega 56-tal van pariban. Eközben a 4K-s eredmények nem változnak az extra nyolc magtól. Ez klasszikus CPU-limit. Azt is lehet tudni, hogy miért. Az NVIDIA aktuális DX12 implementációja a Tier_3-as bekötést nem támogatja hardveresen, de megoldják egy CPU oldali implementációval. A Microsoft ezt nem tiltja, alapvetően az Intel is így csinálja, csak ők az L3 cache-t is bevetik. Haszna ennek eléggé sok van, csak több processzorerőt igényel, de az NV többször utalt már rá a konferenciákon, hogy hosszabb távon többet nyernek ezzel a megoldással, mintha a hardvereikre szabott Tier_2 szintet használnák még ma is, na meg sok lehetőség van trükközni is. És alapvetően ez logikus, elvégre iszonyatosan megfizethető kategóriába kezdenek süllyedni a hat-nyolcmagos procik, és fél év múlva 16-magost is vehetsz mainstream foglalatba. Tehát amíg mondjuk ma még egy picit probléma számukra, az már holnap nem lesz az, és eközben élvezik a legmagasabb bekötési szint előnyeit. Emellett tudják nagyon jól, hogy a média úgyis a legjobb procical fog tesztelni, ahogy itt a Ryzen 3000, rárepülnek a 12-16 magra. Ezt megtanulták a DX11-es érából, hogy hiába kezelték jobban a deferred contextet, annak igazi haszna nem volt, mert a tesztek 4-5 GHz közé tuningolt Core-okat használtak. Most ők kezelik rosszabbul az új DX API-t, de ennek sem lesz igazi hátránya, mert a média számára ugyanúgy nyitva lesznek a lehetőségek arra, hogy 12-16-magos procikat dobjanak a tesztplatformokba. Tehát effektíve teljesen jó, amit csinálnak, mert ugyanúgy nem éri őket hátrány a tesztekben, ahogy az AMD-t sem érte igazán a deferred contextes DX11-es játékokban. Persze pár oldal előveszi majd, hogy mennyivel hatékonyabb már az AMD DX12 meghajtója négymagos procival, amire az AMD is ráerősít, hiszen folyamatosan küldözgetik a review guide-ot, hogy egy 7700K mellett az 1070 Ti, az 1080 és az 1080 Ti egymás nyakán vannak a Forza Horizon 4-ben, és ezért az NV drivere a felelős, bezzeg a mi driverünk mennyire szépen skálázódik már négymagossal is, tehát már ott GPU-limit közelébe kerülnek, de kb. annyi haszna lesz ennek, amennyi az NV-nek volt a DX11-es drivereiből, amikor ugyanez csinálták. A GPU-tesztek ettől még izomprocikkal lesznek levezényelve.
(#34990) namaste: Magasabb felbontáson az 1080 Ti is kezd GPU-limitessé válni. De ugyanúgy eléri a Vega 64-et 1080p-ben is, csak egy 16-magos Threadripperre van szüksége. Tehát a hardver működik, ha alárakod a procit. Tényleg nem viccből nyomatja a saját review guide-ját az AMD 7700K-val. Ott még a Vega 56 sincs meg az 1080 Ti-nek Full HD-ben. Okkal választották ezt a processzort. Tudják nagyon jól, hogy az NVIDIA drivere eléggé másképp bánik a processzor erőforrásaival, így ha Ryzen 2700X-re mennek az a Vegákon nem dob sokat, de az 1080 Ti-nek számítana. Szenyók ám ezek a cégek. Ha rákérdezel, akkor boci szemekkel nyomják, hogy de a 7700K az egyik legjobb gamer proci a magas egyszálas teljesítménye miatt.
Jaja az, csak a Forza Horizon 4-nek pont nem ez kell, és ezt ők nagyon is tudják. -
Abu85
HÁZIGAZDA
Te mondod, hogy innentől kezdve a Turingra lehet tervezni. Én pedig azt mondom, hogy nem, mert az egy dolog, hogy a Turing mostantól kevésbé érzékeny azokra a dolgokra amelyekre a Pascal, tehát egy Microsoft ajánlásai szerint megírt alkalmazás hasonló hatékonysággal futhat NV-n, mint Intelen és AMD-n, de a Pascal ezt a hatékonyságot sosem fogja elérni a mostani implementációval, szóval kb. semmit sem fog változni az NV ajánlása. Kivéve persze, ha nagyon ki akarják végezni a Pascalt, akkor borzalmasan sokat tudnak rontani a hardveren, de erre egyrészt nincs különösebb okuk, másrészt elég sokan elfogadták, hogy az NV ajánlásai az AMD-nek és az Intelnek irrelevánsak, tehát amíg a Pascal tényező, addig miért is ne lenne érdemes ennek kedvezni, ha a többi másik architektúrának ez nem fáj?
Nagyon egyértelmű, hogy hol mutatkozik meg. Ha nem lenne gond a driverrel, akkor milyen hardvere az NV-nek kb. úgy futna, ahogy az új Tomb Raider alatt. Ehhez képest ha csak egy picit nem követed az NV ajánlásait, akkor a Strange Brigade már hatékonyságot veszít, noha itt azért van még egy Vulkan leképező, tehát annyira azért nem volt hely a specifikus optimalizálásnak, de ott van még a Forza Horizon 4, illetve nemrég a World of Warcraft DX12 módja, ahol annyira nem működik az NV drivere, hogy amíg Intelen és AMD-n a DX12 a default, addig NV-n a DX11. Egészen egyértelmű, hogy amíg az AMD és az Intel implementációja az esetek jó részében működik, addig az NV implementációja borzalmasan kényes.
Itt nem ellene történő optimalizálásról van szó. Azért a Microsoft nem véletlenül ajánlja azt, hogy a root signature-ben ne legyen buffer view. Ennek az oka, hogy az API-t úgy alakították ki, hogy ezeket a leírótáblákba helyezzék a fejlesztők. Emiatt egy csomó SRV és UAV nem is helyezhető direkten a root signature-be, hiába írja a saját ajánlásába az NVIDIA, hogy számukra kritikus, hogy itt legyenek ezek az erőforrások. Tehát amikor azt látod, hogy egy alkalmazás nem az NVIDIA, hanem a Microsoft ajánlásait követi, lásd a World of Warcraft DX12 módja, akkor az azért van, mert olyan erőforrás-formátumokat használnak, amiket az API el sem helyezni a root signature-ben. Szóval nem az NV-nek akarnak keresztbe tenni, hanem úgy írták meg a motort, hogy az nem igazán működik az NV ajánlásaival. És tudják nagyon jól, hogy ezzel az NVIDIA rengeteg sebességet veszít, de nem tudnak ellene tenni. Az NV valamiért a DX12 implementálásának ezt a módját választotta, biztos megvolt rá nekik is az okuk, de ez bizonyos felépítésű programoknál eléggé rossz hatásfokú. Ezzel hardveres szinten nem tudnak mit kezdeni, a meghajtót kellene valahogy átírni, hogy jobban igazodjon a Microsoft ajánlásaihoz. Ez igazából a Pascal gondjait is megoldaná, csak most vizsgáld ezt a problémát az NV szemével. Az AMD régóta eléggé kész és eléggé gyors DX12/Vulkan implementációt kínál. Az Intel gyakorlatilag utolérte őket a Vulkan API-ban, és most megint nekifogni átalakítani a dolgokat, hát eléggé necces. Ma már több szól ellene, mint mellette, inkább megéri egy rakás erőforrást beleölni a specifikus trükkökbe. Sokkal bonyolultabb lesz a driver, tesztelni is sokkal nehezebb lesz, de nem kell újrakezdeni.
A Forza Horizon 4 problémája eléggé egyszerűen kezelhető. Ott egyszerűen kell még processzormag. Jövőre jönnek a 16-magos mainstream Ryzenek. Szóval az alapvetően megoldja magát. De egy 16-magos Threadripperrel már nincs az a limit, ami a mainstream CPU-knál tapasztalható. Ott már gyorsabb a Vega 64-nél az 1080 Ti, igaz nem sokkal, de picit gyorsabb. Ezért tesztelt az AMD négymagos CPU-val, amikor kiküldték a review guide-ot. Tudják, hogy az NV DX12-es drivere több processzorerőt igényel, mint a saját driverük, ami ebből a szempontból eléggé hatékony. Nyilván nem hülye cég az AMD. Tudják, hogy ha Threadrippert toltak volna az NV alá, akkor jóval kisebb lett volna a Vega fölénye. Ezekre érdemes felfigyelni, mert az ördög a részletekben rejlik.
Mi is emiatt alakítjuk át a teszplatformot, hogy jövőre könnyen tudjunk 16 magra ugrani, mivel úgy tudjuk, hogy az NV-nél a DX12 és a Vulkan alatti nagyobb processzorigény tartós lesz. Nyolc maggal egy Forza Horizon 4 simán limites, de jövőre 16 maggal már jóval kellemesebb lesz. Erről egyébként nagyon sok duma van a háttérben, hogy a Ryzen "3000"-et az NV nagyon várja, mert erőből megoldja a driverük egyik gondját, tehát azzal nem kell foglalkozni. Emiatt sem éri meg most nekik újraírni, mert aránytalanul nagy befektetést igényelne, miközben fél évre vannak az új procik, amelyek a mostaninál sokkal erősebbek. -
Abu85
HÁZIGAZDA
Továbbra is fontos, hogy sok helyen az NV ajánlásai számítsanak, mert attól, hogy a Turing jobb az explicit API-kkal a Pascal még nem az, és ha az NV ezt leszarja, akkor simán bezuhanhat az 1080 Ti a Vega 56 alá. Szóval itt sok változás azért az NV ajánlásaiban nem lesz.
A driver pedig más lapra tartozik, ott az NV eléggé le van maradva az AMD-hez képest. Hiányzik az a két év, amivel az AMD hamarabb kezdte meg ezt az irányt, és ez abban nyilvánul meg, hogy DX12 alatt kevésbé optimális a CPU-magok használata. A Forza Horizon 4-ben sem azért van a Vega 64 alatt az 1080 Ti, mert ennyire képes a GPU, hanem mert ennyire képes a driver. A felbontás növelésével ez a CPU-limit egyre kevésbé lesz meghatározó, és azzal jön is fel az 1080 Ti. Ezzel nagyon nehéz mit kezdeni általánosan, csak trükköket lehet bevetni, ami segítségnek segítség, de nem általános megoldás. De persze érthető, hogy mi a helyzet. Az AMD aktuális implementációja három éves, míg az NV-é egy. És ebben az is számít, hogy az AMD nem nulláról indult, míg az NV igen, emiatt is cserélték le egy éve az eredeti implementációt. Csak az új meghajtó borzasztóan érzékeny lett bizonyos dolgokra, amit természetesen lehet javítani, de ez nem pénz kérdése, hanem időre van szükség.Én azt sem tartom lehetetlennek, hogy kidobják a fenébe a mostani meghajtót, és a Vulkánt szelik fel úgy, hogy a hardverhez közeli rétegét célozzák egy DX12-es köztes réteggel. Az Intel lassan erre tér át. Az AMD pedig azt csinálja már a kezdetek óta, hogy van egy absztrakció a hardver fölött, és afölé húznak API implementációt. A korábbi tapasztalatok alapján ez tök hülyeségnek hangzik, de explicit API-val ez működik, és nem valószínű, hogy a nyers sebesség itt a kulcs, hanem az, hogy gyakorlatilag mind a két explicit API igen nagy részben közös kódon fut, vagyis elég ezt fejleszteni, és a gyorsulás jön mindkét API-ra vonatkozóan. A beleölt humánerőforrás hatékonysága szempontjából ez azért nem mindegy.
Az Intel Vulkan meghajtója iszonyatosan jó lett, míg az NV most írja át. Már látszanak a változások a korábbi meghajtókból is, egy csomó "PerStageDescriptor" limit lett sokkal nagyobb az elmúlt időszakban. Ami egyébként eleve WTF volt, hogy miért nem ekkorák voltak a kezdetektől fogva, de legalább kapcsoltak. Például a maxPerStageDescriptorStorageBuffers a korábbi 4096 helyett 1048576. Ezt azért illet volna az elején is a hardveres maximumra állítani, mert az AMD is arra rakta. Ugye ez az AMD-nél 4294970000, míg az Intelnél 1200, de a kékeknél eléggé másképp működik a meghajtó. Az Intel hardveres maximuma 384 lenne, de ők trükköznek az IGP-vel közös lapkán lévő CPU-val.
-
Abu85
HÁZIGAZDA
válasz
hokuszpk
#34948
üzenetére
Szerintem egy túrót mérik le ennyi CPU-val. A teljesítményben közel állókat csak másolgatják.
(#34943) b. : Más is ezt méri: [link]
Direkt írtam cikket, hogy a Forza Horizon 4 nem úgy használja már a DX12-t, ahogy régen. A lightos korszakot lezárták. Most már erősebben belemennek az API képességeibe, és a fejlesztők szerint a mai meghajtóknak ez még probléma. Ezt lehet javítani, a kérdés a mikorra. Az NV valószínűleg specifikus trükköket dob majd be, mert arra nem hiszem, hogy van idejük, hogy eljussanak általános implementációval oda, ahol az AMD drivere tart. Sokkal később kezdték meg a munkát az explicit API-kkal, és időközben még volt kettőt hátra történet is, amikor átírták a kezdetni implementációt. Szóval itt rövidebb távon trükközni kell. Erre egyébként viszonylag sok lehetőség van még DX12-ben is, na persze nem annyi, mint DX11-ben, de vállalható.
Az Intel is egy kicsit le van maradva, de ők szerintem azt fogják csinálni, hogy szétválasztják az explicit API-k implementációját. A Vulkan driverük már olyan, hogy van egy hardverközeli réteg, illetve egy API alatti összekötés. Ide már be tudják fűzni a DX12-t is, és akkor a mostan implementációt el is dobhatják. De itt is kérdés a mikor. Bármennyire is logikusnak tűnik, nem túl könnyű fejlesztésekről van szó a gyakorlatot nézve.
Mike-nak ugyan megvan ehhez az iskolája, de a legtöbb munkahelyén leginkább gazdasági, illetve menedzseri pozíciót töltött be. Az RTG-nél is David Wang a mérnöki csapat vezetője. Ugye korábban mindkettőt Koduri vezette, de az AMD két emberre osztotta ki. Így lett Rayfield a "General Manager", míg Wang az "Engineering" fejes, miközben mindkettő titulusa Senior Vice President volt. Ennek valószínűleg az volt az oka, hogy túlzottan sok munka a pozíció egy embernek, illetve talán az is közrejátszik, hogy Wangról azt hallottam, hogy talán az egyik legnagyobb koponya a világon mérnöki szinten (ez igaz lehet, elvégre 25 éve lapkákat, meg GPU-kat tervez), de gazdasági szempontból nincs azért a toppon.
Erre vigyázni kell, mert én is ütköztem már bele ilyenbe. 
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Itt buktuk az réjtrészinget.
Úgy hívják, hogy press release. 
Ú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.
- Itt a Galaxy S26 széria: az Ultra fejlődött, a másik kettő alig
- Építő/felújító topik
- Motoros topic
- Kezdő fotósok digitális fényképei
- Ilyen olcsó sem volt még egy Apple notebook
- AMD Navi Radeon™ RX 9xxx sorozat
- Mibe tegyem a megtakarításaimat?
- Eredeti játékok OFF topik
- Hardcore café
- MWC 2026: Beütött a szer, elburjánzott a Tecno-buli
- További aktív témák...
- Borzasztóan cuki, elegáns, HALK fileszervernek bőven elég teljesítménnyel és elegáns megjelenéssel
- Dell Vostro 3425 6magos Ryzen 5 5625U 8GB RAM 256GB SSD
- Készpénzes / Utalásos Számítógép felvásárlás! Személyesen vagy Postával!
- HP ZBOOK Firefly 16 G10 /i7-1355U/16GB/1 TB SSD/FHD+/IPS/NVIDIA 4 GB Magyar bill
- Azonnali készpénzes Sony Playstation 5 lemezes és digitális felvásárlás személyesen/csomagküldéssel
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest