Hmm elképzelhető, hogy a kicsi a HD 8570M-et váltja?

HD 8570M 384:24:8 GCN 700 MHz -> 537.6 GFLOPs, 5.6 GP/s, 16.8 GT/s
64 bit DDR3 1800 MHz -> 14.4-16 GB/s

R5 M230 320:20:8 GCN 855 MHz -> 547.2 GFLOPs, 6.84 GP/s, 17.1 GT/s
64 bit DDR3 2000 MHz -> 16 GB/s

Valamiért memória sebességnél mindenki hajlamos elfelejteni, hogy 1024 a váltószám informatikában.

Nézzük 64 bit 2000 Mhz = 64*2000*10^6 b/s = 64*2000*10^6 /8 /1024 /1024 /1024 = 14,9 GB/s !=16 GB/s
Nem olyan eget rengető különbség, de azért nem elhanyagolandó.

És mi lesz a 8750M új neve? Vajon bios frissitéssel átnevezhetem majd egy Samsung laptopban?

Nem, egyébként is mi értelme lenne?

Steam/Origin/Uplay/PSN/Xbox: FollowTheORI / BF Discord server: https://discord.gg/9ezkK3m

Nem egeszen:

"Egy ROP blokk is letiltásra kerül, vagyis be kell érni négy darab blending egységgel."

Tehat 320:20:4

Privat velemeny - keretik nem megkovezni...

Itt is felteszem a kérdést, hátha Abu a nagy cikkíró láz közepette talán belefut valamelyik kérdésbe:

Radeon R9 M290X támogatja az OpenCL 2.0 full profile-t? Vagy más dVGA-k esetleg támogatják? Vagy továbbra is csak a Hawaii származékok?

Bocsánat, amint elküldtem az üzenet, rögtön láttam jobb oldalon az új privátokat. (Csak annyira mocsok kicsi az a kis piros szöveg, hogy sose látom )

Mea culpa. Köszi az infót.

Csak azért érdekes ez a helyzet, mert másokat is érdekelne nagyon, hogy SVM hogyan működik multi-GPU környezetben, hogy miként viselkedik ekkor a memória.

Alapból az ember azt remélné, hogy hasonlóan, mint a PRT, hogy az ember lefoglal egy nagy memóriaszeletet, ami adott esetben nagyobb is lehetne a VRAM méreténél, és úgy írja/olvassa, ahogy jól esik, és amikor IO művelet van, akkor valahogy összeszedi az adatot, és a felhasználó felelőssége, hogy ne írja ugyanazt a területet egyidejűleg két device-on. (Mint ahogy ez sub-buffereknél is specifikálva van)

Ami nem riszta, hogy milyen kontroll van afelett, hogy mely szeletei mikor másolódjanak és hova? clEnqueueMigrateBuffer ugye bufferekre pont ezt a célt szolgálja, hogy az ember ne az implicit másolásoknak legyen kitéve, hanem legyen kontroll a dolgok felett, de SVM-nél erre van/lesz/nincs lehetőség? Multi-GPU feldolgozásnál egy hatékony SVM modell lehet a kulcsa mindennek.

dVGA támogatás miatt pedig legjobb esetben is ha valaki mostanság vesz fejlesztői gépet, amivel majd szeretne OpenCL 2.0-át fejleszteni, akkor egyedül az APU-ban bízhat, és talán a Hawaii-ban. Aszimmetrikus load-balance fejlesztéshez jó lenne egy Kaveri-Neptune páros notiban.

(Nem is merek belegondolni mekkora császárság lenne egy Aorus X7-szerű masina Kaverivel és CrossFire Neptune-nal. Persze CPU limites lenne minden játék és CrossFire miatt OpenCL-t is süthetném, úgyhogy csak a megalománia beszél belőlem... de azért elfogadnám )

A jelenlegi állapotban a dedikált GPU memóriája a CPU memóriája lesz. A VRAM meg csak úgy létezik. De ez könnyen kitalálható, hogy elég lassú, noha abszolút működőképes. A Khronos pont azért nem hitelesít most VGA-kat, mert ezen a rendszeren változtatni kell. Ezt az APU-khoz tervezték, azokon jó, de a VGA-khoz kell egy jobb alternatíva. Ezen már dolgoznak is.

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

52 mm^2 ? Aránytalanul kicsinek tűnik a kabinihez képest, amire 110 mm^2-t írtatok és 128 shader (2cu) van benne plusz a processzorrész. A képe alapján is.

pezo77 #5 2017.12.14. 13:29 Hmm. És ez az e-hajó akkor hol is tud kikötni? Az e-bay -ben? ;)

IGP vs. SoC
Nem összehasonlítható.

De ha a tranyószámot nézed, akkor egymilliárd vs. félmilliárd. Méretben is kb. a fele.

[ Szerkesztve ]

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