AMD Developer Summit 2013

[HarryHirsch]

Ab dem 11.11 findet die AMD Developer Summit 2013 (http://developer.amd.com/apu/home/agenda-sessions/) statt.
Themen sind unter anderem:


Mantle
TressFX 2.0
Bullet 3 OpenCL Rigid Body Simulation


und vieles mehr. Sean Tracy von Crytek ist auch vor Ort und erzählt was über “Project Phoenix”.

[Iruwen]

Warum erzählt kursiv?

[x-dragon]

Da ich mit Project Phönix so spontan nichts anfangen konnte, hab ich mir da mal was rausgesucht:

http://www.crytek.com/download/Project%20Phoenix.pptx

[fondness]

Das Ding heißt APU13 :)

Topics and presentation times are as follows:

4:00 - 5:00 p.m. (PST), Monday, November 11:
Lisa Su, senior vice president & general manager, Global Business Units, AMD: "Developers: The Heart of AMD Innovation"
Phil Rogers, corporate fellow, AMD: "The Programmers Guide to Reaching for the Cloud"
8:30 - 9:30 a.m. (PST), Tuesday, November 12:
Mike Muller, CTO, ARM: "Is There Anything New in Heterogeneous Computing?"
Nandini Ramani, vice president, Java Platform, Oracle Solutions: "The Role of Java™ in Heterogeneous Computing, and How You Can Help"
1:15 - 2:15 p.m. (PST) Tuesday, November 12:
Dr. Chien-Ping Lu, senior director, Mediatek USA: "How Many Cores Will We Need?"
Tony King-Smith, executive vice president, Marketing, Imagination Technologies: "Silicon? Check. HSA? Check. All done? Wrong!"
8:30 - 9:30 a.m. (PST), Wednesday, November 13:
Dominic Mallinson, senior vice president, Software, Sony: "Inside PlayStation 4: Building the Best Place to Play"
Brendan Iribe, CEO, Oculus VR: "Virtual Reality - A New Frontier in Computing"
1:15 - 2:15 p.m. (PST) Wednesday, November 13:
Johan Andersson, technical director, DICE: "Rendering Battlefield 4 with Mantle"
Mark Papermaster, CTO, AMD: "Powering the Next Generation Surround Computing Experience"


http://ir.amd.com/phoenix.zhtml?c=74093&p=irol-newsArticle&ID=1871035&highlight=

[y33H@]

Das Ding heißt ebenfalls AMD Developer Summit 2013 ;-)

[samm]

http://ir.amd.com/phoenix.zhtml?c=74093&p=irol-newsArticle&ID=1871035&highlight=Das ist bei Weitem nicht das ganze Programm, sondern nur das, was sie offenbar für Investoren relevant finden... (die Keynotes)

Die ganzen technisch spannenden Dinge findet man hier: http://developer.amd.com/apu/home/agenda-sessions/
HSA-Infos auf diversen Ebenen und optimierte Algorithmen, Compiler, OpenCL (Cuda2OpenCL ;) ) etc. pp.

[HarryHirsch]

WTF! Das hab ich noch gar nicht gesehen.

edit:

Also dieses CU2CL.

[Skysnake]

Ist eigentlich schon länger überfällig. Sowas in der Art hatte auch nVidia mal angekündigt, man hörte dann nur nie wieder etwas davon.

Im Prinzip ist das ja auch "nur" eine Mappinggeschichte, solange man die Sourcen hat.

Mit Bytecode wirds natürlich ungleich komplizierter.

[Coda]

Mit Bytecode wirds natürlich ungleich komplizierter.
Wieso? Sieht halt der generierte OpenCL-Code aus wie Assembler, spielt doch keine Rolle.

[Nakai]

Ist eigentlich schon länger überfällig. Sowas in der Art hatte auch nVidia mal angekündigt, man hörte dann nur nie wieder etwas davon.

Im Prinzip ist das ja auch "nur" eine Mappinggeschichte, solange man die Sourcen hat.

Mit Bytecode wirds natürlich ungleich komplizierter.

Naja CUDA ist vom Techlevel über OpenCL 1.2 derzeit. Eher auf OpenCL 2.0. Ich hoffe auf eine Ankündigung von OpenCL 2.0 für GCN-Architekturen.:)

[Skysnake]

Wieso? Sieht halt der generierte OpenCL-Code aus wie Assembler, spielt doch keine Rolle.
Die Analyse wo wann wie Speicher allociert wird usw wird aber aufwändiger.

Genau so auch die Analyse ob jetzt mit Multithread nicht eventuell Daten verändert wurden usw.

Das Ausführungskonzept ist ja apriori nicht gleich. CUDA ist ja eigentlich blockierend. OpenCl eigentlich nicht blockierend.

Oder war es jetzt genau umgekehrt? und AMD macht nur blockierende Aufrufe sstandardmäßig :confused:

[Coda]

WTF? Das hat doch alles nix mit dem Bytecode zu tun. Das müsste natürlich die CUDA-Runtime übernehmen die man ersetzen muss.

[Skysnake]

Ja und was machen Compiler?

Richtig, die sortieren freudig Sachen um, machen vielleicht hier nen bischen inline, oder auch da ein bischen inline, und wie unterscheidest du dann woher was genau kommt?

Gerade beim inlinen von irgendwelchen CUDA Calls, keine Ahnung was die genau alles machen, holste dir doch schneller irgendwelche Speicherlecks als alles andere.

Mit den API-Calls kannste das alles einfach mappen, man weiß ja was es machen soll, aber beim fertig compilierten und gelinkten? Da musste ja erstmal schauen, was nVidia wann wo wie macht, und wenn Sie was ändern, musst du das auch einpflegen...

Also ich will sowas nicht warten müssen :ugly:

[Gipsel]

Aber das passiert doch alles auf CPU-Seite, wieso sollte es da mit einem Mal größere Probleme geben? Schwieriger könnte es werden, wenn es keine genaue OpenCL-Entsprechung gibt. Und CUDA erlaubt ja auch bestimmte Intrinsics im GPU-Code, die man dann in OpenCL irgendwie nachbilden müßte, was unter Umständen performancekritisch sein kann.

[Skysnake]

Mir gehts es rein ums erkennen.

Klar, man kann das alles nachbilden, und auch erkennen, es ist eben nur mit den Sourcen EINFACHER.

Ich erwarte nicht, das man fix und fertic compilierte CUDA-Software einfach durch nen wrapper jagen wird können um das Zeug dann halbwegs performant auf OpenCL Hardware aus zu führen.

[Coda]

Ja und was machen Compiler?

Richtig, die sortieren freudig Sachen um, machen vielleicht hier nen bischen inline, oder auch da ein bischen inline, und wie unterscheidest du dann woher was genau kommt?

Gerade beim inlinen von irgendwelchen CUDA Calls, keine Ahnung was die genau alles machen, holste dir doch schneller irgendwelche Speicherlecks als alles andere.

Mit den API-Calls kannste das alles einfach mappen, man weiß ja was es machen soll, aber beim fertig compilierten und gelinkten? Da musste ja erstmal schauen, was nVidia wann wo wie macht, und wenn Sie was ändern, musst du das auch einpflegen...

Also ich will sowas nicht warten müssen :ugly:
Speicherlecks durch Compiler-Umsortierungen im Host-Code? Was rauchst du eigentlich?

Für die große Klappe die du immer an den Tag legst ist das mal wieder echt harter Tobak.

[fondness]

Erste Infos:

APU13: HSA-Entwicklerplattformen erst Anfang 2014 verfügbar (http://www.planet3dnow.de/cms/5546-apu13-hsa-entwicklerplattformen-2014/)
APU13: AMD zeigt Battlefield-4-Demo auf Kaveri (http://www.planet3dnow.de/cms/5544-apu13-amd-zeigt-battlefield-4-demo-auf-kaveri/)
APU13: APUs für die Datenwolke, Videocodierung, JAVA, C++ AMP für Linux und mehr (http://www.planet3dnow.de/cms/5501-apu13-apus-fuer-die-datenwolke-videocodierung-erdoelfeld-erforschung-java-und-c-amp-fuer-linux/)
APU13: Hewlett-Packard bringt Moonshoot-Prozessorkarte mit Kabini-Opterons (http://www.planet3dnow.de/cms/5496-apu13-hewlett-packard-bringt-moonshoot-prozessorkarte-mit-kabini-opterons/)
APU13: Kaveri mit 856 GFLOPS laut AMD ab 14. Januar im Laden erhältlich (http://www.planet3dnow.de/cms/5452-apu13-kaveri-mit-856-gflops-laut-amd-ab-14-januar-im-laden-erhaeltlich/)

[y33H@]

Es kann sich jeder bei APU365 anmelden, wo es alle Slides gibt.

https://vts.inxpo.com/scripts/Server.nxp?LASCmd=AI:4;F:QS!10100&ShowKey=16356

[S940]

Schließe mich dem Sonyvortragsurteil aus dem Mantle-Thread an, das war bisher die dümmste Veranstaltung.
Redet der Typ über den PS1-Kontroller und das CD-ROM Laufwerk der PS2 ... ne ne ne ...

Ich dachte sie würden den SoC zeigen und dann so ne Zeitverschwendung ...

[Akkarin]

Srsly: gibs das ganze irgendwo auch in annehmbarer Qualität ?

[S940]

APU13: Beema beerbt Kabini | Planet 3DNow! (http://www.planet3dnow.de/cms/5694-apu13-beema-beerbt-kabini/).

[Nakai]

Da steht kein HSA...mehr. Wehe die haben das rausgekickt. :freak:

[S940]

Da steht kein HSA...mehr. Wehe die haben das rausgekickt. :freak:
Wo? bei Beema? Ja der hat (immer) noch kein HSA, siehe P3D-News am Ende. Wir haben extra nachgefragt.

[Nakai]

Wo? bei Beema? Ja der hat (immer) noch kein HSA, siehe P3D-News am Ende. Wir haben extra nachgefragt.

Verdammt...vor wenigen Monaten hieß es noch "mit HSA-Support".

Sieht einfach wie ein optimierter Kabini aus. Nicht mehr CUs oder andere gravierende Änderungen. Wahrscheinlich werden Teile des SOCs auf Energiesparen getrimmt. Dazu noch 28HPM oder einen anderen optimierten 28nm-Prozess(was hatte Kabini/Temash?).

[S940]

Verdammt...vor wenigen Monaten hieß es noch "mit HSA-Support".
Hm wo hieß es das? Das waren wenn, dann nur Spekulationen. Ein starkes Argument dagegen war schon das Nicht-nennen von HSA bei Steppeeagle, dem embedded Cousin von Beema.
Sieht einfach wie ein optimierter Kabini aus. Nicht mehr CUs oder andere gravierende Änderungen. Wahrscheinlich werden Teile des SOCs auf Energiesparen getrimmt. Dazu noch 28HPM oder einen anderen optimierten 28nm-Prozess(was hatte Kabini/Temash?).Jupp der Kern wird gleich bleiben, entweder RCM dazu oder ein besserer Prozess.
Was Kabini hatte weiss man nicht genau, nur TSMC 28nm, kA ob HP oder HPM :(

Edit: Genaueste Info war die hier:
http://www.planet3dnow.de/photoplog/file.php?n=23133&w=o

Bei Beema wäre mit der deutlichen Perf/Watt-Steigerung auch wieder FD-SOI im Rennen, aber RCM plus Feintuning ist wahrscheinlicher.

[StefanV]

Bei Beema wäre mit der deutlichen Perf/Watt-Steigerung auch wieder FD-SOI im Rennen, aber RCM plus Feintuning ist wahrscheinlicher.
Nach den ganzen Infos zur 'Zusammenarbeit' mit IBM würd ich eher meinen, dass wir uns SOI aus dem Kopf schlagen sollten. Das wird AMD nie wieder verwenden wollen, IBM sei dank...

[S940]

Nach den ganzen Infos zur 'Zusammenarbeit' mit IBM würd ich eher meinen, dass wir uns SOI aus dem Kopf schlagen sollten. Das wird AMD nie wieder verwenden wollen, IBM sei dank...

Absolute Zustimmung (eigentlich) .. aber ich hab gerade nen anderen Zusammenhang entdeckt .. der Mullins mit 4,5W hat fast den gleichen PCMark8-Benchmarkwert wie der Kabini @25W :freak:

Weitere Diskussion besser im Beema-Thread, Duplex hat den ausgegraben:
http://www.forum-3dcenter.org/vbulletin/showthread.php?p=10001754#post10001754