Hirdetés
- Notebookosított mini PC-t leplezett le az AOOSTAR
- Vélemény: más cég lenne az Intel, ha korábban nevezik ki Lip-Bu Tant
- Barátságot teremtene az ARM és az Anti-Cheat rendszere között az Epic Games
- Hamarosan foghatja a kezét a Copilot a játékosoknak
- Az NVIDIA szerint a nagyobb készletek stabilizálják majd az új GeForce-ok árait
- ThinkPad (NEM IdeaPad)
- Házi hangfal építés
- Mindennél nagyobb: tesztpadon a Ryzen 9 9950X3D CPU
- Milyen billentyűzetet vegyek?
- Épített vízhűtés (nem kompakt) topic
- AMD Ryzen 9 / 7 / 5 9***(X) "Zen 5" (AM5)
- Milyen RAM-ot vegyek?
- Hamarosan foghatja a kezét a Copilot a játékosoknak
- 3D nyomtatás
- Azonnali VGA-s kérdések órája
-
PROHARDVER!
OLVASD VÉGIG ALAPOSAN MIELŐTT ÚJ HOZZÁSZÓLÁST ÍRNÁL!!!
Új hozzászólás Aktív témák
-
dezz
nagyúr
válasz
letepem
#13499
üzenetére
Tudomásom szerint a TSMC ontja magából a PS4 és XBO chipjeit, nincs szabad kapacitás.
De maga az átvitel is hosszadalmas dolog, mert az adott gyártó technológiájához és annak különféle paramétereihez kell igazítani a terveket és utána (a tape-out után) még maga a chipgyártó is törpöl rajta egy sort.
-
letepem
aktív tag
Valami konkrétabb angol/magyar nyelvű publikációt tudnátok linkelni, ami konkrétan kimondja egyes technológiák, mondjuk a bulk vagy soi, hátrányait előnyeit. Azt tudom hogy a kaveri bulk-kal készül, de ez miben előny és miben nem az, a trinitynél/richlandnél/Llano-nál használt SHP-hoz képest?
Köszönöm előre is a választ!
-
dezz
nagyúr
Ezt esetleg a Kaveri híres topikba is beírhatnád. Legjobb lenne aktuális órajeleken és CU szám melletti eredményekkel. (Ha már korábbi kijelentéseid hatására egyesek le is vonták a nagy tanulságot, hogy a Kaveri bukás, irány a boltokba i5-ért...)
(#13492) Thrawn: Nem látjuk egymás hozzászólásait abban a topikban.
"mindenféle innen-onnan elejtett infók alapján"
Fogalmam sincs, hogy itt mire gondolsz. Onnantól kezdve senki sem vitatta Fiery teljesítményre vonatkozó kiejeltéseit, hogy közölte, hogy van náluk egy példány. Bár azt azért megjegyeztük, hogy az azért még csak egy ES, amire ő azt mondta, hogy a végleges is ilyen lehet, aztán utóbb hozzátette, hogy meglátjuk. Korábban csak a nem túl acélos órajelet említette, amire én a megduplázott utasításdekódert hoztam fel, ami nem pletyka, hanem hivatalos információ. Megkérnélek, hogy a tényeknek megfelelően "tudósíts".
-
Fiery
veterán
válasz
#24650752
#13494
üzenetére
+10% es megvan, persze csak ha a memoria savszelesseg nem jelent problemat. De ez csak egy teszt, mas tesztekben kicsit maskepp viselkedhet a Kaveri. De mivel a Cape Verde es a Kaveri is GCN alapu, igy az arányok nagyjabol jol saccolhatoak. Jatekra mindenkepp cool lesz a Kaveri. Mantle-vel meg harapni fog
-
Thrawn
félisten
Nem tudok modkert linkelni de: 2013-11-10 13:48:48
Szóval végigolvastam mindent, a fenti a zanzásított véleményem.Nem lesz az, csak a nagy vita közben elfelejted azt az apróságot, hogy amíg neki van mire alapoznia a véleményét (ott van nála a vas), te csak kb a levegőbe beszélsz mindenféle innen-onnan elejtett infók alapján. Az AMD vs Intel kérdésben én csak eltérő nézőpontokat láttam, innentől kezdve kár is volt annyit ragozni a témát.
Fiery:
-
Fiery
veterán
Csak hogy ON is legyen es poztiv info, meg hogy elkezdjek vezekelni az elmult napokert
Futtattunk Richland vs. Kaveri benchmarkot, iGPU-n, azonos CU (6) szam mellett, azonos iGPU orajelen, azonos CPU magorajelen, azonos memoria orajelen, CPB OFF, APM OFF allasban, OpenCL 1.x, semmi HSA varazslat, klasszikus GPGPU szamitasi feladat. Nem FLOPS, hanem egy konkret szamitasi feladat, ami valodi munkat vegez, nem csak porgeti a CU-kat. Single-precision floating-point tesztben tobb mint masfelszeres teljesitmenyt nyom a Kaveri a Richlandhez kepest, double-precision detto. Ennyivel hatekonyabban lehet etetni a GCN feldolgozokat a VLIW4-hez kepest. Nyilvan ez csak egyetlen (pontosabban 2) teszt, es nyilvan nem ennyire kedvezo a helyzet minden felhasznalasban, de az azert jol latszik, hogy a Kaveri iGPU-jaba tenyleg nehez lesz belekotni, legalabbis ha mas iGPU-kkal vetjuk ossze. A HSA egyebkent ezen a konkret teszten nem segitene, nem lenne tole gyorsabb, max. a kernel launch ideje lenne kicsit rovidebb. -
dezz
nagyúr
válasz
Thrawn
#13489
üzenetére
Ez így nem egészen felel meg a valóságnak. Egyébként meg [link].
A korábbi, HSA-val kapcsolatos vitát is végigolvashatnád.
Attól, hogy van nála egy Kaveri, még nem lesz tévedhetetlen és etalon minden téren. Az AMD és az Intel korábbi tevékenységét illetően konkrétan több tekintetben téved.
-
Thrawn
félisten
"szerintem mindenkinek úgy tűnik"
Az a szerencséd, hogy a "szerintem" szó ott van. Egyébként meg kikérem magamnak.
Az különösen zavar, hogy van aki leírja szárazon a tényeket és erre te nekiesel a ződszemüveggel úgy, hogy közben nem veted meg a személyeskedést sem. Ja és mindezek tetejébe a másikat vádolod kékszemüveg miatt, holott marhára nem így van, csak te látod bele. Nekem, akinek tökmindegy, hogy Intel vagy AMD eléggé szembeötlő ám a mutatványod.Megemelem a kalapom Fiery előtt az elmúlt napok történéseit követve, hogy hellyel-közzel türelemmel viseltetett több fórumozó felé is (nem csak ebben a topikban), akik mintha elfelejtették volna, hogy olyasvalakivel állnak le vitatkozni akinél ott figyel egy Kaveri...
Nálam többször elszakadt a cérna, pedig csak olvasó voltam, írni a modkerbe írtam. Nem történt semmi intézkedés, csak egy privátot kaptam, hogy jól van ez így, meg ez amúgyis egy ilyen topik. Hát akkor offba teszem ezt a hszt is és akkor pont jó lesz ide. -
Fiery
veterán
"de szerintem mindenkinek úgy tűnik, hogy te kárörvendesz ezen."
Legfeljebb neked.
"Amit a kacsintól smiley is csak erősít."
Marmint szerinted. Kerj a forum fenntartoitol egy kulon "karorvendoen kacsinto" es egy "kacsintos, de nem karorvendo" smiley ikont, hogy egyertelmu legyen, hogy melyiket kell hasznalni. Hidd el, onnantol mindenki oda fog figyelni arra, nehogy Dezz felreertse a felhasznalt smiley tipusat. Addig meg kerlek ne taplald bele masokba a sajat velemenyedet es elkepzeleseidet, plane amikor nyilvanvalo rosszindulat vezerel.
-
dezz
nagyúr
A piac és a felhasználók szempontjából rossz, ha késik. Akár még ez is hidegen hagyhat, de szerintem mindenkinek úgy tűnik, hogy te kárörvendesz ezen. Amit a kacsintól smiley is csak erősít.
(#13485) Oliverda: Az lehet, csak az a baj, hogy sokan ténynek veszik. Mondjuk ezen nem segítenek azok a roadmapok sem, amiken kb. az év közepétől látható a Kaveri, miközben az év utolsó hónapjában indul meg csak a szállítás és a köv. év Q1-ben kerül valóban piacra.
-
Fiery
veterán
"Megtudhatnám, miért
van a hsz-ed végén 
helyett?"A kacsintos smiley annak szolt, amit elotte TESCO-Zsömle irt ("komoly egy roadmap"). Nem oromot fejezett ki. Engem teljesen hidegen hagy, hogy mikor jon a Carrizo. Pontosabban nem, hiszen sok szempontbol is fontos nekem az, hogy mikor jelenik meg, de nem leszek szomoru, ha kesobb jon, mint X idopont, es nem leszek boldog, ha hamarabb.
-
dezz
nagyúr
Oké, de ez az órajel viszonylag alacsony.
(#13472) Oliverda: Tudom.
(#13474) Fiery: Megtudhatnám, miért
van a hsz-ed végén helyett?(#13477) Bici: A Kaveri legalábbis 2/3 HSA, a full spect nézve. A legalapvetőbb változásokat a 2. harmad hozza.
(#13478) Oliverda: Egyesek szerint a Kaveri közel egy évet késett. [link] Mások szerint csak felet. Persze kérdés, hogy ezeket mire alapozzák.
-
Fiery
veterán
A HSA terjedese szempontjabol nagyobb baj, hogy a Beema/Mullins sem tamogat HSA-t. A Kaveri HSA tamogatasa alapvetoen nem rossz, bar nem full HSA me'g mindig, de a fejlesztok szamara mar "eleg jo" ahhoz, hogy dolgozzanak vele. A Kaveri mint SVM-capable hardver, ha egy HSA fejleszto szemszogebol nezzuk, teljesen korrekt cucc, jol lehet vele dolgozni. Az orajelek meg nem szamitanak a fejlesztesnel tul sokat
Nagyobb baj, hogy nincs me'g beta allapotu HSA implementacio (szoftver stack) sem, hanem csak alpha, ami nem tartalmaz full funkcionalitast, lassu es bugos is nehol; no meg nem elerheto barki szamara. Nem veletlen, hogy az AMD nem demozta a HSA-t "eloben" az APU'13-on, gyakorlatilag nem volt mit demozni. Mukodik egyebkent az alpha HSA stack, marmint lehet vele HSA-compliant OpenCL 2.0 kernelt forditani es futtatni, csak epp joval lassabban, mint az OpenCL 1.x compile path segitsegevel, ugyanazon a vason. Ez annak koszonheto, hogy a regi, jol bevalt OpenCL --> AMD IL compilert kukaznia kellett az AMD-nek a HSA miatt, es helyette elkezdenie a nullarol fejlesztenie egy OpenCL --> HSAIL compilert. Ez utobbinak az allapota pedig erosen felkesz jelenleg, legalabbis ami a teljesitmenyt illeti.Az ARM-os szereplok munkajanak helyzeterol nem tudok semmit, de meg lennék lepodve, ha elorebb jarnanak, mint az AMD a sajat implementaciojaval. En a magam reszerol ugy gondolom, hogy az elkovetkezo 6 honap soran fog eloallni az AMD egy beta allapotu HSA implementacioval, ami mar publikus lesz, es barmelyik fejleszto (nem csak azok, akik a tuzhoz kozelebb ulnek, NDA alatt vagy maskepp) elkezdhet dolgozni vele. Az azutani 6 honap soran varom a stabil HSA implementacio megjeleneset, azaz mire a Carrizo megjon, addigra lesz ugymond kesz a HSA, szoftver es hardver oldalrol is. Az megint mas kerdes, hogy a szoftver fejlesztok mennyire harapnak ra a HSA-ra, mennyire sok HSA-optimalizalt szoftver jelenik meg jovore. Ha tippelnem kene, mondjuk 10-20 db szoftvert mondanek, legalabbis ha a beta allapotu implementaciokat is szamba vesszuk. Kerdeses persze, hogy ezek kozul a szoftverek kozul mennyi lesz majd altalanosan is felhasznalhato szoftver (pl. en a WinZip-re szamitok jovore), es mennyi lesz specifikus, szuk kor szamara keszulo szoftver (pl. CAD/CAM, kutatas, idojaras modellezes, stb), vagy epp HSA benchmark (pl. a CompuBench vagy az uj PCMark).
-
Oliverda
félisten
Úgysem lesz egy jó darabig megfelelő szoftveres pakk HSA-hoz, amire pedig elterjed (már ha), addigra minden szegmensben meglesz a támogatás.
A Carrizo szerintem teljesen kizárt 2014-re. Legjobb esetben is 2015Q1.
Mondjuk én a Kaveri-t sem vártam annál korábbra mint ahogy jelen állás szerint majd megjelenik. Legalább 1 év szokott eltelni két, komolyabban eltérő lapka megjelenése között. A Llano 2011 júliusában jelent meg, a Trinity tavaly októberben, a Kaveri pedig jövő januárban érkezik. A Richland nem számít, mert az csak kis sorjázás volt körömreszelővel.
-
Áhh, most néztem, hogy a desktop is 2015H1-re van pletykálva.
Én inkább a HSA terjedése miatt tartom túl későnek a 2015-öt. Addigra kész szoftvereknek kellene lenniük.
Vagy a félig-HSA-n is megéri elkezdeni a fejelsztést? A HSA-ban érdekelt ARM-es szereplők mikor akarják villantani a sajátj megoldásaikat? -
Fiery
veterán
Desktopra me'g johet a Carrizo jovore, arra van esely, de azert jo lenne latni egy friss desktop roadmapet. Ha nem keszul el 2014 vegere a Carrizo, akkor szinte biztos, hogy cca. 1 ev mulva bedob az AMD egy Richland-szeru koztes core-t ("Kaveri Refresh") a Broadwell-K elleneben.
-
#13474
Fiery
veterán
TESCO-Zsömle
#13473
Fiery
veterán
válasz
TESCO-Zsömle
#13473
üzenetére
Annyi legalabb kiderult rola, hogy a mobil Carrizo nem jon jovore, csak leghamarabb 2015-ben
-
Abu régebben valami olasmit mondott, hogy a Jaguar kicsit gyorsabb csak a Cortex A16-nél azonos frekin, de a 64 bites ARM procik jóval gyorsabbak, és valami Sandy Bridge-es összehasonlítást említett azonos frekin.
Lehet, hogy félreértettem, ez esetben sorry.Persze, a magméretekkel és fogyasztásokkal nem vagyok tisztában a fenti összehasonlítás kapcsán, pedig ez is nagyon érdekes infó lehet.
Abu, ha olvasod, kérlek, erősíts, vagy cáfolj meg! Kössz!
-
Abu85
HÁZIGAZDA
Lesz benne bidirekcionális power elosztás, de ennek az alapértelmezett működési módja a 3,7 GHz és a 720 MHz. Természetesen ahogy nő a turbó, úgy csökken majd az IGP órajele. Ez fordítva nem lesz igaz az asztali termékeknél.
(#13461) Oliverda: 45 watt a TDP kerete az IGP-nek amiben benne van az UVD és a VCE is. Ezek mellett még van TrueAudio és egy elég komplex memóriavezérlő, plusz a display és a PCI Express. Illetve még az L2 cache a processzornak. Ezt most az AMD már külön számolja hozzá, mert dinamikusan lekapcsolható a háromnegyede.
-
-
-
letepem
aktív tag
Megneztem a cikket a kaverirol es lattam hogy "csak" 3.7 ghz jar a mag turbo nelkul. Lehet ez a GF miatt? Mindig volt valami problema a gyartoval ... nem eleg kiforrott, negyed akkor budzse, stb... akkor miert nem csak tsmc-re terveznek? Dragabb, esetleg keves a kapacitas?
-
Abu85
HÁZIGAZDA
Technikailag az AMD mérnökei rakták össze működőre. Nem a pénz hiányzott, hanem a szakértelem a gyártástechnológia kapcsán. Az R600 már akkor is működött, amikor megtörtént a felvásárlás, csak az ATI verziója feleannyit tudott, mint a végleges hardver. Az AMD-től kaptak egy teljes mérnöki gárdát, hogy radikálisan feljavítsák az órajelet. Ezt megtették, de ezért jelent meg 9 hónap csúszással.
Ezután az AMD rakott át mérnököket, hogy a következő kör már jó legyen. Így álltak át gyorsan 55 nm-re, amit az ATI nem tett volna meg, de a friss segítséggel megvolt a tapasztalat. Az RV770-et is az AMD tervezte át. Eredetileg 480 shaderesnek készült, de már a felvásárlásnál átvette az AMD-től egy csapat, hogy 800 shaderest csináljon belőle. -
Fiery
veterán
A K10 elott volt egy K9, ami kukazva lett, ott kezdodott a rossz szeria. Tehat K9, K10, Bulldozer, Komodo, ez nem csak egy atmeneti benazas meg 1-2 rossz ev, hanem folyamatos benazas. Lenyegeben az ATI felvasarlasa ota nincs teljesitmenyben is versenykepes x86 CPU-ja az AMD-nek. Pusztan veletlen egybeeses?
Az Intelre meg lehet mutogatni, de attol, hogy valaki nyomas alatt van, me'g lehet jo termeket tervezni, pl. az Opteronok a nehez idoszakban is eljutottak rengeteg gyarto gepebe. Aztan meg kikoptak megint, mert megint volt jobb valasztas. -
dezz
nagyúr
Akkor még házon belül volt a gyártás az AMD-nél (*), gyártástechnológiai mérnökcsoporttal, akik segítettek az R600 terveinek gyakorlati kivitelezésében, más szóval gyárthatóvá tételében.
A K10 a koros K8-ra épült és a Bulldozer sem pont úgy sikerült, ahogy szerették volna. Na bumm. Mintha az Intelnek nem lett volna már rossz szériája...
* Apropó, ha az Intel nem akadályozta volna illegális módszerekkel a K8 alapú procik piaci sikereit, valószínűleg ma is meg lennének azok a gyárak és talán a gyártástechnológiában sem lennének annyira lemaradva.
-
Fiery
veterán
Nem egy lufirol beszeltem, hanem tobb lufirol. K10, Bulldozer, Komodo, most meg a HSA. De ahogy fentebb is leirtam, ne legyen igazam a HSA-val kapcsolatban.
"az AMD segítsége nélkül zátonyra futott volna a projekt, az ATI pedig valószínű csődbe jutott volna."
Remelem, itt a penzugyi segitsegre gondolsz, es nem a mernokire
"Az AMD mérnökei segítettek kipofozni."
Persze, egyik naprol a masikra felvasarolsz egy GPU-gyartot, majd te segitesz nekik ugy a mernoki gardaddal, hogy elotte neked semmilyen GPU-fejlesztesi tapasztalatod nem volt. Abszolut eletszagu.
"A GCN-t pedig már együtt hozta létre a két cég mérnökeiből álló csoport."
Nyilvan egyutt hoztak letre, hiszen a Fusion projekt megkovetelte, hogy bizonyos szempontbol egymasnak rendeljek ala a fejleszteseket. De az azert megiscsak furcsa, hogy az AMD-s felvasarlas ota nem tudott az ATI reszleg rossz termeket produkalni, mig az AMD x86 magokkal kapcsolatban hat finoman szolva sem csak success story-k voltak az utobbi 5-6 evben.
"A megfogalmazásod is elég furcsa: ha van kivétel, akkor nem mondhatod, hogy csak a GPU-ik jók."
Egyetlen udito kivetel van, igy igaz. Eleg sovany vigasz.
-
dezz
nagyúr
Hogy ez csak egy lufi, az a te véleményed. A véleményedet ne vedd ténynek, mintha tévedhetetlen lennél! (Számos vállalat szakembergárdája pedig pancserok. Ja, tudom, csak az Intelnél dolgoznak jó szakemberek...
)Az ATI-s dolog már ott nem stimmel, hogy az ATI azért lett hirtelen és váratlanul eladó, mert komoly gondjaik voltak az R600-assal, az AMD segítsége nélkül zátonyra futott volna a projekt, az ATI pedig valószínű csődbe jutott volna. Az AMD mérnökei segítettek kipofozni. A GCN-t pedig már együtt hozta létre a két cég mérnökeiből álló csoport.
A megfogalmazásod is elég furcsa: ha van kivétel, akkor nem mondhatod, hogy csak a GPU-ik jók.
-
Fiery
veterán
A lelkesedessel nincs baj. A tulzott lelkesedes nem celravezeto, plane ha csupan azon alapszik, hogy a gyarto felfuj egy szep nagy lufit
A tenyek viszont azt mutatjak, hogy amiota az AMD megvette az ATI-t, azota az ATI-nak van AMD-je, es nem forditva. Maskepp fogalmazva: csak azok a termekek utnek nagyot, ahol az ATI vonal a dominans, azaz ahol a GPU kore epul a termek. Kivetel ez alol a Jaguar, ott az AMD (CPU) resz is remek. -
Abu85
HÁZIGAZDA
A Mantle kapcsán sok dolgot nem fognak publikusan elmondani. Repi arról fog beszélni, hogy neki milyen előnyöket jelentett (párhuzamos dispatch, direkt memóriaelérés és async compute), és hogy mit lehet vele megcsinálni, amit a DX-szel például nem.
Azért az állóvizet kavarni is kell folyamatosan. A Mantle igen közel került ahhoz, hogy a PC-s gaming piacot monopolizálja. Az lehet, hogy azt mondják a támogatók, hogy nem kell félni, mert lesz DX port, de annak a minősége elmarad majd a Mantle-től, vagyis a játékosoknak csak látszólag lesz választásuk. Igen, a Mantle-lel kiütjük a szabvány API-k korlátjait, de a kasszánál majd komoly árat fizetünk ezért. Én nem látom, hogy ebben mi a jó.
-
Fiery
veterán
Engem nem zavar semmi, csak az szokott mosolyt csalni az arcomra, amikor egy adott marka fanjai a nyilvanvalo tenyeket is figyelmen kivul tudjak hagyni
Es a makacs tenyeket is konkret tamadasnak veszik az imadott marka ellen. Ja, meg az is mokas, amikor a jovorol jelen idoben kepesek beszelni, mint ha mar megnyertek volna egy me'g el sem kezdodott haborut ![;]](//cdn.rios.hu/dl/s/v1.gif)
Akinek nem inge, ne vegye magara persze. -
dezz
nagyúr
Az a kérdés merül most fel bennem, hogy vajon kiből indulsz ki...?
Körös-körül mindenki az Intelt ajnározza, ilyen környezetben az is a másik oldal irányába tűnik elfogultnak, aki középen van. De még ha túl is leng a mutató a 0-án a másik irányba, miért csípi annyira egyesek szemét, hogy van egy kivétel az említett szabály alól?
-
-
#13437
Oliverda
félisten
Balala2007
#13436
Oliverda
félisten
válasz
Balala2007
#13436
üzenetére
Igen, ezzel tisztában vagyok.
-
#13431
Oliverda
félisten
Balala2007
#13430
Oliverda
félisten
válasz
Balala2007
#13430
üzenetére
Köszi! Az IVB-hez képest írási műveletekben van jelentős lemaradás. A Haswell az L1-nél duplázta az adatút szélességét az IVB-hez képest, ami itt is jól látszik.
-
Balala2007
tag
válasz
Oliverda
#13424
üzenetére
Turbo/C1E/CPB/stb. letiltva, 1 szalon, Bytes/clk:
AMD 610F01 INTC 306A8 INTC 306C3
L1D 31.867 B/c 31.975 B/c 63.897 B/c
L2 15.930 B/c 17.877 B/c 29.309 B/c
Write
L1D 5.858 B/c 15.994 B/c 31.976 B/c
L2 5.605 B/c 10.663 B/c 10.142 B/c
Copy
L1D 11.802 B/c 31.974 B/c 63.903 B/c
L2 9.683 B/c 15.876 B/c 15.915 B/c -
Fiery
veterán
válasz
Oliverda
#13424
üzenetére
"Finally, the performance values of L1 and L2 cache should reach those of Intel Ivy Bridge and Haswell."
Bulls***. Abszolut ertekben a Kaveri az Ivy Bridge sebesseget nem hogy nem eri el, de a legtobbszor meg sem kozeliti. A Haswellrol mar ne is beszeljunk, az fenyevekre van cache tekinteteben a Kaveritol.
Richland A10-6800K (read/write/copy/latency):
- L1 = 273868 / 49961 / 101432 / 0.9
- L2 = 179671 / 47835 / 87232 / 9.3Ivy Bridge 3770K (read/write/copy/latency):
- L1 = 472238 / 236482 / 471848 / 1.1
- L2 = 243322 / 153415 / 221859 / 3.3Haswell 4770 (read/write/copy/latency):
- L1 = 817131 / 346839 / 755005 / 1.1
- L2 = 356945 / 148899 / 221798 / 3.5A Turbo miatt kicsit nehez orajelciklusra atszamolni ezeket, de azert az arányok jol latszodnak igy is. Ha megis at akarod szamolni, akkor a Richland kb. 4.30 GHz-en, az IVB kb. 3.70 GHz-en, a HSW kb. 3.40 GHz-en futott a benchmark kozben. Persze le kell osztani core-okra is, stb, nem egyszeru az architektura kepessegeig leasni. De a nap vegen ugyis az szamit, hogy az adott orajelen, az adott magszam mellett mire is kepes a cucc osszessegeben.
-
Oliverda
félisten
"In particular, the L2 Cache becomes much faster, by about 20% compared to Richland, a non-negligible value, while the L1 cache increases both size and speed. Finally, the performance values of L1 and L2 cache should reach those of Intel Ivy Bridge and Haswell."
Azonos órajelen mennyivel gyorsabb a Trinity/Richland párosnál az IVB (és a Haswell) az L1 és L2 cache sebességét tekintve?
-
Fiery
veterán
"A CUDA az olyan dolgot nem kínál, amit az OpenCL ne kínálna fel. Még csak gyorsabb programok sem írhatók benne. Az OpenCL-lel alapvetően ugyanúgy tudod használni bármelyik GPU-t, mert a lényeges dolgokban egyezik a CUDA és az OpenCL. Némileg persze más a körítés, de amit CUDA-ban megírsz azt legalább ugyanolyan jól meg tudod írni OpenCL-ben."
...
"A fejlesztői oldalon a CUDA-t azért cserélik manapság OpenCL-re, mert pont ugyanarra jó, így felesleges két fejlesztési irányt fenntartani. Ha csak az OpenCL-re koncentrálnak a fejlesztők, akkor összességében még jobb is lehet a sebesség, mintha írnának CUDA és OpenCL portot egyszerre. Ez egy előnyös dolog a piac minden résztvevőjének: kevesebb fejlesztéssel gyorsabb programok, melyek futnak minden gyártó újabb hardverein. Minden szempontból win-win szituáció."Kivetelesen 100%-ig egyetertek Abuval. Mi is gondolkoztunk azon, hogy az OpenCL GPGPU stressz tesztet vagy az OpenCL GPGPU benchmarkokat portoljuk-e CUDA-ra, de semmi ertelme. Ugyanazt a funkcionalitast, ugyanazt a teljesitmenyt kapod. Sot, ha jol tudom, a ForceWare az OpenCL kodot az elso forditasi fazis utan mar a CUDA feluleten keresztul forditja tovabb es futtatja le, ergo tok mindegy, melyiket hasznalja az ember. Amikor az OpenCL-ben me'g nem lehetett lekerdezni pl. az NVCC-t (Compute Capability), azaz detektalni a GPU generaciojat (pl. Fermi vs. Kepler, GK10x vs. GK110, stb), addig talan volt ertelme a CUDA-nak, mert jobban lehetett specifikusan optimalizalni. De most mar az OpenCL-en at is 100%-osan lehet detektalni az nVIDIA GPU tipusat, az NVCC-t es a PCI eszkozt is, ergo ez az elonye is elveszett a CUDA-nak.
A Mantle kapcsan egyebkent hamarosan beszamol az AMD reszletesen is az API-rol, en szemely szerint nagyon kivancsi leszek ra, mert ha eleg jol van kitalalva, akkor baromi sok mindent ki lehet majd belole hozni. Mondjuk en azert is orulok a Mantle-nak, mert vegre valami felbolygatja az allovizet. Ahogy az angol mondja: S*it hits the fan
-
dezz
nagyúr
"Az AMD-nek speciel pont ezért kellett az ATI, mert megvették vele a HDL-t is."
Legfeljebb ezért is kellett nekik...
(#13420) leviske: Egyszerű: a nextgen konzolokba AMD chip került, nem NV. Így kellő hátszéllel indul a Mantle, aminek a megjelenése egyben szükségszerűség is.
Egyébként milyen grafikus API lesz a SteamOS-ben?
-
Abu85
HÁZIGAZDA
válasz
Oliverda
#13419
üzenetére
Ha jön egy szabványos alternatíva a Mantle-re, akkor nyilván nem fog maradni, vagy csak minimális szerepet kaphat, mint a CUDA. Bár szerintem ha már szabvány, akkor nem a Mantle-re kellene reagálni, hanem továbblépni még egy lépést és az lenne a szabványos megoldás. A Mantle alternatíva szerintem elhibázott megoldás lenne. A Mantle beépítése nem sok idő. Mindössze két-három hónap alatt meg tudják oldani a fejlesztők. A GCN architektúra működésének megtanulása időigényes és költséges. Az AMD-nek itt mázlija van, mert a konzolok miatt úgyis meg kell tanulni a GCN működését, tehát a Mantle csak a beépítési időt igényli. Egy szabványos low-level API igényelné még a többi architektúra működésének megtanulását is, ami nem sokkal jobb, mintha mindenki saját zárt API-t fejlesztene.
A kiutat abban látom, hogy a cégeknek meg kell egyezniük a textúrázás és az egyéb fixfunkciós dolgok hardver oldali szabványosításán. Erre épülne egy olyan virtuális felület, ami elrejtené magát a hardvert a fejlesztők elől, de mégis elég közel lenne a hardver hatékony működtetéséhez. Ekkor erre lehetne írni egy szabványos low-level grafikus API-t, és elég lenne a virtuális felület működését megtanulni. A fejlesztők erre írnák a kódokat, míg a gyártók a fizikai hardvereket ehhez igazítanák. Ha most leülnek, akkor 3-4 éven belül lehet belőle valami.(#13420) leviske: Ha az AMD csak úgy előáll egy Mantle-lel mondjuk 2010-ben, akkor az érdektelen lenne. Nem azért, mert rossz lenne, hanem azért, mert az API beépítése az nem túl nagy feladat, viszont a hardver alacsony szintű működésének ismeretére már nem költenének a kiadók. A Mantle csak azért vált értékes alternatívává, mert a konzolok miatt úgyis meg kell tanulni a GCN-t. Amit ott megtanulnak, azt hasznosítani tudják Mantle alatt is. Bárki más előáll egy saját zárt API-val, annak meg kell küzdenie azzal, hogy a fejlesztőket több millió dollárral támogassa különféle képzések során, különben nem fogják megtanulni olyan hardvert, ami csak PC-re van mondjuk.
Az MS senkinek a számításait nem húzza keresztül. Egyszerűen csak lassan fejlesztenek. Ami rossz, de ez ugyanúgy érint mindenkit és nemcsak az NV-t. A GCN is bindless, akárcsak a Kepler, de mondjuk az Intel top fejlesztése már nem az. Sok dologban hibás az MS, de nem mindenben. Valami csak a körülmények miatt alakult ki. -
leviske
veterán
"Kevesen tudják, de őket is érinti a DirectX fejletlensége."
Ezen a ponton viszont számomra teljesen érthetetlenné vált a mostani helyzet. Adott egy cég, aki gyakorlatilag már 2008-ban neki akart menni az Intelnek és ha a körülmények adottak lettek volna, akkor lazán a háttérbe is szorítják mind a két processzorgyártót. Ez a cég nemrég (tudtommal) szorosan részt vett egy, játékokra kihegyezett operációs rendszer kifejlesztésében.
Mégis hogy a fenébe lehet, hogy pont az AMD állt elő saját API-val, miközben az nVidia számításait évek óta keresztülhúzza a Microsoft a DX fejlesztési irányával? A Steam OS/BOX pont egy tiszta lap lett volna a cégnek és az nVidia ARM-es jövőképe az eddigi elhangzott Valve-es tervekkel össze is vágna. (Ugye az eddigiek alapján amolyan nyíltforrású WiiU ellenfelet akar a cég, valamivel több HC címmel.)
-
Oliverda
félisten
Anno amikor bejött a CUDA még nem tartott ott az OpenCL ahol most, de ezt továbbvezetve az sem kizárt, hogy később a Mantle is a CUDA sorsára jut, ha jön egy olyan API ami képes lesz gyártófüggetlen modellel hozni a teljesítményét. Ha az OpenCL-nek ez sikerült akkor miért ne. Amúgy sem tesznek jót a piacnak a zárt API-k, így felőlem az összes mehet a levesbe.
-
-
Abu85
HÁZIGAZDA
válasz
Oliverda
#13415
üzenetére
A CUDA az olyan dolgot nem kínál, amit az OpenCL ne kínálna fel. Még csak gyorsabb programok sem írhatók benne. Az OpenCL-lel alapvetően ugyanúgy tudod használni bármelyik GPU-t, mert a lényeges dolgokban egyezik a CUDA és az OpenCL. Némileg persze más a körítés, de amit CUDA-ban megírsz azt legalább ugyanolyan jól meg tudod írni OpenCL-ben.
A Mantle egyedi, mert nincs a PC-s piacon más konzol stílusú, alacsony szintű grafikus API, csak két szabványos, magas szintű megoldás, illetve ennek vannak specifikus kiegészítői a gyártóktól, de ettől az API limitációi megmaradnak. Rengeteg olyan dolog van amit a Mantle-ben megcsinálhatsz, de a DirectX-ben vagy az OpenGL-ben nem tudod megtenni. Nem mindegyiknél az API a limitáció, valamikor a WDDM a gond, de az eredmény az, hogy a mai hardverek képességeit alig lehet hasznosítani.
A fejlesztői oldalon a CUDA-t azért cserélik manapság OpenCL-re, mert pont ugyanarra jó, így felesleges két fejlesztési irányt fenntartani. Ha csak az OpenCL-re koncentrálnak a fejlesztők, akkor összességében még jobb is lehet a sebesség, mintha írnának CUDA és OpenCL portot egyszerre. Ez egy előnyös dolog a piac minden résztvevőjének: kevesebb fejlesztéssel gyorsabb programok, melyek futnak minden gyártó újabb hardverein. Minden szempontból win-win szituáció.
A Mantle-re azért mennek a fejlesztők, mert elegük van a limitációkból. Ez megnöveli a fejlesztési költségeket, mert minimum kell egy szabványos leképző is, de cserébe mindazok az effektek, amiket a konzolokra dolgoznak ki portolhatók lesznek PC-re. Igaz, hogy csak a Mantle-re, de kezdetnek megteszi. Ha nem építik be a Mantle támogatását, akkor azzal csak azt érik el, hogy bizonyos konzolra írt effekteket PC-re nem tudnak áthozni. Ezért kell erre válasz az NV oldaláról is, mert a DirectX kóddal mindenképp rosszul járnak a Mantle ellenében. De ha csinálnak egy saját API-t, akkor nyilván nem biztos, hogy minden játékban benne lesz, de legalább nem a szabvány kódra építenek, ami a lehető legrosszabb lesz.
Nem számít, hogy az adott API zárt-e, ha nincs nyílt alternatívája. Vagy támogatják, vagy effektek maradnak ki PC-n, amelyekre alternatív, de butább megoldásokat kell keresni. -
Oliverda
félisten
-
Abu85
HÁZIGAZDA
válasz
Oliverda
#13412
üzenetére
Ettől még az indokok ellene szólnak. Üzletileg semmivel nincsenek előrébb, mert az árszintek rosszak, nincs reakció az AMD szoftveres támadására, és továbbra is az Intel licencpénze felel az NV-nél a nyereség nagy részéért.
Az rendben, hogy Carmack meg Sweeney ellenzi, hogy legyen több low-level API PC-re, de lassan nincs más választása az NV-nek. Kevesen tudják, de őket is érinti a DirectX fejletlensége. Többek között nekik is bindless a rendszerük, és eközben a CPU-t terhelik a DirectX modelljével, de ugyanannyira küzdenek a WDDM limitációitól is. Csinálhatsz egy rakás modernebb működésű hardvert, de amíg a DirectX működése nem változik, addig ezek a fejlesztések csak úgy vannak.Az FTC nem véletlenül kötelezi az Intelt az x16-os PCI Express megtartására. Az NV vitt nekik bizonyítékot arról, hogy a gyártóknak már olyan terveket küldtek 2013-ra, hogy nem lesznek VGA-k a notiban, mert csak x4-es PCI Express lesz a Haswellben. Ezért született meg a 2016-ig tartó kötelezettségvállalás.
-
Abu85
HÁZIGAZDA
válasz
radi8tor
#13411
üzenetére
Teljesen mindegy, hogy a grafikus vezérlő az IGP vagy dGPU. Ez csak egy formalitás, de a működés tekintetében az API nem tesz különbséget.
Arról nincs adat, hogy kikapja-e az Intel a széles PCI Express vezérlőt. Az FTC-vel kötött megállapodás szerint egy x16-os csatornát kell biztosítaniuk a VGA-knak minden platformjukban, és ez 2016-ig él. De ezt tudja az NV is, hiszen ők panaszolták be őket, hogy az Intel ki akarta venni a széles PCI Express vezérlőt, amit az FTC megakadályozott. Ezt azonban nem teszik meg a végtelenségig, így 2016-ra az NV-nek is kell egy platform, de ez már 2015-re is meglesz nekik.
Ez független dolog egyébként a szoftveres harctól, ami egyre nagyobb lesz az elkövetkező években. -
Abu85
HÁZIGAZDA
válasz
Oliverda
#13409
üzenetére
Még most sem látom az értelmét, mert 400 dollárig nem mentek le, ahova kellene a termék. De az NV is tudja, hogy nem ez a gondjuk, hanem az, hogy a Mantle bejelentése óta számos stúdió kereste meg az AMD-t az eddigi támogatók mellett. Innentől kezdve erre kell reflektálni, mivel a hardver másodlagos tényező lesz. A Mantle szoftveres előnyét semmi sem hozza be.
Sajnos pont úgy alakul minden, ahogy azt eltervezték. Pár iparági top stúdió/kiadó bedobja rá a támogatást, és innentől kezdve vagy reagálnak rá a konkurens stúdiók a viszont támogatással vagy technikailag lemaradnak. Ezután mindegy, hogy az NV milyen hardverrel fog jönni, ha a játékok Mantle portot kapnak. Ez egy brutális puccs, a lehető legbrutálisabb beavatkozás a PC-s játékpiac alakulásába. Ennek egyenes következménye előbb a szegmentáció, majd később a monopólium lesz, ami rossz a piacra nézve. -
Abu85
HÁZIGAZDA
válasz
leviske
#13407
üzenetére
A HDL egyelőre csak a TSMC-nél van és a Bobcat/Jaguar már használja. A Glo-Fo esetében kizárt, hogy 32 nm-es SHP-ra implementálnak HDL-t. Ennek nem lenne értelme.
Egyébként a HDL-t nem kell próbálni, lassan 8 éve használják a GPU-khoz. Semmi extra nincs benne, csak nehéz ilyet fejleszteni. Az AMD-nek speciel pont ezért kellett az ATI, mert megvették vele a HDL-t is. Azt visszaimplementálják procira. Egyébként HDL-féle technikát használ az NV és még az ARM/Imagination/Qualcomm trió is. A fizikai implementációkban érdekelt cégek közül egyedül az Intel nem használ ilyet. -
leviske
veterán
A pletykák szerint a Warsaw egy HDL-es "próba", nem? Mert ha annak ellenére is tudnának szerverekben órajelet emelni, akkor a desktop verziókkal a mostaniakkal azonos fogyasztás mellett elég szépen tudnának egyet ugrani.
Más kérdés, hogy amennyiben az APU-k játékokban nem CPU+iGPU, hanem "bővítettCPU" formában lesznek kihasználva, akkor elég skizofrén hozzáállás volna még AM3+ foglalatos processzorokkal is bővíteni a kínlatot.
-
#13406
Ricsiii1992
tag
Fiery
#13405
Ricsiii1992
tag
Steamroller -es fx-re gondoltam (keverem már ezt a sok nevet)
Azért reméltem hogy lesz valami újdonság AM3+ba is; de akkor úgy tűnik nemigazán.Ha nem is több mag, de akkor az a 4 mehetne magasabb frekin, szerintem az a +25W már nem számítana, inkább a tesztekben elért szebb eredmény. Akinek meg számít, az venne 100W-osat alacsonyabb frekivel.
A 140W-ot is száműzték AM3-nál, csak a C2-es Phenom 965 volt annyi, szinte az összes lap tudja a 140-es TDP-t, kijöhetett volna annó a 8150 is pl 140W-tal 3.6 helyett 3.8-4GHz-en , vagy a 8350 4.2 körül. És ez mégse 220W tdp, mint a...
-
#13405
Fiery
veterán
Ricsiii1992
#13404
Fiery
veterán
válasz
Ricsiii1992
#13404
üzenetére
Piledriver modulos FX most is van, Visheranak hivjak. Lesz majd valami frissites az FX platformra jovore (Warsaw kodnevu FX proci, tovabbra is AM3+ foglalatba), de velhetoen csak egy kis orajel emelesben, esetleg szofisztikaltabb CPB mukodesben ki fog merulni a frissites, hasonloan a Trinity --> Richland valtashoz
Az AMD mar egy jo ideje hallgat az FX vonalrol, legalabbis sem Steamrollerre, sem Excavatorra epulo FX-ekrol nincs szo az utitervukben.A TDP pedig egyeni dontes kerdese. Az FM1, FM2, FM2+ platformokat eleve max. 100 Wattra terveztek, ennel feljebb menni nincs sok ertelme. A sok magnak meg abbol a szempontbol nincs ertelme, hogy nem hozna ugysem annyit a konyhara teljesitmenyben, mint amennyivel dragabb es nehezkesebb lenne legyartani. Ez a mostani 2 modulos, eros iGPU-val tarsitott megoldas az AMD "sweet spot"-ja, amihez ugy tunik, ragaszkodni is fognak, hacsak valami alapvetoen nem valtozik meg a mostani mainstream desktop/mobil piacon. Amire leghamarabb 2015-ben lehet esely, a Skylake formajaban. De az is lehet, hogy az megint csak "business as usual" lesz, a Haswellnel kicsivel erosebb CPU-val, es 20-30%-kal erosebb iGPU-val -- az esetben pedig nem fogja a Skylake sem felforgatni a mostani piacot.
-
#13404
Ricsiii1992
tag
Ricsiii1992
tag
Arról esetleg van valami hír, hogy lesz-e Piledriver modulos FX?
Most hogy kijött a Radeon 290x, elég fura lenne, ha nem jönne valami erősebb FX is hozzá. A Kaveri 2 modulja meg kevés lesz egy ilyen kaliberű kártyához. Esetleg annyira besegít majd az IGP, hogy bőven elég lesz a 2 modul is mindenre?
Amit még nem értek: ott a 100W tdp FM2-be, miért nem emelik 125-re?, és akkor jöhetne 3modulos APU is
AM3-ban se vészes a 125W, miért korlátozzák magukat az alacsonyabb TDP-vel? -
leviske
veterán
Futtattunk Richland vs. Kaveri benchmarkot, iGPU-n, azonos CU (6) szam mellett, azonos iGPU orajelen, azonos CPU magorajelen, azonos memoria orajelen, CPB OFF, APM OFF allasban, OpenCL 1.x, semmi HSA varazslat, klasszikus GPGPU szamitasi feladat. Nem FLOPS, hanem egy konkret szamitasi feladat, ami valodi munkat vegez, nem csak porgeti a CU-kat. Single-precision floating-point tesztben tobb mint masfelszeres teljesitmenyt nyom a Kaveri a Richlandhez kepest, double-precision detto. Ennyivel hatekonyabban lehet etetni a GCN feldolgozokat a VLIW4-hez kepest. Nyilvan ez csak egyetlen (pontosabban 2) teszt, es nyilvan nem ennyire kedvezo a helyzet minden felhasznalasban, de az azert jol latszik, hogy a Kaveri iGPU-jaba tenyleg nehez lesz belekotni, legalabbis ha mas iGPU-kkal vetjuk ossze. A HSA egyebkent ezen a konkret teszten nem segitene, nem lenne tole gyorsabb, max. a kernel launch ideje lenne kicsit rovidebb.
van a hsz-ed végén 
helyett?"
Kérdés, hogy a linux hogy áll a HSA-val.
Nagyobb baj, hogy nincs me'g beta allapotu HSA implementacio (szoftver stack) sem, hanem csak alpha, ami nem tartalmaz full funkcionalitast, lassu es bugos is nehol; no meg nem elerheto barki szamara. Nem veletlen, hogy az AMD nem demozta a HSA-t "eloben" az APU'13-on, gyakorlatilag nem volt mit demozni. Mukodik egyebkent az alpha HSA stack, marmint lehet vele HSA-compliant OpenCL 2.0 kernelt forditani es futtatni, csak epp joval lassabban, mint az OpenCL 1.x compile path segitsegevel, ugyanazon a vason. Ez annak koszonheto, hogy a regi, jol bevalt OpenCL --> AMD IL compilert kukaznia kellett az AMD-nek a HSA miatt, es helyette elkezdenie a nullarol fejlesztenie egy OpenCL --> HSAIL compilert. Ez utobbinak az allapota pedig erosen felkesz jelenleg, legalabbis ami a teljesitmenyt illeti.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Akinek nem inge, ne vegye magara persze.
Ú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!
Az ide nem illő hozzászólások topikja:[link]
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 processzorainak kivesézése, lehetőleg minél inkább szakmai keretek között maradva.
- exHWSW - Értünk mindenhez IS
- ThinkPad (NEM IdeaPad)
- Windows 11
- Kapcsolja ki, kapcsolja be!
- MWC 2025: A kicsi és a kamerás - megjött a Xiaomi 15 és az Ultra
- Házi hangfal építés
- Külpolitika
- Mindennél nagyobb: tesztpadon a Ryzen 9 9950X3D CPU
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- Kingdom Come: Deliverance II teszt
- További aktív témák...
- BESZÁMÍTÁS! Intel Core i9 9900K 8 mag 16 szál processzor garanciával hibátlan működéssel
- AMD Ryzen 9 5950X 16-Core 3.4GHz AM4 (64 M Cache, Up to 4.9GHz) Processzor! BeszámítOK
- Intel Core i7 10700 - 4.9 GHz - 8mag/16szál - Eladó!
- BESZÁMÍTÁS! AMD Ryzen 7 5800X3D 8 mag 16 szál processzor garanciával hibátlan működéssel
- AMD Ryzen 5 5600 - Új, 3 év garancia - Eladó!
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest