Új hozzászólás Aktív témák
-
#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.
-
#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.
-
#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.
-
#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] -
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.
-
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.
-
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.
-
#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.
-
#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.
-
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. -
#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.
-
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??? -
#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. -
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.
-
#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.
-
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.
-
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.
-
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.
-
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.
-
#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.
-
Abu85
HÁZIGAZDA
Ahhoz, hogy ez számítson FCAT-tal kell mérni. A presentek közötti mérésnél ezek a beállítások nem módosítják az fps-t.
Nem valószínű, hogy ez egy driverhiba. Az lehet a gond, hogy az NV a Microsoft HDR pipeline-ját használja, míg az AMD mindenhova berakatta a saját natív pipeline-ját. Tehát a Microsoft pipeline-jának többletterhelésétől menetsülnek, mert megkerülik az egészet. Nem véletlen, hogy a Microsoft Xboxon sem a sajátját, hanem az AMD HDR pipeline-ját használja. Lényegesen jobb, mint amik ők összehoztak. De OS frissítésekkel ez helyrehozható, vagy az NV-nek is szüksége lenne egy natív pipeline-ra, amit aztán a fejlesztők beépíthetnek. Igazából az a fő kérdés, hogy miért nem fejlesztettek ilyet alapból.
-
Abu85
HÁZIGAZDA
válasz
cl.aci
#34392
üzenetére
Az NV D3D12 implementációja miatt. Nem igazán szereti, ha egy D3D12 leképezőt egy adott játékba teljesen a Microsoft ajánlásai szerint írnak meg. Ez lehet hardveres vagy szoftveres probléma is, de az látszik, hogy az Intel és az AMD meghajtójának ez egyáltalán nem gond. Valószínűleg később ezt a gondot megoldják, és onnantól már az NV-re is a D3D12 lesz a default, de ezt nem olyan egyszerű ám az alkalmazás oldalán kezelni. Írtál valamit az MS ajánlásai szerint, ami speciel az NV-nek nem jó, vagyis írni kell valamit az NV ajánlásai szerint, ami egyébként most még jó is, mert az Intel és az AMD dizájnja erre sem érzékeny, tehát lehetett volna helyből sok kisebb parancslistát használni. Elég sok D3D12-es játék működik így.
-
Abu85
HÁZIGAZDA
Nyilván NV DX12 meghajtó.
Bocsi.De reggel nem akartam annyira elkapatni a hsz-t, de van még egy rakás probléma, például a memóriatípusok szempontjából az implementáció kialakítása. Na most az egy külön marha nehéz téma. Főleg azért, mert annyira eltérnek az implementációk, hogy nehéz mindenkinek jó megoldást találni.
Nézzétek meg Vulkan alatt (DX12 is ugyanez kb.): Intel - AMD - NVIDIA
És akkor erre kell írni egy memóriamenedzsmentet a programból, ami mindhárom gyártó implementációjával jól működik. Alig lehetetlen.
-
#34376
Abu85
HÁZIGAZDA
->Raizen<-
#34374
Abu85
HÁZIGAZDA
válasz
->Raizen<-
#34374
üzenetére
Ez DX12 alatt erősen programfüggő is. A meghajtó csak korlátozott mértékben segíthet. A drivernél elsődlegesen azért volt látható egy időben javulás az NV-nél, mert az AMD DX12 meghajtója máshogy van felépítve. Nagyon röviden arról van szó, hogy a gyártók számára szabad az implementáció kérdésében trükközni. A Microsoftot és a Khronost addig érdekli a dolog, amíg az adott implementáció átmegy a hitelesítési teszten, de arra magasról tesznek, hogy a hardverhez közel a driver mit csinál.
Az AMD megoldása egy tipikus KISS koncepció, keep it simple, stupid. Maga az explicit implementáció egy közös rétegben valósul meg, amit PAL-nak hívnak. És ez a Mantle óta létezik, azóta fejlesztik, van benne egy rakás pénz, és ami a legfontosabb, kb. 5 év tapasztalat. A Vulkan és a DX12 csak egy ICD-vel van a PAL fölé húzva. Tehát mindkét API esetében az alapréteg ugyanaz, vagyis ha ezt fejlesztik, akkor egyszerre javul a Vulkan és a DX12 meghajtó is. Ezt a rém egyszerű modellt azért alkalmazzák, mert annyira nehézkes a külön reagálni az API-kra, hogy rengeteg erőforrást vinne el a natív megközelítés, de így az erőforrásokat arra fordíthatják, hogy a PAL réteg legyen nagyon gyors.
Az NV megoldása ma már nem ilyen egyszerű. Régen ők is furcsán közelítették meg ezt, volt amikor a Vulkan API-t az OpenGL alól hívogatták, de a DX12-t is megpróbálták költséghatékonyan beintegrálni, de egyik sem sikerült. A mai meghajtóval már natív Vulkan és natív DX12 támogatás van átlapolásra vonatkozó rétegezés nélkül. Ennek az előnye, hogy tényleg specifikusan lehet az implementációval az API-kra reagálni, viszont hátránya, hogy a sok trükközés miatt egészen bonyolult a kód, és a karbantartása sokszorosan több pénzbe és humánerőforrásba kerül. Emellett ugye a mostani implementációk alig egy évesek, vagyis a tapasztalat alapján beépített teljesítmény is kevés bennük. Ezért tudtak az elmúlt évben sokszor javítani, mert akkor még csak pár hónaposak voltak az implementációk, és könnyű volt sebességet találni. Ahogy telik az idő, ez egyre nehezebb lesz, mert függetlenül attól, hogy kívülről nem látszik, azért a háttérben a kód fejlődik, és bizonyos változásokkal mikromásodperceket nyernek helyenként.
Az Intel DX12-es megoldása hasonló az NV-hez, de ők a Vulkan esetében csináltak egy érdekes dolgot. Hasonlóan rétegelték az implementációjukat az AMD-hez. Emiatt nagyon érdekes, hogy a DX12 implementációjuk nem annyira erős, de a Vulkannál a mostani kód hihetetlenül jó. Valószínű, hogy a jövőben döntenek majd arról, hogy a DX12-nál megoldják azt, hogy írnak egy kliensoldali modult a Vulkan implementációhoz használt hardverhez közeli rétege fölé. És akkor a DX12 implementációjukkal is áttérnek a KISS-re. Ezzel ugye az a baj, hogy élesben csinálják a váltást, ami egy csomó meglévő programnál hibát generálhat, de valószínűleg a hosszabb távú hatásai megérik. Látva azt, hogy mennyire jól működik a Vulkan driverükben a hardverközeli réteg, egyértelmű, hogy nem éri meg szenvedni a jelenlegi langyoska DX12 implementációjukkal.
Egyébként nem biztos, hogy az NV-nél jelenleg működne a KISS megoldás. Biztos van oka annak, amiért ők ezt kerülik, annak ellenére is, hogy az AMD-nél általánosan, míg az Intel Vulkan driverénél látványosan jól működik.
-
#34361
Abu85
HÁZIGAZDA
huskydog17
#34357
Abu85
HÁZIGAZDA
válasz
huskydog17
#34357
üzenetére
Ezért mondtam, hogy olvasd el azt az oldalt, ugyanis ha elolvasod világos lesz számodra is, hogy a teljesítmény attól függ, hogy mennyire rángatod az egeret. Tényleg érdemes elolvasni, nem csak a brute force módszer létezik.
Nem vonok le következtetést, de a 19%-os meghibásodási arány szvsz sok volt (azóta 32,4% - [link] ). Mondjuk az eladási mennyiséget nem ismerjük, tehát lehet, hogy kis mennyiségben volt a magyar piac extrém peches. Mindenesetre mi inkább nem kockáztatunk újra. Szopni pedig szoptunk, mert teszt közben ment tönkre, így oda lett minden korábbi eredmény.
-
#34355
Abu85
HÁZIGAZDA
huskydog17
#34343
Abu85
HÁZIGAZDA
válasz
huskydog17
#34343
üzenetére
[link] - olvasd el hogyan működik, és láthatod, hogy sebességmérésre nem alkalmas, mert alapvetően a bemenet határozza meg a számítás mennyiségét. Az iCafe driverben viszont alapértelmezetten aktív.
Finomhangolni bármit lehet, de scene pacing nélkül megközelítőleg sem nyersz vele annyit. Ez nem finomhangolás ugyanis, hanem egy eltérő számítási módszer.
Amikor tönkrement a mi ITX-es 1070-ünk, akkor néztük, hogy nagyon magas a hibaarány a kereskedőnél ahol vettük, és ez jellemző volt a többi ITX-es modellre is. A normál modelleknél viszont átlagos volt a panasz. Nyilván, ha ezt az elején tudjuk, akkor nem is veszünk ITX-es 1070-et, mert lett volna hely a nagyobbnak, de akkor még nem volt annyi adat róla a kereskedőnél. Beszoptuk, ez van.
Ha van hely a házban a nagynak, akkor érdemes azt venni. -
Abu85
HÁZIGAZDA
válasz
Yutani
#34327
üzenetére
Ma már ez annyira nem számít, mert a GPU-k képesek az órajelüket szabályozni, tehát ha belefutnak a beállított hőmérsékleti limitekbe, akkor egyszerűen csökkentik az órajelet, amíg jó nem lesz a helyzet. Szóval ha nem is akármilyen, de lényegében elég széles tartományt lefedő hűtővel is üzemképesek a mai VGA-k.
Az ITX-es GeForce-oknak az egyetlen baja, hogy nagyobb a meghibásodási arányuk a normál verziókhoz képest. Bizonyos modelleknél jóval. Nekünk is tönkrement a laborban egy ITX-es GeForce (egyem a szívét pont teszt közben
![;]](//cdn.rios.hu/dl/s/v1.gif)
), pedig alig hajtottuk, aztán kiderült, hogy nem egy strapabíró szerkezetek sajnos, más is panaszkodott rájuk. Igazából, ha nagyon számít a hely, akkor persze megvehető, de inkább egy normál. Nem sok különbség van az árban, és kevesebb rájuk a garis panasz. -
#34320
Abu85
HÁZIGAZDA
huskydog17
#34319
Abu85
HÁZIGAZDA
válasz
huskydog17
#34319
üzenetére
Na miért fogyna el? Mert mondjuk a Microsoft Residency Starter Library működik ugyan, de megfelelő átalakítás nélkül borzasztóan memóriapazarló? Ugyanez igaz az AMD VMA-ra. Szóval hiába vannak ezek a libek az explicit API-k memóriamenedzsmentjéhez, elsődlegesen a teljesítményt célozzák, és nem a memóriával valós spórolást. Ezért beszél már március óta a Microsoft és a Khronos képviseletében az AMD arról, hogy vigyázzanak, mert az új játékok, amiket fejlesztenek, marhára elkezdték zabálni a VRAM-ot, holott közel sem kellene annyi erőforrás neki.
Alig van HDR-t támogató játék. Ha ezer lenne, akkor nem úgy állna hozzá a Microsoft, hogy ráérnek Windows HDR pipeline problémáit javítani majd hónapok múlva is.
Próbáld ki a Chillt. Megfelezi az átlagos fogyasztást. Linkeltem is, hogy mi történik, ha ugyanazt csináljuk, és nézd nyugodtan a fogyasztásmérőt. A látott eredmény pedig ugyanaz volt, miközben a fogyasztás gyakorlatilag GTX 1060 szintre csökkent.
Nem véletlen, hogy a kínai iCafé megrendelések megnőttek a TUL felé, mert Chillel iszonyat sokat tudnak spórolni a villanyszámlán. Az viszont kétséges, hogy otthoni környezetben ez érezhető lesz-e. Nyilván egy internetkávézóban, 100-150 géppel számít, ha jobb a hatékonyság, de otthon egy géppel nem nagy kunszt. Én sem a kisebb fogyasztásért használom, hanem a scene pacing miatt. -
#34294
Abu85
HÁZIGAZDA
cskamacska
#34293
Abu85
HÁZIGAZDA
válasz
cskamacska
#34293
üzenetére
Nem tudom, hogy miért kellene rábeszélni a Vegára, ha GeForce-ot akar, de itt van pár érv, ha nagyon szeretnéd elérni nála ezt:
- ha elfogy a 8 GB VRAM, akkor a Vega esetében csak egy csuszka segítségével beállít a driverben minimum 12 GB-ot (az ő gépével maximum 16 GB-ot) ... ha WHQD-re lő, akkor ez már erősen megfontolandó, látva azt, hogy mennyit VRAM-ot zabáltak az E3-on prezentált egyes játékok
- ha HDR-t akar, akkor egyedül Radeonnal tudja megkerülni a Windows HDR pipeline-t, amivel lehetőség adódik a közvetlen tone mappingra ... ennek a hátránya, hogy játék oldali támogatás kell, de a Far Cry 5 kezeli
- ha érdekli a villanyszámla, akkor a Chillel egészen extrém szélsőségek között konfigurálható a rendszer fogyasztása, teljesítménye, és még nagyon alacsony lesz az input lag is ... [link] - itt ugyanazt csináltuk a kijelzőn, ugyanaz volt az élmény is, de a fogyasztás teljesen más szintPersze a legjobb, ha hagyod őt választani, és nem beszéled rá semmire.
-
Abu85
HÁZIGAZDA
válasz
velizare
#34291
üzenetére
A nagyobbak közül biztos nem. És ez egy probléma az NV-nek. Nem véletlenül módosítják ezt most. Évekig jó volt, aztán hirtelen szigorítanak, ráadásul olyan kiegészítésekkel, ami nem egyértelmű. Honnan tudja az újságíró, hogy mi az NV számára kedvező hír? Számukra az is rossz, ha valaki kiszivárogtatja, hogy a következő héten ilyen-olyan fasza funkciót kap az érkező driver. Hiába a pozitív hangvétel, ez simán megszegi az új NDA-t.
Beszéltem pár újságíróval, és lényegében az lesz, hogy számukra a teszthardverek kellenek, az NV hírek pedig le lesznek csavarva a hivatalos bejelentések szintjére. Túl általánosan fogalmaz az új NDA, hogy kockáztassanak a pletykákkal, szivárgásokkal, stb. Annyit még mondtak páran, hogy az biztos, hogy az oknyomozó dolgokat megírják továbbra is. A pletykákat el tudják engedni, az újságírói szemmel nézve nem jelentős tényező, de a többit nem. Nekem is hasonló a véleményem. Az nem különösebben hasznos az olvasóknak, hogy már év eleje óta két hónap múlva jön az új GeForce, de a GPP például fontos volt.
-
Abu85
HÁZIGAZDA
válasz
Raymond
#34289
üzenetére
Sajtó válogatja. Ha valaki megírta a pletykákat, vagy oknyomozott, ahogy a HardOCP, akkor ez nekik a világvége, de ők úgy sem írják alá, tehát végül mégsem.
Akik pedig aláírják, azok innentől kezdve jobban meg lesznek fogva. Tehát még ha a HardOCP ír is valami szaftosat, akkor azt sem lehet átemelni.
Azóta kicsit többet tudni erről, mivel vannak magyarázatok az új részekhez. A lényeg annyi, hogy az NV el akarja érni, hogy az új hardverekről csak a bejelentés napján lehessen írni. Előtte se pletyka, se szivárgás, se kódnév, se semmi, se az, hogy jön, mert ezt károsnak ítélik meg. Azt tényleg sajtó válogatja, hogy oknyomozók munkájának átvétele, illetve a pletykák megírása mennyire nagy probléma. Aki például nem írt a GPP-ről, vagy a next-gen GPU pletykákról semmit, annak az új NDA nem jelent változást. -
Abu85
HÁZIGAZDA
Annyit hozzá lehet még tenni, hogy az Intel, AMD, NVIDIA koncepciókat dolgoz ki. A hardver itt a legkevesebb, mert az számolni mindenképpen tud. Az elérés a kulcskérdés, de nem biztos, hogy azok a koncepciók terjednek el, amiket kitalálnak. Nagyon érdekes a culling, amire mindhárman kidolgoztak bizonyos megoldásokat, hogy gyorsítsák az occlusion culling folyamatot, ami egy rakás vektormatek, szóval számításigényes. Senkié sem terjedt el. Helyette jött a GPU-driven pipeline mellett a GPGPU culling. És hiába a sok kutatása a három nagy cégnek, a vezető irányzat ez lesz, és már az API-kban is megvan minden hozzá, hogy nagyon jó teljesítményű legyen (aszinkron compute, shader intrinsics/subgroups, execute indirect/indirect draw count ... a DX12/Vulkan ugyanarra eltérő neveket használ, de ugyanazt csinálják).
-
#34280
Abu85
HÁZIGAZDA
cskamacska
#34279
Abu85
HÁZIGAZDA
válasz
cskamacska
#34279
üzenetére
Amire lesz driveres megoldás azok készek. Például az IWD vagy a DSBR. Bár utóbbiból négy mód van, tehát az egyes játékok működhetnek akármelyik móddal, de a default ma már a binned.
A HSA már kész. Van rá implementáció. Itt le is tölthető: [link]
OpenCL implementáció van 2.0-ra, illetve a ROCm-ben van egy speciális hibrid OpenCL. Feljebb nem tudni, hogy mi lesz, mert a Khronos most elővette azt, hogy a Vulkant és az OpenCL-t egybegyúrja. Emiatt most mindenki ezt lesi, és várnak a fejlettebb implementációkkal, így a SPIR-V miatt az eredeti SPIR újabb verzióit nem nagyon építik be.
Az OpenCL, illetve alapvetően a HSA sem pusztán a GPU-ról szól, ugyanúgy futtatja ezeket a kódokat a CPU is. A PR nyomatta a GPU-s gyorsítást, de valójában mindig arról volt szó, hogy az adott kódrész a neki megfelelő hardveren fusson. Ez nem öli meg a CPU-t, csak valami jobb a GPU-ra.
-
Abu85
HÁZIGAZDA
válasz
#59036672
#34270
üzenetére
Szerintem sok függ attól, hogy a Vega 20-at milyen selejtaránnyal gyártja majd a TSMC. Imádkozz azért, hogy relatíve sok legyen az Instinctnek nem eladható GPU.
(#34271) gézu: Nekünk ugyan nem. Tomék, WCCF-ék, meg akárkiék bullshitjeit nem akarjuk megírni. Már év eleje óta két hónapra van a megjelenés. Most mi az aktuálisan várt dátum, június 30? Erről az egészről ez jut eszembe: [link] - egy ilyen vonatra csak a bulvárújságok ülnek fel.
-
Abu85
HÁZIGAZDA
válasz
#59036672
#34268
üzenetére
Hát ez az. Az NV eddig is rendkívül szűkre szabta a szivárgást. A pletykaoldalak kitalációból élnek, mert amiket megírtak és rákérdeztem, azokra az volt a válasz, hogy kamu. Ezért van már az év eleje óta mindig két hónapra az új GeForce megjelenése.
Ismerek olyan embert, aki tud mindent, csak nem meri elmondani, mert ezeket az információkat harmadik fél szintjén a világon alig egy tucat ember ismeri. Pont azért, hogy ha valakitől kiszivárog, akkor csak egy tucat ember lehessen a bűnös, és ott már könnyű halászni. Az AMD-nél és az Intelnél azért szivárogtatnak sokan, mert akár több száz ember is megtudhatja az új információkat egyszerre, vagyis rendkívül csekély az esélye annak, hogy valaki lebukik a szivárogtatásért. Ezzel az új NDA-val viszont még ha meg is szerezzük az infókat, akkor sem írhatjuk meg, különben ugranak majd a tesztre küldött VGA-k. Gyakorlatilag erről szól az egész, a már ma is rendkívül kontrollált rendszerük kap még egy külső védelmet. -
#34246
Abu85
HÁZIGAZDA
Petykemano
#34245
Abu85
HÁZIGAZDA
válasz
Petykemano
#34245
üzenetére
Pedig ez az a két szituáció, amikor nem éri meg kiadni. Az elsőnél azért, mert jól lehet vele keresni, míg a másodiknál azért, mert nagy veszteséget okozna. A kettő közötti állapot az, amikor ideálisan működik a piac.
-
#34244
Abu85
HÁZIGAZDA
Petykemano
#34242
Abu85
HÁZIGAZDA
válasz
Petykemano
#34242
üzenetére
Gyártó válogatja. Elsősorban a keleti gyártók küzdenek vele, akik főleg a nyugati piacot látják el, ott még ez a probléma nem ütötte fel a fejét, mert az európai bányászfarmok továbbra is jelentős pénzt raknak VGA-ba. Ezt a Sapphire-től tudom. Az anyavállalatuk még mindig több millió eurós megrendeléseket teljesít a bányászfarmok felé. De ez is befuccsol majd záros határidőn belül, ahogy a kínai bányászat tette. Valószínűleg ezért sem érinti még ez a probléma az AMD-t. Amíg ugyanis Európában a Sapphire szolgálta ki szinte kizárólag a bányászfarmokat, addig Kínában csak a TUL adott nekik Radeont, és ők is csupán az összes bányászatra vonatkozó eladás kisebb részéért feleltek. A többi tajvani gyártó GeForce-ot kínált bányászatra, abból lett extrém túltermelés. Az AMD-t valószínűleg úgy augusztus felé kezdi majd el érinteni ez a probléma.
-
Abu85
HÁZIGAZDA
Egyszerű. A JPR-nek eléggé jól kiépített csatornái vannak, így a kereskedőláncoknál vissza tudják keresni, hogy ki vette bányára. Lényegében eléggé egyértelmű, hiszen aki mondjuk egyszerre visz 4+ kártyát az biztosan bányász. Aztán azt is le tudják követni, hogy hányan vittek 2-4 között, és csak egyet. Az előbbi potenciálisan bányász, míg az utóbbi potenciálisan nem az. Erre vannak a statisztikákban hibakorrekciós modellek, amiket bevetnek. Végül lekérdezik a gyártókat, hogy mennyi VGA-t adtak el direkten a bányászoknak. Erről egészen konkrét adatok vannak. Az így kapott eredményeket összeadják és ki is jött a kívánt szám. Le van írva a teljes jelentésükben.
-
#34227
Abu85
HÁZIGAZDA
Petykemano
#34226
Abu85
HÁZIGAZDA
válasz
Petykemano
#34226
üzenetére
A Fenghuang a Polaris 10/20 helyére jön.
Most eléggé alábbhagyott a bányaláz. Csak az eladott kártyák tizede került oda idén.
Majd az új Threadripperre lesznek ráizgulva ősszel. Az Moneroban 80%-kal is gyorsabb, mint a Vega 10.
-
#34224
Abu85
HÁZIGAZDA
Petykemano
#34222
Abu85
HÁZIGAZDA
válasz
Petykemano
#34222
üzenetére
Amikor a vásárlók már nem pucolják ki a raktárakat.
(#34223) Csupingo: 125 wattba simán belefér. A csúcs Kaby Lake-G is 100 watt. Ebből a proci 45. 55 watt jön a leggyorsabb ottani AMD pGPU-ból. Persze az Intel itt érdekes skálázást is alkalmaz, így a proci képes 35 wattra csökkenteni az energiaigényét és akkor 65 wattot kap a pGPU. De ez fordítva is igaz, a proci elkérhet 60 wattot is, és akkor 40 marad a pGPU-nak. Az egész alkalmazásfüggő.
-
#34221
Abu85
HÁZIGAZDA
zovifapp111
#34220
Abu85
HÁZIGAZDA
válasz
zovifapp111
#34220
üzenetére
Nekem csak akkor fog tetszeni, ha értelme is lesz a lapkák közelebb helyezésének. Mert azért lehet igen komoly haszna is. De ha ezt nem használjuk ki, akkor inkább vesztünk.
-
#34219
Abu85
HÁZIGAZDA
huskydog17
#34216
Abu85
HÁZIGAZDA
válasz
huskydog17
#34216
üzenetére
Bele van építve az Intelnél a pGPU árába az összes licenc (engedélyezett driverfunkciók/névhasználati jogok) és a támogatás. Egyedül a tesztelést nem végzi el az AMD, azt az Intel csinálja.
Az APU-k régóta ki vannak véve a mainline driverből, és csak a WHQL részei, vagy a régebbi modellek már annak sem. Ennek az oka, hogy nagyon nagy mennyiségben kerülnek eladásra a VGA-khoz képest, ami a gyártópartnerek support költségeit extrém mértékben megdobja. Az AMD évente kiad minimum 16, de esetleg 20 meghajtót, amik minden asztali gépre települnek, és a legolcsóbb gépeknél az árba nincs betervezve az, hogy a support egy meghajtó kiadása után user errorokat teszteljen, mert a lejelentett hibák 95%-a ez, miközben a kivizsgálásuk költséges.
A fentiek miatt az AMD átállt még az előző évben arra, hogy a saját WHQL csomagjaik között a köztes meghajtók a Windows Update-en keresztül jönnek az APU-kra. Ennek az előnye, hogy nagyságrendileg csökkenti a user errorok számát, mert a Windows automatikusan megoldja, de ha nem, akkor is a Microsoft supportját ostromolja a user, és nem az OEM partnerét. -
#34218
Abu85
HÁZIGAZDA
zovifapp111
#34217
Abu85
HÁZIGAZDA
válasz
zovifapp111
#34217
üzenetére
Mivel a 7 nm-es node gyártási költsége eleve eléggé magas, így leginkább maximum ~400 mm2 közötti GPU-kkal fogunk találkozni. Ezek kerülnek majd annyiba, amennyibe a 12-16 nm-en az ~550 mm2-esek. De persze a költségeket figyelembe véve ideálisabb a 350 mm2 körüli maximum. Ez már egy nagyobb, HEDT tokozásra ráfér.
A Kaby Lake-G jóval gyorsabb a GT 1030-nál. Még az 1050 Ti-nél is jobb. De a Fenghuang Raven gyorsabb lesz a Kaby Lake-G-nél is. Az olyan 1060 szint, és az IGP. Persze elég sokat trükközik a rendszermemóriával, onnan azért sokat nyer.
-
Abu85
HÁZIGAZDA
válasz
keIdor
#34205
üzenetére
Ez bizony nagy kérdés. De alapvetően azt is számításba kell venni, hogy ha a legózási lehetőséget elveszted, akkor az OEM is veszít a választható opciók közül. Lesz Intel CPU Intel GPU-val és AMD CPU AMD GPU-val. Tehát ebben a jövőképben nem csak a gyártók keverésének kiesése a probléma. Aztán a Microsoftnak is komoly szerepe lesz itt, hiszen ahhoz, hogy az NV megmaradjon itt, a Win32 API-t ki kell vezetniük, és a támogatást mondjuk át kell rakni az Azure-ba, így a legacy applikációk futtathatók maradnának a felhőben. Ezzel már lényegtelen lenne a CPU ISA-ja, jöhetnek a Qualcomm is, és az NV a saját ARM-os cuccával.
-
Abu85
HÁZIGAZDA
válasz
lezso6
#34199
üzenetére
Nem valószínű, hogy moduláris lesz a Navi. Lesznek benne GMI-k, de egészen más célból, nem azért, hogy négyet egymás mellé rakjanak egy tokozáson, hanem azért, hogy a CPU-kkal párosítsák. Szóval a Navi esetében még biztos lesz több dizájn a teljesítményre. A proci esetében ez a "szuperglue" koncepció sokkal kedvezőbb, mert nem heterogén megoldásról van szó, de a GPU-knál azért nehezebb szétbontani a rendszert.
-
#34198
Abu85
HÁZIGAZDA
zovifapp111
#34190
Abu85
HÁZIGAZDA
válasz
zovifapp111
#34190
üzenetére
Igazából az a legnagyobb tévedés, hogy azt hiszed olyan világ jön, ahol választhatsz. Nem sajnos. Már a processzor kiválasztása meghatározza a GPU-t. Az Intel nem azért csinál dedikált GPU-t, mert hirtelen olyan nagyon fontos lett a VGA-piac, amikor évekig csak azt mondták, hogy elhanyagolható tényező. Azért lett fontos, mert a jövőben nem tudod majd odarakni a VGA-kat a procik mellé, hanem ott lesz a GPU a procival közös tokozáson. Így pedig már be kell nevezni, mert természetesen saját GPU-t akarnak a procijaik mellé párosítani. Szóval a jövő a jelenlegi útitervekben úgy néz ki, hogy ha kiválasztottad a processzort, akkor azzal jön a GPU és a memória. Később még az adattároló is. Szépen megkapod mindet a fémkupak alatt.
Ennek a legfőbb oka, hogy a CMOS-t nincs mivel leváltani. Elmegyünk 3 nm-ig, 2023-ben itt is lesz, és alapvetően nincs tovább (a 2 nm már nagyon elenyésző előnyt ad, az 1 nm pedig gazdaságilag értéktelen alternatíva). Elméletben sem lehet lépni, hacsak addigra valami CMOS alternatíva nem jön, de nem nagyon látszik semmi, ami 6-7 éven belül bevethető lesz. Szóval el kell kezdeni 3D-ben építkezni, és olyan terülteket fejleszteni, ahol van még potenciál, például a részegységek összeköttetésében. Aztán hosszabb távon, úgy 2030 környékén talán látni lehet majd valami CMOS alternatívát, amire át lehet állni. Az más kérdés, hogy a mai legózás nem biztos, hogy azzal visszatér. -
#34189
Abu85
HÁZIGAZDA
zovifapp111
#34187
Abu85
HÁZIGAZDA
válasz
zovifapp111
#34187
üzenetére
Ilyen formában biztos nem. Ez az NV-nek is egyre kevésbé éri meg. Azzal nem mennek sokra, hogy prémium fícsőrnek tartják. A HDR-es G-Sync esetében nem sok céget győztek meg. Az Acer és az ASUS, ennyi. És ez már probléma nekik, mert például a prémiumért azért egy monitorgyártó elvárná, hogy többet tudjon, mint a FreeSync 2. De ehhez képest az NV megoldásából hiányzik a direkt tone mapping, illetve a Windows bugos HDR pipeline-ját kell használni a maga lilás beütésével. Értem, hogy prémium, csak nem tudni, hogy mire? A lilás árnyalatra? A direkt tone mapping hiányában a nagyobb késleltetésre és a kötelező kijelzőoldali tone mappingra? És akkor az ASUS és az Acer rak rá majd ezer dollár prémiumot, hogy a maguk oldalán azért ne legyen nagy kockázata ennek, így gyorsan visszahozza a beleölt pénzt, amire az európai kereskedők még raknak vagy 800 eurót, mert a luxuskategóriát luxushaszonnal árulják ugye. Legalább a Windows pipeline-ját meg kellene kerülnie az NV-nek, és akkor a lila árnyalat elkerülhető lenne, csak ez annyira körülményes, mert arra kell az NVAPI-ba egy kiegészítés, ami támogatná azt, hogy a játék egy meghajtóoldali pipeline-on kiküldje a képet, és ha már ezt megteszik, akkor amúgy mehetne rögtön a direkt tone mapping megjelenítés, tehát ott lennének, ahol a FreeSync 2, és akkor már csak arról menne a vita, hogy ér-e ez ~2000 dollárt.
Az MS-től nem tudom, hogy mennyire lehet amúgy a lilás beütésre megoldást várni. Az a vicc, hogy Xbox One-on ők is az AMD pipeline-ját használják, annyira jól sikerült a sajátjuk. -
Abu85
HÁZIGAZDA
válasz
keIdor
#34185
üzenetére
Az is elég lenne, ha csak 200 dollár lenne a felár. De manapság a kijelzőgyártók, na meg a kereskedelmi csatornák már igencsak dobálják az 400-700-1000 dollárt pluszt is rá. Nem igazán ez a hardver szabja meg már a végtermék árát, hanem az, hogy az R&D szempontjából a G-Sync a saját hasznát termeli ki. Tehát amíg az összes többi kijelző között egységesen oszlik el az azokba ölt R&D, addig a gyártók úgy döntöttek, hogy erről a G-Sync-et leválasztják. Ez számukra egy biztonsági tényező, okulva a 3D Vision halálából.
-
Abu85
HÁZIGAZDA
válasz
keIdor
#34177
üzenetére
De a notebookos G-Sync-ben sem. Nem azért van ez a hardver, mert annyira szükség van rá. A Pascal óta ki lehetne dobni a kukába, nincs szükség arra, hogy beszereljék, mert ami a Kepler/Maxwellből hiányzott, és szükségesség tette ezt az FPGA-t, az már ott van a Pascal GPU-kban.
Maga a VRR, gyakorlatilag az összes verziója egy faék egyszerű megoldás, ami a VBLANK-et (vertical blanking interval) manipulálja. Ez egy olyan paraméter, ami megadja, hogy mennyi idő telik el az előző képkocka utolsó és az új képkocka első pixelsorának monitorra való kirajzolása között. Minden esetben, minden implementáció ugyanazt csinálja, amíg nincs új képkocka, addig nem kezd bele új rajzolásba a kijelző. Erre van egy szoftver oldali implementáció, hogy a grafikus eszközillesztő kontrollálhassa ezt az értéket. Na most a Kepler ezt nem támogatta, ezért kellett a külső modul. A Maxwell támogatja, bár a működés nem változott, míg a Pascal esetében a HDR-es G-Sync már nem használja ezt a modult úgy, ahogy a korábbi hardverek, így itt már a feldolgozás végig a gépen belül marad (a'la Freesync, Adaptive-Sync, HDMI VRR). Ezért is tartott olyan sokáig kiadni a szoftvert rá, mert nem nagyon akart ez működni az FPGA-n, és az NV végül nem is erőltette, hanem inkább kizárta a munkából. Gyakorlatilag csak a licenc miatt veszi meg a kijelzőgyártó, mert HDR-es G-Sync esetében már nem működik, persze HDR nélkül G-Synchez még kell, de ehhez is lehetne írni egy olyan implementációt, ami inkább a GPU kijelzőmotorját használja. Hosszabb távon ez az ideális megvalósítás, mert számos előnnyel jár a monitorgyártók számára. Használható a GPU-ba épített képskálázás, egyedi OSD-t lehet alkalmazni, egyedi színfeldolgozással és egyedi bemeneti funkciókkal. Illetve az FPGA nélkül az NV is meg tudja csinálni azt, amit az AMD a FreeSync 2-vel. Szimplán kicserélhetik a Windows HDR pipeline-t, ami nem valami jó. Valószínűleg ez már megfordult a fejükben, amikor a HDR-es G-Sync alapjait letették. -
Abu85
HÁZIGAZDA
válasz
core i7
#34055
üzenetére
Egyre többen. Az, hogy az Ubinak már megéri, azt jelenti, hogy más is felveti a spórolás kérdését.
(#34060) core i7: Nem igazán fogsz nagy kilövést látni az AVX minimum igénnyé emelésétől. Pici sebességet talán lehet nyerni, de eddig is támogatta nem kevés játék ezt az ISA-t, miközben megtartotta az SSE4.1-et is. És a Gulftown mondjuk nem maradt le igazán. Szóval ez csak egy ISA, nem fog az erőviszonyokon orbitális mértékben változtatni. Annyit tudok elképzelni, hogy ha ennyire minimum igény lesz, akkor az Intel a következő körben tényleg berakja minden CPU-jába.
-
Abu85
HÁZIGAZDA
válasz
core i7
#34051
üzenetére
Egyszer biztos. Talán úgy 7-10 év múlva. Most az AVX-en a sor. Elég nagy a felhasználóbázis, a kétmagos penyákat már a magszám miatt sem kell számba venni, és a konzolok is támogatják. Nincs igazán sok ellenérv az AVX kapcsán. Az SSE4.1-nél pedig ellenérv lehet a tesztelési költség, amit ennek az ISA-nak a támogatása jelentene. Gondolom ez téged nem vigasztal, de végeredményben ez lassan egy gazdasági kérdéssé válik. Megéri-e az SSE4.1-et azért a maréknyi játékosért támogatni, akik amúgy megfelelnének a magszámra vonatkozó követelménynek (ami ugye manapság minimum 4), de annyira régi a procijuk, hogy az AVX-et még nem támogatja.
-
Abu85
HÁZIGAZDA
válasz
FLATRONW
#34048
üzenetére
Igazából ahhoz van köze, hogy az új konzolok is AVX-et támogatnak, és eleve egy minimum igénnyé kezd válni a négy mag, tehát az se számít, hogy sok újabb Celeron és Pentium nem támogatja. Emiatt egyszerűbb csak az AVX-re fejleszteni, mert ha már visszaportolod mondjuk SSE4.1-re, akkor azzal a tesztrészlegnek igen nagy extra munkát adsz, és minden egyes jövőbeli frissítésnél ezt az extra tesztelési munkát hordozod magaddal, ami összességében nem kevés pénz lesz ám. Emiatt ha már úgyis négy mag a minimum, akkor a stúdiók egyre inkább húznak az AVX-hez is egy vonalat, mert a kétmagos AVX-es nélküli gépek már a magszám miatt kiesnek. A régebbi, sokmagos gépek pedig túl régiek, hogy ezekkel törődjenek.
A másolásvédelem nem kifejezetten kötelezné az AVX-et, de persze ha már a motor eleve ezt igényli minimum, akkor nyilván kérhetnek olyan verziót, ami ehhez igazodik. De sose a másolásvédelem határozza meg az erre vonatkozó igényeket.
Tudom, hogy 4-6 magos AVX nélküli procival nem vígasz, de maga az AVX 7 éves, és mindkét nagy konzol támogatja, tehát alapvetően várható volt, hogy előbb-utóbb abszolút minimum igénnyé válik a PC-n belül.(#34045) Keldor papa: A Dunia limitál? Durva lenne, hiszen háromszor nagyobb terhelésre van felépítve, mint az összes korábbi motorja az Ubinak. Megközelítőleg sem jár most ott az aktuális AnvilNext vagy Snowdrop, ahol a Dunia jelenlegi verziója. Mondjuk az is igaz, hogy az AnvilNext és Snowdrop nem is alkalmaz GPGPU cullingot, míg az új Dunia igen, meg egy rakás más trükköt. Emiatt tud most részlegesebb világot megjeleníteni. Valószínűleg ezt a fejlesztést minden más motorjába beépíti majd az Ubi, csak ez azért időbe kerül.
-
#34034
Abu85
HÁZIGAZDA
Petykemano
#34032
Abu85
HÁZIGAZDA
válasz
Petykemano
#34032
üzenetére
Senki sem hibás itt. Pletykákat lehet írni és linkelni is. Semmi gond nincs velük, csak tudni kell kezelni őket. Még én is megírtam Tombácsi pletykáját, csak még az élesítés előtt megírta az egyik kontakt, hogy kamu, így inkább nem is jelentettem meg a hírt.
-
#34017
Abu85
HÁZIGAZDA
Petykemano
#34012
Abu85
HÁZIGAZDA
válasz
Petykemano
#34012
üzenetére
Ezek nem egyedi mérőszámok. Így lehet mérni a hatásukat, mert a grafika számítása az heterogén feladat, vagyis sok eltérő részegységgel történik az egész és/vagy eltérő hardverállapotok mellett. Tehát van egy megoldás egy bizonyos problémára, amit nem tudsz kimérni fps-en, mert az a teljes képkocka számításának időtartamát méri, miközben lehet, hogy az adott technika a képkocka időtartamának az 5%-ára reagál. Tehát azt az 5%-ot gyorsítja mondjuk 50%-kal. Viszont ha az fps-t méred, akkor rendkívül félrevezető az egész, mert beleraksz a mérésbe 95%-nyi értelmetlen időt, ami csak megakadályozza, hogy megmérd az újítás előnyeit.
Mármint mert nem méred ki. A Doomnál például ki lehetett mérni, hogy az intrinsics mit hozott. Nem az OpenGL és a Vulkan különbségét láttad a Radeonon, hanem azt, hogy a Vulkan kódhoz a PSSL-ből volt fordítva a SPIR-V, míg az OpenGL kódnál maradt a GLSL.
Ezek a mai GPU-k igazából igen extrém mértékben skálázhatók. Ezek a modern ISA-k 30000+ konkurens szálat is futtatnak. Tehát igazából csak a buszrendszertől függ, hogy hány tömböt raksz a hardverbe, valószínűleg akkor sem ütköznél skálázási gondokba, ha minden multiprocesszort külön tömbbe helyeznéd. Az más kérdés, hogy hatalmas faszság lenne, de az ISA alapvetően elbírná. Ezért sincs egy jó ideje gyökeresen új utasításarchitektúra az AMD és az NV részéről, mert hamarabb futnak bele a gyártástechnológia fizikai limitjeibe, minthogy maga az ISA skálázódása váljon korlátozóvá. Legközelebb akkor lesz itt nagy változás, amikor hozzák a dinamikus erőforrás-allokációt. Ott kényszerből bele kell nyúlni a működésbe, mert a mostani ISA-k statikus módszerre vannak szabva. Ez egyébként majd egy külön izgalmas változás lesz. Egyedül a megboldogult Larrabee volt ilyen rendszer, csak hát sajnos nem tudtuk megtapasztalni az előnyeit.
(#34013) Oliverda: Nyilván ezek a dolgok csak azokat érdekelhetik, akik értik is, hogy miről is van szó.
-
#34011
Abu85
HÁZIGAZDA
Petykemano
#34009
Abu85
HÁZIGAZDA
válasz
Petykemano
#34009
üzenetére
Na most ezeket nem úgy kell mérni, erre nem véletlenül voltak olyan meghajtók az elején, amikben le voltak tiltva. A hatásukat eleve nem fps. A DSBR-t például bytes/frame-ben mérik, az IWD hatását a kontextusváltások számában, míg a DCC-t szintúgy bytes/frame-ben. Persze ehhez tudni kell, hogy miket keressen, egy szimpla tesztelő nem tudja megcsinálni. Egyrészt nincs hozzá meghajtója, illetve hiába is szerzi be a toolokat, akkor sem fugja tudni, hogy mit kell nézni.
Ők már jóval többet tudnak a Microsoft új WDDM-éről. Az erőforrásaikat inkább abba ölik, mert egy külön vásárolható kártyával szert se fogsz elérni rajta.
(#34010) Petykemano: Az AMD teljesen más. Ők már tudják használni, hiszen van hozzá egy rakás kiterjesztésük mindegyik elterjedt API-ra. A szabványos megoldás viszont más, ott már mindenki tudja majd használni, így megéri sokkal többet építeni rá, hogy több legyen az összesített sebességelőny is.
-
Abu85
HÁZIGAZDA
Azért nem atomfizika ez. A gyártópartner felé vannak rendelések bányába való VGA-kra. Szimplán odamegy a bányászó társulat, hogy ők el szeretnének vinni egy rakás VGA-t bányászni, mittomén 1 millió euró értékben.
A disztribútorok tekintetében pedig a hivatalos csatornákat azért elég jól lehet követni. A kereskedők sokszor kérhetnek visszajelzést, hogy a kisker cuccaiból mennyi VGA-t vittek el úgy, hogy egyszerre hatot vettek mondjuk. De már a három is gyanús. Ezeket visszaadod adatként, és meg is van, hogy mennyi VGA ment a bányába. Persze van némi hibaarány, de alapvetően nem annyira sok. Ha egy VGA-t veszel, akkor nem valószínű, hogy bányász vagy.(#34003) Yutani: Most nem. Most inkább csökkenőben vannak az árak. Régen valszeg azért sokkal több volt ez. Azt hiszem a Q4-ben valami 3 millió, de ezt nem tudom pontosan. Előtte valszeg volt 5-7 is. Azért a 25% már elég ahhoz, hogy küldje felfelé az árakat.
-
Abu85
HÁZIGAZDA
Direkten ők nem tudják. A gyártópartnereiktől kapott adatokra támaszkodnak. Nyilván a VGA-gyártók ezt azért elég jól fel tudják mérni, akár direkt eladásból, akár a hivatalos csatornákon kért visszajelzésekből. Ezeket kapja meg a JPR is. Nyilván az AIB nem fogja megmondani az NV-nek az AMD, és az AMD-nek az NV számait. Legalábbis hivatalosan nem, aztán fű alatt lehet, hogy megtudják.
-
Abu85
HÁZIGAZDA
válasz
Oliverda
#33995
üzenetére
Mármint melyik gyakorlatban? Ezeket az újításokat a HLSL 2017-től lehet alapvetően használni. Gyakorlati kódot max. az Xbox One látott, esetleg PC-n a Radeonok a Doomban és a Wolf 2-ben, mert ugye ott adott a SPIR-V, de az is specifikus kiterjesztésekkel. A Microsoft a shader modell 6-ba csak idén kényszeríti bele a piacot. Szóval szabványos szinten ezek igazából az idei év végétől élhetnek.
-
Abu85
HÁZIGAZDA
válasz
Oliverda
#33992
üzenetére
A GCN1 és GCN2 nem tudott SDWA-t, DPP-t, nem volt írható a skalár gyorsítótár, illetve nem volt regiszterindexelés sem. Utóbbit emulálnia kellett a fordítónak, ami sokszor nem vezetett jó teljesítményű kódhoz, míg a GCN3-tól ez natívan megoldható.
A GCN1->2 váltás volt inkább marketing, a GCN3 az nagy ugrás volt. A GCN4 alapvetően nem volt igazi előrelépés, de a kódolási sémát lecserélték, viszont az ISA képességei nem változtak. Ezt azért nem nevezik marketingnek, mert ez alapozott meg a GCN5-nek, ami szintén egy igen nagy ugrás az ISA tekintetében, hiszen bevezeti az RPM-et, plusz memória és atomi kiegészítések. -
#33993
Abu85
HÁZIGAZDA
Petykemano
#33991
Abu85
HÁZIGAZDA
válasz
Petykemano
#33991
üzenetére
A DCC, a DSBR, IWD, stb. ezek mind működnek. Régebben volt olyan driver, amiben ezeket letiltották és meg lehetett nézni vele és nélküle. Ma már ilyet nem csinálnak, mert ezt csak a megjelenésre tették meg. Az IWD-t ugye úgy, hogy a 17.50-es batchtől van.
A többit nem értem, a szuperskalárizét és a super-SIMD-et sem.
Sok dolgot nem is kell szoftverből alkalmazni, driveres. A fenti három mindenképpen. DCC-je nyilván van a Fiji-nek is. IWD-je nincs, de az leginkább ott számít, ahol a munkafolyamatok kiosztásáért felelős egység limitál, például Far Cry 5-nél, Deus Ex Mankind Dividednél mindenképpen, mert ott sok a geometria. A DSBR a tipikus tiled motorokban számít, mint a Frostbite, ott nagyon sokat 30% körüli bytes/frame spórolás van. Ez egyébként az iparágon belül a PowerVR spórolásához mérhető, a többi rendszer kevesebbet spórol, igaz azok nem is draw stream megoldások.
Nem is célozzák, hogy sikerüljön. Láttad, hogy senki sem növelte meg a VGA-kra vonatkozó gyártókapacitást, amikor halálra is kereshették volna magukat az elmúlt egy évben. Ezek a cégek írják a piacot és nem csak a résztvevői. Nekik már megvan komponálva a 2020 utáni időszak, amit kurvára nem külön megvásárolható kártyákkal képzelnek el. Ma már arra rendezkedik mindenki. Ha számítana egy kicsit is ez a piac, akkor most mindenki szolgálná ki a ti VGA-k iránti igényeiteket, mert látod, hogy mennyien várják az újakat. Ehhez képest csak az időt húzzák, pedig már nincs mire, a bányászat beállt a termelt VGA-k kb. 7%-ára. A többi már a játékosoknak megy.
-
#33987
Abu85
HÁZIGAZDA
Petykemano
#33980
Abu85
HÁZIGAZDA
válasz
Petykemano
#33980
üzenetére
Azért ritka manapság az előny clock-2-clock, mert ma már az órajel is egy fícsőr. Csak ahhoz ész kell, hogy ezt meg is értse a média. Szóval hiába magyarázza azt az Intel, az NV és az AMD is, hogy a magasabb órajel az nem úgy jön, hogy kisebb a csík és csak úgy megterem, hanem beletervezik magába az architektúrába.
Egy, azóta ex-Intel alkalmazott mondta nekem régebben, hogy több újságíró is a 2000-es évek szintjén ragadt, és nem tudják őket kirobbantani onnan, mert egyrészt nagy már a bizalmatlanság a gyártók felé, hogy biztos hazudnak (nyilván 20 évvel a hátuk mögött talán egy-két füllentésre való emlékezés erre ad is alapot), másrészt régen volt nagy clock-2-clock változás is, és ezt keresik újra és újra, de ma már hiába. A húsz évvel korábbi tapasztalataiknak viszont jobban hisznek, így a modern gondolkodásra képtelenek lettek, vagyis nem tudják elfogadni, hogy a legnagyobb teljesítményt ma konkrétan szoftverből nyerhetik a hardvergyártók is, de ehhez ugye kellenek a szoftverek is.
-
#33957
Abu85
HÁZIGAZDA
Petykemano
#33955
Abu85
HÁZIGAZDA
válasz
Petykemano
#33955
üzenetére
Mindenhol programozni kell. A semmiből nem terem kód senkinek.
Minden számolásnál ugyanazt a matekot kell követni. ALU-k száma * órajel * utasításonkénti operációk száma. Egy nyolcelemű packed dot product például 8 MUL és 7 ADD.
-
#33931
Abu85
HÁZIGAZDA
Petykemano
#33929
Abu85
HÁZIGAZDA
válasz
Petykemano
#33929
üzenetére
Kétféle irány kezd kialakulni. Az egyik a speciális, amikor magát a gyorsítót eléggé specifikusan egy célterületre tervezik, míg a másik az általánosabb felhasználás, amikor nem csak packed dot productra van kigyúrva a hardver.
Ezt többen másképp közelítik meg. Az Intel konkrétan két hardverrel. Nervana a specializált irányra, és a DL-es Xeon Phi az általánosra. Az NV egyszerűen egy hardverbe építi mindkettőt, de úgy, hogy elszeparálják a részegységeket, míg az AMD egy hardverbe építi mindkettőt, de nem szeparálják el a feldolgozókat.
Mindkettőnek megvan a maga előnye és hátránya.
Az Intelnek az lesz a gondja, hogy két hardverre kétféle szoftverkörnyezetet nehéz lesz optimálisan fenntartani, na jó nem annyira nehéz, de minimum eléggé költséges. Viszont a CPU-szerű Xeon Phi dedukcióra nem igazán gyúrható ki, mert már maga a felépítés elvisz egy rakás tranzisztort.
Az NV-nél igazából a tranzisztorköltség a gond, mert gyakorlatilag külön feldolgozókat alkalmaznak a packed dot productra, és mellette más feldolgozók vannak a tréning szakaszra.
Az AMD-nél a Vega 20-ról tudni lehet, hogy az AMD az architektúra flexibilitására épít, és mindent egy feldolgozóból oldanak meg. Ez kicsit olyan, mint amit az Intel csinál a Xeon Phi-nél, csak az architektúra nem követel meg a működéshez bazi nagy, tranzisztorzabáló gyorsítótárakat és ezekhez tranzisztorzabáló vezérlést, vagyis az implementált tudáshoz kellő mennyiségű feldolgozó is lesz. Ennek az előnye az, hogy az elérhető linux driver doksik szerint 4/8 elemű packed dot productot simán le tudsz implementálni. Dot utasítással 8 bites adatokon 1 GHz-en simán megvan ~114 TOPS. És az órajel biztos nem 1 GHz lesz. A 8-elemű módban akár a 400 TOPS is meglehet. De ha feltételezünk 1,5 GHz-et, akkor akár a 600 TOPS is. Ennek az összevont dolognak az az előnye, hogy az összes feldolgozót használhatod packed dot productra, míg az NV s saját módszerével csak a beépített feldolgozók kis részét éri el így, az Intelnek a Xeon Phiben eléve túl kevés feldolgozója van, mert az architektúra nem skálázható ideálisan. A hátrány igazából a tréning szakaszok keletkezik, mert ott igazából ezek a specifikus előnyök nem jönnek elő, mivel legalább 16 bites FP packing kell. Ott már a kevert pontosság melletti lebegőpontos számítási teljesítmény számít. -
Abu85
HÁZIGAZDA
válasz
CsonkaImo
#33903
üzenetére
Lejárt a szerződés és nem hosszabbították meg. Nem volt semmi különleges, csak nem tudtak megegyezni. Úgy tudom, hogy azért a támogatásért, amit az AMD biztosított többet vártak vissza, de az EA nem akar senkitől sem többet szimpla reklámszerződésnél, mert megvan a saját erőforrásuk a technológiai háttérhez, ezért az AMD átvitte az erőforrását a Bethesdához, a CIG-hez és az Epic Gameshez.
-
#33899
Abu85
HÁZIGAZDA
Petykemano
#33897
Abu85
HÁZIGAZDA
válasz
Petykemano
#33897
üzenetére
A DXR esetében a Microsoft két lehetőséget kínál a működésre. Az egyik a fallback layer. Ez egy olyan univerzális réteg, amit a Microsoft ír, és minden olyan legalább shader modell 6.0-t támogató hardveren futni fog, ami nem kapott gyártói réteget. A gyártóknak azonban lehetőségük van arra, hogy írjanak maguk egy saját hardver fölötti réteget a DXR-hez, amivel nem a Microsoft univerzális rétegét fogják használni, hanem maguk határozhatják meg, hogy az egyes feladatok hogyan fussanak a hardveren. Az RTX egy ilyen réteg a Volta fölé. De nem biztos, hogy ez a réteg el lesz nevezve, gyakorlatilag ez egy driver, amit nem drivernek hívnak, de ettől még egy szimpla driver.
(#33898) TTomax: A tesszelláció tökéletes példa arra, hogy mennyire tönkretehet valamit, csak itt a tesszelláció jellegzetessége miatt nem játékról, hanem effektekről lehet szó. Viszont látható, hogy például se a Hairworks, se a God Rays effekt kód nem fejlődik az NV-nél, mert maga az alapkoncepció az indokolatlan mértékű tesszellálásra épít, és ezáltal a geometry shaderre épít, amik olyan mértékben lezabálják az effektre szánt időbüdzsét, hogy a fontosabb komponenseket, a minőséget biztosító komponenseket már nem tudják hozzáadni. És itt például a Hairworksnek alapvetően szüksége lenne valamilyen OIT megoldásra, sőt, specifikus élsimításra is, hogy a jobb ütközésdetektálásról már ne is beszéljünk, csak nincs rá több tervezett erőforrás, mert elment a hardveres kapacitás olyan dolgokra, amelyek a végső képen a végleges minőségbe alig szólnak bele, de vért izzad a vas, hogy megoldja ezeket. Ez nem lenne annyira kirívó, ha nem lenne a Hairworks mellett egy TressFX, ami például nem tesszellál, geometry shadert sem használ, és gyorsabban megcsinálja a feladatot OIT, analitikai élsimítás és ma már SDF kalkuláció mellett, mint a Hairworks ezek nélkül. És ez meghatározza egy effekt jövőjét is. Ha már az alap hibás, akkor nem fogják továbbfejleszteni, mert nem tudnak mit kezdeni az erőforrásigényével, ezért nem láttuk sosem a második generációs HairWorksöt, míg a TressFX már negyedik generációs kódnál tart.
És hasonló probléma merül fel a sugárkövetésnél is. Azt nem igazán lehet optimalizálni, túl egyszerű maga a feladat, maximum paraméterezhető, hogy pixelenként hány sugár legyen, és milyen messze legyen számolva. Hasonlóan a tesszellálásnál, meghatározhatod a formátumot és a részletességet. De ha elszámolják az egészet, akkor onnantól kezdve azon kell gondolkodni, hogy a raszterizálás szempontjából mi legyen visszavéve, vagy ha a memóriaigény jelent problémát, akkor csökkenteni kell a textúra- vagy a geometriai részlegességet, mert ugye a VGA-k esetében a memória eléggé kötött, és nem minden meghajtóban van egy csúszka, hogy oda igazítsd a visszajelzett memóriát, ahol jó a programnak.Önmagában viszont a tesszelláció nem hibás például a fentiekért. Nem az eljárással van probléma, ahogy a sugárkövetés is nagyon jó technika. A tesszelláció esetében például a fenti problémákat minden esetben az emberi hülyeség okozta. Még azt se mondom, hogy szándékos hülyeség, mert lehet, hogy fiatal volt aki a projektet vezette, látszólag jó ötletnek tűnt az egész, mára meg a tanulópénzként tekint rá (főleg úgy, hogy az NV pénzét égette el). A sugárkövetésnél is ez lesz. Lehet ezt jól használni, és lehet úgy is, hogy végeredményben úgy nézd a tükröződést, a GI-t és az AO-t, hogy szép-szép, de a játék többi része öt éves szintre lett butítva. És itt jön elő egyébként az állandó vita, ami tényleg egy aktuális vita, hogy mire érdemes ezt használni. Mert igen, a sugárkövetéssel biztosan jobb lesz mondjuk a tükröződés, de mondjuk egy trükkös SSR megoldás tízszer gyorsabban hoz egy megközelítőleg jó eredményt. És felmerül itt, hogy például a játékos a játék közben észreveszi-e, hogy éppen van egy olyan doboz a jelenetben, ami pont nincs rajta a képkockán, de pont látszódnia kellene a vizes padlón a sarkának. Az ultimate kérdés tehát az, hogy megéri-e ezért az előnyért tízszer több ALU kapacitással fizetni, és megéri-e bizonyos problémák esetén az alapvető minőséget adó raszterizálásból elvenni, ami kihatással van a teljes játék grafikájára is, sugárkövetés ide vagy oda.
-
#33896
Abu85
HÁZIGAZDA
Petykemano
#33895
Abu85
HÁZIGAZDA
válasz
Petykemano
#33895
üzenetére
Nagyon szép a marketing, csak ha megnézed a DXR-t, akkor az jelenleg csak 16 és 32 bites lebegőpontos formátumot támogat. A tensor magok 8 bites fixpontos ALU-k.
Eleve az AMD mondta, hogy ők is tudnak rá drivert csinálni, GCN3-tól felfelé van is már tesztcsomag. Egyébként egy olyan dologról vitázunk, aminél a Remedy elmondta, hogy 1920x1080 pixeles felbontáson, pixelenként egy sugarat, virtuálisan maximum 4 méteres távolságig kilőve a számítások nagyjából 5 ms-ig tartanak. Na most egy sugár az nem sok, és a 4 méteres távolság sem az, tehát iszonyatosan szűk térben alkalmazható technikáról van szó, ami a 60 fps-hez mért képszámítás harmadába kerül és akkor ez csak Full HD. 4K-n ez 20 ms, ami a 30 fps-hez mért képszámítás kétharmada. És akkor még nem számoltál semmit, amit ki tudnál rakni a kijelzőre.
A packing alkalmazható a DXR-en belül, hiszen támogatott a shader modell 6.2 16 bites lebegőpontos formátuma. Persze ettől az ég óvjon minket.
Elmondom neked, hogy miért csinálják ezt a sugárkövetést a gyártók. Az AMD-nek és az NV-nek is ugyanaz a koncepció mögötte. Mindegy, hogy DXR, vagy Vulkan-féle GPUOpen, vagy egy esetleges Vulkan szabvány, a probléma az, hogy a PC-s GPU-kat a jövőben nem igazán lehet úgy skálázni, hogy ne növekedjen meg a multiprocesszor:raszter arány. Viszont ahogy távolodsz a konzolok arányától, ami amúgy 8:1 körüli, úgy lesz egyre több idle lyukad az architektúrában. Tehát tök jó, hogy megvan a GPU-ban az ALU, csak a shadereket nem olyan multiprocesszor:raszterre optimalizálták, amilyen az új, erősebb GPU-ké. Viszont a sugárkövetés egy marhára függetleníthető folyamat a raszterizációtól, vagyis meg tudod azt csinálni, hogy ezt felhasználod az idle lyukak betömésére az aszinkron compute segítségével. Ettől még mondjuk egy újabb, mondjuk 16:1-es arányú GPU nem lesz jobb grafikára, de van egy rakás szabad ALU kapacitása sugárkövetést számolni. Nagyjából ennyi a koncepció mögötte.Egyébként ez a sugárkövetéses dolog nem rossz, csak lesznek majd olyan árnyoldalai, hogy ha nem lesz meg a teljesítmény, akkor maga a sugárkövetéses rész a programon belül túl egyszerű, hogy bármit is elvegyél belőle, emellett a 32 bites lebegőpontos formátum eléggé zabálja a memóriát is (értem a 16 bit opció, csak aki látott már ilyet, az tudja, hogy nem éppen reális), miközben van erre sokkal jobb formátum is, ami pont nem támogatott. Tehát iszonyatosan kell majd a memória, ami miatt félő, hogy kisebb textúrarészletességet szállít a fejlesztő, vagy rosszabb minőségű modelleket, mert azzal a sugárkövetés memóriaigényét is levágja. Vagyis összességében többet vesznek majd el a raszterizálás minőségéből, mint amennyit a sugárkövetés egyáltalán hozzá tud tenni az egészhez. Nézd meg a Metro Exodust sugárkövetéses trailerét.
-
#33894
Abu85
HÁZIGAZDA
Petykemano
#33892
Abu85
HÁZIGAZDA
válasz
Petykemano
#33892
üzenetére
Nem alkalmasak. Maximum denoisingra jók.
-
Abu85
HÁZIGAZDA
válasz
Raymond
#33873
üzenetére
Neked, aki nem hallott róla, de a Vulkanra való átállásnál problémába ütköztek abból a szempontból, hogy nem voltak jó profilozók, emellett az NV Vulkan drivere sem volt életbiztosítás 2016-ban, amikor a munkálatok kezdődtek. Erről itt is olvashatsz bővebben: [link]
Még az id Software is küzdött ezzel, nem véletlen, hogy a Doom Vulkan frissítése több memóriát kért a működéshez GeForce-on. Az early Vulkan adoptereknek egyszerűen nem volt más választásuk, mint Radeonra váltani. Ma már szerencsére sokkal jobb a helyzet, csak mivel korábban már berendezkedtek a Vulkanra, értelmetlen visszacsinálni mindent, főleg úgy, hogy 2017-ben hozott az AMD egy nyomkövetős profilozót, amit idén integráltak is a RenderDoc-ba. Egyszerűen sokkal jobb a fejlesztői környezet, amit kínálnak. A többiek nagyon lassan léptek, és ezt az időbeli a lemaradást hordozzák. Bár az Intel drivere veszettül jó lett idénre, ez azért nagyon pozitívum a számukra. -
Abu85
HÁZIGAZDA
válasz
Raymond
#33870
üzenetére
Már egy éve lehet tudni, hogy az Epic lecserélte a gépparkot AMD-re, de ettől ez nem akadályozza meg, hogy NV-vel is mérjenek. Az AMD-vel kötött szerződésük biztosan nem zárja ezt ki. Azt persze el tudom képzelni, hogy a Vulkan kód még nem végleges, így csak az AMD-re van optimalizálva, és később veszik elő az NV-t és az Intelt. Ebben az esetben érthető, hogy miért nem közölte Vulkan eredményt a többi gyártóról.
Egy szálra kényszerítve mértek, ott pedig nincs nagy különbség a DX11-es driverek között.
-
Abu85
HÁZIGAZDA
Unreal Engine 4 update a Vulkan leképező állapotáról. [link]
Rolando Caloca (ő írja a Vulkan leképezőt) szerint a uniform buffer stratégiájukkal verik a DX11-et egy szálon is:
"Infiltrator Editor
D3D11: 46.83ms / 21.28fps
Vulkan: 36.75ms / 28.15fps
Infiltrator Demo, wide city view
D3D11: 30.36ms / 29.79fps
Vulkan: 13.62ms / 38.08fps"
(Úgy látom egyelőre csak AMD-s eredmények vannak.) -
Abu85
HÁZIGAZDA
válasz
Dandris
#33847
üzenetére
A Hynix a beszállító. Velük van szerződése az NV-nek. A HBM2-t is tőlük veszik. A Hynix leplezte le amúgy az új sorozatot, még amikor bejelentették a GDDR6-ot. Elárulták, hogy az egyik GPU-gyártóval már exkluzív szerződésük van egy 384 bites memóriabuszú VGA-ra. Az, hogy a Samsung hogyan áll irreleváns. Ezekből a szerződésekből nem egyszerű kibújni, maximum büntetéssel, de nem valószínű, hogy a teljesítmény számít, mert a Hynix lehet, hogy ki tudja őket szolgálni, míg a Samsung lehet, hogy nem. Mint írtam korábban a tömeggyártás nem azt jelenti, hogy sokat gyártanak, hanem azt, hogy a gyártósor véglegesítve van. Attól még gyárthatnak 10-et vagy egymilliót is. Mindkettőt tömeggyártásnak értelmezik.
A TSMC 7 nm-es node-ja is tömeggyártás szintjén érhető el. Mégsem gyárt még senki 7 nm-es lapkát tömeges szinten. Egyszerűen csak annyi van, hogy a gyártósor végleges, készen áll a tömegtermelésre, de a megfelelő mennyiséget fizikailag is ki kell építeni, azt pedig a gyártók akkor teszik meg, ha van is igény.
-
Abu85
HÁZIGAZDA
válasz
Dandris
#33842
üzenetére
Ne csak országosan gondolkozz, hanem globálisan.
A kísérleti gyártás fázisában egyébként nem ritka ez a jelenség. A gyártósorokat addig nem kezdik építeni, amíg nem véglegesítik azt. Ugye sokkal drágább lenne egy csomó gyártósort módosítani, mint megvárni a specifikálást, majd arra építve felhúzni a szükséges mennyiséget. A következőképpen zajlik ez. Lesz egy szűk számú gyártósor, ahol megy a kísérleti gyártás, majd onnan egyszer lesz egy véglegesítés. Innentől számít a tömeggyártás, még akkor is, ha baromira kevés a gyártósor. Ezután a leadott rendeléstől függően építik ki a többi gyártósort. Ezzel úgy 3-4 hónapos idő megy el a gyártást is beszámítva, és ekkorra lesz elég lapka. Ezt sehol senki nem tudja gyorsabban, mert ennyi időbe telik a bevezetés. Maximum arról dönthet a megrendelő, hogy piacra dobja-e a terméket korlátozott mennyiségű ellátással.
-
Abu85
HÁZIGAZDA
válasz
Dandris
#33837
üzenetére
Mint írtam a kísérleti gyártás során kezdték el árulni. Őszre csak a szükséges mennyiségű készlet jött belőle, mert több GDDR5X-et gyártott a Micron.
A Cannon Lake-et is lehet már vásárolni, de olyan limitált a készlet, hogy alig épít rá valaki terméket. Azt hiszem, hogy az Intel az egyetlen, de ebben nem vagyok biztos. Az, hogy valamit elkezdesz árulni, az nem jelenti, hogy az igényeket is ki tudod szolgálni a készlettel.
-
Abu85
HÁZIGAZDA
válasz
Dandris
#33835
üzenetére
Nem volt az nagy jóslat. Az NV akkor kezdte el forgalmazni a GTX 1080-at, amikor a Micron még kísérleti gyártásban volt a GDDR5X-szel. Természetes volt, hogy őszre megnőtt a gyártott mennyiség száma, hiszen a gyártósor véglegesítése után jóval többet üzemelnek be, mint amennyit használtak a kísérleti gyártásban.
A GDDR6-tal sincs ilyen szempontból probléma. A Hynix a kísérleti gyártás fázisát viszi, és valószínűleg a nyárra a gyártósort véglegesítik is. A probléma sokkal inkább az, hogy GDDR6-ból nem fognak annál több gyártósort építeni, mint amennyiben megegyeztek a megrendelőkkel. Nagyobb az esély arra, hogy a legtöbb partner nem ilyen memóriát választ. És itt jön elő a kartelezés problémája, ugyanis a teljes gyártókapacitás szűkös, köszönhetően annak, hogy nem követték a memóriagyártók a piaci igényeket, így pedig nem is készültek fel arra, hogy optimálisan kiszolgáljanak mindenkit. Ez a fő oka annak, amiért az NV folyamatosan hozza azokat a VGA-kat, amelyekről spórolják le a GDDR5 lapkákat. Nincs elég, a lapkából már elég sok van, a GP104 hegyekben áll, de nem tudják eladni őket memória nélkül. Ott próbálnak GDDR5 lapkákat nyerni, hogy a legnagyobb felvásárlóknak butított termékeket szállítanak most. Négy butított GTX 1050-en megspórolnak négy GDDR5 lapkát, ami plusz egy GTX 1050 a retail piacra.
-
Abu85
HÁZIGAZDA
válasz
keIdor
#33798
üzenetére
Nem. Nincs különösebb baj a memóriával, a gond az, hogy iszonyatosan hiány van a többi memóriából, és a memóriagyártók nem a GDDR6-ot tartják prioritásnak, amikor a többi megrendelést is ki kell szolgálni. Szóval rendkívül torz most a piaci megjelenés ilyen szempontból. Még ha kész is az első ilyen hardver, akkor sem éri meg kiadni, annyira kevés a memória hozzá, ez pedig még az árat is felnyomja.
-
Abu85
HÁZIGAZDA
Mit teszel rá? A GDDR5 rendkívül sokat fogyaszt, a GDDR6 pedig túl drága.
Az Xbox One a textúrákat a host visible flaggel ellátott memóriában tárolja. A GPU egyszerűen csak kiolvassa és kész. Az adat egyébként nem csak textúra, hanem rengeteg puffer is. Ez a probléma a PC-vel, hogy oda streamelni kell a textúrát is a host visible memóriából, és ezen a ponton vesztesz el egy rakás hatékonyságot, mert nincs szükséged arra a rakás allokációra, hanem azokból kell az allokációk egy része. De nem tudod csak úgy ezeket beolvasni, így pedig másolgatni kell a teljes allokációt. Effektíve költesz rá ~8 GB-nyi memóriát, miközben a valóban fontos adat igazából ebből ~3 GB csak, de nem tudod elérni, hogy csak ezt másolja be a hardver, muszáj hozni a szükségtelen adatokat is.
-
Abu85
HÁZIGAZDA
32 GB-nyi HBM2 jelenleg 400 dollárba kerül minimum. Emellett ehhez 4096 bites busz kell. Mit csinálsz mondjuk egy középkategóriás VGA-n, amire elég az 1024 bites busz? Oda reálisan egy ~40 dolláros 4 GB-os stack az ideális.
Ha jól megírják a programokat, akkor 4 GB is bőven elég lenne, de a legtöbb fejlesztő, csak bevágja a DX12 RSL-t, vagy a Vulkan VMA-t. Ezek megfelelő háttérmunka nélkül csak működnek, de borzasztóan pazarolnak. Szóval messze nem az a baj, hogy nem lehetne megírni jól a programokat, hanem az, hogy nem írják meg. Félelmetes az, hogy a Rise of the Tomb Raider Xbox One X-en 1,2 GB-tal elvan. Ennyi device_local flaggel ellátott memóriát használ GPU. PC-n ugyanez 5-6 GB közötti. Eközben ugyanazt éri el, csak nagyságrendekkel szarabb az allokációk kezelése.
A HBM már csak a GDDR5-nél drágább. A GDDR5X-nél és a GDDR6-nál már olcsóbb. Jóval kevesebb lapka kell a megfelelő sávszél eléréséhez.
-
Abu85
HÁZIGAZDA
válasz
keIdor
#33792
üzenetére
Ez véleményes. Kérdés, hogy a Titan V-t hova számolod. Elvégre lehet rajta játszani.
A HBM-mel egyébként az a problémája az NV-nek, hogy kevés memória építhető a GPU mellé. Nekik nincs HBCC-jük, hogy ezt a problémát csak egy driverbe épített csúszkával kezeljék. Fizikailag kell a memória, és a GDDR6-ből így több használható. Ez a HBM-nek az összes előnyét felülírja a nézőpontjukból.
-
#33788
Abu85
HÁZIGAZDA
Petykemano
#33786
Abu85
HÁZIGAZDA
válasz
Petykemano
#33786
üzenetére
GPGPU felé azért mennek most, mert az mindenkinél van. Tehát ha írnak egy GPGPU-culling megoldást, akkor az kompatibilis az összes konzoltól kezdve, az összes compute shadert támogató GPU-n át, az összes compute shadert támogató IGP-ig. Egy irtó univerzális megoldás multiplatform szinten, még akkor is, ha van nála jobb. Emellett fejleszthető is. Egyszer megírod, és a "hovatovábbal" ráérsz majd két év múlva foglalkozni. Addig optimalizálod, beépíted a subgroup/wave intrinsics függvényeket, kihelyezed asszinkron computera. És ezektől még a módszer univerzális jellege megmarad.
Ha nem egyezik meg a piac, és mindenki lezárja magát a saját linkjére, akkor eleve megszűnik a gyártók keverése. Nem is tudsz majd VGA-t venni. Megkapod a GPU-t a CPU-val közös tokozásban. Az meg tökmindegy, hogy háromféle link van. A program oldaláról ezzel nem kell különösebben foglalkozni. A leglassabb sebessége is messze több, mint amire ma képes a PCI Express, de még a készülő 5.0-t is felülmúlja, és akkor ezek is gyorsulnak a jövőben.
Oké most ez teoretikus lesz. Tehát amerre megy a Microsoft, és amilyen jól működik a texel shading, én egyáltalán nem tartom kizártnak, hogy a PCI Express és a gyártók külön linkjei jól el lesznek egymás mellett. Legalább az asztali szinten. Mobilban nem, ott túl kicsi a hely, de asztalon simán meg lehet csinálni azt, hogy veszel egy Intel vagy AMD procit, ahhoz jár ugye a GPU a tokozáson, és az már egy komplett rendszer. De teszem azt egy texel shading leképezőt használó játéknál az árnyalási fázis függetleníthető a raszterizálástól, tehát azt szépen szétszedi a program, és a fő GPU-d marad a tokozásban, míg az árnyalásra befogsz egy VGA-t a PCI Express porton, de akár befoghatsz 20-at is. Maga a texel shading marha jól skálázódik. Ugyanígy a sugárkövetés. Az is egy nagyon jól függetleníthető feladat. Nem kell azt azon a GPU-n elvégezni, ami éppen a képet rakja ki a kijelzőre, és ennek a skálázódása is igen baráti. És itt lehet igazából keverni a gyártókat is. Láthatod az AotS-t, az is támogat multi-GPU-t AMD+NV rendszeren, tehát technikailag ennek nincs akadálya. Az más kérdés, hogy üzletpolitikailag x gyártó mondhatja azt, hogy az én piacomon y gyártó nem szívesen látott szereplő. De tényleg, a szoftver oldaláról sok dolgot lehet csinálni, még akár nem is jelent ez jelentős többletmunkát.
-
#33785
Abu85
HÁZIGAZDA
Petykemano
#33781
Abu85
HÁZIGAZDA
válasz
Petykemano
#33781
üzenetére
De belehet, csak ott kellene alkalmazni valamilyen heterogén több GPU-s menedzsmentet. És ott nincs mihez kezdeni a rendszerrel, ahol nincs IGP, vagy le van tiltva.
A primitive shadert még be sem építették egy API-ba sem. Annak egy igen leegyszerűsített modelljét alkalmazza például az id tech 6.5. Az se rossz egyébként, alapvetően a primitive shaderrel használható pipeline a culling szempontjából nem tud sokkal többet, mint az id tech 6.5-nél az a modell, hogy az input assembler után rögtön jön egy compute shader lépcső még mielőtt egy csomó nem látható geometria eljutna a vertex shaderbe vagy ezen túlra. A primitive shader elegánsabban kezeli a problémát. Nem kell csúnya compute kódokat írni a működéshez.
(#33782) Loha: Ha elkezdenék butítani a játékmenetet, akkor több munka lenne az egész játék áttervezésével, mintha eleve úgy dolgoznák ki az egészet, hogy minden platform leggyengébb pontjaihoz igazítsák a dizájnt.
(#33783) Raymond: Költői volt a kérdés. Nyilván tudja mindenki, hogy nem igazán fér bele a szűkös időkeretbe a CPU-GPU-CPU-GPU round-trip.
-
Abu85
HÁZIGAZDA
És hogyan adsz ki egy olyan multiplatform játékot PC-n, ami mondjuk alkalmaz a PS4-en visszaírást a CPU memóriájába? Meg sem fog mozdulni. Nem elég gyors az összeköttetés, hogy működjön. PS4-en persze működni fog, de akkor már nem multiplatform játékról van szó. Szóval PS4-en is csak az exkluzív játékok mennek el addig, hogy erősen terheljék a CPU és az IGP összeköttetését, illetve hogy használják a megosztott memóriát.
Azt értsd meg, hogy minden gyártó megcsinálta a maga kis memóriakoherens és egyben igen gyors összeköttetését. Az Intel az UPI-t, az AMD a GMI-t, az NV az NVLinket. Nem azért, mert volt egy rakás felesleges mérnöki kapacitásuk, hanem mert kellett.
-
Abu85
HÁZIGAZDA
CPU visszaírásra. Számos olyan technika van ma, ami nem azért alakult ki, mert ez a jó, hanem azért, mert szűk a CPU és a GPU közötti kapcsolat. Például a GPGPU-culling nem azért terjed a Frostbite, az id tech, a Dunia, stb. motorokban, mert annyira szuper minden kivágási munkát a GPU-ra rátolni. Bizonyos feladatok jobban illenek a CPU-ra, de hiába gyorsabb ezekben, ha közben a pipeline egyirányú, tehát a visszaírást mindenképpen el kell felejteni. Ebben az esetben az dönt, hogy összességében mi a gyorsabb. Ha egy adott feladatban mindent a CPU csinál, vagy ha mindent a GPU. Az teljesen mindegy, hogy a hibrid modell sokkal jobb lenne, mert kevés hozzá a PCI Express. A GPGPU-s irányokkal sem lépünk igazán előre, csak nem a bal kezünket harapdáljuk, hanem a jobbat. Utóbbi pedig picit jobb, van aszinkron compute lehetőség, tehát ez még fejleszthető. De következő körben már tényleg nincs hova lépni. Muszáj magát az alapproblémát kezelni, vagyis a szűkös buszt. És ezen a primitive shader sem igazán segít. Az is csak egy 2000-es években kialakított rendszert cserél jóval modernebbre, nyersz vele maximum egy-két évet, de nem fogja önmaga megoldani a szűk busz problémáját.
-
Abu85
HÁZIGAZDA
válasz
TTomax
#33769
üzenetére
Nem pont a VGA a limit. Leginkább az API. Volt régebben egy előadás, hogy a DX12 és a Vulkan API-val igencsak taccsra lehet vágni a PCI Express 3.0 x16-ot is. Egyszerűen a legacy API-kban máshol voltak a hardveres korlátok, és sok dolog nem jött elő, amelyek az új API-kkal problémásak. És nem kell ehhez szupergyors VGA. Szóval valóban, amit most látunk az leginkább egy kényszerű tényező. Azért nem érezzük a PCI Express-t limitnek, mert a programok úgy vannak elkészítve, illetve effektíve butítva, hogy ne legyen limit, mivel a user nem tud vele mit kezdeni.
-
Abu85
HÁZIGAZDA
válasz
keIdor
#33756
üzenetére
Mert a 16 GB/s már borzalmasan kevés. A 32 GB/s csak szimplán kevés lesz, mire megjelenik. Önmagában ezzel, hogy fejlődik nincs baj, de egyrészt nagyon lassan, és gyakorlatilag csak a teljesítmény növelése a fő cél, holott azért ma már a memóriakoherencia is eléggé fontos lenne.
Én azért remélem, hogy nem tűnik el, mert ha a Microsoftnak bejön ez a Ray-tracing vonal, akkor azt nagyon jól ki lehet helyezni ám külön GPU-kra. Effektíve ilyenkor a Ray-tracing effekt bekapcsolásáért veszel még két GPU-t és kész, mellette meg lehet ott a fő GPU a CPU mellett.
Még lehet itt leképező szintű változás is. Ha mondjuk áttérünk texel shadingre, akkor az is iszonyatosan kedvezne a több GPU-nak, és akkor a PCI Express jó szolgálatot tehetne, hiszen a shading fázisok jól elkülöníthetők lennének.
-
Abu85
HÁZIGAZDA
válasz
TTomax
#33752
üzenetére
Nem tudod a PC-t úgy fejleszteni, hogy a CPU-k 10+ maggal rendelkeznek, a GPU-k 10+ TFLOPS-osak, a memóriák elérése a CPU oldaláról 80, míg a GPU oldaláról 500 GB/s is lehet, és eközben a PCI Expressen keresztül egy nem memóriakoherens kapcsolat érvényesül 16 GB/s-mal. Még a PCI Express 4.0 32 GB/s-ja is kevés lesz. Ahhoz, hogy értékelhető mértékben gyorsíts mindenképpen radikális lépés kell. Egy memóriakoherens, legalább 100 GB/s-os kapcsolat. Az már nem feltétlenül szükséges, hogy a GPU beköltözzön a CPU mellé. Ez csak abból keletkezik, hogy az Intel, az AMD és az NV nem tud megegyezni egy memóriakoherens és nagyon gyors szabványról.
-
Abu85
HÁZIGAZDA
-
Abu85
HÁZIGAZDA
válasz
cyberkind
#33748
üzenetére
Én abszolút emellett állok, de előbb azért meg kellene egyezni, hogy mi legyen helyette. Az nem jó, hogy az Intel UPI-t akar, míg az AMD GMI-t. Persze az Intel GPU tudja támogatni az UPI-t, az AMD GPU a GMI-t, de mi van a keveréssel? Egy GMI-s GPU nem működik UPI-s procival és fordítva.
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.
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.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
), pedig alig hajtottuk, aztán kiderült, hogy nem egy strapabíró szerkezetek sajnos, más is panaszkodott rájuk. Igazából, ha nagyon számít a hely, akkor persze megvehető, de inkább egy normál. Nem sok különbség van az árban, és kevesebb rájuk a garis panasz.
Ú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.
- Samsung Galaxy Watch8 - Classic - Ultra 2025
- Formula-1
- Filmvilág
- Apple iPhone 17 Pro Max – fennsík
- Azonnali alaplapos kérdések órája
- Milyen hagyományos (nem okos-) telefont vegyek?
- Nyíregyháza és környéke adok-veszek-beszélgetek
- Path of Exile (ARPG)
- Genshin Impact (PC, PS4, Android, iOS)
- A Razer új klaviatúra-zászlóshajóját meglátva biztos félrenyeled a teát
- További aktív témák...
- ÁRGARANCIA!Épített KomPhone Ryzen 7 5700X 16/32/64GB RAM RTX 3060 12GB GAMER PC termékbeszámítással
- HIBÁTLAN iPhone 12 Pro 256GB Graphite-1 ÉV GARANCIA - Kártyafüggetlen, MS4518, 100% Akksi
- 360 áthajthatós! Dell Latitude 5330 2 in 1 i7-1265U 10magos! 16GB 1000GB 13.3" FHD 1 év garancia
- OnePlus Nord CE3 Lite 128GB, Kártyafüggetlen, 1 Év Garanciával
- GYÖNYÖRŰ iPhone 13 Mini 128GB Blue -1 ÉV GARANCIA - Kártyafüggetlen, MS4066, 94% AKKSI
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest