Hirdetés
- Hogy is néznek ki a gépeink?
- AMD Ryzen 9 / 7 / 5 / 3 5***(X) "Zen 3" (AM4)
- Kompakt vízhűtés
- AMD Navi Radeon™ RX 9xxx sorozat
- Apple MacBook
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- Házimozi haladó szinten
- Bluetooth hangszórók
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- TCL LCD és LED TV-k
-
PROHARDVER!
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
-
b.
félisten
[Real-Time Path Tracing- Nvidia research]
Az első képen is ott a tigrincs.. -
#37587
Hellwhatever
aktív tag
Devid_81
#37585
-
Devid_81
félisten
-
b.
félisten
-
b.
félisten
válasz
cyberkind
#37581
üzenetére
nem örömteli, de valamit valamiért. A gyártás technológiai fejlődésből egyre kevesebb lesz az előrelépés, ahogy szokták a hozzáértők mondani.
Most azt tudják csinálni, hogy a csúcson ugyan akkora területre bezsúfolnak egyre több tranyót. Ez nem jár kevesebb fogyasztással .
Lejebb a kisebb SKu nál, Mondjuk majd egy 3090 teljesítmény és tranyó szám most 350 W, az Adaban lesz 200 W de a csúcson ezen nem fognak tudni spórolni,majd MCM nél talán. Valószínűleg az RDNA 3 a csúcson jobb hatásfokú lesz. -
cyberkind
félisten
-
Televan74
nagyúr
RUMOR!!! NVIDIA GeForce RTX 4090/4080 AD102 PCB to support up to 24GB of GDDR6X memory, 600W TDP very likely
Érdekes hogy a teljesítménnyel hogy elszálltak a fogyasztások is. Pedig én naiv valamikor azt hittem hogy a teljesítmény megduplázódik a fogyasztás meg a fele lesz.
-
Abu85
HÁZIGAZDA
válasz
Busterftw
#37576
üzenetére
AZ exkluzivitás egy dolog. Ettől még csinálhatna az ARM egy desktop SBSA implementációt. Mert enélkül nem lesz előrelépés, maximum nem csak a Qualcomm firmware-re dolgoznak, hanem MediaTekre és Samsungra. De ez azért nagy gond, mert így ha adnak is ki dobozos Windows verziót, azok csak specifikus lapkákat támogatnak ARM-on. Ahhoz, hogy átfogó legyen a dolog szükség lenne egy PC-hez hasonló BIOS implementációra, amit minden gyártó követ, betart, és akkor az OS is tud vele mit kezdeni. És erre amúgy az SBSA jó alap, de olyan szintű érdektelenség van körülötte, hogy nem igazán látszik a fény az alagút végén. És ez nem a Microsofton múlik, mert az ARM esetében a nagy meló maga a Windows port volt. Felkészíteni azt egy SBSA-hoz hasonló alaprendszerre már igen egyszerű feladat, de ha nincs mire, akkor a Microsoft is csak várni tud.
-
Abu85
HÁZIGAZDA
Mert a Microsoft ARM-os Windows igazából qualcommos Windows. Effektíve nem ARM-ra van támogatás, hanem a Qualcommra. Más gyártói firmware-t az alaptelepítő önmagából nem is kezel. Ezért sincs kiadva dobozos verzió, hogy telepítsd magad. A Raspberry-re is úgy van megoldva, hogy egy külön alkalmazás kell az image kreálására, és ez az alkalmazás csinálja meg azt, hogy a Microsoft Qualcommra szabott támogatását kicseréli.
Az alaprobléma az, hogy az ARM-nak nincs egy BIOS-hoz hasonló rendszere a desktopon, ami egységesíteni az rendszerek alapszintű kezelését. Szerveren van az SBSA, de ezt a végfelhasználói lapkák nem támogatják. Egyébként maga az SBSA az működőképes lehetne, azt képes lenne a Microsoft egységesen támogatni, és akkor ez nem csak Qualcomm only story lenne, de egyelőre az ARM semmit nem tesz azért, hogy ebből legyen bármi is. Meg igazából a gyártók se nagyon verik az asztalt, hogy jó lenne szabványosítani, mert annyira le akarnák tarolni a Windows piacát. A legtöbben úgy vannak vele, hogy who the fuck cares, ott az Android. -
b.
félisten
Igen írja is a cikk, de azért jobb lenne ha ezeket a bővítményeket a Streamline-hoz maga az AMD támogatná és adná ki, nekik is és a fejlesztőknek is jobb lenne ha egyszerre benne lenne már mindhárom skálázási eljárás mondjuk a játék megjelenés napján, nem utólag barkácsolnák bele az FSR-t, ha kimaradt.
-
b.
félisten
Nvidia Streamline.
[Nvidia Streamline Aims to Simplify Developer Support for All Upscaling Algorithms]
Ezzel ha valamelyik cég felkészíti a játékot/ motort a temporális ejárásokra a másik cégek egyszerű plug and play módszerrel beépíthetik a saját eljárásukat. Nyílt forráskódú.
Intel már csatlakozott, de a StreamLine-ben van hely 3. gyártónak is
Nagyjából ezzel elkönyvelhető hogy amelyik játék tudni fogja a DLSS-t az tudja az XeSS-t kisebb munkaráfordítással is és fordítva is. Valószínűleg FSR 2.0 is így működik/ működne ha AMD belelép. -
-
Abu85
HÁZIGAZDA
Ja a proci kell? Az más.
Azt egyébként le lehet hozni desktopra workstationnek. Az AMD is lehozza a saját szervercuccát Threadripperbe, tehát biztos van rá igény, és 72 mag egy lapka. A gondot az jelenti, hogy nem telepíthető rá Windows, de némelyik Linux disztró esetében talán lenne támogatás.
-
b.
félisten
válasz
hokuszpk
#37558
üzenetére
Egyelőre megteszi nekik hidd el kezdő lépésként ,főleg hogy az Intel sem érte el ezt a szintet. Az energiahatékonyságra jobb így is. Mondjuk ezek a számok még azért még fenntartással kezelendők, de azt gondolom Nvidia nem lesz rászorulva sem az Epycre sem az Intel CPU-kra ha saját ökoszisztémát akar szállítani, fordítva nem vagyok benne biztos.
Intelnek lehet, hogy hiányoznának a Zöld gyorsítók egy egy megnyert tenderben de Nagyon sok A100 mellet került be AMD is. -
b.
félisten
[Nvidia Ada Lovelace GPUs Appear in HWiNFO Release Notes]
A BlackWell is izgalmasnak ígérkezik. szerintem ez lesz a következő genes Switch. -
nubreed
veterán
Közben a hazai árak felettébb szánalmasak még mindig. Itthon pl. az egyik legolcsóbb RTX 3060 TI a Gainward Ghost, 271 ezer, itthon (de van hol 290 környékén vesztegetik) miközben ugyanez az Amazon.de -n 640 euró, (+8.87 eur szállítási ktg) mondjuk 375 ft-os euróval is számolva csak 240 ezer plusz a szállítás.
-
#37546
Hellwhatever
aktív tag
Hellwhatever
aktív tag
-
b.
félisten
[Nvidia Unveils Big Accelerator Memory: Solid-State Storage for GPUs]
Ez egy nagyon hasznos dolog lesz. Nyílt forráskódú, bárki számára hozzáférhető. -
#37544
b.
félisten
Hellwhatever
#37543
b.
félisten
válasz
Hellwhatever
#37543
üzenetére
Jogos.
-
#37542
b.
félisten
Hellwhatever
#37539
b.
félisten
válasz
Hellwhatever
#37539
üzenetére
Nem hiszem hogy az valós. Ha lesz is 600 wattos azt szerintem csak F.E. kötelező hibrid hűtésű kártyákkal tartom elképzelhetőnek, az fölé én gamer kártyát nem tudok elképzelni.
-
#37541
Hellwhatever
aktív tag
gejala
#37540
Hellwhatever
aktív tag
válasz
gejala
#37540
üzenetére
Kell rá mókolni valami aktív hűtést. Találtam is egy ilyet: Amazon.com: NVMe M.2 SSD Cooler Heatsinks with 20mm Fan Powerful Cooling… : Electronics (nem valami bizalomgerjesztő
)Esetleg oldalról fújni valahogy mert ezeknek így szerintem is végük lesz.
-
#37540
gejala
őstag
Hellwhatever
#37539
gejala
őstag
válasz
Hellwhatever
#37539
üzenetére
"Lassan nem hogy az 1000 W-os de az 1300 W-os tápok is kevesek lesznek egy jól megrakott enthusiast konfigba.
"
Az hagyján, de mi lesz az SSD-kkel? Azokon is két ventis hűtés lesz majd? Mert 800W-os kártya alatt tuti megsül passzívan. De az se jobb, ha a 800W-os kártya és a 250W-os proci közé rakod... -
#37539
Hellwhatever
aktív tag
b.
#37538
Hellwhatever
aktív tag
Itt már 800 W fölé várják a 4090 Ti-t:
NVIDIA GeForce RTX 4090 'Ada Lovelace' GPUs Rocks Up To 600W TGP, Ti Variant Over 800W, Rumor Alleges (wccftech.com)Lassan nem hogy az 1000 W-os de az 1300 W-os tápok is kevesek lesznek egy jól megrakott enthusiast konfigba.
-
Abu85
HÁZIGAZDA
A Micron még gyártja a GDDR6X-et, de mivel nem lett valami elterjedt, így nem hiszem, hogy annyira ragaszkodnak hozzá. Őszintén szólva, ha nem mennek a 24 Gbps-os GDDR6 fölé vele, akkor az kb. a vége is ennek a vonalnak.
A GDDR7 szerintem nincs olyan közel, de mivel az szabvány lesz, így biztosan minden memóriagyártót érdekel.
-
b.
félisten
persze az OK, de az nvidiának szüksége volt már 3 éve erre erre, náluk meg ninsc IFC és 3 éve nem volt ilyen sebességű GDDR ram. Most se lesz sokkal gyorsabb a GDDR6 végső sebessége mint a GDDR6X.
Gondolom mind a két memória gyártó dolgozik a saját megoldásán és annak fejlesztésén, Nvidiának meg mindegy mert használhatják a Samsung ramjait is, ahogy tették is eddig TPu szerint Nvidia is és Amd is leszerződött velük a 24 es GDDR6 ramokra, ami jó dolgokat vetít előre kisebb SKU-kra is.
Nagyon jól sikerült amúgy a Samsung modulja a fogyasztási értékeket nézve is.
Micronról van infód ? vagy ők ezt elengedték és GDDR7 re mennek rá? -
Abu85
HÁZIGAZDA
-
b.
félisten
-
b.
félisten
Mondjuk azért idő távlatából nézve.
A GDDR6 16 Gbps lett 2021 év végére a GDDR6x pedig 21 Gbps volt már az elején. Most 3 évvel később fog jönni 20+ fölötti sebességgel GDDR6 tőlük. Amikor jött a 20 Gbps sebességű GDDr6X akkor még 14 volt a GDDR6 sebessége ami azért közel 50 % különbség volt akkoriban. Kíváncsi leszek hozzá nyúl e valaki a HBM hez. -
Abu85
HÁZIGAZDA
válasz
Yutani
#37526
üzenetére
A Samsung azért nem csinál GDDR6+ memóriát, mert ők az eredeti GDDR6 szabványra hoznak olyan verziókat, amivel túlteljesítik azt a teljesítményt, amit a Micron lerakott a GDDR6X-szal. Nyilván így tök hasztalan a Samsung számukra visszalépni GDDR6X/+-ra.
A GDDR7 pedig majd egyszer jön, annak ugye JEDEC szabványosítás is kell, tehát az nincs közel.
-
b.
félisten
-
-
Abu85
HÁZIGAZDA
Az Xbox-féle ESRAM meg eDRAM dolgokat ne keverjük ide. Azok PC-n nem működnek. Az Intel is próbálta, de befürödtek vele, aztán elhasználták a CPU L4 gyorsítótárának. Konzolon fasza, mert uralod a hardvert, de PC-n nincs az a programozó, aki foglalkoznak per kapacitás alapon egy ilyen jellegű optimalizálással.
A HBM2e-ről vannak ilyen jellegű adatok, mert ezeket már kipróbálták a gyártók. A gondot az okozza, hogy miképpen lehet ezt működtetni. A teljesítmény szempontjából a legjobb megoldásnak még ma is az tűnik, ha egy gyorsító két fedélzeti tárat kap. Egy HBM-eset és egy GDDR-eset. Viszont a programozók oldalán ezek külön kezelendők, vagyis az alkalmazásban meg kell adni, hogy melyik adat menjen a HBM-es területbe, és melyik a GDDR-esbe. Alapvetően ez végezte ki az Xe-HP vonalat megjelenés előtt, ami kapott volna külön memóriát is a tokozáson lévő HBM mellé, de helyette az Intel kapott visszajelzést a programozóktól, hogy kezeljen két memóriaterületet, akinek hat anyja van.
A HBM klasszikus gyorsítótárként való alkalmazása sem problémamentes. Az alapvető kérdés ilyenkor az, hogy a gyorsítótársor a cache-ben igazodjon a HBM-hez, vagy a HBM-et igazítsák az alapvetően alkalmazott gyorsítótársorhoz. Előbbi esetben jelentősen át kell tervezni a GPU-t, és nem biztos, hogy ennek a haszna kifizetődik, míg utóbbiban a találati arány elképesztően megcsappan. Nyilván nem megoldhatatlan a probléma, de ma még nem tartunk ott, hogy ne lehetne olcsóbb megoldásokkal kezelni ezeket.
Ami reálisan megvalósítható lehet, hogy a GPU kap egy olyan memóriavezérlőt, ami csak 4 kB-os lapokkal dolgozik már allokáció szintjén is, és ezek a 4 kB-os lapok lesznek másolgatva a HBM és a másik memória között. Ez kivitelezhető.
-
b.
félisten
válasz
hokuszpk
#37515
üzenetére
AMD nem kis halacska már, egy baromi nagy techóriás, óriási nagy bevétellel. Ráadásul Xilinx megvételével 30 % ot (!!)nőttek kapitalizációban.
Abu Módosította azért elég sokat a kezdeti hozzáállásából, amit az elején is érdemes lett volna szerintem így kezelni. Persze a halandzsa részét elengedtem és néhány szót amit nem az Endor-ról hozott tolmács írt le, azért elolvastam.
-
hokuszpk
nagyúr
na ebbe mar nemtudok belekotni, neha mondjuk vicces belegondolni, hogy a piaci ize alapjan az AMD annyit vagy majdnem annyit er, mint az Intel.
* idokozben azon filoztam, lehet ABU mar megszerezte es atnezte az NV hackbol szarmazo anyagot, ezert all magabiztosan bele a vitaba
![;]](//cdn.rios.hu/dl/s/v1.gif)
-
b.
félisten
Na akkor most hogy elvonatkozatottunk attól ahonnan indultunk azért ilyenkor felmerülhet az a forgatókönyv hogy a Nagy L2 gyorsítókat összefogják egy extra gyors és még nagyobb dinamikus hozzáférésű dedikált ramba, pl HBM2e , aka IF cache( vagy mint az Xbox eDRAM ) és itt beléphetne a forgatókönyvbe az amiről pletykálnak hogy az új vezérlő és parancsprocesszor képes lehet felfűzni eltérő sebességű ramokat egy dizájnra.
Ha megnézed ezt a hatalmas L2 cache mennyiséget nem lehetne máshogy megfelelő ütemben szortírozni csak ha szintén készítesz hozzá vagy egy extra széles buszt és ehhez megfelelő parancsprocesszort, vagy pedig beledobod egy még nagyobb L3 ba.. ami még egy 40 megás L2 esetén( A100) is extra adatokat mozgat. Ott pedig nem 384 bitről beszélünk, hanem többről ,ráadásul ott az NVlink is.
Máshogy olyan extra mennyiségű plusz parancshívást jelentene a CPu nak hogy a mostani extra nagy CPU terhelést is többszörösen túlszárnyalná. Nem tudom elképzelni hogy működhetne csupán L2 tár ilyen mértékű növelésével ez a mostani CPU dizájnokkal.
Rengeteg adat ez. -
Abu85
HÁZIGAZDA
válasz
paprobert
#37511
üzenetére
Van. Magának a GPU blokknak a része az L0-L1-L2 mindegyik architektúránál. És se az AMD, se az NVIDIA dizájnjaiban nem férnek hozzá ezekhez a GPU blokkon kívüli gyorsítók, például a kódoló és dekódoló blokk, a kijelzőmotor, vagy a DMA motorok, és hasonlók. De az Infinity Cache-hez mindegyik hozzáfér. Ez szándékosan van amúgy így, mert az L2 cache-nek csak bajt okozna, ha a GPU blokkon kívüli egységek szemetelnék a tartalmát. Az Infinity Cache nem ilyen érzékeny, az ugye egy victim cache.
Tehát az egy jó döntés a gyártók részéről, hogy a GPU blokkon kívüli részegységeket nem kötik rá az L2-re sem, és az is jó döntés az AMD-től, hogy ezeket ráköti az IC-re, de az L2-re már nem.A co-issue feldolgozás nem egy ördögtől való ötlet. Sokáig az AMD is csinálta az R600-tól kezdve, ennek leszármazottjainál, egészen a GCN-ig. Általában attól függ a co-issue bevetése, hogy van-e az adott architektúrán belül lényegi haszna, és az adott dizájnon belül mennyire drága beépíteni. Az RDNA-ban a co-issue feldolgozásnak nincs túl sok értelme a jelenlegi felépítés mellett, és eközben a beépítés drága is lenne. Az NV azért csinálja, mert nekik a beépítése olcsó, és van is helyenként haszna, miközben valós hátrányt csak a fogyasztásra fejt ki. Amúgy, ha az NV-nek ez az Ampere-ben egy drágán beépíthető dolog lenne, ami aránytalanul sok tranyót elzabálna, akkor ők se foglalkoznának vele.
A co-issue dizájnoknál jelenleg a problémát az jelenti, hogy egymástól nem függő wave-eket tudjon futtatni az a két feldolgozótömb, amelyek egy ütemezőn csüngenek. A gyorsítótárnak nincs sok limitje erre a feldolgozási formára. A regiszterterületnek annál inkább. De megint visszajutunk oda, hogy ha a co-issue beépítése a tranyóköltségben kellően olcsó, akkor megéri erre elverni a tranyót, függetlenül az ilyen rendszerek tipikus hátrányaitól. Minden csak viszonylagos, és az Ampere az egy olyan dizájn, ahol éppen határon volt a co-issue többletköltsége a várható nyereséghez viszonyítva, tehát éppenséggel nem volt hülyeség erre elvinni a dizájnt.
-
paprobert
őstag
A cache-ek között a különbség abban van, hogy milyen részegység fér hozzá, hány részegység fér hozzá, és teszik ezt milyen késleltetéssel.
Az NV például annyira felfújta a feldolgozószámot az Ampere-rel, hogy igazából az optimálisnál szélesebb az egész GPU. Te ezt co-issue-nak nevezed, de hagyjuk.
Ezzel szemben az AMD még csak egy visszafogottabb tartományig skálázta a GPU-ját. Arányaiban erős, kigyúrt az architektúra per mm2, emiatt bőven maradt tranzisztorbüdzsé, ill. lapkaterület is az Infinity Cache-nek.Ennek a következménye az lett, hogy az AMD szolidabb, RDNA2 GPU-ja bőségesen el van látva feldogozónkénti gyorsítótárral. Nekik a következő generációban a GPU felfele skálázásával van inkább dolguk. (Érdekes lesz látni, hogy továbbra is bele fog-e férni egy ekkora cache szelet, amikor a reticle limit egyre közelebb kerül majd. Illetve hogy van-e elég jó parancsmotorjuk ennek a kontrollálására)
Míg az NV széles GPU-ja jelenleg jobban éhezik, azaz egy "kisebb" L2 növelés is kiugró javulást hozhat, már rövid távon.Meglévő IP blokk áthozása, illetve házon belüli tapasztalat a victim cache rendszerbe illesztésével egyébként egy valósnak tűnő elmélet, nagyon nem kell kétségbe vonni.
Viszont látni kell a pro-kontra érveket. A zöldeknél egy IC-hez hasonló megoldás csak akkor lesz, ha az passzol majd az architektúrához. (tiszta lapos resetnél elgondolkodhatnak rajta)
Addig meg marad a -hasamra ütök-, +30% feldolgozó, -30% cache arány. -
Abu85
HÁZIGAZDA
válasz
Yutani
#37509
üzenetére
Ha a pletykák igazak ugye, akkor igen. Az AMD-nél az IC egyfajta felfogóháló a kritikus fontosságú gyorsítótársoroknak. Ugyanakkor az Infinity Cache-t nem számítva a gyorsítótárak strukturálása igen hasonló ahhoz, amit az NV csinál. A kapacitás persze más, esetleg helyenként van egy-egy extra lépcső, de a cél ugyanaz.
Effektíve az AMD is megnövelhette volna az L2 gyorsítótárat az IC kapacitásával, valamivel nagyobb lett volna a lapka persze, de akkor a gyorsítótárstruktúrába dolgoznak bele, ami valószínűleg növeli a ROP blokkok hatékonyságát, de nem annyira, mint egy direkt ilyen védőhálónak tervezett IC. -
Yutani
nagyúr
Az Nvidia tehát nem ezt az utat választotta, hanem növelte az L2 cache-t? Ami biztosan nem rossz, hiszen nem hülyék vannak az NV-nél, csak ők nem gondolkodnak egyelőre busz szélesség csökkentésben egy plusz cache bevezetésével. Egyébként meg az AMD-nek még dolgozni kell az IC-n, mert látszik, hogy 4k-n elfogy az erő például 1440p-hez képest, és gyanítom, hogy ez az IC-n múlik, illetve a szűk memória buszon.
-
Abu85
HÁZIGAZDA
Akkor folytassuk. A cache tekintetében a legnagyobb különbséget az jelenti egy CPU-nál és egy GPU-nál, hogy a GPU-k esetében az ISA-t eleve úgy tervezik, hogy már a memóriamodell szintjén kulcsszerepet játszik az adatpárhuzamos feldolgozás. Az adatpárhuzamos processzorok, aka GPU-k egy külön rendszert is alkalmaznak a memória olvasására és írására ... gather és scatter. A GPU-kban található vektor szélessége alapvetően meghatározza, hogy egy multiprocesszoron belül hány lane dolgozik, hány operáció végrehajtása történik párhuzamosan. Egy széles vektor elemei a szélességnek megfelelően több különböző memóriacímre lesznek kiírva, és az adatok behívásánál is ugyanennyi memóriacímről kell betölteni a szükséges információkat. Mindez a chipen belül rengeteg kommunikációt jelent (amire még egyszer hangsúlyozom egy GPU-nál fel van készítve maga az ISA), és jelentősen növeli az ilyen feldolgozás a cache-miss lehetőségét. Ahhoz, hogy ezt egy GPU esetében redukálják, bankokra osztják a gyorsítótárat. Ez alapproblémát nem oldja ugyan meg, de a bankokon belül azért nem lesz olyan rossz a helyzet.
Az AMD GPU-iban is ugyanúgy megvannak a klasszikus GPU-s vonások a cache tekintetében. L0-L1-L2, bankokra osztás, stb. Mind azért történik, hogy a GPU-k jellegzetességét kezeljék. Eddig a pontig nincs is igazán jelentős különbség az NV megoldásaihoz nézve, maximum a kapacitás, de az RDNA 2-ben is annyi L2 partíció van, amennyi 16 bites memóriacsatorna, ezek ugyanúgy szét vannak választva, és minden partícióba az adott csatornából származó adatok kerülnek gyorsítótárazásra. És ez tök ugyanígy történik az Ampere és a Turing esetében is. Nem azért, mert az AMD és az NV egyszerre hülye, hanem azért, mert így hatékony.
Az Infinity Cache ezt egészíti ki egy alapvető újítással. És itt fontos az, hogy kiegészíti, nem pedig megváltoztatja, mert a GPU-k cache-dizájnja eddig se volt rossz, csak az elmúlt években jött pár újítás a modern architektúrákba. Többek között a ROP blokkok az L2 gyorsítótárak klienseivé váltak, amit a Maxwell hozott be annak idején, de azóta azért ez a módszer is sokat fejlődött mindkét gyártónál. Egyrészt szögezzük le, hogy ez a változtatás nagyon jó már alapból, és úgy is előnyt hoz, hogy közben a sok-sok éve bevált tipikus GPU-s cache-dizájnhoz nem kell nyúlni. Ugyanakkor a ROP blokkok úgy kliensei az L2 gyorsítótáraknak, hogy közben a GPU ezt a gyorsítótárat egy rakás más dologra is használja. Tehát nem uralkodnak felette a ROP blokkok teljesen. Emiatt az ott tárolt adatok bármikor átdobhatók a VRAM-ba, és ez eléggé tipikus helyzet is, amikor a ROP blokknak hasznos lenne, ha a kívánt gyorsítótársort megtalálná az L2-ben, de mivel egy rakás adat cserélődik ott folyamatosan, így elég sokszor kell menni érte a VRAM-ig. Erre hozta be az AMD az Infinity Cache-t, ami egy Zen-ben használt dizájnból származó victim cache. Nem képezi a rendszer a szokásos gyorsítótár-hierarchia részét, hanem a fő feladata az, hogy az L2-ból kidobott, ROP blokkoknak fontos gyorsítótársorokat összegyűjtse. Ezzel tulajdonképpen megelőzi azt a problémát, hogy a GPU-nak a VRAM-ig kelljen menni, ha a ROP blokk által keresett gyorsítótársor hiányozna az L2-ből, mert az L2 bizony egy olyan gyorsítótár, ahol aztán nagy a nyüzsgés. És pont emiatt a nyüzsgés miatt választotta azt az AMD, hogy nem az L2 partíciók kapacitását növelik meg, mert a nyüzsgés attól még ott lesz, mert szinte minden részegység ír oda valamit, és sok ezer párhuzamosan futó lane mellett ez nem kevés adat ám. Ellenben az Infinity Cache konkrétan arra van, hogy "felfogja" az L2-ből nyüzsgés miatt kidobott, de fontos adatokat.
Na most ilyen fajta cache-re leginkább a CPU-kban van szükség, ezért sem az AMD GPU-s részlege tervezte ezt meg, hanem a CPU-s részlegtől emelték át, mert egy GPU-ban tipikusan nem gondolnak ilyen jellegű cache beépítésére. Illetve eddig nem gondoltak. -
hokuszpk
nagyúr
mondjuk az AMD oldali allitast ( nemszoszerintde : "azert a cputervezok csinaltak , mert a gpu reszlegnel nemvolt meg a megfelelo tapasztalat" ) tippre valahonnan AMD berkekbol vette, ezt extrapolalhatja az emberfia talan egy hasonlo profilu ceg hasonlo profilu diviziojara. Persze a tevedes bennevan, de igy felisteni modra ecceruen marhasagnak minositeni szerintem marhasag
a legnagyobb chiptervezo meg tippre inkabb az Intel de ennek utana kellene nezni. -
b.
félisten
válasz
hokuszpk
#37502
üzenetére
Hogy lehetne megcafolni egy feltetelezeskre alapuló allítast? Már maga az allítas is nonszensz.hogy tudna megmondani barki mire kepes egy ceg,mint Nvidia aki Amerika legnagyobb Chiptervezo cege?hogy lehetne ezt innen kijelenteni higy Nvidia atert nem csinal IF cachet mert.nem tudjak megtervezni?Ez egy marhasag,pont ugyan olyan velemeny mint Abu-é.Ha nem így tervezik annak működésbeli vagy előállítasbeli oka van,nem mérnöki tudás.
Kicsit forditsuk meg mit miert gondol az ember.
Nálunk még kb. semmi nem érződik a csökkenő trendből.
Usákoknál amúgy most törölték el a vámot a kínából érkező PC alkatrészekre, aki mostanában fejleszt a nagy vízen túl annak dőzs lesz.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Lehet akkor , hogy lesz benne a egy pár izgalmas újítás.A 3D tokozás szerinted szóba jöhet a drágább verzióknál?
Ú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!
MIELŐTT LINKELNÉL VAGY KÉRDEZNÉL, MINDIG OLVASS KICSIT VISSZA!!
A topik témája:
Az NVIDIA é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.
- Interactive Brokers társalgó
- Miért álltak az oldalak egy hétig, mi történt?
- Fűnyíró topik
- Samsung Galaxy S21 és S21+ - húszra akartak lapot húzni
- Hogy is néznek ki a gépeink?
- PROHARDVER! feedback: bugok, problémák, ötletek
- Mobil flották
- Allegro vélemények - tapasztalatok
- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
- Békéscsaba és környéke adok-veszek-beszélgetek
- További aktív témák...
- EVGA GeForce FTW3 ULTRA GAMING RTX 3070 Ti 8GB GDDR6X 256bit Videokártya
- ASRock Radeon Challenger Pro RX 6700 XT 12GB OC
- !!Újszerű!! AsRock RX 7700XT 12GB /Jótállással!/Szép állapotban!/Beszámítás! Posta ok!
- !!ÚJSZERŰ!! Gigabye Aero RTX 4070 Super 12GB /Jótállással!/Beszámítás!/Posta ok!
- Videokártyák
- Telefon felvásárlás!! Samsung Galaxy S25, Samsung Galaxy S25 Plus, Samsung Galaxy S25 Ultra
- Kaspersky, BitDefender, Avast és egyéb vírusírtó licencek a legolcsóbban, egyenesen a gyártóktól!
- 0% THM részletfizetés, beszámítás! Gamer PC, notebook, konzol, Apple termék, hardver KAMATMENTESEN!
- Telefon felvásárlás!! Apple Watch Series 6/Apple Watch Series 7/Apple Watch Series 8
- Lenovo ThinkPad dokkolók: USB-C 40A9/ 40AY/ 40AS/ Thunderbolt 3 40AC/ Hybrid USB-C DisplayLink 40AF