AMD stellt HUMA vor

[Flusher]

HUMA = Heterogeneous Uniform Memory Access

Revolution im PC-Bereich?

http://www.golem.de/news/huma-gemeinsamer-speicher-fuer-cpu-und-gpu-nicht-nur-fuer-ps4-1304-99009.html

http://www.pcgameshardware.de/CPU-Hardware-154106/News/AMD-Kaveri-Heterogeneous-Uniform-Memory-Access-HUMA-1067465/



Man hat es ja bereits vermutet, dass AMD das PS4 Konzept auch in den PC-Bereich bringen wird. Dass es aber schon mit Kaveri so weit ist, hätte ich nicht erwartet.

Meinungen?

[Coda]

Warum hast du es nicht erwartet? Sie haben alle Bausteine fertig, warum sollen sie sie nicht in den APUs verbauen?

Übrigens recht viel Marketing-Bullshit natürlich. Aber das braucht AMD gerade.

[Flusher]

Warum hast du es nicht erwartet? Sie haben alle Bausteine fertig, warum sollen sie sie nicht in den APUs verbauen?

Übrigens recht viel Marketing-Bullshit natürlich. Aber das braucht AMD gerade.

Naja nach landläufiger Meinung, hat man eigentlich sowas in einer Jaguar-Lösung erwartet. Dass das Ganze jetzt mit Steamroller noch in diesem Jahr kommen wird, finde ich wie gesagt etwas unerwartet.

Selbstverständlich ist das viel Marketing Unsinn dabei. Wäre aber bei NVIDIA oder Intel auch nicht anders ;)

Wie siehst du als (Spiele)-Entwickler denn diese Technologie?

[Radeonfreak]

Gibt's da Vorteile wenn man eine dezidierte Grafikkarte benutzt? :confused:

[tomvos]

Gibt's da Vorteile wenn man eine dezidierte Grafikkarte benutzt? :confused:

Ganz grob vereinfacht beschrieben:

Das kommt drauf an. Bisher ist es so, dass ein Arbeitspaket mit der CPU erstellt wird, dann über PCIe ins VRAM der GPU geladen wird, dort berechnet wird, um dann wieder per PCIe in das RAM des Rechners geschrieben zu werden.

Solange die Transaktionszeit über PCIe deutlich kleiner ist als die Rechenzeit auf der GPU (im Vergleich zur Rechenzeit auf der CPU), dann lohnt sich eine schnelle dedizierte Grafikkarte eher.

Sobald aber die Transaktionszeit einen deutlichen Anteil an der Gesamtzeit hat, dann wäre es hilfreich, wenn nun nicht die gesamten Daten über PCIe gesendet und empfangen werden müssten, sondern nur noch Pointer auf Speicherbereiche. Das ist eine der neuen Funktion, welche HUMA bieten soll.

[Botcruscher]

Deswegen müssen die Daten dann aber trotzdem vom Arbeitsspeicher in den Grafikartenram? Man spart so halt etwas Overhead. Bei der iGPU liegen die Daten wenigstens schon da wo man sie braucht.

[Flusher]

Ist es denn dann nicht möglich, dass die dedizierte GPU über das PCIe Interface direkt auf den Hauptspeicher zugreifen kann und den eigenen Speicher dann gar nicht mehr benötigt? Macht natürlich nur sinn, wenn die Speicherbandbreite ausreichend ist.

Jetzt wo ich darüber nachdenke - selbst PCIe 3.0 mit 32 Lanes hat nichtmal eine Bandbreite von 32 GB/s - das liegt auf dem Niveau einer Einsteiger-GPU mit DDR3 Speicher. Oder habe ich gerade einen Denkfehler?

[S940]

Gibt's da Vorteile wenn man eine dezidierte Grafikkarte benutzt? :confused:

Phil Rogers erklärte während der Telefonkonferenz außerdem, dass auch diskrete GPUs von hUMA profitieren sollen. Denn GPUs dürfen dann auf den gesamten Systemspeicher (Virtual Address Space inklusive Pageable System Memory) zugreifen statt nur auf Teile davon, und zwar mit den gleichen Pointern, wie sie auch CPUs nutzenhttp://www.heise.de/newsticker/meldung/AMDs-Unified-Memory-Mehr-Performance-und-Energieeffizienz-fuer-Kaveri-und-Co-1850975.html

Die Latenz über PCIe wird deswegen aber natürlich nicht besser.

[Locuza]

Naja nach landläufiger Meinung, hat man eigentlich sowas in einer Jaguar-Lösung erwartet. Dass das Ganze jetzt mit Steamroller noch in diesem Jahr kommen wird, finde ich wie gesagt etwas unerwartet.

Das ganze war schon jahrelang auf den Roadmaps und dann später direkt bei Kaveri adressiert.
http://www.elektroniknet.de/uploads/media_uploads/images/1361212414-13-amdroadmap.jpg

Das war somit schon bestätigt.

Mit der CPU hat das ganze ja auch weniger zu tun, ausschlaggebend sind eher die Fähigkeiten der GPU, die Unified Northbridge und die Memory Managment Units.
Kabini als Jaguar-Abnehmer hat ja keine hUMA.

[DinosaurusRex]

Kabini als Jaguar-Abnehmer hat ja keine hUMA.

Warum eigentlich nicht? :confused:

[Locuza]

Nun, offiziell ist erst einmal ja gar nichts, aber da in diesem Zusammenhang Kabini nicht genannt wurde, gehe ich davon aus das Kabini keine hUMA besitzen wird.

Bei dieser Roadmap steht auch nur bei Kaveri HSA Application Support:
http://www.notebookcheck.com/typo3temp/_processed_/csm_AMD_Client_Roadmap_1_7_13_0acf512345.jpg

Kabini kommt ja auch einige Monate vor Kaveri.
Vielleicht war das zu früh, für die verbesserte Unified-Northbridge, den verbesserten Memory-Managment-Units oder bei anderen technischen Details.

[R.I.P.]

Huh? Was redet ihr denn da? Das Revolutionäre an der PS4 ist doch der gemeinsame Zugriff auf den Speicher von GPU + CPU! Wurde ja schon xmal in fast jeder PS4 News erklärt. Also bei PS4 auch Kabini + GPU. Deswegen hat die PS4 ja 8GB GDDR5..

Wenn Kabini im Desktop/Notebook gemeint ist, dann ok, wurde glaube ich niemals bestätigt oder dementiert, aber ohne DDR4 oder GDDR5 sowieso unnütz

[Screemer]

einheitliche gddr5 onboard für den ganzen soc sollen obiges problem lösen.

aktualisieren wäre ne idee...

[ndrs]

Also bei PS4 auch Kabini + GPU.
[...]
Wenn Kabini im Desktop/Notebook gemeint ist, dann ok

Du verwechselst Kabini mit Jaguar. Kabini ist der komplette Die aus Jaguarkernen und GPU. In einer PS4 steckt also kein Kabini. Der CPU-Teil ist so gut wie identisch. Mehr aber auch nicht.

aber ohne DDR4 oder GDDR5 sowieso unnütz
Gerade bei geringer Speicherbandbreite sollten die eingesparten Kopiervorgänge die größten Performance-Sprünge bringen.

[Fragman]

die news bedeutet dann wohl auch das es keine ramgrenze mehr geben wird fuer gpu's?
oder kommt dann doch wie schon in einem anderen thread besprochen mainboard versionen mit unterschiedlichen festverloeteten ramgroessen?

(oder bleibt der aktuelle systemram gleich, damit einhergehend doch eine starke ausbremsung der gpu?)

[Tesseract]

die frage ist ob da auch "benutzbare" ausführungen kommen die in den punkten bandbreite und rechenleistung in der nähe von dedizierten grakas liegen.
wenn das ganze dann mit DDR3 und auf der rechenleistung von low-end-grakas rumkrebst können sie es behalten.

[No.3]

HUMA = Heterogeneous Uniform Memory Access

Revolution im PC-Bereich?

http://www.golem.de/news/huma-gemeinsamer-speicher-fuer-cpu-und-gpu-nicht-nur-fuer-ps4-1304-99009.html

http://www.pcgameshardware.de/CPU-Hardware-154106/News/AMD-Kaveri-Heterogeneous-Uniform-Memory-Access-HUMA-1067465/

Huh? Was redet ihr denn da? Das Revolutionäre an der PS4 ist doch der gemeinsame Zugriff auf den Speicher von GPU + CPU!


wieso nur musste ich da sofort an das Chip-RAM beim Commodore Amiga denken... :confused:

[ndrs]

wenn das ganze dann mit DDR3 und auf der rechenleistung von low-end-grakas rumkrebst können sie es behalten.
Selbst Low-End-GPUs haben bei weitem mehr Rechenleistung als aktuelle Highest-End-CPUs. Warum willst du das vorhandene Potential ungenutzt lassen?

[Tesseract]

Selbst Low-End-GPUs haben bei weitem mehr Rechenleistung als aktuelle Highest-End-CPUs. Warum willst du das vorhandene Potential ungenutzt lassen?

bringt aber nix wenn man ein spiel spielen will und die APU erstickt dabei einfach an der rechenlast. spiele-engines sind die hauptdisziplin, für die eine vereinigung von CPU und GPU sinnvoll ist und genau da sind alle heutigen APUs totale krüppel.

ich habe ehrlich gesagt die befürchtung, AMD wird da mit viel marketing-blah etwas rausbringen, das leistungsmäßig unterhalb der PS4 liegt.

[fondness]

ich habe ehrlich gesagt die befürchtung, AMD wird da mit viel marketing-blah etwas rausbringen, das leistungsmäßig unterhalb der PS4 liegt.

Drei Streamroller-Module und 512 GCN SPs. Die CPU-Leistung wird also deutlich über der PS4 liegen, die GPU-Leistung darunter, das ist kein wirkliches Geheimnis.

[R.I.P.]

Du verwechselst Kabini mit Jaguar. Kabini ist der komplette Die aus Jaguarkernen und GPU. In einer PS4 steckt also kein Kabini. Der CPU-Teil ist so gut wie identisch. Mehr aber auch nicht.

Gerade bei geringer Speicherbandbreite sollten die eingesparten Kopiervorgänge die größten Performance-Sprünge bringen.

Danke für die I-Tüpfelchen, was aber grundsätzlich nichts an meiner Aussage ändert: die Technik des gemeinsamen Zugriffs auf den Speicher würde auch mit einer beliebig genannten CPU mit Jaguar Kernen funktionieren, wenn so gewollt, wie die PS4 ein Beispiel ist (obwohl sehr stark custom). ;D

[ndrs]

spiele-engines sind die hauptdisziplin, für die eine vereinigung von CPU und GPU sinnvoll ist.
Jedwede Berechnung die sich in irgendweiner Form massiv paralellisieren lässt kann davon profitieren (Stichweort GPGPU). Spiele sind da eher ein Nebenschauplatz.

[ndrs]

die Technik des gemeinsamen Zugriffs auf den Speicher würde auch mit einer beliebig genannten CPU mit Jaguar Kernen funktionieren, wenn so gewollt, wie die PS4 ein Beispiel ist (obwohl sehr stark custom). ;D
Ich denke, dass das eher eine Sache der integrierten Northbridge ist. Und darauf, dass sich in der Beziehung Kabini und PS4 noch so ähnlich sind würde ich nicht wetten wollen.

Edit: Übrigens ist die Nutzung von hUMA in der PS4 garnicht geklärt. Siehe
Auf Rückfragen bezüglich der Sony PlayStation 4 ließ uns AMD lediglich wissen, dass Details zur Implementierung von Sonys Architektur nicht kommentiert werden. Somit gibt es vorerst keine Bestätigung für die HSA-Kompatibilität oder die Nutzung von hUMA bei der PS4.
http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?id=1367308053

[Skysnake]

Warum hast du es nicht erwartet? Sie haben alle Bausteine fertig, warum sollen sie sie nicht in den APUs verbauen?

Übrigens recht viel Marketing-Bullshit natürlich. Aber das braucht AMD gerade.
Vor allem sollten sich die Marketingfuzis nochmal anschauen, was UMA/NUMA bedeutet. :ugly:

Mit nem globalen Adressraum hat das nämlich apriori REIN GAR NICHTS! zu tun...

Ich kann auch mit nem NUMA System einen globalen Adressraum aufspannen... Wird bei jedem heutigen Multi-Sockel-System gemacht. Das sind zwar SMP Systeme, aber der Speichercontroller liegt in den jeweiligen CPUs, daher ist es eben kein UMA, sondern NUMA, da die Latenz davon abhängt, an welcher CPU der RAM hängt.

Bis auf derartige "Freinheiten" :ugly: sind die Folien aber gar nicht mal schlecht gemacht, und greifen die Grundproblematik eigentlich ganz brauchbar auf.

die news bedeutet dann wohl auch das es keine ramgrenze mehr geben wird fuer gpu's?

Die gibt es faktisch schon heute bei den dedizierten GPUs nicht mehr. Die können schon länger mit 64Bit Adressen umgehen, die halt intern auf 48 (42???) Bit physikalische Adressen runtergebrochen werden.

Schau dir nur mal GPUDirect an bei nVidia. Da wird dir dann schnell klar, dass das "nur" noch an den RAM-Controllern und eben den Einschränkungen von GDDR5 liegt.


oder kommt dann doch wie schon in einem anderen thread besprochen mainboard versionen mit unterschiedlichen festverloeteten ramgroessen?

(oder bleibt der aktuelle systemram gleich, damit einhergehend doch eine starke ausbremsung der gpu?)
Bei GDDR5 würde ich davon ausgehen, dass fest verlötet ist. Ist bzgl Kosten usw auch wünschenswert.

bringt aber nix wenn man ein spiel spielen will und die APU erstickt dabei einfach an der rechenlast. spiele-engines sind die hauptdisziplin, für die eine vereinigung von CPU und GPU sinnvoll ist und genau da sind alle heutigen APUs totale krüppel.

APUs mit gemeinsamen Adressraum spielen ihre Stärken aber gerade abseits von Games aus, und werden hier eine gefährliche Kombination für dedizierte GPUs. Sie haben halt einige architektonische Vorteile, die sie vor reine CPU aber auch vor CPU+dGPU katapultieren können. Alles was feingranulare Problemestellungen hat, oder eben auch viele Branches kann prinzipiell noch immer auf eine APU beschleunigt werden, bei ner dedizierten GPU schauste da schnell in die Röhre.

Das sind zwar Rechenmonster, aber auch so schwerfällig wie ein 40-Tonner...


ich habe ehrlich gesagt die befürchtung, AMD wird da mit viel marketing-blah etwas rausbringen, das leistungsmäßig unterhalb der PS4 liegt.
Kann man davon ausgehen, ist aber auch kein Beinbruch aktuell.

Sony und MS werden sicherlich etwas dafür abgedrückt haben, für 1-2 Jahre nicht all zu stark unter Druck zu geraten.

[Tesseract]

Jedwede Berechnung die sich in irgendweiner Form massiv paralellisieren lässt kann davon profitieren (Stichweort GPGPU). Spiele sind da eher ein Nebenschauplatz.
parallelisierbarkeit hast du im consumer-bereich fast ausschließlich in spielen. für office und surfen braucht es kein GPGPU.

APUs mit gemeinsamen Adressraum spielen ihre Stärken aber gerade abseits von Games aus, und werden hier eine gefährliche Kombination für dedizierte GPUs. Sie haben halt einige architektonische Vorteile, die sie vor reine CPU aber auch vor CPU+dGPU katapultieren können. Alles was feingranulare Problemestellungen hat, oder eben auch viele Branches kann prinzipiell noch immer auf eine APU beschleunigt werden, bei ner dedizierten GPU schauste da schnell in die Röhre.
gib mir ein beispiel. solche aufgaben gibt es abseits von spielen im consumerbereich, für den diese chips gedacht sind, so gut wie nicht.

[Skysnake]

Sortieren, Video/Musik codieren/encodieren, Auswertungen, Tabellenkalkulationen, Datenbanken teils, Hashing usw usw.

Mit der wichtigste Punkt dürfte aber Multi-Media und eben Sortieren sein. Gerade Datenbanken könnten allerdings auch recht gut davon profitieren, wobei das wohl großteils auch auf Sortieren dann hinausläuft bei den Punkten, bei denen es relevant wird.

Sortieren ist aber eben ein EXTREM wichtiger Punkt. Sortieren muss man ständig und andauernd. Deswegen gibt es da ja auch so unglaublich viele unterschiedliche Algorithmen und Datenstrukturen, um jeweils die perfekt passende Lösung für sein Problem zu haben.

[Tesseract]

das sind alles keine anwendungsbeispiele sondern grundkonzepte. wo wird im consumerbereich z.B. so viel (und vor allem zeitkritisch) sortiert, dass man einen unterschied merken könnte? die meisten sortierungen haben wahrscheinlich so wenige elemente, dass sich threading überhaupt nicht lohnt.

der punkt ist nicht, dass es solche fälle nicht gibt, sondern, dass diese fälle in der consumer-praxis fast ausschließlich im echtzeit-rendering (AKA spiele) vorkommen weil hier pausenlos (jeden frame) enorme datenmengen (jedes pixel, jedes objekt, jeder vertex usw.) und das ganze noch zeitkritisch verarbeitet werden muss. wo kommt das sonst noch vor?

[R.I.P.]

Ich denke, dass das eher eine Sache der integrierten Northbridge ist. Und darauf, dass sich in der Beziehung Kabini und PS4 noch so ähnlich sind würde ich nicht wetten wollen.

Edit: Übrigens ist die Nutzung von hUMA in der PS4 garnicht geklärt. Siehe

http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?id=1367308053

Habe dasselbe bei Planet3dnow gerade selbst gelesen. Also bitte auf Eis legen, was ich gesagt habe :freak:

[Windi]

Sortieren, Video/Musik codieren/encodieren, Auswertungen, Tabellenkalkulationen, Datenbanken teils, Hashing usw usw.

Mit der wichtigste Punkt dürfte aber Multi-Media und eben Sortieren sein. Gerade Datenbanken könnten allerdings auch recht gut davon profitieren, wobei das wohl großteils auch auf Sortieren dann hinausläuft bei den Punkten, bei denen es relevant wird.

Sortieren ist aber eben ein EXTREM wichtiger Punkt. Sortieren muss man ständig und andauernd. Deswegen gibt es da ja auch so unglaublich viele unterschiedliche Algorithmen und Datenstrukturen, um jeweils die perfekt passende Lösung für sein Problem zu haben.

Mal Video/Musik ausgenommen, kommt das wirklich so häufig vor?
Vor allem bei der breiten Masse die vor allem Office, Surfen und Multimedia macht?
Wird in Zukunft bei Video/Musik nicht eh auf eigenständige De/Encoder gesetzt?


Dank Playstation und Xbox sehe ich die meisten Anwendungen auch erst im Spielebereich und später dann bei weiteren Programmen.

[Skysnake]

das sind alles keine anwendungsbeispiele sondern grundkonzepte. wo wird im consumerbereich z.B. so viel (und vor allem zeitkritisch) sortiert, dass man einen unterschied merken könnte?

der punkt ist nicht, dass es solche fällt nicht gibt, sondern, dass diese fälle in der consumer-praxis fast ausschließlich im echtzeit-rendering (AKA spiele) vorkommen weil hier pausenlos (jeden frame) enorme datenmengen (jedes pixel, jedes objekt, jeder vertex usw.) und das ganze noch zeitkritisch verarbeitet werden muss. wo kommt das sonst noch vor?
Es gibt noch eine Welt außerhalb von Zockern ;)

Und Videos/Musik Transcodieren ist ein typischer Anwendungsfall für den 0815 Anwender.

Du darfst dich da auch nicht so sehr auf den Zocker mit seiner 1k€ Kiste versteifen, sondern mehr an den Menschen mit seinem Laptop oder gar Smartphone denken, und auf der anderen Seite eben Server.

AMD bringt nicht ohne Grund seine APUs als FirePros/Opterons jetzt raus.

Und ja, es sind Grundkonzepte, es zeigt aber, wie wichtig! die Integration eben ist.

Mit ner dedizierten GPU kannst du vieles davon entweder gar nicht vernünftig machen, oder du brauchst wirklich richtig dicke Probleme, die wirklich nie ein normaler Anwender im Heimbereich hat.

Ob man den Geschwindigkeitsvorteil unbedingt direkt spürt ist auch nicht wirklich entscheidend. Wenn man dadurch 5-10% mehr Akkulaufzeit erreicht, ist das schon Argument genug für den 0815 Kunden ;)

Mit dem Argument: "Wer merkt schon den Unterschied", macht man es sich halt sehr einfach. Warum kauft jemand einen Quadcore, wenn er nicht zockt? usw usw.

Es gibt halt doch genug Leute, die ihren Nutzen daraus ziehen (sobald die Software dazu da ist, was das Hauptproblem ist).

@Windi:
Sortieren ist wohl der häufigste Vorgang, den es überhaupt gibt.

Und ja, auch auf deinem Rechner wird sehr sehr sehr oft sortiert ;) Vor einer Suche macht man nämlich sehr oft eine Sortierung. Danach sucht man nämlich das nächste mal schneller ;)

Indizierung mittels Hashfunktion ist auch sehr häufig.

Man sollte das wirklich nicht unterschätzen, wie häufig Sortierverfahren eingesetzt werden.

Das 0815Nutzer-Argument ist halt so ne Sache. Was ist denn ein 0815 Nutzer? Und ist dem sein "Rechner" nicht inzwischen ein Smartphone, und ist der dann nicht gerade über die zusätzliche Leistung/Akkulaufzeit glücklich?

Und wenns in den Profi-Bereich geht, haste halt Datenbanken usw usw usw.

[Tesseract]

Und Videos/Musik Transcodieren ist ein typischer Anwendungsfall für den 0815 Anwender.
das machen spezialeinheiten viel effizienter. abgesehen davon ist auch das kein wirklicher anwendungsfall für homeuser. decodieren ist einer, deswegen haben grakas seit jahren spezialeinheiten dafür verbaut.

Mit ner dedizierten GPU kannst du vieles davon entweder gar nicht vernünftig machen, oder du brauchst wirklich richtig dicke Probleme, die wirklich nie ein normaler Anwender im Heimbereich hat.
kannst du mit der APU auch nicht weil sich der verwaltungsaufwand dafür oft nicht lohnt.

Ob man den Geschwindigkeitsvorteil unbedingt direkt spürt ist auch nicht wirklich entscheidend. Wenn man dadurch 5-10% mehr Akkulaufzeit erreicht, ist das schon Argument genug für den 0815 Kunden ;)
und das soll jetzt ein argument für AMDs chip sein? :freak:

Mit dem Argument: "Wer merkt schon den Unterschied", macht man es sich halt sehr einfach. Warum kauft jemand einen Quadcore, wenn er nicht zockt? usw usw.
das ist eine berechtigte frage und der hauptgrund, warum wir seit jahren bei ~4 cores feststecken und intel generation für generation R&D in die energieeffizienz buttert anstatt die CPUs auf >=8 cores aufzublasen. gerade in ultrabooks sind dualcores erstaunlich häufig.

es geht mir darum, dass meiner meinung nach die balance nicht stimmt. der chip hat für ein non-gaming-system eine viel zu starke und für ein gaming-system eine viel zu schwache GPU. nicht ohne grund hat die PS4 ein viel GPU-lastigeres verhältnis.

[tomvos]

@Skysnake:

Deine Beispiele mögen ja durchaus korrekte Anwendungsfälle sein, aber in der Praxis ist es sehr teuer, eine Anwendung auf HSA/HUMA zusätzlich zu optimieren. Denn im Gegensatz zur PS4 muss der Code ja auch noch auf dem Rest der x86 Welt laufen.

Des Weiteren ist immer die Frage zu klären, ob denn nun eine Operation über die CPU oder GPU schneller ist. Wie du schon selbst beschrieben hast, mag das durchaus von der zu verarbeitenden Datenstruktur abhängen. Also kann diese Entscheidung oftmals erst zur Laufzeit der Anwendung korrekt getroffen werden.
Natürlich gibt es Standardfälle, in denen eine Entscheidung pauschal für GPU oder CPU korrekt entschieden werden kann. Aber welcher Entwickler macht sich denn noch die Arbeit, seinen Code bezüglich der Wahl der Ausführungseinheit zu optimieren?

AMD müsste also neben der Hardware ein verdammt cleveres Framework liefern, welches genau diese Entscheidung (meist) korrekt trifft. Der Entwickler nutzt dann nur noch irgendwelche Library-Funktionen, während die Library selbst sich darum kümmert, wie es die Funktion denn nun am effizientesten zwischen CPU und GPU aufteilt und ausführt (wie z.B. ein Hash-Table Sort)

Erst dann wird eine APU auf dem Massenmarkt Erfolg haben. Bis dahin ist aber noch eine Menge Arbeit zu leisten.

[Skysnake]

kannst du mit der APU auch nicht weil sich der verwaltungsaufwand dafür oft nicht lohnt.

Dann hast du das grundlegende Konzept hinter HSA nicht verstanden ;)

Ziel ist es mehr oder weniger Taktspezifisch entscheiden zu können, ob jetzt etwas auf Einheit A oder besser auf B ausgeführt werden soll. "Taktgenau" deswegen, weil es keinen/wenig Sinn macht. Meist kann man das ja durchaus wieder in vernünftige Größen packen.

Mit dem gemeinsamen Adressraum und Speicher fällt ja ein sehr sehr großer Block weg, bzgl Overhead.

Ziel ist es eigentlich, bei Sachen wie OpenMP eben ganz trivial zu paralellisieren, und dass der Compiler dann sieht: "Ah, ich hab hier ne Schleife, die ich 1k mal durchlaufe, und die unabhängig ist. Also kann ich das auf die GPU mappen, weil das genug Parallelität enthält."
Und wenns halt nur 4 oder 8 Fach parallel ist, oder SEHR viele Branches enthält, bzw man eben Compiler"hints" gibt, dann packt der Compiler das auf die CPU-Cores.

Mit statisches Codeanalyse/Profiling kann man da auch verdammt viel drehen.

Im Prinzip eignet sich ein Großteil der Aufgaben, die man mit OpenMP angeht auch für APUs mit HSA.


und das soll jetzt ein argument für AMDs chip sein? :freak:

HUMA ist ja nur Marketingsprech. Das Konzept (HSA) bezieht sich auf TI, Samsung usw usw. Da muss man auch nur darauf warten, dass das endlich kommt. Der Code soll halt auf den ARM-Designs UND auf den AMD Chips laufen. Das ist schon ein Vorteil für Entwickler. Du musst halt nur einmal das Code-Grundgerüst entwickeln.


das ist eine berechtigte frage und der hauptgrund, warum wir seit jahren bei ~4 cores feststecken und intel generation für generation R&D in die energieeffizienz buttert anstatt die CPUs auf >=8 cores aufzublasen. gerade in ultrabooks sind dualcores erstaunlich häufig.

Und genau da hilft eben HSA. Energie sparen, und Energie sparen zieht sich vom Smartphone bis hin zum größter Cluster/Supercomputer. Der limitierende Faktor ist Energie. Es wäre heutzutage kein Problem einen Rechner zu bauen, der 10 mal so schnell wäre als Titan. Das kann dann aber einfach keiner mehr bezahlen im Unterhalt. Die Technologie zur entsprechenden Skalierung, und auch die Probleme die entsprechend skalieren sind aber durchaus bereits vorhanden.


es geht mir darum, dass meiner meinung nach die balance nicht stimmt. der chip hat für ein non-gaming-system eine viel zu starke und für ein gaming-system eine viel zu schwache GPU. nicht ohne grund hat die PS4 ein viel GPU-lastigeres verhältnis.
Das ist halt Ansichtssache.

Du willst mehr CPU-Cores. Von denen kommt allgemein die Leistung aber durch Sachen wie SSE und AVX heutzutage neben der puren steigerung der Core Anzahl. Mit >4/8 Cores kommst du aber eben in Bereiche, wo deine Probleme einfach schon so viel Parallelität enthalten müssen (insbesondere wenn du dann auch noch SSE/AVX nutzen willst), dass du bereits darüber nachdenken kannst, die ganzen Sachen auf eine iGPU zu mappen. Bei ner dedizierten GPU musst du da bei weitem noch nicht drüber nachdenken, da ist einfach der Transferoverhead viel zu groß.

Wie schon oft gesagt. iGPUs eröffnen einen komplett neue Arbeitsfelder für GPUs, einfach nur weil der Transferoverhead wegfällt.

@Skysnake:

Deine Beispiele mögen ja durchaus korrekte Anwendungsfälle sein, aber in der Praxis ist es sehr teuer, eine Anwendung auf HSA/HUMA zusätzlich zu optimieren. Denn im Gegensatz zur PS4 muss der Code ja auch noch auf dem Rest der x86 Welt laufen.

DAS ist eben der Knackpunkt, der im Verantwortungsbereich des HSA-Konsortiums liegt. Im Optimalfall ist das nicht mehr als ein neucompilieren und einbinden der entsprechenden angepassten Bibliotheken.

Gerade für Sortierverfahren verwendet man eigentlich die 0815 Bibliotheken, wo es auch sehr sehr sehr saubere Interfaces gibt. Hier könnte man für den Programmierer völlig transparent das Sortierverfahren ersetzen, und da man einen gemeinsammen Adressraum hat, muss man auch nicht groß aufpassen.

Gleiches gilt für OpenMP. Auch hier ist ein sehr guter Ansatz vorhanden, wo man viel über den Compiler regeln kann.

Die Frage ist halt nur, ob Sie das auch machen werden, oder eben hoffen, dass der ARM-Zug die Sache zieht.


Des Weiteren ist immer die Frage zu klären, ob denn nun eine Operation über die CPU oder GPU schneller ist.

Dafür gibts Profiling und Codeanalyse.

SSE wird heutzutage von den Compilern auch automatisch eingesetzt usw usw.


Wie du schon selbst beschrieben hast, mag das durchaus von der zu verarbeitenden Datenstruktur abhängen. Also kann diese Entscheidung oftmals erst zur Laufzeit der Anwendung korrekt getroffen werden.
Natürlich gibt es Standardfälle, in denen eine Entscheidung pauschal für GPU oder CPU korrekt entschieden werden kann. Aber welcher Entwickler macht sich denn noch die Arbeit, seinen Code bezüglich der Wahl der Ausführungseinheit zu optimieren?

Kommt auf den Bereich drauf an. Je nachdem ist es entweder ein "Ich verwende so viele Bilbiotheken wie mögich" und einem "ich brauch das letzte quäntchen Leistung, also optimiere ich für eine Architektur"
Zumindest sollte man Bibliotheken nutzen, wenn es möglich ist. Es ist schwierig schnelleren Code selbst zu schreiben :freak: Und wenn, es doch macht, dann weiß man normal, was man macht. ;)


AMD müsste also neben der Hardware ein verdammt cleveres Framework liefern, welches genau diese Entscheidung (meist) korrekt trifft. Der Entwickler nutzt dann nur noch irgendwelche Library-Funktionen, während die Library selbst sich darum kümmert, wie es die Funktion denn nun am effizientesten zwischen CPU und GPU aufteilt und ausführt (wie z.B. ein Hash-Table Sort)

Gibt es durchaus genug unter Fortran. Da werden die Cachegrößen von den Bibliotheken meines Wissens nach zuerst automatisch ermittelt und dann dementsprechend verwendet.

Ich hatte für ne Matrixmultiplikation eine einfache Variante hiervon auch schonmal implementiert, die sich aber nur auf eine Cachestufe bezogen hat.


Erst dann wird eine APU auf dem Massenmarkt Erfolg haben. Bis dahin ist aber noch eine Menge Arbeit zu leisten.
Das definitiv.

Samsung, TI usw hier ins Boot zu holen war von AMD wirklich ein kluger Schachzug, denn damit können Sie die nötige Verbreitung erreichen. Fehlen eigentlich nur noch die Chinesen mit MIPS. Aber selbst ohne die ist das schon eine verdammt große Basis, WENN! sich die anderen beteiligten Firmen eben auch an den Fahrplan halten, und voll hinter HSA stehen. Davon sieht man leider bisher nichts/nicht viel :(

[Tesseract]

Ziel ist es eigentlich, bei Sachen wie OpenMP eben ganz trivial zu paralellisieren, und dass der Compiler dann sieht: "Ah, ich hab hier ne Schleife, die ich 1k mal durchlaufe, und die unabhängig ist.
und wie nicht-trivial das ist sieht man schön daran wie gut momentan klassische CPU-multicores ausgelastet werden; und wenn etwas nichtmal auf >=4 cores skaliert, wie dann auf hunderten?
abgesehen davon kann man schon froh sein wenn 1000 loops pro core überhaupt den threading-overhead rechtfertigen. mit hunderten cores wird das immer unwahrscheinlicher, vor allem wenn sich die gegen ein paar wenige cores mit brutal hoher pro-thread-performance behaupten müssen.
das ganze ist etwas komplexer als über einen fetten loop ein pragma zu setzen.

HUMA ist ja nur Marketingsprech. Das Konzept (HSA) bezieht sich auf TI, Samsung usw usw. Da muss man auch nur darauf warten, dass das endlich kommt. Der Code soll halt auf den ARM-Designs UND auf den AMD Chips laufen. Das ist schon ein Vorteil für Entwickler. Du musst halt nur einmal das Code-Grundgerüst entwickeln.
ich hab auch kein problem mit dem konzept, im gegenteil. meine kritik richtet sich an die gewichtung der einheiten in diesem speziellen AMD-modell.

Und genau da hilft eben HSA.
ein chip mit einem schlechten verhältnis der einheiten spart keine energie sondern verschleudert nur unnötig transistoren.

Du willst mehr CPU-Cores.
wie bitte? ich will die doppelte bis dreifache menge an GPU-cores damit man das teil guten gewissens als gaming-tauglich empfehlen kann. das bischen monitor ansteuern und die paar desktop-effekte kann man mit einer sandy bridge genauso und das auch noch sparsamer.
das ding ist so nicht fisch und nicht fleisch und genau das ist das problem.

[Skysnake]

Was sind dann Atoms, Core i3, die aktuellen APUs usw usw?

Sie setzen halt selbst die APUs nicht als wirkliche Gameingkisten an, sondern als Aufwertungen für CPUs, mit einem Touch zur Workstation, oder halt Microserver.

Sony und MS würden wie gesagt ziemlich pissed sein, wenn man mit der PS4/XBOX720 direkt ne normale APU für den Desktop bringen würde, die gleich shcnell oder gar schneller ist.

Da wird man sicherlich 1-2 Jahre warten müssen, nachdem die neuen Konsolen drausen sind.

Und bzgl dem Pragma:
Das ist halt die Frage, wann man überhaupt anfängt zu paralellisieren. Zudem ist es ja nicht so, das man plötzlich keine CPU mehr hat, sondern die iGPU einfach nur noch dazu.

Sprich in den Fällen, die du meinst, nutzt man halt einfach die CPU ganz normal weiter. Wo ist das Problem?

Die iGPU soll ja als Ergänzung da sein und nicht als Ersatz.

Und wenn ich mir vorstelle, ich müsste ne 10Core IB-E CPU mit AVX2 auslasten, dann ist der Sprung zur sinnvollen Nutzung der iGPU auch nicht mehr weit. Vor allem liegen dazwischen Welten im Energieverbrauch, und auch in den Kosten.

Und vor allem, was macht man dann in der nächsten Generation mit ~16 CPU-Cores inkl AVX?

Und was in der danach?

Ich hoffe du siehst, worauf das hinaus läuft. Es macht einfach ab einem gewissen Punkt schlicht keinen Sinn mehr, den Core Count weiter hoch zu pushen, einfach weil die Probleme, die man dafür braucht auch auf GPUs mit ihren Restriktionen passen.

[Tesseract]

Zudem ist es ja nicht so, das man plötzlich keine CPU mehr hat, sondern die iGPU einfach nur noch dazu.
aus sicht der herstellungskosten, des stromverbrauchs usw. ist das schon so.
eine iGPU mit dem selben techlevel aber 1/4 der cores könnte deutlich billiger und kleiner sein und trotzdem mehr oder weniger die selben aufgaben gleich gut abdecken. entweder das oder man versucht das teil wirklich gamingtauglich zu bekommen aber da fehlt halt noch einiges, vor allem wenn man bedenkt, dass bald neue konsolen kommen und sich ports an denen orientieren werden.

intel geht übrigens gerade in die selbe richtung. haswell hat einen viel größeren prozentsatz iGPU als z.B. zu sandy bridge, nur anfangen kann man damit irgendwie nix. was haswell kann, kann sandy im prinzip auch und für spiele sind beide zu verkrüppelt.

Ich hoffe du siehst, worauf das hinaus läuft. Es macht einfach ab einem gewissen Punkt schlicht keinen Sinn mehr, den Core Count weiter hoch zu pushen, einfach weil die Probleme, die man dafür braucht auch auf GPUs mit ihren Restriktionen passen.
wie oft denn noch: ich propagiere kein hochschrauben von CPU-cores.

[S940]

Deine Beispiele mögen ja durchaus korrekte Anwendungsfälle sein, aber in der Praxis ist es sehr teuer, eine Anwendung auf HSA/HUMA zusätzlich zu optimieren.
Naja schreib einfach in OpenCL und fertig. Der AMD-Treiber/Compiler kümmert sich dann um hUMA und nutzt das automatisch, falls Du ne entsprechende APU im System hast.
Oder halt C++ AMP, da gibts dann auch die Möglichkeit für nen SSE-Codepfad in der Binary.

@Skysnake:
Ich kann auch mit nem NUMA System einen globalen Adressraum aufspannen... Wird bei jedem heutigen Multi-Sockel-System gemacht. Das sind zwar SMP Systeme, aber der Speichercontroller liegt in den jeweiligen CPUs, daher ist es eben kein UMA, sondern NUMA, da die Latenz davon abhängt, an welcher CPU der RAM hängt.Natürlich kannst Du das, hab mich bei der Folie auch erstmal gewundert, was sie da sagen wollen, man kennts ja eigentlich traditionell vom ccNUMA der Opterons. Aber im Endeffekt gehts nur wieder um Unklarheiten. Was heißt schon "NUMA"? NUMA = "Non Uniform Memory Access", und was bedeutet das nun? Das die Speicherzugriffe nicht "einheitlich" sind. Latenzen sind total egal in dem Kontext, davon redet keiner. Bei nem Opteronsys hatte man eben unterschiedliche Speicherkontroller in jedem einzelnen Sockel/DIE, bei den aktuellen APUs hatte man dagegen 2 Speicherkontroller in einem einzigen Sockel, quasi ne Art 2P System mit shared DRAM-Kontroller und ohne Kohärenz. Ist also schon ok, dass NUMA zu nennen, aber man muss es halt wissen. Anfangs ist es schon ein bisschen komisch :freak:

Hatte eigentlich gehofft, das ein Mr. Papermaster mehr zur Technik erzählt, aber tja .. leider nur Blablubb ... ich hab die Folie auf P3D noch editiert, hat mir nicht gefallen so wie das ist. "Memory" ist einfach auch zu doppeldeutig. Man weiss nicht, ob er da die Speicheradressen, oder die Speichermodule meint - zumindest wenn man kein Hintergrundwissen hat.

[Skysnake]

Wie oft denn noch: ich propagiere kein hochschrauben von CPU-cores.
Dann versteh ich deine Kritik nicht, außer "bigger is better"

Genau da läuft man ja dann aber bei x86 in Pronleme aktuell. NOCH fehlt die Software, man braucht genug Bandbreite, also GDDR5 minimum. Besser noch nen EDRAM dazu. Soweit ist AMD aber scheinbar noch nicht.

Mit ner kleinen iGPU macht man es sich da in vielen Bereichen einfacher.

Und ja, ich hätte da auch gern mehr, seh da aber durchaus auch gewisse Zwänge. Son EDRAM usw ist ja auch nicht ganz trivial. AMD macht aktuell kleine Schritte, dafür aber recht viele. Ich habe den Eindruck, dass sie damit aktuell besser fahren als mit großen Sprüngen, wo sich ständig was verschiebt.

Naja schreib einfach in OpenCL und fertig. Der AMD-Treiber/Compiler kümmert sich dann um hUMA und nutzt das automatisch, falls Du ne entsprechende APU im System hast.
Oder halt C++ AMP, da gibts dann auch die Möglichkeit für nen SSE-Codepfad in der Binary.

Naja, das muss sich erst noch zeigen. So 100% überzeugt bin ich noch nicht. Mit multithread gibts immer wieder raceconditions. Der Teufel steckt da im Detail!

@Skysnake:
Natürlich kannst Du das, hab mich bei der Folie auch erstmal gewundert, was sie da sagen wollen, man kennts ja eigentlich traditionell vom ccNUMA der Opterons. Aber im Endeffekt gehts nur wieder um Unklarheiten. Was heißt schon "NUMA"? NUMA = "Non Uniform Memory Access", und was bedeutet das nun? Das die Speicherzugriffe nicht "einheitlich" sind. Latenzen sind total egal in dem Kontext, davon redet keiner.
Ähm doch :ugly:

Natürlich bezieht sich das auch auf die Latenzen. Man bezieht sich da ja nur darauf, wie auf den Speicher zugegriffen wird. Also ob auf den Speicher sich die Zugriffe unterscheiden. Wie das dann im Detail realisiert ist ist ja egal.


Bei nem Opteronsys hatte man eben unterschiedliche Speicherkontroller in jedem einzelnen Sockel/DIE, bei den aktuellen APUs hatte man dagegen 2 Speicherkontroller in einem einzigen Sockel, quasi ne Art 2P System mit shared DRAM-Kontroller und ohne Kohärenz. Ist also schon ok, dass NUMA zu nennen, aber man muss es halt wissen. Anfangs ist es schon ein bisschen komisch :freak:

Mit NUMA hab ich da doch gar kein Problem, sondern mit der Aussage zum shared Memory/Addresspace. Das kannste eben auch auf NUMA und sogar auf distributed Memory Systemen realisieren. Da gibt es ja die wildesten Kombinationsmöglichkeiten, die es eigentlich auch alle schonmal gab.

[Gipsel]

Teseracts Argument kann man in etwa so zusammenfassen:
Momentan fährt er eine Vespa und unter einem Ferrari steigt er nicht auf's Auto um. Ein Golf ist ihm zu popelig. :wink:

[Tesseract]

passender vergleich wäre eher:
es gibt leute, die in die stadt schuhe shoppen fahren und es gibt leute, die möbel transportieren wollen. für das eine gibt es einen smart und für das andere einen LKW.
und ihr argumentiert jetzt darüber, dass man mit einem smart mit dachträger mehr transportieren kann als mit einem smart ohne dachträger. mein punkt ist, dass man nie so viele schuhe kaufen wird, dass diese nicht in den smart ohne dachträger passen und man, wenn man möbel transportieren will, sinnvollerweise den LKW nehmen sollte.

wenn wir schon bei fahrzeugvergleichen sind. :tongue:

[Gipsel]

LKWs (Teslas und FirePros) stehen ja gar nicht zur Disposition. :tongue:

[Skysnake]

Vor allem ist eben eine APU in gewissen Szenarien sowohl schneller als nen dicker Quad/Octa Core, als auch schneller als nen Gespann aus CPU und dGPU. Im Zweifelsfall kann man die dGPU nämlich gar nicht nutzen, einfach weil der Transferoverhead einem das Genick bricht.

Und von Energieeffizienz von ich erst gar nicht an :ugly:

Genau hier liegt aber die Stärke und auch das Ziel bei HSA. Energie sparen, indem man die Funktionseinheit nimmt, die etwas am sparsamsten erfüllt. Ob die dabei eventuell am Ende vielleicht nen taken langsamer oder schneller ist, ist apriori nicht klar. Im Zweifel nimmt man halt einfach mehr der Rechenknechte.

PS:
Bei dem Vergleich musste ich schon sehr schmunzeln :biggrin:

[Botcruscher]

Er trifft es aber ganz gut. Der Vorteil für den Homeuser ist bei seinem Anwendungsgebiet einfach nicht gegeben. Da fehlt einfach die Killeranwendung. Ob ein Video da doppelt so schnell codiert wird spielt keine Rolle. Ich wüsste eh nicht wer das macht. Die Masse zieht sich ihre Videos einfach von Youtube. Da limitiert dann eh was anderes.
Der einzig positive Punkt: es ist irgendwie gratis und wenn man damit schon nix anfangen kann, so stört es auch nicht. Der Dachträger ist also eh auf dem Smart, er braucht damit nicht mehr Sprit und Übermorgen könnte ich vielleicht damit eine Waschmaschine transportieren. Ein Anhänger(dGPU) samt SUV wäre trotzdem besser geeignet.

[Skysnake]

Wie gesagt, man fängt halt unten rum an, was für den Mobilebereich doch sehr sehr sehr gut ist, und genau da wird heute eben viel Geld gemacht.

AMD hat begrenzte Ressourcen und auf der anderen Seite 2 Konsolendeals, die praktisch genau! in diese High-End-APUs schlägt, die er gern hätte. Ich kann mir bei bestem Willen nicht vorstellen, das Sony und MS das zulassen würden, dass etwa zu gleichen Zeit wie ihre Konsolen Desktop-Chips kommen die deren Konsolen in die Tasche stecken.

Da hätte AMD nie den Deal bekommen. MS und Sony wollen ja ihre Konsolen erstmal verkaufen und einen Kundenstamm aufbauen.

[Botcruscher]

WARUM sollten Sony oder MS damit ein Problem haben? Kann ich auf einem PC mit 256MB RAM Skyrim spielen? Konsolen leben von der Software(Optimierung). Die Hardware ist Mittel zum Zweck. Ein PC wird dagegen immer flexible Brutforce belieben.

[LadyWhirlwind]

Ist die Systemarchitektur bei der Xbox Infinity schon gesichert?

@Skysnake Kommt immer darauf an, wie sehr Sony und MS dabei auf bestehende AMD-Technologien zurück greifen. Es ist ein Unterschied ob AMD die Tech exklusiv für Sony entwickelt hat, oder ob Sony als auftraggeber noch ein paar Optimierungen für Konsolen an ihrem Chip für die PS4 veranlasst hat. Im ersten Fall wäre die Technologie Sony, in dem Fall hätten sie die ganzen Entwicklungskosten dafür zu tragen, eher unwahrscheinlich. Im zweiten Fall gehört die Tech AMD und dann kann AMD damit machen was die wollen. Für jegliche längerdauernde exklusivität müsste Sony und MS dann viel bezahlen. Glaub ich eher nicht daran, möglich das AMD Sony und MS ein marketingfenster eingeräumt hat, wo sie die neue Konsolentechnik bewerben können ohne das AMD Trittbrettfahrer spielt.

[FeuerHoden]

Sobald die Leistung da ist werden die Anwendungen schon kommen. Ein P4 ist heute zu langsam um eine überladene Webseite anzuzeigen, ein Athlon geht bei Youtube Videos in die Knie, aber ich kann mir von den Leuten anhören 'Das ist doch nur Internet das braucht doch keine Leistung, dafür kann doch der Computer nicht zu schwach sein ...'
Dann gibts auf Youtube in Zukunft eben 3D Videos in Full HD auf einer WebGL Oberfläche mit AA+AF und dem ganzen Kram.
Entwickler sind immer am kreativsten wenn es darum geht unnötig Leistung zu verbraten.

[HPVD]

hab da mal ne Frage:

was genau ist der Unterschied zwischen dem "hUMA" von AMD welches ja früher oder später auch für diskrete GPUs genutz werden soll
vgl: http://www.heise.de/newsticker/meldu...o-1850975.html

und dem Nvidia für Maxwell angekündigten "unified virtual memory" ?

geht der Ansatz von AMD & Co (HSA) weiter als der von Nvidia oder ist beides bei Nutzung einer diskreten GPU sehr ähnlich?

[hatte gleiches auch im Maxwell Spek Forum gefragt aber noch keine Antwort erhalten...]

[S940]

Ähm doch :ugly:

Natürlich bezieht sich das auch auf die Latenzen. Man bezieht sich da ja nur darauf, wie auf den Speicher zugegriffen wird. Also ob auf den Speicher sich die Zugriffe unterscheiden. Wie das dann im Detail realisiert ist ist ja egal.
Ne, wenn die Latenzen wichtig wären, dann dürfte AMD das im APU-Beispiel nicht NUMA nennen, dort sind die Latenzen schließlich gleich, da der gleiche DRAM-Kontroller benutzt wird. Die fassen den NUMA begriff einfach allgemeiner auf als Du. Ja die Latenzen können auch ein Grund für "uneinheitlich" sein, aber das meinen sie nicht, das wär schon wieder zu speziell.
Mit NUMA hab ich da doch gar kein Problem, sondern mit der Aussage zum shared Memory/Addresspace. Das kannste eben auch auf NUMA und sogar auf distributed Memory Systemen realisieren. Da gibt es ja die wildesten Kombinationsmöglichkeiten, die es eigentlich auch alle schonmal gab.Ach soherum, ja das ist auch etwas komisch, wobei ich mich frage, ob man für den gemeinsamen Adressraum dann nicht zwingend ccNUMA bräuchte. Ohne Kohärenz wär ein gemeinsamer Adressraum doch ziemlich nutzlos, oder nicht?
Eventuell sind sie da so spitzfindig und unterscheiden zw. ccNUMA und NUMA ... würde mich bei ner Marketingfolie nicht wundern. Einerseits verallgemeinert, andrerseits wieder total speziell... halt total unscharf. Hauptsache man hat was gesagt, was genau ist nebensächlich ...

[Skysnake]

Ne, wenn die Latenzen wichtig wären, dann dürfte AMD das im APU-Beispiel nicht NUMA nennen, dort sind die Latenzen schließlich gleich, da der gleiche DRAM-Kontroller benutzt wird. Die fassen den NUMA begriff einfach allgemeiner auf als Du. Ja die Latenzen können auch ein Grund für "uneinheitlich" sein, aber das meinen sie nicht, das wär schon wieder zu speziell.

Nein, NUMA vs. UMA bezieht sich nur! darauf, wie man auf den Speicher zugreift, also ob alle Prozessoren/Funktionseinheiten den RAM/Speicher gleich sehen, und zwar den gesamten Speicher, oder eben nicht.

Alles andere bezieht sich dann wieder auf sharedMemory, distributedMemory, unified Adressspace usw usw.

Naja, die APUs sind ja soweit ja auch schon eine UMA-Architektur, eben weil Sie nur einen DRAM Kontroller benutzen. Sie haben aber eben keinen gemeinsamen Adressraum, obowhl Sie auf die gleichen physikalischen Adressen zugreifen :freak:

Das ist bisher halt etwas "seltsam", und macht normal auch absolut keinen Sinn, aber die Entwicklung braucht halt ihre Zeit/Zwischenschritte, bis alles so funktioniert wies auch Sinn macht.


Ach soherum, ja das ist auch etwas komisch, wobei ich mich frage, ob man für den gemeinsamen Adressraum dann nicht zwingend ccNUMA bräuchte. Ohne Kohärenz wär ein gemeinsamer Adressraum doch ziemlich nutzlos, oder nicht?
Eventuell sind sie da so spitzfindig und unterscheiden zw. ccNUMA und NUMA ... würde mich bei ner Marketingfolie nicht wundern. Einerseits verallgemeinert, andrerseits wieder total speziell... halt total unscharf. Hauptsache man hat was gesagt, was genau ist nebensächlich ...
Die "hUMA" APUs sind eigentlich (N)UMA Architekturen (NUMA, eventuell weil die iGPU bevorzugt wird, aber darüber kann man sich streiten) mit Cachecohärenz, also ccUMA.

Der Knackpunkt bei den neuen hUMA APUs ist halt, dass Sie einen unified Adressspace haben, also nondistributed sharedMemory-Systeme sind. ;D

Eigentlich ist es ein SEHR klassischer Aufbau von Früher, nur eben alles auf einem DIE zusammengefasst.

Im Prinzip ist es so etwas wie früher SMP-CPUs, bei denen noch in der Nothbridge der Speichercontroller sitzt, und JEDE! CPU gleichberechtigt an die Northbridge/Controller angeschlossen ist.

[S940]

Nein, NUMA vs. UMA bezieht sich nur! darauf, wie man auf den Speicher zugreift, also ob alle Prozessoren/Funktionseinheiten den RAM/Speicher gleich sehen, und zwar den gesamten Speicher, oder eben nicht.Naja, "Speicher gleich sehen" geht ja nicht, da bisher ja 2 Speicherkontroller im Einsatz waren. Deswegen ist es kein UMA. Ist mMn schon einigermaßen ok, je nachdem wie streng man NUMA jetzt definiert.


Sie haben aber eben keinen gemeinsamen Adressraum, obowhl Sie auf die gleichen physikalischen Adressen zugreifen :freak:

Das ist bisher halt etwas "seltsam", und macht normal auch absolut keinen Sinn, aber die Entwicklung braucht halt ihre Zeit/Zwischenschritte, bis alles so funktioniert wies auch Sinn macht.
Ja schon kurios, aber GPUs hatten wohl andere Adressierungsmodelle.
Die "hUMA" APUs sind eigentlich (N)UMA Architekturen (NUMA, eventuell weil die iGPU bevorzugt wird, aber darüber kann man sich streiten) mit Cachecohärenz, also ccUMA.

Der Knackpunkt bei den neuen hUMA APUs ist halt, dass Sie einen unified Adressspace haben, also nondistributed sharedMemory-Systeme sind. ;D

Eigentlich ist es ein SEHR klassischer Aufbau von Früher, nur eben alles auf einem DIE zusammengefasst.

Im Prinzip ist es so etwas wie früher SMP-CPUs, bei denen noch in der Nothbridge der Speichercontroller sitzt, und JEDE! CPU gleichberechtigt an die Northbridge/Controller angeschlossen ist.
Ja, alles wie gehabt, da geb ich Dir absolut recht. Man muss nur das erste Schema (UMA) mit dem letzten (hUMA) in dem einen Bildchen vergleichen. Was ist da denn anders, außer, dass anstatt des x-ten CPU-Kerns jetzt halt eine GPU dranhängt? Nix ^^

Und "heterogen" ist ja auch nur ein feiner Begriff für "Mischmasch".

Wie war das eigentlich früher mit den exteren FPUs bei 386/387 und dann der Integration in die CPU? War das ein ähnlicher Schritt, gab es Parallelen oder hatten die FPUs damals überhaupt keine Speicherzugriffe?

[Skysnake]

Öhm...

Soweit ICH! das jetzt weiß, lasse mich aber GERN eines besseren belehren, hatte die dedizierten FPUs nur Register, in die man geschrieben hat. Das wars.

Bzgl Bildchen:
Genau das habe ich mir auch gedacht. Für solche Spitzfindigen diskussionen muss man eigentlich Bildchen zeichnen, und diese dann mit den Bildchen der Definition vergleichen, ansonsten vertut man sich da einfach verdammt schnell.

Es gibt einfach sehr sehr feine aber entscheidene Unterschiede im Detail zwischen UMA/NUMA.

Vor allem heute, da man eh nur noch alles mögliche Zusammengepancht hat, und kaum noch wirklich saubere Sachen, einfach weil man das "Beste" aus jeder Idee mitnehmen will. Das macht die Diskussion halt dann verdammt schwierig ;D

[Coda]

Die FPU hat auch FLD und FSTORE instructions, kann also sehr wohl von RAM lesen und schreiben. Ging aber durch den gleichen Memory-Controller.

Du musstest aber mit einer speziellen Instruction (FWAIT) auf die FPU warten um sicher zu sein, dass sie auch fertig war mit dem was du zuletzt abgeschickt hattest :freak:

[Skysnake]

Wieder was dazu gelernt :up:

Wobei ich mir das schon etwas umständlich vorstelle, wenn die FPU noch auf den RAM zugreifen konnte.

[Botcruscher]

Ein P4 ist heute zu langsam um eine überladene Webseite anzuzeigen, ein Athlon geht bei Youtube Videos in die Knie, aber ich kann mir von den Leuten anhören 'Das ist doch nur Internet das braucht doch keine Leistung, dafür kann doch der Computer nicht zu schwach sein ...'

Läuft mit einem 3200+@S754 bei meiner Mutter super und auch ein E-350/450 dürfte(wenn ein Kern gefordert wird) nicht wirklich schneller sein. Damit hätten wir Lowend abgedeckt. Alles was Intel als Pentium/I3 verkauft dürfte ein gutes Stück schneller sein.

[samm]

http://www.planet3dnow.de/cms/wp-content/gallery/hq/10amd-heterogeneous-q.png

Quelle mit mehr Folien zum Thema bei P3DN (http://www.planet3dnow.de/cms/4916-details-zu-amds-heterogener-verarbeitungsschlange/)

D.h. also, dass die beiden Komponenten ohne Umweg über's OS Tasks untereinander zuteilen können - entlastet die CPU direkt, die ansonsten diese Aufgabe hat, und indirekt, indem der Overhead (Scheduler, Treiber etc.) des Betriebssystems bei der Aufgabenzuteilung wegfällt. Auch kann die GPU direkt die CPU wieder ankicken - musste die CPU im alten Modell die GPU pollen, um herauszufinden, ob sie ihre Tasks schon fertig abgearbeitet hat, und ggf. noch Resultate aus dem Extra-Speicherbereich nachladen?

Scheint mir ein enormer Effizienzgewinn in der Zusammenarbeit zu sein, und eine ganz grundsätzliche Verbesserung der Integration.

Nun nur mal sehen, wie das abstrahiert und wie/ob es sich in der API auswirkt :) Und natürlich in Anwendungen...

[Skysnake]

Die GPU sollte eigentlich einen Interrupt auslösen können, wenn Sie fertig ist, aber keine Ahnung ob das auch gemacht wurde. Ich geh aber mal stark davon aus.

[Nakai]

Die GPU sollte eigentlich einen Interrupt auslösen können, wenn Sie fertig ist, aber keine Ahnung ob das auch gemacht wurde. Ich geh aber mal stark davon aus.

Mhh, wird da nicht direkt in nen Speicher reingeschrieben, obs fertig ist?
Die CPU müsste nur pollen. Bei irgendeinem PS4-Titel wurde es so gemacht. Drei Speicherbereiche, CPU, Shared, GPU. Gibts wohl mehrere Möglichkeiten...

Die FPU hat auch FLD und FSTORE instructions, kann also sehr wohl von RAM lesen und schreiben. Ging aber durch den gleichen Memory-Controller.


Du meinst die alte X87-FPU? Die ist schon etwas outdated, aber wird leider des öfteren noch benutzt...

Mit SSE und AVX wirds zum Glück anders gemacht.

[Lunica]

Und Videos/Musik Transcodieren ist ein typischer Anwendungsfall für den 0815 Anwender.




... Dem 0815 Anwender ist das aber egal wie lange dies dauert.
Der Amateur greift in die Börse und kauft sich dann eben bessere Hardware/Software.
Der Profi kann es sowieso abschreiben bzw. verschreibt es dem nächsten Kunden.

Außerdem geht es nicht immer nur um den Wandlungsprozess.
Die Cuda Unterstützung in Premiere beschleunigt primär die Echtzeitdarstellung.
Transcodiert wird wegen der Kompatibilität (Filter) über die CPU.
Spricht ja auch nichts dagegen.
Ich bin mir ziemlich sicher das Adobe keinen Millimeter Notiz von APUs nehmen wird.
Sind einfach irrelevant für den Amateur bis Profi Bereich.
Des weiteren haben Kern-Programme wie After Effects sehr alte Strukturen die nicht einfach geändert werden können.

Und wie ein extrem Intel CPU lastiges Spiel wie Planetside 2 auf der "Jaguar" AMD APU der PS4 laufen wird... Na das muss sich erst noch in Benchmarks zeigen. Ich bin mir ziemlich sicher - Nicht gut.