- Rendkívül ütőképesnek tűnik az újragondolt Apple tv
- NVIDIA GeForce RTX 4080 /4080S / 4090 (AD103 / 102)
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- OLED TV topic
- Milyen egeret válasszak?
- Fejhallgató erősítő és DAC topik
- HiFi műszaki szemmel - sztereó hangrendszerek
- Házimozi haladó szinten
- Miniképernyős, VIA-s Epomaker billentyűzet jött a kábelmentes szegmensbe
- AMD GPU-k jövője - amit tudni vélünk
Hirdetés
-
Olcsó 5G-s ajánlatot nyújt a Realme Indiának
ma Megérkezett a Realme C65 5G, az első készülék a MediaTek Dimensity 6300-zal.
-
SMITE 2 - Napokon belül indul a zárt alfa teszt
gp Több mint egy tucat karaktert próbálhatnak ki a szerencsésebbek, a teljes listát a május első napján esedékes streamben árulják el.
-
Ülésezik a hardveregylet
ph Az irodai készülékek és monitorok társaságát egy ház, egy egér és egy DAC egészíti ki.
Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
A Cascade Lake 14 nm-es node-on készül.
A Cannon Lake valódi 10 nm. A következő az Ice Lake lesz, ami 10 nm-en jön, de mostanában nem jegyzik az útiterveken. Ez mondjuk nem azt jelenti, hogy nem jön, hanem inkább azt, hogy nem tudnak becsült időpontot rá.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Igen tuti. Ott vannak a gyártóknál a Xeon minták.
Jelen pillanatban az Intel sem számol azzal, hogy 2019 előtt be tudják indítani a 10 nm-es node esetében a tömeggyártást. Idén ezzel nem tudnak már mit kezdeni. Ezt a pénzügyi konferencián árulták el. Azt sem tudják megmondani, hogy 2019-ben mikor lesz tömeggyártás, mert csak évszámot adtak meg, de se negyedévre, se félévre vonatkozó előrejelzés nincs. Valószínűleg ők se tudják ezt biztosan.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Mert a Ryzennél már nincs klasszikus CPU-hőmérséklet. Egyedül a burkolati hőmérséklet van értelmezve, ami viszont nincs is egy asztali gépnél, vagyis ezt a BIOS szimulálja. Emiatt óriási lesz a különbség a valós hőmérséklet és a szoftver által kiolvasott adat között, mivel nem mindig kompenzálja a szoftver a burkolati hőmérsékletre vonatkozó adatot. Valóságban nem is lehet kompenzálni, maximum megpróbálni. Szóval a CPU-hőmérséklet szoftveres kiolvasása a Ryzennél nem lehetséges.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Igen, csak az offset sem pontos. A kompenzációt nem elég simán csak úgy számolni, hogy -20 vagy -10 fok. Sajnos ezekkel az AVFS rendszerekkel nagyon nehéz zöld ágra vergődni.
(#33) Dandris: Ez nem érdekes, hanem a normális működés alapja. A szimulált burkolati hőmérséklet, mint adat nem jelenti azt, hogy nem mér a proci semmit. A hűtőtől változik a hőmérséklete, amitől változik a burkolati hőmérséklet is. Ezt egy mobil eszköznél valóban kimérik, míg egy asztali gépnél csak egy számítással szimulálják. Viszont megszerezni a proci belső használatra mért értékeit nem lehet. Eleve van benne kb. 20 hődióda és majdnem 1300 path monitor. Nem nagyon tudnál az adatokkal mit kezdeni, még ha az AMD engedné is, hogy lásd.
(#32) Dandris: Minden újabb Zen magot használó Ryzen throttlingol. Az a Precision Boost 2 és az XFR 2 célja, hogy sose álljon be az órajel alapra, hanem mindig keresse a beállítható extrát, ha csak 25 MHz az, akkor annyit, de mindig menjen az órajel el a határig. Ettől olyan gyorsak multi-thread környezetben.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Igen, bár az összefüggés fordítva van. A lényeg, hogy az egész AVFS rendszer azért van, hogy a processzornak ne kelljen fix egymagos, kétmagos, x magos turbót megadni. Van egy alapórajel, egy Boost órajel és egy XFR órajel, de az újabb Zen magoknál ez nincs mennyiséghez kötve. Ha a hőmérséklet éppen engedi, akkor akár az összes magot fel tudja vinni a processzor a specifikációban megadott Boost órajel fölé. És minél jobb a hűtőd, minél kedvezőbb a hőtérképe a procinak, annál több esetben meg tudja ezt tenni. Ez a titka a Ryzennek, itt rengeteg teljesítményt nyernek. A régebbi prociknál, ha beterhelted az összes magot, akkor nem is engedett turbózni, akkor sem, ha elméletben lehetett volna, fixen állt az órajel alapon.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
emeritusz
#47
üzenetére
Itt arról van szó, hogy egy gyártástechnológiát nem lehet jellemezni egy számmal. Sokkal több paraméter van, amit leadnak az ISTR-nek a gyártók, és ezek alapján az ISTR besorolja valamelyik osztályba az adott node-ot. Tehát nem a gyártó dönti el, hogy mi kerül a nanométer elé. Persze ki lehet emelni a leadott paraméterek közül egy-két adatot, de az kb. ugyanannyira torz képet eredményez, mint a nanométer előtti szám.
A gyártástechnológia azért nehéz ügy, mert maga a téma nagyon bonyolult ahhoz, hogy ezt különösebb magyarázat nélkül a felhasználók elé tárd. Az Intel csinálta ezt évekig, egy olyan egyszerű üzenettel, hogy a nanométer előtti kisebb szám a jobb. És ennyit megértett a világ, mindenkibe ez rögzült. Ettől függetlenül bődületes baromság, viszont ha megkérdezel valakit, akkor valószínűleg azt fogja mondani, hogy a kisebb szám a jobb, tehát az Intel sok évig sulykolt üzenete elérte a célját.
Az egy másik kérdés, hogy az eredeti Otellini-terv szerint a tick-tock módszerrel az Intel már egy ideje 7 nm-es lapkákat gyártana EUV-vel. De ugye jött Krzanich...(#54) Keldor papa: A TSMC gyárt most 7 nm-en, de EUV nélkül. A GloFo kapásból EUV-s 7 nm-t hoz, csak ezt később tudják bevezetni tömeggyártásban, leginkább jövő tavaszra. A TSMC node-ja egyébként igen sok áramkörhöz jó, a beszámolók alapján nyugodtan lehet rá építeni, amíg nincs itt az EUV-s opciójuk, persze drága, ezt be kell nyelni. A Samsung is EUV-s 7 nm-t hoz, állítólag az év végére.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Ha a DX12 az első tervezett specifikációval jelenik meg, akkor az AMD-n kívül senki sem tudná támogatni a pure bindless bekötést. Egyszerűen egyetlen más hardvert sem terveztek memóriaalapú erőforrás-kezelésre. Mindegyik slotalapú. Szóval az kifejezetten kedvező, hogy a követelmények a megjelenésre teljesíthetőbb formát öntöttek. Az Intel egyébként azzal trükközik, hogy az utolsó szintű gyorsítótárat használja fel a kétmilliós limit teljesítésére, míg a processzormagokat a bekötés elvégzésére. Nem von el ez nagy erőforrást, mert a procimagok szépen bekötik az EU-kba az erőforrást, így emulációt végző binding API-t sem alkalmaznak erre. Az NV pedig írt egy emulációt végző binding API-t, amit maga a DirectX 12 nem tilt, ennek az eldurvuló regiszterhasználat lesz az ára, de a gyártó el tudja dönteni, hogy megéri-e vagy sem.
Egyedül a resource heap követelményeket nem dolgozták át. Oda valóban valamilyen emuláció nélküli pure bindless kell, vagy az Intelnek az a gyorsítótáras, procimagos trükközése. És látod, hogy ez mit eredményezett. Az NV nem tudja támogatni a legmagasabb szintet még a Voltával sem. Szóval a Microsoft nem ilyen ezzel-azzal kicseszek szándékkal változtatja a speckókat, éppen ellenkezőleg.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A bekötés magának az API-nak a része. Maga a bindless a DX12-nek az alapvető modellje. Amikor a Microsoft megszabta a bindless specifikációkat, akkor két modellt különítettek el. Egyet kapott az NVIDIA, leginkább azért, mert külön kérték ezt, és természetesen bekerült az alapvetően tervezett pure bindless koncepció, amit tulajdonképpen az Xbox One-ra szabtak, de ezáltal nyilván a GCN is jó, és az Intel is támogatta a Gen9-cel, mert ezt is finomították a véglegesítésre. Ezek alatt van egy kompatibilitási szint, ami gyakorlatilag egy CPU-n futó binding API. Ilyenkor a meghajtó elhelyez egy erőforrás-leírót egy tömbbe. Amikor a wave-ek elkezdenek futni a multiprocesszoron, ezt a tömböt fogja a multiprocesszor igényelni. Ennyi lényegében a bekötés. De a probléma az vele, hogy a processzor segítségére van szükség ahhoz, hogy a GPU tudja honnan kell mit betölteni a memóriából. Ezért jött be a bindless, ugyanis a Tier2-es szint, vagyis amit az NV-re csináltak, annyiban különbözik, hogy az SRV-ket és a samplereket be tudja tölteni a mintavételezőbe a branch egység. De a többi puffer view-re már a CPU kell. A Tier3-es pure bindless szint alapvetően annyi, hogy nem kell használni a DX12 binding API-ját, mert a GPU-ban van egy programozható integer skalár egység (vagy az Intel esetében maga a CPU-mag és az LLC), ami a CPU munkáját teljesen ki tudja váltani. Minden memóriahozzáférés, akár a szűrt adattal visszatérők is beleprogramozhatók a shaderekbe, mert lényegében erről szólnak a bindless szintek, hogy a CPU-t ne terheljék a fejlesztők ezzel a feladattal. Na most a programozhtóság megkövetelése miatt ezt nem tudod csak úgy fixfunkciós blokkal megoldani, ide kell egy olyan részegység, ami megcsinálja a proci feladatát, vagy trükközöl, ahogy az Intel.
Ez így mind szép és jó volt, de időközben felmerült az a probléma, hogy egy architektúrát áttenni memóriaalapúvá, igen nagy változást igényel, akár 4-5 éves tervezést is, ha előtte nem volt erre semmilyen akarat. Ezzel viszont a Tier2-es szint, vagyis a sima bindless bekötés korlátozza a hardvereket, mivel például hiába tud a Pascalnál több CBV-t, UAV-t kezelni, vagy esetleg hiába támogat minden pufferhalmaz esetében unpopulated RS bejegyzést, a DirectX 12 nem fogja megengedni neki az extra tudás kihasználását. Emiatt a Tier2-es bindless szint rendkívül korlátozóvá és haszontalanná vált.
Az NV a múlt évben átváltott a pure bindless szintre, amit a végleges specifikációkkal szerencsére nem nehéz emulálni, mert volt esze a Microsoftnak a véglegesítés előtt az emuláció lehetőségét is mérlegelni. Az NV-nek a megoldás persze valahol káros is, mert a SM-enként 4 KB-nyi vektorregisztert is bukhatnak, ami a regiszterszegény Maxwell és Pascal architektúrákban jóval több, mint az egészséges határ, de valószínűleg 10-15%-nál nagyobb büntit nem szereznek vele, és innentől kezdve a bindless motorok nem jelentenek problémát, tehát egyedül az erőforráshalmazok problémájával kell foglalkozni, mivel a GeForce-ok csak olyan halmazokat hozhatnak létre, ahol a flagek csak egy kategóriába sorolt típust engednek használni.
Szóval a bekötés magának az API-nak a szerves része, és nem véletlen, hogy még trükközés vagy emuláció árán is a pure bindless megoldásra megy mindenki.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#151
Abu85
HÁZIGAZDA
szmörlock007
#150
Abu85
HÁZIGAZDA
válasz
szmörlock007
#150
üzenetére
Elvileg egy lapkában lesz aktív. Ezzel az a baj, hogy az újítások zömét már csak emiatt is letiltják, mert nem akarnak egy lapka miatt külön platformlayert rakni a driverbe, szóval kb. behúzzák az egészet a Gen9 layere alá és kész. Így aztán hiába van a hardverben változás, a szoftver felé már el van fedve.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
CPU-n fut a binding API.
Oda tölti be az adatot. Ez egy igen speciális módszer, amit az NV kitalált a Keplernél. Alapvetően működik, mert a SRV-ket és a samplereket a binding API nélkül is be tudja tölteni a mintavételezőbe. Azt senki sem állította, hogy elegáns módszer, de megcsinálja, amire kitalálták. Nagyon sokat egyébként nem lehet tenni egy slotalapú architektúránál, annyira mélyen kellene belenyúlni a dizájnba, hogy leginkább trükközéssel lehet menni a pure bindless felé. Az AMD-nek csak azért egyszerű a dolga, mert ők amikor a nullához közeli állapotról tervezték a GCN-t, akkor eldöntötték, hogy memóriaalapú lesz, így pedig nagyon kedvező a pure bindless dizájn megvalósítása. Kell egy skalár ALU a CU-ba, ami megoldja a feladatot. Ha már kész az architektúrád, akkor rengeteg korábban meghozott döntést szükségszerűen hordozni kell a következő dizájnra is, amíg nem váltod le az egészet.
Az NV váltott implementációt. A problémájuk az, hogy hiába hozott a Microsoft nekik egy külön bekötési szintet a DX12-ben, akkor is hátrányban vannak az Intelhez és az AMD-hez képest a feature szempontjából. De a Microsoft nem törődik igazából az API alatt meghúzódó részletekkel, tehát érdektelen számukra, hogy egy TIER szint támogatását a gyártó hogyan éri el. Ezért az NV is átállt egy pure bindless megvalósításra. Ehhez alkalmaznak egy extra réteget az API alatt, ami gyakorlatilag elrejti a hardver képességeit, és megfelelő támogatást ad az API felé, miközben a különbségeket kezeli a hardver felé. Gyakorlatilag emuláció. Ezt nem kizárt, hogy az NV kérte, mert a Microsoft még az utolsó pillanatban is változtatott annyit a binding modellen, hogy egyszerűbbek legyenek a szoftveres trükkök.
A regiszterhasználat az NV szerint attól függ, hogy a program mit csinál. A legrosszabb eshetőség, ha divergens módon dinamikusan indexeli az erőforrás-leírót. Ebben az esetben maximum 16 darab 32 bites regiszter a terhelés aktív warponként. Ez a worst case. De maga shader fordító fel van már készítve rá. Ha ilyen terhelést fejthet ki egy shader, akkor limitálja az aktív warpok számát. A Volta esetében az összevont L1 gyorsítótárban is lesznek trükkök erre a működésre.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A DX12-ben binding API biztosítja az erőforrások bekötését, ha erre a hardver nem képes önmaga. Gyakorlatilag a meghajtóba írható erre egy implementáció, ami elhelyezi az erőforrás-leírókat egy tömbbe. Amikor a warp vagy wavefront, illetve általános nevén a wave futni kezd, akkor ezt a tömböt fogja igényelni elsőként, amit már a CPU-n futó binding API előkészített olyan formába, hogy a GPU megfelelően működhessen. Az adatok elérése innentől kezdve pufferbetöltés vagy textúra mintavételezéssel valósítható meg. Attól függ, hogy szűrt vagy nem szűrt minta kell.
Attól, hogy egy textúrázótól elvárható ez, még meg kell neki mondani, hogy hol vannak. Gyakorlatilag az erőforrás-leírók kvázi pointerek. Ehhez kell a binding API. Hacsak a hardver nem képes arra, hogy az esetlegesen shaderekbe programozott memóriaeléréseket értelmezze. Erre van a Tier2 és a Tier3 szint. Előbbi esetben az SRV-ket és a samplereket be lehet tölteni a binding API nélkül, mert le lehet programozni a memóriaelérést a shaderben. Utóbbi esetben pedig ez minden erőforrásra leprogramozható.
Az NV erre nem tért ki. Ők csak felvázolták, hogy ez a worst case. Ha egy shader így működik, akkor az nagyon fel tudja zabálni a regisztert. De állítólag ez még így is előnyös, mert a legtöbb esetben az újabb meghajtókba épített emulációnak pozitív hozadéka van. Csak néhány eset az, ahol hátrányos. Valószínűleg arra számítanak, hogy a fejlesztők nem hülyék, és mérlegelik ezeknek az eseteknek a használatát. Nem mondták meg, hogy mit tárolnak. Forrást nem tudok adni, ez egy telefonkonferencia volt, nem tudom, hogy felvették-e.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
Új hozzászólás Aktív témák
ph Az Intelt még az ág is húzza! Nem elég a 10 nm-es node helyzete, az első lapkával is meg kell szenvedni.
- Garanciális Intel Core i5-13600K
- Intel I5 13600KF 14mag/20szál - Új, Tesztelt - Eladó! 88.000.-
- Beszámítás! Intel Core i9-11900 Processzor - Garancia & Számla - Utolsó Darabok
- Új bontatlan, dobozos, számlás, garanciális i9 13900K CPU akció!
- Újszerű - INTEL Core i5-14600KF 14mag 20 szál 5.3GHz CPU - bolti garanciával