ARM+GCN erre kíváncsi leszek!

A fogadtatás a paicon lesz az érdekes.

"Only two things are infinite, the universe and human stupidity, and I'm not sure about the former." (Albert Einstein)

"Az IGP szempontjából egy GCN V.I. architektúrára épülő megoldás lesz bevetve. Valószínűleg 256 shader részelemre van lehetőség, de nem kizárt, hogy 20 nm-es gyártástechnológián több is belefér."

Szerintem meg kizart, hogy 256-nal tobb beleferjen. Azert ennyire me'g az AMD sem zsonglor, a 20 nano a 28 nanohoz kepest ennyit nem hoz. Eleve mar a 256 shader is duplaja a 28 nanon hasznalt 128-nak... Nagyon sokan orulnenek mar a 256-nak is

"Valószínű egyébként, hogy az Amur SoC APU elsődlegesen nem a tabletek piacára nevez. Ez a terület egyszerűen túl telített ahhoz, hogy gyorsan letarolható legyen, illetve az ide való betörés is nagyon nehézkes."

Pont ezt fejtegettem egy masik topicban. Orulok, hogy nem csak en latom ezt a betoresi lehetoseget finoman szolva is nehezkesnek.

Ja, es Nolan FTW

[ Szerkesztve ]

Arra én is marha kíváncsi leszek.

Ez tök jó, tényleg hajrá, csak ezzel most már jelenjen is meg valami. Mármint a csúcsmodellel is, mert A10 Micro-6700T is FTW csak éppen semmit nem lehet vele kapni . Valószínűleg Intel tényleg masszívan olcsón/olcsóbban adja az Atomot, hogy azzal viszont igen.

Nem tudom mennyire erős GPU-ra lenne szükség ebben a szegmensben. Tegra K1-ben ott csücsül 192 mag, de felhasználói élmény nem feltétlenül egyezik meg a specifikáció alapján elvárttal. Vélhetően az is jobban muzsikálna nagyobb géptestben.Hasonlóan Kaveri ULV + kis géptest + CPU turbó esetéhez.
Jó lenne oda 128 is, csak tudja tartani az órajelet.
Viszont Oracle és Google is nagy halak, jó lenne megint szépet kszálni egy adott ügyfélkör számára jól eltalált lapkával.

Szerintem az ARM-os verzió sikeressége azon múlik, hogy ténylegesen mikor kerül piacra a termék, az x86-os verziónál viszont én is félek, hogy feleslegesen fejlesztik, mert hacsak ők nem építenek valamit rá, nem fog bekerülni semmibe, ahogy ez a tendenciából látszik már évek óta. Nem is értem, hogy hova, vagy kinek fejlesztenek, mert a piacra biztos nem. Ráadásul a 20nm már holnap is késve jönne, nemhogy jövőre (és ez még gondolom ez egy best case scenario, vagyis a 2015-ből könnyen lehet 2016 is.

Az a baj a világgal, hogy a hülyék mindenben holtbiztosak, az okosak meg tele vannak kételyekkel.

Pontosan ezért nem lesz semmi a Nolanből sem, papíron szép, de senki sem fog rá terméket építeni, mert az Intel inkább fizet, minthogy a konkurencia levegőhöz jusson. Nekem ne mondja senki, hogy ennyire nincs igény az AMD termékeire, amikor az Atom márkanevet az Intelnek sikerült teljesen lejáratnia.
Én inkább az Amurtól várok valamit, persze nem instant bombasikert.

#7 Tigerclaw: A TSMC 20nm-es gyártósorai elvileg már üzemelnek, ezekben a chipekben pedig semmi radikális nincs, nem szabadna hogy túl sok problémát okozzanak. Az ARM magok licenszelt referencia A57-esek lesznek egyelőre.

[ Szerkesztve ]

"Only two things are infinite, the universe and human stupidity, and I'm not sure about the former." (Albert Einstein)

Egy GCN V.I. CU csak 50 millió tranzisztor. Szerintem nagyjából ~1,5 milliárd lehet a büdzsé, amiből fel kell építeni a lapkát. Ebből a TSMC 20 nm-es LP-n olyan ~70 mm2-es SoC jön ki. Ez azt jelenti, hogy a Beemához képest extra 500 millió tranyó építhető be. Ebbe simán befér akár 384 ALU is. A kérdés, hogy mi lesz még benne, mert ha kap TrueAudiót, ISP-t, valami extra fixfunkciós bizbaszt, akkor abból az 500 millió extra tranyóból maximum 200 költhető az IGP-re, így pedig már 256 ALU tűnik logikusnak.

(#7) Tigerclaw: A beágyazott rendszerekbe. Ott elég sok pici lapkát eladnak, főleg a casino gaming területen. Gyakorlatilag egy év alatt elfoglalták a casino gaming terület 22%-át, és mennek a többi 78%-ért.

[ Szerkesztve ]

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

Arra a piacra nem ágyúval verébre egy ilyen SoC?

"Only two things are infinite, the universe and human stupidity, and I'm not sure about the former." (Albert Einstein)

A fogyasztási adatokról lehet valamit tudni, vagy csak nekem kerülték el figyelmemet a részletek

Nem a SoC-ért veszik, hanem a Mantle-ért. A szoftverfejlesztési költség ezzel jelentősen csökken, és emellett az érdeklődők nem mennek el, mert nem maga a hardver a drága, hanem a játék, amit fejlesztenek rá. Persze ez még csak a Windows Embedded licencszel rendelkezőket érinti, de ha lesz Mantle Linuxra, akkor mennek át a többiek is.

[ Szerkesztve ]

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

Puma+ 256 CU-val karöltve 15 W-os limittel már közel lenne ahhoz, hogy házon belül generáljon konkurenciát (A8-7100 ), bár némi hátrányt jelenthet a 64 bites memóriabusz [de ilyen kis fogyasztással és vélt ez alapján GPU órajellel erre sem vennék mérget].

Árban tippem sincs, mekkora difi az OEM számára Bay Trail és Mullins között. Ötlet? HP-nál a Stream 13 229.99$ (Celeron N2840), Stream 14 299$ (A6 Micro 6400T).

[ Szerkesztve ]

x86 chipek milyen tokozást kapnak?

Premium Mining Rigek és Gamer/Workstation gépek: tőlem, nektek :)

"Mindkét SoC APU két darab 64 bites memóriavezérlőt kap..."

#16 haxiboy: "A két lapka által használt BGA tokozás..."

A második bekezdés túl messze van?

"Only two things are infinite, the universe and human stupidity, and I'm not sure about the former." (Albert Einstein)

A szövegértelmezés is?
Nem a 64 bit volt a kérdés, hanem hogy ebből ezen a fogyasztási szinten valóban származik-e érdemi hátrány a GPU teljesítményt tekintve (mert egy A10 Micro 6700 T GPU max 500 MHz-en ketyeg szemben egy A6-6310 vagy Athlon 5350 800 MHz-ével). Így már érthető vagyok?

[ Szerkesztve ]

Úgy látszik a szövegértelmezés is.

Mindkét SoC-nak két darab, azaz 2x64 bites memóriavezérlője van, ami 128 bit, tehát a kérdésed okafogyott.

Szerk.: Újraolvastam a kedvedért. Egy fél mondattal később:

"ECC használata mellett csak az egyik csatorna működhet."

Tehát félreérteni is csak akkor lehet, ha nem olvastad el rendesen a cikket.

[ Szerkesztve ]

"Only two things are infinite, the universe and human stupidity, and I'm not sure about the former." (Albert Einstein)

Egye-fene igazad van, nekem meg késő
Így viszont tényleg kannibalizálhatja a gyengébb 2 modulos APU-kat.
Jó éjt!

Én eddig se nagyon láttam Kaverivel szerelt notit, csak mutatóban van 1-2, szóval nem nagyon van mit kannibalizálni.

"Only two things are infinite, the universe and human stupidity, and I'm not sure about the former." (Albert Einstein)

Két csatornás memóriavezérlő, imáink meghallgattattak...

Senki sem mondta, hogy lesz belőle 15 wattos verzió. Maximum 6-7 wattosra van szerintem kilátás mostantól, mert Carrizo-L-ből lesz 10-15 wattos.

A Mullins az mindenkinek 40-55 dollár, típustól függően. A Bay Trail ára bonyolult. Főleg attól függ, hogy mibe rakod. A Celeron alapára 20-25 dollár, de ha a Microsoft olcsó programjában résztvevő Binges Windows lesz a gépen, akkor csak 5 dollár. De van az Intel Atom Z3735G. Az ingyenes, ha a végtermék 200 dollárnál olcsóbb.

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

Lehet, hogy tranyo szamban beleferne, de ha jol tudom, a CU-k nem nullat disszipalnak Nem hiszem, hogy TDP-ben beleferne, de persze az is lehet, hogy alacsonyabb orajelen tobb CU-val jobb az osszteljesitmeny, es inkabb ezt valasztja majd az AMD, mint a 256 CU-t magas(abb) orajelen. Nagy kerdes, hogy a CPU es uncore resz hogyan fogja tudni kiszolgalni a sok-sok CU-t, hova jut a Mantle ezen a platformon, es a HSA mennyire zuzza majd szet a piacot. A 128 bit szeles memoria vezerlo mindenkepp szukseges lesz a sok CU-hoz.

[ Szerkesztve ]

"De van az Intel Atom Z3735G. Az ingyenes, ha a végtermék 200 dollárnál olcsóbb."

Mivaan? Az intel promócióként osztogatja az atomokat a gyártóknak ? Nem vet ez fel némi versenypolitikai aggályoskodást ? (nem mellesleg én szívesen kifizetnék 255$-t egy micro-6700T Mullins-os változatért atom helyett...)

30€ Meta store bónusz Quest headset aktiváláshoz, keress priviben :)

HSA nem kérdés. Még az Intel is kontrollálhatatlanul a részévé válik a SOFIA projekttel, mert IGP-ből a SOFIA partnerek is Mali, PowerVR, Vivante megoldásokat használnak majd.
Ez egyértelműen egy eldöntött iránynak tűnik, ráadásul megoldja a fragmentáció gondját, ami a Google számára prioritás. Viszont a HSA nyíltsága azt jelenti, hogy nem csak az AMD fog ilyen rendszert kínálni. 2015-re a Samsung és az ARM is készül.

A Mantle érdekesebb. Ezért is célozhatják szerintem az AMD termékei az Android TV-t. A Google számára kritikus fontosságú egy low-level grafikus API, ha az új iOS-re és Windows (Phone) 10-ra készülő játékokat Androidon szeretnék tudni. Az AEP-ben a portolás szimplán nem oldható meg.

[ Szerkesztve ]

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

Gondolhatod, hogy nem véletlenül termelnek negyedévente egymilliárd dollár veszteséget az ultramobil üzletágban.
Támadható lenne, ha mindegyik gyártó áttérne rá, de még ingyenesség mellett is rendkívül korlátozott sikere van az Atomnak. Amíg a gyártókat ingyen sem érdekli, addig a konkurensek nyugodtak. Ezért is jön a SOFIA projekt, az Intel rájött, hogy így semmit sem ér el, csak a pénzt dobja ki az ablakon.

[ Szerkesztve ]

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

"Valószínűleg 256 shader részelemre van lehetőség, de nem kizárt, hogy 20 nm-es gyártástechnológián több is belefér"
Azért az elég kemény . Mondjuk nem hinném, hogy racionálisan beleférne több, már csak a tervezett TDP miatt se igen lehetne megtenni.

#29: "az Intel rájött, hogy így semmit sem ér el, csak a pénzt dobja ki az ablakon."
Az ő pénzüket - már csak a fentebb írt taktikájuk miatt is - valahogy nem tudom sajnálni...

[ Szerkesztve ]

Cancel all my meetings. Someone is wrong on the Internet.

Mar tobbszor emlitetted a Google fele fragmentaciot, de nem igazan fogom fel, hogyan tudja a HSA megoldani a kijelzo es az oprendszer fragmentacios problemat Ami sokkal nagyobb fejtores a fejlesztok szamara, mint mondjuk egy iGPU fragmentacio. Kulonosen erdekes kerdes, hogy ha a HSA-hoz nem csatlakozik az Intel es az nVIDIA, de ok is jelen vannak az androidos piacon, akkor hasznal vagy art-e a HSA a GPU-val kapcsolatos fragmentacionak... Aztan ott a (Metal,) Mantle, OpenGL ES, ez mind-mind fragmentacio, amin a HSA nem latom, mikepp tudna segiteni.

[ Szerkesztve ]

Ha ütős lesz az Amur, akkor szvsz piacképesebb lehet mint a Nolan. Valóban telített a terület, viszont itt nem az Intel-lel kell konkurálni hanem jóval kisebb, kevésbé befolyásos cégekkel. Az AMD-nek be kell fektetni több 10 000 lapkába, amit mondjuk ingyen felajánl egy nevesebb gyártónak egy jó support csomaggal egy olyan termékhez ami jó referencia lehet nekik.

"Minden negyedik-ötödik magyar funkcionális analfabéta – derült ki a nemzetközi felmérésekből."

Meglatjuk. Szerintem szivni fognak, mert nincsen olyan kiepitett bazisuk, mint az x86 piacon. Iszonyu sok konkurenciajuk lesz, es a mullinsos pelda is jol mutatja, hogy nem feltetlenul tudjak olcson gyartani a procikat 55 dollar rohadt draga egy tablet SoC eseteben, hacsak nem egybol a high-end-be celozzak a cuccot. Mindenesetre en orulni fogok, ha a Mantle es a HSA is befut Androidon (is), de kozben meg felek attol is, hogy az nVIDIA-hoz hasonloan kinlodni fognak. Eleg sok parhuzamot latok a Tegrak es az Amur kozott, de lehet, hogy hulyeseg

A HSA azt fogja megoldani, hogy ha a Google fejleszt egy olyan VM-et, amely HSAIL-be fordít, akkor az garantálja, hogy akármilyen programot írsz a VM-re, az futni fog az összes HSAIL-t támogató hardveren. Ezért nem akar a Google OpenCL-t, mert ott még mindig különálló az IL. Maximum egy köztes fordítási réteg szintjéig lehet közös az alap, de a Google azt akarja, hogy elég legyen egy forráskódot írni portolható teljesítménnyel. Ezt csak a HSA kínálja fel.
Az Intel nem probléma. Ők a SOFIA projektre állnak rá. Adnak processzormagokat például a Rockchipnek, de az IGP főleg Mali vagy PowerVR lesz.
Igazából VM-ből lehet más IL-be fordítani. Ha az NV számára jó, hogy 30-40%-os tempóbüntit kapnak, akkor nem gond a PTX beépítése. A HSA csak ahhoz kell, hogy jó legyen a teljesítmény.

[ Szerkesztve ]

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

Szegény AMD-re már ráférne, hogy bejöjjön a biznisz.
Ha tényleg ott van az APU ahová a Google is gondolja, akkor nyert ügy a piacon! Én szurkolok nekik.

"Akula Sub, ready for the deep!"

A Mantle biztos nem lesz alapból benne az Androidban. Akármilyen open lesz az API az év végén a működése nem a jellemző mobil opciókhoz van tervezve. Az IMR elvű GPU-kkal működik igazán jól. Ilyet pedig ma már csak az AMD, az Intel és a Vivante csinál. Az NV is menetel a Maxwellel a tile-based működés felé, noha eléggé speciális formában, de kezd elszakadni az IMR működéstől. Ha választani kellene, akkor a Google számára inkább a Metal API-ra lenne szükség, mert az eleve tile-based optimalizált. Vagy a DirectX 12, annak van TBR és IMR módja is.
A Mantle a Google számára csak az Andriod TV szempontjából érdekes. Ott bevállalható, hogy nagymértékben leszűkítik a chipválasztást, annak érdekében, hogy versenyben maradjanak az Apple-lel. Jobb ezt választani, mint a vereséget.

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

Oke, tehat akkor egy olyan fragmentaciorol van szo, ami tulajdonkeppen nem is letezik Hiszen a fragmentacio -- ebben az esetben -- arra vonatkozna, hogy egyes gyartok tamogatnak OpenCL-t, masok CUDA-t (nVIDIA), megint masok meg semmit, mikozben nincs is igazan Androidra OpenCL-t vagy CUDA-t kihasznalo szoftver. A Renderscriptet meg eleve zarojelbe lehet tenni, az vegkepp nevetseges. Ergo van egy igeny, hogy GPU-n fusson kod, de azt nem szolgalja ki semmi jelenleg, de a HSA azt igeri, hogy ki fogja. Kiveve persze a Tegrakon meg az Intel cuccain, ami megint hoz fragmentaciot a buliba De oke, alairom, a HSA egy kalap ala gyujtheti a kulonbozo gyartok GPU-it, es lehet majd kodot irni, amely mindegyiken szepen elfutkarozik (kiveve Intel es nVIDIA). Ezt mondjuk OpenCL-lel is meg lehetett volna csinalni on-the-fly forditassal, ha a gyartok csinaltak volna normalis compilereket, de oke, legyen HSA, nekem vegul is mindegy, mikepp cimkezzuk. Az mondjuk egy erdekes kerdes lesz, hogy a HSA-t hogyan lehet majd az Android-fele Javabol meghajtani, ha a Google nem tagja a HSA alapitvanynak, emiatt mondjuk megnyugtatobb lenne, ha belepne. Maskulonben ha takolas kell a HSA kihasznalasahoz Androidon, az nem lesz tul jo buli a fejlesztoknek, es konnyen megint visszakerulhet az egesz az OpenCL szintjere...

[ Szerkesztve ]

Ebbol nekem az jon le, hogy a Google mar fejleszti is a sajat Metal/Mantle konkurens megoldasat -- ha van egy kis eszuk. Mindenesetre, az AMD GPU kompetenciaja jol fog jonni az ultramobil piacon is, csak arazasban le kell tudni nyomni a sok-sok konkurenst.

Ezért érdekli a Google-t a HSA, mert a legtöbb mobil piacra nevező fejlesztő nem akar OpenCL-t. Egy részük persze akar és ezt elfogadták, ott van és szállítsák a programot előtelepítve. Ennyit tudtak tenni. Amit a fejlesztő akar az az IGP kihasználása úgy, hogy ne kelljen megtanulnia új dolgokat. Itt kilyukadunk a Java 9-hez, amiben van Lambda és Stream API, és így ugyanazzal a kóddal kihasználhatók a többmagos processzorok és az IGP is. Nem kell hozzá semmi specifikus dolog, a VM dönt arról, hogy mi hol fut. A Google számára csak egy olyan VM kell, ami támogatja a Java 9-et és HSAIL-be fordít. Rögtön automatikus lesz az IGP-k kihasználása, mert szimpla többszálú kóddal megoldható. És ugyanaz a kód futhat többmagos processzoron, IGP-n, vagy akár mindkettőn egyszerre. Ez alapvetően a terv.

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

Az elég régóta köztudott hogy az intel az atomokat áron alul adja (tehát bukik rajtuk), az viszont nekem is új hogy ingyen is ad már.
A hatóságokkal nincs gond, az ilyen nagy cégek a törvények fölött állnak általában.

Troll (nemhivatalos definíció): az akinek véleménye nem tetszik nekünk/nem értünk vele egyet. (10-ből 9 fanboy ezt ajánlja) || Fanboy 8 in 1 (Intel, AMD, Nvidia, konzol, PC,+minden politikai oldal) hiszen "ahol nem mi vagyunk, ott az ellenség"

Es mindehhez nem kellene, hogy a Google is a HSA alapitvany tagja legyen? Vagy ki fogja megirni helyettuk a Javabol HSAIL-be fordito kodot? Mert ugye az Android nem Java VM-et hasznal, hanem sajat VM-et, ergo ha az Oracle meg is csinalja a Java --> HSAIL forditot, es bedobja a HSA alapitvanyba mint barki altal hasznalhato resource, azt a Google nem fogja tudni hasznalni, mar csak azert sem, mert nem a HSA alapitvany tagja.

Nem szükséges. Az egész projekt az OpenJDK-ra épít. Mivel ez eleve nyílt, így nincs értelme egy alternatív nyílt projektnek. Egyszerűen fel lehet használni a GRAAL-t és az egyéb OpenJDK fejlesztéseket egy saját VM-be.
Az Oracle azért lépett be a HSA-ba, mert ők saját célra is használnák más projektekhez, de az OpenJDK-t természetesen segítik. Az Oracle egyébként hardvergyártó és a későbbi terveikben a HSA egyfajta platformként lesz jelen a SPARC processzorokba helyezett speciális feldolgozók hatékony programozásához. Ennek természetesen az OpenJDK projekt az alapeleme, de a hardveren nyilván elkérik majd a saját kis jussukat.

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

Oke, elfogadom, amit irsz, engem csupan az nyugtalanit kisse, hogy a HSA alapitvanyba -- ha nem tevedek -- egyetlen operacios rendszer fejleszto ceg sem lepett be. Se Apple, se BlackBerry, se Google, se Microsoft, se Oracle. A Microsoft reszerol, az x86 Windows eseteben legalabbis, nem feltetlenul lenne igenyem erre, de a mobil cuccoknal megnyugtatobb lenne latni, hogy platform szintu megoldasrol beszelhetunk. A HSA alapitvany jelenlegi tagjait atnezve leginkabb az jon le, hogy a CPU-gyartok (minusz Intel es Apple) kitalaltak maguknak valamit, amit nehany szoftver gyarto es nehany egyetem jopofanak lat, de a kepbol nagyon hianyzik az osszefogo "ero", amit az operacios rendszerek fejlesztoi jelenthetnenek. Persze tudom en, hogy nem feltetlenul kell oprendszer szintu tamogatas a HSA-hoz, csak hat fejlesztokent sokszor nem ezt tapasztalja az ember, foleg mobil vonalon

Az OS-fejlesztők ráálltak arra, hogy valami OS-specifikus featurrel a platformhoz kell láncolni a fejlesztőket, ezért nem támogatnak semmi olyat, ami univerzális. Ezen csak úgy lehet változtatni, ha a többi piaci szereplő, akiknek ez viszont rohadtul nem érdeke, kikényszeríti a változást. Az meg pont így néz ki.

"Only two things are infinite, the universe and human stupidity, and I'm not sure about the former." (Albert Einstein)

Az Oracle belépett, és a Linuxos disztrók közül is vannak már benne. De az OS-ek esetében ez nem fontos. Nem nekik szól. Persze beléphetnek, de nem az OS-re vonatkozóan fogják megtenni, hanem a hardverekre vagy a programozási nyelvekre vonatkozóan.
A HSA a legtöbb gyártónak az érdeke, mert eléggé világos, hogy a fejlesztők nem fognak minden egyes architektúrára optimalizálni. Lásd az OpenCL, elég sok AMD-specifikus programkód van, amelyek jobb teljesítményt adnak GCN-en, vagy máson egyszerűen nem is futnak. Esetleg egy évvel később írják meg a többi hardverre a támogatást. Ennek a problémának az egyenes megoldása a HSA. Egy forrásból, garantáltan skálázódó teljesítmény, garantált kompatibilitással már megjelenéskor, mindenkinek. Ezért van ez az összefogás a cégek között.

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

Egymástól nagyon eltérő architektúrák között hogy portolják a teljesítményt?

Közös IL-t és AQL-t használnak hozzá. Ez egy fontos eleme a teljesítmény portolhatóságának. Régóta ismerik ezt a koncepciót, csak senki sem hitte, hogy a piac ezért hajlandó ekkora összefogásra.
Az OpenCL esetében pont az a gond, hogy már az IL szintjén is eltérők a rendszerek, AQL pedig nincs is, helyette egy szoftveres réteg van, amire szintén specifikusan kell optimalizálni.

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

GCN - Mali összehasonlítás:
-GCN van LDS, Mali nincs LDS,
-GCN SIMT architektúra, 64 párhuzamos szál egyszerre, Mali a szálakat egyenként ütemezi,
-GCN skalár utasítások, Mali vektor utasítások.
Ezekkel mit kezd a HSAIL/AQL? Ha a kód az egyikre optiMalizált, nem fut hatékonyan a másikon.

Nyilvan a kod egyikre sem lesz specifikusan optimalizalva. Az OpenCL 1.x is megoldotta ezt a kerdest, egyetlen kodbazisbol tudsz forditani AMD VLIW5-re, GCN-re, Keplerre, Maxwellre, Gen7-re, stb. Mas kerdes, hogy mi fog tortenni a platform specifikus optimalizaciokkal, de gondolom az a cel, hogy ezt mindenki elfelejtse, es amolyan "mindenre jo, de semmire nem jo kiugroan" kodot generaljon a fordito. Az az alapotlet, hogy me'g egy optimalizalatlan, GPU-n futo, masszivan parhuzamos kod is gyorsabb lehet -- elvileg --, mint egy CPU-n futo, azonos celu kod.