Mindkét gyártónál különállók a ROP blokkok fizikailag. Ennek főleg skálázhatósági oka, hogy ne kelljen csupán a ROP-blokkok számának növelése miatt újratervezni az L2 és a multiprocesszorok belső buszrendszerét. Az AMD-nél a shader engine is inkább egy logikai csoportosítás, mintsem egy eszközszinten megjelenő fizikai bedrótozás.
Annyi a különbség, hogy az NV-nél a ROP blokk fizikailag is rákapcsolódnak egy L2 partícióhoz, míg az AMD-nél ez logikailag van kijelölve. Így kap minden ROP blokk egy saját L2 partíciót úgy, hogy közben az L2 és a ROP rendszer függetlenül skálázható.
De persze a belső működésben is különbségek vannak. Az AMD-nél a ROP blokkok főleg a Z adatok írására használják a logikailag kapcsolódó L2 partíciót. Ennek nagyon prózai oka van, az MSAA így gyorsabban hajtható végre.

[ Szerkesztve ]

Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

Átlagfelhasználó szemszögből ez az AMD hype a következőképp néz ki:

A netet böngészve még mindig azt látom mindenhol, hogy bizonyos AMD kártya teljesítménye rendre az NVidia alatt van, ár/érték arányban viszont ez kiegyenlítődik. Ott van azonban az, hogy a nem RX AMD kártyák mintegy kályhaként üzemelnek, és olyan táp kell alá, hogy sok usernek azt is cserélnie kellene, ha AMD-be fektetne. Ráadásul sokakban benne van, hogy magas üzemi hőmérséklet -> gyorsabb amortizáció.

Itt most az átlagról beszélünk, aki, tegyük fel, nem akar "zsákbamacskát" venni 90-100 rongyért ( 1060 vs 480 viták ).

Az emberben benne maradt, hogy az AMD annyit eszik, mint egy hősugárzó, ellenben az NVidia-ra ez nem jellemző. Aki MiniITX-et épít, szóba se jöhet az AMD, ezenfelül utóbbinál szinte kötelező a tág ház és profi házhűtés.

Decemberben 2 hónap keresgélés után úgy döntöttem, veszek egy AMD kártyát, adok egy esélyt. R9 390 lett végül, combos MSI gaming, gondoltam, ha ez nem hűti le a kártyát, akkor semmi. Egy 550 Ti-t váltott ( meg teljesen új konfigot ), csak jelzésképp, ilyen gyakran cserélek. A kártyával az ég világon semmi baj nem volt, de tényleg annyira forró volt, hogy a ház oldallapjai is rendesen átmelegedtek. A driveres támogatásról nem is beszélve. Az MSI gaming app összeakadt az AB-vel, az a Crimsonnal, stb.

Most újra ott vagyok, mint decemberben. Nagyon kíváncsi leszek milyen teljesítményt nyújt az új AMD széria, de mielőtt AMD kártyát veszek, kétszer többet akarok róla tudni.

De miért R9 390-et vettél? Az RX 480 hasonló teljesítményű és kevesebbet is eszik (kevesebb hő, ha már ennyire fontos), modernebb, VP9 gyorsítás, stb.

[ Szerkesztve ]

solfilo

Mivel az RX-480 ára már elég régen beállt, ezért ugyan értelmét keresem egy decemberi R9-390 vásárlásnak, de sehol nem találom, főleg hogy Te magadat az átlagnál némileg tájékozottabb júzernek írod le?

"Csak egy dologtól félek. Ha meghalok, az asszony eladja a gépeimet annyiért, amennyit bevallottam neki." KERESEM: Lian Li PC-C50, Silverstone Milo ML03 ..............................................................................................

Az ár volt a lényeg. 60k R9, 85k+ RX 480. Nem vagyok tájékozottabb, mint az átlag "júzer".

Ár/érték arányban jó döntés volt, a kártyával semmi baj nem volt, a fő probléma a szoftveres háttér, plusz egyéb kellemetlenségek. Például YT HD videó alatt a kártya gondol egyet, és elkezd eszement módon hűteni, minden ok nélkül.

Jesszusom. Ezt is megértük: AMD-s fórumban AMD-s szövegtől kapok hányingert.
Más ennek a harmadáért kap pár nap pihit.

namaste #195
"AMD-nél nincsenek a ROP-ok a L2 partíció/MC-khez rendelve, hanem a Shader Engine-hez; az NV-nél fordítva, a ROP-ok az L2/MC mellett vannak és nem a GPC-kben."
Bocs, én ehhez hülye vagyok mint tyúk az ábécéhez, de anno az első GCN leírásában (lásd ITT) is az volt, hogy az L2 a memóriacsatornáknak megfelelően van fölszeletelve, és ide kapcsolódnak a ROP-ok. Ez összhangban áll azzal, ami a GCN Architecture Whitepaper 15. oldalán látható. Ez a kép nem pont ugyan az, de a lényege megegyezik:

trollkodásnak nevezed a tényeket, sok mindent elárul

én nagyon örülnék neki, ha az amd mutatna valamit, de ha nem mutat akkor sem "koppanok", és ha mutat akkor sem jó lenne, ha az intelt árversenyre kényszerítené valaki, jelenleg ő diktál és ez a vevőknek rossz, hatalmas fejlesztésre is azért nincsenek rákényszerítve, mert nincs rá okuk
a64 időkben volt rá okuk, meg is született a c2d és a core i

és hát na, az amd namajdmost' szlogenjével már a padlás tele van sajnos

Panzika az a cpu 35w-ot nem fog átlépni

elég sok gépet mértem, még sztem maradtak fenn fórumokban táblázatok is
c2d-ket ráadásul remekül lehet alulfeszelni, t500-asomban volt t9400 is, igaz egyik legjobb hűtésű gép, de cpu-t alulfeszelve brutálisan halk volt terhelve is

_tejesen'® joálapotpan'™_-_Hamarosan a hiányból is hiány lesz...by Samus

Érdekesnek találom, hogy a Vega architektúra leírásában sok fejlesztés a jobb skálázódást célozza; a memóriarendszert a "világ legjobban skálázódó memóriaarchitektúrájának" nevezik.
Na, ezt most vessük a Polaris előtt kiadot roadmappel:

A Vegánál csak annyi áll, hogy "HBM2", plusz némi perf/watt fejlődés. A következő, "Navi" architektúra újdonságának írták, hogy "Scalability".
Mennyire kell ezeket a jelszavakat komolyan venni?
Persze, a skálázhatóság javítására itt és most nagy szükség van, hiszen a Fiji teljesítménye nem skálázódott igazán jól a plusz számolókkal.

A Navi-nál még ez áll: "Nextgen Memory". Ez vajon mi fán terem? A HBM2 sávszélessége valószínűleg még 1-2 év múlva is élvonalbeli lesz, miért kell leváltani? Vagy a drága és macerás interposer helyett hoznak be valami rugalmasabb és olcsóbb megoldást, mint az Intel-féle EMIB?
(Lehet, hogy ez inkább a nagy Radeon találgatós topikba kellene...)

Ide kapcsolódik:
Fiery #5
"512 GB/s memoria savszelesseg? Nem ugyanennyi volt masfel eve mar a Fiji is? Biztos, hogy ez eleg lesz 2017-2018-ban is? Vagy a Fiji jart tulsagosan a kora elott?"

Az újabb VGA-k egységnyi számítási teljesítményre vetített sávszélessége (egy lebegőpontos műveletre hány bit memóriaelérés jut): az Nvidia 10-es sorozatánál 0,28-0,35 bit/FLOP között alakul; az RX400-as Radeonoknál 0,35-0,4 bit/FLOP között, míg az R9 390/X, Fury*.* 0,5 bit/FLOP körül szór.
Ez alapján azt mondanám, hogy -a szavaiddal élve- a Fiji járt a kora előtt.
Ugyanakkor, ha figyelembe vesszük, hogy a hírek szerint Fury sávszél-gondokkal küszködött, ez arra világít rá, hogy az Nvidia hatékonyabban használja ki a rendelkezésre álló sávszélt, előrébb jár a színtömörítési stb módszerekben, és így kisebb, 0,3-0,35 bit/FLOP között megoldotta azt a feladatot, amihez a Fijinek 0,5 bit/FLOP is éppen csak elég. Úgy is mondhatnánk, hogy az AMD ezt a hatékonysági lemaradást brute force elven, a vadiúj HBM technológiával próbálta megoldani.
Remélem, a Vegában a mozaikos optimalizálás és a javított színtömörítés visszafogja a sávszél pazarlást és egy szintre hozza a hatékonyságot az aktuális zöld kártyákéval. Ha így lesz, akkor a pletykák alapján számolt ~0,34 bit/FLOP egyáltalán nem lesz kevés a Vega10-nek.

A hbc, high bandwidth cache az maga a hbm?
A hbc lehet-e az xbox esramja? Vagy esetleg kétszintűen, hogy az esram felel a késleltetésért, a hbm meg a sávszélességért?

Lehet-e a die azért ilyen nagy, mert van rajta gddr5 vezérlő is? Nagy hülyeség volna, de végső soron a scorpion elvileg gddr5-tel jön.

Találgatunk, aztán majd úgyis kiderül..

Szerintem a Navi féle Nextgen Memory a GDDR5 -t váltó memoriára utal. Ha az nem lesz akkor még mindig ott a HBM2
A Scalability meg gondolom hogy ne legyen Polaris és Vega szerűen két architektúra egyszerre, hanem mint a Zen-t is eggyel akarják lefedni az egész palettát. De ez persze csak egy röpke gondolat.

KisDre.artstation.com

HBM3, de a Navi most inkább 2019-es termék.

(#218) KisDre: A GDDR6 az nagyjából ugyanaz, mint a GDDR5X. A HBM1-et nem tudná váltani.

[ Szerkesztve ]

Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

Üdv
A Navi gondolom gcn6 lesz nem? Hiszen felesleges most architektúrát váltani mert épp a vegával jön egy úgy memóriaarchitektúra.

[ Szerkesztve ]

HBM 3 lesz olyan is?? az már 8192bites lesz ?

Aha, dereng valami erről - újabb iteráció, nagyobb sebesség, nagyobb sűrűség, hurrá.
DE! A nagy kérdés, hogy az interposer kihozatalával és gyártási költségével sikerül-e valami áttörésfélét elérni?
Mert ha nem, akkor vagy valami EMIB-hez hasonlót kellene fejleszteni, vagy valami radikálisan újat kitalálni.

KisDre #218
"A Scalability meg gondolom hogy ne legyen Polaris és Vega szerűen két architektúra egyszerre, hanem mint a Zen-t is eggyel akarják lefedni az egész palettát"

Aha, lehet, hogy erről van szó. Bár én ezt a "Polaris-alsó / Vega-felső szegmens" felosztást nem érzem annyira tervszerűnek; a Polarisra inkább egy átmeneti, kísérleti sorozatként tekintek - a kísérletezésnek meg ugye nem a nagyvaddal kezdünk neki.
Szeretnék arra gondolni, hogy a "skálázhatóság" alatt már a 16384 számolóig azok darabszámával lineárisan növekvő teljesítményű architektúrát értik

Hát, reméljük teljesítményileg a legjobbakat, addig még a Vegával is jó lenne ismerkedni

KisDre.artstation.com

A skálázást már a kezdetektől beletervezik az architektúrába, utána már csak paraméterezni kell a konkrét termékhez.
Azt írják, hogy egy SE tartalmaz:
- 1 Geometry Processor
- 1 Rasterizer
- 1-16 CUs
- 1-4 RBEs
Ezek nem csak logikailag alkotnak egy egységet, hanem fizikailag.
Annak nincs sok értelme, hogy ugyan a ROP bármely MC-t elérheti, de logikailag lekorlátozzák.
A különböző ROP - MC konfigurációkkal mi a helyzet?
Z az L2-ben. Forrás?

Minden vonatkozó ábra és szöveges leírás arra utal, hogy a ROP-oknak van saját szín és mélység/stencil cache-ük és közvetlenül a memóriába írnak, illetve onnan olvasnak.
Miért nem vezet közvetlen nyíl a ROP blokkoktól az L2-be egyik ábrán se? Az öt évvel ezelőtti cikkben is rosszul szerepel.
Ráadásul a Veganál jelentette be az AMD, hogy a ROP-ok az L2-be dolgoznak. Most megoldották azt, amit öt éve már megoldottak?

Navi Scalability - GPU-k összekapcsolása gyors adatvezetékkel, GMI (?)

xgmi már lesz a vega 20ban is, de a skálázhatóság ettől még lehet gpu szintű (nem pedig alacsonyabb, mint shader, rop, cu, stb.)

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.

amugy nem lehet hogy ez az uj megoldas az AMD-tol a NV Quardo termekvonala ellen keszul, es azert van akkora bitszelessegu meg RAM mennyiseg is?
es max majd kihozatal szar akkor butiva kijon 8-12Gb RAM-l is a proliknak

mert oda az NV is eleg horror aru kartyakat gyart, ha van jedi a cuccban, akkor a sok RAM miatt ott eladhatobb, meg kifizetik az arat is
nezd meg egy aktualis NV fele GF es egy Quadro kartya arcimkejet, ami ugyanaz a generacio, meg a chip

több drón kell ;P

Természetesen a skálázás már az ISA oldalán kialakításra kerül.

Nem teljesen úgy épül fel belül a termék, ahogy a logikai diagramm mutatja. Régebben elmondta nekem az egyik tervező, hogy a GCN-nél van egy marhára széles belső gyűrűs busz és minden fel van rá húzva. Ezek pedig logikailag egymáshoz vannak csoportosítva, de semmiképp sem fizikailag. Ennek a fő oka az, hogy a logikai csoportosítás ugyan nehezebb tervezés szintjén, de végeredményben kisebb lapkát lehet kialakítani. Ennek a járulékos előnye még, hogy aszimmetrikusan tervezhetnek, lásd eltérő ROP:MC arány.

Semmit nem korlátoznak le. Annyi történik, hogy az egyes ROP-okhoz hozzárendelnek logikailag egy L2 partíciót, hogy a Z egységek oda írhassanak, így gyorsítva az MSAA-t. Ennyi történik. Hogy miért? Mert ez hasznos.

[ Szerkesztve ]

Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

Ez senki sem állította, hogy nincs a ROP-oknak saját gyorsítótáruk. Itt igazából arról van szó, hogy az MSAA eltérő terhelés a Z egységek számára. Nem éri meg a legrosszabb eshetőségre gyorsítótárat tervezni, mert sokszor nagyon kihasználatlan lenne. Emiatt terveznek az általános eshetőségre, és a legrosszabb esetek lefedése érdekében minden ROP blokknak lesz egy logikailag hozzárendelt L2 partíciója, hogy az erős MSAA terhelés sem végezze ki a teljesítményt. Ezzel tulajdonképpen spóroltak a Z-cache gyorsítótár méretén, amivel kisebb lesz a lapka, de mégse lesz hátrányos annyira, mert ott az L2 partíció.

A Vega egyrészt már mindent az L2-be ment, illetve a bejelentés lényege a koherencia megjelenése, ami eddig nem volt része a hardvereknek.

[ Szerkesztve ]

Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

A Quadrokhoz van az AMD FirePro vonala. Csak oda nem kéne új architektúra. Pláne, hogy az NV oldalon is Geforce körítés, esetleg strapabíróbb NYÁK, más driver, jobb support.Maximum a Teslák ellen mehetne valami új, bár már eddig is mindig az lett mondha (khm. khm.), hogy az AMD mennyivel jobb számítási teljesítményben, supportban, kutyafülében, mertnagyobb számítási teljesítmény, meg OpenCL, utána HSA stb.

"Minden vonatkozó ábra és szöveges leírás arra utal, hogy a ROP-oknak van saját szín és mélység/stencil cache-ük"

Ez egyértelmű, szerintem senki nem is mondott mást.

"Miért nem vezet közvetlen nyíl a ROP blokkoktól az L2-be egyik ábrán se?"

Nem azért a húsz fillérért mondom, de az ábrán a memóriavezérlőkbe se közvetlen nyíl vezet...

Vigyázz ezekkel a valaki mondta kijelentésekkel, nem biztos hogy igaz. Utoljára az R600-ban volt ring bus, miért mondanának mást, miért titkolnák?
Az, hogy fizikailag elérheti a ROP bármely MC-t, de logikailag nem, az korlátozást jelent.
Hogy hasznos, nem jelenti azt, hogy úgy is működik, szerintem is hasznos. MSAA esetén nem csak a Z értékeket, hanem a színinformációkat is nagyobb felbontáson tárolják, azt is hasznos lenne L2-be írni.
Van erre mérési eredményed, ami bizonyítja ezt a működést?

(#231) ukornel
Nem azért írtam, mert valaki ezzel ellentéteset állított volna, hanem mert ez van a doksiban.

Az ábrák se pontosak, össze-vissza vannak, pl. egyiken az L2 egy darabból áll, a másikon darabokban a memóriavezérlők mellett. De ez nem baj, mert különböző aspektusokat ábrázolnak és a szövegből ki lehet hámozni a lényeget.
"de az ábrán a memóriavezérlőkbe se közvetlen nyíl vezet..."
Az azt akarja szimbolizálni, hogy a ROP-ok bármely memória partícióba írhatnak egy crossbaron keresztül. És ahhoz a csíkhoz kapcsolódnak az egyéb részek egy hubon keresztül, azok se az L2-be dolgoznak, hanem a memóriába.

Nem titkolják. Megkérdeztem még a GCN3-nál, hogy miképp vannak ezek belül összekötve, ha már azt magyarázták, hogy minden elem függetlenül skálázható, mert eszközszinten fizikailag nem egymás elválaszthatatlan részeni, és mondták az AMD-től, hogy egy nagyon széles gyűrűs busz van belül. A memóriaalrendszer ehhez egy HUB-on kapcsolódik.

Fizikailag és logikailag is elérheti bármelyik ROP bármelyik MC-t. Csak a Z adatokat egy ROP blokk egy hozzárendelt L2 partícióba is menti, mert a dedikált gyorsítótár nem akkora, hogy erős MSAA terhelés mellett is kibírja a terhelést.

A szín gyorsítótár az nagyméretű, 16 kB-os. A Z gyorsítótár a pici, csak 4 kB-os.

Gondolom nem viccből csinálják így, de mivel ez kikapcsolhatatlan, így az eredményét megmérni mi nem tudjuk.

[ Szerkesztve ]

Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

"Nem azért írtam, mert valaki ezzel ellentéteset állított volna, hanem mert ez van a doksiban."

Ez szép és jó, hogy benne van a doksiban. Úgy érzem, nem árt tisztázni, ki mit állított, mikor én kéretlenül és hozzáértés nélkül beleugattam.
Abu85: "Eddig a ROP blokkokhoz tartoztak a L2 gyorsítótár partíciói"
namaste:
"A GCN-nél a ROP és a hozzátartozó color/depth cache a memóriavezérlőhöz kapcsolódik, semmi köze az L2-höz."

Lehet, hogy Abu nem fogalmazott pontosan, de az biztos, hogy a ROP (és "tartozékai") nem közvetlenül csatlakoznak a memóriavezérlőhöz. A témában nézd meg az Anandtech leírását a GCN megjelenésekor:
"As it turns out, there’s a very good reason that AMD went this route. ROP operations are extremely bandwidth intensive, so much so that even when pairing up ROPs with memory controllers, the ROPs are often still starved of memory bandwidth. With Cayman AMD was not able to reach their peak theoretical ROP throughput even in synthetic tests, never mind in real-world usage. With Tahiti [...] The solution to that was rather counter-intuitive: decouple the ROPs from the memory controllers. By servicing the ROPs through a crossbar AMD can hold the number of ROPs constant at 32 while increasing the width of the memory bus by 50%."
Igaz, Anandék crossbart írtak, Abu meg ring bust mondott, ami nem ugyanaz - talán valami bonyolultabb hibrid összeköttetés van, amire Abu forrása gyűrűs buszként hivatkozott, az Anandteché meg crossbarként. A lényeg most nem is ez, hanem, hogy már az első GCN-ben sem közvetlenül a MC-hez kapcsolódtak a ROP-ok.
A Vegánál ezt írják:
"AMD has significantly reworked how the ROPs (or as they like to call them, the Render Back-Ends) interact with their L2 cache. Starting with Vega, the ROPs are now clients of the L2 cache rather than the memory controller, allowing them to better and more directly use the relatively spacious L2 cache."

Szerintem ez összhangban van azzal, amit Abu mond, de azzal is, amit te a #167-esben írtál. De lehet, hogy csak rosszul látok.

"Az ábrák se pontosak, össze-vissza vannak, pl. egyiken az L2 egy darabból áll, a másikon darabokban a memóriavezérlők mellett. De ez nem baj, mert különböző aspektusokat ábrázolnak és a szövegből ki lehet hámozni a lényeget."
OK, az ábrák nem pontosak, de őszintén szólva a Whitepaperen se könnyű elmenni.

"Az azt akarja szimbolizálni, hogy a ROP-ok bármely memória partícióba írhatnak egy crossbaron keresztül. És ahhoz a csíkhoz kapcsolódnak az egyéb részek egy hubon keresztül, azok se az L2-be dolgoznak, hanem a memóriába."
Ja, de van egy global data share is az L2-vel

Ezen a ponton egyre inkább úgy látom, hogy túl kevés a pontos, konkrét információ a hivatalos leírásban. Számomra mindenképp. Vagy egyszerűen a felkészültségem nincs meg az értelmezésükhöz. Asszem, kár volt belekotyognom, elnézést.

[ Szerkesztve ]

Ahhoz képest, hogy az AMD a legnyitottabb cég ezen a téren, elég jól titkolják, publikusan nem jelent meg semmi ilyesmi.

si_programming_guide_v2.pdf, 4. oldal:
Unified Cache. Most shader memory – vertex buffers, textures, constant buffers, UAVs, etc. – are
read/written through a shared cache. Draw indices and the CB and DB blocks do not use the shared cache.

Ki lehet mérni, különböző méretű és formátumú shadow map segítségével. Amíg a cache-be dolgozik, addig gyors, ha kifut a cache-ből és a memóriába ír/olvas, akkor lassú.

(#234) ukornel
Amikor azt írtam, hogy közvetlenül, akkor az L2 kihagyására gondoltam, a szín és mélység adatokat a memóriába írja, illetve onnan olvassa. Az egész vita abból indult, hogy a Vega RBE az L2-be ment, a korábbiak nem. Abu azt írja, hogy a mélység adatokat az L2-be menti, a doksik meg azt, hogy a memóriába.
A GDS egy külön egység, azt a shadernek külön utasítással kell elérnie.

Teljesen igazad van ebben: "A Radeonok sokat esznek meg nagyon melegednek, ezért veszek nV-t!"
Ezt ismerősöm mondta!

De mellékesen rápakolta a Fullcover blokkot a kártyára... Erre inkább rá se kérdeztem hogy minek...
Na mind1..

Az amortizáció az onnan kezdődik hogy a GPU eléri a maximális hőmérsékletet és nem throttingol hanem nyomatja tovább max/turbo órajelen és tovább melegszik (ez általában 100°C), csak vannak elvetemültek akik szerint ez nem így van... De gondolom ezzel senkinek nem mondtam újat

@(#222) ukornel: úgy tudom hogy az interpooser az már alapból olcsó dolog, meg szinte bármelyik lerobbant gyártósoron le lehet gyártani (bár azért egy porszívógyár az megszenvedne vele )!

[ Szerkesztve ]

Magyarországon az egy főre eső hülyék száma: kettö! (Hofi Géza)

A programozók ezekkel az információkkal nem tudnak mit kezdeni. Nincs rá ugyanis befolyásuk. A dokumentáció ott hasznos, amire befolyásod van.

Nem hiszem, hogy az működne, mivel ez a trükk specifikusan az MSAA-ra szabott. Csak az a célja, hogy az MSAA maradjon gyors, és ne lassuljon be, ha 8x-re állítod, vagy fölé.

Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

Hát, azért elég sokszor szerepel a dokumentációkban a crossbar, az xbar és a hub, de ringbus sehol.

Be lehet vetni a MSAA-t is a shadow map számoláshoz.

A felfűzött egységek tömbösítve vannak. Azokban van/lehet crossbar. Például a ROP blokkok nem egyenként kapcsolódnak a gyűrűs buszhoz, hanem összevonva. Fizikailag az összes blokk együtt van rákapcsolva a belső buszra. Ettől függetlenül logikailag már szét vannak osztva. Ezek a trükkök a tranyóspórolást teszik lehetővé.

Az AMD régóta csak logikai vázlatot ad meg a lapkáról, és elsődlegesen azért, mert eszközszinten az egész teljesen másképp néz ki. Például még a Terascale 2 idején az eszközszint és a logikai vázlat igencsak hasonlított. Ma már nem.

Persze, hogy be, és az történik, hogy az MSAA-ra vonatkozó adatokat menti az L2-be. A többi megy a memóriába, vagy a dedikált Z cache-be.

Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

Július. Szerintem.
Bár örülnék neki, ha április végén befutna.

5600X 2x16GB 6800XT | i5-3570 2x4GB 1050TI | MS Surface Book | iPad Pro 12.9 | iPhone X | iMac e2008

Nem 2017H1-ről volt szó (újabban 2017Q2)? Én júniusra szavazok inkább.

[ Szerkesztve ]

solfilo

Igazad van. Elnéztem egy hónappal.

5600X 2x16GB 6800XT | i5-3570 2x4GB 1050TI | MS Surface Book | iPad Pro 12.9 | iPhone X | iMac e2008

Ha júniusban tényleg a boltokban lesz és júliusra normalizálódik az ára akkor azt lehet megvárnám a váltással, hátha valami olyan VGA jön ami tarol ár/értékben.

www.kamerapro.hu | FOTÓS TERMÉKEK SZÉLES VÁLASZTÉKA

Felső kategóriás kártyák lesznek, azok ár/értéke annyira nem szokott jó lenni. Te melyik árszegmensben keresel?

solfilo

Ennek - emberi nyelvre lefordítva - mi lesz az előnye egy RX470-hez képest?
Értem én, hogy több pixelt dolgoz fel az új architektúra, de mi lesz ennek a tényleges eredménye?

https://www.oldtech.hu/

Élőben, most a VEGA-ról!