- Amazon Fire TV stick/box
- Azonnali informatikai kérdések órája
- Így építsd a billentyűzeted!
- A régi node-okra koncentrál a szankciók miatt Kína
- 5.1, 7.1 és gamer fejhallgatók
- Hogy is néznek ki a gépeink?
- Processzorra való vizesblokk az ASUS ROG-os portfóliójában
- TCL LCD és LED TV-k
- Május 7-én lesz az új iPadek bemutatója
- VR topik (Oculus Rift, stb.)
Hirdetés
-
20 ezer új munkást visz Eindhovenbe az ASML
it Hatalmas politikai feszültséget okozott az ASML és a holland kormány nézeteltérése, de most úgy néz ki, hogy jelentős bővítésbe kezdenek Eindhovenben.
-
Megjelenési dátumot kapott a Metaphor: ReFantazio
gp A tervek szerint a végső kiadás októberben lesz elérhető PC-re és konzolokra.
-
MG4 menetpróba
ma Mindenképpen van fantázia az MG4-ben, az alapfeladatokat olcsón kipipálja, de többet akar nyújtani, mint amire képes.
Új hozzászólás Aktív témák
-
JanR
addikt
"mivel a Khronos Group késet a felület elfogadtatásával" - késett
Azért az AMD nem tétlenkedik, ez is támogatni fogja év elejétől. Egyre szimpatikusabb ez a Kaveri. Intel féle megoldásról van valami info van már?
-
Fiery
veterán
Az AMD szamara letkerdes volt, hogy az OpenCL 2.0 idoben (a Kaveri piaci startja elott) veglegesitesre keruljon. Addig nyakatekert megoldasokkal, gyakorlatilag tákolással tudta csak megoldani az OpenCL-lel meghajtott SVM (megosztott memoria) kezelest a sajat HSA implementaciojaban.
Az Intel ugy tunik, nem a HSA-val kepzeli el a jovot, de ez nem zarja ki azt, hogy a 2015-ben bemutatkozo Skylake tamogassa az SVM-et, es esetleg HSA-hoz hasonlo fejlesztesek legyenek naluk is. Az en szemelyes sejtesem az, hogy teljesen maskepp fog az egesz mukodni az Intelnel, mint az AMD-nel, de ugyanugy kozvetlenul hozzaferhetnek majd a GPU-magok is a rendszermemoriahoz.
[ Szerkesztve ]
-
Abu85
HÁZIGAZDA
De nem értem, hogy mitől nyakatekert, hogy az IGP a saját L2 cache-je helyett a CPU-éba írja az adatot? Ez az egyik legfontosabb eleme az implementációnak, mert a processzormagok nem tolerálják a késleltetést, míg az IGP nagyon is, tehát azt a magot helyezték előtérbe, ami érzékeny arra, hogy az adat ott legyen a memóriában.
Nézd meg a Sony PS4 megoldását. Az valóban más, de ott például az IGP L2 gyorsítótárjában kerül az adat, és a processzor ugorja át a saját L2-jét. Viszont ilyenkor az IGP-nek át kell ugrania a grafikai számításokkal az IGP L2-t, mert különben teleszemetelné adattal. Erre van a direkt shader futtatás a memóriából fícsőr.Egyszerű a működés, de a gyakorlatban messze ez a leghatékonyabb, mert kontrollált a tárak szemetelése.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Fiery
veterán
A nyakatekert mukodes alatt azt ertem, hogy az OpenCL 2.0 veglegesitese elott az AMD kenytelen volt az OpenCL 1.2 specifikacioba "beletákolni" az SVM tamogatast. Tehat ez egy API problema volt (semmi koze a cache-ekhez), ami azonnal megoldodott, amint megjott az OpenCL 2.0. Innentol mar csak az OpenCL --> HSAIL compilert kell tuningolni, es minden szep es jo lesz
[ Szerkesztve ]
-
#06658560
törölt tag
Ha már virtuálisan egységes címtérről beszélünk, miért csak IGP esetén lépték meg? dGPU esetén is lehetne hazsnálni, a busz sebességének, késleltetésének büntetésével, ellenben működne IGPU-tól cluster dGPU-s rendszerekig.
-
Abu85
HÁZIGAZDA
Elvben van rá lehetőség, de annyira korlátozza a sebességet a fizikailag még megtörténő adatmásolás, hogy jobbnak látták, ha ezt a programozó kontrollálja. Egyébként az aktuális rendszerben a Hawaii cGPU egy AMD64 ISA-s processzorral párosítva üzemképes lehet SVM-mel, de csak úgy, hogy a cGPU is a rendszermemóriát használja és nincs semmilyen gyorsítótárazás. Erre készíthet támogatást az AMD ha akar, de sok értelme igazából nincs.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Meteorhead
aktív tag
Na, kint van OpenCL 2.0, már csak 100+ Wattos Kaveri-szerű (vagy nagyobb IGPs) szerverprocesszorok kellenének, nem csak az alacsony fogyasztású web serverekbe szánt 18 Watoos jószág, és gyakorlatilag eljött a HPC mennyország.
Quad-socket AMD deszka, amiben lenne 4 X 512-1024 shader elem és tele lehetne pakolni 512GB RAM-mal... hát hadd ne mondjam hány szilárdtestes kolléga gyilkolna egy ilyen konfigért. Ha nem is oldják meg HT-n kerseztül az IGP-k szinkronizálását, hanem 4 device-ként látszódik, még akkor is nagy királyság lenne.
Várjuk az APP SDK 3.0-át OpenCL 2.0 példakódokkal és doksikkal (nomeg az implementációval).
-
polika
senior tag
Vicc hogy a CUDA6-nál meg pont a programozótól elvett köztes layer által valahogy automatikusan megoldott adatmásolást istenítitek a hozzá kapcsolódó hírben, és azt írja az elemzőtök hogy az nem jár performance penaltyval, mert legtöbb programozó úgysem érti a hardver mélylélektanát és ha kivesszük a kezükből a döntést, hogy az algoritmusuknak megfelelő helyen legyen a "bedrótozott" másolás akkor az esetek nagy részében gyorsabb kód jön létre.
Itt meg AMDnél jobb ha a programozó kontrollálja mikor is van rá szükség...
a fene se érti ezt, mindent megmagyaráztok mi miért jó
-
polika
senior tag
válasz Meteorhead #7 üzenetére
AMD berlin apu, 2-4 way serverekbe való...ez a kaveri szerveres változata, abban megvannak az interconnectek. Az hogy pontosan a közös címtérbe való irkálásnál meg a feljebb említett cache cucc hogy passzol össze egy ilyen környezetbe az más kérdés, várhatóan feladat függő is hogy mennyire párhuzamosítható, de valóban elég burtkó tudományos számítási, big data konfigok lesznek szerver oldalon is ha a szoftveres dolgokban is ennyire ráfeküdnek a másolgatás elkerülésére és a GCN telejs erejét rá lehet szabadítani az adatokra.... pl nekünk a nagy átteresztőképességű illesztési algoritmusokban (DNS szekvenálás az ilyen masinákra optimalizált kódokkal brutál gyorsulást lehetne elérni, mert itt minden teljesen párhuzamosítható)
-
Abu85
HÁZIGAZDA
Az egy fontos eltérés, hogy mi hogyan látjuk, és hogy az API fejlesztője hogyan látja. Én csak azt az infót közvetítem, hogy az NV szerint a koncepció előnyös, míg a Khronos szerint nem az. Ez nem az én véleményem, hanem az API-t delegáló fejlesztőké. Mindkettő mellett vannak pró és kontra érvek. Ha az én véleményemre vagytok kíváncsiak, akkor én olyat csinálnák, ami lehetővé teszi azt, amit a CUDA6, de csak opcionálisan bekapcsolható formában. Így a kecske is jól lakhat és a káposzta is megmaradhat.
(#9) Lacccca87: Nyilvánvaló a PCI Express busz sebessége 30x nagyobb, mint a CF hídé. Láthatod, hogy 4K-ban nincs is ellenfele az új CF-nek.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Fiery
veterán
válasz Meteorhead #7 üzenetére
2 vagy tobb utas APU nem szerepel az AMD jelenlegi utitervjen, ugyhogy en a magam reszerol nem szamitanek ra egyhamar Ha ilyesmi a cel, akkor lehet, hogy az nVIDIA elobb csinalja ezt meg ARM CPU mag(ok) kore epitve. Vagy az Intel a Skylake szerver valtozataval -- amirol azonban me'g annal is kevesebb konkretumot lehet tudni.
Az AMD-fele OpenCL 2.0 implementacio pedig me'g nincs kesz, me'g beta allapotban sem, ugyhogy a stabil kiadássá valamikor csak a 2014-es ev masodik feleben érhet meg, hacsak nem porgeti fel az AMD a fejlesztest a mostaninal is durvabban.
[ Szerkesztve ]
-
Abu85
HÁZIGAZDA
Az AMD már supercomputing fabric-kal gondolkodik. A Freedom ASIC majd bele lesz integrálva a lapkákba. Addig ezek mellé kell rakni a chipet.
Ez Intelnél is azért nem találsz erre infót, mert ők is supercomputing fabric-ra építenek majd. Ennek a neve az Aries.
Ezekkel a fabric-okkal teljesen le lesz lőve a többutas fejlesztési irány. Nincs előnye a fabric mellett, mert ugyanazt megcsinálja az összeköttetés, ráadásul anélkül, hogy számos speciális technikát kellene hozzá fejleszteni. Persze a fabric működése nagyon fontos, tehát egyszerűbb nem lesz, csak kötetlenebb. A rendszerépítők sokkal szabadabb dizájnokat fejleszthetnek.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Lacccca87
őstag
-
-
Lacccca87
őstag
Lehet hülye kérdés, de ha ezt tudták/tudják már akkor amikor a PCIe 3 szabványt alkották meg akkor miért nem foglalkoztak ezzel a kérdéssel? Vagy a 3.x esetleg 4 nél már van róla szó hogy valahogy csökkentsék a késleltetést?
Ez egyértelműen a lapgyártók érdeke is lenne mert így diferenciálhatnák a termékeket is.(gamer lap ként eladva használható lenne a szolgáltatás, játékokba meg opcionálisra beépíteni) -
QG
tag
"Az új felület legfontosabb újítása, hogy egységesen támogatja a központi processzorok és az integrált grafikus vezérlő között megosztott virtuális memóriát, így az előbbi két részegység teljesen mellőzheti a memóriamásolásokat, illetve ezek eliminálásával hatékonyabb algoritmusok hozhatók létre és a heterogén módon programozható hardverek használata is egyszerűbb lesz. Sajnos erre a funkcióra ma még nincs hardver a piacon"
A Kabini nem tudja ezt?
[ Szerkesztve ]
“Anti-intellectualism has been a constant thread winding its way through our political and cultural life, nurtured by the false notion that democracy means that 'my ignorance is just as good as your knowledge.'” ― Isaac Asimov
-
QG
tag
válasz #32839680 #22 üzenetére
Le vagyok döbbenve, azt hittem eddig hogy ezért szeretjük a Kabinit
De ha nem ezért, akkor miért is olyan remek, hogy a konzolok is ezt akarták?[ Szerkesztve ]
“Anti-intellectualism has been a constant thread winding its way through our political and cultural life, nurtured by the false notion that democracy means that 'my ignorance is just as good as your knowledge.'” ― Isaac Asimov
-
Abu85
HÁZIGAZDA
válasz #06658560 #15 üzenetére
Nézd az eredmények az új XDMA CF-et igazolják, addig nehéz belekötni abba, hogy elméletben mi a hátránya ennek. [link] - Tökéletesen látszik, hogy 4K-ban az összesen 500 MB/s-os SLI már kevés, míg az egy irányban 900 MB/s-os CF épp hogy elég, de az új CF konkrétan aláz.
(#16) Lacccca87: Azért az új összeköttetéseket az AMD már a Mantle-re tervezte. Ott azért fontos a rugalmasság, hiszen a fejlesztő úgy használja az erőforrásokat, ahogy akarja.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz #06658560 #25 üzenetére
A GPGPU eddig is működött a PCI Express összeköttetésen keresztül. Ha megírtad az alkalmazást úgy, hogy a gépben mondjuk használjon hat erőforrást, akkor használt is. Ezen most sem változtattak.
Lehet persze, csak közelébe sem érnének annak a teljesítménynek, amit a PCI Express kínál. Utóbbi rugalmasabb és gyorsabb. Ez egy nagyon egyszerű döntés volt. A normál CF hidas megoldás mellett már nem szól semmi.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Fiery
veterán
A Kabini nem egyezik meg a konzolok APU-javal, csak annyi a hasonlosag, hogy azonos x86 CPU architekturara (Jaguar) es azonos iGPU architekturara (GCN) epulnek. De a körítés közel sem azonos, az x86 magok szama sem azonos, az iGPU-rol nem is beszelve. A konzolok APU-ja tamogat(hat) SVM-es es HSA-t, de a Kabini es a Temash nem, sot a jovore megjeleno utod modellek (Beema, Mullins) sem fognak ilyesmit tamogatni. 2013-ban a PC-re nem lesz SVM vagy HSA képes hardver, csak 2014 elejen jon a Kaveri es annak mindenfele valtozatai (Bald Eagle az ultrabookokba es tabletekbe, Berlin az 1 utas szerverekbe es munkaallomasokba). 2014 vege fele pedig erkezik elvileg a Kaveri utodja, a Carrizo, ami valami olyasmi kepletbol all majd elo, hogy: Kaveri + full HSA + AVX2 + egyeb fejlesztesek.
[ Szerkesztve ]
-
#06658560
törölt tag
De, multiGPU rendszerben folyamatos adatcserék esetén több csatornán mozog az adat, kisebb késleltetést szed össze amíg elér a helyére. Amíg egy ciklusban át tudsz küldeni x adatmennyiséget és ezt nem feltétlen léped át, ellenben rohadt sokszor kéne ennyit mozgatnod oda-vissza, akkor csak a PCI-E-re támaszkodva mér gondban vagy- hisz a GPU-k között valamint a CPU felé is mozgatni kell, szép kis adatsorod lesz a busznál. Amennyiben van alternatívád, az adat jelentős részét el tudod küldeni másfele.
-
Abu85
HÁZIGAZDA
válasz #06658560 #28 üzenetére
Ők nem így gondolkodtak, hanem felvázolva az előnyöket és a hátrányokat döntöttek az előnyösebb megoldás mellett. Technikai értelemben a PCI Express egy kiépített koncepció, mindenhol ott van, egyszerűen csak használni kell. A tesztek szerint a megoldásuk egyértelműen előnyös. Minden szituációban az XDMA CF a kedvezőbb a hidas multi-GPU-hoz képest. Az elkövetkező 2-3 évet simán kibírja, utána pedig az sem biztos, hogy lesz VGA.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#06658560
törölt tag
válasz #32839680 #32 üzenetére
Eddig maximum egyutasról beszélnek, ha pedig még nem terveznek többet minimum említés szintjén, akkor a potenciális vevők, programozók sem tudnak vele számolni, így minimum három évg elő sem veszik, vagyis befutni kb. hat év múlva tudna legkorábban. A tervezés és koncepcióváltás kezdetekor ezt is el kellett dönteni, hova akarják pozicionálni a terméket- ha akarnák komolyan szerverre már kellett volna legyen róla pletyka.
Új hozzászólás Aktív témák
- Samsung Galaxy S21 Ultra - vákuumcsomagolás
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Készül a Galaxy S24 FE
- Google Pixel 6/7/8 topik
- Amazon Fire TV stick/box
- Azonnali informatikai kérdések órája
- 20 ezer új munkást visz Eindhovenbe az ASML
- Videó stream letöltése
- Ukrajnai háború
- Eredeti dizájnnal tér vissza idén a Nokia 225 4G
- További aktív témák...
- GIGABYTE RTX 3070 8GB GDDR6 AORUS MATER Eladó! 130.000.-
- KFA2 GeForce RTX 3050 EX OC 8GB GDDR6 Videokártya - Számla + Garancia, Ár alatt! BeszámítOK!
- ZOTAC GeForce Twin Edge RTX 3070 8GB OC GDDR6
- ASUS RTX 3060 Ti 8GB GDDR6 TUF GAMING OC Eladó! 95.000.-
- ASUS GeForce RTX 3070 Ti 8GB OC GDDR6X 256bit Amazon Garanciával