Hirdetés
-
IT café
A legtöbb kérdésre (igen, talán arra is amit éppen feltenni készülsz) már jó eséllyel megtalálható a válasz valahol a topikban. Mielőtt írnál, lapozz vagy tekerj kicsit visszább, és/vagy használd bátran a keresőt a kérdésed kulcsszavaival!
Új hozzászólás Aktív témák
-
Raymond
félisten
válasz lezso6 #41490 üzenetére
Nem, nem azert irjak hogy 40 mert ugy lehet a GCN-hez hasonlitani hanem azert mert 40. Amit a 10. oldalon latsz ott nem egy GCN-t hasonlit egy fel DCU-hoz hanem 1:1 az arany. A fenti RDNA abra azert van ugy hogy a ket CU kozti shared cache-eket lasd.
(#41489) meteoreső
Mielott belemerulnenk - ugye vilagos hogy az a vastagitott mondat engem igazol?
[ Szerkesztve ]
Privat velemeny - keretik nem megkovezni...
-
Petykemano
veterán
válasz lezso6 #41491 üzenetére
Vajon hogy skálázódik?
-A dual compute unit valószínűleg nem, tehát nem lesz triple compute unit.
-Egy prím unithoz tartozhat 5-nél.több DCU? - valószínűleg igen, csak az eddigi GCN-es tapaaztalatok azt mutatják, hogy egy ilyen egységben (shader unit), 10-nél több CU nem volt megfelelően kihasználható. De vajon ez változott?
- egy SE-ben 2 "shader unit" van. Lehetne több? Azzal valószíneg az ütemező (ace, hws, wgd) terhelődne túl. (Felfételezvén, hogy az ütemezés a shader enginek számával skálázódik, különben semmi értelme nincs annak, hogy egy shader engineben 2 shader unit van)
- 2.SE-nél lehet több?Nekem úgy tűnik ez az architektúra.legalja. nem.mondanám még tahitinek se, mert ott ugyan csak két se volt, de tele volt tömve cuval.
Ha minden szinten skálázható, akkor
4x4x8x2 CU érhető el. Itt persze már minden szinten szűk keresztmetszetek léphetnek fel.
Ez persze csak feltételezés részemről. De ha így van, akkor tényleg navi=scalabilityMár csak az a kérdés, hogy ebből a 2×2×5(×2) felépítésből hogy tiltanak le 4CU-t? (Ami 2 DCU)
Találgatunk, aztán majd úgyis kiderül..
-
Raymond
félisten
válasz lezso6 #41498 üzenetére
Nem koteketni, a tablazatnak nem volt ertelme. Itt a hozzaszolas amire valaszoltam:
Nem hiztak meg a CU-k ahogy a tablazatodban szerepelt, maradt a 64 ALU csak nem 4x16 hanem 2x32 felosztaban. Attol hogy aztan odairtad hogy DCU attol meg a CU-k nem hiztak amilyenre irtad es meg mindig 40 van beloluk. A 20 amirol irogatsz az a Work Processor ami 2 CU-bol all. Navi:
Navi = 4x Compute Engine
1x CE = 10 Work Processor
1 WP = 2 CU
1CU = 64 ALUA diak vilagosak, nincs mit felreerteni, de ugy latszik neked sikerult. Meg valamilyen oknal fogva kotni az ebet a karohoz is.
Privat velemeny - keretik nem megkovezni...
-
Raymond
félisten
válasz lezso6 #41506 üzenetére
"A legkisebb egységet hasonlítottam össze, ami a SIMD motorokat tartalmazza."
Ennek. A legkisebb egyseg a CU. A 64 ALU-s CU. Az eredetileg SIM0-SIMD3 lett most SIMD0-SIMD1. Amin az 1x Wave64 @ 4 cycle helyett lett 2x Wave32 @ 1 cycle. Nem szelesedett semmit a CU.
Privat velemeny - keretik nem megkovezni...
-
titán
válasz lezso6 #41560 üzenetére
A naviról tényleg nem tudunk sokat, a super viszont faék egyszerűen számolható. De navinál elfogadtam az amd saját méréseit, pedig kétkedve kellett volna fogadnom, elfogadom a kritikát. Átlagban jó eséllyel még a 2060S sem lesz meg, ha a szokásos 5-10%-os nagyotmondást kivonom az egyenletből.
A kérdés inkább a Super sorozat árazása lesz, nem a teljesítménye. Túl optimistának látom azt, hogy az árakat kategóriánként egy az egyben viszik tovább.
[ Szerkesztve ]
evDirect villanyautós töltőhálózat
-
sutyi^
senior tag
válasz lezso6 #41567 üzenetére
Szokás szerint megint közel teljesen ki van facsarva, amit lehet órajelek tekintetében és azért ilyen a fogyasztás.
Ha mindkét kártya alacsonyabb órajelekkel jönne, akkor ugyan csak GTX 1660 Ti / RTX 2060-al versenyeznének, de sokkal barátságosabbak lennének a fogyasztási mutatók + még lenne benne órajel tartalék.
-Pedig nem is én utállak téged, te utálod saját magad! - ...és mégis egész nap együtt kell lennem saját magammal.
-
titán
válasz lezso6 #41569 üzenetére
Azt nem értem, hogy miért nem csinálnak nagyobb GPU-t több végrehajtóval és alacsonyabb feszültséggel, órajellel. Tiszta golyósok. A vezetés egyszerűen idióta. Azt képzelhették, hogy egy évvel ezelőtt kijönnek, és ahhoz tervezték a GPU méretet? Csak hát szokás szerint addig csúsztak vele, hogy mire kijött, már tök elb.szott koncepció lett, mert húzni kell az égbe. És ez megy már 7 éve folyamatosan. Ha egyszer lenne annyi esze a boardnak, hogy figyelembe vennék, hogy úgyis csúsznak egy évet, és 30%-kal több magot terveznének a modellekbe, akkor maradhatnának az elképzelt fogyi keretben, egyből versenyképesek lennének és az AIB gyártóknak sem kéne harakirit elkövetni, mikor meglátják a TBP értéket.
[ Szerkesztve ]
evDirect villanyautós töltőhálózat
-
Petykemano
veterán
válasz lezso6 #41567 üzenetére
Van egy fószer, aki azt hangoztatja, hogy a 7nm (N7, de elvileg Samsung is) nem igazán jó abban, hogy viszonylag nagy lapkát (gpu) magas órajelre tudjon pörgetni.
A zen2-höz és socokhoz képest a naviX lapka még mindig óriási.Egyébként Szerintem a 5700 -> 5700xt skálázódása kifejezetten jó: ~10% frekvencia és 10% cu (~20% tflops) beáldozásával ~20%-kal alacsonyabb a TBP.
Ezzel együtt persze lehet, hogy a vágott lapka minősége annnyival rosszabb is és valójában mindkettő a maga kategóriájában túl van húzva.
Találgatunk, aztán majd úgyis kiderül..
-
Tyrel
őstag
válasz lezso6 #41575 üzenetére
De mindig csak a saját előző fejlesztéseikhez képest lépnek előre, az nVidiától közben egyre jobban elmaradnak... Eleinte csak 300W fogyasztásokkal tudtak versenyezni a felsőbb kategóriákban, most meg már meg se próbálják, egyre nagyobb a távolság.
Persze ez nem lenne gond ha nagyon költséghatékony kártyákat csinálnának, fillérekért, hiszen akkor legalább a ruppótlan piacokat uralhatnák, pl. balkán, ázsia nagyja, oroszország, ilyenek, onnan is lehet jó bevétel... de ez se megy, nevetséges árcédulákkal jönnek ki a cuccaik.
A Vega messze túl drága volt, hivatalosan nem is csökkent eleget az ára csak próbálnak tőle szabadulni a gyártók is meg nagykerek is, azért lehet néha úgy-ahogy elfogadható áron hozzájutni, de már azt is erősen beárnyékolja a 2060.
A VII-t inkább hagyjuk is, túl sokat fogyaszt, messze túl drága, nincs custom, és nem kínál semmit a konkurenciával szemben, kivéve persze több VRAM-ot ami nem kell semminek.
Aztán itt ez a Navi is, a jelenlegi RTX szériával szemben is igen erősen megkérdőjelezhető már az árazása, ha meg még jön ez a SUPER is, akkor meg végképp piacképtelen lesz.Komolyan ilyen rettenetesen pozícionált termékekkel és ilyen nevetséges árazással mi a jó francot akarnak???
Pedig amúgy pl. egy 5700 XT önmagában valószínűleg nem lenne rossz kártya, de alapból sokkal kevesebb AMD rajongó van mint nVidia, rosszabb a hírűk, népszerűtlenek, és akkor erre még jön az, hogy a SUPER megjelenésével olcsóbban kapsz legalább ugyan olyan jó (vagy inkább jobb) kártyát a másik oldalról... innentől kezdve meg kb. a reviewer-ek meg az a 12 rajongó fognak Navi-t venni.
Ha ennyire nem megy inkább hagyják a francba az egészet, meg közben adjanak hálát amiért a konzolok hardvereiben az nVidia nem verseng velük, különben azt is elbuknák pillanatok alatt.
[ Szerkesztve ]
Turenkarn
-
Tyrel
őstag
-
Petykemano
veterán
válasz lezso6 #41577 üzenetére
Annyira nem új node. Meg hát élvileg volt egy respin. (Reméljük nem a sorozatgyártott szemetet adják most el) De biztos kell még tapasztalatot gyűjteni.
Ámít nem értek, hogy a Vega 20 is itt készül, ami 40%-kal nagyobb is. Ha az kijön 4 hbm-mel $699-ből, akkor ezen mi kerül $4-500-ba.
Találgatunk, aztán majd úgyis kiderül..
-
Petykemano
veterán
válasz lezso6 #41586 üzenetére
Voltak, akik végeztek ad-hoc számításokat, hogy mennyibe kerülhet a navi kártya.
$100 lapka
$80-90 GDDR6
$60-70 PCB, hűtés, egyébsumma $250 lehet, de lehet, hogy felül van lőve így is.
Ez válasz arra, hogy miért nem polaris. De egyben azt is jelenti, hogy a $380 árral van meg a 45%-os margó, ami efelett kel el, az grátisz.Ehhez képest mennyi lehet 2 HBM2 stackel szerelt Vega? Nyilván $50-ral olcsóbb a lapka, de a HBM2 ennyivel drágább is lenne?
A $250-300-os vega 56-ok már önköltségi áron mennének?Találgatunk, aztán majd úgyis kiderül..
-
Abu85
HÁZIGAZDA
válasz lezso6 #41616 üzenetére
Nem teljesen. A NOC és az NTC nem csak erre vonatkozik. Nyilván a része rendre a Wave32 és a Wave64, de például a Wave32 nem sokat ér akkor, ha nem tudod elfedni a memóriaelérés késleltetését. Ez tehát önmagában nem működik, kell hozzá egy másik képesség, ami részben szoftveres, de a lényege a gyorsítótár tartalmát figyelembe vevő ütemezés. És emiatt van az, hogy egyetlen korábbi SIMT GPU-nál sem éri el az 1-et az egy munkaelemre levetített IPC. Az, hogy a Navi erre képes legyen, durván ki van tömve cache-sel. Összesen 336 kB-nyi cache-ről beszélünk itt per multiprocesszor. Ezzel szemben a GCN-ben van 80 kB, a Turingban van 96 kB. Persze a multiprocesszor az eléggé laza megfogalmazás, hiszen ezt lehet egyszerűre és bitang komplexre is tervezni, de ha per-ALU-ra vetíted le ezt, akkor a Navi esetében 2,625 kB/ALU, míg a GCN és a Turing esetében ez az érték rendre 1,25 és 1,5. Gyakorlatilag a cache-rendszer az oka annak, amiért olyan magas IPC-t lehet elérni munkaelemekre levetítve. Emiatt nem csak a Wave32-ről van szó, mert az igazából nem ér semmit egy ilyen cache-rendszer nélkül. A GCN-en is lehetne Wave32-t csinálni, vagy a Turingon is Wave16-ot (ők warpnak hívják, de igazából mindegy), de szart sem érne, mert csak szopatnád az architektúrádat azzal, hogy nem lesz elég wave elfedni a memóriaelérést. Gyakorlatilag rosszabbul járnál a Wave64 és a Wave32 módokhoz képest. Nem is kínálja fel a GCN és a Turing a felezés lehetőségét. A hardver csak drámait lassulna tőle.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
.Ishi.
aktív tag
válasz lezso6 #41618 üzenetére
Ez jogos, az AMD nem ígérget semmit, figyel arra, hogy hivatalosan mit kommunikálnak. (Bár azért Koduri is nyomta a hype-ot olyan mondatokkal a Vega idejében, hogy "várjátok meg a gaming drivereket" és hasonlók.)
Viszont egy kompetens marketing csapat tudja kezelni ezt is, mert nem "szokásos hype" alakult ki, hanem a "1080 teljesítmény 250 dodóért" vagy "RX 590 teljesítmény 75W TDP-ből." Marketingből szerintem valamennyire lehetne kezelni az ilyen durva wishful thinking helyzetet. (Vagy nem kezelik, mert látják, hogy a Navi pl. túl drága lesz a 200 dolcsi alatti szegmensbe vagy valami. De akkor is, valamilyen kommunikáció jobb, mint a semmilyen.)
[ Szerkesztve ]
-
Abu85
HÁZIGAZDA
válasz lezso6 #41624 üzenetére
Ez még mindig túlegyszerűsített. Tehát a GCN-nél egy SIMD16 10 wave-et képes futtatni és egy wave lefuttatásához négy ciklus kell. De nem azért kell ennyi, mert 3 ciklusig pihizik, hanem azért, mert egy wave 64 lane széles, tehát egy wave-ből egy ciklusban csak 16 lane-t futtat. Most itt megjegyezném, hogy a Polaris esetében már 8 wave-re lett csökkentve az IB mérete, de ez igazából nem túl lényeges, 6 wave fölött elég jól le lehet fedni a memóriaelérést. Ha most minden klappol a GCN-ben, akkor a peak érték VALU szintjén 1 lane/clock.
És a munkakiosztás is számít, a GCN úgy működik, hogy megvan az adott erőforrásigénye a feladatnak, és arra futtat x wave-et. Tegyük fel, hogy ötöt. Ilyenkor az új wave-ek adagolása úgy történik, hogy mindegyik SIMD16 kap egy új wave-et, és ezek közül maximum egy lehet vertex shader wave, mert azok tipikusan eszik a regisztert és a cache-t. A compute egy picit bonyolultabb, mert ott az LDS is bejön a képbe, mint limit. De ugye asznkron compute-ban tudod mixelni a grafikai és a compute munkákat, csak legyen elég erőforrásod, hogy legalább 4 wave fusson per SIMD16. De persze van egyébként kiterjesztés is, ami a wave_limit, mert sokszor a cache-hit többet ér, mint a memóriaelérés átfedése. Nagyjából hasonlóan működik az összes többi modern GPU, az arányoknál van különbség, de ugyanúgy lehet egy kódnál fontosabb a cache-hit, mint a throughput, ugyanúgy limit lesz az LDS és a regiszter mindenhol, leginkább az LDS, stb. Ez az, amit értettek azon, hogy a mai architektúrákat könnyű megtanulni, de nehéz olyan kódot írni, ami igazán jól kihasználja a multiprocesszorok képességeit. Ha sok wave fut az is lehet baj, ha kevés, az is, aztán milyen feladatokat érdemes egymás mellett futtatni, hogy legyen elég regiszter+LDS ahhoz, hogy elég wave futhasson, stb.A Navi ezeken annyit változtatott, hogy a multiprocesszor olyan robusztus, hogy lényegében egy "just works" típusú rendszer lett. Tele van cache-sel, képes a saját működését a munkafolyamathoz igazítani, az ütemezés a cache tartalmához igazodik. Ha a késleltetésből származik elő, akkor úgy működik, ha a throughputból, akkor úgy. Tehát lényegében írsz egy kódot, és minden olyan optimalizálás, amit ma azért csinálsz, hogy igazodj a hardverek limitjeihez, a munkacsoportok mérete ne hasson rosszul a vektorregiszter lokalitására, ne legyenek rossz hatékonysággal használva az I-cache-ek (ez explicit API-val kiemelten fontos), a wave-ek tényleg megfelelően legyenek kiosztva, azok a Navinál igazából már nem kritikusak. Lehet ezekre optimalizálni, de arányaiban nagyon gyorsan megvan az az optimális kihasználtság, amiért a GCN-en, illetve a Turingon sokat küzdesz, ráadásul sokszor eltérő optimalizálási stratégiával.
Érdemes megnézni, hogy a Navi mennyire teker olyan kódokban, amit tipikusan Turingra írtak. Például a BF5 egyes shaderei, ahol kifejezetten arra optimalizál a motor, hogy az L1 gyorsítótár aktívan használva legyen, mivel a vektorregiszterek újrahasznosítási lehetősége tipikusan rövid. A Navinak ez pont csemege, mert négyszer nagyobb L1 gyorsítótára van, mint a többi hardvernek, illetve még van egy extra alacsony késleltetésű L0 gyorsítótár is a két SIMD-re. Mindegy, hogy a shadert Turingra optimalizálták, hardverből le van kezelve az a probléma, amire a DICE optimalizált.
Ennek egyébként akkor lesz nagy hátránya, ha elkényelmesedik a piac, mert oké, hogy a Navira gyorsan megvan a sebesség (konzolon fut, a PC-s meg majd vesz gyorsabbat mentalitás), de például a GCN, a Turing, és lényegében az összes régebbi GPU nagyon is igényli ezeket az optimalizálásokat. És nyilván ezek azért még maradnak egy darabig, nem is kevés ideig. Tehát nem szabad átesni itt a ló túloldalára.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Petykemano
veterán
válasz lezso6 #41627 üzenetére
Ez alapján tökre illik rá, hogy a gpu nem késleltetésérzékeny. Csak közben de.
De had értsem meg én is, hogy ha van egy wave64, ami a max 16 széles feldolgozótömbön 4 órajelciklus alatt tud lefutni csak és a 4x16-os CU-n 4 wavefrontnak kellene folyamatosan futnia a maximális kihasználtsághoz.
Akkor miért kell 64 hosszú (?) Wavefrontot futtatni? Ez minek a hülye ötlete volt?
Vagy miért kell 16-os tömbökre bontani a CU-kat, miért nem 64, amit szükség esetén Lehetne bontani 2/4 felé?Találgatunk, aztán majd úgyis kiderül..
-
Petykemano
veterán
válasz lezso6 #41629 üzenetére
Engedd meg, hogy lefordítsam egy számomra autentikusabb példára. Mindamellett, hogy persze érthető és most hallgattam meg Steve Burke és David KAnter beszélgetését, ami szintén tisztított a képen.
Hasznos volt a magyarázatod, de nem haragszol, úgy vélem, pont az maradt ki, amire rákérdeztem:
- miért kamion = Wave64 (ami ha jól értem egy 64 darabos adatcsomagot jelent)
- miért olyan áteresztőképességű utakat használunk, ami az RDNA-ban már kétszeres?Utak helyett folyóval illusztrálnám, amin kompok viszik át az autókat.
Az autók az adatok.GCN:
- 4db 16 férőhelyes komp (4x SIMD16)
- maximum 64 autó átvitelére lehet egyszerre jegyet váltani.RDNA:
- 2db 32 férőhelyes komp (2x SIMD32)
- lehet 64, de már akár csak 32 autó átvitelére is jegyet váltani.Az a szabály, hogy akik együtt váltanak jegyet, azok kénytelenek mind ugyanazon a kompon menni. Hiába tűnik úgy, hogy a 64 autó átszállítására a 4db 16 férőhelyes komp ideális. Valójában 64 autó átszállítására a GCN esetében 1 kompnak 4x kell fordulnia, akkor is, ha egyébként a másik 3 komp sajnálatos módon nem csinál semmit. És sajnálatos módon akik már átjutottak a túloldalra, nem távozhatnak, amíg mind a 64-en biztonságosan át nem értek.
A GCN maximális kihasználtságához 4 csoportra lenne szükség, akik együtt váltanak jegyet.
Az RDNA abban segít, hogy ha 64-en állnak össze és váltanak jegyet, akkor azok még mindig csak egy komppal utazhatnak, de a 32 férőhelyes kompnak elég csak kétszer fordulnia. Míg ha történetesen 32 autós áll össze, akkor akár egy fuvarral átérhet az egész csoport a túloldalra és mehet dolgára.
Tehát a kérdés:
- Miért szabály az, hogy 64-en válthatnak csak egyszerre jegyet? Ha tudjuk, hogy a kompunk 16 férőhelyes és egy csoportot csak egy komp tud szállítani, akkor miért nem 16 engedjük, hogy 16 fős csoportokban váltsák meg a jegyet?
- Vagy ha tudjuk, hogy 64-es csoportokban jönnek/jöhetnek csak a kocsik, akkor miért szarakodunk 16 férhelyes kompokkal, miért nem dolgozunk 64 férőhelyesekkel?
Lehet olyan, hogy több nem 64 fős csoport akar átutazni? Abban az esetben pont hasznos, ha több kisebb komp van.Szóval ha tudjuk, hogy egy Wave64 csak egy SIMD csoporton tud tudni, akkor miért nem Wave16-ok vannak? A wave64 mindig 64 adatot jelent, vagy csak maximum 64-et? Miben jelentene hátrányt ha 16 hosszú lenne a max?
Találgatunk, aztán majd úgyis kiderül..
-
#82819712
törölt tag
válasz lezso6 #41633 üzenetére
Szeretem mikor példákkal beszélgettek itt mert az széleskörben érthető
PH Popular Hardver
csak aztán óvatosan a kompkkal kényes téma ez most még a végén Clark Ádám kell a futószalagba is.
Igen a sebesség egyértelműen hiányzott a kompokból.
lehet a dual Cu-ra is kellett volna mondanod egy példát egy építkezésen pakoló két munkással akik az ablakon adják be a cserepet (cache) és emiatt nem kell két munkásnak fel le szaladgálni a lépcsőn dupla ideig.
Így talán azt a vitát is megúsztuk volna és "a DCU az más" ennyi."így utólag belegondolva lehet az AMD tévedett a 64 szállal kapcsolatban, legalábbis grafika terén, mert ugye compute-ban meg igencsak jó."
Nem tévedett csupán közös tervezés...
Eddig is beszélte a reddit népe hogy a Rdna játék arhtektúra és szétválik a computesúlyos GCN-től.
és nocsak a MAC 4 Vegával (2*2) azaz GCN-el erősít (sok ember meghökkenésére) a compute force-os területen.Amire nem harapott rá fura módon senki mint téma az a RNDA2 fix funkciós működése
"2020-21 will pack some fixed-function hardware for certain real-time ray-tracing effects."[ Szerkesztve ]
-
Petykemano
veterán
válasz lezso6 #41633 üzenetére
A kompos példámban egy forduló egy órajelciklus. Így nem kell belékeverni az adhoc választott sebességet.
Mert valójában is amikor jön egy 64 adatos wave, az bekerül a CU egyik SIMD16-os csövébe, ami 4 órajelciklus alatt (4 fordulóval) tud végezni a csomaggal.
A kompos példában csak az a kérdés merül föl (ami a kamionosnál soha nem merülhetne fel), hogy miért is kell 64 autónak.összeállnia egy jegyhez.
Ezt válaszoltad: Wave64 - throughput. Ha nem így lenne, akkor a csoportok (wavek) kezelése több adminisztrációs erőforrást igényelne. (Mondjuk több rajzolási parancsot? Több regisztert, buffert, azélesebb ütemezőt)
Rendben. De amikor eljut egy wave (64) a CU-ba akkor ott miért nem lehet azt egy helyett egyszerre 4 SIMD16-ra ráküldeni - hisz ugyanaz az utasítás. Egy CU miért nem tudja a neki leküldött wave-eket a saját erőforrásain optimálisan vágrehajtani a wave tényleges elemszámától függően?
A másik kérdést, hogy miért nem szélesebb a SIMD feldolgozó megválaszoltad. Köszi
Találgatunk, aztán majd úgyis kiderül..
-
Petykemano
veterán
válasz lezso6 #41636 üzenetére
+stratova
Ja persze, én se gondolnám, hogy az aMD gyártana 10CU-s lapkát, csak IGPben.
(A navi14 lesz elvileg még. Elvileg kisebb. Navi12-ről még nincs írásos bizonyíték)De igazából a Samsung dealen ábrándoztam. Hogy ezekkel a számokkal az RDNA-ból hogy jön ki egy versenyképes mobil gpu?
David Kanter azt Mondta, eddig annyira nem volt szempont a tényleg alacsony fogyasztás- függetlenül attól, hogy normális órajelen normális fogyasztása volt a gcnnek, de innentől az amdnek nagyon rá kell gyúrnia az energiahatékonyságra
Találgatunk, aztán majd úgyis kiderül..
-
Raymond
félisten
válasz lezso6 #41641 üzenetére
Nem kellett, semmi koze ahhoz amit eredetileg irtal hogy 20 CU van a Navi-ban. A linkelt hozzaszolashoz pedig idezleg teged:
"Renderképen szerintem felesleges találgatni hogy mi micsoda, főleg ha már megvannak a specifikációk."
De ha gondolod akkor karikazd be a CU-t aztan meglatjuk hogy 20 vagy (ahogy az AMD is irja) 40.
[ Szerkesztve ]
Privat velemeny - keretik nem megkovezni...
-
stratova
veterán
válasz lezso6 #41636 üzenetére
Kérdés "mainstream standard" lesz e most a 2SE, 2x2PU, 2x2xX DCU felállás.
Mert a Hawaii-nál bemutatkozó 4 SE izmosabb frontend backend, felállás évek alatt Tongán át egészen Vega 12-ig (Radeon Pro Vega 16/20) szivárgott le.
A sokat (átnevezést) megélt Cape Verde után pedig Polaris 12 1 SE-ről 2-re hízott. Ez utóbbi lapka korábbi driveres morzsák alapján, egy ideig még velünk lehet az OEM-eknek (esetleg notebookgyártóknak) "hála" RX 630, 640 néven.
A fentiekből én afelé hajlok, hogy a korábbi standard 2 SE-hez hasonlóan (Tahiti, Pitcairn, Bonaire), a mostani 2SE, 2x2PU több lapkát is érinthetne, "csak" a CU-k mennyiségét backendet és memóriabuszt variálná AMD.
-
Petykemano
veterán
válasz lezso6 #41649 üzenetére
A 2070 (tu 106), 2080 (tu104) és 2060 (tu106) superek elvileg egy-egy respinek. Kb mint a tobago, meg ezek voltak a 300-as szériában.
Viszont a wccftech-en még mindig szerepel a 2070Ti super és 2080Ti super mellett, hogy new chip.Az a fura, hogy a tu104 1080-ból eddig nem volt vágott, vagy ez volt a vágott.
Nade a lényeg, hogy az 1080Ti tu102-volt. (754 mm²) Ha ehhez képest lesz egy új chip, akkor tényleg beparázhatott, nem?
Vagy ez már egy 7nm-es chip lenne, ami az egyszem "poor" Volta örökébe lép?[ Szerkesztve ]
Találgatunk, aztán majd úgyis kiderül..
-
Z10N
veterán
válasz lezso6 #41649 üzenetére
Osszek@kilva is tovabb fogja szamolgatni a zoldhasu dollarokat. Amugy a 2060/S miatt jobban aggodnek a helyukben. Atlagosan 10%-s arcsokkentesre szamitok. Viszont a 2GB GDDR6 nincs a szamitasba veve. $300?
1920/2176=0,8823
0,8823x$350=$308,8Nagyon erik az az instant $100-s vagas a 5700/XT-nek, ha el is akarnak adni belole.
[ Szerkesztve ]
# sshnuke 10.2.2.2 -rootpw="Z10N0101"
-
Abu85
HÁZIGAZDA
válasz lezso6 #41627 üzenetére
Ez nem pont így működik. A multiprocesszornak van egy minimum száma a SIMD-eken párhuzamosan futtatható wave-ekre. A GCN-ben 10, a Polarisban 8, a Navi-ban 20. De igazából, ha eléred a 7-et, akkor bőven van elég wave átlapolni a késleltetést.
A GCN-ben egy Wave64 az négy ciklus alatt fut egy SIMD16-on. Az RDNA-ban egy Wave64 két ciklus alatt fut egy SIMD32-ön, de a variálható wavefrontméret miatt a fordító úgy is fordíthatja a kódot, hogy egy Wave32 fusson egy ciklus alatt a SIMD32-n. Egyszerre mindig csak egyel eteted mindet, a különbség az, hogy bizonyos kódoknál kedvezőbb a throughputra helyezni a hangsúlyt, míg más kódoknál a latency-re való optimalizálás hatékonyabb. Ezt amíg a korábbi GPU-kban direkten optimalizálva kellett megoldani a shader kódon belül, addig a Navi esetében már a hardver kapott olyan képességeket, hogy a fordítón keresztül felismeri a kódok jellegét, és annak megfelelően NOC vagy NTC módban futtatja.Ez is kihasználtságlimites. A másik opció a függőséglimit, de az SIMT dizájn miatt nem alakulhat ki. A kihasználtságlimit továbbra is létező jelenség marad, mert azért egyre sűrűbbek azok az übershaderek, mik lezabálják a regisztereket, de inkább az LDS-t. Például a DICE a BF5 esetében azért optimalizál az L1 reuse-ra, mert a regiszterek esetében a "hit" ablak, hát eléggé kicsi, és ez nem lesz másképp a Navi esetében sem, tehát ebből a szempontból azért még nem akkora változás, viszont az L0-L1 cache-dizájn nagyon hatékony, nem csak méretesek a gyorsítótárak, de a késleltetésük is alacsonyabb lett a korábbi dizájnokhoz képest. Ez például jelentős előnyt a DICE számára. Ettől persze a kihasználtságlimit elméletben megmarad, csak messze nem olyan erősen, ahogy a mostani hardvereken úgy általában. Itt a statikus erőforrás-allokáció problémáira még mindig optimalizálni kell, de ez gyakorlatilag minden GPU-n így van.
Variálható wavefrontméretet csak az Intel kínált (azt is igazából rosszul, mert amíg mondjuk a geometry shadekhez tényleg jól igazodott a hardver - rohadt gyors itt, szó se róla, addig a compute shadereknél már nem volt optimális a működés, mivel ez a bonyolult hardverdizájn elfogyasztotta a tranzisztorokat, és nem volt lehetőség gyors LDS-t kiépíteni ... és itt szopikázik az Intel főleg a DX12/Vulkan játékoknál, hiszen a nagyon lassan elérhető L3 cache az LDS). Az AMD és az NV korábbi architektúrái nem tudtak igazodni a kód jellegéhez. Ezért mondták folyamatosan az AMD és az NV emberei, hogy mi a jó módszer a dizájnjaiknak. Figyeld meg, hogy az AMD majd a jövőben nem fogja annyira kihangsúlyozni, hogy vigyázni kell ám az erőforrás-allokációra, mert kell a wave-szám, hogy működjön a multiprocesszor. Egyszerűen a hardver lett toleráns azokkal a kódokkal szemben, amelyek a korábbi tipikus GPU dizájnokon amúgy problémát jelentettek, például a divergens kódok, de most maga a működés tud a kódhoz igazodni.
(#41631) Petykemano: A wave/warp méretek kialakításánál az történik, hogy a hardver képes legyen annyi wave-et futtatni, hogy azok biztonsággal áthidalják a memóriaelérés késleltetését. Mondjuk a GCN-en egy wave64 futtatása elindul. Kiderül, hogy kell az adat hozzá, azért elmegy a Bélabá (ő a GPU adathordára) a memóriába, de amíg Bélabá hozza az adatot a szatyrában, addig kő (ez ilyen paraszthardver) valamit futtatni a GPU-n. Ezért elindul egy másik wave64, de annak is kell adat (természetesen sok a Bélabá), és így tovább. Egy idő után ugye megjönnek az adatok, és ha van mondjuk 7 wave, akkor tuti, hogy lesz egy olyan wave, ami addig dolgozik, amíg Bélabáék hozzák a cuccost a többi wave-nek.
Na most a kérdésedre az a válasz, hogy persze a GCN is működtethető lenne úgy, hogy mondjuk wave16-ok futnak, meg a Turing is működtethető lenne úgy, hogy wave16 fut. Nem ezzel az elméleti lehetőséggel van a probléma, hanem azzal, hogy Bélabáék nem elég gyorsak ilyen kis wave-méretre, tehát a variálható wave-mérettel többet vesztesz, mint nyersz, mert nem hoz Bélabá annyi adatot hozzájuk, hogy elfedjék a memória késleltetését. Erre tehát tervezni kell a hardvert, nem működik ez csak úgy magától. Ezért nincs variálható wave-méret a korábbi GPU-kban.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Raymond
félisten
válasz lezso6 #41644 üzenetére
Pedig de, azt irtad a CU szelesedett, viszont nem szelesedett. Ugyanugy 64 ALU mint eddig es 40 van belole. Az hogy kettot egy WGP-be csoportositanak nem jelenti azt hogy a CU mar nem 64 ALU mint eddig mert az. Meg a WGP-nel is ott van hogy "DualCU" mert ketto. Es a WGP-bol van 20. A CU-bol 40-van ahogy az AMD is irja. Meg a "virtualis CU", az is jo volt
Privat velemeny - keretik nem megkovezni...
-
sutyi^
senior tag
válasz lezso6 #41679 üzenetére
Ha a valogatott gamekben egy jól binnelt GPU éppen hogy gyorsabb mint egy 2070, akkor inkább egál az.
De ha rászámolod a partner kártya felárakat mondjuk egy konzervatív +30-50USD-ot hozzá téve, akkor meg pont ott van az XT, ahol a konkurens termék, a sima meg egyenesen drágább mint egy 2060.
Aztán ha bőrdzsekis tényleg útjára indítja a "Super" paletta frissítést, ahol az eddigi konkurens termékek árban lejjebb mennek, akkor csak szimplán még rosszabb lesz ár-értékben.
[ Szerkesztve ]
-Pedig nem is én utállak téged, te utálod saját magad! - ...és mégis egész nap együtt kell lennem saját magammal.
-
TTomax
félisten
válasz lezso6 #41682 üzenetére
Nem igazán ... a ref. árán nyugodtan vehetsz customot de a navinál nem így lesz sajnos.Nekem erős a gyanúm,hogy egy-két hónapon belül jön a pricecut,AMD nagymester ebben.
[ Szerkesztve ]
★★★★★ I got too much soul, rhythm and blues R&B ya see, all that's cool, but hip-hop and rap yeah that's where my heart's at Even back when I used to break on a box ★★★★★ "Chief Rocka"
-
#82819712
törölt tag
válasz lezso6 #41684 üzenetére
Barrons szerint 2019 word's best CEOs Lisa
Pinky Demon: Az a baj VSesen értelmezel olyat amit nem VSesen mondok.
[ Szerkesztve ]
-
stratova
veterán
válasz lezso6 #41697 üzenetére
Kérdés, hogy az asztali piac megkapja-e a 1650 Ti-t, ha jól látom a teljes TU117 1024 CUDA mag / ALU lenne. Bár ezzel NV helyében Navi12 érkeztével (azelőtt pár nappal/héttel ahogy szokták) rukkolnék elő. Mondjuk ha nem üveghangon jár, akkor ezzel RX 570-et lehetne verni nem 580-at.
-
stratova
veterán
válasz lezso6 #41706 üzenetére
Ha AMD reagálni akar 1660 Ti /1660-ra akkor még Navi 10-hez hasonló akapon lehetne, hozni 1-2 kártyát.
32/28 CU 12 Gbps 256 bit GDDR6-tal illetve 24 CU 256 bit GDDR5-tel ezen túlmenően Navi 10-zel azonos frontend/backend (4 tri/clk, 64 PU) mellett. A kisebb kártya memoriasávszélességben még 7 Gbps memoriával is rálicitálna a 1660-ra, és közelebb kerülhetne hozzá fogyasztásban (120 W), bár a nagytestvére talán még inkább 150 W-ot enne.Hogy mindegyiken 8 GB VRAM lehetne az nem lenne újkeletű (most is van ennyi memóriával 4 Vega&Polaris verzió).
A kisebb Navi 12 pedig Vega M GL-hez lehetne hasonló (4 tri/clk, 32 PU) 20 CU-val csak itt 128 bit 8-9 Gbps GDDR5-tel, bár 3,5 Tflops esetén talán sávszélesség limites lenne, de akkor 1650 Ti is az (max 3,533 Tflops olvasható róla TPU-n).
-
Petykemano
veterán
válasz lezso6 #41716 üzenetére
jó a pont.
De ugyanakkor furcsa, hogy a Vega 20, ami 2 helyett 4 HBM vezérlőt tartalmaz, mégis megközelítőleg azonos tranzisztorsűrűségre jön ki, mint a 4 böszme nagy kiterjedésű GDDR6 vezérlővel bíró navi, de inkább még rosszabb. Tehát mindent nem magyaráz a memóriavezérlő.Viszont ha a Memóriavezérlő nem skálázódik, mint tudjuk és abu elmondása szerint a nagy és nagy teljesítményű blokkok sem skálázódnak úgy, mint a gyűrűs oscillátor, vagy egy mobil SOC, akkor nagyon hasonló tranzisztorsűrűséget kéne látnunk majd az nvidiától és az inteltől is.
Találgatunk, aztán majd úgyis kiderül..
-
nagyúr
válasz lezso6 #41725 üzenetére
azt csak az nv tudja. de igor bácsi is nagyon kételkedik ebben a fóliában, mert nem adja ki a matek.
Tudod, mit jelent az, hogy nemezis? Az érintett, erősebb fél kinyilatkoztatása a méltó büntetés mértékét illetően. Az érintett fél jelen esetben egy szadista állat... én.
-
Új hozzászólás Aktív témák
Hirdetés
A topikban az OFF és minden egyéb, nem a témához kapcsolódó hozzászólás gyártása TILOS!
MIELŐTT LINKELNÉL VAGY KÉRDEZNÉL, MINDIG OLVASS KICSIT VISSZA!!
A topik témája:
Az AMD éppen érkező, vagy jövőbeni új grafikus processzorainak kivesézése, lehetőleg minél inkább szakmai keretek között maradva. Architektúra, esélylatolgatás, érdekességek, spekulációk, stb.
- PlayStation 5
- Politika
- Lenovo 3000 és IdeaPad notebookok
- Kevesebb mag, több AI: teszten az Intel Lunar Lake
- Gaming notebook topik
- Sorozatok
- Idén kilőtt az OLED monitorokra a kereslet
- BestBuy ruhás topik
- Autós topik látogatók beszélgetős, offolós topikja
- Kerékpárosok, bringások ide!
- További aktív témák...
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: Ozeki Kft
Város: Debrecen