AMD toont ARM-serverchip en kondigt x86-ARM-chips aan

AMD heeft tijdens een presentatie zijn eerste demonstratie gegeven van het Seattle-platform, de codenaam voor AMD's serverplatform op basis van 64bit-ARM-chips. Ook kondigde AMD aan volgend jaar x86-apu's met ARM-cores te combineren.

De eerste demonstratie van het Seattle-platform bestond uit een LAMP-webserver, waarmee een Wordpress-blog en videostream werden geserveerd. Het demoplatform bestond uit een 64bit-Opteron A1100-serie processor met maximaal 128GB registered ddr3-geheugen. Ook had het platform acht pci-express-lanes verdeeld over twee slots en acht sata-poorten.

De eerste samples van het Seattle-platform zijn al uitgeleverd, terwijl de commerciële uitrol in de tweede helft van dit jaar moet volgen. AMD ziet de vraag naar compacte en zuinige servers met ARM-cores naar eigen zeggen toenemen. Seattle wordt op 28nm geproduceerd.

Verder kondigde AMD voor 2015 Project SkyBridge aan. Dit platform moet ARM-A57-cores combineren met Puma+-cores en een gcn-gpu. De apu's en socs van Project Skybridge moeten op 20nm worden geproduceerd. Met deze strategie, die AMD 'ambidextrous computing' noemt, wil het bedrijf niet alleen embedded toepassingen aandrijven, maar ook voor consumentenproducten ontwikkelen.

Voor 2016 staat verdere ARM-integratie van AMD-producten op de roadmap. Het bedrijf heeft een licentie van ARM gekocht om zelf ARM-cores te ontwikkelen. In 2016 zouden de eerste door AMD ontworpen ARM-cores met 64bit en codenaam K12 moeten worden uitgebracht. Die zouden standalone, in Seattle en gecombineerd met x86-apu's als in Project Skybridge moeten worden gebruikt.

Reacties (48)

[Android Cpt]

X86-ARM?, klinkt goed, x86 software op arm, maar dan lijkt een zuinige gewone x86 me weer beter, ben benieuwt

[Morphix]

Als ik Anandtech mag geloven is er helemaal geen sprake van 'gecombineerde' cpu's. Het gaat om pin-compatible cpu's. Ergo, de arm soc past op dezeflde moederborden als de compatible x86 soc. Knap staaltje journalistiek dat dit in dit artikel niet naar boven komt.

[TweakingRens]

Staat ook in het laatste plaatje, "APUs and SOCs with pin-compatible x86/ARM compute"
Jammer, had leuk geweest om snel te kunnen switchen tussen Android en Windows. Dat had AMD flink wat marktaandeel opgeleverd op het tablet/hybrid vlak.

[robvanwijk]

Nee, niet snel switchen, tegelijk draaien! Vroeger hadden we een co-processor voor FP, vandaag de dag hebben we een co-processor (al wordt het niet meer zo genoemd) voor graphics; als AMD echt gelooft in "heterogeneous" dan zie ik geen reden waarom ze niet x86, GCN én ARM cores op één stuk silicium kunnen plakken.

Bij de meeste huidige multicores is het zo dat alle cores identiek aan elkaar zijn (uitzondering: big-little, al draaien die wel dezelfde instructieset), maar dat hóéft niet; het is op zich prima mogelijk om (bijvoorbeeld) vier x86 cores en twee ARM cores naast elkaar te zetten... als daar tenminste een markt voor is.

Ja, je OS zal flink herschreven moeten worden om support te hebben voor meerdere, gelijkwaardige^*) architecturen in een machine, maar ik zie niet in waarom het niet zou kunnen. Nou ja, zelfs als "Windows 9" het ondersteunt; practisch gezien gaat natuurlijk niemand devven voor ARM-voor-de-pc totdat Intel dit ook aanbiedt...

*) Op dit moment gebruiken CPU en GPU wel verschillende architecturen, maar ze zijn niet gelijkwaardig: er is er duidelijk eentje de baas.

[Squee]

Nee, niet snel switchen, tegelijk draaien! Vroeger hadden we een co-processor voor FP, vandaag de dag hebben we een co-processor (al wordt het niet meer zo genoemd) voor graphics; als AMD echt gelooft in "heterogeneous" dan zie ik geen reden waarom ze niet x86, GCN én ARM cores op één stuk silicium kunnen plakken.

Dat zal ook niet zo'n probleem zijn, maar wat is daar het praktisch nut van? Het klinkt natuurlijk wel leuk en stoer om een x86 en een ARM core op een SoC te plaatsen maar het is natuurlijk een nachtmerrie om er programma's voor te schrijven, en al helemaal voor 'general purpose computing'. Het is overigens ook absoluut niet iets nieuws, in de embedded wereld zijn ze van oudsher gewend te werken met heterogene architecturen waarbij meerdere soorten CPUs aan een bus hangen, of meerdere soorten cores op een chip geintegreerd zijn.

Het grootste probleem is natuurlijk binaire compatibiliteit, want dat is er gewoon niet tussen ARM en x86, en als je de ene instructieset op de andere architectuur wilt gaan emuleren dan is het einde helemaal zoek want dat heeft echt totaal geen toegevoegde waarde meer. Je zou dan eigenlijk naar een besturingssysteem toe moeten wat om kan gaan met verschillende architecturen, maar dan ontkom je niet aan het gebruik van OF alleen maar Just-in-time compilatie (denk aan Java, .NET of LLVM) zoals het HeliOS project van Microsoft Research, of je moet naar een systeem toe met meerdere binaire representaties in een enkele executable, zoals MacOS een tijdje ondersteunde met 'Universal Binaries' om op x86 of PowerPC te kunnen draaien. Of een ander goed voorbeeld van langer geleden was het Amoeba distributed operating systeem van Tanenbaum van de VU wat op een heterogeen cluster kon draaien waarbij elke binary geannoteerd was met op welke architecturen deze kon draaien zodat de scheduler wist waar hij het kon plaatsen.

En dan begin ik nog niet eens over shared libraries, shared state en endianness... maar kort samengevat; zeker niet triviaal dus!

[robvanwijk]

Dat zal ook niet zo'n probleem zijn, maar wat is daar het praktisch nut van?

Sommige architecturen zijn beter geschikt voor bepaalde taken dan andere. Ik bedoelde x86+ARM niet als variant op big-little (waar taken van de ene naar de andere core worden geschoven), maar als variant (uitbreiding) op x86+GCN, waar elk (deel van een) programma voor een specifieke architectuur is geschreven.
Als je er redelijkerwijs vanuit kunt gaan dat elke APU over één of meer ARM cores beschikt, dan kun je taken die op ARM beter / makkelijker / zuiniger zijn daarvoor schrijven. Vandaar ook mijn opmerking over dat Intel wel mee moet doen voordat dit nuttig wordt. En ja, in een overgangsperiode waarin veel van je klanten nog een APU (of CPU) zonder ARM hebben kom je dan bij fat binaries-achtige oplossingen. Niet ideaal, maar je moet wat.

Het grootste probleem is natuurlijk binaire compatibiliteit, want dat is er gewoon niet tussen ARM en x86

Als je bovenstaande verduidelijking hebt gelezen dan zul je zien dat dit juist geen probleem is, want dat is juist niet nodig.

[MSalters]

Je OS hoeft waarschijnlijk niet zo erg herschreven te worden als je dacht. Zowel Linux als Windows zijn al multi-arch sinds x64. Het verschil tussen 32 en 64 bits processen is erger dan het verschil tussen x86 en ARM. In een 32/64 bit mix zijn je pointers niet meer dezelfde lengte, terwijl dat issue niet speelt met ARM-64 versus x64.

Het gevolg is dat de marshalling layer die nodig is om syscalls te doen vanuit ARM-64 naar x64 simpeler kan zijn dan de marshalling code van x86 naar x64, en sowieso is de infrastructuur voor die marshalling layer al aanwezig.

[StefanTs]

Dat kan ook gewoon, Android x86 is gewoon beschikbaar.

[7o9]

Het zal naast elkaar zijn. ARM en x86 zijn compleet verschillende architecturen.

[wizekid]

Niet naast elkaar, eerst appart pin-incompatible; dan pin compatable interchangable ARM en x86 cores op hetzelfde platform. I.E. één moederbord chipset voor verschillende architecturen.

Dit artikel insinueerd iets anders (verkeerd), lees anders het originele bericht.

[Stoney3K]

Niet naast elkaar, eerst appart pin-incompatible; dan pin compatable interchangable ARM en x86 cores op hetzelfde platform. I.E. één moederbord chipset voor verschillende architecturen.

Dit artikel insinueerd iets anders (verkeerd), lees anders het originele bericht.

Naast elkaar kan natuurlijk prima (zelfs onder hetzelfde OS). Als allebei de CPU's toegang hebben tot dezelfde resources, zoals geheugen en randapparatuur, dan kun je ze prima aparte taken uit laten voeren. Een x86-proces en een ARM-proces zitten elkaar niet in de weg. Hetzelfde trucje halen we al jaren lang uit met de GPU die in je moederbord zit geprikt.

Dat is nog wel een gat in de markt voor Microsoft, zodat legacy Windows-applicaties nog altijd te draaien zijn.

[Verwijderd]

Een GPU is niet helemaal hetzelfde trucje, omdat een GPU gewoon z'n eigen geheugen toegewezen krijgt, en verder niet met de rest van het systeem communiceert.

Ik zou zelf zeggen dat het meer lijkt op een normaal multi-CPU systeem. Of enigszins op een systeem als de Amiga, waar de chipset een aantal co-processors heeft die ook bewerkingen op het systeemgeheugen kunnen doen, of de hardware aansturen.

Met een ARM en een x86 naast elkaar zou dat ook moeten kunnen (de Itanium had trouwens ook x86-logica aan boord om x86-processen te draaien). Er zullen wel wat beperkingen aan zitten (je kunt natuurlijk niet at random kiezen welke CPU de hardware aanstuurt. Er zal 1 CPU zijn die als 'host' dient, en dingen als hardware-interrupts fysiek binnenkrijgt en afhandelt. Maar er kan natuurlijk wel een hoop gevirtualiseerd worden binnen het systeem).

[mad_max234]

Een GPU is niet helemaal hetzelfde trucje, omdat een GPU gewoon z'n eigen geheugen toegewezen krijgt, en verder niet met de rest van het systeem communiceert.

Dat hoeft helemaal niet, GPU en CPU kunnen prima geheugen delen, zelfs samen aan hetzelfde stukje geheugen werken, met unified memory access bijvoorbeeld.

nieuws: AMD kondigt unified memory access voor apu's aan
nieuws: AMD kondigt Heterogeneous Queuing aan

[Reactie gewijzigd door mad_max234 op 23 juli 2024 00:49]

[Verwijderd]

Dat hoeft helemaal niet, GPU en CPU kunnen prima geheugen delen, zelfs samen aan hetzelfde stukje geheugen werken, met unified memory access bijvoorbeeld.

Dat kan (en is nogal logisch, want ergens moet er ooit data van het systeemgeheugen naar het videogeheugen, of soms andersom, anders krijg je nooit textures, shaders etc ingeladen), maar dat bedoel ik niet.
Ook een geintegreerde GPU heeft gewoon een stukje gereserveerd 'videogeheugen', ook al is het in dit geval geheugen op het moederbord.
Bij een discrete videokaart wordt (een deel van) het videogeheugen gemapt naar de adresruimte van de CPU, en kun je het op die manier aanspreken alsof het systeemgeheugen is.

Maar dat is niet waar ik het over heb. Wat ik bedoel is dat je met de CPU gewoon compleet random access hebt tot al het geheugen (waaronder dus ook memory-mapped devices), en ook de IO-space.
Een conventionele GPU kan daar niks mee, en volgens mij gaat dat hUMA ook niet verder dan buffers delen tussen CPU en GPU (zoals ik hierboven uitlegde), maar dan iets efficienter, omdat de driver 'weet' dat het systeemgeheugen is.
Ik zie het nog niet echt gebeuren dat je met hUMA ook geheugen kunt aanspreken in kernel-mode (buiten de display driver zelf dus), met de GPU.

[Squee]

Dat kan (en is nogal logisch, want ergens moet er ooit data van het systeemgeheugen naar het videogeheugen, of soms andersom, anders krijg je nooit textures, shaders etc ingeladen), maar dat bedoel ik niet.
Ook een geintegreerde GPU heeft gewoon een stukje gereserveerd 'videogeheugen', ook al is het in dit geval geheugen op het moederbord.
Bij een discrete videokaart wordt (een deel van) het videogeheugen gemapt naar de adresruimte van de CPU, en kun je het op die manier aanspreken alsof het systeemgeheugen is.

Dit was tot niet zo heel erg lang geleden nog waar, maar dat is toch echt niet meer zo bij de huidige GPU generaties. De werkelijkheid is eigenlijk dat de grens steeds meer aan het vervagen is. Zo was er al sinds de AGP generatie videokaarten de GART waarmee de videokaart een bepaald configureerbaar gedeelte van het systeemgeheugen kan aanspreken. Maar recentere generaties GPUs van Nvidia (Kepler o.a.) en AMD (met hUMA) hebben hun eigen interne MMU en kunnen via die manier verschillende contexten hebben (gedeeld worden door gebruikers). En nu heeft AMD in zijn laatste hUMA architecturen zelfs cache coherency tussen de CPU en het geheugen wat de GPU ziet, wat het delen van informatie tussen de CPU en GPU nog efficienter maakt omdat je niet eerst de date uit je cache hoeft te flushen (of met een non-cacheable memory mapping hoeft te schrijven wat in het algemeen ook vrij traag is).

Maar die ontwikkeling van MMUs in GPUs brengt bij je laatste opmerking;

Ik zie het nog niet echt gebeuren dat je met hUMA ook geheugen kunt aanspreken in kernel-mode (buiten de display driver zelf dus), met de GPU.

Als je het over geheugen address spaces hebt, dan kan je niet echt spreken over kernel-mode. Kernel-mode is een bepaalde staat van executie binnen een processor waarin je allerlei speciale configuratie registers en andere dingen kunt beinvloeden om het systeem te besturen, zoals het uitvoeren van bepaalde privileged instructies. Dit bijvoorbeeld om veranderingen te maken in de page table, waardoor je nieuwe address spaces kan definieren. Wanneer je ook een virtual to physical address mapping kan maken op een device zoals een GPU, dan zal de driver en/of het Operating Systeem moeten zorgen dat dit overeen komt met de page tables die je op zet in de MMU van je CPU (of misschien kunnen dezelfde page tables wel gedeeld worden - zo ver heb ik me er niet in verdiept, maar je zal je mappings toch coherent willen houden). Mocht de MMU van de GPU zelf een eigen mapping (page table) bijhouden, dan kan je dat opzetten zoals je wil, als je een deel van de fysieke adressen wilt mappen die aan de kernel toebehoren. De controle hier over zal wel liggen bij de driver die nog altijd op de CPU draait die de bepaalde configuratie registers in de GPU zal opzetten voor deze mappings. Daardoor ligt de eindverandwoordelijkheid voor dergelijke mappings alsnog bij code die waarschijnlijk in kernel-mode op de CPU draait - en je gaat er van uit dat die het op een veilige manier opzet.

[Verwijderd]

Als je het over geheugen address spaces hebt, dan kan je niet echt spreken over kernel-mode.

Waarom niet?
Er is privileged geheugen dat alleen vanuit kernel-mode toegankelijk is.
Mijn punt is: daar kun je alleen bij als je GPU-code vanuit kernel-mode kunt draaien, en dan ook nog eens als je gewoon random access hebt tot dat geheugen.
Op dit moment is het nog zo dat er eerst een buffer gealloceerd moet worden op de GPU door de driver, en dan kan de GPU daarbinnen dingen adresseren. Daar kom je dus niet heel ver mee in bovenstaande situatie.

Het zou in theorie kunnen, in een mogelijke toekomst, maar volgens mij is de GPU-technologie nog niet zo ver. Daarnaast is volgens mij het doel van hUMA iets anders, zoals ik al zei.

De rest van je verhaal is nogal overbodig, je denkt dat ik dat niet weet, maar ik weet dat wel, en de kern van m'n verhaal ontgaat je.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 00:49]

[Squee]

Waarom niet?
Er is privileged geheugen dat alleen vanuit kernel-mode toegankelijk is.
Mijn punt is: daar kun je alleen bij als je GPU-code vanuit kernel-mode kunt draaien, en dan ook nog eens als je gewoon random access hebt tot dat geheugen.

Misschien had je dan toch nog even mijn 'overbodige' verhaal goed moeten lezen, vooral het tweede deel. Zoals ik al aangaf; kernel-mode is niets anders dan een staat van executie binnen een core (en zijn MMU). Alles daar buiten heeft totaal geen notie van kernel mode of niet, of uberhaupt uit wat voor context een bepaalde operatie komt, en ziet alleen maar fysieke geheugen adressen langs komen (de caches** en de memory controller bijv) **: m.u.v. de L1 cache in bepaalde designs. Er bestaat dus niet zoiets als 'priviliged geheugen' gezien van iets buiten de core/MMU. Wat wel bestaat is een address mapping in de MMU die de kernel in het algemeen gebruikt voor zijn geheugen, maar met speciale priviliged instructies en/of configuratie registers kan aanpassen (zoals de scheduler doet wanneer hij tussen processen wisselt en dus de actieve mapping moet veranderen).

Maar goed, wat mijn punt dus is, is dat er voor moderne GPUs een eigen mapping gemaakt kan worden door de driver, wat eigenlijk ook al sinds AGP kon zoals ik al uitlegde. Daardoor is er dus niets wat je er van weerhoudt om een stuk van het kernel geheugen daar naar toe te mappen. De GPU heeft totaal geen notie van wat 'kernel-mode' is of niet, omdat dit alleen iets is wat binnen de core/MMU bestaat. Of misschien is het gewoon dat we qua terminologie niet helemaal op een lijn zitten.

[Verwijderd]

Er bestaat dus niet zoiets als 'priviliged geheugen' gezien van iets buiten de core/MMU.

Dat heb ik ook helemaal niet beweerd. Je begrijpt m'n verhaal gewoon niet, en begint maar allerlei dingen te verzinnen die er niks mee te maken hebben. Daarom is het verhaal dus totaal overbodig.

Maar goed, wat mijn punt dus is, is dat er voor moderne GPUs een eigen mapping gemaakt kan worden door de driver, wat eigenlijk ook al sinds AGP kon zoals ik al uitlegde.

Dat *kan*, maar zoals ik zelf dus al zeg, op dit moment werkt dat allemaal via buffers die van te voren door de driver gealloceerd worden (shadercode, ook compute shaders, kunnen alleen relatief binnen zo'n buffer adresseren, absolute of fysieke adressen heb je gewoon niet in dit programmeermodel).
Je kunt dus niet 'zomaar' een fysiek (danwel logisch) adres aanspreken met de GPU. Je hebt geen random access tot het hele geheugen, zoals met een CPU. En *daarom* kun je dus ook niet zomaar even de GPU inschakelen om hardware aan te spreken (wat dus vanuit kernel-mode moet, omdat je in userspace sowieso niet bij memory-mapped IO ranges kunt. Of laat ik het zo formuleren: je kunt de GPU pas toelaten om code in kernel-space te draaien als de GPU zich aan dezelfde regels houdt van memory protection als de CPU. Want misschien is het in theorie nu al mogelijk om gewoon het hele geheugen als een 'shared object' te mappen naar de GPU, maar dat moet je niet willen natuurlijk als de GPU hier geen vorm van beveiliging op heeft, en gewoon alles kan lezen en schrijven).

[Reactie gewijzigd door Verwijderd op 23 juli 2024 00:49]

[Jaerie]

Ik verwacht eerder een toepassing als dual-boot, waarbij van cores gewisseld wordt als er van OS gewisseld wordt.

[Splorky]

Zou leuk zijn een instant on Windows op ARM die in de metro mode start en zodra Windows op de achtergrond gestart is kan overschakelen naar de desktop CPU in de volwaardige Windows (of Android als dual bood)

Ben al erg te spreken over de boot tijd van Windows.
Maar volgens mij had ik gelezen dat de ARM CPU meer als een soort fuctieset diende ter ondersteuning van de CPU(APU) voor bijvoorbeeld encryptie

[Stoney3K]

Zou leuk zijn een instant on Windows op ARM die in de metro mode start en zodra Windows op de achtergrond gestart is kan overschakelen naar de desktop CPU in de volwaardige Windows (of Android als dual bood)

Dat is niet eens nodig. Als er een x86-programma op een ARM-Windows wordt uitgevoerd, dan wordt de x86-processor pas in actie gezet die alleen de instructies van dat proces uitvoert, terwijl de rest gewoon op ARM draait. Of andersom natuurlijk.

[Finraziel]

Misschien moet je het artikel helemaal lezen voor je anderen afkraakt... hier is een tip: doe eens ctrl-f consumentenproducten

[SSH]

"Dit is" betekend nu, niet de toekomst. Dedicated chips zijn al tientallen jaren de strategie, dat is geen nieuws.

[Blokker_1999]

Je bent tweaker of je bent het niet. Ik zou de mensen die thuis server CPUs of server OSen gebruiken geen eten willen geven. Heb ook nog mensen gekend die Win Server 2003 gebruikten thuis als OS evenals mensen met Opterons in hun thuis PC.

Indien dit platform betaalbaar word en energiezuinig blijkt te zijn, zie ik mezelf ook nog wel zo een bordje aankopen.

[goarilla]

Voor welke specialistische taak heb je een ARM server nodig.
Ze gaan het success van dit toch niet laten afhangen van het mogelijke ontstaan van ARM-only killer server applicaties.

[SSH]

Daarom willen ze in consumentenproducten. Vermoedelijk voor in TV's en NASsen.

En waarvoor heb je een ARM chip nodig? Voor alles dat teveel stroom kost? Als je zoals Google veel servers hebt, dan valt er flink te besparen op de energie rekening. Sun servers waren efficient in het serveren van websites, zal me niks verbazen als ARM dit gaat overnemen.

[martijnvanegdom]

@Jaerie,

Het gaat om een serverplatform. Server wil je (over het algemeen) niet opnieuw laten opstarten om ze een andere taak te laten vervullen.. Servers staan 9 van de 10 keer altijd en reboot je eigenlijk alleen vanwege software updates of hardware aanpassingen..

[Jaerie]

De 64bit-ARM chips zijn inderdaad voor servers, de x86-ARM (dus niet 'gewoon' 32bits ARM), is ook voor consumentendoeleinden.

[mcDavid]

Wordt het niet eens tijd dat AMD, koning van de APU's, een SOC voor mobiele devices gaat ontwikkelen nu ze ook de ARM-structuur aan hun portfolio toegevoegd hebben?

[Cergorach]

Ik denk dat ze daar een beetje te laat mee zijn, die markt is langzaam aan het inklappen, er zijn wel nieuwe markten, maar daar gaan voornamelijk super budget modellen verkocht worden. AMD moet dan heel wat investeren met het risico dat ze daar nooit voet aan wal zetten.

[SPee]

Inderdaad, teveel spelers en te lage prijzen.
AMD moet gewoon verder gaan met waar ze nu mee bezig zijn: server processoren.
Daar is veel meer marge op te krijgen en wordt nog niet door de huidige ARM spelers overspoelt.

[Verwijderd]

AMD is jaren geleden al van die pure server richting afgestapt. Het zou dus niet zo zijn dat ze daarmee doorgaan maar naar terugkeren. Dat zou imho het domste zijn wat ze kunnen doen en meteen het begin van het einde van AMD. Gaat dus niet gebeuren.....

AMD richt zich al geruime tijd op APU's van ULV mobile tot mainstream desktop en discrete grafische oplossingen. Daarbij ligt het zwaartepunt inmiddels steeds meer op dit soort embedded oplossingen welke simpelweg meer toekomst hebben.

Via Seamicro zal AMD (micro) server oplossingen blijven aanbieden van alle fabrikanten.
Dat wil letterlijk zeggen dat AMD dus allang Intel en ARM server cpu's verkoopt in hun eigen (AMD) Seamicro servers.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 00:49]

[Bohemian]

AMD is jaren geleden al van die pure server richting afgestapt.

In 2009 had AMD nog zo'n 10% van de servermarkt en dat is teruggelopen naar 3% (Intel heeft de rest). Maar dat komt niet doordat ze "van die pure server richting afgestapt" zijn, Intels producten werden simpelweg meer gekocht. Bovendien hebben ze nooit een "pure server richting" gevaren.

AMD denkt dat in 2019 dense servers of microservers 25% van de servermarkt uitmaakt en dat de ARM architectuur hier een heel grote rol gaat spelen. AMD wil marktleider worden in de ARM dense servers.

Dat wil letterlijk zeggen dat AMD dus allang Intel en ARM server cpu's verkoopt in hun eigen (AMD) Seamicro servers.

AMD biedt helemaal geen ARM in SeaMicro aan, laat staan dat ze dit "allang" doen. De AMD Opteron A1100 "Seattle" komt pas in de tweede helft of het einde van 2014, maar of die in een SeaMicro komt zou ik zo niet weten.

AMD richt zal al geruime tijd op APU's van ULV mobile tot mainstream desktop en discrete grafische oplossingen. Daarbij ligt het zwaartepunt inmiddels steeds meer op dit soort embedded oplossingen welke simpelweg meer toekomst hebben.

Toen Rory Read in 2011 aantrad als CEO haalde AMD zo'n 90-95% van zijn omzet uit PC gerelateerde producten. Zijn strategie is om aan het einde van 2015 50% van de omzet te halen uit zogenaamde "high growth" segmenten, zoals o.a. inderdaad embedded chips en dense servers. Ze hadden zich ten doel gesteld 20% van de omzet hieruit te halen aan het einde van 2013 en dat is ze gelukt, mede dankzij de semi-custom console chips. Dus tot nu toe loopt alles volgens plan.

Verder willen ze zich ook gaan differentiëren door semi-custom oplossingen aan te bieden, zoals ze dit dus reeds hebben gedaan met de console chips voor Sony's PS4 en Microsofts XBox One. Hierbij kan de klant bijvoorbeeld hun eigen IP laten integreren in de chips en kunnen de chips worden geoptimaliseerd voor specifieke toepassingen.

[Reactie gewijzigd door Bohemian op 23 juli 2024 00:49]

[Verwijderd]

AMD had ooit 25 procent van de zware servermarkt in handen.
AMD (R.R.) maakte echter de keuze om daar minder in te investeren.
Dat is dus een AMD keuze, los van de server verkopen van Intel of AMD.
De AMD server strategie ligt al jaren bij ULV (SeaM.) freedom fabric servers.
(veel kleine zuinige en voordelige serverchips ipv een paar grote/dure.)

AMD haalt (Q1-14) meer omzet uit (ATI) videokaarten dan alle CPU's / APU's.
Volgens jouw percentages zou daarmee de nieuwe strategie mislukt zijn, wat eenvoudigweg niet klopt........

Embedded, custom en winstgevendheid liggen perfect op schema wat tijdens een stevige crisis een huzaren stukje mag heten.......

Rory Read heeft voorheen bij Lenovo als enige IT fabrikant een forse stijging laten zien in de omzet tijdens deze zelfde crisis. Alles ziet er naar uit dat hij bij AMD hetzelfde geintje nog eens dunnetjes over zal doen.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 00:49]

[Dreamvoid]

Embedded, custom en winstgevendheid liggen perfect op schema wat tijdens een stevige crisis een huzaren stukje mag heten

Makkelijk is het niet, maar om het uitzonderlijk te noemen gaat ook wat ver. Er zijn inderdaad wat chipbedrijven die in meer of mindere mate de handdoek in de ring hebben gegooid qua mobile/server cpu's (ST-Ericsson, TI, Calxeda, VIA, Transmeta), maar Intel, Qualcomm, Samsung, Apple, Mediatek, IBM, Oracle en nVidia draaien een stuk beter.

De truc gaat worden voor AMD of ze een aantal nichemarkten kunnen vinden, te klein voor de grote jongens, maar waar wel een redelijke boterham valt te verdienen. Consoles is daar 1 van, discrete GPU's een andere, en wellicht microservers (nu een minuscule markt maar wellicht interessant in de toekomst).

[Bohemian]

AMD haalt (Q1-14) meer omzet uit (ATI) videokaarten dan alle CPU's / APU's.
Volgens jouw percentages zou daarmee de nieuwe strategie mislukt zijn, wat eenvoudigweg niet klopt........

Dit zijn niet mijn percentages, maar die van Rory Read zelf. Uit de 'CEO Prepared Remarks' (bij Q413 Financial Results) http://cdn.pressebox.de/a...ults+Prepared+Remarks.pdf:
"We exceeded the goal we set for semi-custom and embedded to generate 20 percent of our revenue by the fourth quarter of 2013. We believe this validates the strategy we outlined two years ago to embrace the trends re-shaping the industry.
We remain on track for our growth businesses to generate approximately 50 percent of our revenue by the end of 2015."

Het gaat dus om "growth businesses" vs "graphics and traditional PC".
"Graphics and traditional PC" was dus verantwoordelijk voor 90-95% van de omzet toen Rory Read aantrad. Hij wou 20% uit de growth businesses halen aan het einde van 2013 en wil aan het einde van 2015 hieruit 50% halen.
"growth businesses" omvat semi-custom, embedded, ultra-lower power client, dense servers en professional graphics.
Voor de professional graphics hebben ze nog een goede deal binnen gehaald met de Apple Mac Pro.
De nieuwe ARM-licentie die AMD heeft (wat dus maandag bekend werd gemaakt) is dus met name voor de ultra-lower power clients, één van de high growth businesses waar AMD op inzet. Het nieuws uit het artikel is dus in wezen ook nieuws met betrekking tot AMD's strategie voor hun 'turn-around'.
Wat trouwens ook nog aardig is om op te merken is dat deze growth businesses best kunnen overlappen. Ze willen bijvoorbeeld semi-custom dense servers maken als een klant daar interesse voor heeft.

[Reactie gewijzigd door Bohemian op 23 juli 2024 00:49]

[Bohemian]

Rory Read heeft voorheen bij Lenovo als enige IT fabrikant een forse stijging laten zien in de omzet tijdens deze zelfde crisis. Alles ziet er naar uit dat hij bij AMD hetzelfde geintje nog eens dunnetjes over zal doen.

Ja dat klopt, Rory Read is erg erg goed. Ik ben ervan overtuigd dat zijn aanstelling echt een ommekeer voor AMD is. Ze hebben nu echt goed management en goed talent in huis. Het duurt in de chip business alleen even voordat alle effecten hiervan in de vorm van producten etc. goed te zien zijn...

[Verwijderd]

Ja, ik denk ook dat je nu te laat bent als ARM-speler. Ik denk dat het grootste gevaar van Intel komt op dit moment. Hun Atom SoCs worden gevaarlijke tegenstanders van ARM, nu al op 22 nm, en straks op 14 nm.
Ik denk dat de bestaande ARM-spelers het moeilijk genoeg gaan krijgen om overeind te blijven, en dat nieuwkomers niet veel kans maken om marktaandeel te winnen (of je moet met iets HEEL goeds komen, maar de ARMs van AMD zijn vooralsnog niet echt spectaculair).

[Dreamvoid]

Als AMD de mainstream ARM markt op gaat komen ze daar een net zo machtige en dominante speler als Intel tegen: Qualcomm. Wat ze nu doen is kleine niche markten vinden die voor de grote jongens niet lucratief genoeg zijn.

[Squee]

Ik denk dat jullie je daar misschien wel eens een klein beetje in zouden kunnen vergissen. Wat je niet moet vergeten is dat AMD in tegenstelling tot Qualcomm wel al veel ervaring heeft met het maken van serverprocessoren (denk maar eens terug aan hoe vooruitstrevend de Opteron was met zijn Hypertransport links en geintegreerde memory controllers een jaar of tien geleden) . Het design van een core is maar een klein aspect van het ontwerpen van een serverchip. De hele SoC er omheen van caches, interconnects, coherence, memory controllers, I/O interfaces en dergelijke daar zal AMD flink wat IP van op de plank hebben liggen en veel meer ervaring mee hebben! En dat is ook eigenlijk wat ik hier boven zag in de plaatjes van de slides over Skybridge; een enkel en uniform SoC ontwerp wat ze kunnen hergebruiken voor beide ARM of x86 core gebaseerde systemen. Slimme zet van ze, zou ik zeggen.

[Reactie gewijzigd door Squee op 23 juli 2024 00:49]

[Dreamvoid]

De microserver markt is inderdaad precies zo'n niche markt. Op het moment is die nog heel klein (de enige pure-play speler daar, Calxeda, is inmiddels failliet), maar er liggen wel mogelijkheden. En het is maar de vraag of Intel met hun Avoton chips werkelijk serieus de concurrentie willen aangaan met hun eigen (veel lucratievere) midrange Xeon serverchips. Ook Qualcomm zal zich afvragen of er daar wel de hoge volumes en/of marges te halen zijn die ze nu in mobile pakken.

[Reactie gewijzigd door Dreamvoid op 23 juli 2024 00:49]

[Verwijderd]

Wordt het niet eens tijd dat AMD, koning van de APU's, een SOC voor mobiele devices gaat ontwikkelen nu ze ook de ARM-structuur aan hun portfolio toegevoegd hebben?

Dat komt er ongetwijfeld aan aangezien de prio tegenwoordig meer naar mobiele apparaten aan het verschuiven is. Zie Intel, Nvidia en nu ook AMD die ook voor serveroplossingen bezig is. De low power soc's zijn er volgens mij al van AMD.

[arens77]

Ik ben het helemaal met je eens! Dat zou heel goed zijn voor amd zodat ze een stabieler inkomen kunnen creeren, maar dan moeten ze wel nog langs qualcomm moeten wringen.

[Dreamvoid]

AMD heeft al een paar jaar mobile SoC's voor tablets in het gamma, helaas sloegen de afgelopen drie generaties niet aan. Mullins moet voor de ommekeer gaan zorgen deze zomer.

[Reactie gewijzigd door Dreamvoid op 23 juli 2024 00:49]

[GewoonWatSpulle]

De eerste demonstratie van het Seattle-platform bestond uit een LAMP-webserver, waarmee een Wordpress-blog en videostream werden geserveerd. Het demoplatform bestond uit een 64bit-Opteron A1100-serie processor met maximaal 128GB registered ddr3-geheugen.

Was dat echt nodig voor WordPress, ik bedoel zoveel heeft een videostream niet nodig lijkt me.

Verder kondigde AMD voor 2015 Project SkyBridge aan.

Dit moet haast wel een pun zijn richting Intel's Skylake.

[Reactie gewijzigd door GewoonWatSpulle op 23 juli 2024 00:49]

[ongewoongewoon]

Zo'n combinatie lijkt mij voor desktops en tablets ook prettig ! Zeker voor windows 8 , dan heeft een RT app voor windows 8 ineens veel meer draagvlak