Tim Sweeney - End of the GPU Roadmap

[AnarchX]

Abstract: "Mainstream GPUs emerged 12 years ago and rapidly evolved from fixed-function graphics accelerators to semi-programmable computing devices. The speaker will argue that the GPU roadmap is now coming to an end, and that future PCs and game consoles will be powered by general computing devices, utilizing multi-core vector-processing units to run all code, graphics and non-graphics, uniformly, at Teraflop performance levels. He'll then give an overview of the design dimensions impacting such an architectures, such as caches, threads, vector sizes, and programming models."

http://graphics.cs.williams.edu/archive/SweeneyHPG2009/

Ein wirklich interessanter Vortrag der einen Blick auf die Richtung geben könnte, in welche sich die UE in Zukunft bewegen könnte und mit dieser dann wohl auch der Markt für "Grafikprozessoren".

[Exxtreme]

Ich glaube, es ist noch nie das eingetreten was Sweeny prophezeiht hat.

[Mordred]

GPUs sind für viele CPU Aufgaben immernoch vollkommen ungeeignet wie stellt der sich das vor?

[Aquaschaf]

Halte ich für unrealistisch. Ein heterogenes Rechnermodell mit ein paar monolithischen Cores und einer großen Anzahl an einfachen Cores ergibt viel mehr Sinn.

EDIT: auf den Folien sieht es überhaupt nicht so aus als würde er suggerieren was im Abstract steht - "future PCs and game consoles will be powered by general computing devices, utilizing multi-core vector-processing units to run all code, graphics and non-graphics, uniformly, at Teraflop performance levels".

Da steht kaum was interessantes drinnen und nichts was mir neu wäre.

[Demirug]

Ich glaube, es ist noch nie das eingetreten was Sweeny prophezeiht hat.

Wenn es um das Thema Software Rasterizer geht da verliert Sweeny irgendwie immer den Blick für die Realität.Irgendwie sind es immer nur „noch“ 5 Jahre bis dorthin.

Zudem schwingt in seinen Vorträgen eben auch immer unterschwellig Werbung für die Unreal Engine mit.

[Nighthawk13]

Passt hier grad schön rein: "Rasterization on Larrabee"
http://www.ddj.com/hpc-high-performance-computing/217200602

Nach "Bauchgefühl" würd ich sagen, das fixed-function Rasterisierung schneller ist(und es sich lohnt, Fläche auf dem Chip-die dafür zu opfern).

[Nakai]

Ka, wieviel ein Rasterizer an Fläche und Transistoren frisst, aber es sollte doch möglich sein, diesen irgendwann einfach zu integrieren. Es sollte doch nicht soviel Aufwand sein einen Rasterizer in eine CPU zu integrieren.


mfg Nakai

[AnarchX]

Ein Rasterizer muss aber auch mit der Rohleistung der GPU skaliert werden, bei G200 hat man das wohl aber etwas vernachlässigt.

[StefanV]

Naja, mit dem Punkt, das die GPUs gar keine mehr sind sondern mehr kleine, schnelle Recheneinheiten und das das mehr Richtung CPU gehen wird, die also flexibler werden, da stimme ich mal zu, aber das alles auf der GPU laufen werden wird??
I don't think so...

Klar KI und Physik sicherlich, aber die CPU muss ja auch noch was bekommen ;)

[Crazy_Chris]

Wär mal interessant zu wissen wie Crytek dazu steht. :tongue:

[HOT]

Es ist ja eher so, dass die CPU irgendwann GPU-Funktionen in ihrer FPU integrieren könnte, sodass man darüber einen IGP laufen lassen kann und natürliche GPGPU-Funktionen. Aber das wird ganz sicher kein Ersatz für eine High-End-GPU sein. Das wäre schon bei der Abwärme und Die-Grösse ein Problem.

[StefanV]

Öhm, Fusion? ;)
Deswegen sagte ich woanders, das ich solche Teile richtig toll find, sofern man nur die Grafikeinheit (=TMUs) abschalten kann, den Rechenteil aber weiter nutzen kann.

Wo wir gerade dabei sind, SSE5 bzw AVX ist doch etwas, das in diese Richtung geht, oder??

[Avalox]

Aber das wird ganz sicher kein Ersatz für eine High-End-GPU sein. Das wäre schon bei der Abwärme und Die-Grösse ein Problem.

Und du meinst, dass sich noch jemand für High End GPUs interessiert, wenn schon in der CPU eine GPU Funktionalität steckt?
High End GPUs, welche dann sogar noch durch die Trennung von der CPU oftmals echte Nachteile zur CPU Lösung haben werden?

Wo sind denn die High End FPUs heute?

[[fu]121Ah@work]

jedes jahr dieselbe aussage von ihm. gähn.

[Coda]

Im Endeffekt wird er aber recht behalten. Crytek und id Software haben schon sehr ähnliche Talks gehalten.

Dabei geht es auch nicht unbedingt darum dass CPUs und GPUs zusammengeführt werden, sondern darum den Streamprozessor (= GPU) direkt zu programmieren.

[Fetza]

Und du meinst, dass sich noch jemand für High End GPUs interessiert, wenn schon in der CPU eine GPU Funktionalität steckt?

Öhm, kommt das nicht ganz darauf an, wie leistungsfähig diese gpu funktionen der cpu sind? Ich hab ja keine ahnung von sowas, aber ist es nicht sehr unwarscheinlich, das man einer cpu gleich die selbe leistungsfähigkeit bezüglich grafikberechnug verleihen kann, wie sie aktuelle high-end gpus besitzen?

Ich meine das jetzt auf absehbarer zeit, sweeney spricht ja ungefähr von 2012/13.

[Avalox]

Öhm, kommt das nicht ganz darauf an, wie leistungsfähig diese gpu funktionen der cpu sind? Ich hab ja keine ahnung von sowas, aber ist es nicht sehr unwarscheinlich, das man einer cpu gleich die selbe leistungsfähigkeit bezüglich grafikberechnug verleihen kann, wie sie aktuelle high-end gpus besitzen?


Es gibt mehrere Ebene der Betrachtung.

Es geht ja bei der Diskussion nicht um die primäre Leistungsfähigkeit, als vielmehr den Wandel der Philosophie des Ansatzes.

Eine GPU, oder GPGPU wurschtelt heute mehr oder weniger angeschlossen in seiner Umgebung eben der Grafikkarte selbsständig umher. Dort ist die GPU spezialisiert, aber eben auch eingeschränkt.

Die Anbindung an eine CPU bedeutet dort nicht nur die Flexibilisierung in der Nutzung der Ressourcen, es bedeutet auch eine starke Rationalisierung.

Eine Rationalisierung, welche von Softwareentwicklern genutzt werden kann, um kostengünstiger Ergebnisse zu produzieren, aber eben auch eine Rationalisierung welche von Systemdesignern genutzt werden kann um günstigere Systeme zu entwickeln.

Die CPU mit der GPU zu verbinden ist eine Rationalisierungsmaßnahme erster Güte. Dort kann man nicht rechnen, dass es was vergleichbares wie heutige High End Lösungen in Zukunft geben wird. Auch wenn die konkreten Produkte natürlich mehr zustande bringen, als heutige Lösungen, da ja die Entwicklung voran geschritten ist. Bis es soweit ist, wird es noch einige Zwischenschritte geben.

[Monger]

Dabei geht es auch nicht unbedingt darum dass CPUs und GPUs zusammengeführt werden, sondern darum den Streamprozessor (= GPU) direkt zu programmieren.
Klar, der Trend wird natürlich anhalten. Aber bis man dort vom Befehlssatz und der Architektur her die Flexibilität einer CPU hat, werden noch ein paar Jährchen vergehen.

Das größte Problem imho ist immer noch, dass wir softwaremäßig immer noch nicht so weit sind, hochparallelisierte Software gescheit zu schreiben. Das ist derzeit immer noch ein Gefrickel. Solange die Tools nicht besser werden, nützt auch eine flexiblere Hardware nur wenig.

[Avalox]

Das größte Problem imho ist immer noch, dass wir softwaremäßig immer noch nicht so weit sind, hochparallelisierte Software gescheit zu schreiben. Das ist derzeit immer noch ein Gefrickel. Solange die Tools nicht besser werden, nützt auch eine flexiblere Hardware nur wenig.

Na ich denke, dieses ist doch das Betätigungsfeld, wo sich Tim Sweeney mit seiner Unternehmung in Zukunft genau sieht. Er möchte doch genau die Middleware liefern, welche kostengünstig die Entwicklung erlaubt indem sich der Entwickler auf seine Kernkompetenz eben den Inhalt konzentriert. Abseits jedes weiteren Eintauchens in den Compiler, Lieferant von sehr abstrahierten Lösungen.

Ich frage mich, wie sich ein Microsoft mit DirectX in solch einer Welt sieht?

[Demirug]

Na ich denke, dieses ist doch das Betätigungsfeld, wo sich Tim Sweeney mit seiner Unternehmung in Zukunft genau sieht. Er möchte doch genau die Middleware liefern, welche kostengünstig die Entwicklung erlaubt indem sich der Entwickler auf seine Kernkompetenz eben den Inhalt konzentriert. Abseits jedes weiteren Eintauchens in den Compiler, Lieferant von sehr abstrahierten Lösungen.

Streiche das kostengünstig. Es ist ein weit verbreiteter Irrglaube das man durch den Einsatz einer lizenzierten Engine Geld spart.

Ich frage mich, wie sich ein Microsoft mit DirectX in solch einer Welt sieht?

Genau da wo sie sich jetzt auch sehen. DirectX ist ein Satz von vereinheitlichten Schnittstellen für Hardware welche dem gleichen Zweg dient aber nicht binär kompatibel ist.

[Monger]

Na ich denke, dieses ist doch das Betätigungsfeld, wo sich Tim Sweeney mit seiner Unternehmung in Zukunft genau sieht.

In dem Feld wird schon seit 30 Jahren hin- und her entwickelt - bisher imho mit wenig Erfolg. Das heißt natürlich nicht dass sich das nicht mal ändern könnte, aber derzeit fehlt mir da schlicht die Fantasie wie das konkret aussehen soll. Da können noch einige Jahrzehnte ins Land ziehen, bis da entsprechende Konzepte greifbar sind.



Ich frage mich, wie sich ein Microsoft mit DirectX in solch einer Welt sieht?
Die haben doch schon vor langer Zeit angekündigt, dass sie früher oder später in DirectX davon weg wollen, Aufgaben nur an bestimmte Hardware zu binden. Ob jetzt z.B. der Sound von der Soundkarte, der CPU oder gar der Grafikkarte gerendert wird, soll eines fernen Tages irgendwann mal ein Scheduler entscheiden. Das wäre z.B. bei Docking Stations ganz interessant: solange das Notebook eingedockt ist, läuft halt alles auf Sparflamme über die CPU, und sobald man eindockt könnte man diese oder jene dedizierte Hardware nutzen.

Noch ist das Zukunftsmusik, aber imho würde so ein Scheduler eine Spezialisierung der Hardware eher begünstigen denn reduzieren. Eine eierlegende Wollmilchsau kann halt in aller Regel alles gleichermaßen schlecht.

[Avalox]

Streiche das kostengünstig. Es ist ein weit verbreiteter Irrglaube das man durch den Einsatz einer lizenzierten Engine Geld spart.


Dort wird man wohl dem Risiko ein € Zeichen anhängen und so Geld sparen.


Genau da wo sie sich jetzt auch sehen. DirectX ist ein Satz von vereinheitlichten Schnittstellen für Hardware welche dem gleichen Zweg dient aber nicht binär kompatibel ist.

Na, ja. Ist dort dann nicht eine Framebuffer Schnittstelle, das letzte was übrig bleibt zumindest auf der Seite der Grafikschnittstelle?


Die haben doch schon vor langer Zeit angekündigt, dass sie früher oder später in DirectX davon weg wollen, Aufgaben nur an bestimmte Hardware zu binden. Ob jetzt z.B. der Sound von der Soundkarte, der CPU oder gar der Grafikkarte gerendert wird, soll eines fernen Tages irgendwann mal ein Scheduler entscheiden. Das wäre z.B. bei Docking Stations ganz interessant: solange das Notebook eingedockt ist, läuft halt alles auf Sparflamme über die CPU, und sobald man eindockt könnte man diese oder jene dedizierte Hardware nutzen.


Mit der dedizierten Lösung von Intel/AMD wird es doch sicherlich definierte Befehlserweiterungen geben.
Es ist doch nicht so, dass im zukünftigen PC ein Sack voll von Komponeten steckt, welche allesamt multifunktional das selbe, nur in unterschiedlicher Ausprägung machen. Das ist nicht effizient, auch nicht unter Kostengesichtpunkten und wird mittelfristig verschwinden.
Vielmehr wird es eine Diversifizierung unterschiedlicher Plattformen und deren Varianten geben. Dieses wird sich mit entsprechenden Libraries sicherlich handhaben lassen.

Die Frage ist doch wie viel Funktionalität, wird sich ausserhalb des Schnittstellenbedienung noch im Produkt befinden? Wird es MS schaffen, so wie heute im Ansatz eigene Middleware Funktionalität im Deckmantel in einer ganzheitlichen Lösung zu transportieren?

[Gast]

Im Endeffekt wird er aber recht behalten. Crytek und id Software haben schon sehr ähnliche Talks gehalten.

Dabei geht es auch nicht unbedingt darum dass CPUs und GPUs zusammengeführt werden, sondern darum den Streamprozessor (= GPU) direkt zu programmieren.Damit wären wir ja wieder beim Amiga? ;)

Ist schon interessant. Mal werden Zwischenlayer gelobt, mal nieder gemacht. Mal ist NET gut, mal ist es lahm, mal DX, dann wieder nicht mehr in dieser Form.

Ich glaub viele von diesen ganz neuen Ideen müßen nur her, damit sich Betriebssysteme und Hardware weiter toll verkaufen oder die jeweiligen Hersteller den anderen ihre Marktanteile abjagen können um an der Börse weiterhin mit Zuwachsen auszuschütten. Viel zu selten hat der ganze Mumpitz direkt etwas mit besserer Technik und klaren Vorteilen für den Kunden zu tun.

[Demirug]

Na, ja. Ist dort dann nicht eine Framebuffer Schnittstelle, das letzte was übrig bleibt?

Glaubst du ernsthaft das sich die ganzen IHV auf eine einzige ISA einigen?

[Chris Lux]

die keynote von sweeney war wirklich nichts besonderes. ich empfand sie eher als heuchlerisch, weil er auf der einen seite von ökonomischer entwicklung sprach und eben voll auf konsolen konzentriert ist bei denen auch die nächste generation nichts von seinen ach so tollen ideen umsetzen können wird. auf der anderen seite eben spricht er über sehr interessante rendering verfahren, die wie gesagt in absehbarer zeit niemals auf epics zielplattformen laufen werden. denn ich bin mir 100% sicher, dass neue konsolen auch wieder nichts besonderes darstellen werden, einfach aus dem kosten/nutzen verhältnis heraus.

vor allem wollte er REYES wieder mal puschen. war zu witzig...

[Avalox]

Glaubst du ernsthaft das sich die ganzen IHV auf eine einzige ISA einigen?

nö, ganz sicher nicht auf eine, aber auf maximal drei. Denn mehr Hersteller fallen mir nicht ein.

[Monger]

Es ist doch nicht so, dass im zukünftigen PC ein Sack voll von Komponeten steckt, welche allesamt multifunktional das selbe, nur in unterschiedlicher Ausprägung machen. Das ist nicht effizient, auch nicht unter Kostengesichtpunkten und wird mittelfristig verschwinden.
Ich sehe zumindest mal zwei Nischen die imho fast unvereinbar sind. Ich nenne sie einfach mal "Multi purpose" und "Masse statt Klasse".

Multi Purpose heißt: du brauchst irgendwas, was grundsätzlich mal mit jeder Form von Problem umgehen kann - egal wie abwegig und selten es ist. Manche Befehle im x86 Befehlssatz sind ganz schön exotisch - trotzdem sind sie notwendig, und es müssen dafür Transistoren verbraten werden. Performance spielt da nicht so sehr eine Rolle als schlicht Machbarkeit.

"Masse statt Klasse" steht für all die Aufgaben, die aufgrund ihrer puren Masse auf Performance gedrillt werden müssen. Das sind meistens recht einfache Operationen - aber davon halt etliche Millionen. Deshalb sind hochspezialisierte Lösungen wie z.B. starke Parallelisierung wichtig.

Beide Ansätze sind imho kaum vereinbar. Du brauchst beides. Manche informationstechnische Probleme sind leicht zu berechnen, aber schwer zu beschreiben, andere wiederum leicht zu beschreiben und schwer zu berechnen. Weder lohnt es sich für eine GPU alle x86 Befehle zu implementieren, noch eine CPU auf hunderte von Kernen zu verteilen.

[Avalox]

Weder lohnt es sich für eine GPU alle x86 Befehle zu implementieren, noch eine CPU auf hunderte von Kernen zu verteilen.

Das wird man genau aber machen. Man wird die CPU auf hunderte von Kerne verteilen und alle x86 Befehle implementieren. Die Kerne werden spezialisierte Aufgaben haben, Befehlssatz ist eh abstrahiert.
Und alles wird sich auf einem Siliziumträger eines Herstellers befinden und dieses ist der wahrlich entschiedenste Punkt von allen.

Wie viele Transistoren hast du den heute im PC und wie verteilen sich diese?

Speicher, CPU, GPU, + weitere Steuerelekronik für Schnittstellen und Komponenten.

Hauptspeicher wird mittelfristig in die CPU wandern, kurzfristig auch die GPU. Schnittstellenanbindung wird auch in die CPU wandern. Festplatten werden gegen Flashspeicher ausgetauscht.

So produktiviert sich der Hersteller in Zukunft. SoC mit internen RAM und zusätzliche Produktivierung über die Fertigung von Flashspeicher.

Eine Hand voll von Bauteilen für einen PC und dieses aus einer Hand.

[Monger]

Hauptspeicher wird mittelfristig in die CPU wandern, kurzfristig auch die GPU. Schnittstellenanbindung wird auch in die CPU wandern. Festplatten werden gegen Flashspeicher ausgetauscht.

Daran zweifle ich (noch). Das würde drastische Fortschritte in der Fertigungstechnik erfordern. Die DIE Größen sind schon heute unverschämt groß, und schon die letzten beiden Strukturverkleinerungen hatten ganz schön Anlaufschwierigkeiten.

Natürlich wäre es eleganter, ein voll integriertes System aus einem Guss zu machen. Ich glaub aber trotzdem erst dran wenn ichs sehe. Der "Cell" geht ja schon in diese Richtung - und man hat ja gesehen was dabei für ein Exot rausgekommen ist.

[Gast]

Das wird man genau aber machen. Man wird die CPU auf hunderte von Kerne verteilen und alle x86 Befehle implementieren. Die Kerne werden spezialisierte Aufgaben haben, Befehlssatz ist eh abstrahiert.

Warum sollte man das auf Hardware Ebene abstrahieren? Auf Softwareebene bewegt sich alles Richtung Abstraktion per JIT-Compiling. Warum nicht das Instruktionmapping wie bei heuten GPUs schon üblich dort ins Backend schieben?

[[fu]121Ah@work]

Im Endeffekt wird er aber recht behalten. Crytek und id Software haben schon sehr ähnliche Talks gehalten.

Dabei geht es auch nicht unbedingt darum dass CPUs und GPUs zusammengeführt werden, sondern darum den Streamprozessor (= GPU) direkt zu programmieren.
deine ansicht und meinung in allen ehren - ich seh es nicht so.

wir gingen in den 90er jahren von der "unified" schiene weg, nicht ohne grund. den software renderer hatten wir schon mal, was passiert ist, als die ersten "proprietären" beschleuniger ala v1 rauskamen, kennt man ja.

die idee einer "unified" architektur die direkt programmiert wird, ist schön und gut, allerdings wird es dadurch nicht besser. gründe:

verschiedene hersteller verwenden verschiedene interne befehle. die eine architektur ist vielleicht für postprocessing schneller, die andere hat mehr rohpower. und dann, bring mir softwareentwickler die sowas coden können - wir wissen ja wie hoch die entwicklungskosten mit jedem neuen feature werden. tesselation? geil, aber... wie will er objektorientiert direkt nen chip programmieren? das ist geblubber, das zwar jedes jahr wieder amüsant ist, allerdings nicht viel handfestes dahinter steht.

ausser natürlich sein magisches raytracing ;) das mag ja ne lösung sein, aber es ist nicht die einzige lösung. hatte tausend diskussionen mit nem kumpel der C# codet und auch selbst gerne mal CUDA verwendet für irgendwelche spielereien. Er ist ein riesen fan von raytracing, aber ein argument stoppt das geblubber über viel mehr genauigkeit usw. immer: WELCHER BILDSCHIRM STELLT UNENDLICH GENAU ETWAS DAR? es gibt limitationen die selbst nen raytracer - solange dieser sich in unseren gegebenen Systemen - also - eingabe - verarbeitung - ausgabe (bildschirm...) bewegt - überflüssig machen; stichwort Pixel als kleinste sichtbare einheit.

ich will jetzt auch nicht technisch was vom zaun reissen, aber es ist nur so dass ich ca. 1998 das erste mal sowas gehört habe. passend nach der V2 release mit unreal was auch immer.

[Gast]

Naja, nen chip in OOP Programmieren... genau das wird doch täglich gemacht...?
Jeder der c++ Codet programmiert dem Hörensagen nach, einen Chip (nämlich die CPU) objektorientiert.

Ich glaube was sweeny sich wünscht ist sowas wie CUDA, vereinfacht, und dynamisiert (die Recheneinheiten müssen Flexibler werden, MIMD statt SIMD etc.) und dann steht den Engine-Entwicklern die volle teraflops-Power der GPUs für allerlei Krimskrams zur Verfügung. Dann gibts es keine Renderpipeline mit angedockten Shaderprogrammen mehr sondern nur noch "Das GPU-Programm".
Dann fällt die Trennung zwischen Physik und Grafik weg etc. Und wer lustig ist kann sogar nen grafischen Taschenrechner schreiben der auf der GPU läuft....

In dem Falle bestüde der "Grafiktreiber" mehr oder weniger nur noch aus einem compiler, der den C++ (oder was auch immer) - Code in die Sprache der GPU übersetzt und fertig.
Kein Boilerplate mehr, keine API mit mehreren Megabytes o.ä.
Sogar die Plattform wäre mehr oder minder egal.

Vorteil:
Kleinere Projekte, die sich die Entwicklung einer eigenen Engine nicht leisten können, müssten diese irgendwo lizensieren... und Sweenys geschäft brummt.

Dass das wunschdenken ist, und da zu viele Leute noch ein Finanzielles interesse daran haben dass alles beim alten bleibt, verschweigt er lieber... ;)

[Coda]

Es geht jetzt schon seit Jahren immer mehr in Richtung frei programmierbarer Streamprozessoren. Deine Meinung in aller Ehren - aber du liegst eindeutig falsch.

Sparse-Voxel-Octree Raycasting hat übrigens automatisches LOD. Aber das ist schwer OT.

[Simon Moon]

Hauptspeicher wird mittelfristig in die CPU wandern, kurzfristig auch die GPU. Schnittstellenanbindung wird auch in die CPU wandern. Festplatten werden gegen Flashspeicher ausgetauscht.

Glaub ich nicht. Wir haben wohl seit etwa 20 Jahren immer ungefähr gleich viele Ram Chips in unseren Computern. Geschrumpft ist hier nur die Fertigungsdichte, womit man sich immer mehr Speicherplatz erkauft hat. Selbst bei einer Halbierung der Fertigungsdichte alle 2 Jahre, bräuchten wir immer noch ein gutes Jahrzehnt, bis wir einen 32GBit Chip hätten - wobei ich bis dahin eher sowas wie 32 - 128GB RAM für realistisch halte.

[Aquaschaf]

121Ah@work;7479316']wir gingen in den 90er jahren von der "unified" schiene weg, nicht ohne grund. den software renderer hatten wir schon mal, was passiert ist, als die ersten "proprietären" beschleuniger ala v1 rauskamen, kennt man ja.

Es ist ja dann nicht "unified". Weiterhin bleibt eine Unterteilung in ein paar monolithische Prozessoren + einen großen Haufen simpler Prozessoren.

[Demirug]

nö, ganz sicher nicht auf eine, aber auf maximal drei. Denn mehr Hersteller fallen mir nicht ein.

Also besteht Bedarf noch einer Normierung.

[Avalox]

Glaub ich nicht. Wir haben wohl seit etwa 20 Jahren immer ungefähr gleich viele Ram Chips in unseren Computern.


Es wird kommen.
Zum einen ist es die nächste logische Konsequenz. Denn nachdem der Speichercontroller in die CPU integriert wurde, wie auch die I/O Schnittstellen CPU seitig diversifiziert wurden. So wird als nächster Schritt mit nachhaltigen Ergebnis sein, dass der Hauptspeicher in die CPU integriert wird. Ferner wird in Zukunft noch mehr I/O in die CPU integriert. Flashspeicher Controller könnte ich mir auch sehr gut in der CPU vorstellen.

Selbst wenn du meinst, dass die Anzahl der Speicherchips nicht abgenommen hat, so hat aber der Bedarf an Hauptspeicher allgemein im Verhältnis der Packungsdichte abgenommen.
Dann überlege doch mal, wie viel Hauptspeicher heute nur aufgebracht wird, um die Festplatte zu puffern. Es ist ja nicht nur der originäre Festplatten Cache, es sind auch Preloading Mechanismen, System Libraries und Programm Puffer. 64Bit Systeme würden es erlauben, jede Speicherzelle eines Flashspeichers(oder sonstigen Massenspeichers) sogar direkt zu adressieren.

In einer Übergangszeit ist auch durchaus vorstellbar, dass in schnellen internen Fastram und langsamen zusätzlichen Speicher unterschieden wird.

Es wird so kommen, der Hauptspeicher rutscht in die CPU. Schon allein aus dem Grund weil es geht und man es sich gar nicht erlauben kann dieses nicht zu tun, um die Systemperformance weiter zu steigern und immer aufwendigere Fertigungsprozesse zu produktivieren.

Also besteht Bedarf noch einer Normierung.

Eine Normierung der Schnittstellen?
Man wird Hersteller spezifische Bibliotheken linken. Schon heute bietet ja eine gute Engine mehr als diese drei Renderpfade.
Wo ist denn der Mehrwert dessen? Zu Zeiten eines 3Dfx war der Mehrwert ja gegeben, es war ein neuer Markt in dem sich ein frecher Emporkömmling tummelte. Die etablierten Hersteller und Investoren gierten nach jemanden, der einen erreichbaren Standard bot. Aber diese Situation hat sich grundlegend geändert. Es gibt drei große Blöcke, ein Intel, ein AMD/ATI und ein nVidia/IBM (oder sonstigen PPC Partner). Solch ein Standard kann mit DirectX auch nicht mehr viel gemein haben, dieses ist ja viel zu speziell und funktionsorientiert.

[Demirug]

Eine Normierung der Schnittstellen?
Man wird Hersteller spezifische Bibliotheken linken. Schon heute bietet ja eine gute Engine mehr als diese drei Renderpfade.
Wo ist denn der Mehrwert dessen? Zu Zeiten eines 3Dfx war der Mehrwert ja gegeben, es war ein neuer Markt in dem sich ein frecher Emporkömmling tummelte. Die etablierten Hersteller und Investoren gierten nach jemanden, der einen erreichbaren Standard bot. Aber diese Situation hat sich grundlegend geändert. Es gibt drei große Blöcke, ein Intel, ein AMD/ATI und ein nVidia/IBM (oder sonstigen PPC Partner). Solch ein Standard kann mit DirectX auch nicht mehr viel gemein haben, dieses ist ja viel zu speziell und funktionsorientiert.

Du vergleichst ernsthaft die Renderpfade einer Engine mit komplett unterschiedlichen möglicherweise inkompatiblen hersteller spezifischen APIs? Für die dann auch noch jeweils ein eigener spezieller Compiler gebraucht wird?

Dann müsste die PC Version eines Spiels auf drei „Plattformen“ portiert werden. Sowas hat heute keine Chance mehr. Entweder die Hersteller einigen selbst auf eine einheitliche API/ISA oder jemand anders muss eine vorgeben.

[Avalox]

Dann müsste die PC Version eines Spiels auf drei „Plattformen“ portiert werden. Sowas hat heute keine Chance mehr. Entweder die Hersteller einigen selbst auf eine einheitliche API/ISA oder jemand anders muss eine vorgeben.

Nicht das Spiel. Die Middleware muss halbwegs aufwendig portiert werden. Das wird diese ja heute schon. Zumal in Zukunft diese mehrwertigen CPUs sich ja auch in den Konsolen befinden werden.

Wenn MS dort standardisieren will, so muss es ja funktional geschehen. Ein echter Nachteil bei flexiblen Lösungen. Heutige GPU Hersteller stimmen sich mit MS ab. Ein Feature, welches nicht von MS unterstützt wird hat keinen Chance am Markt und MS nutzt natürlich die Erfahrung der GPU Hersteller für neue Funktionen. Eine flexibler Ansatz löst dieses systemimmanent auf.
Wenn MS weiterhin einen funktionalen Weg beschreitet, so ist dieses eine tatsächlich funktionale Einschränkung und wird damit automatisch die Unzufriedenheit der Engine-, wie auch der Spieleentwickler heraufbeschwören.
Tim Sweeney jammert ja schon heute, dass alle Spiele gleich aussehen, weil eben der technologischen Vorgaben die selben sind. Man möchte sich abgrenzen und direkt aus Entwicklungen partizipieren. Ausbrechen aus der Uniformiert.

Wie auch immer MS dort einen Standard abbilden möchte, es kann rein gar nichts mit dem heutigen DirectX zu tun haben.

Ausserdem wird es neben DirectX ganz sicher auch sofort einen Hersteller eigenen Weg geben. Schon dieses ist ja eine völlig neue Situation für MS.

Ich denke wir werden schon beim Larrabee erleben, wie Intel dort eine eigene Compiler Erweiterung anbieten wird und sicherlich werden die ganz schicken Larrabee Sachen nicht mit DirectX realisiert sein.

Ich finde es spannend.

[Demirug]

Avalox, ich will dir ja nicht zu nahe treten aber hast du schon einmal einen aktuelle multiplattform Renderframework gesehen? Man versucht dort die ganzen Unterschiede in den Render-APIs der unterschiedlichen Plattformen wegzubügeln. Dies wird gemacht damit höhere Layer der Engine auf eine einheitliche Schnittstelle zugreifen können. Was glaubst du wie begeistert die zuständigen Systemdevelopers sein werden wenn sie sich plötzlich wieder mit einer eigene API pro Hersteller konfrontiert sehen? Die würden fluchen ohne Ende.

Den einzigen den eine solche Aufspaltung gefallen kann sind Mittelwarehersteller. Dadurch könnten sie nämlich ihre Produkte teurer verkaufen.

Schauen wir uns doch mal die Historie von Direct3D an. In der Vergangenheit (vor 10) wurden für einzelnen Hersteller immer wieder Extrawürste gebacken. Es wurden Features unterstützt die nur ein IHV anbot. Entsprechenden Caps zeigten an ob man es benutzten kann oder nicht. Das Ergebnis war immer wieder das gleiche. Ein verschwindend geringer Prozentsatz von Spielen nutze diese Features. Das entfernen der Caps bei 10 und die damit einhergehen strenge Definition eines Featuresets geschah auf Wunsch der Entwickler die dieses Capschaos endgültig satt hatten. Es gibt dafür bei Microsoft extra regelmäßige Treffen von Entwicklern der wichtigen Studios.

Sicherlich wird Intel für Larrabee spezielle Bibliotheken anbieten. Bei den Spieleentwicklern wird das aber genauso floppen wie CUDA. Und nvidia konnte einen relevanten Marktanteil in die Waagschale werfen. Davon ist Intel meilenweit entfernt.

Es wird laufen wie immer. Wenn sich die Hardware ändert wird sich eine neue Direct3D Version darauf anpassen. Vielleicht bekommt sie dann irgendwann endgültig einen neuen Namen aber das ändert nichts am Prinzip.

[Monger]

Wenn MS weiterhin einen funktionalen Weg beschreitet, so ist dieses eine tatsächlich funktionale Einschränkung und wird damit automatisch die Unzufriedenheit der Engine-, wie auch der Spieleentwickler heraufbeschwören.
Tim Sweeney jammert ja schon heute, dass alle Spiele gleich aussehen, weil eben der technologischen Vorgaben die selben sind.
Das hat imho weniger mit dem Featuresatz als mit der Tool- und Middlewarelandschaft zu tun.

Die Unreal Engine 3 z.B. unterstützt ja eine ganze Reihe von Beleuchtungsmodellen, und ist zumindest angeblich auch flexibel genug, um diese gegen beliebige andere Lösungen austauschen zu können. Ich kann mich da an einige Techdemos erinnern, die optisch nun wirklich überhaupt keine Gemeinsamkeit hatten.
Die meisten Studios übernehmen halt aus Kostengründen den Königsweg, und kaufen sich das hinzu was auch in anderen Spielen schon funktioniert hat. Die mangelnde Vielfalt ist imho viel eher der stark rationalisierten Content Pipeline geschuldet als tatsächlich technischen Einschränkungen.

[tomvos]

Ich finde, Tim Sweeney geht zu wenig auf die eigentliche Aufgabenstellung ein, die sich durch GPUs ergeben. Alle GPUs werden per PCIe an das System angeschlossen. Das gilt für nVidia, ATI und Intels Larrabee. Zeitaufwändige Speichertransfers aus und in den Hauptspeicher sind momentan der Hauptgrund, warum der Einsatzzweck für GPU-Computing beschränkt ist.

Selbst wenn die GPU im Prozessor sitzt und den Speicherkontroller direkt anstelle von PCIe nutzen kann, so ist die Bandbreite innerhalb der CPU deutlich kleiner als innerhalb der GPU. Ein Core i7 bietet als Spitzenwert 25,6 GB/s (lesen und schreiben), während eine NVIDIA 280GTX intern 141,7 GB/s zur Verfügung stehen.

Ich rechne damit, auch in Zukunft verschieden schnelle Speichertypen im Computer zu haben. Alleine schon aus Kostengründen verbietet es sich, allen Speicher extremst schnell anzubinden. Auch hat die Erfahrung gezeigt, dass gar keine Notwendigkeit besteht, 100% des Speichers mit maximal möglichem Tempo anzusprechen.


Der Ansatz aus der Unreal3 Engine, Task-Parallelism als Lösung zu verfolgen ist gescheitert. Lösungen werden eher im Bereich Data-Parallelism zu finden sein. (Ab Folie 40 beschrieben.)

Damit die neuen Lösungen akzeptabel funktionieren, muss die Softwarelösung zumindest genauso leistungsfähig sein, wie bisherige GPUs, die von Natur aus massiv Data-Parallel sind. Die Recheneinheit - sei es nun CPU oder GPU oder sonstiger Hybrid - muss also irgendwie mit einen sehr großen Datenvolumen versorgt werden. Das wäre einfach, wenn der gesamte Hauptspeicher mit der gleichen Geschwindigkeit angesprochen werden könnte, wie das VRAM innerhalb der Grafikkarte - bzw. das ein homogener Speicherblock wäre.

In der Praxis wird es eher auf diverse Cache- und Streaming-Techniken hinauslaufen. Es gibt bereits viele Beispiele, wie sich Latenzen und fehlende Speicherbandbreite verstecken lassen. Von daher wird zwar die GPU und CPU demnächst auf einen DIE bzw. Prozessorträger zu finden sein - aber das ist hinsichtlich der Leistung (Thema Bandbreite) so relevant wie alle Onboard GPUs ...

Insofern sehe ich nicht das Ende der GPU, sondern nur den Wandel der GPU zum spezialisierten Vektorrechner. Im Vergleich zur CPU sind nun mal die Caches kleiner und die Flexibilität geringer, aber für die geplanten Aufgaben durchaus angemessen. Eine CPU ist flexibler, nutzt dafür aber auch viel weniger Schaltkreise für die eigentliche Berechnung.
Eine universelle Recheneinheit, die beide Aufgaben nach Bedarf erledigen kann - und das vergleichbar mit der jeweils besten GPU oder CPU - sehe ich z.Z. nicht. Weder bei NVIDIA, noch bei Intel. Solange diese Universal Processing Unit (UPU) fehlt, würde ich noch nicht von einem Ende der Grafikkarten sprechen.

[Chris Lux]

Ich finde, Tim Sweeney geht zu wenig auf die eigentliche Aufgabenstellung ein, die sich durch GPUs ergeben. Alle GPUs werden per PCIe an das System angeschlossen. Das gilt für nVidia, ATI und Intels Larrabee. Zeitaufwändige Speichertransfers aus und in den Hauptspeicher sind momentan der Hauptgrund, warum der Einsatzzweck für GPU-Computing beschränkt ist.
darauf ist er eingegangen. in seiner vision wird das gesammte spiel/anwendung auf der massiv parallelen einheit laufen. er ist auch soweit gegangen ansaetze von programmiermodellen/-sprachen anzusprechen fuer verschiedene aufgaben in so einer anwendung.

[Avalox]

Sicherlich wird Intel für Larrabee spezielle Bibliotheken anbieten. Bei den Spieleentwicklern wird das aber genauso floppen wie CUDA. Und nvidia konnte einen relevanten Marktanteil in die Waagschale werfen. Davon ist Intel meilenweit entfernt.

Es wird laufen wie immer. Wenn sich die Hardware ändert wird sich eine neue Direct3D Version darauf anpassen. Vielleicht bekommt sie dann irgendwann endgültig einen neuen Namen aber das ändert nichts am Prinzip.


Nun sage mir doch mal, was ein Tim Sweeny oder John Carmack abhalten wird solche Bibliotheken zu nutzen, um sich so mit ihrer Engine weiter von handgestrickten 0815 Standardlösung abgrenzen zu können und einen Mehrwert zu bieten?
Zumal generell davon auszugehen ist, dass solche Lösungen auch in den nächsten Spielkonsolen Verwendung finden werden.


Viel eher werden sich doch die Hersteller der CPUs untereinander auf einen einheitlichen Befehlssatz, oder Schnittmenge einigen, als dazu einen Dritten ins Boot zu holen, welcher primär dort gar keinen Nutzen bringt.


IDamit die neuen Lösungen akzeptabel funktionieren, muss die Softwarelösung zumindest genauso leistungsfähig sein, wie bisherige GPUs

Nein dieses muss es nicht sein. Zum einen kann man schon heute schön praktisch an den Konsolen sehen, welche dort technologisch den PC deutlich hinterher hinken und doch sehr erfolgreich sind. Der technologische Vorsprung des PC wird kaum genutzt und dort wo er genutzt wird, resultiert dieses in einen marginalen Vorteil.

Solch eine Lösung muss schlicht hinreichend, breit verfügbar und günstig sein, mehr ist zum Erfolg nicht nötig.
Auch ist heutige Software, so wie sie ist, weil die Systeme so sind wie sie sind. Dieses System lebt von einer Doppelbeziehung, welche sich durchaus schnell ändern kann.

[Aquaschaf]

Selbst wenn die GPU im Prozessor sitzt und den Speicherkontroller direkt anstelle von PCIe nutzen kann, so ist die Bandbreite innerhalb der CPU deutlich kleiner als innerhalb der GPU. Ein Core i7 bietet als Spitzenwert 25,6 GB/s (lesen und schreiben), während eine NVIDIA 280GTX intern 141,7 GB/s zur Verfügung stehen.

Die Spitzenwerte sind nicht vergleichbar. Wenn das Zugrifssmuster nicht schön geordnet ist, dann bricht die Bandbreite bei der GPU viel stärker ein.

Der Ansatz aus der Unreal3 Engine, Task-Parallelism als Lösung zu verfolgen ist gescheitert. Lösungen werden eher im Bereich Data-Parallelism zu finden sein. (Ab Folie 40 beschrieben.)

Diese Arten der Parallelität schließen sich doch nicht aus. Auf Task-Ebene Parallelität zu haben ist trotzdem sehr schön, weil das erst einmal weniger Kommunikation erfordert. Und wieso betrachtest du den Ansatz der U3-Engine als Fehlschlag?

[tomvos]

Die Spitzenwerte sind nicht vergleichbar. Wenn das Zugrifssmuster nicht schön geordnet ist, dann bricht die Bandbreite bei der GPU viel stärker ein.
Das stimmt natürlich, allerdings habe ich keine anderen Werte verfügbar. Bzw. alle anderen Werte sind stark anwendungsspezifisch.



Diese Arten der Parallelität schließen sich doch nicht aus. Auf Task-Ebene Parallelität zu haben ist trotzdem sehr schön, weil das erst einmal weniger Kommunikation erfordert. Und wieso betrachtest du den Ansatz der U3-Engine als Fehlschlag?

Die Tasks haben unterschiedliche Anforderungen an die Rechenkapazität. Task Parallelism funktioniert dann gut, wenn viele Tasks mit ähnlichen Aufwand verfügbar sind. Tim Sweeny schreibt selbst, dass die U3 Engine 6 (Haupt)Threads hat und somit gar nicht erst in der Lage ist, über weite Bereiche zu skalieren.

[Aquaschaf]

Tim Sweeny schreibt selbst, dass die U3 Engine 6 (Haupt)Threads hat und somit gar nicht erst in der Lage ist, über weite Bereiche zu skalieren.

Muss sie ja auch nicht. Für den Zeitraum und die Plattformen für die sie designed wurde reicht das aus.

[Demirug]

Nun sage mir doch mal, was ein Tim Sweeny oder John Carmack abhalten wird solche Bibliotheken zu nutzen, um sich so mit ihrer Engine weiter von handgestrickten 0815 Standardlösung abgrenzen zu können und einen Mehrwert zu bieten?

Carmack bevorzugt doch schon seit Doom III wenn möglich den allgemeinen Weg gegenüber IHV spezifischen Lösungen.

Sweeny kann ich zugegebenermassen schwer einschätzen. In seinen Vorträgen spielt er gerne den großen Visionär (mit geringer Trefferwahrscheinlichkeit) aber sonst ist er ein knallharter Geschäftsmann. Die Unrealengine ist solide Arbeit aber jetzt nicht unbedingt cutting Edge. Zudem beklagen sich viele das sie eine Blackbox ist und man nur sehr schwer etwas ändern kann. Deswegen sehen ja auch so viele Spiele damit gleich aus. Entsprechend glaube ich auch nicht das er sich auf IHV spezifische APIs einlassen wird. Für eine allgemeine API zur alternativen nutzung von GPUs (bzw. GPU ähnlichen Chips) ist er aber sicherlich zu haben.



Zumal generell davon auszugehen ist, dass solche Lösungen auch in den nächsten Spielkonsolen Verwendung finden werden.

Von der nächsten Generation ist noch nichts zu sehen und im Moment hofft jeder Entwickler das dies auch noch lange so bleibt.

Viel eher werden sich doch die Hersteller der CPUs untereinander auf einen einheitlichen Befehlssatz, oder Schnittmenge einigen, als dazu einen Dritten ins Boot zu holen, welcher primär dort gar keinen Nutzen bringt.

Von welchen CPUs reden wir jetzt hier? Die CPU/GPU Hybriden ala Fusion? Die werden gerade mal genügend Power haben um einen IGP zu ersetzten. Da diese sich aus der aktuellen Produktline ableiten wird es auch keine gemeinsame ISA geben.

[Coda]

Zudem beklagen sich viele das sie eine Blackbox ist und man nur sehr schwer etwas ändern kann.
Aber man bekommt doch den Sourcecode, nicht?

[Demirug]

Aber man bekommt doch den Sourcecode, nicht?

Ja, aber man hat mir gesagt das es relativ kompliziert sein soll da was zu ändern.

[LordDeath]

Ein Bisschen Offtopic, aber geht Epic Games nicht ein Risiko ein, wenn sie ihren Kunden den Sourcecode ihrer Engine zur Verfügung stellen?
Die könnten den Code doch erweitern und künftig ihren einen Fork der Unreal Engine weiter benutzen.
Oder ist es vertraglich geregelt, dass künftige Spiele mit Teilen von Epics Code weitere Zahlungen an Epic mit sich ziehen werden?

[Crazy_Chris]

Ein Bisschen Offtopic, aber geht Epic Games nicht ein Risiko ein, wenn sie ihren Kunden den Sourcecode ihrer Engine zur Verfügung stellen?
Die könnten den Code doch erweitern und künftig ihren einen Fork der Unreal Engine weiter benutzen.
Oder ist es vertraglich geregelt, dass künftige Spiele mit Teilen von Epics Code weitere Zahlungen an Epic mit sich ziehen werden?

Und ruck zuck wird man verklagt. Kann doch nicht jeder machen was er will. Da gibt es knallharte Lizenzbedingungen. :freak:

[Controller Khan]

Aber man bekommt doch den Sourcecode, nicht?

Meine Erfahrung beziehen sich auf Unreal Engine 1.

Sobald man massiv eigenen UnrealScript Code schreibt, fliegt das Ding gerne um die Ohren.:frown:
Die Engine ist halt nur gegen Epics Code getestet.
-> auf vorhandenden Code von Epic aufbauen, das wird noch undurchsichtiger. :rolleyes:

Der ist auch eine echte Blackbox mit vielen (Quer)-Abhaengigkeiten.
Dann Probleme fixen dauert.

Den C++ Code bekommt als zahlender Entwickler bestimmt, nur der Zeitaufwand das entsprechend zu debuggen.

Das die professionellen Entwickler solche Wagnisse nicht eingehen, versteht sich von selbst.
Manchmal sind Entwickler schon so mit Unreal Ed ueberfordert (Stranglehold).

[Aquaschaf]

Meine Erfahrung beziehen sich auf Unreal Engine 1.

Davon kann man denke ich keine großartigen Rückschlüsse auf die Version 2 und 3 der Engine ziehen.

[RIPchen]

Geht aber - bitte nicht schlagen - schon ein wenig in Richtung Larrabee...

[Gast]

darf man das noch mal in zusammenhang mit opencl und direct compute aufwärmen?

[Gast]

Ja, aber man hat mir gesagt das es relativ kompliziert sein soll da was zu ändern.
Das Problem ist eher, dass jedes neue release soviele changes hat, dass der merge echt kein spass ist, aber man dennoch wegen bugfixes das ganze schlucken muss.
Deswegen fassen die meisten einwickler entweder nichts an oder sie schreiben alles um und gehen auf eigene faust.