Online-Abo
  • Login
  • Registrieren
Games World
      • Von Skysnake Lötkolbengott/-göttin
        Die cores von Apple sind auf jeden Fall custom Lösungen, und dieServer Chips vonSamsung auch
      • Von ruyven_macaran Trockeneisprofi (m/w)
        Jup, es gäbe da komplexere Formen - aber hier finden sie keine Anwendung. Apple, Samsung und Co verbauen durch die Bank A5/A7/A15 Kerne. Hätten sie nur den Befehlssatz lizensiert, wäre das in allen drei Fällen ARM-7v-A und die eigentlichen Kerne müssten Hersteller=Entwicklerspezifische Namen tragen. Tun sie aber nicht, sondern sie tragen die von ARM für von ARM entwickelten Implementationen vorgegebenen Namen.
        Möglich, dass die großen Hersteller noch das Layout modifizieren (auch wenn ich nicht glaube, dass sich das lohnt - ARM liefert ja sehr gründliche Arbeit ab), aber den Schaltplan dürften sie wohl 1:1 übernehmen. Eine Eigenwicklung auf Basis einer ARM-Befehlssatzlizenz waren afaik Intels Xscale.
      • Von Skysnake Lötkolbengott/-göttin
        Einigen wir uns einfach darauf, das wir unterschiedliche Ansichten dazu haben, wie sich das entwickelt. Die Diskussion ist etwas Brotlos, und ich denke auch, das wir da nicht wirklich weiter kommen werden. Wir können aber gern die Diskussion in 1-2 Jahren nochmals führen

        Einen Punkt möchte ich aber noch ansprechen:
        Zitat

        ? Erzähl mir nicht, dass dir der Unterschied zwischen der Lizenz für eine fertige ARM-Architektur und für eine x86-Befehlssatz nicht klar wäre
        Die mögen ihr eigenes Chipdesign machen und den non-Core-Bereich entwickeln, aber die eigentliche Verschaltung und Konzipierung der Kerne (und in den meisten Fällen sicherlich auch deren Layout) kommt von ARM.
        Apple, Qualcomm sowie meines Wissens nach Samsung haben auch die reinen Befehlssätze lizensiert, und implementieren auch ihre eigenen Designs.

        Bei ARM ist es halt ziemlich schwierig, weil ARM eben sowohl reine ISA-Lizensen, als auch fertige Designs anbietet. Meist haben Kunden beides, und arbeiten dann auf Grundlage der fertigen Designs ihre eigenen Anpassungen aus.
      • Von ruyven_macaran Trockeneisprofi (m/w)
        Zitat von Skysnake
        Nein, das ist keine Katastrophe für die. Du musst da etwas weiter denken. Gerade bzgl Cloud-Diensten ist das ziemlich cool. Wenn du @home bist, läuft das Programm auf deinem X-beliebigen Rechner. Wenn du unterwegs bist, läuft es auf dem Server und wird auf dein Smartphone, Tablet oder Notebook gestreamt, was wiederum eine x-beliebige Architektur haben kann.


        Server, Smartphone, Tablet - eine nette Liste, die all diejenigen Märkten enthält, bei denen AMD nichts zu melden kann und zu denen man tunlichst keine Verlagerung anstreben sollte.

        Zitat
        Normal müsstest du also x*X verschiedene Varianten implementieren und debuggen. Wenn das wegfällt, dann ist das schon SEHR göttlich für den Entwickler. Du bekommst einfach eine sehr sehr sehr hohe Marktdurchdringung dann auf dem Silbertablett.

        Klar, man muss dann den Server und Client implementieren, aber eben nur einmalig.


        Das ist für jede Client-Architektur einmalig, egal ob du deine Cloud mit HSA oder ohne betreibst. Von einer virtualisierten Architektur, die den gleichen Code einheitlich auf x86, ARM und GCN ausführen könnte, habe ich jedenfalls noch nichts gehört. (Geschweige denn von einer Idee, wieso ein derartiger Ansatz diesmal klappen sollte )

        Zitat
        AMD kann dann im Mobilebereich einfach sagen: Ja wir sind x86, ja ihr könnt all eure Desktop Software bei uns ausführen, weil wir genug Punsh haben, aber ihr könnt auch ALLE! eure Software aus dem Play-Store nutzen.


        Das wird AMD aber wenig nutzen, denn niemand will Office 2013 auf seinem Smartphone ausführen und erst recht wird er dafür nicht in kauf nehmen, dass dieses Smartphone eine 50% geringere Akkulaufzeit hat. Hardware verkaufst du entweder, in dem du dazu Software hast, die der Nutzer woanders nicht (vernünftig) nutzen kannst (z.B. neue Rendertools -> schnellere Hardware, Mario -> SNES) oder in dem bestehende Software auf der neuen Hardware deutlich besser läuft (z.B. Firefox -> Ultrabook).
        Aber nicht wenn sie schlechter läuft. Niemand wird einen AMD-mobile-Chip für x86 und ARM kaufen, der nicht bereits ein funktionsfähiges ARM und ein funktionsfähiges x86 Gerät hat. AMDs Kombi Chip müsste besser sein, als diese undzwar in dessen jeweiligen Segment. Denn bis sich derartige Hardware etabliert hat, gibt es keine x86 Anwendungen für ultra mobile Geräte und umgekehrt keine ARM Anwendungen für Desktop-PCs.
        Stellt sich somit die Frage: Kann AMD jetzt (oder später, dann die entsprechenden Nachfolger als Konkurrenz einsetzen) dank HSA einen Prozessor bauen, der Haswell im Desktop schlägt UND *Was immer Samsung und Apple gerade verbauen* in Smartphones hinter sich lässt? Ich denke nicht. Die wären froh, wenn sie auch nur eins von beiden Zielen zu 2/3teln schaffen würden.

        Zitat
        Gerade bei Konvertebles und Tablets ist das halt schon ein killer Feature.


        Yup. Windows8/RT feiert mit dieser Verschmelzung des besten aus zwei Welten auch gerade riesige Erfolge. Apple hat schon Insolvenz angemeldet

        Zitat
        Du musst ja auch bedenken, dass alle drei nicht einfach nur fertige ARM-Cores lizensieren, sondern ihre eigenen Chips bauen. Nichts anderes macht AMD. Sie haben eine x86 Lizenz und machen ihre eigene Implementierung.


        ? Erzähl mir nicht, dass dir der Unterschied zwischen der Lizenz für eine fertige ARM-Architektur und für eine x86-Befehlssatz nicht klar wäre
        Die mögen ihr eigenes Chipdesign machen und den non-Core-Bereich entwickeln, aber die eigentliche Verschaltung und Konzipierung der Kerne (und in den meisten Fällen sicherlich auch deren Layout) kommt von ARM.

        Zitat
        Die leben aktuell echt nur von ihrem Desktop-Namen und den wohl sehr niedrigen Preisen.


        Z.B. der PC hat jahrzehntelang von letzterem gelebt.

        Zitat
        Sie verstehen durchaus Chips (ARM) zu designen, und haben auch kein ideologisches Problen ARM auch ein zu setzen im Gegensatz zu Intel. Die ketten sich selbst an x86.


        Ich wiederhole: Welche konkurrenzstarken ARM-Chips hat AMD denn bislang so entwickelt? Iirc hatten die einmal kurzzeitig ein paar Designs eingekauft, aber selbst haben sie nie etwas gemacht.
        Das heißt nicht, dass sie es gar nicht könnten, aber es geht hier darum, wie AMD wieder nach vorne kommen könnte. Und dazu müssen sie es nicht "okay" machen, sondern "besser als alle Konkurrenten". Vermutlich würde AMD nicht einmal ein ARM-Duell mit Intel gewinnen...

        Zitat
        AMD denkt sich wohl, Sie könnten da besser mithalten, als allein mit x86 gegen Intel UND ARM.


        Derzeit kämpfen sie mit Intel gegen ARM. Und wie bekannt ist, hat Intel durchaus Interesse daran, den x86-Juniorpartner nicht ganz untergehen zu lassen.

        Zitat
        Ich seh da wirklich die Flexibilität von AMDs-Designs als killer Feature an. Bei den Servern können Sie dann mit hoher Performance werben (ok kann Intel auch),


        Intel kann das nicht "auch". Intel kann das. AMD kann es derzeit nicht und hat, soweit bekannt ist, auch keinen einzigen neuen Performance-Chip in der Pipeline.


        Zitat
        aber eben auch damit, das ALLE Software auf ihren Maschinen läuft (das kann dann weder Intel wegen ARM, noch ARM, weil nicht auf High-Performance ausgelegt). Es wäre also etwas die eierlegende Wollmilchsau.


        Die Gold frisst. Was solange keinen Nutzen bringt, wie niemand
        a) Server kauft, um Angry Birds darauf zu spielen
        oder
        b) servertypische Hardware für ARM programmiert. Letzteres wird wiederum nicht geschehen, solange es keine ARM-CPUs gibt, die besser sind, als Intels Serverlösungen. Und hier beißt sich die Katze in den Schwanz: AMD kann nicht mit schwachen Chips den Markt umkrempeln. Und wenn ARM-Spezialisten dies an Stelle von AMD machen, dann kann AMD gegen die genausowenig anstinken, wie jetzt gegen Intel. Niemand kauf ein System, dass in zwei Sachen schlecht ist - erst recht nicht für den Servereinsatz, wo man die Hardware an einen beschränkten Aufgabenbereich anpassen kann.

        Zitat
        AMD hält sich im großen und ganzen an ihren Fahrplan, den Sie für HSA ausgegeben haben


        Ich kenne die aktuellen Fahrpläne nicht, aber war die komplette Softwareumgebung nichtmal für 2011/2012 versprochen? Ganz davon abgesehen, dass Chips mit den Funktionen, die für HSA-Hardware versprochen werden, ursprünglich mal für spätestens 2010 erwartet wurden?

        Zitat
        Jetzt muss AMD nur noch liefern.


        Und genau an diesem "nur" scheitert AMD seit über einem halben Jahrzehnt in einem Segment nach dem anderen:

        Zitat
        Das brauchen Sie ...
        ...muss kommen.
        ... Bauchschmerzen....
        AMD braucht ...
        ... einfach machtlos.
        Aktuell kan AMD eigentlich nicht wirklich viel mehr machen...
        ...Es fehlen aktuell einige Launches.


        Und genau so klingt das seit Jahren.


        Zitat
        Es kommt dieses Jahr einiges bzgl HSA, APU Opterons usw usw.


        APU Opterons? AMD wird Richland-Desktop CPUs rebranden. Selbst wenn HSA schon etabliert wäre, hätte man damit keine Chance gegen Haswell. Kaveri & Ableger kommen eher 2014 in Stückzahlen - und sind afaik immer noch auf dem "normale CPU mit normaler GPU und vereintem Speicher"-Techlevel.
        Davon abgesehen nützten einem in den kommenden Jahren auch gute Serverprozessoren wenig, das Geld liegt im Endkundengeschäft.

        Zitat
        Spannend wird halt vor allem, ob man jetzt SMP Systeme mit APUs bauen kann, oder nicht, und was jetzt mit HT für die reinen CPUs wird. Hier muss man wirklich mal endlich den nächsten Schritt tun.


        Es gibt keinerlei Hinweise auf eine (Weiter)Entwicklung von Multi-CPU-Plattformen und AMD hat auch nicht die nötigen Ressourcen für so viele paralelle Entwicklungsstränge.

        Zitat
        nVidia hatte hier wohl die kritische Masse bereits überwunden. Zudem können Sie mit Features wie GPUDirect SEHR überzeugen. Auch DynamicParalelism ist sehr beliebt. Man hört aber weiterhin überwiegend, dass die Leute eigentlich nicht wirklich weiter auf CUDA setzen wollen, einfach weil Sie selbst erkannt haben, dass die Bindung an CUDA eben problematisch ist. Sie haben nur oft keine andere Wahl. Die neuen Features sind überzeugend, die Software ist schon teilweise auf CUDA da, nVidia gibt inzwischen 0 OpenCL Support (Kepler GPUs sind nicht für OpenCL von der KhronosGroup zertifiziert.... nVidia hat gar keine OpenCL 1.2 GPUs im Angebot usw)

        Dazu kommt halt, das nVidia in de Markt >50% besitzt, wohl eher sogar in GPGPU Bereich >75%.


        Tjo. Und genau das meine ich: Im Hardwaremarkt ist eben nicht das Bessere Feind des Guten - sondern der Verlierer gegenüber dem Etablierten. Über x86 meckern Entwickler sogar schon seit min. 2,5 Jahrzehnten. Geschadet hat das Intel wenig.

        Zitat
        <<10% Marktdurchdringung, und man hat das total veraltete Featureset im Vergleich zur Konkurrenz.


        Weiter oben hast du aber selbst betont, wie wichtig Kompatibilität ist. Und die hat man zum bereits etablierten Marktsegment. Ab der kommenden Generation sogar 100% - inkl. vollem Featureset. Dagegen muss HSA anstinken.

        Zitat
        Musst du auch nicht. Es reicht, wenn man Mobile-Anwendungen betreiben kann.


        Guck dir die Rechenleistung moderner Smartphones an und du wirst sehen, dass ich von genau dieser Leistungsklasse rede.
        Was AMD für künftige CPUs angekündigt hat, würde vermutlich schon mit dem Betriebssystemfunktionen mancher Systeme ausgelastet werden, von Anwendungen ganz zu schweigen.



        MS unterstützt auch ARM. Wenn die Hardware dafür da ist, wird MS von ganz allein das OS auch für einen mischbetrieb fit machen. Zumal das nicht mal zwingend der Fall sein muss. Es reicht schon, wenn man entsprechend intelligente Compiler hat, die eben für mehrere OS compilieren können. Man braucht halt die richtigen Einstiegspunkte usw.

        Zitat
        Schau doch mal das BigLittle Konzept an. Das könnte man durchaus auch mit x86 mischen. Das Ergebnis wäre ein Rechner den man eigentlich nicht mehr runter fahren müsste, und der extrem sparsam im Idle, dafür aber noch immer sehr stark unter Last wäre.

        Ich seh da jetzt dein Problem nicht


        Mein Problem ist, dass du mir Widersprichst und dann deinen Widerspruch mit meinen Argumenten zu belegen behauptest
        Also nochmal zum mitschreiben: ARM und x86 sind einander zu ähnlich. Wie du selbst schreibst kriegt man das meiste, was ARM kann, auch halbwegs mit x86 hin und umgekehrt könnte man das meiste, was x86 kann, mit ARM machen. Es gibt leichte Effizienzunterschiede, aber die sind nicht so groß, dass es sich lohnen würde, ein komplette zweite (Co-)CPU der anderen Architektur zu integrieren und zumindest die Systemsoftware für beide kompatibel zu gestalten. Mittelfristig wird in jedem Markt somit nur eine von beiden Architekturen überleben und alle Konzepte, die auf ihre Verschmelzung setzen, schleppen einfach nur unnötigen Balast mit sich rum.
        Das kann man sich erlauben, wenn einen gewissen Vorsprung vor der Konkurrenz hat und auf diesem Wege versucht, zusätzliche Märkte zu erschließen oder neue Technologien einzuführen. AMD hat aber keinen Vorsprung. AMD hat einen mächtigen Rückstand. Wenn die noch Balast draufpacken, mögen die CPUs in irgendwelchen Zukunftsszenarien superduper Vorteile haben, aber im jetzt kauft sie niemand, weil sie im jetzt nicht konkurrenzfähig sind. Und so wird das Zukunftsszenario nie eintreten.

        Zitat
        BigLittle funktioniert auch.


        BigLittle hat nur einen Befehlssatz.

        Zitat
        Crosscompiles auf jedwede Architektur funktioniert auch.


        Was crosscompiling mit einem Architekturwechsel im laufenden Betrieb zu tun?

        Zitat
        Genau hier seh ich z.B. auch eine Kernaufgabe für das HSA-Konsortium. Sie müssen entsprechende Schnittstellen für die Compiler/Hardware entwickeln, die genau so etwas reibungslos ermöglichen.


        Eine Schnittstelle für die Compiler hilft dir da nicht weiter (es sei denn, du willst grundsätzlich erst während der Laufzeit kompilieren ) und die Schwierigkeit besteht ja eben darin, dass du zwischen zwei Hardwareteilen mit unterschiedlicher Schnittstelle wechseln willst. Und die kannst du auch nicht vereinheitlichen. Das würde auf eine komplette Plattformvirtualisierung hinauslaufen.

        Zitat
        Für ein x86 Programm x86 Cores. Für ARM Programme ARM Cores. Für low Power/idle usw ARM, für Sequenzielle Parts mit viel Rechenbedarf x86. Für Sequenzielle parts, die nur sehr wenig Leistung brauchen (z.B. iGPU steuern usw usw) ARM, für massiv parallele Aufgaben die iGPU.


        Alle bis auf einen HSA Partner können keine x86 Kerne für x86 Programme verbauen, sondern müssen die gleichen Aufgaben mit ARM-Kernen bewältigen.

        Zitat
        Das HSA Konzept ist absolut begrüßenswert! Wenn die Hardware das alles vom Programmierer weg nimmt, dann ist das göttlich, und selbst wenn es nur der Compiler übernimmt, ist es noch immer sehr sehr gut.


        Und wenn nichts dergleichen geschieht, weil Software, die in den nächsten Jahren HSA-Chips nutzen will, diese über ARM, x86 und OpenCL ansprechen muss, dann nennt man das "Realität".
        Ich erinnere in diesem Zusammenhang übrigens an die letzte CPU-Architektur, die es dem Compiler überlassen wollte, hochoptimierten Code für höhere Recheneffizienz und bis dato ungeahnte Möglichkeiten zu liefern...

        Zitat
        Bisher gibt es aber keine Anzeichen dafür, dass es eben nicht geht. Das Konsortium ist nur etwas ruhig. Jetzt muss sich zeigen, ob das die Stille vor der Veröffentlichung, oder die Stille vor dem großen Knall unter den Partnern ist. We will see.


        Bislang ist es die Stille nach großen Ankündigungen und sonst nichts.
      • Von Skysnake Lötkolbengott/-göttin
        Zitat von ruyven_macaran
        Jup. Z.B. mit Links zu den Office Suiten, Grafiktools und Videoschnittprogrammen, die sie anbieten.
        Mit "Software" meine ich keine Firmware
        OS ist Firmware?
        Compiler sind Firmware?

        Denk auch an die Spracherkennungssoftware, ähnlich Siri, die entwickelt wurde.

        Gerade die Compiler- und OS-Entwickler sind eine sehr sehr sehr sehr sehr wichtige Schlüsselkomponente. Ohne die kannst du das HSA-Konzept nämlich vergessen. Was aber stimmt ist, das aktuell von genau diesen beiden Fraktionen aber noch die Beiträge fehlen. Es ist aber auch nicht verwunderlich, das erst die Hardware dazu da sein muss, bevor die Software dann den Markt erreicht. Daher NOCH kein Grund zu Panik aber durchaus um besorgt zu sein.

        Zitat

        k. Da habe ich mich von der enorm hohen Zahl an Chips mit PowerVR Grafik täuschen lassen.
        Kein Ding, der Markt ist nicht gerade übersichtlich, und relativ dynamisch, ein Grund, warum man da mit propritären "Standards" auch keinen hinter dem Ofen vor holt. Man bindet sich einfach ums verrecken nicht an einen Hersteller im SFF.

        Zitat

        Das für die anderen HSA-Mitglieder toll wäre, für AMD aber eine Katastrophe. Und iirc geht es darum, warum HSA AMDs Rettung ist.
        Nein, das ist keine Katastrophe für die. Du musst da etwas weiter denken. Gerade bzgl Cloud-Diensten ist das ziemlich cool. Wenn du @home bist, läuft das Programm auf deinem X-beliebigen Rechner. Wenn du unterwegs bist, läuft es auf dem Server und wird auf dein Smartphone, Tablet oder Notebook gestreamt, was wiederum eine x-beliebige Architektur haben kann. Normal müsstest du also x*X verschiedene Varianten implementieren und debuggen. Wenn das wegfällt, dann ist das schon SEHR göttlich für den Entwickler. Du bekommst einfach eine sehr sehr sehr hohe Marktdurchdringung dann auf dem Silbertablett.

        Klar, man muss dann den Server und Client implementieren, aber eben nur einmalig.

        Denk auch mal an die ganzen Spielehersteller. Die müssen ohne HSA alles doppelt entwickeln einmal für arm und einmal für x86. Wenn man mit HSA intelligent dran geht, dann macht man das nur noch einmalig und skaliert eben mit Auflösung, AA, Polycount usw. oder Streamt die Inhalte.

        Denk mal nur an so was simples wie AngryBirds. Der Hersteller hätte sich SEHR gefreut, wenn er einfach noch eine Version für x86 dazu bekommen hätte.

        Vorallem für AMDs Mobile-Pläne ist das ziemlich gut.

        Intel steht vor dem Problem x86 vs den Rest der Welt (ARM).

        AMD kann dann im Mobilebereich einfach sagen: Ja wir sind x86, ja ihr könnt all eure Desktop Software bei uns ausführen, weil wir genug Punsh haben, aber ihr könnt auch ALLE! eure Software aus dem Play-Store nutzen.

        Gerade bei Konvertebles und Tablets ist das halt schon ein killer Feature.

        Zitat

        ? Welche bedeutenden Architekturen haben Samsung, Mediatek, Qualcomm, ARM (ausgenommen ARM-Architektur) denn so in den letzten Jahren auf den Markt gebracht?
        Samsung arbeitet an 64Bit ARM, Sie haben mit am Big-Little Konzept gearbeitet usw.

        Du musst ja auch bedenken, dass alle drei nicht einfach nur fertige ARM-Cores lizensieren, sondern ihre eigenen Chips bauen. Nichts anderes macht AMD. Sie haben eine x86 Lizenz und machen ihre eigene Implementierung. Man hört bei AMD halt nur mehr davon, was da tolles eingebaut wird. Bei der ARM Fraktion eher nicht. Da interessiert es einfach keine Sau. Gerade im Bereich der GPUs wurde in den letzten 2-3 Jahren aber gewaltig auf die Tube gedrückt. Wenn man mal bedenkt, dass die iGPUs im Mobilebereich jetzt dann die aller neusten OpenGL Standards unterstützen, und teilweise sogar DoublePercision (WTF ), womit Sie sich auch für OpenCL rausputzen, dann fällt einem schon teils die Kennlade runter.

        nVidia ist da ein ziemlicher Blender in dem Bereich. Bei ner Diskussion mit Ailuros vor einiger Zeit im 3DCenter ist mir die Kinnlade runter gefallen, als ich erfahren habe, WIE WEIT nVidia beim Featureset hinterherhinkt. Die leben aktuell echt nur von ihrem Desktop-Namen und den wohl sehr niedrigen Preisen.

        Zitat

        Gegen Intel sind sie nur im x86 Markt zu klein. Da werden ihnen die anderen nicht helfen können. Wenn die anderen den x86 Markt verkleinern, ist das auch nicht zu AMDs Vorteil.
        Der Feind deines Feindes ist dein Freund....

        AMD fährt da schon eine gefährliche aber vielversprechende Idee, indem Sie das Schanier zwischen x86 und ARM darstellen wollen. Gegen die ARM-Fraktion kann sich AMD durchaus behaupten. Sie verstehen durchaus Chips (ARM) zu designen, und haben auch kein ideologisches Problen ARM auch ein zu setzen im Gegensatz zu Intel. Die ketten sich selbst an x86.

        Natürlich sind Gegner wie Qualcomm und Samsung im ARM-Segment genau so gefährliche Gegner wie Intel im x86, man hat aber durchaus viel Know-How für GPU und High-Performance Designs. AMD denkt sich wohl, Sie könnten da besser mithalten, als allein mit x86 gegen Intel UND ARM.

        Es ist ja nicht so, das ARM nicht in den x86 Markt, vorallem Server, drücken würde, auch wenn es kein HSA geben würde. AMD könnte daran nur nicht partizipieren.

        Ich seh da wirklich die Flexibilität von AMDs-Designs als killer Feature an. Bei den Servern können Sie dann mit hoher Performance werben (ok kann Intel auch), aber eben auch damit, das ALLE Software auf ihren Maschinen läuft (das kann dann weder Intel wegen ARM, noch ARM, weil nicht auf High-Performance ausgelegt). Es wäre also etwas die eierlegende Wollmilchsau.

        Es ist ein Ritt auf der Rasierklinge, aber man hat eigentlich keine andere Wahl, und wirklich schlechter als ohne diesen Ritt kann es eigentlich auch nicht mehr werden, wenn man sich die aktuelle Situation mal anschaut...

        Zitat

        Davon abgesehen ging es nicht um die Marktstärke, sondern um die vorzuweisenden Produkte. AMD arbeitet sehr lange an kombinierten Architekturen und hat bislang so gut wie gar nichts vorzuweisen (vereinheitlichte Speicheransteuerung - das wars im wesentlichen). Und daran werden die Partner erst recht nichts ändern, denn HSA ist kein kooperatives Entwicklungsprogram, sondern nur eine Allianz zur Etablierung gemeinsamer Schnittstellen.
        Ja, und AMD HAT eben schon einiges, und das ist überzeugend. Vor allem auch das was noch kommt weiß zu gefallen. AMD hält sich im großen und ganzen an ihren Fahrplan, den Sie für HSA ausgegeben haben, und da kommen wie z.B. Speicherkohärenz auch mit dGPUs noch einige Knaller, die wirklich nicht trivial sind.

        Man scheint sich da wirklich sehr sicher zu sein, die richtigen Implementierungen gefunden zu haben, und das ist wichtig. Man braucht Ideen, wie man etwas gelöst bekommt. Jetzt muss AMD nur noch liefern. Wichtig wäre z.B. in 1 aller aller aller spätestens 2 Jahren auch einen eDRAM minimum onPackage, besser noch auf einem Interposer.

        Das brauchen Sie einfach um die Performance der iGPU weiter pushen zu können. Ansonsten werden Sie gegen Intel nicht bestehen können. Aktuell reicht wohl noch der GDDR5 Schachzug aus, aber eDRAM muss kommen. Ich habe da aber keine großen Sorgen bzgl Technologie von Seiten AMD, weil die XBOX720 wird genau das ja haben. Ich befürchte es wird eher am Fertiger liegen, der Ihnen noch das Genick brechen könnte. und genau da habe ich auch wirklich die größten Bauchschmerzen....

        AMD braucht einfach gewisse Schlüsseltechnologien die eDRAM on Packge und Interposer in den nächsten Jahren, sonst gehen Sie einfach unter.

        Zitat

        Soweit das altbekannte.
        Jetzt zur Frage: "Was ändert der Versuch, den größten Sprung seit dem IBM-PC durchzuziehen, an der fehlenden Möglichkeit, große Sprünge zu machen?"
        Die Ideen sind da, die Konzepte stehen. Das ist mit das wichtigste, denn so was schüttelt man nicht über Nacht aus dem Ärmel. Bei allem anderen ist man halt auf seine Partner angewiesen, aber das wäre man EH! Man ist also zu einem gewissen Grad einfach machtlos.

        Aktuell kan AMD eigentlich nicht wirklich viel mehr machen, selbst wenn Sie mehr Geld hätten. Ok, Sie könnten sich ihre FABs wieder kaufen, und dann da mal die Peitsche auspacken Aber das ist einfach unrealistisch.

        Zitat

        Und das machen sie. Bei AMD sehe ich dagegen keine Beschleunigung.
        Jaein. Es fehlen aktuell einige Launches.

        Es kommt dieses Jahr einiges bzgl HSA, APU Opterons usw usw.

        Soweit ich das einschätzen kann, sollten da einige große Schritte auf einmal passieren, sobald die APU-Opterons da sind. Die FirePro APUs sind ja schonmal ein guter Schritt gewesen.

        Spannend wird halt vor allem, ob man jetzt SMP Systeme mit APUs bauen kann, oder nicht, und was jetzt mit HT für die reinen CPUs wird. Hier muss man wirklich mal endlich den nächsten Schritt tun.

        Zitat

        Genauso wie bei gpGPU, wo CUDA ja sofort nach der Einführung von OpenCL weggestorben ist
        nVidia hatte hier wohl die kritische Masse bereits überwunden. Zudem können Sie mit Features wie GPUDirect SEHR überzeugen. Auch DynamicParalelism ist sehr beliebt. Man hört aber weiterhin überwiegend, dass die Leute eigentlich nicht wirklich weiter auf CUDA setzen wollen, einfach weil Sie selbst erkannt haben, dass die Bindung an CUDA eben problematisch ist. Sie haben nur oft keine andere Wahl. Die neuen Features sind überzeugend, die Software ist schon teilweise auf CUDA da, nVidia gibt inzwischen 0 OpenCL Support (Kepler GPUs sind nicht für OpenCL von der KhronosGroup zertifiziert.... nVidia hat gar keine OpenCL 1.2 GPUs im Angebot usw)

        Dazu kommt halt, das nVidia in de Markt >50% besitzt, wohl eher sogar in GPGPU Bereich >75%.

        Im SFF Markt sieht das GANZ! anders aus.

        <<10% Marktdurchdringung, und man hat das total veraltete Featureset im Vergleich zur Konkurrenz.

        Zudem wird im SFF-Markt viel viel viel! mehr Wert darauf gelegt, das ich in der nächsten Generation der Hardwareliferanten einfach wechseln kann, wenn der scheise baut.

        Die Märkte sind also überhapt nicht vergleichbar.

        Zitat

        Du bist dir schon darüber im klaren, dass das ein reines Softwareprojekt auf Basis einer externen Emulation ist?
        Da wird rein gar nichts nativ ausgeführt, denn in aktuellen AMD CPUs gibt es keine ARM-Kerne. Egal, wie oft du das behauptest.
        Ich habe es nur am Rande verfolgt, da ich selbst kein ARM-Gerät besitze, und daher für mich völlig uninteressant.

        Zitat

        Und nur dafür. Davon, dass das Ding frei programmierbar/zugänglich ist, wüsste ich nichts. Wäre für ein Sicherheitssystem auch alles andere als gut, wenn es das wäre.
        AMD hat sich hierzu noch nicht geäußert. Man wird das sehen müssen.

        Zitat

        Mit einem kleinen A5 kannst du aber nicht die Software betreiben, die auf einem Desktop/Notebook von Interesse ist. Da ist Quadcore A9 oder A15 gefordert.
        Musst du auch nicht. Es reicht, wenn man Mobile-Anwendungen betreiben kann. ARM drückt auch NICHT in den Desktop/Notebook Bereich. Die drücken weiter oben in den Serverbereich, wo man Energieffizienz groß schreibt, und es egal ist, ob ich jetzt 10 oder 20 Cores habe.

        Zitat

        Mir wäre nicht bekannt, dass Microsoft Mitglied in der Allianz ist.
        Es heißt also korrekterweise "nutzen sie ALL ihre Software auf unseren Geräten, wenn sie ein Nerd sind, ständige reboots in ein anderes Betriebssystem nicht scheuen und damit leben können dass ein Teil ihrer Software mit 5% der Geschwindigkeit läuft, die ihr Smartphone bietet".
        Technisch immer noch interessant - aber das waren prä-3dfx-3D-Entschleuniger auch.
        MS unterstützt auch ARM. Wenn die Hardware dafür da ist, wird MS von ganz allein das OS auch für einen mischbetrieb fit machen. Zumal das nicht mal zwingend der Fall sein muss. Es reicht schon, wenn man entsprechend intelligente Compiler hat, die eben für mehrere OS compilieren können. Man braucht halt die richtigen Einstiegspunkte usw.

        Zitat

        Schön. Dir ist aber schon klar, dass ich nicht von Kernen, sondern Architekturen rede? Und den Aufgabentypen, die diesen besonders liegen?
        ARM sind lowPower designs, wobei A15 da etwas von weg geht. Man hat aber nicht die SingleThread Leistung eines x86, kann dafür aber auch sehr sehr sehr weit runter mit dem Verbrauch bei einem absoluten Witz an DIE-Space.

        Schau doch mal das BigLittle Konzept an. Das könnte man durchaus auch mit x86 mischen. Das Ergebnis wäre ein Rechner den man eigentlich nicht mehr runter fahren müsste, und der extrem sparsam im Idle, dafür aber noch immer sehr stark unter Last wäre.

        Ich seh da jetzt dein Problem nicht
        [/quote]
        Zitat

        Jup, ein Betriebssystem, dass im laufenden Betrieb auf eine andere Architektur wechseln kann, wäre schon was feines.
        So ähnlich wie ein 10 GHz Prozessor mit 10 mW Verbrauch.
        Oder ein Fissionsreaktor, der keine Strahlung abgibt und keinen Müll produziert.
        Oder ein Solarauto, dass nachts fährt.
        BigLittle funktioniert auch.
        Crosscompiles auf jedwede Architektur funktioniert auch.
        Ich seh da keine unüberwindbaren Hürden. Mit MS ja durchaus aktuell, weil MS da aktiv werden muss.

        Für Linux seh ich aber wirklich absolut kein Problem, Linux derart an zu passen, dass eben beide Architekturen in unterschiedlichen Powerstates genutzt werden. Man muss halt "nur" die Software und vor allem die Compiler fit dafür machen. Vor allem müssen die Hardware und Compilerhersteller Hand in Hand arbeiten, damit der Kontextwechsel auch wirklich sauber passt, und man nicht versehentlich den falschen Code verwendet

        So unrealistisch wie du das darstellst ist das bei weitem nicht. Die Grundlagen dafür sind da, man muss es nur zusammenführen.

        Genau hier seh ich z.B. auch eine Kernaufgabe für das HSA-Konsortium. Sie müssen entsprechende Schnittstellen für die Compiler/Hardware entwickeln, die genau so etwas reibungslos ermöglichen.

        Zitat

        Schön gesagt.
        "unterschiedliche Einsatzfelder"
        "auf Kernkompetenzen konzentrieren"

        Und was will HSA, zumindest der HSA-Partner-AMD-Theorie zu folge? Beide Architekturen gleichberechtigt parallel in einer einheitlichen Umgebung für die gleichen Aufgaben nutzen.
        AMD will vor allem sich von Intel befreien, und den ARM Zug für sich nutzen, ohne ihre x86-Kompetenzen zu vergessen, wo Sie eine breite Softwareunterstützung haben. Halt etwas, was Intel nicht liefer kann, aber nützlich ist.

        Ich versteh auch wirklich nicht, worauf du hinaus wilslt imt "gleichen Aufgaben" Man nimmt das, was am Besten für eine Aufgabe geeignet ist.

        Für ein x86 Programm x86 Cores. Für ARM Programme ARM Cores. Für low Power/idle usw ARM, für Sequenzielle Parts mit viel Rechenbedarf x86. Für Sequenzielle parts, die nur sehr wenig Leistung brauchen (z.B. iGPU steuern usw usw) ARM, für massiv parallele Aufgaben die iGPU.

        Das HSA Konzept ist absolut begrüßenswert! Wenn die Hardware das alles vom Programmierer weg nimmt, dann ist das göttlich, und selbst wenn es nur der Compiler übernimmt, ist es noch immer sehr sehr gut.

        Es muss halt nur funktionieren

        Bisher gibt es aber keine Anzeichen dafür, dass es eben nicht geht. Das Konsortium ist nur etwas ruhig. Jetzt muss sich zeigen, ob das die Stille vor der Veröffentlichung, oder die Stille vor dem großen Knall unter den Partnern ist. We will see.
  • Print / Abo
    Apps
    PC Games Hardware 01/2017 PC Games 12/2016 PC Games MMore 01/2016 play³ 01/2017 Games Aktuell 12/2016 buffed 12/2016 XBG Games 11/2016
    PCGH Magazin 01/2017 PC Games 12/2016 PC Games MMORE Computec Kiosk On the Run! Birdies Run
article
1067465
CPU
AMD Kaveri: Ausblick auf den Heterogeneous Uniform Memory Access (HUMA)
Mit der nächsten Ausbaustufe der APUs, der Accelerated Processing Units, setzt AMD auf einen gemeinsamen Speicher für die integrierte CPU sowie die GPU - dieses Prinzip nennt sich Heterogeneous Uniform Memory Access (HUMA) und erlaubt unter anderem eine vereinfachte Programmierung der APUs.
http://www.pcgameshardware.de/CPU-Hardware-154106/News/AMD-Kaveri-Heterogeneous-Uniform-Memory-Access-HUMA-1067465/
30.04.2013
http://www.pcgameshardware.de/screenshots/medium/2013/04/AMD-HUMA-02.jpg
cpu,grafikkarte,amd,kaveri
news