Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
[link] - Régebben is volt már HDR teszt, és akkor is ugyanez az eredmény jött ki. Ráadásul ott mindent megegyezőre állítottak.
Úgy néz ki, hogy itt a HDR pipeline a hunyó. Az AMD sokat nyer azon, hogy saját pipeline-t írtak, és nem a Microsoftét használják.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#34477
Abu85
HÁZIGAZDA
Petykemano
#34475
Abu85
HÁZIGAZDA
válasz
Petykemano
#34475
üzenetére
Mert nyolcmagos. A motorba építettek deferred contextet, de csak NV-n aktiválják, viszont így az NV driver máshogy viselkedik, mint az IC manuális többszálúsággal. Az AMD utóbbit használja, vagyis a magok számának növelése valós eredményhez vezet. Az Intel IGP-i is az utóbbit használják.
A következő generációs GeForce parancsmotorjából már rengeteg aktuális funkciót kivágtak, és az általános data path-ok szélesebbek, így az sem igényel majd specifikus optimalizálást a skálázódáshoz, vagyis ott is mehet majd az általános kódút.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A driver gyakorlatilag kizárható. Itt egyre inkább a szervizkönyvtárak HDR SDK-ja a kulcs. Még 2016-ban írtunk is róla, hogy első körben ez nem lesz szabványos. [link] - Az AMD-nek van a Photon SDK-ja, ami az AGS-en keresztül kezelhető, míg az NV egy házon belüli SDK-t csinált anno. Na most a probléma ott lehet, hogy a Photon SDK-t az AMD folyamatosan fejleszti, hogy megkerüljék a Windows HDR pipeline-t, míg az NV az egészet ráhagyta, és inkább a Microsoft szabványos környezetét kezdték el támogatni, így viszont a saját környezetük mögül kivették a pénzt, vagyis nem fejlődött tovább. A Windows gyári környezete viszont nem tűnik acélosnak, tehát hiba volt így dönteni, de vissza már nem lehet menni a múltba, segíteni kell a Microsoftot, hogy jó legyen a szabványos környezet is. Ebből még mindig nem lenne gond, csak az AMD berakatja a Photon SDK-t mindegyik HDR-es játékba, szóval ők addig meg tudják kerülni a Microsoft HDR-jét, amíg a redmondiak meg nem oldják a problémákat. Az NV ezt a leállított fejlesztések után nem tudja megtenni, újraindítani pedig felesleges, hamarabb megoldja a problémákat a Microsoft. Azt persze nehéz megmagyarázni, hogy a HDR SDK-jukat miért állították le, gondolom az oda szánt pénzt valahova át kellett csoportosítani.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Mert működött az NV-nek is a HDR SDK-ja. Ezért nem értem, hogy miért álltak le vele. Az tisztán látszik, hogy a Microsoft szabványos HDR-je nagyon köhög. Ezt már akkor lehetett sejteni, amikor az Xbox One konzolokba nem a saját megoldásukat, hanem az AMD Photonját tették be.
Felesleges AMD vs. NV hitvitát csinálni ebből is. Ez csak HDR. Jelen pillanatban nem sok haszna van a mai panelekkel. A tipikus ANSI kontraszt a legtöbb kijelző esetében 10 stops, de maximum 12, és ehhez igazából még nem kell HDR. Maximum az a selling point, hogy bizonyos kijelzők ki tudják rakni a direkten tone mappingolt képet, így azt láthatod, amit a fejlesztő akart. De ezt igazából el lehetne érni szabványosan is, az egész csak egy fixen specifikált szoftver a FreeSync 2 HDR mögött. Valószínű, hogy a FreeSync 2 HDR összes, ma még abszolút egyedi tulajdonsága szabvány lesz olyan 2-3 éves távlatban, akkor már felnőnek a feladathoz a kijelzők is, nem csak ANSI kontrasztban, hanem pixelszintű vezérléssel, stb. Úgy már lesz értelme magának a HDR-nek is.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
-
Abu85
HÁZIGAZDA
válasz
Crytek
#34514
üzenetére
Lehet, de nem biztos. Egyszerű PS3 portról van szó, ami nem fut ideálisan PC-n. PS4-es verziót kellett volna portolni, csak a Sega nem készített még erre a motorra ennek megfelelő fejlesztőeszközöket.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
TTomax
#34543
üzenetére
De kamu. Azért nevezték át, mert az SLI-nek és a Crossfire-nek semmi haszna a DX12/Vulkan API-k alatt. Ezek az API-k ugyanis nem támogatják a meghajtóoldali multi-GPU-s megoldásokat, így pedig a Crossfire nevet dobták, ugyanis hasztalan, ha az API oldalán vágják el a támogathatóságot. Az mGPU egy átfogó név lett, ugyanis így az AMD egy kalap alá tudja venni a régi API-kra a régi Crossfire működését, ami ugye haldoklik, emiatt sem látsz már több GPU-s rendszert egy NYÁK-on, illetve az új API-k teljesen megváltozott funkcionalitását, beleértve a WDDM 2.0-ba épített szabványos AFR-t, amit a Microsoft csinált, és nem is engedik meg a gyártóknak, hogy belepofázzanak ebbe.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
TTomax
#34546
üzenetére
Az AFR azért nem működik, mert nem lehet optimálisan működtetni a mai modern motorokkal. Ezzel senki sem tud mit kezdeni.
Ha kifelé egy GPU-nak látszódik egy megoldás, akkor memóriakoherens interfésszel van összekötve. Arra nem kell külön támogatás, hiszen nincs két különálló memóriaterületed.
Maga az X2-es Vega létezik, csak ott van bevetve, ahol van értelme: VDI-ban. AMD Radeon Pro V340 a neve egyébként.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#34555
Abu85
HÁZIGAZDA
Petykemano
#34554
Abu85
HÁZIGAZDA
válasz
Petykemano
#34554
üzenetére
A sugárkövetés alapvetően nem egy tensorban megvalósítható dolog. Az FP32-es számítás, ráadásul a DXR aktuálisan érkező verziója 32 bites vertex formátumot támogat csak, vagyis ha nem butítasz nagyon a geometriai részletességen, akkor 10+ GB VRAM a belépő. A második DXR verzió fog több vertex formátumot támogatni, de az leghamarabb jövő tavasszal jön, de az is lehet, hogy csak egy év múlva, mert rengeteg más szempontból is változás lesz a DXR-ben, ami már eleve megtöri a kompatibilitást, tehát célszerű, akkor egyben újrakezdeni.
A fixpontos dot product a denoising szempontjából előnyös a DXR-ben, de ott is valami szabályozást akar az ipar, mert az AMD például már bejelentkezett a 4 bites megoldásával, amit a DXR specifikáció elfogad, de az NV szerint kellene egy minimum érték. Nekik ugye 8 biten kell ragadni a hardverük miatt, ami azt jelenti, hogy az AMD sokkal gyorsabb lesz a Vega 20 4 bites formátumával. A 8 bites fixpontos dot product egyébként egy reális szabvány lehetne, de mivel az AMD-nek már van 4 bitre is alkalmas hardvere, így csípőből ellenezni fogják, vagyis leginkább annak van most realitása, hogy az NV és az Intel is elkezd vadul menni a 4 bites formátumra.
Jelen pillanatban a DXR mögött rengeteg a kérdés. Már csak a hardver oldali implementáció miatt is, mert a Microsoft nem nagyon akarja szabályozni ezt, ők úgy vannak ezzel, hogy adnak egy specifikációt, aztán nézik a végeredményt. Azt nem igazán akarja a cég meghatározni, hogy a végeredmény előtt mit csinálhat a hardver. Az MS szempontjából akár varázsolhat is, ha a végeredmény megfelel a követelményeinek. Az NV azonban szabályozást akar, méghozzá úgy, hogy a Microsoft kötelezően írja elő, hogy fixpontos dot product számításokat egy külön ALU-csoport végezze. Ebbe például az AMD és az Intel helyből nem fog belemenni, mert ők például ellenzik ezt a megoldást, ugyanis ha így lenne meghatározva a specifikáció, akkor tranzisztorok milliárdjait költenék egy olyan részegységre, amely grafikai szempontból csak egy specifikus működés mellett hasznos, máskor pedig csak a helyet foglalja. Ezzel szemben az AMD és az Intel a fő ALU-kba építi bele a fixpontos dot product támogatást, vagyis ha erre nincs szükség, akkor azok a tranyómilliárdokat elfoglaló ALU-k mást számolnak. Az NV-nek érthető, hogy ez miért nem tetszik, a architektúrájuk ilyen formában hátrányba kerül, mert ha egy játék nem használ majd DXR-t, akkor semmit sem fog érni a hardverben található rakás fixpontos dot product ALU. Ráadásul a denoising esetében a Microsoft nem igazán határoz meg semmit. Emiatt az AMD lehet, hogy nem is DL TOPS-szal implementálja, hanem SAD/QSAD/MQSAD megoldással, amit visszamenőleg meg tudnak oldani az összes GCN-re.A másik probléma ebből a szempontból a Vulkan API. Amire szintén van egy nagyon érdekes sugárkövetési megoldás. És ott az a fő gond, hogy azt az AMD írja, és nem egy szabványalkotó. Ráadásul nem lehet megcsinálni driverben azt, hogy ezeket a feladatokat a hardver ne futtassa le, vagyis az NV és az Intel is kénytelen elviselni mindazt a terhet, amit az AMD saját megoldása rájuk rak. És a DXR-hez képest a Vulkan AMD-s megoldása nem az API kiegészítése, hanem egy API feletti réteg, így a meghajtó oldalán nem befolyásolható, úgy fut a program egy hardveren, ahogy az AMD akarja. A DXR ebből a szempontból sokkal általánosabb, hiszen a Microsoft lehetővé teszi a saját fallback layerét, illetve a gyártó bármikor írhat rá drivert, amiben sok dolgot befolyásolhatnak. Ilyen formában a DXR nem igazán veszélyes, mert specifikált megoldás, amit egyenrangú felekként támogathat minden IHV. A Vulkan feletti Radeon Rays sokkal veszélyesebb, mert még ha a Volta tudná is futtatni sokkal hatékonyabban, akkor sincs meg az az úgymond híd, amivel ezt meg is tudják valósítani.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Dandris
#34559
üzenetére
Amíg ilyen a specifikáció, addig az AMD vidáman számolhat 4 biten. Pont ezért akarja az NV a specifikációt bővíteni, mert így nekik nem kellene az AMD hardvere után menni. De nem valószínű, hogy a Microsoft hajlandó lesz erre.
A Microsoft nem köti ki, hogy hogyan számoljon a hardver. Mint írtam a DXR a végeredményt tekinti, hogy az megfelel-e az elvárásoknak. A hardver belül akár varázsolhat is, a Microsoft egyszerűen tesz rá. Tehát az IHV döntése lesz, hogy a denoisingot hogyan implementálja a hardverben. Erre tényleg rengeteg megoldás van, és mondjuk az Intel és az AMD nem fogja ezt külön hardverrel megcsinálni, mert akkor kevesebb FP32 ALU lenne beépíthető ugyanabba a tranyóbüdzsébe. Az NV architektúrája viszont nem tudja ezt követni, tehát nekik muszáj különálló hardvereket alkalmazni az egyes speciális feladatokra. Ez az egyetlen oka, amiért sokkal merevebb DXR specifikációkat akarnak, mert nagyon gyorsan hátrányba kerülnek a mostani specifikációkkal.
De amúgy ez a DXR legkisebb problémája. Sokkal nagyobb baj, hogy csak 32 bites vertex formátumot támogat. Ez borzalmasan memóriazabáló, vagyis ha egy VGA-n nincs legalább 10+ GB memória, akár fizikailag rá építve, akár aktivált HBCC-vel, akkor annak a geometriai részlegesség látja majd kárát.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Dandris
#34561
üzenetére
De ki beszél csak az NV-ről? Tudtommal a DXR a téma, annak pedig elég kevés köze van az NV-hez, elvégre az Intel és az AMD hardverein is fut.
Cáfold meg amit írok. Ennyire egyszerű. Várom a szakmai érveidet.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#34570
Abu85
HÁZIGAZDA
Petykemano
#34568
Abu85
HÁZIGAZDA
válasz
Petykemano
#34568
üzenetére
Szakmai szinten kezdjük ott, hogy az NVIDIA-nak nincs ray-tracing megoldása. A DXR egy Microsoft szabvány. Semmi köze az NVIDIA-hoz. Az RTX csak egy név, ami a DXR drivert takarja, de ilyet más is írhat, akár el is nevezhetik sugárbébinek. Tehát egy olyan dolgot nem lehet szidni, ami nem is létezik.
Az AMD-nek van egyébként saját ray-tracing megoldása Vulkan API-ra. Az valóban nem szabványos, annak ellenére sem, hogy amúgy minden hardveren működni fog, hiszen a Radeon Rays library van bekötve a Vulkan API fölé. Ez sem lesz más, mint a DXR, csak nem szabványos, tehát az AMD határozza meg, hogy miképpen futhat az egyes hardvereken, nem pedig az adott hardver gyártója, ahogy a DXR esetében.A legnagyobb probléma egyébként ezekkel a ray-tracing megoldásokkal, legyen az a Microsoft szabványa, vagy az AMD Vulkan fölé húzott koncepciója, hogy iszonyatosan erőforrás-pazarlók. Ez mindkettőre igaz lesz. És persze lesz itt 1 TB/s-os közel 600 TOPS-os Vega 20, vagy már van 650 GB/s-os 120 TOPS-os Titan V, stb, ezeket sokan nem fogják tudni megvenni. Pedig ezek azok a szintek, ahol ez a sugárkövetés realitás, de még így is 30 fps-ről van szó. Emellett a DXR csak olyan programot futtat, amiben az IR DXIL-ben van szállítva, amire pedig csak a dxc fordít, méghozzá csak új specifikációjú HLSL-t. Tehát a DXR használatához nem csak ezt kell beépíteni, hanem újra kell írni közel 300 ezer sornyi meglévő kódot. Nem véletlen, hogy annyira egyikre sem ugrott rá a piac, mert a DXR-nél közel másfél éves munkával jár egy meglévő motor portolása, és eközben Windows 10 Redstone 5 lesz a minimum igény. A mostani Redstone 4-re már azt fogja mondani az alkalmazás az indításnál, hogy "baszki ez nem elég jó ide". A Vulkan API-nál az AMD-s Radeon Rays megoldásának pedig ott a baja, hogy bár technikailag gyártófüggetlen, azért a backendet biztosító Anvil erősen úgy van megírva, hogy bizonyos AMD kiterjesztéseket igényel. Tehát persze be lehet építeni, még Windows 7-ig visszamenőleg is működik, de nem garantálható 100%-ig, hogy az effekt bekapcsol az NV és az Intel Vulkan implementációján.
Szóval nagyjából itt tart a ray-tracing. A DXR-rel lezárod a játékod az év végén érkező Windows 10 frissítésre, és aki nem használ ilyet, annak nem is érdemes megvenni a programot, mert nem fog elindulni. A másikkal pedig nincs garancia a 100%-os kompatibilitásra. Ettől függetlenül a SIGGRAPH-on is volt róla szó, hogy pár fejlesztőnél befizették mindkettőt, de pénz nélkül erre nincs értelme ráugrani. Különösen az AMD speciális megoldására, mert abból sose lesz szabvány. Szerintem kb. a Bethesda lesz az egyetlen, aki használni fogja, elvégre nekik az AMD csinálja az R&D-t.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A ray-tracinget egyáltalán nem nehéz leprogramozni. Ez az egyik vonzó tényező a sugárkövetésben. Sokkal nehezebb valamilyen raszterizációs trükköt kialakítani rá. A DXR-nél nem az a nehézség, hogy nem lehet könnyen ray-tracing effektet írni. Ilyet igazából DXR nélkül is lehet csinálni, hiszen a compute shadert ezért hozták létre. A DXR is egy specifikus kiegészítés, ami végeredményben a DirectX 12 DirectCompute felületén fut, vagyis effektíve compute shader. A probléma a Microsoft specifikációja, ugyanis a DirectX 12 a wave programozás szempontjából "mindent vagy semmit" elvet követ. Ergo nem az a DXR nehézsége, hogy írsz pár shadert rá, amit majd az API átalakít compute IR-ré és IHV-specifikus kódokká, hanem az adja a problémát, hogy ebben a módban a rendszer csak DXIL IR-t fogad el, amihez pedig az adott motorba írt összes shadert újra kell írni, ami azért egy jó 300-400 ezer sor egy modern játéknál. Ez a fő oka, amiért az AMD például egy saját megoldást csinált a Vulkan API-hoz, mert szerintük erre a fejlesztők 1%-a ha hajlandó lesz. A Radeon Rays megoldás annyiban más, hogy ott C++-ban kell programozni a sugárkövetést, és a meglévő shaderekhez nem kell hozzányúlni, az Anvil a háttérben mindent elintéz, majdnem plug&play a modell. De ugye náluk meg az a probléma, hogy az Anvil nem egy kiemelten támogatandó projekt az Intel és az NV részéről, tehát ha mondjuk igényel valami olyan AMD kiterjesztést, amit a konkurensek implementációja pont nem támogat, akkor para van és nem fut le az effekt. De leprogramozni ezt sem nehéz, sőt a DXR-rel ellentétben, át sem kell írni több százezer sornyi meglévő kódot.
A probléma sokkal inkább az, hogy bármelyiket is választja egy fejlesztő, valamilyen szempontból mindkettőnek vannak mélytorkozós részei. És akkor most kinek hiányzik a mai világban beleállni egy mélytorkozásba úgy, hogy DXR-rel kizár mindenkit, aki nem Redstone 5-ös Windows 10-et futtat, vagy Vulkan esetén potenciálisan szopat mindenkit, aki Anvilra nem optimalizál Vulkan implementációt???[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#34576
Abu85
HÁZIGAZDA
Petykemano
#34573
Abu85
HÁZIGAZDA
válasz
Petykemano
#34573
üzenetére
Semmit nem tudunk arról, hogy a gyártók hogyan implementálják a DXR-t. Ezt ugyanis lehet fallback layeren futtatni, illetve írni rá egy specifikus implementációt. Annyit tudunk, hogy az NV a Volta-hoz ír meghajtót, míg az AMD a GCN-hez, de itt annyi infó még van, hogy a GCN3-tól más lesz az implementáció, mint a GCN3 alatt. Minden más hardver a fallback layert használja.
A teljesítmény szempontjából két tényező van. Lesz ugye maga a számítás. Mivel a DXR is ugyanazt csinálja, mint más raytracing framework, így hasonló lesz itt a teljesítmény, mint mondjuk a Luxmarkban, persze a raszterizáció miatt itt közrejátszik majd az aszinkron compute hatékonysága, hiszen nem csak a sugárkövetést számolják az ALU-k compute shaderben, hanem más feladatot is. A másik tényező például a denoising speciális végrehajtása. Ehhez lehet használni egy rakás implementációt. A Microsoft gyári implementációja egy SAD-re épülő technika, ami a fallback layeren belül működik. Az NV valószínűleg a tensor magokat használja majd itt, míg az AMD valószínűleg a saját dedikált SAD/QSAD/MQSAD utasításait. A Vega 20-ban valószínűleg valami kevert megoldást alkalmaznak majd, hogy hozzájussanak a 4 bites feldolgozás extrém sebességéhez. Szóval ezek a tényezők összességében határozzák meg a végső sebességet.
Az AMD Vulkan-hoz írt implementációja eléggé speciális. A teljesítménynél az a probléma vele, hogy az Anvilt az AMD saját magára írja, tehát tök oké, hogy elvileg működhet gyártófüggetlenül, de annyira magára tudja szabni az egészet az AMD, hogy nem fog annyira gyártófüggetlenül működni. Értsd ezt úgy, hogy amíg a DXR esetében a gyártó önállóan dönthet úgy, hogy bizonyos dolgokat felgyorsít egy gyártói implementációval, amihez ad egy drivert ki és megy, addig a Vulkan-féle sugárkövetésnél az NV-nek és az Intelnek az AMD-t kell megkérni arra, hogy ugyan gyorsítsák már fel rajtuk a sugárkövetést.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Ezt nagyrészt a kényszer szüli.
Az Intelt a hagyományos GPU-piac annál jobban nem nagyon érdekli, ahogy most vannak. Gyakorlatilag 70%-ban uralják az egészet. Ha ennél jobban megérné, akkor már beleöltek volna egy rakás pénzt, de nem tették, mert jelentősen növekedtek volna a kiadások, miközben a részesedés arányaiban nem nőtt volna annyit, hogy ez megérje.
Ami itt tényleg számít az a szerver és a professzionális terület. Ezt nagyrészt ma még uralják a CPU-kkal, de azt már nem lehet elvitatni, hogy a GPU-k egyre több helyre törnek be, és persze ezt nem úgy kell elképzelni, hogy megjelent a GPU, és akkor mindenki azt vesz CPU helyett, hanem elkezdődik egy folyamat, aminek a vége mindenképpen az lesz, hogy a GPU nagyjából tudni fogja a CPU-vel elérhető szoftveres hátteret. Nem ma, nem holnap, leginkább csak pár év múlva, de oda fog érni. És itt kezdődik a para az Intelnek, mert eddig hiába jöttek GPU-k egy csomó szerver/professzionális területre, a szoftveres háttért tekintve a fejlesztések elsőként nagyrészt CPU-ra érkeznek meg, ehhez építhető ki rengeteg, TB-os szintű memória, tehát egy csomó olyan tényező volt és még van ma is, amiért a GPU, jó-jó sok TFLOPS, de mégsem jó máshol. Például a render egy elég nagy piac, és ott önmagában a TFLOPS eléggé számít, a GPU-k jók is itt, de mégis nagyon sok cég, köztük a legnagyobbak CPU-s renderfarmot építenek ki, mert a szoftverek ehhez fejlődnek a leggyorsabban, meg ugye a memória is TB-os magasságokig bővíthető, akár fölé is. De a fenyegetés ott van, mert a GPU-knál a Vegából van 2 TB memóriával szerelt változat, illetve a szoftveres háttér is egyre inkább tartja a lépést a CPU-s fejlesztésekkel. Tehát technikailag már nincs messze az, hogy a GPU-k igazi fenyegetéssé váljanak itt, mert ha valaki mondjuk csinál egy olyan rendszert, aminél a CPU-t és a GPU-t egy tokozásra teszi, a GPU-nak lesz egy gyors HBM-je vagy HMC-je, és a CPU-n keresztül még eléri a 2-4-8 TB-nyi rendszermemóriát is, akkor ezzel csúnyán be tudja darálni a renderfarmokat. És ez a valaki nyilván az Intel akar lenni, meg persze a többiek, de az Intel szemszögéből ők problémaforrások.
És ez a példa egy csomó dologra kiterjeszthető, mert ahol megjelentek a GPU-k, ott a szoftveres háttérnél elkezdődött valami, és a szoftverfejlesztések egyre inkább közelítik a CPU-s kódokat, tehát a GPU-k nem csak tessék-lássék, hanem egyenesen reális alternatívává válnak, és a Vega megmutatta, hogy a memóriaprobléma is kezelhető, vagyis a legnagyobbnak tartott hardveres hátrány is lekezelhető. Persze az Intel anno azon az állásponton volt, hogy jó ide a Larrabee... akarom mondani Xeon Phi, de hát egyem a szívüket, az sosem működött igazán. Szóval nagyjából ezért csinálják.A hagyományos GPU-piac annyira nem fontos, de mivel lesz hardver, vagyis úgymond a fejlesztés igazán komoly költségét a szerver- és a professzionális piac miatt úgyis be kell ölni az egészbe, így a terméket lehozni a consumer rétegnek már "csak" maximum 1-2 millió dolláros költség, ami az egészet figyelembe véve nem nagy, így innen már megéri menni a 70%-nál is nagyobb részesedésre, mert arányaiban kifizetődővé vált. Ezt tehetik pGPU-val, vagy dedikálttal is, számukra előbbi a kedvezőbb, mert ott szépen csomagban árulhatják a hardvert a CPU-val, tehát mindenkit rákényszerítenek, hogy megvegye. IGP-re sincs ugye mindenkinek szüksége, de nem tudja nem megvenni.
Nem mellesleg azért abban eléggé igazuk van, hogy értelmes gaming notebookokat csak ilyen Kaby Lake-G-hez hasonló koncepciókkal lehet csinálni, mert így igen kicsi lesz a platformdizájn, és mehet a nagyobb akkumulátor arra a helyre, amit normális esetben egy GPU foglalna el. Tehát itt is van azért alapja annak, amit csinálnak. A többi terület pedig annyira nem érdekli őket, ezek túl picit ahhoz, hogy egy Intel kaliberű cégnek fontosak legyenek, de ha ide is venni fogja a nép, hát akkor szállítják.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#34624
Abu85
HÁZIGAZDA
Petykemano
#34623
Abu85
HÁZIGAZDA
válasz
Petykemano
#34623
üzenetére
Nem időben. Akkor kellett volna, amikor Justin Rattner helyére magát jelölte. Ott rombolta le az Intel következő 5-6 évét.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#34630
Abu85
HÁZIGAZDA
Petykemano
#34628
Abu85
HÁZIGAZDA
válasz
Petykemano
#34628
üzenetére
Azt jelenti, hogy a 2022-ben érkező Sapphire Rapidsban sem lesz gyorsabb p2p interconnect, mint 2019-ben érkező Rome-ban. És ez Krzanich döntése volt, elvégre ő felelt ezekért a tervekért Ruttner helyén. Ez pedig alapvetően meghatározza a skálázhatóságot. Most már ezzel nincs mit tenni, nem lehet csak úgy leállítani a fejlesztéseket. A Sapphire Rapids után lesz esélyük, addig a Rome is nagy falat lesz, hát még a következő Milan.
(#34629) Locutus: A 2070 játéktól függően úgy 15-25%-kal jobb az 1080-nál (legtöbb helyen inkább 15, de ha nagyon sávszéligényes a játék, akkor többel). A 2080 kb. hasonló az 1080 Ti-hez, hol gyorsabb, hol lassabb, attól függ, hogy mennyire terheli a ROP-ot és a memóriát a játék, mert ezekből sokkal kevesebb van a 2080-ban. A 2080 Ti pedig gyorsabb az 1080 Ti-nél úgy nagyjából 10-20%-kal.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
TTomax
#34635
üzenetére
A SIGGRAPH-on volt erről szó. Azt kell nézni, hogy maga a program mennyire tudja átlapolni az RT-t és a rasztert. Egy jól megírt DX12-es leképező nem igazán, mert az már eleve sok aszinkron compute-ot futtat. Innentől kezdve az RT egy extra számítás lesz az ezredmásodpercekben is. Na most egy 8xATAA-t a csúcs-turing 6 ms körül számol Full HD-ben, ami az egyik legkíméletesebb RT effekt. Persze lehet ezernyi dologgal játszani, például a sugarak távolságával, azok pixelenkénti számával, stb. De jelenleg annyira korlátozott a teljesítmény, hogy egy sugár/pixel a realitás, illetve nem lehet ezeket sokáig kilőni. Az árnyék a legkevésbé teljesítménygyilkos, de csak akkor, ha kicsi távolságra lövöd a sugarakat, kis térben viszont elég jól működik. Ezt egy csúcs-turing 3-4 ms között is megoldja Full HD-ben, hacsak nem trükköz valamit a program. A legnagyobb tempógyilkos a visszaverődés. Az 10 ms alatt nincs még a leggyorsabb hardverrel sem. Ez azt jelenti, hogy ha 60 fps a célod, akkor egy ilyen effektet úgy tudsz bekapcsolni, ha a játék amúgy 170 fps-sel megy nélküle. Nem véletlen, hogy a Frostbite egy SSR hibridet használ, ami nem teljesen sugárkövetés, ezzel legyűrték 7 ms alá az igényeit egy Quadro RTX 8000-en. A 2070-re nincsenek adatok, de ha a Quadro RTX 8000-n ezek vannak, akkor sok jóra nem számíthat. Kb. a shadow és az AO menni fog rajta Full HD-ben, de erősebb grafika mellett 30 fps-sel leginkább, vagy áldozol másból, hogy sugárkövetést futtass. Azt tudni kell, hogy a sugárkövetés eléggé sávszéligényes, tehát ez jobban számít itt, mint a TFLOPS-Gigarays.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
snecy20
#34640
üzenetére
Sokat zabál nagyon. Laikusoknak az jöhet le, hogy ezt külön hardver számolja, de ez nem igaz. A DXR futószalagnak csak az egyes lépcsőin belül az egyes elemei gyorsíthatók. De a teljesítményt akkor is nagyban meghatározza a szimpla pontosság melletti számítási tempó, illetve a memória-sávszélesség. Az RT mag csak a gyorsítóstruktúrára, illetve a sugár-háromszög intersectionre kínál hardveres megoldást, míg a tensor a denoisingra, de ez nem a teljes számítás. A DXR shaderek a hagyományos feldolgozókon futnak.
(#34641) TTomax: A legtöbben szerintem nem mennek tovább az árnyékoknál, mert azt lehet úgy implementálni, hogy majdnem minden leképezővel megfelel. Az AO is nagyjából oké, míg az ATAA önmagában bonyolultabb, de kompatibilitási szempontból eléggé általános. A visszaverődés, ami nehezebb, nem csak a teljesítményigény miatt. Ami itt problémás lesz a legtöbbeknek, hogy előbb írniuk kell egy DX12 leképezőt is, hogy ez az egész működjön. Aztán a shadereiket le kell konvertálniuk az új specifikációhoz, hogy DXIL-ben is tudják szállítani őket. Ez a support költséget durván az egekbe küldi, ha nem vállnak meg a régi kódtól. Itt a PUBG-ra leszek kíváncsi, hogy miképpen bírják rá a kínai játékosokat a Windows 10-re váltásra, mert így is kész káosz a support, hát még ha dupla annyi kódot kell karbantartani.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
rumkola
#34696
üzenetére
A DirectX Raytracing egy szabvány. Az RTX az csak a "driver" neve, de maga a kód szabványos. Az AMD nem nagyon veszekszik a stúdiókkal, hogy ne rakják be a DirectX Raytracinget (amit RTX-nek is lehet hívni), pont ellenkezőleg.
Azt egyébként hozzá kell tenni, hogy az RTX technológia jelenthet DLSS-t is. Hülyeség ide sorolni, de az NV ide sorolja. Szóval nem csak sugárkövetést rejthet.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#34701
Abu85
HÁZIGAZDA
Petykemano
#34700
Abu85
HÁZIGAZDA
válasz
Petykemano
#34700
üzenetére
A függetlenített int32 elsődlegesen ahhoz kellett, hogy sugárkövetésben ez egy, ha nem is nagyon sűrűn, de azért picit erőteljesebben használt operáció. Így az fp32-es shading mellett párhuzamosan lefuthat. Persze csak akkor, ha van elég regiszter hozzá, mert ugye ez még mindig probléma lesz, de legalább az elvi lehetőség adott.
Az 50% az L1-ből jön, de csak akkor, ha a futtatott shader kevés warpot tud használni a Pascal multiprocesszorán. Lásd a Vega esetében az LDS pressure, amitől a Polarishoz képest a Vega CU shader teljesítménye a duplájára nőtt. Na most a Pascal->Volta/Turing váltásnál nem volt közel duplázás, de azért az összevont cache az occupancy limites szituációkban simán hoz 50%-ot, ha a meghajtó úgy van beállítva, hogy a maximális warpot direkt limitálja, hogy azzal a cache partíción keresztül csökkentse az LDS/register pressure-t. Persze a legtöbb compute shadert úgy írják, hogy ne legyen occupancy limites a Pascal/Polaris és a még korábbi generációkon sem. De azért van már olyan compute shader, ami már az. Ezekhez az új, occupancy limitre kifejezetten ügyelő Vega/Volta/Turing dizájnok az ideálisak, vagy az Intel IGP-i, azok brute force tolják. A gyakorlatban pedig ezeket azért nem látod igazán, mert rengeteg shadert futtat egy alkalmazás, tehát teszem azt a shaderek 3%-ára az új multiprocesszor hatékonyabb, de az összesített teljesítményt inkább a maradék 97% határozza meg, ahol pedig eleve nincs occupancy limit, vagy nem annyira erős, hogy amellett még ne lehessen elfedni a memória késleltetését. Persze azzal, hogy a hardverek fejlődnek, a fejlesztők egyre komplexebb shadereket írhatnak, így pedig egyre több olyan shader futhat egy játékban, ami a régi dizájnokkal occupancy limites lesz.A DLSS az olyan mint az SS, csak nem mindenhol alkalmazza a rendszer. Igazából azért hoz sebességnövekedést, mert közben mást viszont nem úgy számol, ahogy natív részlegességgel amúgy tenné. Ezért van megjelölve a DLSS külön, mert a DLSS nélküli eredmény jelöli a natív részletességet. Ha natív részletesség mellett lenne alkalmazva a DLSS, akkor az extra számítástól csökkenne a teljesítmény, de pont az a lényege, hogy ne kelljen némelyik számítást elvégezi.
Ha ugyanaz a számítás az AMD és az NV között, akkor igazából a képminőség is 99%-ban ugyanaz. Egyedül a szűrés különbsége okozhat eltérést, de ez felfogásbeli különbség, illetve ebből a szempontból az AMD-nek van egy beállítása a driverben, ami annyit tesz, hogy ha a mintázat szűrésének minőségét a user "teljesítmény"-re állítja, akkor azt a minőséget kapja, amit az NV ad default. De az AMD default minősége még mindig eléggé sokban követi a Microsoft WHQL-es, mára már nem kötelező érvényű előírásait.
A különböző eljárások pedig különböző minőséget adnak. A főbb dolgokat összehasonlítottuk régebbi cikkekben (viszont ezek jó része nem alma-alma összehasonlítás, mert eltér maga az eljárás, tehát természetes némi különbség): [link] és [link][ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#34809
Abu85
HÁZIGAZDA
cskamacska
#34790
Abu85
HÁZIGAZDA
válasz
cskamacska
#34790
üzenetére
A specifikus kódok nem úgy jönnek, hogy ezeket megírják külön. Nagyrészt azt csinálják a fejlesztők, ideértve a DICE-ot, hogy a PS4Pro géphez írt PSSL shadereket fordítják át egy source-to-source fordítóval az AMD HLSL ext. specifikációjára, amiből aztán tudnak fordítani egy olyan D3BC kódot, amit az AGS szervizkönyvtár elfogad. Alapvetően ebben jelentős munka nincs, az AMD úgy írta meg az AGS-t, hogy a PSSL shaderek szintaxisához igazodjon, ami egyébként eleve nem tér el jelentősen a HLSL-tól, főleg nem az AMD specifikus HLSL ext.-től, tehát effektíve csak a függvények nevét cserélik.
A Frostbite esetében az történik, hogy a DICE leginkább a DPP és az SDWA képességekre épít a PSSL kódokban, így tudnak sebességet nyerni a PS4Pro gépen. Ezekkel gyakorlatilag gyorsabban oldanak meg bizonyos kivágásra vonatkozó feladatokat, vagy tehermentesítik a CPU-t. A PC-s környezetben ugye nem pont úgy fut a Frostbite, ahogy konzolon, mivel a szabványos API-k számos konzolon elérhető függvényt nem tesznek elérhetővé, így bizonyos GPGPU-s eljárásokat át sem lehet menteni, helyettük egy CPU-s megoldás fut PC-n. Ugyanakkor az AMD-nek ezeket átmentik, és mivel ezek a DPP-re és az SDWA-ra épülnek, így alapvetően GCN3/4/5 kell a futtatásukhoz. Ennél egy jóval rosszabb hardveres lehetőségeket rejtő kódot kapnak a GCN1/2 hardverek. Ezért van az, hogy a Frostbite új verzióiban a GCN3/4/5 dizájnok eléggé meglépnek a GCN1/2-től. Egyszerűen ugyanazt a gyártóspecifikus kódot sokkal gyorsabban tudják futtatni.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#34828
Abu85
HÁZIGAZDA
huskydog17
#34827
Abu85
HÁZIGAZDA
válasz
huskydog17
#34827
üzenetére
Nem hiszem, hogy ezen a motoron lehet a DX11-en segíteni. Maximum pár százalékot. De a fejlesztők nem használnak gyártóspecifikus kiterjesztéseket, tehát a motor csak DX12-ben éri el az ExecuteIndirectet. DX11-ben ennek nincs szabványos megfelelője, csak az AMD és az NV függvénykönyvtárain keresztül. Ezekből viszont semmit sem használnak. Még HDR-re is a Microsoft szabványos, "belilulós" pipeline-ját működtetik. Rohadt Xbox One persze a direkt tone mappingos alternatívát kapta, hogy szakadjanak meg.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#34831
Abu85
HÁZIGAZDA
huskydog17
#34830
Abu85
HÁZIGAZDA
válasz
huskydog17
#34830
üzenetére
Csak ehhez mindenképpen kellene indirect draws/dispatches, mert ennek hiánya okozza az eséseket. Ugye ezzel az alkalmazás meghatározott számú rajzolási parancsot generálhat és futtathat a processzor beavatkozása nélkül. DX12-ben erre van az ExecuteIndirect, de DX11-ben ennek nincs semmilyen szabványos megfelelője, ami a processzorra sokkal nagyobb terhet ró. Az AGS-ben és az NVAPI-ban vannak megfelelő függvények, csak azokat nem használja a játék. Beépíteni sem hiszem, hogy beépítik, mert ezt így utólag eléggé necces megcsinálni. Egy rakás gyártóspecifikus kódot igényel, amit hetekig tart kitesztelni, arról nem is beszélve, hogy nem szabványos kódokról lenne szó, és az AMD, illetve az NV implementációja a DX11 kiterjesztés tekintetében különbözik. Gondolom ezért is állnak úgy hozzá, hogy ebből inkább nem kérnek, ott a DX12 a szabványos ExecuteIndirecttel. Alternatíva lehetne a Vulkan API, annak is van megfelelő, szabványos kiterjesztése (KHR_draw_indirect_count) erre.
Az nagyon fontos, hogy bizonyos motorok azért gyorsak DX11-ben, mert eleve GPU-driven pipeline dizájnt használnak, illetve alkalmaznak indirect draws/dispatches metódusokat a gyártói kiterjesztéseken. Ezek nélkül például a Frostbite-ban vagy az AnvilNextben is kb. feleannyit tudna a DX11-es mód. A "csodákat" is főleg ezekhez teszi hozzá a meghajtó, nem igazán a szabványos kódokhoz.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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. [ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
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
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
lezso6
#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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Crytek
#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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Crytek
#35345
üzenetére
De most váltanak. Ez képezi az újítások egy részét. Csak hát nem akarták emiatt csúsztatni a játékot. Az Tomb Raidereknek ritka szar a DX11-es módja. Onnan nem nehéz javulni. Az Anvil egy GPU-driven pipeline, ami teljesen más sztori.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#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.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
Nem mellesleg azért abban eléggé igazuk van, hogy értelmes gaming notebookokat csak ilyen Kaby Lake-G-hez hasonló koncepciókkal lehet csinálni, mert így igen kicsi lesz a platformdizájn, és mehet a nagyobb akkumulátor arra a helyre, amit normális esetben egy GPU foglalna el. Tehát itt is van azért alapja annak, amit csinálnak. A többi terület pedig annyira nem érdekli őket, ezek túl picit ahhoz, hogy egy Intel kaliberű cégnek fontosak legyenek, de ha ide is venni fogja a nép, hát akkor szállítjá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.
- Okos Otthon / Smart Home
- Elektromos autók - motorok
- Bugok, problémák a PROHARDVER lapcsaládon
- Redmi Note 13 Pro 5G - nem százas, kétszázas!
- Milyen CPU léghűtést vegyek?
- Itt van az eddig legjobban teljesítő kétfiókos NAS a TerraMastertől
- Nvidia GPU-k jövője - amit tudni vélünk
- Gitáros topic
- Filmvilág
- Synology NAS
- További aktív témák...
- Gyönyörű autómatricák azonnal gyors országos kiszállítással! PH-soknak 30% kedvezmény!
- Asus K95VJ, 18,4" FHD, I7-3630QM 8x3,40 GHz, 16GB DDR3, 250GB SSD+1TB HDD, 1GB VGA ,WIN 10, Számla,
- Asus R751L, 17,3" FHD, I7-4510U, 8GB DDR3, 1TB HDD, 2GB VGA ,WIN 10, Számla, garancia
- IdeaPad 1 15ALC7 15.6" FHD Ryzen 5 5500U 16GB 512GB NVMe SSD (PCIe 4.0) gar
- Asus N73S, 17,3" FHD, I7-2670QM 8x3,10 GHz, 16GB DDR3, 250GB SSD,500GB HDD, 2GB VGA ,WIN 10, Számla,
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Alpha Laptopszerviz Kft.
Város: Pécs