AMD Graphics Core Next - neue GPU Architektur für Ende 2011

[AnarchX]

2620 - AMD Graphics Core Next
At the heart of every AMD GPU is a power aware high performance set of compute units that have been advancing to bring users new levels of programmability, precision and performance. Starting with the introduction of the HD 2000 family of Unified Shader Systems to the PC consumer markets in 2007, AMD has delivered four unique generations. In this presentation, an overview of AMD's Graphics Core Next architecture will be introduced. We’ll talk about the architecture of this new shader system, and how it provides improvements to the necessary software stack and creates user programming flexibility. We believe you will obtain an understanding of this new architecture and how it lays the foundation for future AMD architectures.
https://amdfusion.wingateweb.com/scheduler/eventguide/publicScheduleByType.jsp

Update:
"In a couple of days you are going to hear about our exciting new graphics architecture that will be coming out later this year and will be utilized by our future APUs," said Rick Bergman, senior vice president and general manager of AMD products group.
http://www.xbitlabs.com/news/graphics/display/20110614234623_AMD_Reaffirms_Plans_to_Introduce_Next_Generation_Radeon_Graphics_ Later_This_Year.html

Technische Folien zu Core Next:

http://www.hardware.fr/news/11648/afds-architecture-futurs-gpus-amd.html

http://developer.amd.com/documentation/presentations/assets/6-Demers-FINAL.pdf

[Duplex]

We’ll talk about the architecture of this new shader system
was für Shader will AMD zukünftig einsetzen? 4D & 5D kennen wir bereits, Nvidia hat 1D Shader, was für ein Vorteil soll der Software Hersteller dabei haben, wie kommt es zu einer besseren Auslastung?

[AnarchX]

AFDS Keynote: “Evolution of AMD's Graphics Core, and Preview of Graphics Core Next”
Eric Demers, AMD Corporate Vice President and CTO, Graphics Division

GPU shader cores have been evolving frequently and significantly at AMD. We introduced our common shader core in 2007 with the HD 2000 series. This introduced the unified VLIW-5 instruction set that we've had since. In late 2010, we introduced the first significant departure from this core architecture, the symmetrical VLIW-4 used in the HD6900 series of products. In this presentation, we will review that evolution, but also present an overview of the next generation of AMD cores under development. This next generation of cores will propel forward its capabilities and continue this evolution.
http://developer.amd.com/afds/pages/keynote.aspx

[Nakai]

Sieht für mich eher nach einem ziemlich großen evolutionärem Schritt aus. Ergo für DX12+.

[AnarchX]

Keynote: Eric Demers, AMD
Thursday, June 16
10:30am - 11:15am PDT

http://developer.amd.com/afds/pages/default.aspx

[Ailuros]

VLiW3? :D

[Gipsel]

http://developer.amd.com/afds/pages/default.aspx
Die einstündige Präsentation "AMD Graphics Core Next" von Mike Houston und Mike Mantor ist schon heute 16:00 Uhr Ortszeit, also 1:00 Uhr MESZ diese Nacht.

[Ailuros]

Die einstündige Präsentation "AMD Graphics Core Next" von Mike Houston und Mike Mantor ist schon heute 16:00 Uhr Ortszeit, also 1:00 Uhr MESZ diese Nacht.

Ich will aber wirklich auf ernsthaftere Aenderungen hoffen als bisher ;)

[Nakai]

So laut Gipsel sollte der Stream jetzt dann anfangen...mal gucken was kommt. Bis jetzt empfang ich noch nix.^^;)

€: Wird das überhaupt übertragen?

[Nakai]

Erste Infos sind geleakt:
http://www.realworldtech.com/forums/index.cfm?action=detail&id=120411&threadid=120411&roomid=2

http://twitter.com/#!/DKrwt

A few highlights from the talk:

Multiple primitive pipelines for setup, etc.

Real caching in L1, L2, separate color/z caches for graphics and atomics
Concurrent tasks
Out of order resource allocation
ECC on srams and drams

Shaders
No vliw, just multiple issue simd
Branch, scalar, vector, vector memory, export units
4x16 wide vector ALUs

More to come

[Coda]

Kein VLIW? WTF?

Edit: Wenn ich das richtig interpretiere, dann gehen sie in Zukunft den NVIDIA-Weg. Also SIMT.

Edit2: Jup, sieht so aus:
http://cdnmo.coveritlive.com/media/image/201106/phpP5OaT0008.jpg

Sieht schon ziemlich Fermi ähnlich aus, auch mehrere Primitive-Pipelines, richtige Caches, ECC, concurrent Kernels etc.

[Ailuros]

Kein VLIW? WTF?

Edit: Wenn ich das richtig interpretiere, dann gehen sie in Zukunft den NVIDIA-Weg. Also SIMT.

Edit2: Jup, sieht so aus:

Sieht schon ziemlich Fermi ähnlich aus, auch mehrere Primitive-Pipelines, richtige Caches, ECC, concurrent Kernels etc.

Klingt mir persoenlich eher in die Richtung die SGX geht. Waere es falsch zu denken dass das DP/SP ratio vielleicht immer noch auf 1:4 liegt?

[AnarchX]

Wohl alle Folien: http://www.hardware.fr/news/11648/afds-architecture-futurs-gpus-amd.html

Laut Bergman soll wohl diese Architektur schon in den 28nm GPUs zum Jahreswechsel verbaut sein.

[Gipsel]

Klingt mir persoenlich eher in die Richtung die SGX geht. Waere es falsch zu denken dass das DP/SP ratio vielleicht immer noch auf 1:4 liegt?
Auf den Folien steht es sei variabel, je nach Zielmarkt.

Muß mir das bei Gelegenheit nochmal genauer anschauen, aber auf einer ganz einfachen Basis haben sie die VLIW4-Gruppen getrennt und jeder "self-contained" SIMD-Engine (OpenCL-Compute Unit) gleich 4 Thread-Sequencer verpaßt (bisher 2, die alle 8 Takte, die 2 alternierenden Wavefronts pro SIMD liefern), die jetzt keine VLIW-Anweisungen ausspucken, sondern "skalare" (Achtung, nv-Sprech!) Anweisungen. Die ehemaligen VLIW4-Gruppen stehen als 4 eigenständige SIMD-Einheiten zur Verfügung (AMD spricht hier korrekterweise von Vektor-ALUs, bei nv sind es die "skalaren" :freak:). Die ehemaligen VLIW-Slots werden jetzt also mit Anweisungen aus unterschiedlichen Wavefronts gefüllt. Die 64 "Lanes" einer Wavefront-Instruktion wird immer noch über 4 Takte verteilt ausgeführt (SIMDs sind 16-wide).

So eine SIMD-Einheit ist nicht mehr wie die alten SIMD-Engines praktisch komplett, deswegen ergeben erst 4 davon zusammen (mit den L1-caches/LDS/Branch unit/zusätzlichen skalaren Einheit für alle zusammen) wieder eine Compute Unit.

Interessant ist, daß AMD nicht den LDS und L1 zusammenlegt, sondern 64kB LDS einzeln stehen läßt, dafür aber GP-R/W-L1 und Texture-L1 vereint. Außerdem gibt es noch einen extra Skalar-Cache (genau wie Instruction Cache von 4 compute units geteilt, das werden also die Grundbausteine werden, 4 CUs = 16 SIMDs = 256 ALUs pro Block). Das ist eine etwas andere Richtung als nv eingeschlagen hat. Der Tex-L1 ist jetzt auch komprimiert und wird erst beim Lesen dekomprimiert, die Assoziativität sinkt leicht (voll assoziativ = 128 way bei R700 bis NI, jetzt 64fach assoziativ), dafür hat man mehr Platz und für's Texturing kann die Bandbreite wohl besser genutzt werden (die Radeons kommen bei Tex-lastigen Sachen momentan an das L1-Bandbreiten-Limit).

Wie gesagt, muß man sich noch mal im Detail (die AMD aber vielleicht noch gar nicht verrät) anschauen (Was kann jede Einheit? AMD spricht von float ALUs die 32bit Integer-Operationen können. Jeweils alle? Wie schnell?), aber AMD investiert doch merklich in mehr Verwaltung und erhöhte Effizienz, was hoffentlich nicht an anderen Ecken zu Sparversuchen führt, die dann wieder bremsen. Auf jeden Fall scheint sich AMD von der festen Kopplung der Ausführungslatenz der Einheiten an die grundlegende Architektur verabschiedet zu haben (bisher 8 Takte). Dies würde es im Prinzip wie bei nvidia ermöglichen, den Takt durch eine andere Auslegung der Pipeline (deutlich?) anzuheben.

[Gipsel]

Kein VLIW? WTF?

Edit: Wenn ich das richtig interpretiere, dann gehen sie in Zukunft den NVIDIA-Weg. Also SIMT.

Edit2: Jup, sieht so aus:
http://cdnmo.coveritlive.com/media/image/201106/phpP5OaT0008.jpg
Die Folie listet die Fortschritte gegenüber den bisherigen Radeons auf. Die scalar engine bezieht sich hierauf:

http://www.abload.de/img/img0032673_1bunu.jpg

Das ist zusätzlich zu den Vektor-ALUs verbaut. Stell' Dir das perspektivisch wie einen abgespeckten Integer-Kern vor, der neben fetten SSE/AVX-Einheiten sitzt ;)

[Ailuros]

Das variabel je nach Zielmarkt hab ich schon gesehen; sagt aber leider nicht viel aus. Da DP von geringerer Nutzbarkeit bei kleineren GPU ist, ist es wohl klar dass je kleiner der chip desto mehr links und rechts fuer solche Faehigkeiten gespart wird.

Koennte die OoO resource allocation auch fuer einen revamp der Tessellations-pipeline deuten?

[LovesuckZ]

Koennte die OoO resource allocation auch fuer einen revamp der Tessellations-pipeline deuten?

Ist doch abgebildet: Unabhängige Geometrie- und Rastereinheiten. Also wie bei Fermi.
Wobei ich nicht weiß, ob diese sich weiterhin außerhalb der Cores befinden oder wie bei nVidia eine Einheit in Gruppen bilden.

/edit: Laut der Folie befinden sie sich außerhalb.

[X.Perry_Mental]

Laut Bergman soll wohl diese Architektur schon in den 28nm GPUs zum Jahreswechsel verbaut sein.
Neue Architektur in neuem Prozess klingt irgendwie riskant. Intel wird ja auch nicht ohne Grund nur mit wenigen, beherrschbaren Änderungen auf einen kleineren Prozess wechseln und erst wenn dieser steht eine neue Architektur einführen (Tick-Tock). Ich drücke die Daumen.

[Screemer]

ok. dann war cayman wohl der letzte vliw-chip. denkt ihr da kommt vielleicht noch ein 28nm refresh oder wird man da gar nicht mehr mit rechnen können. was haltet ihr von diesem weg? ist dieses system besser nach unten skalierbar um in zukunft den low-power/embedded bereich wieder im portfolio zu habe?

[Sorkalm]

ok. dann war cayman wohl der letzte vliw-chip. denk ihr da kommt vielleicht noch ein 28nm refresh oder wird man da gar nicht mehr mit rechnen können. was haltet ihr von diesem weg? ist dieses system besser nach unten skalierbar um in zukunft den low-power/embedded bereich wieder im portfolio zu habe?

Würde ich nicht sagen, Trinity (die APU) kommt noch mit VLIW(4), und es müssen ja auch nicht alle 28 nm-Chips schon umgestellt werde. Zuletzt hat ja auch nur Cayman VLIW4 bekommen...

[Coda]

Die Folie listet die Fortschritte gegenüber den bisherigen Radeons auf. Die scalar engine bezieht sich hierauf:
Okay, und was machen sie damit? Wird die zwischen den Threads einer Wavefront geteilt?

Und was für Instructions haben dann die breiten ALUs? Wirklich SIMD?

Edit: Ich hab die Slides durchgegangen und für mich sieht das immer noch so aus, als würden sie alle Threads einer Wavefronts zusammen auf einem SIMD ausführen, also doch wie NVIDIA. Für die These spricht auch das "predictable performance" und "easier compiler scheduling" etc.

[Gipsel]

Okay, und was machen sie damit? Wird die zwischen den Threads einer Wavefront geteilt?
Die bearbeitet die skalaren Instruktionen, die für eine Wavefront anfallen, behandelt hard coded loops, die Branch-Masken usw. Wie gesagt, stell' Dir das perspektivisch wie den skalaren Integer-Kern einer CPU vor, der neben dicken SSE/AVX-Einheiten sitzt. Hat ja auch ein eigenes Register file.
Und was für Instructions haben dann die breiten ALUs? Wirklich SIMD?Na klar, ist immer noch so wie bei allen GPUs. Was anderes macht auch kaum viel Sinn.
Edit: Ich hab die Slides durchgegangen und für mich sieht das immer noch so aus, als würden sie alle Threads einer Wavefronts zusammen auf einem SIMD ausführen, also doch wie NVIDIA.Das stand doch nie in Frage?!? Jede SIMD-Einheit (Vektor-ALU) bekommt alle 4 Takte eine neue Instruktion. Eine Instruktion einer Wavefront (bleibt bei 64er Breite) wird immer noch über 4 Takte verteilt. Bei nv sind's seit Fermi eben nur noch 2.

In nvidia-Terminologie haben die SMs (CUs) 64 "skalare" ALUs in vier 16er-Blöcken (SIMDs) und es gibt 4 Scheduler/Dispatcher (Thread Sequencer hieß das bis NI, jetzt gibt es [noch] keinen neuen Namen dafür), die alle 4 Takte jeweils eine(/mehrere) Instruktion(en) für eine Wavefront absetzen (maximal 5 Instruktionen pro Wavefront, können sein: 1 Wavefront-ALU, 1 branch, 1 skalare Operation/Load/Store, 1 L/S/TEX, 1 LDS, 1 Export/GDS, bestimmte Sachen wie barriers werden zusätzlich direkt von den Schedulern initiiert). Das Scheduling geht wahrscheinlich round robin zwischen den einzelnen Schedulern. Es gibt 64kB shared (local) memory, 16 kB L1, der gleichzeitig R/W für GPGPU, als auch Texture-L1 ist (bei Fermi separat, dafür LDS/L1 zusammengefaßt).

Ganz lustig eigentlich, habe ich doch über 64 ALUs pro SM bei Kepler spekuliert.

[Coda]

Die bearbeitet die skalaren Instruktionen, die für eine Wavefront anfallen, behandelt hard coded loops, die Branch-Masken usw. Wie gesagt, stell' Dir das perspektivisch wie den skalaren Integer-Kern einer CPU vor, der neben dicken SSE/AVX-Einheiten sitzt. Hat ja auch ein eigenes Register file.
Der Vergleich hinkt etwas, weil eine AVX-Einheit ja SIMD für einen Thread ausführt. Aber vom Aufbau okay.

Das stand doch nie in Frage?!?
Das war darauf bezogen:
Die Folie listet die Fortschritte gegenüber den bisherigen Radeons auf. Die scalar engine bezieht sich hierauf
Aber gut, dann sind wir uns ja einig.

Also ich finde es sieht schon sehr Fermi ähnlich aus.

Ganz lustig eigentlich, habe ich doch über 64 ALUs pro SM bei Kepler spekuliert.
Uhm, würde das nicht die Warp-Größe verdoppeln?

[Gipsel]

Der Vergleich hinkt etwas, weil eine AVX-Einheit ja SIMD für einen Thread ausführt. Aber vom Aufbau okay.Ist bei einer GPU auch nicht viel anders. Die Hardware-Threads werden immer noch in Warps/Wavefronts ausgeführt. Den "Thread" den ein Programmierer normalerweise sieht, ist eben nur ein data element (OpenCL-Sprech) so eines Vektors. Da ändert auch noch so viel predication und lane masking nichts dran. Aber das hatten wir ja schon mehrfach ;)
Uhm, würde das nicht die Warp-Größe verdoppeln?Warum? Man braucht nur mehr Scheduling Ports. Der Schritt von 32 ALUs zu 48 ALUs im SM hat doch die Warp-Größe auch nicht geändert.

[Coda]

Ist bei einer GPU auch nicht viel anders. Die Hardware-Threads werden immer noch in Warps/Wavefronts ausgeführt. Den "Thread" den ein Programmierer normalerweise sieht, ist eben nur ein data element (OpenCL-Sprech) so eines Vektors. Da ändert auch noch so viel predication und lane masking nichts dran. Aber das hatten wir ja schon mehrfach ;)
Ja, stimmt schon.

Warum? Man braucht nur mehr Scheduling Ports. Der Schritt von 32 ALUs zu 48 ALUs im SM hat doch die Warp-Größe auch nicht geändert.
Ach so meinst du. Ist das bei dem ATI-Ding wirklich auch so, das es mehrere Scheduler gibt?

Also es sind eigentlich wirklich 4 unabhängige 16er SIMDs die in 4 Takten jeweils eine Thread Group bearbeiten?

[Hugo78]

Mir drängt sich grade die Frage auf, ob es jetzt nicht wahrscheinlicher wird,
dass AMD in Zukunft nicht doch auch CUDA benutzt/lizenziert, wenn sie mit dieser "fermi-artigen" VLIW/SIMD fertig sind.

CUDA mag ja nicht offen sein, aber ich erinnere mich dunkel, dass vor paar Monaten ein AMD Mensch beim Thema GPGPU Code leicht nörgelnt meinte,
dass ja der ganze vorhandene Code aus der Ecke ja so "Nvidia 1D" optimiert sei.
Daran wird sich wohl auch nichts so schnell ändern,
solange sich CUDA weiterhin (schneller / umfassender) entwickelt oder einfach schlicht immer mehr Softwareleute in der Industrie,
heute mit "CUDA groß werden", als mit OpenCL und es damit in Zukunft nur um so schwerer wird für OpenCL.
Nvidia's Marktanteil in dem Bereich liegt ja aktuell bei was?... 90%, 95%?!

Oder ist VLIW4/5 in der bisherigen Form, auch einfach nicht das OpenCL Optimum und AMD vollzieht hier schlicht einen notwendigen Schritt,
ganz ohne Bezug auf eine mögliche CUDA Kompatibilität?!

[LovesuckZ]

AMD hat erst vor kurzem verkündet, dass man CUDA als Nische ansieht und man voll auf OpenCL setzen wird. Imo macht eine "Angleichung" nur sinn, wenn man die Arbeit von nVidia nach OpenCL führen will. Eine Lizenzierung von CUDA es wird auch durch nVidia nicht geben.

[Gipsel]

Ach so meinst du. Ist das bei dem ATI-Ding wirklich auch so, das es mehrere Scheduler gibt?Das sind die 4 Dinger, die ich oben "Thread Sequencer" genannt habe, weil sie bisher so hießen. Auf der Abbildung hier sind das die vier Dinger neben Instruction fetch:

http://www.abload.de/img/img0032663_1mjpi.jpg

Das "Instruction Arbitration" einen Schritt weiter stellt dann nur sicher, daß nichts doppelt benutzt wird.
Es gibt also 4 Scheduler, die jeweils maximal 5 Operationen alle 4 Takte absetzen können(Edit: das stimmt so nicht). Nach dem "Instruction arbitration" gibt es dann 6 issue-Ports zu den Einheiten.
Also es sind eigentlich wirklich 4 unabhängige 16er SIMDs die in 4 Takten jeweils eine Thread Group bearbeiten?
Ja. Jeder SIMD-Block/Vektor-ALU arbeitet an einer anderen Wavefront für jeweils 4 Takte (mindestens 4, DP, transcendentals, IMULs dürften länger dauern), dann kommen die nächsten Wavefronts.

[Gipsel]

AMD hat erst vor kurzem verkündet, dass man CUDA als Nische ansieht und man voll auf OpenCL setzen wird. Imo macht eine "Angleichung" nur sinn, wenn man die Arbeit von nVidia nach OpenCL führen will.Was meinst Du denn mit der Worthülse? Und was hat das mit dem Thema zu tun?

[Coda]

Mir drängt sich grade die Frage auf, ob es jetzt nicht wahrscheinlicher wird,
dass AMD in Zukunft nicht doch auch CUDA benutzt/lizenziert, wenn sie mit dieser "fermi-artigen" VLIW/SIMD fertig sind.
Hat damit im Prinzip nichts zu tun. Man könnte ohne weiteres auch GPUs bauen die alle CUDA-Features haben und VLIW-Architekturen sind.

Aber die Scalar Unit irritiert mich immer noch etwas. Ist das z.B. für die Kontrolle einer Schleife mit fester Abbruch-Bedingung für alle Threads? Ist das wirklich so häufig, das es sich lohnt?

[Gipsel]

Aber die Scalar Unit irritiert mich immer noch etwas. Ist das z.B. für die Kontrolle einer Schleife mit fester Abbruch-Bedingung für alle Threads? Ist das wirklich so häufig, das es sich lohnt?
Das auch. Als Hauptgrund führt AMD an, daß das Management des Kontrollflusses (den die Hardware ja sowieso für Warps/Wavefronts macht) flexibler und effizienter gestaltet:

http://www.abload.de/img/img0032675_1lmxu.jpg

Deswegen ja auch meine Analogie zum Integer-Kern bei AVX. Bei Adressberechnungen kann die wohl auch noch mit reinspielen, wenn man den Diagrammen glaubt.

[Coda]

Ja gut, aber man hat ja mehr als einen Kontrollfluss innerhalb einer Thread Group.

Edit: Obwohl, ja eigentlich nicht. Hm. ist das dann nicht einfach sowas wie eine aufgeblasene Branch-Unit wie bei R600?

[Gipsel]

Ja gut, aber man hat ja mehr als einen Kontrollfluss innerhalb einer Thread Group.

Edit: Obwohl, ja eigentlich nicht. Hm. ist das dann nicht einfach sowas wie eine aufgeblasene Branch-Unit wie bei R600?
Sah die bei R600 anders aus als bei R700 und später?

Die alten Thread-Sequencer und auch die Branch Unit waren sehr einfach und beschränkt, Sachen wie der Split einer Wavefront (Teile laufen in unterschiedliche Richtungen) oder das Rejoinen wurden wahrscheinlich eine Stufe höher weitergereicht (wie insgesamt Clause-Wechsel über das übliche Alternatieren hinaus). Jetzt kann das innerhalb der CU passieren, die zusätzlichen Latenzen sinken. So eine CU wird gewissermaßen etwas eigenständiger als vorher eine SIMD-Engine.

[Coda]

Wie ist das bei NVIDIA eigentlich gelöst?

[Gipsel]

Mir drängt sich grade die Frage auf, ob es jetzt nicht wahrscheinlicher wird,
dass AMD in Zukunft nicht doch auch CUDA benutzt/lizenziert, wenn sie mit dieser "fermi-artigen" VLIW/SIMD fertig sind.Wieso sollten sie (selbst wenn es möglich wäre)? Mit der neuen Architektur dürften "skalare" Workloads auch auf Radeons besser laufen. Die Frage ist, wieviel Overhead kostet es AMD und ob sie günstiger/effizienter dabei wegkommen als nvidia.

Eigentlich ist es ganz spannend, es ist bei der Architektur im ganz groben eine Art Konvergenz zu beobachten. Bei den Features geht das jetzt etwas über Fermi hinaus, andere Sachen sehen allerdings immer noch einfacher gelöst aus (Scheduler). Es bleibt also spannend, wer da die richtigen Kompromisse gemacht hat und natürlich auch, wie Kepler im Vergleich aussehen wird.

Btw., skalarer Code ist auch für nvidia oft alles andere als optimal. Die profitieren auch häufig von Vektorisierung bzw. allgemein ILP im Befehlsstrom, nicht nur GF104 und Konsorten. Dann benötigt man nämlich weniger Warps, um die GPU auszulasten und Latenzen zu verstecken, was zudem meist effizienter ist als die stupide Erhöhung der Warp-Anzahl.

[Gipsel]

Wie ist das bei NVIDIA eigentlich gelöst?
Daß ist hier doch OT! :freak:

Nein im Ernst, weiß ich jetzt nicht so genau. :redface:
Wenn ich raten müßte, wird das irgendwie in/bei den Schedulern gehandhabt (bzw. haben die auch irgendeine Einheit, die in keinem mir präsentem Blockschaltbild auftauchen, die das macht).

Über die Internas ist bei Radeons m.M. nach etwas mehr bekannt. Kann aber auch einfach daran liegen, daß ich mehr Zeit damit verbracht habe. K.A.

[Coda]

Die profitieren auch häufig von Vektorisierung bzw. allgemein ILP im Befehlsstrom, nicht nur GF104 und Konsorten. Dann benötigt man nämlich weniger Warps, um die GPU auszulasten und Latenzen zu verstecken, was zudem meist effizienter ist als die stupide Erhöhung der Warp-Anzahl.
Kannst du das bisschen erläutern? Das gilt doch eigentlich nur für die 48SP/SM-Chips.

[Gipsel]

Kannst du das bisschen erläutern? Das gilt doch eigentlich nur für die 48SP/SM-Chips.
http://www.cs.berkeley.edu/~volkov/volkov10-GTC.pdf

I.Hide arithmetic latency using fewer threads
II.Hide memory latency using fewer threads
III.Run faster by using fewer threads
IV.Case study: matrix multiply
V.Case study: FFT
Ist provokant formuliert, ist aber was dran. "Occupancy" bezeichnet übrigens dort die Anzahl der Threads im Vergleich zu den maximal möglichen, die die GPU kann/könnte. Im Prinzip läuft es darauf hinaus, daß man nicht nur TLP hat, sondern die Nutzung von ILP auch auf Fermi (auch GF100/110) sinnvoll ist (und dann eben weniger Threads reichen, um die Latenzen zu verstecken). Am Ende kommt er mit Regeln an, die man praktisch 1:1 von Radeons kennt, um die VLIWs auszulasten. Das hilft eben oft beiden. Und nebenbei zitiert er des öfteren den CUDA Programmer-Guide um anschließend zu zeigen, daß die Tips da so nicht ganz stimmen :rolleyes:

Der Volkov ist übrigens der, der seit dem G80 für die nv-GPUs ein paar hochoptimierte Routinen geschrieben hat, von dem gibt es allgemein eine ganze Menge Präsentationen und Veröffentlichungen zu nvidia-GPUs.

[Coda]

Öh, ILP ist dann aber der falsche Ausdruck. Man muss halt möglichst viele Ops vor eine Speicher-Operation schieben, von denen diese nicht abhängt. Die können dann aber beliebig voneinander abhängen. Das würde ich nicht als ILP bezeichnen. Und vor allem muss man dafür keine Vektoren verwenden.

Die GF100-GPUs können per-se ja kein ILP ausnutzen.

[Gipsel]

Öh, ILP ist dann aber der falsche Ausdruck. Man muss halt möglichst viele Ops vor eine Speicher-Operation schieben, von denen diese nicht abhängt. Die können dann aber beliebig voneinander abhängen. Das würde ich nicht als ILP bezeichnen.

Die GF100-GPUs können per-se ja kein ILP ausnutzen.
Sie können kein ILP nutzen im Sinne von simultan vom Scheduler losgeschickten Operationen, das ist richtig.
Dummerweise beträgt aber die Latenz bei Fermi so etwa 20 Takte, selbst für eine einfache Addition (ja, ist ziemlich hoch, Radeons liegen bei 8 Takten). Und für diese 20 Takte will die Pipeline irgendwie gefüllt werden. Das geht nur mit unabhängigen Instruktionen (das Ergebnis liegt ja erst 20 Takte später vor). Wo diese unabhängigen Instruktionen herkommen, ist erstmal egal. Das können andere Warps sein (die per se unabhängig sind, das ist TLP) oder eben auch unabhängige Instruktionen des gleichen Warps, wenn im Instruktionsstrom ILP vorliegt. Und so nutzt Fermi das dann eben doch ;)
Und wie Volkov dort zeigt, sind die entstehenden Algos oft sogar (deutlich) effizienter, als wenn man das Problem stupide mit mehr Threads totzuschlagen versucht.

[Coda]

Ah okay, jetzt versteh ich was er meint. Es geht nicht nur um die Latenz von Speicheroperationen zu verstecken, sondern auch bei normalen Ergebnissen. Das hat mich verwirrt.

Mit weniger Occupancy hat ein Thread ja auch mehr Registerplatz, oder?

[Aquaschaf]

Mit weniger Occupancy hat ein Thread ja auch mehr Registerplatz, oder?

Das ist ja genau der Grund aus dem man mit weniger Threads effizienter arbeiten kann.

[Gipsel]

Das ist ja genau der Grund aus dem man mit weniger Threads effizienter arbeiten kann.
Da gibt es noch ein oder zwei mehr. Z.B. kann man je nach Algo das shared memory z.T. effizienter nutzen (Werte werden öfter wiederverwendet, was heißt, daß man im Endeffekt seltener aus dem Speicher liest). Weiterhin erfolgen die Speicherzugriffe in größeren Blöcken, was das Coalescing einfacher macht.

[M.(to_the)K.]

Wohl alle Folien: http://www.hardware.fr/news/11648/afds-architecture-futurs-gpus-amd.html

Laut Bergman soll wohl diese Architektur schon in den 28nm GPUs zum Jahreswechsel verbaut sein.

schon in der nächsten generation? cschwachsinn. die nächste generation wird erstmal ein refresh in der alles auf vliw 4 umgestellt wird. wäre ja auch etwas dumm extra ne neue vliw 4 architektur zu entwickeln und die nach einem chip schon wieder wegzuscmeißen. :rolleyes:

der nächste chip wird erstmal ein refresh. man wird garantiert nicht alles über die haufen werfen UND auf 28 nm gehen. und das alles in diesem jahr. NO WAY.

[Aquaschaf]

Da gibt es noch ein oder zwei mehr. Z.B. kann man je nach Algo das shared memory z.T. effizienter nutzen (Werte werden öfter wiederverwendet, was heißt, daß man im Endeffekt seltener aus dem Speicher liest). Weiterhin erfolgen die Speicherzugriffe in größeren Blöcken, was das Coalescing einfacher macht.

..und man hat unter Umständen auch einen geringeren Overhead durch Parallelisierung, die Arbeits-Komplexität steigt bei einigen PRAM-Algorithmen beispielsweise logarithmisch mit der Anzahl der Prozessoren.

Die Vereinfachung in den Nvidia-Programmierrichtlinien finde ich deswegen aber nicht verkehrt. Code so zu schreiben dass sie eher mehr Threads verwenden kann einfacher sein, als ihn so zu schreiben dass pro Thread genug ILP vorhanden ist um die Pipeline zu füllen. Ich verstehe bloß nicht, warum sie es überhaupt nicht erwähnen dass es letztlich egal ist ob die Instruktionen die nötig sind um die Pipeline zu füllen aus einem Thread kommen oder aus mehreren.

[M4xw0lf]

schon in der nächsten generation? cschwachsinn. die nächste generation wird erstmal ein refresh in der alles auf vliw 4 umgestellt wird. wäre ja auch etwas dumm extra ne neue vliw 4 architektur zu entwickeln und die nach einem chip schon wieder wegzuscmeißen. :rolleyes:

der nächste chip wird erstmal ein refresh. man wird garantiert nicht alles über die haufen werfen UND auf 28 nm gehen. und das alles in diesem jahr. NO WAY.

Es ist ja nicht so, dass diese neue Architektur von heute auf morgen vom himmel fällt; im zweifelsfall kann die Entwicklung da auch schon vor Monaten oder Jahren angefangen haben.

[AnarchX]

"In a couple of days you are going to hear about our exciting new graphics architecture that will be coming out later this year and will be utilized by our future APUs," said Rick Bergman, senior vice president and general manager of AMD products group.
http://www.xbitlabs.com/news/graphics/display/20110614234623_AMD_Reaffirms_Plans_to_Introduce_Next_Generation_Radeon_Graphics_ Later_This_Year.html

Von Demers gibt es heute Abend vielleicht ein paar greifbarere Daten, wie GFLOPs pro Watt für die 28nm GPUs mit Core Next. Oder Tessellations-Benchmarks. ;D

[M.(to_the)K.]

Es ist ja nicht so, dass diese neue Architektur von heute auf morgen vom himmel fällt; im zweifelsfall kann die Entwicklung da auch schon vor Monaten oder Jahren angefangen haben.

natürlich hat man damit vor längerem begonnen. und eben deshalb wird man das wohl kaum für einen chip gemacht haben. die önderung kosten nämlich einieges an zeit und geld. wieso sollte amd all das geld in eine neue architektur investieren, wenn sie die nur in ienem chip verwenden wollen? das ist reichlich unwirtschaftlich. und gerade amd kann sich sowas eigentlich nicht erlauben. ich aknn mir durchaus vorstellen das man 2012 bei der 2ten 28nm generation, mit mehr erfahrung, ne komplett neue architektur präsentiert. 2011 wird man aber wohl nur 28nm mit vliw 4 architektur vereiniegen. es ist ja schon seit längerem bekannt das cayman mehr eine notlösung war, als klar war das 32nm nicht kommt. also hat man southern island nach hinten geschoben und nothern island ( cayman) in 40 nm released. cayman ist im grunde ein abgespeckter southern island. amd hat also noch was unterm schreibtisch was das lciht der welt erblicken soll. deswegen war auch schon vor moanten vermutlich das tapeout. weil der chip schon ne weile fertig ist und man nur auf tsmc gewartet hat bis amn den nächsten schritt gehen kann.

[fondness]

natürlich hat man damit vor längerem begonnen. und eben deshalb wird man das wohl kaum für einen chip gemacht haben. die önderung kosten nämlich einieges an zeit und geld. wieso sollte amd all das geld in eine neue architektur investieren, wenn sie die nur in ienem chip verwenden wollen? das ist reichlich unwirtschaftlich. und gerade amd kann sich sowas eigentlich nicht erlauben. ich aknn mir durchaus vorstellen das man 2012 bei der 2ten 28nm generation, mit mehr erfahrung, ne komplett neue architektur präsentiert. 2011 wird man aber wohl nur 28nm mit vliw 4 architektur vereiniegen. es ist ja schon seit längerem bekannt das cayman mehr eine notlösung war, als klar war das 32nm nicht kommt. also hat man southern island nach hinten geschoben und nothern island ( cayman) in 40 nm released. cayman ist im grunde ein abgespeckter southern island. amd hat also noch was unterm schreibtisch was das lciht der welt erblicken soll. deswegen war auch schon vor moanten vermutlich das tapeout. weil der chip schon ne weile fertig ist und man nur auf tsmc gewartet hat bis amn den nächsten schritt gehen kann.

Was genau verstehst du an "will be coming out later this year " nicht? Es ist ja schön wenn man eine eigenen Meinung hat, aber Fakten sollte man dann doch nicht ignorieren.

[M.(to_the)K.]

naja vllt. macht man es dann wie bei der 6000er. der "pipe-claener" alias 7800 wird ne vliw 4 architektur und im dezember kommt mit der 7900 was komplett neues. wird vliw 4 nicht auch noch in den lliano nachfolgern in der gpu verbaut?

also ist es nur die aussage eines mitarbeiter oder wurde das auf der Konferenz offiziell verkündet das diese architektur "later this year" erscheint?

[fondness]

also ist es nur die aussage eines mitarbeiter oder wurde das auf der Konferenz offiziell verkündet das diese architektur "later this year" erscheint?

Die Aussage kam von Rick Bergman höchst-persönlich, seines Zeichens Boss der gesamten AMD-Produkt-Entwicklung. Wenn er das sagt dann stimmt es auch.

[M.(to_the)K.]

ok, dann gebe ich mich geschlagen. ;)

ich hoffe der pipecleaner kommt bald. der würde dann super zum bulldozer passen. dann könnte man gleich passend zu der neuen schnellen cpu die passende graka präsentieren.

naja ist vllt. nicht schlecht. mit noch mehr vliw 4 shadereineheiten wäre die programmierung wohl reichlich haarig geworden. der pipe-clenaer bleibt ja vllt. sogar bei 1536 shadern. vllt. wird nochmal leicht erhöht. dank 28nm wäre der cayman dan ja locker auf barts-größe. wäre super ne verbesserte 6970 für 200 euro zu bekommen.

die neue architektur scheint vom r600 ja nicht mehr viel übernommen zu haben. 5 jahre entwicklungszeit sprechen ja ne duetlich sprache. man kann nur hoffen das man diesmal das volle potenzial gleich entfalten kann. wie nvidia seinerzeit mit dem g80. ne neuauflage vom r600 oder gf100 kann man nciht gebrauchen. naja man kann amd nur die daumen drücken das es klappt.

[Screemer]

[...]and will be utilized by our future APUs," said Rick Bergmantrinity mit next kernen? kann sich das schon einer vorstellen?

[Ailuros]

Ist doch abgebildet: Unabhängige Geometrie- und Rastereinheiten. Also wie bei Fermi.
Wobei ich nicht weiß, ob diese sich weiterhin außerhalb der Cores befinden oder wie bei nVidia eine Einheit in Gruppen bilden.

/edit: Laut der Folie befinden sie sich außerhalb.

Ich weiss zwar nicht was AMD angestellt hat, aber ich koennte mir gut vorstellen dass sie diese sogar vor den ALUs untersucht haben fuer moegliches hot-clocking.

[AnarchX]

naja vllt. macht man es dann wie bei der 6000er. der "pipe-claener" alias 7800 wird ne vliw 4 architektur und im dezember kommt mit der 7900 was komplett neues. wird vliw 4 nicht auch noch in den lliano nachfolgern in der gpu verbaut?
Natürlich wäre es denkbar das Core Next wieder nur im High-End-Chip verbaut wird.



also ist es nur die aussage eines mitarbeiter oder wurde das auf der Konferenz offiziell verkündet das diese architektur "later this year" erscheint?
Senior Vize Präsident von AMD.

[Coda]

Vor allem wird das Ding auch ohne Flimmer-AF kommen und wird offenbar ordentlich Geometry- und Rechenleistung haben. Was können sie denn bitte noch falsch machen?

[Gipsel]

Vor allem wird das Ding auch ohne Flimmer-AF kommen und wird offenbar ordentlich Geometry- und Rechenleistung haben. Was können sie denn bitte noch falsch machen?
Zu wenig Einheiten, fehlender Takt/zuviel Verbrauch oder einfach Verspätung. Schiefgehen kann immer viel.

[Coda]

Das war auch eher rhetorisch gemeint ;)

[HOT]

trinity mit next kernen? kann sich das schon einer vorstellen?
Trinity bekommt denke ich wirklich die Cayman VLIW-Kerne. Ich kann mir nicht vorstellen, dass da next schon drin ist, immerhin ist Trin ja schon offiziell vorgeführt worden. MMn ist next noch nicht soweit. Allerdings kann der Kram durchaus in der nächsten Bobcat-Generation enthalten sein und vllt. gibts später nochmal ein Trinity-Refresh late 2012. Man weiss ja, was man von AMD-CPU-Roadmaps halten kann, die sich über 2 Jahre erstrecken :D.

[Tesseract]

Was können sie denn bitte noch falsch machen?

die profile geschlossen halten. :down:

[Nakai]

Vor allem wird das Ding auch ohne Flimmer-AF kommen und wird offenbar ordentlich Geometry- und Rechenleistung haben. Was können sie denn bitte noch falsch machen?

Eine CU hat ja 4*16er SIMDs. Das wäre von der Rohleistung ziemlich genau mit einer SIMD des alten VLIW-Designs zu vergleichen(nur Rohleistung(!)). Das Drumherum der Architektur wurde ja noch nicht geklärt. Ergo Tex:ALU-Verhältnis unbekannt. Ebenso Rasterizer und Tesselator unbekannt.
Ansonsten gleich man sich ziemlich an NV an, jedenfalls bzgl des groben Aufbaus. Werd mich aber da nochmal reinlesen.


mfg

[Gipsel]

Eine CU hat ja 4*16er SIMDs. Das wäre von der Rohleistung ziemlich genau mit einer SIMD des alten VLIW-Designs zu vergleichen(nur Rohleistung(!)). Das Drumherum der Architektur wurde ja noch nicht geklärt. Ergo Tex:ALU-Verhältnis unbekannt.Nicht ganz. Man kennt bereits die Bandbreite des L1 (64 Byte/Takt), was identisch zu den bisherigen Texture-L1 ist. Da wird also aller Wahrscheinlichkeit auch wieder eine Quad-TMU dranhängen für 4x16 ALUs. Ist ziemlich das gleiche Verhältnis wie bei GF100/110, wo 2*16 ALUs (mit doppeltem Takt) auch an einer Quad-ALU hängen. GF104/114 (alle Designs mit 48 ALUs und 8er TMU) haben im Verhältnis mehr Texturleistung. Aber die TMUs könnten bei AMD noch effizienter werden, insbesondere bei Fließkomma/HDR-Formaten, falls das nötig sein sollte.

[Gipsel]

Schon mal sorry für den langen Post, ich versuche den mal zu strukturieren.
Wie gesagt, muß man sich noch mal im Detail (die AMD aber vielleicht noch gar nicht verrät) anschauen (Was kann jede Einheit? AMD spricht von float ALUs die 32bit Integer-Operationen können. Jeweils alle? Wie schnell?), aber AMD investiert doch merklich in mehr Verwaltung und erhöhte Effizienz, was hoffentlich nicht an anderen Ecken zu Sparversuchen führt, die dann wieder bremsen. Auf jeden Fall scheint sich AMD von der festen Kopplung der Ausführungslatenz der Einheiten an die grundlegende Architektur verabschiedet zu haben (bisher 8 Takte). Dies würde es im Prinzip wie bei nvidia ermöglichen, den Takt durch eine andere Auslegung der Pipeline (deutlich?) anzuheben.
So, ich habe mir das Ganze nochmal durch den Kopf gehen lassen und will hier mal mit einer alternativen Deutung (fast nur der CUs) ankommen, die in der Tendenz dann doch deutlich vom Fermi-Weg abweichen würde. K.A. ob das so kommt und ehrlich gesagt ist es in einigen Punkten vielleicht ein wenig optimistisch, aber ich denke die veröffentlichten Folien könnten das hergeben.


Bisherige Situation bei Radeons:

Die Radeon-ALUs haben eine fixe Ausführungslatenz von 8 Takten. Eine Wavefront (64 Elemente breiter Vektor) wird über 4 Takte von 16 Einheiten verarbeitet. Daraus ergibt sich, daß man 2 Wavefronts abwechselnd ausführen muß, um die ALU-Latenzen zu verstecken. Dies speiegelt sich in der Scheduling-Hardware wieder, jede SIMD-Engine hat 2 "Thread Sequencer", die die SIMD-Engine abwechselnd mit Anweisungen für jeweils eine Wavefront versorgen (genau eine Wavefront pro Sequencer). Der Code wird vom Compiler in "Clauses" strukturiert, die ohne Unterbrechung direkt und stupide von den Sequencern Anweisung für Anweisung an die Einheiten gegeben werden können. Speicherzugriffe und Kontrollfluß machen jeweils eigene Clauses auf. Nur an Clause-Grenzen wird die Wavefront von einem Sequencer gewechselt (weswegen Clausewechsel mit sehr geringer Frequenz gemanaged werden). Innerhalb einer Clause ist garantiert, daß für alle Anweisungen alle Abhängigkeiten aufgelöst sind. Abhängigkeiten müssen also nur zwischen ganzen Clauses gecheckt werden, nicht zwischen einzelnen Anweisungen. Dies macht ein Großteil der Ersparnis am Scheduling und Verwaltungsoverhead bei Radeons aus.

Vergleich mit nvidia:

Die ALUs haben eine variable Ausführungslatenz irgendwo zwischen 18 Takten (Fermi single precision) über 24 Takte (G80/Tesla single precision) bis zu 48 Takten (Tesla double precision, Integer Multiplikation). Die Scheduler verwalten deswegen (und auch weil es shared Einheiten gibt, wie SFUs, L/S-Einheiten) die Abhängigkeiten und Resourcen-Konflikte für jede einzelne Instruktion vieler Warps über ein Scoreboarding-System. Es gibt viel mehr Instruktionen in flight. Bei Fermi müssen alle 2 Takte (hotclock, oder eben jeden Takt bei Basisfrequenz) die Abhängigkeiten überprüft werden, damit eine oder zwei (bei SMs mit 48 ALUs) passende Instruktion vom Scheduler ausgewählt werden kann. Die ALUs laufen mit knapp doppeltem Takt, die absoluten Latenzen sind also für single precision nur grob 30% höher als bei ATI. Ein Großteil davon wird wahrscheinlich vom "Operand Collector" und Result Netzwerk verschlungen, dieses ist bei Radeons prinzipiell einfacher bzw. durch die Pipeline-Struktur maskiert.


Die Architektur wurde wahrscheinlich auch schon im Hinblick einer Integration in die CPU entworfen, und damit meine ich nicht das "Danebensetzen" einer iGPU neben die CPU-Kerne, sondern einer mittel- bis langfristigen Integration in die CPU.
Bei der Entwicklung soll erstmals auf breiter Front Knowhow der CPU-Ingenieure eingeflossen sein. Die bauen ja auch SIMD-Einheiten, wenn auch deutlich schmaler, aber dafür (ist bei K7 bis K10/Llano so) mit Latenzen von 4 Takten (für DP!) bei Taktraten über 3 GHz (allerdings mit einem um grob eine Größenordnung höherem Aufwand an Silizium dafür).
Evergreen/Cayman können abhängige Instruktionen in eine VLIW-Instruktion packen, was zeigt, daß die Einheiten an sich in SP auch nur maximal 4 Takte für die Operationen benötigen. Das Problem ist wohl eher das Fetchen der Operanden und das Result-Netzwerk. Gerade damit haben die CPU-Leute unheimlich viel Erfahrung.
AMD ist "on record", daß die neue Architektur nicht viel mehr Platz einnimt als die alte VLIW, einige Sachen werden aufwendiger, andere einfacher, die Einheitenzahl soll weiter (kräftig) steigen.


Die neue Architektur senkt die Instruktionslatenz auf 4 Takte. Der Takt bleibt damit bei <~1GHz.

Wie gesagt können die ALUs selber das locker. Da jede Wavefront über 4 Takte ausgeführt wird, kann die nächste Instruktion sogar wenn sie vom Resultat der vorhergehenden abhängig ist direkt hinterher ausgeführt werden (Hinweis: in der Präsentation steht beim Vergleich VLIW zu neu neben dem oben erklärten "interleaved wavefront instruction required"= 8 Takte als Vorteil für die neue Architektur "vector back-to-back wavefront instruction issue"= 4 Takte?). Man spart sich also komplett das Verfolgen der Abhängigkeiten der arithmetischen Instruktionen (nur Speicherzugriffe und LDS müssen beachtet werden). Wenn eine Einheit frei ist, kann der nächste Befehl kommen. Das gilt zumindest für die SIMDs (also die Vektor-Alus) und die skalare ALU, der Rest verkompliziert das wieder etwas.

Im Endeffekt heißt das, daß jeder "Sequencer" (die Blöcke wo "SIMD PC & IB" drinsteht) für genau einen SIMD-Block zuständig ist. Meiner Deutung nach ist jeder Sequencer reihum an der Reihe, also immer alle 4 Takte um die nächste(n) Instruktion(en) für "seine" Wavefronts an "seinen" SIMD-Block (oder auch eine skalare) zu liefern. In dieser Beziehung bleiben die Sequencer also extrem einfach. Aufgebohrt werden sie insofern, als daß sie für je (mindestens) 10 Wavefronts einen kleinen Instruction-Buffer (da alles in-order ist, entspricht das praktisch 10 kleinen FIFOs) besitzen, so daß jetzt viel schneller zwischen Wavefronts gewechselt werden kann (ohne irgendeine Latenz, bisher wohl an die 40 Takte, sprich, wenn man viele Clauses mit weniger als 10 Instruktionen hat, verliert man Performance, weil die Latenz nicht mehr versteckt werden kann).

Wenn die Sequencer jetzt einfach jeden 4. Takt eine Instruktion losschicken würden, ergäbe das Problem, daß maximal 4 Instruktionen/4 Takte von den 4 Sequencern zusammen kommen können, die 4 SIMDs auch 4 Instruktionen/4 Takte verarbeiten können, allerdings sobald ein Speicherzugriff/local memory/branch oder skalare Instruktion kommt, mindestens 1 SIMD leersteht. Im Prinzip genau das gleiche wie bei GF100/GF110, wo zwei issue ports zwei 16er Vector-ALUs, L/S-Einheiten sowie SFUs versorgen müssen. Der lebt zwar auch ganz passabel damit, allerdings dürfte das bei AMD anders funktionieren.

Die Sequencer sind passiv und nicht viel mehr als eine Ansammlung von ein paar FIFOs, können aber mehrere Befehle liefern, solange sie von verschiedenen Wavefronts kommen (da müssen für Vektor-Befehle auch keine Abhängigkeiten beachtet werden). So saturiert man ziemlich sicher die Einheiten, die Folien lassen dies als wahrscheinlich erscheinen.

Die Last liegt so oder so auf dem "instruction arbitration" mit den nachgestellten 6 issue ports (dem eigentlichen Scheduler der CU). Da ist die Präsentation (zumindest die Folien, vielleicht wurde es ja gesagt) nicht wirklich klar, worauf sich die dort aufgeführten Bedingungen/Beschränkungen genau beziehen (und bedeutungsverwirrende kleine Fehler gibt es auch noch).
So oder so arbeitet das Ding offenbar auch in einem round robin Verfahren. Jeden Takt kommen die Wavefronts eines anderen SIMDs an die Reihe, allerdings alle davon (laut Präsentation liegt die Kapazität bei mindestens 10). Es werden aus den jeweils ältesten Einträgen jedes Instruction Buffers im dazugehörigen Sequencer (davon gibt es 10+) maximal 5 ausgewählt, maximal eine pro Wavefront/Instruction Buffer (also kein super"skalares" issue wie bei GF104/114) und maximal eine pro Instruktionsklasse (Vektor, skalar, Branch, Speicherzugriff, local memory-Zugriff, Export/GlobalDataShare). Wenn also eine Wavefront einen skalaren Befehl ausführt oder auf das local memory zugreift, wird die Vektor-Einheit einfach einem Befehl einer anderen Wavefront gefüllt.

Ist die Latenz der Vektor- und Skalar-Einheiten jeweils 4 Takte, so müssen keinerlei Abhängigkeiten berücksichtigt werden. Für Befehle die aufwendiger sind (double Precision, Integer-Multiplikation, Transcendentals) und dann z.B. 8 Takte (half rate DP soll laut hardware.fr erwähnt worden sein, konfigurierbar zwischen 1/2 und 1/16) oder 16 takte (1/4 Rate) Latenz haben, reicht es einfach das Issue zu der betreffenden Einheit für die Dauer der Belegung zu unterlassen (man weiß ja vorher, wie lange es dauern wird), das wird also sehr einfach.
Solange gilt: Latenz (für ein Datenelement) = Durchsatz (für die ganze Wavefront), sieht das für den Scheduler wie eine in-order unpipelined Einheit aus, da braucht man kein ausgefeiltes Scheduling für, da es einfach keine Konflikte im Sinne von Abhängigkeiten zwischen den Instruktionen geben kann. Und da es per Definition zwischen verschiedenen Wavefronts ebenfalls keine Abhängigkeit gibt (außer über LDS, Speicherzugriffe bzw. Barriers), kann die skalare und die Branch-Unit genauso einfach verwaltet werden.

Nur für den Speicher-/LDS-Zugriff muß man mehr Aufwand treiben (Instruktionen, die das Zielregister des Lesevorgangs benutzen wollen nicht schedulen, bis der fertig ist, hält die entsprechende Wavefront praktisch solange an).


Immer noch ziemlich einfache Scheduler, die aber trotzdem bei "skalaren" Problemen ordentlich Performance bieten sollten.
Durch die Möglichkeit pro Takt Instruktionen von mehr als einer Wavefront abzusetzen, hat man ein Loadbalancing zwischen den Wavefronts auf einem SIMD, um z.B. auch bei Code mit viel Kontrollfluß die Einheiten maximal auszulasten. Dies ist gewissermaßen eine orthogonale Entwicklung zu nvidias "dual issue", welches ILP benötigt. Das wäre dem neuen AMD-Ansatz vollkommen egal, TLP ist das, was zählt, eine doch schon deutliche Wende.

Beispiel: 50% Vektoranweisungen, 50% skalare Anweisungen/Branches
Trotz dieses für GPUs recht extremen Codemixes ist es prinzipiell möglich, sowohl die Vektor-, als auch die Skalar-Einheiten maximal auszulasten, d.h. das Ganze ohne unnötigen Performanceeinbruch zu absolvieren. Es werden pro Takt im Optimalfall jeweils eine skalare Anweisung/Branch einer Wavefront sowie eine Vektor-Instruktion einer anderen Wavefront ausgeführt, also Instruktionen von 8 Wavefronts/4 Takte! :cool: Ziemlich cool, wenn das so klappen sollte.

Der Kontrollfluß bleibt komplett in der CU, bei der alten Lösung waren neben den Thread-Sequencern auch der UTDP (ultra threaded dispatch processor soll das heißen) beteiligt. Nur unter dessen Mitwirkung können wohl die Clauses in den Sequencern getauscht werden.
=> Das war langsam (AMD behauptet auch mehr Energieverbrauch als mit der neuen Lösung)

Minderaufwand:
Instruktionen sind deutlich kleiner (nur 4 Byte + optionale 4 Byte Immediates, 4 Instruktionen liegen also zwischen 16 und 32 Byte; R600 bis Cayman haben 8 Byte pro VLIW-Slot + 2 x 8 Byte Immediates, d.h. maximal 48 Byte für VLIW4, 56 Byte für VLIW5), Instruktionscache wir effizienter genutzt/muß nicht gesteigert werden.

Und der Shadercompiler wird natürlich tendenziell einfacher, weil alle möglichen Auswahlregeln beachtet werden mußten und direkt in die Anweisungen codiert wurden (z.B. die Abfolge der Bänke, von denen aus dem Registerfile gelesen wird, da gibt es ein paar beinahe esotherische Wechselwirkungen mit Swizzles, die vom Compiler bedacht und dann entsprechend codierte Anweisungen erzeugt werden müssen, im Prinzip konfiguriert die Anweisung selbst das "operand collector" Netzwerk). Nun handhabt das die Hardware komplett selber (was aber wohl ein gewisses Aufbohren der entsprechenden Teile erfordert).


Kein Loadbalancing zwischen den einzelnen SIMDs.
Eine Wavefront ist auf ein SIMD festgepinnt (G80/Tesla haben das wohl auch so gemacht) und kann nicht dazwischen wechseln (zumindest nicht so einfach). Praktisch gesehen halte ich das meist für zu verschmerzen. Auswirkungen würde es zeigen, wenn man Aufgaben mit deutlich ILP aber sehr wenigen Threads hat, die von den Vektor-ALUs limitiert sind (für speicherlimitierte Szenarien speilt das keine Rolle, weil sich alle SIMDs die Speicherpipeline teilen). Da könnte der letzte übrigbleibende alle ALU-Blöcke auf Fermi nutzen, hier nicht. Allerdings dürfte Fermi in dem Fall die lange Latenz seiner Pipeline stören, so daß das kaum zu einem Nachteil führen dürfte. Die neue AMD-Architektur benötigt minimal 4 Wavefronts = 256 Data Elements ("Threads") pro CU, um die Vektor-ALUs voll auszulasten, egal wie viel ILP vorliegt (Cayman benötigt minimal 2 Wavefronts pro SIMD-Engine, allerdings muß so oder so noch ILP vorliegen, komplett ohne ILP kommt Cayman nie höher als AMDs NG-GPU theoretisch schon mit nur einer Wavefront). GF100/110 benötigen nämlich ~576 Data Elements (18 Warps) bei ILP=1 und minimal 192 Data Elements (6 Warps) bei ILP=4 (mehr ILP hilft nicht mehr, daß scheint die Tiefe des Fensters zu sein, die die Fermi-Scheduler betrachten). Also selbst bei maximalem ILP benötigt GF100/110 fast genau so viele Datenelemente, um nur die Ausführungslatenzen zu verstecken. GF104/114 liegt da grob 50% schlechter (864 Datenelemente=27 Warps bei ILP=1 nötig).

Weiterhin sinkt die einem Thread zur Verfügung stehende Registergröße (weil bei gleicher Gesamtgröße von 256kB wohl tendenziell mehr Wavefronts laufen werden). Bisher kann ein Datenelement in einer Wavefront problemlos auf die x,y,z,w-Registerbänke aller VLIW-Slots (bestimmen die Bank, in die geschrieben wird) zugreifen. Jetzt wird praktisch eine Bank zum Registerfile eines SIMDs, es steht weniger Platz darin zur Verfügung. Dies wird etwas kompensiert durch die effizientere Nutzung der Register (vorher mit 128Bit-Granularität alloziert) und durch die geringere Latenz der Wavefronts, weswegen auch weniger laufen müssen, um die Latenzen zu verstecken. Allerdings ist AMD mit 256 kB pro CU immer noch gut dabei, wenn man mal mit nvidia vergleicht (128 kB/SM bei wie ausgeführt vergleichbar oder gar höherer Anforderung an die Anzahl der Datenelemente [Threads]).

Mehraufwand:

4 "Sequencer" pro CU mit insgesamt 40+ kleinen FIFOs für Instruktionen (statt nur 2 pro SIMD-Engine bei R600 bis Cayman)
Scheduling-Aufwand wird moderat (war vorher in den SIMD-Engines fast nicht-existent), da es praktisch nur für Speicherzugriffe erfolgen muß, aber immerhin sind 4 mal so viele Instruktionen unterwegs (auch wenn sie deutlich kleiner sind).
Zusätzliche skalare Einheit mit eigenem Registerfile (8kB), eigenem Speicherzugriff über eigenen 16kB L1-Cache (read only, geteilt mit 3 weiteren CUs)
Instruktionscache nicht mehr pro "graphics engine" (diese Ansammlungen von 7 [Barts] bis 12 [Cayman] SIMD-Engines mit eigenem Rasterizer-Block) sonern 32kB pro 4 CUs.
Local memory auf 64 kB verdoppelt (ist natürlich auch ein Vorteil :rolleyes:)
16kB (Cayman hat 8kB) L1-Cache jetzt R/W (delayed write-through bei Beendigung des Kernels für die jeweilige Wavefront, Kohärenz-Protokoll vom Programm steuerbar), gleichzeitig Texture-L1 (Texturen werden beim Lesen bei Bedarf on-the-fly dekomprimiert), nominelle Bandbreite bleibt gleich (was heißt, daß da wohl wieder 4 TMUs dranhängen werden). L1<=>L2-Bandbreite wird übrigens angeblich halbiert (zumindest pro Speicherkanal)?!
laut hardware.fr angeblich optional half rate double precision
Und als letzter Punkt:
Wahrscheinlich aufwendigeres Design der Registerfiles/Operand Collector-/Result-/Bypass-Netzwerke, um die 4 Takte Latenz zu schaffen. Etwas wird es wohl davon kompensiert, daß Wavefronts an ein SIMD festgepinnt sind. Betrachtet man die 4 SIMDs als die 4 eigenständiger gewordenen VLIW4-Slots des Cayman, so kann man im Vergleich auf diesen ganzen Swizzle-Kram des Lesens von den 4 x,y,z,w-Bänken verzichten. Cayman hat im Prinzip pro SIMD 16 Registerfiles, die jeweils 4 Bänke mit jeweils 3 Read- und einem Writeport hatten. Das Lesen von den einzelnen Bänken und Verteilen auf die einzelnen Slots kostete einfach Zeit, die man jetzt sparen kann. Der Preis erscheint moderat, man benötigt 4 x 16 Registerfiles (statt 16 mit je 4 Bänken) mit jeweils 3 Read- und einem Writeport und kann sich dieses ganze Umverteilen sparen (die alte Designentscheidung klingt bei Cayman nicht mehr so einleuchtend, aber bei VLIW5 war das noch recht clever). Während eine alte VLIW-Anweisung also 12 Operanden aus dem Registerfile (+ maximal 5 Pipelineregister, für madd benötigt man bei VLIW5 maximal 15 Operanden) lesen und praktisch beliebig auf die einzelnen Slots verteilen konnte, entfällt jetzt dieser Verteilungsschritt. Man hat einfach 4 mal so viele Registerfiles (mit einem Viertel der Größe), die Daten werden nicht mehr ganz so weit rumgeschickt.

[Coda]

Gute Theorie, aber:

Meinst du wirklich, das CPU-Ingineure ihren GPU-Kameraden so überlegen sind? Kann ich mir vor allem durch die starke Personal-Rotation in dem Bereich nicht so sehr vorstellen.

[LovesuckZ]

Mehr Informationen (von heute?): http://www.pcper.com/news/Graphics-Cards/AMD-Fusion-Developer-Summit-2011-Live-Blog

[Gipsel]

Gute Theorie, aber:

Meinst du wirklich, das CPU-Ingineure ihren GPU-Kameraden so überlegen sind? Kann ich mir vor allem durch die starke Personal-Rotation in dem Bereich nicht so sehr vorstellen.
Nicht unbedingt überlegen, aber die machen das eben schon seit 20 Jahren. Deswegen schrieb' ich, die haben damit verdammt viel Erfahrung, weil es dort einfach wichtig ist. Bei GPUs hat das einfach keine Priorität gehabt. Das Dogma ist/war: Latenzen versteckt man einfach mit mehr Threads, fertig ist die Soße. Da war die Priorität eher, eine Einheit, die 1 FMA/Takt kann, möglichst klein und energiesparend zu bekommen.

Der Unterschied zwischen K10 mit 4 Takten bei 3.7 GHz für eine DP-Multiplikation (~1,1 ns) und Fermi mit 36 (?) Takten bei 1,6 GHz (22,5 ns) für das Gleiche ist schon ziemlich groß, selbst wenn man den unterschiedlichen Flächenverbrauch berücksichtigt. Das können kaum die Ausführungslatenzen selber sein (siehe den abhängigen Operationen in einer VLIW-Anweisung), bei Fermi gab es in einem Hintergrundartikel (RWT? B3D?) sogar mal explizit die Erwähnung dieser Operanden-/Resultat-Netzwerke, die ein beträchtlicher Faktor sind. Bei CPUs ist der Aufwand da meist riesig, um ja keinen Takt Latenz (insbesondere bei den Integer-Kernen) zu verschenken. Das ist also sozusagen deren täglich Brot.

Aber vielleicht schreibt David Kanter ja demnächst mal einen Artikel zu der Architektur, der war wohl da. Oder wir warten bis Herbst/Winter, dann werden wir es eventuell erfahren.

[fondness]

Die sind wohl neu:

http://img716.imageshack.us/img716/649/phpuovx0506.jpg (http://img716.imageshack.us/i/phpuovx0506.jpg/)
http://img805.imageshack.us/img805/5802/php0nkotf08.jpg (http://img805.imageshack.us/i/php0nkotf08.jpg/)
http://img35.imageshack.us/img35/9357/phphrvnei09.jpg (http://img35.imageshack.us/i/phphrvnei09.jpg/)
http://img853.imageshack.us/img853/6853/phpt7z9tv10.jpg (http://img853.imageshack.us/i/phpt7z9tv10.jpg/)
http://img853.imageshack.us/img853/3937/phppiqte511.jpg (http://img853.imageshack.us/i/phppiqte511.jpg/)
http://img28.imageshack.us/img28/8406/php6rleaf12.jpg (http://img28.imageshack.us/i/php6rleaf12.jpg/)

[Gipsel]

Mehr Informationen (von heute?): http://www.pcper.com/news/Graphics-Cards/AMD-Fusion-Developer-Summit-2011-Live-Blog
Fondness hat schon ein paar Folien gepostet, die im Prinzip netter aussehen, und wo z.T. weiterführende Informationen draufstehen. Daß die 4 Boxen mit "PC & Instruction Buffer" jetzte jeweils mit SIMD0, SIMD1, SIMD2, SIMD3 benannt sind, bestätigt zumindest schon mal den Teil meines Deutungsversuches. Die eine Folie klärt auch die Sache mit der L1/L2-Bandbreite auf. Bei einem 256Bit-Speicherinterface wird es nicht halbiert, sondern eher verdoppelt im Vergleich zu Cayman (der nicht mehr Bandbreite/Takt dort hat als schon ein RV770, das wird also auch mal Zeit).

Ich finde ja den Punkt "Supports x86 virtual memory" ganz interessant.

PS:
PC = program counter, heißt bei CPUs normalerweise instruction pointer

Edit:
Und nochmal die Aussage, es gibt von 1/2 oder 1/4 DP Rate bis 1/16 DP Rate je nach Markt. Und ganz am Ende die Bestätigung, daß die ersten GPUs mit der Architektur noch dieses Jahr rauskommen.

[Coda]

Öh, was ist denn FSA?

Das mit dem virtuellen Speicher war aber eigentlich klar. Das hab ich für die nächste Gen schon erwartet. Aber eher von NVIDIA.

Interessant wird, wie sie da über PCI-Express die Cache-Kohärenz sicherstellen.

[Gipsel]

Öh, was ist denn FSA?
Fusion System Architecture

Da der Aufbau der CUs und der GPU an sich identisch zu den Graphics core Next bzw. der "Compute Unit Architecture" ist, werden wir das wohl bis Ende 2012 im übernächsten Fusion sehen (nach Trinity), nachdem das Ende dieses Jahres in einer diskreten Karte debütieren soll.
Das mit dem virtuellen Speicher war aber eigentlich klar. Das hab ich für die nächste Gen schon erwartet. Aber eher von NVIDIA.Na, denen verbietet das doch keiner! :D
Interessant wird, wie sie da über PCI-Express die Cache-Kohärenz sicherstellen. Ich glaube, daß steht erst bei der überübernächsten Generation 2013 an (vorher geht das wohl nur innerhalb einer APU).

[S940]

(vorher geht das wohl nur innerhalb einer APU).
Auf den Folien steht per IOMMU, die gibts seit dem 890FX, alle 900er haben es jetzt.

[Coda]

Es ist die IOMMU der GPU gemeint, nicht die des Chipsatz. Die gibt es bei PCIe-Grafikkarten schon immer, aber nicht in dieser Komplexität. Bei AGP war die noch im Chipsatz, weil es immer nur eine GPU gab.

Außerdem steckt die IOMMU des Chipsatzes in der Northbridge, also im Prozessor selbst (das war mal die AGP-GART). Das hat nix mit der Southbridge zu tun.

[S940]

Es ist die IOMMU der GPU gemeint, nicht die des Chipsatz

Ok, das kapier ich noch, und glaube es DIr auch, aber beim Rest wirds irgendwie konfus:

Außerdem steckt die IOMMU des Chipsatzes in der Northbridge, Meinte ich doch, oder was soll sonst mit 890FX gemeint sein :confused:
also im Prozessor selbst (das war mal die AGP-GART).
Naja, solange man nen 890FX Chipsatz braucht anscheinend nicht ;-) Kurz: Nur bei Llano & Brazos.
Das hat nix mit der Southbridge zu tun.
Wieso jetzt auf einmal Southbridge :confused:

Naja, aber wohl egal, wichtig war Deine erste Aussage.

[Coda]

Meinte ich doch, oder was soll sonst mit 890FX gemeint sein :confused:
Die IOMMU ist in der CPU.

Naja, solange man nen 890FX Chipsatz braucht anscheinend nicht ;-) Kurz: Nur bei Llano & Brazos.
Es kann sein, dass da noch eine IOMMU verbaut wird, die für PCIe-Geräte fungiert, die keine eigene haben. Aber dann wird's wirklich konfus.

Wieso jetzt auf einmal Southbridge :confused:
Southbridge = Alles auf dem Board, Northbridge = CPU.

Ist logisch fortgeführt von früher einfach so. Man spricht auch immer von "integrated Northbridge".

[S940]

Die IOMMU ist in der CPU.
zusammen mit:
Es ist die IOMMU der GPU gemeint, nicht die des Chipsatz.
Also die IOMMU für die GPU ist in der CPU ?


Es kann sein, dass da noch eine IOMMU verbaut wird, die für PCIe-Geräte fungiert, die keine eigene haben. Aber dann wird's wirklich konfus.Wie besagt, seit 890FX gibts das auch bei den "umgelabelten" Serverchipsätzen:
http://www.amd.com/de/products/server/platforms/Pages/server-platforms.aspx
Allerdings stehts unter Virtualisierung, ist das vielleicht dann was anderes ?

Southbridge = Alles auf dem Board, Northbridge = CPU.

Ist logisch fortgeführt von früher einfach so. Man spricht auch immer von "integrated Northbridge".
Hm ok, wenn Dus so siehst. Bins aber eher gewohnt, dass man bei AMD die Hypertransport I/O Bridge als NB bezeichnet. Die NB in der CPU dann eben integrated NB, und die Southbridge ist das Teil, das auf den Namen SBxxx hört ;-). Im obigen Link bei der Serverplattform stehts z.B. genauso drin (wobei dei Southbridgebezeichnungen bei den Servern anders sind).
Aber egal, hat sich ab Llano dann eh erledigt und Intel ist eh schon soweit ^^

[Coda]

Also die IOMMU für die GPU ist in der CPU ?
Früher mal für AGP. Heute nicht mehr.

Heute ist die IOMMU in der CPU dazu da die Hardware-Adressen der PCI-Geräte zu verbiegen.

Ganz ehrlich: Ich steig da auch nicht mehr durch. Es gibt mit dem 890FX dann mindestens drei IOMMUs und ich kann mir gerade auch kein ganzes Bild mehr davon machen, welche was tut.

[Screemer]

das wäre doch mal ne nachfrage wert ;)

[john carmack]

mal so nebenbei... bevor ich einen neuen Thread öffne.

Können Grafikkarten mehr als 4GB Speicher adressieren?

Wie läuft das bei Grafikkarten?


Wie das bei Windows 32Bit/64Bit geht, verstehe ich ja. Aber wie funktioniert das bei GraKa´s?

wird es bald "64Bit" GPU´s geben?

[Maorga]

Ja, das sollten sie können, da sie nur ein 256MB Fenster dem System zeigen welches darauf Zugriff hat. Intern verwaltet die Grafikkarte alles selber und da sollte auch mit 4GiB keine Probleme geben. Nein es wird keine 32/64 bit GPUs geben :) Die können ja ihren Adressraum so gestalten wie sie wollen vielleicht 48 Bits oder 156 :)

[Gipsel]

Hat nicht nvidia mal gesagt, Fermi könne bis 40 Bit physisch adressieren? Mehr als 32Bit sind ja schon nötig, um die 6GB-Teslas betreiben zu können. CPUs stehen momentan glaube ich bei physisch 48 Bit (K8 hat auch mit 40Bit angefangen). Der virtuelle Adressraum kann jeweils größer sein.

AMD hat jetzt gesagt, daß man für GPUs und (x86-)CPUs/APUs einen gemeinsamen Adressraum schaffen wird, so daß die 64Bit-Zeiger der CPU auch auf der GPU funktionieren (und umgekehrt). Komplett mit Unterstützung des virtuellen Adressraums mit TLBs usw. wie man das kennt (also kein Treiber, der das irgendwie übersetzt, sondern Hardware). Ein Prozeß auf der CPU und sein jeweiliger Kontext auf der GPU teilen sich also den virtuellen Adressraum. Es dürfte kein Orakel benötigen, daß nvidia sowas auch machen wird und bereits auf dem Weg dahin ist.

[HOT]

[...]

Ich finde ja den Punkt "Supports x86 virtual memory" ganz interessant.
[...]
Hm, ich seh schon ein FM3-Board mit einem GPU-Zusatzsockel zur Erweiterung der BDng-APU auf einem Quad-Channel-DDR4-Board vor meinem geistigen Auge :D.

[Nakai]

AMD hat jetzt gesagt, daß man für GPUs und (x86-)CPUs/APUs einen gemeinsamen Adressraum schaffen wird, so daß die 64Bit-Zeiger der CPU auch auf der GPU funktionieren (und umgekehrt). Komplett mit Unterstützung des virtuellen Adressraums mit TLBs usw. wie man das kennt (also kein Treiber, der das irgendwie übersetzt, sondern Hardware). Ein Prozeß auf der CPU und sein jeweiliger Kontext auf der GPU teilen sich also den virtuellen Adressraum. Es dürfte kein Orakel benötigen, daß nvidia sowas auch machen wird und bereits auf dem Weg dahin ist.

Ein virtueller Adressraum ist niemals schlecht. AMD muss hier eben die X86-CPU noch einbeziehen. NV könnte mit ARM dagegenhalten.
Den Gedanken könnte man noch weiterdenken. Soetwas wie Llano oder Zacate ist doch nur ein Witz.
Highend-CPU mit High-GPU auf einem DIE.:freak:

Natütlich müsste dafür noch einiges getan werden. Man braucht eine bessere Speichernanbindung. Selbst DDR4 hat für eine GPU eine viel zu niedrige Speicherbandbreite. Da müssen andere Technologien umgesetzt werden.

Oke zu Offtopic...

[Coda]

AMD hat jetzt gesagt, daß man für GPUs und (x86-)CPUs/APUs einen gemeinsamen Adressraum schaffen wird, so daß die 64Bit-Zeiger der CPU auch auf der GPU funktionieren (und umgekehrt). Komplett mit Unterstützung des virtuellen Adressraums mit TLBs usw. wie man das kennt (also kein Treiber, der das irgendwie übersetzt, sondern Hardware). Ein Prozeß auf der CPU und sein jeweiliger Kontext auf der GPU teilen sich also den virtuellen Adressraum. Es dürfte kein Orakel benötigen, daß nvidia sowas auch machen wird und bereits auf dem Weg dahin ist.
Ich dachte sogar ich hätte in den CUDA-4.0-Release-Notes schon sowas gelesen:

Unified Virtual Addressing

Mal in die Doku schauen ;)

Ja, schaut so aus:
For 64-bit applications on Windows Vista/7 in TCC mode (see Section 3.8), on Windows XP, or on Linux, a single address space is used for the host and all the devices of compute capability 2.0 and above. This address space is used for all allocations made in host memory via cudaHostAlloc() and in any of the device memories via cudaMalloc*(). Which memory a pointer points to – host memory or any of the device memories – can be determined from the value of the pointer using cudaPointerGetAttributes(). As a consequence:


When copying from or to the memory of one of the devices for which the unified address space is used, the cudaMemcpyKind parameter of cudaMemcpy*() becomes useless and can be set to cudaMemcpyDefault;
Allocations via cudaHostAlloc() are automatically portable (see Section 3.2.4.1) across all the devices for which the unified address space is used, and pointers returned by cudaHostAlloc() can be used directly from within kernels running on these devices (i.e. there is no need to obtain a device pointer via cudaHostGetDevicePointer() as described in Section 3.2.4.3).


Applications may query if the unified address space is used for a particular device by checking that the unifiedAddressing device property (see Section 3.2.6.1) is equal to 1.

Wobei das auch ein simpleres Schema ohne Page Tables sein könnte.

[boxleitnerb]

Den Gedanken könnte man noch weiterdenken. Soetwas wie Llano oder Zacate ist doch nur ein Witz.
Highend-CPU mit High-GPU auf einem DIE.:freak:


Das wird auf absehbare Zeit aus vielerlei Gründen nicht passieren und ist auch (noch) nicht erstrebenswert - dazu sind die Nachteile zu groß für Kunden und für Hersteller ;)

[Nakai]

Das wird auf absehbare Zeit aus vielerlei Gründen nicht passieren und ist auch (noch) nicht erstrebenswert - dazu sind die Nachteile zu groß für Kunden und für Hersteller ;)

Es macht, aus professioneller Sicht, Sinn, dass die GPU so nahe wie möglich an der CPU ist. Dass wird natürlich nicht so schnell gehen. Zuerst muss eine neue Speicherarchitektur eingeführt werdem, sodass GPUs und CPUs so wenig wie möglich ausgebremst werden.
Natürlich muss noch einiges dafür getan werden...

[Coda]

Neue Speicherarchitektur? Wieso?

[Nakai]

Neue Speicherarchitektur? Wieso?

DDR für die CPU hat niedrige Latenzen aber auch niedrige Bandbreite.
GDDR hat hohe Latenzen und hohe Bandbreite.

DDR ist für eine GPU nicht sehr optimal, genauso wie GDDR für die CPU.
Außerdem bräuchte man, wenn man Virtual Memory integriert, für jeden Speichertypen einen integrierten Speicherkontroller und Ausgänge nach Außen.

Das alles sehe ich als suboptimal an, außer die CPU bekommt große L3 oder L4 Caches oder die GPU bekommt einen schnellen EDRAM. Aber das alles sind natürlich nur Überlegungen...

[Coda]

DDR für die CPU hat niedrige Latenzen aber auch niedrige Bandbreite.
GDDR hat hohe Latenzen und hohe Bandbreite.
Schon klar. Allerdings war das früher weitaus schlimmer. DDR4 hat auch schon recht hohe Latenzen.

Ich denke eher man trifft sich da in der Mitte. Quad-Channel DDR4 hätte schon bis zu 136GB/s.

[HPVD]

auch heise schreibt was dazu...
http://www.heise.de/newsticker/meldung/GPU-Architektur-AMD-will-Nvidia-das-Fuerchten-lehren-1262833.html

[AnarchX]

DDR für die CPU hat niedrige Latenzen aber auch niedrige Bandbreite.
GDDR hat hohe Latenzen und hohe Bandbreite.

DDR ist für eine GPU nicht sehr optimal, genauso wie GDDR für die CPU.
Außerdem bräuchte man, wenn man Virtual Memory integriert, für jeden Speichertypen einen integrierten Speicherkontroller und Ausgänge nach Außen.

Das alles sehe ich als suboptimal an, außer die CPU bekommt große L3 oder L4 Caches oder die GPU bekommt einen schnellen EDRAM. Aber das alles sind natürlich nur Überlegungen...

Laut Demers ist auch Stacked-DRAM für AMD interessant.

[Nakai]

Laut Demers ist auch Stacked-DRAM für AMD interessant.

Mhh, interessant ja. IMO könnte das AMD noch einigermaßen kontrollieren, wenn man den Stacked-DRAM selber entwickelt und auf Leistung trimmt.
Die Frage is doch eher, was es bringt. Wenn AMD den Weg der Vereinheitlichung des RAM geht, ist so ein Stacked-DRAM nur für SingleChip-SOC-Systeme äußerst interessant(wo nicht mehr als nur der SOC verbaut ist). Oder der RAM wird direkt aufs Package verlötet, wie beim RSX der PS3.

Schon klar. Allerdings war das früher weitaus schlimmer. DDR4 hat auch schon recht hohe Latenzen.

Ja, das ist war. Nur geht man heutzutage auch auf größe SharedCaches, welche diesen hohen Latenzen gut entgegenwirken können.

Ich sehe diesen Gedanken, den AMD mit Speichervirtualisierung ansetzt einfach nicht zu Ende gedacht. Klar, es eröffnet sehr interessante Möglichkeiten, aber jetzt oder in der baldigen Zukunft wird soetwas noch nicht konsequent durchgezogen werden.

[Gipsel]

Übrigens hat Hiroshige Goto das mit dem zeitlichen Ablauf des Scheduling (round robin für die SIMDs) auch so verstanden und eine Grafik dazu gebastelt (nur SIMDs dargestellt, sonst wäre das wohl unübersichtlich geworden).

http://pc.watch.impress.co.jp/img/pcw/docs/453/941/23.jpg

Diese langgestreckte Wavefront bei SIMD3 soll eine aufwendigere Operation (z.B. DP, trancendental) darstellen.

[Nakai]

Diese langgestreckte Wavefront bei SIMD3 soll eine aufwendigere Operation (z.B. DP, trancendental) darstellen

Sieht hier eher nach DP aus, da es genau 4 Zeiteinheiten sind. SFUs sind ja, wie beim 4D-Konzept, nicht mehr integriert. Wie lang sollten denn SFs hier Zeit benötigen?


mfg

[Gipsel]

Sieht hier eher nach DP aus, da es genau 4 Zeiteinheiten sind. SFUs sind ja, wie beim 4D-Konzept, nicht mehr integriert. Wie lang sollten denn SFs hier Zeit benötigen?DP geht doch jetzt angeblich mit halber Rate (wären 8 Takte, also doppelt so lang) ;)
Nein, sieh' es eher als schematisches Bild, nicht als genaues Maß für irgendeine Art von Instruktionen.

Bei Cayman belegen transcendentals 3 Slots. Wenn die neue Architektur das genauso macht, werden solche Instruktionen also über 3*4=12 Takte ausgeführt.

[Ailuros]

Gibt es in der Zwischenzeit einen halbwegs anstaendigen Artikel ueber GCN oder muss ich mir hardware.fr online uebersetztes Kauderwelsch antun?

Gipsel,

Ist 1:2 DP sicher auf GCN oder sollte man noch etwas Vorbehalte haben bis es gesichert ist?

[Gipsel]

Gibt es in der Zwischenzeit einen halbwegs anstaendigen Artikel ueber GCN oder muss ich mir hardware.fr online uebersetztes Kauderwelsch antun?Falls Du japanisch kannst, versuch' es doch mit dem Artikel von Hiroshige Goto :D
Ansonsten nein, der Rest beschreibt die Architektur meist doch recht unpräzise, wenn nicht gar falsch ;(
Alles ist natürlich längst noch nicht bekannt, aber was willst Du denn wissen?

Ist 1:2 DP sicher auf GCN oder sollte man noch etwas Vorbehalte haben bis es gesichert ist?
Also alle die da waren, sagen einhellig, daß wäre explizit erwähnt worden. Zur Marktsegmentierung kann das (ähnlich wie bei nvidia) dann runtergeregelt werden. Als Erklärung kann ich mir vorstellen, daß die Recheneinheiten an sich im Verhältnis zur Datenversorgung der Einheiten relativ billig geworden sind.

Wenn Du Anzahl x Operationen ausführst, mußt Du dazu 3x Operanden lesen und x Ergebnisse schreiben. Nun sind die Operanden in DP doppelt so groß, Du kannst also bei halbem Durchsatz an Operationen mit gleicher Geschwindigkeit der Registerfiles leben. Bei 1/4 Durchsatz liegt die Hälfte davon sozusagen ungenutzt rum. Der SP-Fall bestimmt also die erforderliche Komplexität und Geschwindigkeit, mit der die Einheiten mit Daten versorgen werden müssen. Wenn dieses also anfängt zu limitieren, dann kann es irgendwann relativ billig werden, die Recheneinheiten auf halbe Rate aufzubohren, weil dafür wie gesagt null zusätzlicher Aufwand außerhalb der eigentlichen ALUs erforderlich wird. Offenbar meint AMD mit dem neuen Design dort angekommen zu sein, denn es war ja nun nicht so, daß sie in der DP-Leistung zurücklagen.

[Coda]

Bei Cayman belegen transcendentals 3 Slots. Wenn die neue Architektur das genauso macht, werden solche Instruktionen also über 3*4=12 Takte ausgeführt.
Es ist doch aber ein Unterschied ob ich drei Einheiten zusammenschalte, um eine Op zu erledigen oder sie über mehrere Takte auf einer ausführe.

[Gipsel]

Es ist doch aber ein Unterschied ob ich drei Einheiten zusammenschalte, um eine Op zu erledigen oder sie über mehrere Takte auf einer ausführe.
Stimmt, 16 ist nicht durch 3 teilbar, werden also wahrscheinlich eher 4*4=16 Takte werden, oder die machen das noch irgendwie anders als bei Cayman (durch eine Einheit loopen statt mehrere parallel betreiben?).

[Coda]

Wie willst du ohne VLIW Einheiten zusammenschalten? Die Instructions pro Thread sind dann ja schließlich skalar.

Edit: Okay, jetzt verstehe ich was du meinst. Ähnlich wie DP in Fermi, nur über jeweils vier Einheiten mit 1/4 Durchsatz. Könnte auch sein.

[Gipsel]

Wie willst du ohne VLIW Einheiten zusammenschalten? Die Instructions pro Thread sind dann ja schließlich skalar.

Edit: Okay, jetzt verstehe ich was du meinst. Ähnlich wie DP in Fermi, nur über jeweils vier Einheiten 4x so lange Latenz.
Edit: genau

[Locuza]

Gibt es in der Zwischenzeit einen halbwegs anstaendigen Artikel ueber GCN oder muss ich mir hardware.fr online uebersetztes Kauderwelsch antun?

Gipsel,

Ist 1:2 DP sicher auf GCN oder sollte man noch etwas Vorbehalte haben bis es gesichert ist?

Also der Artikel von AnandTech ist doch eigentlich eine gute Rundumbeschreibung?

http://www.anandtech.com/show/4455/amds-graphics-core-next-preview-amd-architects-for-compute/1

[Gipsel]

Also der Artikel von AnandTech ist doch eigentlich eine gute Rundumbeschreibung?

http://www.anandtech.com/show/4455/amds-graphics-core-next-preview-amd-architects-for-compute/1
Nur sind dummerweise die ganzen netten Grafiken, die zeigen sollen, wie die Wavefronts auf Cayman und GCN abgearbeitet werden, schlichtweg falsch. Die erklären nicht, die verwirren, bzw. lassen ein falsches Verständnis beim Leser aufkommen.

[Locuza]

Was ist denn konkret falsch? Ich verstehe halt simpel nur, dass wenn eine Instruktion von den Daten der anderen abhängt, eine Einheit blockiert wird. Bei GCN berechnet eine SIMD-Einheit jeweils ein Wavefront.

[Gipsel]

Was ist denn konkret falsch? Ich verstehe halt simpel nur, dass wenn eine Instruktion von den Daten der anderen abhängt, eine Einheit blockiert wird. Bei GCN berechnet eine SIMD-Einheit jeweils ein Wavefront.
Nur hängen verschiedene Wavefronts per Definition nicht voneinander ab (es sei denn sie gehören zu einer Workgroup und man synchronisiert sie über eine barrier, aber das führt jetzt zu weit).
Nehmen wir mal diese Abbildungen von Anandtech, die den Vorteil zeigen soll:

http://images.anandtech.com/doci/4455/GCN-final-1Th.pnghttp://images.anandtech.com/doci/4455/GCN-final-2Th.png

Es gibt jetzt zwei Möglichkeiten.
1. Die verschiedenen Farben symbolisieren Befehle für eine einzige Wavefront. Dann ist natürlich die Bezeichnung Wavefront A, B, C, D, E schon mal falsch, allerdings der gezeigte Ablauf für Cayman korrekt. Cayman packt unabhängige Operationen einer einzigen Wavefront in eine VLIW-Anweisung (genauer macht das schon der Compiler).
Allerdings kann GCN nicht Befehle einer Wavefront auf verschiedene SIMDs verteilen, dieser Teil der Darstellung macht in dem Fall überhaupt keinen Sinn. Eine Wavefront wird bei GCN immer auf ein und demselben SIMD ausgeführt (anders als bei GF104 und Konsorten übrigens).

2. Die verschiedenen Farben symbolisieren wirklich verschiedene Wavefronts (wobei dann wie oben dargestellt die Abhängigkeit zwischen C und D keinen Sinn macht). In dem Fall stimmt es für GCN fast, verschiedene Wavefronts werden auf die verschiedenen SIMDs verteilt, nur dieses Überspringen der einen Wavefront macht eben keinen Sinn. Auf der anderen Seite ist dann aber die Darstellung für Cayman grob falsch, denn der kann natürlich keine Operationen verschiedener Wavefronts in eine VLIW-Anweisung mixen (wenn das gehen würde, wäre das praktisch fast schon GCN ;)).

Ergo Verwirrung pur.

[Ailuros]

Also der Artikel von AnandTech ist doch eigentlich eine gute Rundumbeschreibung?

http://www.anandtech.com/show/4455/amds-graphics-core-next-preview-amd-architects-for-compute/1


Gipsel hat schon recht; ich hab mir das Ding durchgelesen und war am Ende noch verwirrter als vorher.

[Gipsel]

Gipsel hat schon recht; ich hab mir das Ding durchgelesen und war am Ende noch verwirrter als vorher.
Ich habe ja den japanischen Artikel von Hiroshige Goto nicht umsonst erwähnt. Der hat das als einziger zumindest mal halbwegs korrekt aufgemalt (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=8794579#post8794579).

Aber es ist zugegebenermaßen auch schwierig das einfach darzustellen, da man sich vorstellen muß, wie z.B. mehrere Instruktionen von sagen wir mal mindestens 8 verschiedenen Wavefronts für jeweils 64 Elemente ausgeführt werden (am besten noch ein Mix aus Vektor- und Skalarinstruktionen). Da muß man das an der richtigen Stelle runterkochen, so daß vielleicht ein oder zwei Details verloren gehen, allerdings auch nichts Falsches bei rauskommt.

[Coda]

Eine Wavefront wird bei GCN immer auf ein und demselben SIMD ausgeführt (anders als bei GF104 und Konsorten übrigens).
Woraus schließt du das?

[Gipsel]

Woraus schließt du das?
Die 4 Instruction Buffer pro CU sind SIMD0...3 gelabelt, also exklusiv. Und jedes SIMD hat sein eigenes 64kB Registerfile. Wenn eine Wavefront auf einem anderen SIMD ausgeführt würde, wüßte die gar nicht, womit sie rechnen soll ;)
Außerdem würde dann das schön auf die Ausführungslatenzen/-durchsatz abgestimmte round robin Schema für's Scheduling arg ins Trudeln geraten (sprich, das würde nicht funktionieren).

Ist auch Teil meiner Begründung, weswegen der Registerzugriff einfacher (und damit schneller) erfolgen kann als noch bei Cayman (jeder Slot konnte alle 4 Bänke [x,y,z,w] des Registerfiles lesen) und auch bei Fermi (da ist es sogar im Prinzip noch komplizierter, weil die Register auch mehr Writeports benötigen, bei Cayman benötigt jede Bank nur einen). Als Nachteil des Ganzen hatte ich in meinem langen Post mit den Spoilern schon das nicht mögliche Load-Balancing zwischen den SIMDs aufgeführt (was ein GF104-SM in Grenzen kann). So ein GCN-CU hat aber insgesamt eine deutlich höhere issue-Bandbreite, weswegen das im Normalfall nur ein sehr kleiner Nachteil sein dürfte wenn überhaupt.

[Gipsel]

Praktisch dazu passend ein Paper von nvidia (http://cva.stanford.edu/publications/2011/gebhart-isca-2011.pdf), wie man mit einer Art kleinem Cache für die Registerfiles den Zugriff lokaler gestalten (was ich ja oben als Vorteil von GCN gegnüber der alten VLIW-Architektur und auch Fermi aufgeführt habe) und ihn dadurch beschleunigen bzw. den Stromverbrauch senken kann. Ganz interessant ist auch, daß nvidia dort (ebenfalls zum Stromsparen) ein anderes Scheduling (zweistufig) vorschlägt. Beides zusammen bringt übrigens nur Vorteile, solange die Instruktionslatenz nicht zu hoch ist. In dem Paper wird mit einer Latenz von 8 Takten gerechnet. Ein Hinweis für die Zukunft bei nv? Ich finde das ganz interessant im Vergleich zu den Änderungen bei GCN.
Hmm. Ich sollte das wohl auch im Kepler-Thread posten. :rolleyes:

[Gipsel]

Falls übrigens irgendwer wissen will, welche Instruktionen so eine Compute Unit (CU) von SI/GCN (hat intern übrigens eine R1000-Bezeichnung ;D) versteht, dem kann ich einen Blick auf dieses Posting bei B3D (http://forum.beyond3d.com/showthread.php?p=1561886#post1561886) empfehlen. Da habe ich mal alle Vektor-/Skalar-/Speicher- und DataShare-Befehle aufgelistet.
Was mich im ersten Moment am meisten überrascht hat, sind die Unmenge an Vergleichsoperationen und Atomics für Texturen (die fallen wohl bei der Vereinigung des Texture-L1/L2 mit dem normalen Caches ab, die Atomics werden jetzt ja in den Caches gemacht, außer den LDS-atomics).

[deekey777]

Hat dieses FSA-Ding eigentlich was mit Huddys Wunsch nach CTM-Programmierung zu tun?

[Gipsel]

Hat dieses FSA-Ding eigentlich was mit Huddys Wunsch nach CTM-Programmierung zu tun?
Was meint er damit denn genau?

[deekey777]

Was meint er damit denn genau?
Er meinte, dass durch die Verwendung der APIs wie DirectX Leistung verschenkt wird, was bei einer deutlich näheren Programmierung nicht der Fall sei (Bsp.: Konsolen <-> PC).

[Gipsel]

Um Deine Frage zu beantworten, langfristig wahrscheinlich schon. Das Ziel der FSA wird ja sein, die GPU-Einheiten enger an die CPU anzubinden, bzw. schlußendlich möglichst zu verschmelzen (zumindest die, die auf dem gleichen Die sind). Das könnte dann so aussehen, daß z.B. bei einem Bulldozer zwischen den 4 Modulen noch ein "Throughput"-Scheduler liegt (z.B. mit einem ACE pro Kern und mit einer Menge CUs daran), auf den alle Kerne Zugriff haben (ähnlich wie die geteilte FPU innerhalb eines Moduls). Der CPU-Code kann dann (durch noch einzuführende Befehlserweiterungen) Aufgabenteile, für die eine durchsatzoptimierte Architektur besser geeignet ist als die CPUs, nach dort verlagern. Bei Beendigung meldet der "Throughput-Scheduler" das an den jeweils aufrufenden Integer-Kern zurück. Da der gleiche Adressraum benutzt wird und der Speicher bzw. der gemeinsam benutzte LL-Cache kohärent gehalten wird, werden Latenzen und Datenverkehr minimiert.

Wenn man das soweit hat (eigentlich schon vorher, das muß nur programmierbar genug sein), könnte man im Prinzip eine Engine komplett an DirectX vorbei entwickeln (sagen wir mal in OpenCL 2/3.x geschrieben, damit es portabel bleibt, was aber den CTM-Aspekt wieder vermindert), wenn man denn möchte (ist aber wahrscheinlich eine ziemliche Arbeit). Genau das hat Intel ja schon bei ihrem Larrabee vorgeschlagen. Man kann dann je nach seinen Anforderungen eventuell bessere und effizientere Lösungen finden, als es bei Einsatz von DX der Fall ist. Aber ehrlich gesagt weiß ich noch nicht, was ich davon halten soll und ob es zu begrüßen wäre, wenn jeder jetzt mit einmal anfängt, seine eigene 3D-Pipeline mit OpenCL oder was auch immer (eventuell noch offline vorkompiliert und optimiert für 3 verschiedene Architekturen oder so :rolleyes:) zu basteln.

[Gipsel]

Übrigens scheint es (außer wahrscheinlich Trinity) keine neuen VLIW Chips mehr von AMD zu geben. Gerade mal den Treiber gecheckt, alle neuen ASICs sind bereits GCN. Siehe auch hier (http://forum.beyond3d.com/showthread.php?p=1561986#post1561986).

[Gipsel]

Zu der FSA hat Charlie übrigens noch das eine oder andere anzubieten (http://semiaccurate.com/2011/06/20/amd-talks-about-next-generation-software-and-fusion):
AMD is promising a fully open FSA, and has stated they will publish the FSA virtual ISA (FSAIL), FSA memory model, and FSA dispatch. These specs will be ISA agnostic for both the CPU and GPU, anyone can play in the new sandbox, and AMD wants others to join. They have even pledged a review committee for FSA, so break out the party hats and get ready, there will be punch and pie.

More importantly is the FSAIL itself, or FSA Intermediate Layer. FSAIL is a virtual ISA that basically a thin and light JIT that writes to the real ISA. This JIT is called a “Finalizer”. The FSAIL is fully threaded, supports all the debugging features of a CPU, the GPU can hit all the CPU services, and the CPU can hit the same on the GPU. Once you are here, the GPU becomes part of the CPU, or at least is theoretically seamless enough that such distinctions are pretty pointless.
Sieht so aus, als könnten auch andere Hersteller das Modell adaptieren bzw. sich auch integrieren, wenn sie einen passenden "Finalizer"-JIT-Compiler für ihre Hardware schreiben.

[Brillus]

Zu der FSA hat Charlie übrigens noch das eine oder andere anzubieten (http://semiaccurate.com/2011/06/20/amd-talks-about-next-generation-software-and-fusion):

Sieht so aus, als könnten auch andere Hersteller das Modell adaptieren bzw. sich auch integrieren, wenn sie einen passenden "Finalizer"-JIT-Compiler für ihre Hardware schreiben.
AMD scheint ja die Fusion Idee stark voranzutreiben. Langsam könnte der Unreal Mensch recht haben mit seinem Spruch "In 10 Jahren verschmelzen CPU und GPU komplett" die er schon seit gefühlten 15 Jahren predigt.

[Ailuros]

AMD scheint ja die Fusion Idee stark voranzutreiben. Langsam könnte der Unreal Mensch recht haben mit seinem Spruch "In 10 Jahren verschmelzen CPU und GPU komplett" die er schon seit gefühlten 15 Jahren predigt.

Tim Sweeney und ich wuenschte er haette auch genau dieses damit gemeint. Im Gegensatz reitete er mehrere Male auf Bloedsinn wie die Rueckkehr auf software rendering. Zwischen dem und das was Du oben angeblich zitierst gibt es schon einige Welten an Unterschied.

Kurz: es ist IMHO egal wo und wie eine GPU in einem System hockt; wenn es diese gibt ist es hardware und nicht software processing (ueber general purpose Prozessoren wie CPUs).

[Gipsel]

So, nachdem der GCN Shadercompiler im Cat 11.7 jetzt läuft, habe ich mal ein wenig mit rumgespielt.

Was man lernen kann, ist z.B. wie der GCN-Scheduler das Problem der Abhängigkeiten von Speicherzugriffen löst. Bei B3D gibt es schon eine Erläuterung (http://forum.beyond3d.com/showthread.php?p=1563604#post1563604), die sich auch auf das von mir favorisierte Einfachhalten der Scheduler bezieht (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=8790084#post8790084), sprich, ich würde so ein Scoreboarding-System wie bei nvidia möglichst vermeiden.

Die deutsche Fassung:
Der GCN-Scheduler überprüft auch bei Speicherzugriffen nicht, ob bei den Operanden eines ALU-Befehls eine Abhängigkeit von einem Speicherzugriff besteht (was es aus meiner Sicht noch wahrscheinlicher macht, daß das auch für ALU-Befehle untereinander gilt). Vielmehr werden in 3 Klassen getrennt (Vektor-Lesen, Schreiben/Export, local memory/skalar) die Anzahl der noch nicht beendeten Zugriffe jeder Wavefront einfach nur gezählt. Es ist jetzt Aufgabe des Programms (des Compilers) in den Instruktionsstrom Marker einzufügen (effektiv sind das eine Art von Barrieren, wird über einen sogenannten "internen Befehl" realisiert, der direkt im Instruktionsbuffer verarbeitet wird), die die Anzahl der maximal erlaubten ausstehenden Operationen (jeweils der 3 Klassen) angeben, damit die Wavefront fortgesetzt werden kann.

Interessanterweise ist das keine Einschränkung der Funktionalität/Performance, da die Instruktionen ja sowieso in-order ausgeführt werden, man für jeden Befehl somit genau abzählen kann, der wievielt-letzte Speicherzugiff beendet sein muß, damit man weitermachen kann (*). Die Lösung kommt somit ohne den Vergleich der Registernummern der Operanden aller potentiell zur Auswahl stehenden Befehlen mit den Zielregistern aller ausstehenden Speicheroperationen wie beim Scoreboarding aus. => Scheduler ist deutlich einfacher :)

(*):
Zumindest wenn man auch voraussetzt, daß die Speicherzugriffe auch in-order ihre Vollendung melden (was bei GCN der Fall ist).

[Ailuros]

Lese ich das jetzt falsch oder bedeutet das Ganze dass der Compiler diesmal "intelligenter" vorgehen muss?

[Gipsel]

Lese ich das jetzt falsch oder bedeutet das Ganze dass der Compiler diesmal "intelligenter" vorgehen muss?
Ein wenig mitarbeiten muß der schon. Allerdings muß der nichts Ausgefallenes tun, sondern gewissermaßen einfach nur die Speicherzugriffe mitzählen und vor davon abhängige Instruktionen einen entsprechenden Marker setzen. Die Abhängigkeiten werden von einem Compiler sowieso schon verfolgt (für die Anordnung der Instruktionen), insofern ist das jetzt kein wirklicher Mehraufwand. Dafür spart man sich das eben in den Schedulern, was wie schon gesagt bei einem in-order Design die exakt gleiche Performance liefern sollte, wie ein Scoreboarding in Hardware. Die GCN-Lösung sieht für mich erstmal recht clever aus.

[Skysnake]

Der Compiler sollte eigentlich soweit ich das überblicken konnte und auch nach den Infos vom FDS deutlich einfacher werden. Viel wird in Hardware gepackt.

Was ich allerdings nicht ganz verstehe ist, warum du von Round-Robin ausgehst?
Soweit ich mich jetzt richtig erinnere, und die Sache richtig verstanden habe, nähert man sich eher deutlich dem Sheduling einer CPU an, also präemptive Sheduling mit Priorisierung der Threads/Wavefronts. Zumindest hatte ich die ganze Sache so verstanden.

Ich möchte auch nochmals die Sache mit Trinity aufgreifen. Soweit ich die Formulierung auf des FDS verstanden habe, soll Trinity schon auf GCN setzen. Erachte ich jetzt auch nicht für sooo unrealistisch.

Bzgl. der Zukunft sollte man sich eventuell mal folgendes Gedankenspiel von mir näher anschauen.

Wenn man BD anschaut, dann hat er ja eine geteilte FPU, die jeden Takt neu zugeteilt werden kann, und ihren eigenen Decoder-Part, Sheduler etc. hat. Wenn man sich jetzt dazu noch anschaut, wie eine CU bei GCN aussieht, und praktisch alles enthält was man so grob brauch, dann sehe ich die Sache schon als sehr gut möglich, dass man die FPU von BD wegschmeist und dafür eine CU reinklemmt, oder aber halt zusätzlich zu FPU die CU einsetzt, wobei ich letzteres eher für unwahrscheinlich halte.
Man kann ja auf den gleichen Adressraum jetzt zugreifen etc etc. Auch gibt es ja Folien, die ein komplette feingranulare Verschmelzung von GPU und CPU andeuten.

So back to GCN:
Warum reden eigentlich immer alle von Fermi?
Mich erinnert das alles eher an die Vektorrechner :ugly:
Man hat seine Vektoreinheiten (SIMDs) und dazu noch ne keline Skalareinheit. Die Caches, etc etc. Also ich seh da eigentlich keinen wirklich großen Unterschied mehr.

Und auch nochmals auf den kohärenten Speicher mit gemeinsamen Adressraum zurück zu kommen. Das ist ja nicht mal das Einzige! Paging und allozieren von mehr Speicher als Vorhanden ist, soll ja auch möglich sein. Das ist schon sehr geil für einen Programmierer. Absolut keine Gedanken mehr darum machen, wie viel Ram denn jetzt noch frei ist, und was denn nun wo liegt. Einfach allozieren, Daten rein packen, und wo es ist ist doch SCHEIS egal. :D Sehr schick finde ich.

Mir bereitet die Sache mit dem kohärenten Speicher allerdings auch noch einige Kopfschmerzen, da eben die Latenzen ziemlich komisch werden... PCI-E hat ja so rund 1.000 ns und HT zum Vergleich so rund 50 ns wenn ich es richtig im Kopf habe.
Soweit die Sache zu verstehen war, soll wohl die IOMMU auf dem Chipsatz dazu verwendet werden, die Sache zu verwalten zwischen CPU und GPU, und die ist ja mit HT angebunden ;)

Ich hab mir die Sache wie folgt durchdacht:

IOMMU bekommt von der GPU ne Anfrage, und checkt das mit der CPU, was kein Problem ist da HT.
Wenn jetzt Daten geschrieben werden von der GPU, bleibt halt die Latenz zum Chip bestehen, wobei dies kein so großes Problem ist, da die CPU bei der IOMMU ja auch anfrägt in diesem Fall. Hier muss also verwaltet werden. Die GPU darf die Daten halt erst dann verwenden, wenn von der IOMMU das OK kam.
Schreibt die CPU zuerst, kommt ein invalid inkl. der neuen Daten von der IOMMU. Je nach dem kann die IOMMU noch darauf warten, ob ein Update von der GPU kommt, um ein invalid an die CPU zu schicken, bleibt dieses aus, weiß die CPU sie kann schreiben, wenn nicht muss aufgelöst werden=eklig

Auf Seite der GPU gehts halt genau so dann von statten. Es wird so lange gerechnet, bis ein invalid von der IOMMU kommt. Man muss hier also nur einmal die Laufzeit über PCI-E berücksichtigen. Bevor man seine Werte schreiben kann. Damit muss man auch keine Daten wegschmeisen, da ja erst geschrieben wird, nachdem der Gegenpart informiert wurde.

Ist zumindest die eleganteste Lösung, die mir eingefallen ist. Eventuell kann man ja auch das PCI-E Mapping ab HT 2.0 verwenden, um so die Latenz beim umsetzen auf PCI-E zu reduzieren. Da bin ich mir aber unsicher, da ich in diesem Punkt nicht wirklich genau bescheid weiß.

Summa sumarum fürn GPGPU-Bereich wirklich viele tolle neue Sachen dabei, aber für den Grafikmarkt seh ich nicht sooo wirklich viele neue coole Sachen auf uns zukommen.

PS: Zu Kepler gibt es ja die "Gerüchte" nVidia würde ja schon ne ARM"CPU" einsetzen, ähnlich wie AMD als Skalareinheit für gewisse Berechnungen. Gibt aber auch die Info, dass es da noch weiter geht, und man wohl komplett unabhängig von der CPU ein Programm ausführen kann.

Euch dazu was näheres bekannt?

[Gipsel]

Der Compiler sollte eigentlich soweit ich das überblicken konnte und auch nach den Infos vom FDS deutlich einfacher werden. Viel wird in Hardware gepackt.
Der wird ja hauptsächlich deswegen einfacher, weil er nicht mehr das VLIW-Packing beachten muß, wobei die VLIW-Anweisungen auch immer noch in sogenannte Clauses strukturiert wurden, um deutlich größere Einheiten zu haben, zwischen denen Abhängigkeiten bestehen konnten (vermindert Verwaltungs- und Schedulingaufwand).

Meine Ausführungen zielen eher auf die Hardware ab, sprich, wie kann man die Performance auch im Worst-Case verbessern, ohne deutlichst mehr Aufwand in der Hardware zu betreiben, sprich, wie macht man es am effizientesten, so daß man weiterhin einen Vorteil in Sachen (Rechen-)Leistung/mm² gegenüber nvidia behält.
Was ich allerdings nicht ganz verstehe ist, warum du von Round-Robin ausgehst?
Soweit ich mich jetzt richtig erinnere, und die Sache richtig verstanden habe, nähert man sich eher deutlich dem Sheduling einer CPU an, also präemptive Sheduling mit Priorisierung der Threads/Wavefronts. Zumindest hatte ich die ganze Sache so verstanden.
Die beiden Punkte haben erstmal nichts miteinander zu tun. Die Round-Robin-Geschichte habe nicht nur ich so verstanden, schau mal ins B3D-Forum. ;)
Das ergibt sich im Prinzip aus der Beschreibung als die wahrscheinlichste weil einfachste Möglichkeit. Wenn eine CU eine Wavefront zur Bearbeitung zugeteilt bekommt, entscheidet sich, auf welchem der 4 SIMDs die abgearbeitet wird (wahrscheinlich je nach Füllstand der einzelnen Instruction Buffer für die SIMDs). Jede der 4 SIMD-Einheiten hat einen eigenen Instruction Buffer (deswegen sind die auf den Folien mit IB SIMD0 ... IB SIMD3 bezeichnet) mit einer Kapazität von jeweils mindestens 10 Wavefronts. Die Folie, die das Scheduling beschreibt, sagt aus, daß in jedem Takt, die Wavefronts einer SIMD-Einheit für das Issue betrachtet werden. Tja, und da die Vec-ALUs an jeder Instruktion 4 Takte knabbern (64er Wavefronts, Vec-ALUs haben 16 Lanes, 64/16=4) und es auch 4 SIMDs gibt, geht das praktisch nur Round-Robin. Hiroshige Goto hat das übrigens auch genau so in seinem Artikel über GCN aufgemalt (Bild gibt es hier (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=8794579#post8794579)).

Der Vorteil davon dürfte sein, daß AMD das Scheduling in 2 Teile aufspalten kann. Direkt in jedem Instruction Buffer, was im Prinzip 10+ FIFOs als Mini-L0-Instruction-Cache, jeweils mit Program counter (Zeiger auf aktuelle Anweisung im Code), Zähler für Menge der ausstehenden (Speicher-)Operationen und noch ein paar Werte/Flags (Priorität, Privilege-Level [ja, gibt es bei GCN] usw.) für jede der Wavefronts darstellt, wird wohl festgelegt, welche Instruktionen ausgeführt werden können. Da es strikt in-order ist, kommen nur die jeweils vordersten Einträge (Befehle) jeder Wavefront in Frage. Die sind praktisch per se unabhängig (außer die werden per barrier-Befehl innerhalb einer threadgroup synchronisiert, deswegen werden Barrriers auch direkt in den IBs gehandhabt), da ist also erstmal egal, welche in welcher Reihenfolge genommen werden.
Geprüft werden muß natürlich, ob irgendwelche Abhängigkeiten bestehen (z.B. von einem Speicherzugriff), und somit erstmal abgewartet werden muß. Wie das gelöst wird, habe ich ja oben schon geschrieben. GCN zählt praktisch die ausstehenden Speicherzugriffe (für jede Wavefront) mit. Bei Issue eines Zugriffs wird der entsprechende Zähler um 1 erhöht, wenn er fertig ist (und die vorhergehenden gleicher Art auch = in order completion/retire), wieder um 1 vermindert. Kommt eine Instruktion, die von einem Speicherzugriff abhängig (der nicht schon garantiert beendet wurde) ist, setzt der Compiler einen Marker in den Instruktionsstrom, der praktisch angibt, vom wievielten vorherigen Speicherzugriff die nachfolgende(n) Instruktion(en) abhängig sind (der zählt also einfach beim Kompilieren schon genau so mit). Alles was der Instructionbuffer also tun muß, ist die Zahl(en) im Marker (es gibt 3 Klassen von Speicherzugriffen, die getrennt gezählt werden) mit dem Zähler im Instruktionbuffer zu vergleichen. Ist die Bedingung erfüllt, wird der Marker aus dem IB entfernt und die nächste Instruktion kann ausgeführt werden, ansonsten bleibt der Marker drin stehen und blockiert die Ausführung der Wavefront (bis der entsprechende Speicherzugriff fertig ist).
Man spart also dem Scheduler, sich die Register aller ausstehenden Speicherzugriffe zu merken und für jeden einzelnen Befehl jeweils alle diese Register mit den bis zu 4 Operanden jedes Befehls zu vergleichen (also 4 * Anzahl der ausstehenden Speicherzugriffe Vergleiche pro Befehl). Jetzt muß man das nur tun, wenn so eine interne "Instruktion" auftaucht, weswegen man mit einer reduzierten Rate und damit deutlich weniger Vergleichen auskommt (nur maximal 3 Vergleiche/Takt dafür). Zudem kann man das alles bereits bei den undecodierten Instruktionen machen, da man gar nicht wissen muß, auf welche Register was zugreift. Die instruction buffer müssen lediglich den Instruktions-Typ bzw. -Klasse erkennen (wird durch die ersten paar Bit festgelegt, ist also ein einfacher Lookup, mehr dazu später) und für die Barrieren-Marker einen 12 Bit-Wert interpretieren (als 3 Zahlen mit 3, 4, 5 Bit), bzw. für den s_sleep-Marker einen 3 Bit-Wert (blockiert die Wavefront für 64 Takte*übergebenen 3Bit Wert, also 0, 64, 128, ..., 448 Takte, der s_sethalt Befehl legt die Wavefront auf unbestimmte Zeit schlafen, kann dann wohl über eine Message aufgeweckt werden), die Zahlen stehen dabei für alle diese internen Instruktionen an identischen Bitpositionen (das ist für die Operanden der anderen Befehle nicht unbedingt so).
Die oben erwähnten Barrieren zur Synchronisierung mehrerer Wavefronts funktionieren fast genau so. Kommt man mit einer Wavefront an der Barriere an, wird die Wavefront blockiert, bis alle zur Threadgroup gehörenden Wavefronts an der Barriere stehen. Erst dann geht es weiter.

Zurück zur Auswahl der Instruktionen. Es gibt allgemein verschiedene Strategien, wie darüber entscheiden wird (z.B. round robin zwischen den Wavefronts auf einem SIMD, oder "greedy", also eine Wavefront solange es nicht mehr weitergeht und dann erst eine andere). Da GCN mehrere Befehle pro Takt absetzen kann (die aber alle von einer jeweils anderen Wavefront auf dem gleichen SIMD kommen müssen), geht keine dieser beiden Reinformen, es wird also irgendein Mischmasch davon sein, da wird bei AMD schon irgendwer ein paar Simulationen laufen lassen haben, was wohl am besten ist.
Im Prinzip wird unter Berücksichtigung der Priorität jeder Wavefront (kann der Nutzer selber im Programm setzen, es gibt 4 Prioritätslevel, das Scheduling dürfte dann ganz grob so laufen wie mit den Prioritäten eines Betriebssystem Schedulers, eben nur total abgespeckt und fest in Hardware gegossen, Exception-Handler laufen übrigens auf einem erhöhten Privilege-Level, da wird dann alles andere sowieso erstmal angehalten) möglichst eine Instruktion jeder Instruktionsklasse (Vektor, Skalar, Branch, LDS, Vec-Mem, Export/GDS) von wie gesagt unterschiedlichen Wavefronts ausgewählt, die für das Issue in Frage kommen. Deswegen muß der Instruction Buffer auch schon den Instruktionstyp erkennen, damit er die entsprechend einsortieren kann.

Der nächste Schritt ist dann ein "arbitration" Schritt, also es wird praktisch geprüft, ob die enstprechende Einheit überhaupt frei ist (z.B. eine DP-Instruktion benötigt doppelt so lange, da kann also nächsten Takt kein Befehl issued werden) und bei den geteilten Einheiten im Falle der völligen Sättigung das Zugriffsrecht zwischen den SIMDs verteilt (z.B. ein SIMD hat die Speicherpipeline vollkommen zugestopft, so daß diese keinen weiteren Befehl mehr annehmen kann, dann müßte hier sichergestellt werden, daß die anderen auch ab und zu mal drankommen, bevor von dem Verursacher noch was nachgeliefert wird). Wie das genau funktioniert, hängt zumindest bei den Skalar-/Vektoreinheiten davon ab, wie die Latenzen und der Durchsatz denn aussehen. Der Punkt ist ja noch nicht ganz geklärt und es sind verschiedene Lösungen denkbar.

Erst dann müssen die Instruktionen (vollständig) decodiert werden, also die einzelnen Felder der Befehlsworte in den eigentlichen Befehl, die Registernummern, eventuelle Immediates sowe Input-/Output-Modifier usw. zerlegt werden. Dies ist nicht ganz trivial, weil GCN auf ein recht kompaktes Instruktionsformat setzt, so daß möglichst viele gebräuchliche Befehle möglichst kurz encodiert werden können. Alle Skalar-Befehle (ohne Immediates>16 Bit) werden in 32 Bit encodiert, ebenso wie Ein- und Zwei-Operanden Vektor-Befehle (ohne Immediates) sowie die Interpolationsbefehle (die praktisch destruktive FMACs mit spezieller Codierung sind). Außerdem können bei den meisten (Vektor-)Befehlen auch direkt ein skalares Register oder eine LDS-Speicherstelle als Operand angegeben werden. Insgesamt benötigt man schon eine Handvoll verschiedener Encodierungen, was es zwar etwas komplexer aber auch kompakter macht (man ist aber weit von x86 weg, was die Komplexität angeht ;)).
Dadurch, daß die Befehle schon vorsortiert ankommen, benötigt man nur noch je einen auf den jeweiligen Instruktionstyp spezialisierten Decoder (die dann nicht 4 Takte für alles Zeit haben, sondern jeden Takt eine neue Instruktion bekommen). Alles was decodiert wurde, wird dann direkt an die jeweilige Einheit gegeben (Vector-Befehle jeden Takt an die jeweils nächste Vector-ALU, muß ja die richtige sein), alle anderen Einheiten werden von allen SIMDs geteilt. Die Skalar-Einheit dürfte jeden Takt eine neue Instruktion akzeptieren (64 Bit eventuell nur alle zwei, aber da habe ich Zweifel, verkompliziert das Scheduling, da wäre es wohl bald günstiger eine volle 64Bit ALU einzubauen, ist ja nur eine einzige, aber wer weiß), genau wie alle anderen Pipelines, bis sie dann eventuell an der Grenze der unterstützten Operation in flight angekommen sind und das an die Arbitration Stufe zurückmelden.

So wie ich das sehe, könntest man mit GCN vielleicht schon sowas wie einen Timer-Interrupt basteln, der dann einen speziellen Handler mit erhöhtem Privilege-Level aufruft, der dann den Zustand auf dem entsprechenden SIMD irgendwie sichert und dafür dann die nächsten Aufgaben reinswitched. Also echte Präemption. Allerdings bezweifle ich ein wenig, ob GCN in der jetzigen Version schon die Unterstützung für eine effiziente Umsetzung mitbringt (auszuschließen ist es aber nicht).

Wird mir jetzt zu lang, ich höre erstmal auf hier. :rolleyes:
Ich möchte auch nochmals die Sache mit Trinity aufgreifen. Soweit ich die Formulierung auf des FDS verstanden habe, soll Trinity schon auf GCN setzen. Erachte ich jetzt auch nicht für sooo unrealistisch.VLIW4 ist offiziell bestätigt. Es gab da so eine Folie mit 4 Panels zur FSA (Fusion System Architecture) so als ganz grobe Roadmap ohne Zeitangaben, auf der Trinity vielleicht ein paar mehr Features als Llano hat. Aber GCN kommt erst im Trinity-Nachfolger. GCN erfüllt dann wohl so ein paar Sachen des dritten Panels, aber das letzte wird auch erst mit einem Nachfolger möglich werden. FSA bezeichnet momentan eher den Weg, nicht ein fertiges Ziel und Trinity macht den zweiten (wohl kleinen) Schritt auf dem FSA-Weg, GCN dann den etwas größeren dritten.

Bzgl. der Zukunft sollte man sich eventuell mal folgendes Gedankenspiel von mir näher anschauen.

Wenn man BD anschaut, dann hat er ja eine geteilte FPU, die jeden Takt neu zugeteilt werden kann, und ihren eigenen Decoder-Part, Sheduler etc. hat. Wenn man sich jetzt dazu noch anschaut, wie eine CU bei GCN aussieht, und praktisch alles enthält was man so grob brauch, dann sehe ich die Sache schon als sehr gut möglich, dass man die FPU von BD wegschmeist und dafür eine CU reinklemmt, oder aber halt zusätzlich zu FPU die CU einsetzt, wobei ich letzteres eher für unwahrscheinlich halte. Man kann ja auf den gleichen Adressraum jetzt zugreifen etc etc. Auch gibt es ja Folien, die ein komplette feingranulare Verschmelzung von GPU und CPU andeuten.Ich denke genau auf Letzteres wird es rauslaufen, denn die FPU hat viel niedrigere Latenz und für Sachen mit wenig Threads die deutlich höhere Leistung.

Es gab ja auch einen Vortrag von einem ARM-Vertreter, der mal so perspektivisch aufgezeigt hat, was man in Zukunft bei 10nm oder 7nm für Beschränkungen hinsichtlich des Stromverbrauchs beachten muß. Denn die Anzahl der Transistoren steigt erheblich schneller, als deren Stromverbrauch sinkt. Dadurch hat man in ein paar Jahren zwar Unmengen an Transistoren auf einem Chip, kann aber nur einen (kleinen) Teil davon gleichzeitig betreiben, der Rest muß praktisch per Clock-/Powergating stillgelegt werden. Da kann es sich also lohnen, beide zu verbauen, eine FPU (256bit AVX#-Einheit), die eben bei Problemen mit geringer Parallelität unter Ausnutzung von OoOE, Spekulation und allen anderen Tricks das Maximum rausquetscht, und ein paar breitere Vektoreinheiten, die in-order laufen und möglichst auf alle stromfressenden Features der CPU verzichten, dafür eben bei durchsatzorientierten Problemen mit sehr hoher Parallelität eben mit deutlich höherer Effizienz glänzen. Je nach Problem startet man das dann auf der FPU oder den CUs und erhält jeweils optimale Performance im verfügbaren Power-Budget. Intel hat sich mal ähnlich geäußert und gemäß Andreas Stiller von der ct gibt es Gerüchte, daß Haswell 2014 sowas schon bringen könnte (AVX2 in FPU + Larrabee-ähnliche Kerne auf einem Die). Die integrierte GPU hat dann noch ein paar fixed function Einheiten und teilt sich dann die CUs/Larrabee-Kerne mit den CPU-Kernen. Für sowas wäre es ziemlich interessant, wenn man z.B. AVX sowohl auf der FPU als auch den Larrabee-Kernel (dann eben als AVX-1024 oder so, also mit breiteren Vektoren) laufen lassen könnte.

[Skysnake]

Zurück zur Auswahl der Instruktionen. Es gibt allgemein verschiedene Strategien, wie darüber entscheiden wird (z.B. round robin zwischen den Wavefronts auf einem SIMD, oder "greedy", also eine Wavefront solange es nicht mehr weitergeht und dann erst eine andere). Da GCN mehrere Befehle pro Takt absetzen kann (die aber alle von einer jeweils anderen Wavefront auf dem gleichen SIMD kommen müssen), geht keine dieser beiden Reinformen, es wird also irgendein Mischmasch davon sein, da wird bei AMD schon irgendwer ein paar Simulationen laufen lassen haben, was wohl am besten ist.
Im Prinzip wird unter Berücksichtigung der Priorität jeder Wavefront (kann der Nutzer selber im Programm setzen, es gibt 4 Prioritätslevel, das Scheduling dürfte dann ganz grob so laufen wie mit den Prioritäten eines Betriebssystem Schedulers, eben nur total abgespeckt und fest in Hardware gegossen, Exception-Handler laufen übrigens auf einem erhöhten Privilege-Level, da wird dann alles andere sowieso erstmal angehalten) möglichst eine Instruktion jeder Instruktionsklasse (Vektor, Skalar, Branch, LDS, Vec-Mem, Export/GDS) von wie gesagt unterschiedlichen Wavefronts ausgewählt, die für das Issue in Frage kommen. Deswegen muß der Instruction Buffer auch schon den Instruktionstyp erkennen, damit er die entsprechend einsortieren kann.

Den Teil hier hatte ich gemeint. Da hat man wohl aneinander vorbei gesprochen. Hatte nicht verstanden, dass mit dem Round Robin die Zuteilung der Wavefronts bzgl der Sheduler gemeint ist. Dachte innerhalb selbiger, was ja nicht so sein soll, hast du ja schön oben ausgeführt mit dem "Bertiebssystem like".

Was halt auch interessant ist, wie die Sache mit den Warteschlangen gemacht wird, die jeder Prozess haben soll. Also nicht mehr ein großen Ringbuffer, in den alle ihre Aufgaben reinknallen und der dann abgearbeitet wird von der GPU.


Die Skalar-Einheit dürfte jeden Takt eine neue Instruktion akzeptieren (64 Bit eventuell nur alle zwei, aber da habe ich Zweifel, verkompliziert das Scheduling, da wäre es wohl bald günstiger eine volle 64Bit ALU einzubauen, ist ja nur eine einzige, aber wer weiß), genau wie alle anderen Pipelines, bis sie dann eventuell an der Grenze der unterstützten Operation in flight angekommen sind und das an die Arbitration Stufe zurückmelden.

Ja das mit den 64 bit wäre nett, da man dann eben innerhalb einer Wavefrontausführung jeder SIMD einen DP-Wert liefern könnte , oder wohl halt 2 SP Werte. Ich denke mal die soll für Loops etc eingesetzt werden. Da wären 2 SP Werte schon nett, die Konstante hoch/runter zählen + nen Vergleich. Whiles könnte man auch realisieren. Damit könnte man die SIMD halt wirklich nur durchrechnen lassen. Bei VLIW muss das doch in die VLIW-Instruction mit rein gepackt werden soweit ich das weiß oder?
Soweit ich mich erinnern kann, machen/machten die Vektorrechner das auch so.


Wird mir jetzt zu lang, ich höre erstmal auf hier.

Also von mir aus nicht :D
Gerade Präemption ist recht interessant.

Da kommt mir nämlich aktuell das von dir gepostete Paper von nVidia zu der effizienteren Nutzung von großen Registern in den Kopf. Man hätte ja seine zwei Bereiche. Die zur Ausführung bereiten, und die nicht bereiten Threads. Könnte also eventuell vom Ansatz her auch integriert sein, oder noch integrieren lassen.

Präemption wäre halt nett, da man sich so nicht so wirklich BLÖDE "deadlocks" einhandelt wie mit CUDA teils -.-


Es gab ja auch einen Vortrag von einem ARM-Vertreter, der mal so perspektivisch aufgezeigt hat, was man in Zukunft bei 10nm oder 7nm für Beschränkungen hinsichtlich des Stromverbrauchs beachten muß. Denn die Anzahl der Transistoren steigt erheblich schneller, als deren Stromverbrauch sinkt. Dadurch hat man in ein paar Jahren zwar Unmengen an Transistoren auf einem Chip, kann aber nur einen (kleinen) Teil davon gleichzeitig betreiben, der Rest muß praktisch per Clock-/Powergating stillgelegt werden. Da kann es sich also lohnen, beide zu verbauen, eine FPU (256bit AVX#-Einheit), die eben bei Problemen mit geringer Parallelität unter Ausnutzung von OoOE, Spekulation und allen anderen Tricks das Maximum rausquetscht, und ein paar breitere Vektoreinheiten, die in-order laufen und möglichst auf alle stromfressenden Features der CPU verzichten, dafür eben bei durchsatzorientierten Problemen mit sehr hoher Parallelität eben mit deutlich höherer Effizienz glänzen. Je nach Problem startet man das dann auf der FPU oder den CUs und erhält jeweils optimale Performance im verfügbaren Power-Budget. Intel hat sich mal ähnlich geäußert und gemäß Andreas Stiller von der ct gibt es Gerüchte, daß Haswell 2014 sowas schon bringen könnte (AVX2 in FPU + Larrabee-ähnliche Kerne auf einem Die). Die integrierte GPU hat dann noch ein paar fixed function Einheiten und teilt sich dann die CUs/Larrabee-Kerne mit den CPU-Kernen. Für sowas wäre es ziemlich interessant, wenn man z.B. AVX sowohl auf der FPU als auch den Larrabee-Kernel (dann eben als AVX-1024 oder so, also mit breiteren Vektoren) laufen lassen könnte.

STIMMT!
Diesen Punkt hatte ich völlig verdrängt. Ich erinnere mich auch grad dran, dass die Leuts von IBM, die ja an der direkten Wasserkühlung und den stacked Chips arbeiten die Stromversorgung als mit das größte Problem sehen.
Unter diesem Gesichtspunkt macht es schon Sinn, "einfach" ne weitere Funktionseinheit dazu zu packen, die ~ das gleiche Powerbudget hat, nur eben für eine gewisse Art von Task mehr Durchsatz/Rechenleistung bringt.

Klasse Idee :daumen:

Bzgl. Trinity muss ich mir doch nochmal die Zeit nehmen, den Keynote von Eric Demers (http://developer.amd.com/afds/pages/rebroadcast2.aspx)nochmals an zu hören. Ich hatte seine Äußerung, als sie den Laptop mit Trinity gezeigt haben, wie oben ausgeführt, verstanden. Vielleicht ist mein Englisch aber doch zu schlecht :ugly:
Ich such die Stelle nochmals raus.

EDIT:


So wie ich das sehe, könntest man mit GCN vielleicht schon sowas wie einen Timer-Interrupt basteln, der dann einen speziellen Handler mit erhöhtem Privilege-Level aufruft, der dann den Zustand auf dem entsprechenden SIMD irgendwie sichert und dafür dann die nächsten Aufgaben reinswitched. Also echte Präemption. Allerdings bezweifle ich ein wenig, ob GCN in der jetzigen Version schon die Unterstützung für eine effiziente Umsetzung mitbringt (auszuschließen ist es aber nicht).

Schau mal bei 38:00 in den Keynote von Eric Demers. Preämption und context switching wird GCN definitiv enthalten/unterstützen.

Der Keynote mit Trinity ist doch nicht der mit Eric Demers :ugly: Dauert wohl noch etwas, muss alle anderen auch nochmals anschauen -.-

PS: Ich hab im Netz was gefunden, dass am 11. Dezember die nächste OpenCL Version kommen soll, und die Spatzen pfeifen es von den Dächern, dass mit GCN eine neue OpenCL Version kommen wird ;)

EDIT2:
Wie ich gerade sehen durfte ist der Q&A Teil nun auch im Rebroadcast mit drin :D

GNC wird DP in 1/2 1/4 und 1/16 unterstützen. Gute Nachricht. Schlechte Nachricht, er sprach davon, dass HPC sich am oberen Rand bewegen wird, und halt die anderen Sachen drunter. Consumer werden also wohl nicht mehr so gut weg kommen wie aktuell bei AMD :(

Btw. Die letzte lange Frage ist von mir ;)
Im letzten Satz nuschelt er auch noch was ganz interessantes hin. Sie tunneln HT über den PCI-E Link. Ich glaub daher, dass die volle Funktionalität, insbesondere der shared Memory zwischen CPU und GPU nur mit einem AMD System gehen wird. AMD scheint sich seiner Sache wohl ganz schön sicher zu sein ^^

[Gipsel]

Ja das mit den 64 bit wäre nett, da man dann eben innerhalb einer Wavefrontausführung jeder SIMD einen DP-Wert liefern könnte , oder wohl halt 2 SP Werte. Ich denke mal die soll für Loops etc eingesetzt werden. Da wären 2 SP Werte schon nett, die Konstante hoch/runter zählen + nen Vergleich. Whiles könnte man auch realisieren. Damit könnte man die SIMD halt wirklich nur durchrechnen lassen. Bei VLIW muss das doch in die VLIW-Instruction mit rein gepackt werden soweit ich das weiß oder?
Die Skalar-Einheit ist praktisch eine reine Integer-ALU, nix mit SP und DP. Die kann halt nur I32, U32, I64, U64 die ganzen logischen Operatoren Vergleiche und natürlich auch Shifts und Operationen zum Manipulieren von Bitfeldern (Lanemasken!). Die ist wirklich hauptsächlich zum Steuern des Programmflusses da, für alles was da so an skalaren Aufgaben anfällt. Zur Rechenleistung trägt die nicht bei, sie entlastet nur die Vektor-ALUs. Dabei kann die Skalareinheit ein Register namens VCC (Vector Condition Code) zugreifen, das ist praktisch ein 64Bit Wert, wobei jedes Bit für den Ausgang eines Vergleichs in der Vektoreinheit steht (jedes Data Element einer Wavefront hat ein Bit). Setzt dann die Execution-Lanemasken für Predication und so'n Zeug (können die Vektor-ALUs aber im Notfall/für einfache Sachen auch selber mit den v_cmp?x_??_??-Befehlen). In den Skalar-Registern werden auch Werte gehalten, die für alle Elemente einer Wavefront gleich sind, da die Vektor-ALUs auch die Skalar-Register lesen können. Umgekehrt funktioniert das übrigens nicht. Allerdings können die Vektor-ALUs auch Werte in die Skalar-Register schreiben (allerdings nur einen von einer einzigen Lane pro Befehl).

Eine for Schleife (mit fester Durchlaufzahl für alle Datenelemente in der Wavefront, also for(i=0;i<100;i++) funktioniert im Prinzip so:
Schleifenzähler steht im SGPR s_i, die Taktnummer ist /4 geteilt, wir betrachten also nur ein SIMD. Vergleiche für Zahlen mit maximal 16Bit können direkt in literals/immediates innerhalb der Vergleichsanweisung codiert werden, heißen dann s_cmpk, sonst müssen s_cmp Anweisungen genommen werden, die bis 64Bit funktionieren, bei denen dann aber beide Werte in einem Register stehen müssen (bei s_add/s_addk ist es genau so). Der Ausgang des Vergleichs steht in SCC (Scalar Condition Code). Sprünge sind üblicherweise relative Sprünge (+- um die angegebene Weite, wobei sich die neue angesprungene Adresse als neu = alt + (offset*4)+4 berechnet), das nur zum Verständnis.
Die Adressen sind der Speicherort der jeweiligen Instruktion, die können irgendwo liegen, ich fange einfach mal bei 0 an, können natürlich irgendwo liegen, die meisten Instruktionen sind 4 Byte lang, maximal können es 8 Byte werden.

Takt/Adresse Skalar-ALU Vec-ALU Branch-Einheit

1/0 s_cmpk_lt_i32 s_i,100 // SCC = i<100
2/4 s_cbranch_scc0, 6 // if SCC=0 jmp +28 (hinter Schleife)
3/8 v_instr1
4/12 v_instr2_3op // 8 Bytes
5/20 v_instr3
6/24 s_addk_i32 s_i,1 // s_i += 1
7/28 s_branch, -8 // unbedingter Sprung zum compare (Adresse 0)
8/0 s_cmpk_lt_i32 s_i,100 // SCC = i<100
9/4 s_cbranch_scc0, 6 // if SCC=0 jmp +28 (hinter Schleife)
10/8 v_instr1
11/12 v_instr2_3op // 8 Bytes
12/20 v_instr3
13/24 s_addk_i32 s_i,1 // s_i += 1
14/28 s_branch, -8 // unbedingter Sprung zum compare (Adresse 0)
../32

Also alles schön nacheinander, wenig spannend, nur in 3 von 7 Takten pro Schleifendurchlauf hat die Vektor-ALU was zu tun. Interessant wird es, wenn mehrere Wavefronts auf dem gleichen SIMD laufen, nehmen wir mal 2:

Takt Skalar-ALU Vec-ALU Branch-Einheit

1 s_cmpk_lt_i32 s_i,100
2 s_cmpk_lt_i32 s_i,100 s_cbranch_scc0, 6
3 v_instr1 s_cbranch_scc0, 6
4 v_instr2_3op
5 v_instr3
6 s_addk_i32 s_i,1 v_instr1
7 v_instr2_3op s_branch, -8
8 s_cmpk_lt_i32 s_i,100 v_instr3
9 s_addk_i32 s_i,1 s_cbranch_scc0, 6
10 v_instr1 s_branch, -8
11 s_cmpk_lt_i32 s_i,100 v_instr2_3op
12 v_instr3 s_cbranch_scc0, 6
13 s_addk_i32 s_i,1 v_instr1
14 v_instr2_3op s_branch, -8
15 s_cmpk_lt_i32 s_i,100 v_instr3
16 s_addk_i32 s_i,1 s_cbranch_scc0, 6
17 v_instr1 s_branch, -8
18 s_cmpk_lt_i32 s_i,100 v_instr2_3op
19 v_instr3 s_cbranch_scc0, 6
20 s_addk_i32 s_i,1 v_instr1
21 v_instr2_3op s_branch, -8
22 s_cmpk_lt_i32 s_i,100 v_instr3
23 s_addk_i32 s_i,1 s_cbranch_scc0, 6
24 v_instr1 s_branch, -8
25 s_cmpk_lt_i32 s_i,100 v_instr2_3op
26 v_instr3 s_cbranch_scc0, 6
27 s_addk_i32 s_i,1 v_instr1
28 v_instr2_3op s_branch, -8
29 s_cmpk_lt_i32 s_i,100 v_instr3
30 s_addk_i32 s_i,1 s_cbranch_scc0, 6
31 v_instr1 s_branch, -8
...
So, jetzt hat man nach der kurzen Einlaufphase am Anfang immer noch 7 Takte pro Schleifendurchlauf, allerdings für gleich 2 Wavefronts. Die Vector-ALUs tun jetzt schon 6/7 Takten was Nützliches. Mit 3 Wavefronts wäre die Vector ALU zu 100% ausgelastet (wenn man hier 4 Instruktionen in die Schleife packen würde, auch schon mit zwei), trotz des Kontrollflusses. Insgesamt müssen (bei ein paar Wavefronts) weniger als 50% der Instruktionen Vec-ALU Instruktionen sein, um die Rechenleistung von GCN voll auszulasten. Vec-ALU-Instruktionen muß nur die Instruktionsklasse mit den meisten Instruktionen sein. Beim Beispiel oben hat man zwar 3 Vec-ALU Instruktionen und 4 andere pro Schleifendurchlauf, aber da die vier anderen sich auf 2 für die Branch-Einheit und zwei für die skalare ALU aufteilen, ist die Bedingung immer noch erfüllt (man benötigt nur 3 Wavefronts). Das geht also genau in die Richtung, wie Du geschrieben hast. Mit der gleichzeitigen Nutzung von Speicherzugriffen und local memory (die auch noch parallel laufen können), sieht das insgesamt ziemlich mächtig aus.

Also insbesondere bei diesen kleinen Schleifen ist das eine enorme Verbesserung gegenüber den VLIW-Architekturen. Da ging zum einen bei kleinen Kontrollstrukturen die Packrate der VLIW-Slots runter (mehr als 3 hätte man ja nicht reinpacken können, mehr sind ja nicht da *)) und zum anderen wurde für den Kontrollfluß ein eigener "Clause" aufgemacht. Der Clause-Wechsel ist aber mit einer gewissen Latenz verbunden, so daß bei kleinen Kontrollstrukturen das recht ineffizient werden konnte.

*)
Stimmt so nicht ganz, da der Schleifenzähler und der Vergleich auch in den SIMD-Einheiten gemacht wurde (war halt redundant, daß das für jede Lane einzeln erfolgte), allerdings gibt es ja immer Abhängigkeiten Vergleich=> Branch, dann die 3 ALUs+Zähler Increment (da hätten 4 Slots gefüllt werden können, angenommen die 3 Operationen sind unabhängig) so daß da wohl minimal 3 Instruktionen in 2 Clauses draus geworden wären. Das wären also schon ohne Berücksichtigung der Ineffizienz der Clauses 3 Takte lang 16*4 (4 Slots bei VLIW4, vor Cayman sogar 5) ALUs belegt worden, jetzt sind wir ja immer noch auf einem einzigen SIMD und benötigen bei 3 Wavefronts auch nur noch 3 Takte/Wavefront, allerdings bei nur einem Viertel der ALUs. Der Durchsatz einer CU ist für dieses einfache Beispiel also mindestens Faktor 4 höher als der einer Cayman-SIMD-Engine.


Insgesamt ist das System doch schon deutlich unterschiedlich zu Fermi, der nur ein Issue von 2 oder maximal 4 (SM nach GF104-Typ) Instruktionen aus 2 Warps simultan durchführen kann und der damit 2 oder gar 3 Vec-ALUs (GF104) füllen muß und zudem damit noch die L/S-Einheiten und einen oder zwei (GF104) SFU-Blöcke bedient.

Bei GCN sind Wavefronts zwar auf eine Vec-ALU festgepinnt (bei Fermi wohl nicht unbedingt), dafür bietet GCN deutlich mehr Issue ports (5 bis 6 pro Takt) und ist dabei nicht wie GF104 auf ILP angewiesen, es werden einfach andere Wavefronts vom gleichen SIMD genommen, um möglichst viele Instruktionen von verschiedenen Instruktionstypen gleichzeitig auf die Reise zu schicken (nicht unabhängige vom gleichen Warp wie bei GF104). Hier kommt GCN wohl die relative Einfachheit der Scheduler zu gute, so daß sie sich dieses eher erlauben können. Mal sehen, ob nvidia für Kepler ähnliche Ideen hatte, oder ob die Entwicklung jetzt konträr läuft. AMD ging von mäßiger Nutzung der TLP + starker der ILP bei den VLIW-Architekturen jetzt mit GCN zur ausschließlichen Nutzung von TLP (+ DLP bei allen und immer natürlich). NVidia dagegen nutzte ILP bisher nur eher mäßig, vielleicht kann man mit GF104 einen Trend zu einer Steigerung desselben ausmachen, der sich mit kepler eben fortsetzen wird oder auch nicht. :rolleyes:

[Coda]

Btw. Die letzte lange Frage ist von mir ;)
Im letzten Satz nuschelt er auch noch was ganz interessantes hin. Sie tunneln HT über den PCI-E Link. Ich glaub daher, dass die volle Funktionalität, insbesondere der shared Memory zwischen CPU und GPU nur mit einem AMD System gehen wird. AMD scheint sich seiner Sache wohl ganz schön sicher zu sein ^^
Interessant. Also doch.

[Gauß]

Ein gemeinsamer Adressraum hat nur kosmetische Vorteile solange es keine uniforme Speicheranbindung für GPU/CPU gibt. Unvorhergesehene Seitenfehler und intransparente Speicherdomänenzugriffe sind für Echtzeitprobleme prinzipbedingt unbrauchbar. Der einzige wirkliche Vorteil derzeit ist der Speicherschutz.

[Coda]

Ein gemeinsamer Adressraum hat nur kosmetische Vorteile solange es keine uniforme Speicheranbindung für GPU/CPU gibt.
Das seh ich anders. Der Zugriff kann wahrscheinlich direkt sehr viel schneller erfolgen, wenn man nicht durch zig API-Layers muss um etwas zu kopieren.

[Skysnake]

Allein der geringere Programmieraufwand und damit die gesunkene Fehleranfälligkeit sind schon sehr nützlich. Ganz davon abgesehen, dass man so Sachen wie Speicherverwaltung nicht mehr so Arg im Kopf haben muss, da man ja immer neuen Speicher allozieren kann.

Ein letzter Punkt, der auch in dem Keynote angesprochen wurde ist, dass man halt so was wie mit den Mega-Textures machen kann, also dynamisch die Texturen aus dem CPU-RAM nachladen. Bisher muss man da nen ganz schönes Hick Hack machen. Man muss ja sicherstellen, dass Sie rechtzeitig da sind etc. In Zukunft kannste das getrost vergessen. Das macht schon die Hardware für dich.

@Gipsel:
Ich muss mir den Assembler-Code mal in Ruhe anschauen, das letzte mal ist schon ne Weile her :ugly:

Aber auf jeden Fall sehr konstruktiv die Diskussion. So einen Spaß hatte ich schon länger nicht mehr :D

Was ich aber schon anmerken wollte ist, dass das Bsp. mit dem i<100 etwas unglücklich ist in meinen Augen, denn in diesem Speziellen Fall kann der Compiler ja schon die Sache richtig sortieren und loopunrolling machen.

Viel entscheidender ist der Fall, i<x, wobei x, wie du schon selbst angesprochen hast!, eben entweder eine Const-Variable ist, oder aber halt zumindestens eine, die für alle Elemente eine Wavefront gleich ist.

Ohne die Skalareinheit würde man halt eine SIMD mindestens einen Takt lang halt komplett blockieren.

Die wahl von SP/DP war wohl etwas unglücklich. Mir gings darum, dass man halt 1 64Bit Wert, oder 2 32 Bit Werte pro Takt berechnen kann. Du meintest ja, dass es nur Integer-ALUs sind. Woher hast du denn das? :ka: Für For-Schleifen, Maskierung (SEHR WICHTIG) etc. reicht ein 32/16 Bit Wert (int; long int) ja aus, ich denke aber mal schon, man wird zumindest eine 64 Bit ALU haben, dann hat man auch long long int zumindest abgedeckt. Mich würde es aber wundern, wenn die Skalareinheit wirklich nur Integer kann. Gibt ja auch genug Fälle wo man Floats hat. Wäre irgendwie halbherzig umgesetzt in meinen Augen.

So ne FPU ist ja aber auch nicht ganz klein, vielleicht reichts im Moment einfach nicht für eine. :ka:

[S940]

Btw. Die letzte lange Frage ist von mir ;)
Im letzten Satz nuschelt er auch noch was ganz interessantes hin. Sie tunneln HT über den PCI-E Link. Ich glaub daher, dass die volle Funktionalität, insbesondere der shared Memory zwischen CPU und GPU nur mit einem AMD System gehen wird. AMD scheint sich seiner Sache wohl ganz schön sicher zu sein ^^
Hmm, läuft das auf das hier raus:
http://www.abload.de/img/hypershekwk.png
http://www.hypertransport.org
?

[Gipsel]

Was ich aber schon anmerken wollte ist, dass das Bsp. mit dem i<100 etwas unglücklich ist in meinen Augen, denn in diesem Speziellen Fall kann der Compiler ja schon die Sache richtig sortieren und loopunrolling machen.
Dann mach halt eine variablen, als Parameter an den Kernel übergebenen Wert draus. Dann ist das mit dem Unrolling nicht mehr so einfach dann muß der Compiler nur s_cmp_lt_i32 ausspucken statt s_cmpk_lt_i32 (ist die Version mit 16 Bit Immediate).
Du meintest ja, dass es nur Integer-ALUs sind. Woher hast du denn das? :ka:
Ich habe hier den Instruktionssatz mitsamt einer rudimentären Dokumentation für viele Befehle und kann den Treiber Kernel für GCN-ISA kompilieren lassen und mir dann den erzeugten Code nach Durchlauf durch einen Disassembler ansehen ;)
Nur OpenCL-Kernel muß ich noch hinbekommen, bisher gehen nur IL-Kernel.
Für For-Schleifen, Maskierung (SEHR WICHTIG) etc. reicht ein 32/16 Bit Wert (int; long int) ja aus, ich denke aber mal schon, man wird zumindest eine 64 Bit ALU haben, dann hat man auch long long int zumindest abgedeckt.Die Lane-Masken und das VectorCondition Code-Register sind alle 64Bit, eine Wavefront hat ja 64 Datenelemente. Deswegen gibt es auch eine Menge 64Bit-Befehle.

[Skysnake]

Hmm, läuft das auf das hier raus:
http://www.abload.de/img/hypershekwk.png
http://www.hypertransport.org
?
Da ist aber jemand auf die gleiche Idee gekommen wie ich ;)
Als nächste würde ich mal nach ner "Konferenz" Anfang diesen Jahres suchen. Vielleicht findet man da ja noch ein paar spannende Sachen, die in diese Richtung gehen ;)

Dann mach halt eine variablen, als Parameter an den Kernel übergebenen Wert draus. Dann ist das mit dem Unrolling nicht mehr so einfach dann muß der Compiler nur s_cmp_lt_i32 ausspucken statt s_cmpk_lt_i32 (ist die Version mit 16 Bit Immediate).

Ich sag ja nicht, dass mit der aktuellen nicht einfach wäre, sondern, dass es ohne Skalar-Einheit zu großen Leistungsverlusten kommen würde ;)
Daher ist die Skalareinheit ja auch in meinen Augen mehr oder weniger Zwingend, wenn ich so breite SIMD-Units habe.


Ich habe hier den Instruktionssatz mitsamt einer rudimentären Dokumentation für viele Befehle und kann den Treiber Kernel für GCN-ISA kompilieren lassen und mir dann den erzeugten Code nach Durchlauf durch einen Disassembler ansehen ;)

Soso... Ausm gDebugger? Wenn ja sag mal was dazu, bei mir spackt das Ding nur rum irgendwie -.-
Oder ausm KernelAnalyzer xy? Der funktioniert bei mir aktuell auch nicht... Ist mit dem neusten Treiber zerschossen, den 11.7 hab ich aber noch nicht ausprobiert.
Und woher haste den Disassembler?

Fragen über Fragen...

Ich brauch btw. noch die Antwort für die .dat ím 11.7 bin doch zu piep mir die Datei richtig anzeigen zu lassen :uhammer:


Nur OpenCL-Kernel muß ich noch hinbekommen, bisher gehen nur IL-Kernel.

hm... kann man doch zur Note von Hand machen oder?
Den Code als OpenCL-Kernel zu haben wäre aber natürlich extrem schick!


Die Lane-Masken und das VectorCondition Code-Register sind alle 64Bit, eine Wavefront hat ja 64 Datenelemente. Deswegen gibt es auch eine Menge 64Bit-Befehle.
Deswegen mein ich ja auch ich glaub dass es ne 64 Bit ALU sein wird, die halt mit dem gleichen Takt arbeitet, oder halt eine 32Bit mit doppelten Takt, damit man die Maskierungen hin bekommt.

Ok ich seh grad was dich gestört hat. Hab geschrieben, dass für die Maskierung 16/32 bit reichen würden. Das natürlich Blödsinn :freak: Wenn dann halt entsprechend höher getaktet. Das hätte ich dazu schreiben sollen -.- Gott ich sollte glaub echt die Sachen hier lieber 3 mal prüfen statt 2 mal. Das Niveau ist hier doch glücklicherweise viel höher als normal. Da muss man sich erst mal dran gewöhnen :biggrin:

[Gipsel]

Soso... Ausm gDebugger? Wenn ja sag mal was dazu, bei mir spackt das Ding nur rum irgendwie -.-
Oder ausm KernelAnalyzer xy? Der funktioniert bei mir aktuell auch nicht... Ist mit dem neusten Treiber zerschossen, den 11.7 hab ich aber noch nicht ausprobiert.
Und woher haste den Disassembler?
Nein, den Debugger habe ich noch gar nicht gesehen oder ausprobiert. Aber wenn Du das 11.7er Preview nicht hast, läuft der doch sowieso nicht richtig, das Preview haben die doch extra wegen dem Support des Debuggers veröffentlicht. Den Kernelanalyzer müßte man wohl irgendwie patchen, dann könnte das gehen, aber ich hänge mich da über das CAL-Interface rein (ist sogar von AMD ganz gut dokumentiert, wie das geht). Und der Disassembler steckt auch im Treiber, der kommt da immer gepaart mit dem Shadercompiler, das ist (war?) nur schlechter dokumentiert ;).
Ich brauch btw. noch die Antwort für die .dat ím 11.7 bin doch zu piep mir die Datei richtig anzeigen zu lassen :uhammer:Du kannst Dir entweder die passenden Stellen einfach mit 'nem Texteditor (ich glaube Unicode-Unterstützung ist nicht schlecht ;)) ausschneiden und dann manuell umbrechen, oder Du schreibst Dir einen kleinen Parser dafür, wenn Du die komplette Liste sehen willst. Die einzelnen Felder sind immer durch Kommas getrennt, und die Felder pro Eintrag muß man dann einfach abzählen (sind 18, glaube ich), da gibt es keinen Extra-Marker oder einen Zeilenumbruch. Das erste Feld ist immer einfach die laufende Nummer (aktuell von 1 bis 658, das steht auch am Anfang sozusagen in der Kopfzeile, wahrscheinlich kann man diese Nummer auch als Marker für einen neuen Eintrag nehmen) und das dritte Feld jedes Eintrages würde ich erstmal glatt verwerfen, das ist jeweils eine ewig lange Buchstaben-Zahlen-Kombination.
hm... kann man doch zur Note von Hand machen oder?
Den Code als OpenCL-Kernel zu haben wäre aber natürlich extrem schick!Mich hat gerade einer drum gebeten, mal den GCN-Code von einem OpenCL-BitCoin-Miner zu erzeugen, der ist ewig lang (das Cayman Disassembly ist eine 229kB Textdatei, der ISA-Code ist 38kB ;)), den willst Du bestimmt nicht per Hand in IL übersetzen. :rolleyes:
Und dummerweise gibt es mit GCN einen neuen IL-Dialekt, bestimmte Konstrukte sind nicht ganz kompatibel. Also während die meisten für Cypress/Cayman geschriebenen IL-Kernel auch für GCN kompiliert werden können (wobei das manchmal recht ineffizient aussieht, insbesondere bei Kontrollfluß, was aber wohl daran liegt, daß für die VLIW-Architekturen der Kontrollfluß auch nicht so straightforward ging, so daß im Prinzip oft eine Menge mit GCN eigentlich unnötiger Operationen im Code stehen werden), will dieser OpenCL-Miner noch nicht so richtig. Füttere ich den vom OpenCL-Compiler erzeugten IL Code an den Shadercompiler, ist das für Cypress und Cayman kein Problem, aber bei GCN beschwert er sich, daß irgendein IL Opcode nicht von der Architektur unterstützt wird (verrät mir aber nicht welcher das ist :motz:). Der ganze arithmetischen Kram ist es nicht, ich vermute GCN will entweder andere IL-Befehle für global memory Zugriffe (da hat sich ja schon was geändert, insbesondere mit der Kohärenz, was auch vom Nutzer steuerbar ist, also vielleicht fehlt nur ein Flag, was sagt ob ich Kohärenz haben will oder nicht) oder irgendwas mit den Thread- und Group-IDs wegen der anderen Organisation der CUs. Man muß also dem OpenCL-Compiler noch beibringen, den GCN-Dialekt von IL auszuspucken. Mal sehen, wann ich dazu komme, heute sicherlich nicht.

[Skysnake]

Nein, den Debugger habe ich noch gar nicht gesehen oder ausprobiert. Aber wenn Du das 11.7er Preview nicht hast, läuft der doch sowieso nicht richtig, das Preview haben die doch extra wegen dem Support des Debuggers veröffentlicht.

AH jetzt wir mir einiges klarer. Da hätte ich auch selbst drauf kommen können. Dachte es sollte schon gehen und war nur ne Beta halt von ner neuen Version -.-

Dann werde ich mal heute oder morgen den drauf hauen :D


Den Kernelanalyzer müßte man wohl irgendwie patchen, dann könnte das gehen,

Ja da muss auch noch nen patch kommen, Sie arbeiten wohl dran. Muss mal schauen ob sich schon was getan hat.


aber ich hänge mich da über das CAL-Interface rein (ist sogar von AMD ganz gut dokumentiert, wie das geht). Und der Disassembler steckt auch im Treiber, der kommt da immer gepaart mit dem Shadercompiler, das ist (war?) nur schlechter dokumentiert ;).

Aha....

Du hast nicht so rein zufällig einen Link dazu, wie du das machst? :rolleyes:
Ist dass das ganz normale CAL-Dokument? Wenn ja muss ich mich da wohl doch mal durch beisen ;(


Du kannst Dir entweder die passenden Stellen einfach mit 'nem Texteditor (ich glaube Unicode-Unterstützung ist nicht schlecht ;)) ausschneiden und dann manuell umbrechen, oder Du schreibst Dir einen kleinen Parser dafür, wenn Du die komplette Liste sehen willst. Die einzelnen Felder sind immer durch Kommas getrennt, und die Felder pro Eintrag muß man dann einfach abzählen (sind 18, glaube ich), da gibt es keinen Extra-Marker oder einen Zeilenumbruch. Das erste Feld ist immer einfach die laufende Nummer (aktuell von 1 bis 658, das steht auch am Anfang sozusagen in der Kopfzeile, wahrscheinlich kann man diese Nummer auch als Marker für einen neuen Eintrag nehmen) und das dritte Feld jedes Eintrages würde ich erstmal glatt verwerfen, das ist jeweils eine ewig lange Buchstaben-Zahlen-Kombination.

Ja ich hab ooO genommen und da halt im writer den UNICODE (UTF-8) Zeichensatz genommen, aber der liefert mir halt das:


SZDD��'3At��##�1.0,Driv�er Insta�llation,�MSI ASIC� IDs,ATI� Technol�ogies��c,�2011 May� 13 15:1�:52,6.10�.14.47,1�,

letzte Seite:
7�m#��m��muY2,TRIN�ITY MOBI�LE (9900�),Mq9cLl�blUlvGar�w1vO373o�9MmXWyG8#mTSr��.}>}N}#^}n}~}�}�}�}�}�}#�}�}"�j�#���+�Y��:�J�3X�DESK�TOPg�1m�}�y4CsuLQO��#����Mэ��#�#�@!�1�A�Q�a�q�1~���vX4ʝ g�3��}�S0DcX/�QvfJFi+R#
�#�*�:�J�Z�j�z�#��������ʭڭw�^-�o�#� �uY5=�g�4�S�c�X/S/3Y#FDeb3~�����#����ν޽��#�#�#.�>�N�x��=�͓݃��uY6��VASTATOR DUOg�9F���oFo����##�#�&�6�F�V�f�v� �ݖݦݶ���F��]�H��#�vX7X�h�9l��RbLg1v+n�/2OBT9nq#0FcXa�q���#�����������#�#�#!�1�n�9}��


In der ersten Zeile gehts ja noch, aber später wirds halt echt eklig, siehe unten halt.

Bin da leider etwas planlos -.-

Mit den anderen Zeichensätzen kommt halt nur NOCH MEHR MÜLL bei raus -.- Und für ne Parser hab ich aktuell gar keine Ahnung wie anfangen.


Mich hat gerade einer drum gebeten, mal den GCN-Code von einem OpenCL-BitCoin-Miner zu erzeugen, der ist ewig lang (das Cayman Disassembly ist eine 229kB Textdatei, der ISA-Code ist 38kB ;)), den willst Du bestimmt nicht per Hand in IL übersetzen. :rolleyes:

Ja gut äh... :freak: Ich dachte da eher schon an sehr kleine reduzierte Bsp.s halt.


Und dummerweise gibt es mit GCN einen neuen IL-Dialekt, bestimmte Konstrukte sind nicht ganz kompatibel. Also während die meisten für Cypress/Cayman geschriebenen IL-Kernel auch für GCN kompiliert werden können (wobei das manchmal recht ineffizient aussieht, insbesondere bei Kontrollfluß, was aber wohl daran liegt, daß für die VLIW-Architekturen der Kontrollfluß auch nicht so straightforward ging, so daß im Prinzip oft eine Menge mit GCN eigentlich unnötiger Operationen im Code stehen werden), will dieser OpenCL-Miner noch nicht so richtig. Füttere ich den vom OpenCL-Compiler erzeugten IL Code an den Shadercompiler, ist das für Cypress und Cayman kein Problem, aber bei GCN beschwert er sich, daß irgendein IL Opcode nicht von der Architektur unterstützt wird (verrät mir aber nicht welcher das ist :motz:). Der ganze arithmetischen Kram ist es nicht, ich vermute GCN will entweder andere IL-Befehle für global memory Zugriffe (da hat sich ja schon was geändert, insbesondere mit der Kohärenz, was auch vom Nutzer steuerbar ist, also vielleicht fehlt nur ein Flag, was sagt ob ich Kohärenz haben will oder nicht) oder irgendwas mit den Thread- und Group-IDs wegen der anderen Organisation der CUs. Man muß also dem OpenCL-Compiler noch beibringen, den GCN-Dialekt von IL auszuspucken. Mal sehen, wann ich dazu komme, heute sicherlich nicht.
Naja, OpenCL halt ja den Laufzeitcompiler etc. Da braucht man wahrscheinlich ne neue Datei. (Sorry mir fällt grad nicht mehr ein, wie die heißt, wurde mit OpenCL 1.1 eingeführt, so das man sowohl AMD als auch nVidia in einem Rechner haben kann)

[Gipsel]

Du hast nicht so rein zufällig einen Link dazu, wie du das machst? :rolleyes:
Ist dass das ganz normale CAL-Dokument? Wenn ja muss ich mich da wohl doch mal durch beisen ;(Ich glaube schon, weiß das gerade nicht mehr.
Ja ich hab ooO genommen und da halt im writer den UNICODE (UTF-8) Zeichensatz genommen, aber der liefert mir halt das:


In der ersten Zeile gehts ja noch, aber später wirds halt echt eklig, siehe unten halt.

Bin da leider etwas planlos -.-
Ahh, jetzt kommen wir der Sache schon näher. Du nimmst nicht zufällig die Datei atiicdxx.da_ statt atiicdxx.dat? Erstere ist nämlich noch gepackt. In dem Fall ist das mit Windows kommende Kommandozeilentool expand das, was Du brauchst. ;)

[Skysnake]

Ah gut, das erklärt einiges ^^ hatte mich schon gewundert, warum die .da_ heißt. Ist mir eigentlich nie unter gekommen.

Funktionieren tut aber nach expand noch immer nicht -.- Kommt noch immer Grütze bei raus... :motz:

[aylano]

Weiß man schon, umwieviel die Tesselation-Performance steigen soll, oder ist da noch nichts bekannt?

Früher hatte AMD quasi immer eine Tesselation-Unit pro GPU.
Bis auf HD 6970, wo es dann 2 gab.

Wird es dann pro CU dann eine Tesselation-Unit geben ODER
ein kompletter Neuentwurf der Tesselation-Unit, die dann in kleineren Teilen sogar je eines in SIMD eingebaut wird?

[Gauß]

Das seh ich anders. Der Zugriff kann wahrscheinlich direkt sehr viel schneller erfolgen, wenn man nicht durch zig API-Layers muss um etwas zu kopieren.Speicherzugriffe auf der GPU sind um zwei Größenordnungen langsamer als der Aufwand für API-Aufrufe. Wenn es irgendwo hängt dann nur weil das gewollte Zugriffsmuster nicht dem der API-Funktion entspricht.

[Coda]

Speicherzugriffe auf der GPU sind um zwei Größenordnungen langsamer als der Aufwand für API-Aufrufe.
Du willst mir erzählen, dass ein Speicherzugriff der GPU länger dauert, als wenn ich von der Host-CPU über Direct3D/Kernel/PCIe der Karte etwas rüberkopiere worauf sie warten muss?

Ich glaube kaum.

[Gauß]

Nein, ich habe gesagt das es bezüglich der Gesamtgeschwindigkeit eines Speichertranfers zwischen CPU und GPU irrelevant ist wie der Befehl dazu aussieht.

[Coda]

Ich denke nicht, aber man kann es leider vorher auch nicht nachmessen. Ich hab beispielsweise im Hinterkopf, das sich die Battlefield-Entwickler da mal drüber geärgert haben, wieviel Overhead da durch die API entsteht.

[Gauß]

Das einzige was ich mir als Problem vorstellen kann ist der Fall wo untypische Speicherzugriffsmuster wie bei clipmaps vorgenommen werden. Würde man eine dafür passende Speicherverwaltung im Treiber anbieten könnte man sogar noch schneller sein als wenn man dies der CPU und dem Betriebssystem überläßt.

[Skysnake]

Ähmm...

An der physikalischen Übertragung kannst du gar nichts ändern, und die stellt auch das Problem bei "ungewöhnlichen" Speicherzugriffsmustern da. Wenn du halt Daten im Abstand der Cacheline liest, dann ist das halt scheise, und bleibt scheise, egal was du machst.

Die APIs etc satteln da nur NOCH MEHR! drauf. Jeder OS trap etc kostet massig Zeit.

Du kannst jedes X beliebige System völlig unbrauchbar machen, in dem du einfach am laufenden Band OS traps machst.

Korrigiert mich wenn ich falsch liege, aber son OS trap liegt doch bei hunderten/tausenden Taktzyklen.

[Gauß]

Ähmm...

An der physikalischen Übertragung kannst du gar nichts ändern, und die stellt auch das Problem bei "ungewöhnlichen" Speicherzugriffsmustern da. Wenn du halt Daten im Abstand der Cacheline liest, dann ist das halt scheise, und bleibt scheise, egal was du machst.

Die APIs etc satteln da nur NOCH MEHR! drauf. Jeder OS trap etc kostet massig Zeit.

Du kannst jedes X beliebige System völlig unbrauchbar machen, in dem du einfach am laufenden Band OS traps machst.

Korrigiert mich wenn ich falsch liege, aber son OS trap liegt doch bei hunderten/tausenden Taktzyklen.Was du sagst macht keinen zusammenhängenden Sinn.

[Coda]

Überzeugende Argumentation ;)

[Skysnake]

Was du sagst macht keinen zusammenhängenden Sinn.
Was verstehst du daran nicht?

Ich versuch gern es ausführlicher zu machen, damit es klarer wird ;)

[Gauß]

Gibt es was zu diskutieren?
Ein Speichertransfer zwischen CPU und GPU dauert mindestens einige duzend Mikrosekunden. Davon abgesehen dass dies bei diesen Größenordnungen keine Rolle spielt schätze ich dass die Betriebssystemkontrolle der IOMMU inklusive der Seitenverwaltung nicht schneller ist als ein API-Aufruf mit hardwarespezifischer Speicherverwaltung des Treibers.

[Gauß]

Was verstehst du daran nicht?

Ich versuch gern es ausführlicher zu machen, damit es klarer wird ;)Es ist einfach zusammenhangsloses und aussagenloses Geschreibsel.

[Skysnake]

Es ist einfach zusammenhangsloses und aussagenloses Geschreibsel.
Wat? :freak:

Speicherzugriffe, die halt nicht alligned sind, wie z.B. Speicherzugriffe, die jeweils um eine Cacheline versetzt sind, oder halt immer auf ne andere Bank des Speichers landen sind langsam, das hat aber nichts mit der Software zu tun. Man kann halt nur auf die eine Bank oder die andere Zugreifen.

Nichts anderes sag ich im ersten Teil. Man sollte einfach unterscheiden, woher Probleme kommen. Von Software, oder davon, dass die Hardware einfach gewissen Limitierungen unterliegt. Was ist daran schwer zu verstehen?:confused:

Ähmm...

An der physikalischen Übertragung kannst du gar nichts ändern, und die stellt auch das Problem bei "ungewöhnlichen" Speicherzugriffsmustern da. Wenn du halt Daten im Abstand der Cacheline liest, dann ist das halt scheise, und bleibt scheise, egal was du machst.


So als nächster Punkt kam halt, dass ne API halt immer zusätzliche Latenzen verursacht. Egal was du machst, die physikalische Übertragung musst du ja trotzdem machen, und das geht halt in Hardware deutlich schneller als in Software mit nem OS Trap oder whot ever. Da machst du ja auch nichts anderes als den Transfer dann halt von der Software aus zu starten, um z.B. den DMA zu programmieren.


Die APIs etc satteln da nur NOCH MEHR! drauf. Jeder OS trap etc kostet massig Zeit.


Eine Hardwarelösung ist daher eigentlich immer im Vorteil im Vergleich zu ner Softwarelösung, ganz schlechte Implementierungen mal ausgenommen. Das Einzige was einem davon abhält ist halt die Komplexität.


Du kannst jedes X beliebige System völlig unbrauchbar machen, in dem du einfach am laufenden Band OS traps machst.

Was ist daran schwer zu verstehen? Es soll nur zeigen, dass die OS Traps sich eben sehr stark auf die Leistung auswirken. Wir ham mal die Aufgabe gehabt im Prinzip genau so etwas zu machen. Es war verblüffend, wie man die Performance mit OS Traps in die Knie zwingen kann.

War am Bsp. eines Webservers, wenn ich es richtig im Kopf hab.

Und ja PCI-E hat so ne Latenz von 1 µs, so grob. Dennoch macht ne Softwarelösung einiges aus. Wenn du nur 1k Taktzyklen für die Abarbeitung des gesamten API-Aufrufs brauchst, dann bist du bei 1 GHz schon bei deiner µs. Du bist also schnell in der gleichen Größenordnung wie die reine Übertragung über das PCI-E Protokoll.

[Gipsel]

Ein Speichertransfer zwischen CPU und GPU dauert mindestens einige duzend Mikrosekunden. Davon abgesehen dass dies bei diesen Größenordnungen keine Rolle spielt schätze ich dass die Betriebssystemkontrolle der IOMMU inklusive der Seitenverwaltung nicht schneller ist als ein API-Aufruf mit hardwarespezifischer Speicherverwaltung des Treibers.
Ich glaube die Frage ist gerade, was verursacht die dutzende µSekunden-Latenz? Ist es die Latenz einer Übertragung über PCI-Express an sich (dachte eigentlich, das wäre weniger) oder ist es die Dauer, die man da als Overhead so obendrauf noch hat.

[Coda]

Ein Speichertransfer zwischen CPU und GPU dauert mindestens einige duzend Mikrosekunden.
Wenn der PCIe-Link direkt in der CPU ist?

Laut diesem (http://www.hypertransport.org/docs/wp/Low_Latency_Final.pdf) Paper des Hypertransport-Konsortiums ist man bei 8-Byte-Reads bei ~250ns über einen 16x PCIe-1.0-Link.

Das sollte bei PCIe-3.0 nochmal geringer sein, wegen der höheren Datenrate.

[anddill]

One Eure Diskussion zu verstehen möchte ich meinen Senf zu der Latenzdiskussion doch mal dazugeben, Wie auf Seite 5 des verlinkten Dokuments erwähnt wird, muss man bei PCIe alle Bits eines Wortes erst serialisieren, auf alle verfügbaren Lanes verteilen und auf der anderen Seite wieder einsammeln, da die Übertragung asyncron verläuft. Außerdem kommen noch 25% Overhead dazu und dann muss der ganze Kram noch geprüft, korrigiert und wieder sortiert werden.
Ich kann mir also schon vorstellen, dass PCIe verglichen mit physikalisch parallelen Bussen eine erheblich höhere Latenz erzeugt. Absolut gesehen ist die Zeit natürlich minimal, aber wenn ich das richtig im Kopf habe ist es trotzdem 10x so lange wie ein Zugriff auf den RAM. Und das ist ja erst mal nur die Buslatenz. Irgendwo müssen die Daten ja auch herkommen und hingehen.

[Skysnake]

Also laut Prof. Brüning, der im "HT center of Excellenz" ist, und ein low latency NIC gebaut hat, sowohl auf HT als auch auf PCI-E, hat PCI-E 1.000 ns Latenz, und HT so 50 ns (kann auch 20ns gewesen sein).

Der Unterschied ist also schon recht groß. Vor allem für kleine Datenpakete wird man halt mit PCI-E 3.0 nicht schneller werden. Man hat ja die 128/130 Bit Codierung. Es wäre also nur möglich, hier gesondert für kleine Datenpakete, die 8/10 Bit Codierung wieder zu verwenden, es HT tut. Man hat aber halt noch immer den ganzen Drecks overhead von PCI-E. HT geht halt so aus dem Prozessor einfach raus. Basta, da muss man nix mehr machen :D

[Coda]

One Eure Diskussion zu verstehen möchte ich meinen Senf zu der Latenzdiskussion doch mal dazugeben, Wie auf Seite 5 des verlinkten Dokuments erwähnt wird, muss man bei PCIe alle Bits eines Wortes erst serialisieren, auf alle verfügbaren Lanes verteilen und auf der anderen Seite wieder einsammeln, da die Übertragung asyncron verläuft. Außerdem kommen noch 25% Overhead dazu und dann muss der ganze Kram noch geprüft, korrigiert und wieder sortiert werden.
Das sollte aber in den Ergebnissen später alles berücksichtigt sein.

Wenn nicht, lass ich mich gerne vom Gegenteil überzeugen. Mich haben die Werte auch gewundert, weil ich auch von weitaus größeren Unterschieden ausgegangen bin.

[Gauß]

Wat? :freak:

Speicherzugriffe, die halt nicht alligned sind, wie z.B. Speicherzugriffe, die jeweils um eine Cacheline versetzt sind, oder halt immer auf ne andere Bank des Speichers landen sind langsam, das hat aber nichts mit der Software zu tun. Man kann halt nur auf die eine Bank oder die andere Zugreifen.

Nichts anderes sag ich im ersten Teil. Man sollte einfach unterscheiden, woher Probleme kommen. Von Software, oder davon, dass die Hardware einfach gewissen Limitierungen unterliegt. Was ist daran schwer zu verstehen?:confused:Es hat nichts mit der Frage zu tun ob ein gemeinsamer Adressraum effizienter sei.

So als nächster Punkt kam halt, dass ne API halt immer zusätzliche Latenzen verursacht. Egal was du machst, die physikalische Übertragung musst du ja trotzdem machen, und das geht halt in Hardware deutlich schneller als in Software mit nem OS Trap oder whot ever. Da machst du ja auch nichts anderes als den Transfer dann halt von der Software aus zu starten, um z.B. den DMA zu programmieren.

Eine Hardwarelösung ist daher eigentlich immer im Vorteil im Vergleich zu ner Softwarelösung, ganz schlechte Implementierungen mal ausgenommen. Das Einzige was einem davon abhält ist halt die Komplexität.

Was ist daran schwer zu verstehen? Es soll nur zeigen, dass die OS Traps sich eben sehr stark auf die Leistung auswirken. Wir ham mal die Aufgabe gehabt im Prinzip genau so etwas zu machen. Es war verblüffend, wie man die Performance mit OS Traps in die Knie zwingen kann.

War am Bsp. eines Webservers, wenn ich es richtig im Kopf hab.Und was hat ein Webserver mit den Datenströmen einer GPU-Anwendung zu tun? Es ist z.B. für Spiele völlig untragbar das Seitenfehler irgendwelche Unterbrechungen aus heiterem Himmel auslösen, also hat das überhaupt keine Relevanz.

Und ja PCI-E hat so ne Latenz von 1 µs, so grob. Dennoch macht ne Softwarelösung einiges aus. Wenn du nur 1k Taktzyklen für die Abarbeitung des gesamten API-Aufrufs brauchst, dann bist du bei 1 GHz schon bei deiner µs. Du bist also schnell in der gleichen Größenordnung wie die reine Übertragung über das PCI-E Protokoll.Ein Datentransfer zwischen CPU und GPU dauert in der Praxis mindestens 60 Mikrosekunden (selbst gemessen). Zum Beispiel ein regulärer Aufruf für glBufferData benötigt gerade einmal 87 CPU-Instruktionen (nvoglv32.dll), was auf einer CPU der Mittelklasse in deutlich weniger als 10 Nanosekunden erledigt ist.
Alles was dahinter noch gemacht wird muss auch bei einem memcopy in software erledigt werden und letztendlich muss auch die Planungsoptimierung wie sie der Treiber vornimmt irgendwo implementiert werden.

[Skysnake]

Also laut Prof. Brüning, der im "HT center of Excellenz" ist, und ein low latency NIC gebaut hat, sowohl auf HT als auch auf PCI-E, hat PCI-E 1.000 ns Latenz, und HT so 50 ns (kann auch 20ns gewesen sein).

Hab nochmals genau diesen Punkt nachgefragt. Es waren die 1µs für die komplette Abarbeitung des Stacks. Ob da jetzt Highlvl API mit dabei ist, konnte mir der Tutor nicht mehr genau sagen. Würde sich aber mit der Aussage oben bzgl. den ~250ns decken.

PS: War nicht selbst Prof. Brüning, sondern einer seiner Mitarbeiter. Hatte mich da falsch erinnert. Man verzeihe mir :rolleyes:



Es hat nichts mit der Frage zu tun ob ein gemeinsamer Adressraum effizienter sei.

Habe ich das gesagt?

Les nochmal ;)

Ich hab selbst gesagt, dass man aufpassen sollte WARUM etwas langsam ist. Für manche Sachen spielt die API etc ne Rolle, und für andere ist es eben absolut BUMS egal, da eben eine Beschränkung des physikalischen Hardwarezugriffs besteht.

Hab ich auch im letzten Post schon gesagt. Ich hoffe es ist jetzt klar.:freak:


Und was hat ein Webserver mit den Datenströmen einer GPU-Anwendung zu tun? Es ist z.B. für Spiele völlig untragbar das Seitenfehler irgendwelche Unterbrechungen aus heiterem Himmel auslösen, also hat das überhaupt keine Relevanz.

Du hast da ja auch keinen "Seitenfehler" sondern eher nen "Cachemiss". Der Ram ist ja noch immer deutlich schneller als ne HDD

Und das mit dem Webserver, sollte einfach nur verdeutlichen, dass solche API-Aufrufe mit OS Trap eben nicht zwingend vernachlässigbar sind. Hier gab es ja die Aussage, dass die API-Aufrufe absolut nichts ausmachen würden, und das ist so pauschal eben nicht richtig.


Ein Datentransfer zwischen CPU und GPU dauert in der Praxis mindestens 60 Mikrosekunden (selbst gemessen).

Mit was/wie gemessen?


Zum Beispiel ein regulärer Aufruf für glBufferData benötigt gerade einmal 87 CPU-Instruktionen (nvoglv32.dll), was auf einer CPU der Mittelklasse in deutlich weniger als 10 Nanosekunden erledigt ist.

In OpenGL bin ich leider bisher noch nicht vertraut. Wo wird das Buffer-Objekt initialisiert? Aus der Doku war dies nicht eindeutig klar. Ich gehe daher davon aus, dass das im Ram der CPU passiert.


Alles was dahinter noch gemacht wird muss auch bei einem memcopy in software erledigt werden und letztendlich muss auch die Planungsoptimierung wie sie der Treiber vornimmt irgendwo implementiert werden.
Nicht bei einem gemeinsamen Adressraum mit kohärentem Speicher. Da sollte eigentlich nur ein Befehlt nötig sein, um den DMA zu programmieren, und das wars dann auch.

Wenn einer was schreibt, muss man auch nicht von Hand syncronisieren, sondern das übernimmt die Hardware.

Vor allem der letzte Punkt ist halt deutlich effizienter, als dies über Software zu machen.

[Gipsel]

Ein Datentransfer zwischen CPU und GPU dauert in der Praxis mindestens 60 Mikrosekunden (selbst gemessen). Zum Beispiel ein regulärer Aufruf für glBufferData benötigt gerade einmal 87 CPU-Instruktionen (nvoglv32.dll), was auf einer CPU der Mittelklasse in deutlich weniger als 10 Nanosekunden erledigt ist.Du weißt aber schon, daß ganz allgemein so ein Aufruf an sich, deutlich länger dauern kann, als alles, was dann ausgeführt wird?

Und wie hast Du denn die "deutlich weniger als 10ns" ausgerechnet?
87 CPU-Instruktionen / 3 Instruktionen pro Takt = 29 Takte
29 Takte / 3 GHz = 9,7ns

Oder so ähnlich? :freak:

Na dann verabschiede Dich mal ganz schnell davon, so geht das nämlich nicht.

[Gauß]

Du weißt aber schon, daß ganz allgemein so ein Aufruf an sich, deutlich länger dauern kann, als alles, was dann ausgeführt wird?

Und wie hast Du denn die "deutlich weniger als 10ns" ausgerechnet?
87 CPU-Instruktionen / 3 Instruktionen pro Takt = 29 Takte
29 Takte / 3 GHz = 9,7ns

Oder so ähnlich? :freak:

Na dann verabschiede Dich mal ganz schnell davon, so geht das nämlich nicht.Ach was du nicht alles sagst... :rolleyes:

[Gipsel]

Ja, das sage ich. Und habe damit wohl sogar Recht ;)

[Gauß]

Ja, das sage ich. Und habe damit wohl sogar Recht ;)Und auf welcher Basis gehst du davon aus das ich ein naiver Depp bin der keine Grundlagen beherrscht?

[Skysnake]

Hat das wer gesagt?

Es ist aber unklar, wie du das gemessen hast, oder allgemein wie du auf die Ausführungszeit kommst. Wenn du es weist, und uns/mir erklären kannst, dann machs doch einfach.

[Gipsel]

Und auf welcher Basis gehst du davon aus das ich ein naiver Depp bin der keine Grundlagen beherrscht?
Wenn Du mich schon so fragst, weil Du dann nicht diese Aussage getaetigt haettest:
Zum Beispiel ein regulärer Aufruf für glBufferData benötigt gerade einmal 87 CPU-Instruktionen (nvoglv32.dll), was auf einer CPU der Mittelklasse in deutlich weniger als 10 Nanosekunden erledigt ist.;)

Das ist einfach unrealistisch, sogar ohne irgendwelchen calling overhead. 87 Instruktionen, Mittelklasse-CPU und deutlich unter 10ns passen nicht zusammen. So einfach ist das.

[Coda]

Mal abgesehen davon ist das ohnehin nur der User-Space-Teil. Der schreibt nur in einen Buffer rein was der eigentliche Kernel-Treiber zu tun hat, und das geht sicher nicht in 87 Takten.

Allein der dazu nötige Context-Switch ist erheblich.

[Gipsel]

Mal abgesehen davon ist das ohnehin nur der User-Space-Teil. Der schreibt nur in einen Buffer rein was der eigentliche Kernel-Treiber zu tun hat, und das geht sicher nicht in 87 Takten.

Allein der dazu nötige Context-Switch ist erheblich.
Genau. Das zudem noch die von ihm angegebene Zeit fuer die von ihm angegebenen 87 Instruktionen an sich ebenfalls schon utopisch ist, ist ja nur das Tuepfelchen auf dem i sozusagen. :wink:

[Gauß]

Hat das wer gesagt?

Es ist aber unklar, wie du das gemessen hast, oder allgemein wie du auf die Ausführungszeit kommst. Wenn du es weist, und uns/mir erklären kannst, dann machs doch einfach.Ich habe in einer Grafikanwendung für jedes Bild Daten hochgeladen (probiert habe ich selbstverständlich allerlei Formate und Volumen) und diese werden von einem Fragment-Programm verarbeitet, wobei diese nicht zurückgeschrieben werden. Die genannten 60 Mikrosekunden sind die geringste Zeitdifferenz die ich im Vergleich zu statischen Daten erreichen konnte. Die genutzte API war OpenGL 3.1 auf einer GF100 unter Windows7.

Wenn Du mich schon so fragst, weil Du dann nicht diese Aussage getaetigt haettest:
;)

Das ist einfach unrealistisch, sogar ohne irgendwelchen calling overhead. 87 Instruktionen, Mittelklasse-CPU und deutlich unter 10ns passen nicht zusammen. So einfach ist das.Ich habe den Durchschnitt für alle glMapBuffer-Aufrufe in einer Anwendung gemessen. Ob der Messwert für den Aufruf, wo ich die Instruktionen abgezählt habe, zutrifft? Keine Ahnung, ist auch völlig Wurscht. Kann jeder schnell selbst nachmessen das der Aufwand für den Befehl einer Speicherabbildung im Verhältnis zur eigentlichen Ausführung völlig vernachlässigbar ist (extreme Synchronisationsproblem natürlich ausgeschlossen).
Es ist einfach lächerlich das darüber diskutiert wird.

Mal abgesehen davon ist das ohnehin nur der User-Space-Teil. Der schreibt nur in einen Buffer rein was der eigentliche Kernel-Treiber zu tun hat, und das geht sicher nicht in 87 Takten.

Allein der dazu nötige Context-Switch ist erheblich.Nö, auf welcher Basis begründest du diese Behauptung? GPUView erzählt das genaue Gegenteil.
Der KMD führt nur noch den DMA-Befehl dazu aus (sobald dies möglich ist) weil alles andere bereits vorher passiert. Zudem werden da keine einzelnen Befehle, sondern Massen davon verarbeit.

Vorschlag: wir warten einfach ab ob ein vereinter Adressraum die Leistung mit heterogenen Speicherdomänen -wie auch immer- verbessern wird, oder nicht.
Halt genauso wie wir mit der Zeit ein Antwort auf die Frage bekommen haben ob WebGL & Co. ein Sicherheitsrisiko sei, nicht war? ;D

[Skysnake]

Ich habe in einer Grafikanwendung für jedes Bild Daten hochgeladen (probiert habe ich selbstverständlich allerlei Formate und Volumen) und diese werden von einem Fragment-Programm verarbeitet, wobei diese nicht zurückgeschrieben werden. Die genannten 60 Mikrosekunden sind die geringste Zeitdifferenz die ich im Vergleich zu statischen Daten erreichen konnte. Die genutzte API war OpenGL 3.1 auf einer GF100 unter Windows7.

Ich geh mal davon aus, dass du CUDA verwendet hast. Richtig? Wenn ja, post mal bitte den Codeabschnitt, wo und wie du gemessen hast. Der Teufel steckt bei solchen Sachen sehr im Detail.


Ich habe den Durchschnitt für alle glMapBuffer-Aufrufe in einer Anwendung gemessen. Ob der Messwert für den Aufruf, wo ich die Instruktionen abgezählt habe, zutrifft? Keine Ahnung, ist auch völlig Wurscht. Kann jeder schnell selbst nachmessen das der Aufwand für den Befehl einer Speicherabbildung im Verhältnis zur eigentlichen Ausführung völlig vernachlässigbar ist (extreme Synchronisationsproblem natürlich ausgeschlossen).
Es ist einfach lächerlich das darüber diskutiert wird.

Jetzt ist aber noch immer nicht klar, WO der Buffer liegt. Liegt der im RAM der CPU oder der GPU?
Und noch was, was macht denn der Befehl denn genau alles?

[Gipsel]

Der KMD führt nur noch den DMA-Befehl dazu aus (sobald dies möglich ist) weil alles andere bereits vorher passiert. Zudem werden da keine einzelnen Befehle, sondern Massen davon verarbeit.
So,und jetzt überlege mal, was das für eine Auswirkung auf die Latenz der Übertragung hat.
Halt genauso wie wir mit der Zeit ein Antwort auf die Frage bekommen haben ob WebGL & Co. ein Sicherheitsrisiko sei, nicht war? ;DWarst Du das mit dem Speicherschutz? Dir ist aber klar, daß die WebGL-Lücken damit nichts zu tun haben (die sind zum Teil ja auch Lücken der Browser oder der Implementation)? Einen Bluescreen zu erzeugen oder über Laufzeittests den ungefähren Inhalt von irgendwelchen Texturen zu ermitteln würde dadurch nicht verhindert werden. Du kannst mit ähnlichen Methoden auch auf CPUs z.B. den zu einem anderen Prozeß gehörenden Cache-Inhalt analysieren.

[Skysnake]

So,und jetzt überlege mal, was das für eine Auswirkung auf die Latenz der Übertragung hat.


Danke, mir ist als ich es gelesen habe, gerade das Lichtlein aufgegangen :freak:

Manchmal ist man so blind :lol:

[Gauß]

Ich geh mal davon aus, dass du CUDA verwendet hast. Richtig? Wenn ja, post mal bitte den Codeabschnitt, wo und wie du gemessen hast. Der Teufel steckt bei solchen Sachen sehr im Detail.


Jetzt ist aber noch immer nicht klar, WO der Buffer liegt. Liegt der im RAM der CPU oder der GPU?
Und noch was, was macht denn der Befehl denn genau alles?Genau wie viel Stunden Anfängerkurs soll ich dir weihen? :rolleyes:

So,und jetzt überlege mal, was das für eine Auswirkung auf die Latenz der Übertragung hat.Was soll dieser Blödsinn?! Hast du dir mal überlegt was es für eine Auswirkung auf die Fallgeschwindigkeit eines Körpers hat wenn man ihn fallen lässt?
Höre doch einfach mal mit diesem hohlen Gelaber auf und sag ganz konkret wie ein vereinigter Adressraum für heterogenen Speicher die Leistung verbessert. Ich bin sehr sehr gespannt!

Warst Du das mit dem Speicherschutz? Dir ist aber klar, daß die WebGL-Lücken damit nichts zu tun haben (die sind zum Teil ja auch Lücken der Browser oder der Implementation)? Einen Bluescreen zu erzeugen oder über Laufzeittests den ungefähren Inhalt von irgendwelchen Texturen zu ermitteln würde dadurch nicht verhindert werden. Du kannst mit ähnlichen Methoden auch auf CPUs z.B. den zu einem anderen Prozeß gehörenden Cache-Inhalt analysieren.Wie bitte?! Diese Sicherheitslücken sind exakt das was du in der Diskussion geleugnet hattest und selbstversändlich zielt ein Speicherschutz des GPU-Speichers darauf ab genau diese Lücken zu verhindern.
Ach was vergeude ich hier wieder meine Zeit mit Internetdiskussionen wo sich nur Leute profilieren wollen?

Danke, mir ist als ich es gelesen habe, gerade das Lichtlein aufgegangen :freak:

Manchmal ist man so blind :lol:Kindergarten

[Coda]

Entschuldige bitte, aber der einzige der hier so klingt als müsse er sich profilieren bist du.

Null sinnvolle Argumentation und große Fresse reißen. Selbst wenn du hier recht haben solltest disqualifizierst du dich völlig damit.

[Gaestle]

Kindergarten

Gauß, warum so hart?

Hier sind Laien (wie ich), Halblaien, Hobbyentwickler und (mindestens ein) professioneller Entwickler am Start. Und natürlich gibt es (wie überall) einige junge, selbstbewusste und vielleicht sogar etwas übermütige Mituser. Es wäre für relativ passive Leser wie mich ein Gewinn, wenn Du ein wenig Nachsicht und Geduld hättest, auch wenn es Dir natürlich gar nix bringt und deshalb auch egal sein kann.

@Coda: Trotz meiner vollständigen technischen Ahnungslosigkeit vermute ich, dass er weiß wovon er schreibt und dass das Problem wieder mal nur die Begrenztheit der Sprache (ergo: Missverständnisse im Bereich von Begriffsdefinitionen) ist.

[Gipsel]

Was soll dieser Blödsinn?! Hast du dir mal überlegt was es für eine Auswirkung auf die Fallgeschwindigkeit eines Körpers hat wenn man ihn fallen lässt?
Du erzaehlst uns, ein gemeinsamer Adressraum, wo keine API-Aufrufe getaetigt werden muessen, damit die GPU auf den CPU-Speicher zugreifen kann, haette keine Performancevorteile, begruendest das damit, dass Du gemessen hast, dass Uebertragungen von CPU zu GPU mindestens 60 Mikrosekunden dauern wuerden, aber der API-Aufruf an sich sehr schnell waere (auch wenn die von Dir genannten <10ns aus geschilderten Gruenden nicht stimmen koennen), vernachlaessigst dabei aber vollkommen die Sachen, die wirklich die Zeit dabei kosten. Auf Deine nicht schluessige Argumentation hinzuweisen, ist da alles andere als Bloedsinn.

Also komm' mal wieder ein wenig runter!
Wie bitte?! Diese Sicherheitslücken sind exakt das was du in der Diskussion geleugnet hattest und selbstversändlich zielt ein Speicherschutz des GPU-Speichers darauf ab genau diese Lücken zu verhindern.Na dann erzaehle mal, wie Speicherschutz etwas verhindert, wofuer man gar keinen direkten Speicherzugriff benoetigt? Diese Angriffsmethoden funktionieren wie gesagt prinzipiell auch auf CPUs. Und ein Bluescreen ist an sich auch erstmal keine Sicherheitsluecke im Sinne des Wortes.

[Skysnake]

Zumal wir ja festgestellt haben, dass die die reine Übertragung über PCI-E ja in der Größenordnung von 0,25-1µs sind. Da ist noch sehr viel Platz über bis zu den 60µs die er gemessen haben will. Wobei noch immer nicht klar ist, was der Befehl genau macht, und vor allem WO! er das macht.

Nehmen wir aber mal an, dass alles passt, dann bleiben aber halt trotzdem mal großzügig geschätzt 50% Zeitersparnis über.

Und Gauß, Anfängerkurs brauchst du mir nicht geben. Höchstens zur effektiven Nutzung von Streams, Verknüpfung von CUDA/OpenCL/OpenGL und effizienten Algorithmen, wobei das halt nicht viel mit GPUs zu tun hat, sondern eher höhere Mathematik/Numerik.

Ich finds wirklich traurig, das man über so eine Schiene kommen muss...

So BTT:

Hier im Forum war ja ein Artikel auf 4Gamer.net verlinkt worden, und da habe ich noch 2 Folien gesehen, die mir bisher entgangen waren, zumindest habe ich Sie bewusst nicht wahr genommen.

Folie 1 klärt eigentlich viele unserer Diskussionspunkte bzgl. der Scalar-Unit auf:

http://www.4gamer.net/games/135/G013536/20110711007/SS/007.jpg

Wie man sieht ist Sie leider doch nur ne Integer Unit :( Bin da wirklich enttäuscht.... Ne FPU wäre mir DEUTLICH lieber gewesen. So muss man sich wieder Gedanken machen, ob man jetzt Int oder Float nutzen soll....

Die Performance ist aber etwa so wie erwartet:

16 Bytes/Cycle (warum Cycle und nicht clock? Ein Unterschied? Ich glaub eher nicht, falls ja bitte aufklären) PS: mir ist während dem Schreiben eine Idee gekommen. Könnte damit die Ausführungszeit einer Wavefront gemeint sein?

Das müsste also heißen, dass man folgende Konstellationen hat:

1 long int/Cycle pro SIMD
2 int/Cycke pro SIMD
2 long long int/Cycle pro CU
2 Maskierungen/Cycle pro SIMD

16 Byte sind ja 128 Bit, und wir haben 4*16 SIMDs. Also 64 Recheneinheiten/CU. Wäre da dann nicht eine Wavefront von 32 Threads praktisch? (also sofern Cycle eben=Wavefront Ausführung)
Damit könnte man eben in jedem Durchlauf die Maskierung erledigen.

Die zweite Sache sind die Register:

http://www.4gamer.net/games/135/G013536/20110711007/SS/011.jpg

JEDE SIMD hat 64kB Register? :ugly:

WTF? Ich war davon ausgegangen, dass alle 4 zusammen 64kB haben.

Also wenn das stimmt, dann wird GCN ein extremes Cache/Register Monster :ugly:

Und warum steht da was von 4-128b ? Warum soll man 4-128bit Werte/cycle write/read/atomic machen können?

[Gipsel]

Hier im Forum war ja ein Artikel auf 4Gamer.net verlinkt worden, und da habe ich noch 2 Folien gesehen, die mir bisher entgangen waren, zumindest habe ich Sie bewusst nicht wahr genommen.Bei hardware.fr (http://www.hardware.fr/news/11648/afds-architecture-futurs-gpus-amd.html) gibt es die auch, und sogar nicht so verzerrt. ;)
Wie man sieht ist Sie leider doch nur ne Integer Unit.Sag' ich doch.
Die Performance ist aber etwa so wie erwartet:

16 Bytes/Cycle (warum Cycle und nicht clock? Ein Unterschied? Ich glaub eher nicht, falls ja bitte aufklären) PS: mir ist während dem Schreiben eine Idee gekommen. Könnte damit die Ausführungszeit einer Wavefront gemeint sein?

Das müsste also heißen, dass man folgende Konstellationen hat:

1 long int/Cycle pro SIMD
2 int/Cycke pro SIMD
2 long long int/Cycle pro CU
2 Maskierungen/Cycle pro SIMD

16 Byte sind ja 128 Bit, und wir haben 4*16 SIMDs. Also 64 Recheneinheiten/CU. Wäre da dann nicht eine Wavefront von 32 Threads praktisch? (also sofern Cycle eben=Wavefront Ausführung)
Damit könnte man eben in jedem Durchlauf die Maskierung erledigen.
Der Zusammenhang ist der, dass die Scalar Unit mit einem einzigen Befehl mehrere aufeinanderfolgende Register (bis zu 8 glaube ich, zumindest habe ich das bisher als Maximum im Code gesehen) aus dem Speicher fuellen kann.
Die Bandbreite von 16 Byte/Takt sagt uns also, dass bis zu 4 aufeinanderfolgende 32Bit Werte aus dem scalar Cache gelesen werden koennen (liest man mehr, dauert es eben laenger). Die angegebenen Werte gelten also in jedem Fall wirklich pro Takt und nicht pro 4 Takte. Die Scalar Unit kann ja jeden Takt einen Befehl entgegennehmen, jeden Takt einen von einem auf einem anderen SIMD laufenden Wavefront (Zugriff auf die Skalareinheit geht genau so round robin wie das Issue an die SIMDs).
Die zweite Sache sind die Register:

JEDE SIMD hat 64kB Register? :ugly:

WTF? Ich war davon ausgegangen, dass alle 4 zusammen 64kB haben.

Also wenn das stimmt, dann wird GCN ein extremes Cache/Register Monster :ugly:
Natuerlich, sogar Fermi hat ja insgesamt 128kb Register in einem SM, R600/R700/Cypress/Cayman haben alle 256kB pro SIMD (schau mal auf einen Die-Shot von Llano, da sieht man gut, dass das merklich Flaeche einnimmt, das sind die SRAM-Arrays, die direkt um jeweils 4 VLIW-Units herum gruppiert sind, das sind die sichtbaren Bloecke in den SIMDs), da sind die 4*64kb pro CU ja fast schon ein Rueckschritt (in Sachen Register pro Wavefront ist es das sogar). :wink:
Und warum steht da was von 4-128b ? Warum soll man 4-128bit Werte/cycle write/read/atomic machen können?
Das ist genau das, was die TMUs bisher koennen (die konnten nur keine atomics, das kommt neu dazu). Von 4 Adressen jeweils 16 Bytes lesen. Das koennen maximal also 4 Quads mit einem 32Bit Texturformat sein (maximal 4 bilinear gefilterte Texel) fuer Grafikanwendungen. Die koennen die Daten aber auch ungefiltert durchreichen und somit auch vier 128 Bit (xyzw bzw. rgba) Vektor lesen. Was bisher nicht geht, ist von mehr als 4 Adressen pro Takt zu lesen (Fermi kann 8 Adressen [eher 4+4, aber auch nur maximal 64 Byte pro Takt] aus Texturcache, aus L1/local memory gehen 16 pro Takt, ebenfalls auf 64 Byte pro Takt limitiert).
Bei GCN ist Textur- und General Purpose L1 cache unified, local memory gibt es extra, bei Fermi dagegen ist local memory und GP-L1 vereint, Texturcache ist extra.
GCN geht jetzt mit der Adressierung genau so weit wie Fermi, aus dem GP-L1-Cache koennen maximal 64 Byte pro Takt von 16 unterschiedlichen Adressen gelesen werden (entspricht den 16 L/S Einheiten bei Fermi). Inwiefern das bei Grafikanwendungen eine Rolle spielen koennte, muss man mal sehen (4offset_gather4 waere eine Nutzungsmoeglichkeit, oder AF-Filter mit ausgefalleneren Sampleverteilungen, also keine bilinearen Filter als Grundlage).

Aus dem LDS koennen uebrigens sogar maximal 32*4Byte gelesen werden. Der hat also bei GCN eine hoehere Bandbreite als der L1-Cache, die anders als bei Fermi obendrauf kommt und nicht geteilt wird.

[Skysnake]

Stimmt, hast recht. Das sind wirklich 256KB Register bei der 5000er/6000er Serie. Hatte die daraus resultierenden 16k Vector-Register im Kopf.

Man hat aber noch immer die Verdoppelung des LDS, was auch gut ist :D
L1 ist auch doppelt so groß. Das auch nett.

An die Sache mit RGBA hab ich nicht gedacht, wobei ich dachte, dass das nur 32 Bit Werte sind.

-.- Ach passt dann doch... Für jede SIMD dann halt genau einen Pack -.-

Ok passt ^^

Was das aber für GPGPU bringen soll ist mir noch etwas schleierhaft. Grafikausgabe juckt mich jetzt nicht wirklich. Hab mich aber auch noch nicht damit eingehend beschäftigen können. Mit der Grafikausgabe macht man halt auch gleich nen RIESEN Fass auf, wenn man das angeht -.-

Btw. was mir gerade noch eingefallen ist, zur Scalar Unit stand noch was zu flags für preämtive Scheduling ^^ Also GCN kann das wohl wirklich.

Da freut man sich wirklich, da man sich dann um so dumme Verklemmungen nicht mehr rumschlagen muss wie bei Fermi :ugly:

[Gauß]

Du erzaehlst uns, ein gemeinsamer Adressraum, wo keine API-Aufrufe getaetigt werden muessen, damit die GPU auf den CPU-Speicher zugreifen kann, haette keine Performancevorteile, begruendest das damit, dass Du gemessen hast, dass Uebertragungen von CPU zu GPU mindestens 60 Mikrosekunden dauern wuerden, aber der API-Aufruf an sich sehr schnell waereWärst du an einer sachlichen Diskussion interessiert hättest du erkannt dass deine Unterstellung falsch ist.

(auch wenn die von Dir genannten <10ns aus geschilderten Gruenden nicht stimmen koennen),Ich habe im Detail geschildert wie ich diese Messung vorgenommen habe und im Gegenzug hast du absolut nichts geschildert sondern einfach geleugnet.

Na dann erzaehle mal, wie Speicherschutz etwas verhindert, wofuer man gar keinen direkten Speicherzugriff benoetigt? Diese Angriffsmethoden funktionieren wie gesagt prinzipiell auch auf CPUs. Und ein Bluescreen ist an sich auch erstmal keine Sicherheitsluecke im Sinne des Wortes.Solch absurden Aussagen zu diskutieren ist meine Zeit nicht wert. Viel Spass dann noch.

[Skysnake]

Für Speicherkopieren etc etc ist aber kein API-Aufruf mehr notwendig, wenn man einen gemeinsamen Adressraum hat. Da gibst du einfach den entsprechenden Zeiger mit und das wars :ugly:

Gerade DU solltest das doch wissen, wenn du mit CUDA arbeitest. Da musst du immer erst von Hand die Daten rüber schieben, und dann den Kernel mit den entsprechenden GPU-Zeigern starten....

Es fällt also jeder versch... API Aufruf weg, in dem du die Daten rüber kopierst, und die summieren sich in so mancher Anwendung ganz schön auf...

Und bzgl. der Messung, nein das hast du noch nicht wirklich erklärt.

[Gauß]

Für Speicherkopieren etc etc ist aber kein API-Aufruf mehr notwendig, wenn man einen gemeinsamen Adressraum hat. Da gibst du einfach den entsprechenden Zeiger mit und das wars :uglyjojo... einfach so...

[Skysnake]

Du hast einen gemeinsamen Adressraum. Ich versteh dein Problem absolut nicht.

Man kann sich also sehr wahrscheinlich entweder aussuchen, wo man initialisiert, und die CPU dann die Daten da rein schreiben lassen, oder der GPU-RAM wird eben für swapping/cacheing benutzt, sprich wenn man Daten vom CPU-RAM liest, wird er dort, sofern Platz ist, eben zwischengespeichert, und bei Mehrfachzugriffen eben nicht jedes mal über PCI-E gehen zu müssen.

Du kannst aber gern ausführen, wo du ein Problem siehst.

[Gipsel]

Wärst du an einer sachlichen Diskussion interessiert hättest du erkannt dass deine Unterstellung falsch ist.Dann kann es wohl nur an "Deinem zusammenhanglosen Geschreibsel" (tm by Gauss (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=8822087#post8822087)) liegen, dass Du Deine Argumentation offenbar keinem hier im Thread verstaendlich machen kannst.
Ich habe im Detail geschildert wie ich diese Messung vorgenommen habe und im Gegenzug hast du absolut nichts geschildert sondern einfach geleugnet.Ich habe Dir gesagt, dass aus prinzipiellen Erwaegungen die von Dir angegebenen Zahlen nicht stimmen koennen. IPC=4 in einem API-Aufruf? Null Calling Overhead? Null Zeitaufwand fuer Context-Switch zum Kernel Mode Driver und zurueck? Das kostet zusammen wirklich eher tausende Takte als die von Dir behaupteten ~30. Denk' doch mal nach!
Solch absurden Aussagen zu diskutieren ist meine Zeit nicht wert. Viel Spass dann noch.Keine Antwort ist auch eine Antwort. :rolleyes:

[Gipsel]

jojo... einfach so...
Du kannst ja mal ueberlegen, wie eine CPU auf einem Dual-Sockel-CPU-Board in einem NUMA-System (nennt man manchmal auch SUMA, sufficiently uniform memory architecture) auf den Speicher der anderen CPU zugreift (die beiden Bereiche bilden auch einen gemeinsamen und sogar kohaerenten Adressraum). Oder auch wie die Latenzzeit beim Zugriff auf Remote-Speicher in dem Fall aussieht (okay, ist praktisch der Optimalfall, aber egal, PCI-Express 3 ist jetzt nicht soo viel langsamer als HT oder QPI) ;). Da wird es mittel- und langfristig hingehen.

[Skysnake]

Der einzige echte Nachteil von PCI-E ist halt, dass die CPU intern nicht damit arbeitet, und man daher erst mal ne CNC etc dran hängen muss. Bei HT/QPI gehts halt einfach aus dem Chip raus und gut is.

[Gipsel]

Der einzige echte Nachteil von PCI-E ist halt, dass die CPU intern nicht damit arbeitet, und man daher erst mal ne CNC etc dran hängen muss. Bei HT/QPI gehts halt einfach aus dem Chip raus und gut is.
Ich sehe da keinen prinzipiellen Nachteil bei auf dem Die integrierten PCI-Express-Controllern (die es ja jetzt schon gibt) in dieser Hinsicht. Die Latenz ist eben geringer, da es mehr darauf optimiert ist mit der 8/10 Codierung (HT, was QPI da macht, weiss ich jetzt gar nicht).

[Skysnake]

Naja doch, HT hat auch ne 128/130 Bit codierung, die für kleine Datenpakete aber auch auf 8/10 runtergebrochen werden kann, und soweit ich die Ausführungen dazu von den Leuten, die im HT Excellenzcluster sind, verstanden habe, arbeiten die AMD-CPUs eben intern praktisch schon mit HT, womit man die Signale eigentlich nur noch was außen bringen muss mit minimalen Anpassungen, und das wars auch schon.

Bei PCI-E muss man halt noch den gesamten Physischen-Layer mit CRC etc. durchlaufen. Das spart man sich halt anscheinend.

[Gipsel]

Bei PCI-E muss man halt noch den gesamten Physischen-Layer mit CRC etc. durchlaufen. Das spart man sich halt anscheinend.Das glaube ich weniger. Auch HT hat CRC, im Prinzip sogar 2 Ebenen (pro Link bzw. pro Paket). Die PHY von HT und PCI-Express sehen auf einem Dieshot auch fast gleich aus. ;)
HT hat auch deswegen weniger Latenz, weil jederzeit Kontrollpakete auch in einen ansonsten ausgelasteten Link einschieben koennen, die haben also gewissermassen eine separate Queue und hoehere Prioritaet als die normalen Datenpakete. Also viel gespart kann da nicht werden.

[Skysnake]

Naja, du brauchst ja auch innerhalb des Chips wohl ne CRC, um sicher zu sein, dass man keinen BitFlip drin hat. Das wird wohl für HT mit verwendet.

GENAU kann ich dir nicht sagen, was man sich alles spart, aber man spart sich laut denen halt scheinbar wirklich einiges.

Und der mit dem DIE-Shot und sehen ist gut ;) Die Logik sieht man ja nicht :ugly:

[S940]

Naja, du brauchst ja auch innerhalb des Chips wohl ne CRC, um sicher zu sein, dass man keinen BitFlip drin hat. Das wird wohl für HT mit verwendet.

GENAU kann ich dir nicht sagen, was man sich alles spart, aber man spart sich laut denen halt scheinbar wirklich einiges.

Und der mit dem DIE-Shot und sehen ist gut ;) Die Logik sieht man ja nicht :ugly:

Zumindest bei Sun war da nicht viel um:
http://www.orthy.de/images/stories/bokill/Sun/Niagara2/texasinstruments_sun_serdes-interface_niagara2.jpg

Alles nur Serializer/Deserializer Logik, was am Ende rauskommt ist fast beliebig :freak:

Auch hier zu sehen:
http://www.realworldtech.com/includes/images/articles/Niagara2-4.gif

PSR, ESR, FSR, das sieht alles identisch aus, was ja auch zu erwarten ist, wenns auf der gleichen µArchitektur besteht, wie im ersten Bildchen genannt.

Glaube jetzt kaum, dass das für Hypertransport <> PCIe nicht auch möglich wäre.

[Skysnake]

Also wie gesagt, soweit ich das verstanden habe ist das bei AMD CPUs eben so, dass die Datenstruktur innerhalb der CPU und zu HT die gleichen sind.

Sprich du brauchst halt wohl mit den Datenpaketen nicht viel zu machen, außer halt nochmals ne CRC oder so drum rum und halt das Signal treiben, das wars dann aber auch.

Sprich die 8/10 bzw. 128/130 Bit Codierung, die halt viel Zeit frisst muss man wohl nicht machen.

Wie gesagt, GENAU hab ich da jetzt nicht nachgefragt, was da genau der Unterschied ist, denn da wäre ich wohl vor ner Stunde nicht mehr weg gekommen :ugly:

[Coda]

Ich unterstelle deinem Professor aber auch eine gewisse Befangenheit, wenn er im HT-Center of Excelence arbeitet ;)

[Skysnake]

Mit dieser Einschätzung würde ich dir normal auch absolut Recht geben, wenn er nicht auch "Probleme" bei AMD ansprechen würde, wie die nur 40Bit physikalische Speicheradressierung (oder warens 48Bit bei den aktuellen?).

Zudem haben die ja Extoll gebaut, was sowohl HT als auch ein PCI-E Interface hat, wobei Extoll ein low latency Interconnect ist. HT ist einfach schneller und da gibts ja wirklich nichts zu verschenken an Latenz, wenn man sich mit Myrinet und Infiniband anlegt :ugly:

Ich denke die haben daher schon das Maximum aus beidem raus geholt.

[Coda]

Das könnte dann aber auch einfach am Protocol-Layer liegen. Du darfst nicht vergessen, dass AMD hier freie Handhabe hat, wenn AMD GPU+CPU kombiniert werden.

[Skysnake]

Auf was bezieht sich der Post gerade?:uconf3:

[Gipsel]

Auf was bezieht sich der Post gerade?:uconf3:
Ich vermute mal, es geht in die Richtung:
HT hat auch deswegen weniger Latenz, weil jederzeit Kontrollpakete auch in einen ansonsten ausgelasteten Link einschieben koennen, die haben also gewissermassen eine separate Queue und hoehere Prioritaet als die normalen Datenpakete.

[Coda]

Auf was bezieht sich der Post gerade?:uconf3:
Auf den Latenz-Unterschied zwischen HT und PCIe.

Ich sehe da zwar schon auch Unterschiede von der Auslegung her, aber die gemessenen Unterschiede sind schon extrem.

Kann allerdings auch sein, das die Buffer, die die unterschiedlichen Lane-Längen ausgleichen die Ursache sind. Soweit ich weiß sind die Routing-Vorgaben für HyperTransport und QuickPath strenger.

[Gipsel]

Übrigens gibt es jetzt auch die Präsentation von Mike&Mike vom AFDS (http://developer.amd.com/afds/assets/presentations/2620_final.pdf) als pdf.

Edit:
Im Anhang auf Seite 43 sind dann auch die "Dependency Counters" erwähnt, mit der die Konsistenz bei local memory/Speicherzugriffen sichergestellt wird, ohne auf Scoreboarding zurückgreifen zu müssen, wie von mir hier schon mal erläutert (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=8814050#post8814050).

[Coda]

Ich muss schon sagen, das sieht alles sehr vielversprechend und durchdacht aus.

[mboeller]

habs gerade in einem anderen Forum gesehen:

http://vr-zone.com/articles/next-generation-gpus-amd-s-cray-on-a-chip-/13163.html

+

http://groups.google.com/group/comp.arch/browse_thread/thread/d2a359486239c67b/47b1adab7b7f7307

Schaut so aus, als ob AMD, zumindest von der Architektur-Seite her alles richtig gemacht hat. Der Kommentar von Andy Glew "Larrabee done right" hört sich schon einmal gut an.

[Gipsel]

habs gerade in einem anderen Forum gesehen:

http://vr-zone.com/articles/next-generation-gpus-amd-s-cray-on-a-chip-/13163.html

+

http://groups.google.com/group/comp.arch/browse_thread/thread/d2a359486239c67b/47b1adab7b7f7307

Schaut so aus, als ob AMD, zumindest von der Architektur-Seite her alles richtig gemacht hat. Der Kommentar von Andy Glew "Larrabee done right" hört sich schon einmal gut an.
Andy Glews Kommentar zum Vergleich mit Larrabee würde ich mal nicht so ernst nehmen. Den hat er offensichtlich getätigt, bevor er die Präsentation wirklich gesehen hat. Denn er hat (wie dem Kommentar dort zu entnehmen) offensichtlich einige Aspekte von GCN etwas falsch verstanden.

Der VR-Zone-Artikel beleuchtet die Sache gar nicht mal so schlecht, auch wenn die Abschätzung der DP-Rechenleistung vollkommen daneben ist (die gehen von Full-Rate aus, obwohl AMD klar gesagt hat, daß es maximal Half-Rate wird, und auch das höchstens bei den Top-Modellen bzw. den Firestreams).

Was beim Vergleich mit Larrabee übrig bleibt, ist das man eine Skalareinheit (nur eben ohne x86) mit (einer) Vektoreinheit(en) kombiniert.
Bei Larrabee war es je ein x86er-Kern mit einer 512 bit breiten Vektoreinheit, die (4fach)SMT können.
Bei GCN ist es eine (abgespeckte) Skalareinheit für vier 512Bit breite Vektoreinheiten, die allerdings logisch auf 2048Bit breiten Vektoren arbeiten (und dafür dann 4 Takte brauchen, wodurch man wieder beim 1:1 Verhältnis des Durchsatzes von Skalareinheit [die jeden Takt ein Befehl entgegenehmen kann] und Vektoreinheit landet), die im Prinzip jeweils 5/6/10 fach SMT (je nachdem, wie man zählt) je SIMD können (die Skalareinheit teilen sich also bis zu 40 Threads/Wavefronts).

Insgesamt kann man schon sagen, daß die Architektur so aussieht, als wenn AMD da ein wenig länger drüber nachgedacht hat, und wirklich (wie der zweite Kommentar bei Deinem Google-Groups-Link und auch AMD selber bei der GCN-Präsentation gesagt hat), von der Cray-X1-Architektur inspiriert wurde, die allerdings noch stark auf die Erfordernisse von GPUs zugeschnitten wurde.
Beim dort angesprochenen X1 besteht jeder MSP (Multistreaming-Processor, grob äquivalent zur CU) aus vier SSPs (single-stream processor, ganz grob ein GCN-SIMD), wobei allerdings jeder SSP eine 2 way superskalare Skalareinheit (und nicht eine für alle 4 geteilt wird) sowie zwei Vektoreinheiten besitzt (nur eine lane!, variable Vektorlänge, wie eben bei klassischen Vektorrechnern, 32stage pipeline). Übrigens saßen 4 SSPs zusammen mit vier Cache-Chips auf einem MCM-Modul (mit einem Verbrauch von so ~400W), welches einen MSP gebildet hat, also weit davon entfernt, daß man davon 32 oder so auf ein Die packt. Der X1 lief mit 800 MHz für die Vektoreinheiten und 400 MHz für die Skalareinheiten. Ein MSP machte 12.8 GFlop/s (double precision natürlich, 3.2 GFlop/s pro SSP), eine CU bei 800 MHz kann 102 GFlop/s in SP (51 in DP).

Der Hauptunterschied für den Durchsatz kommt daher, daß der X1 nur single-lane-Vektoreinheiten benutzt, GCN (wie schon Radeons vorher oder auch Fermi) Vektor-ALUs mit 16 lanes (ich glaube, das ist der Hauptpunkt, der an Andy Glew vorbei gegangen ist ["They are even giving up on SIMT/CT (Single Instruction Multiple Threads/Coherent Threading)."], was klar falsch ist, mal abgesehen von den bescheuerten Begrifflichkeiten). Die Crays hatten den Vorteil, daß sie flexibel mit unterschiedlichen Vektorlängen umgehen können (da die Einheiten selbst eben immer nur ein Datenelement pro Takt bearbeitet haben, eben nur über eine variable Anzahl von Takten). Die lange Pipeline (32 stages) limitiert aber die minimale effektive Vektorlänge ohne ILP allerdings auf 32 Elemente, also sehr ähnlich zur Wavefront-/Warp-Größe bei Grafikkarten. Außerdem waren die Crays flexibler beim Zuweisen von Arbeit zu den SSPs (single-stream vs. multi-stream mode), aber das würde hier wohl zu weit führen.

[Skysnake]

Genau das hab ich auch gesagt, als ich die GCN Folien gesehen hab.

"Sieht wie ein Vektorrechner aus", was die Crays ja waren. Da hats komischerweise keinen interessiert. Naja egal.

Wenn ihr wollt, kann ich mal mein Skript vom letzten Jahr durchkruschteln zu parallele Rechnerarchitekturen. Da war ein nettes Blockbild zu Vektorrechnern/Cray zu finden.

Wenn ihr wollt kann ich mal die Folien dazu hier online stellen. Sagt einfach bescheid.

[deekey777]

So, Tahiti als erster der GCN-Generation ist draußen, da stellt sich die Frage:
Vor allem wird das Ding auch ohne Flimmer-AF kommen und wird offenbar ordentlich Geometry- und Rechenleistung haben. Was können sie denn bitte noch falsch machen?

[LovesuckZ]

So wie sich Dave Baumann um eine klare Ansage bzgl. des DP:SP Verhältnis windet, kann man wohl davon ausgehen, dass SI nur ein 1:4 Verhältnis haben wird:


AFDS was talking about the architecture in terms of capabilities and scalability, not any specific products implemented on the architecture.
http://forum.beyond3d.com/showpost.php?p=1608081&postcount=1926

[deekey777]

Eric Demers and GCN, Part II@Rage3D (http://www.rage3d.com/interviews/amdchats/eric_demers_dec_2011/)
12x64 KB L2-Cache.
Frontend unverändert, aber verbessert, was die Auas angeht.

[DrumDub]

So wie sich Dave Baumann um eine klare Ansage bzgl. des DP:SP Verhältnis windet, kann man wohl davon ausgehen, dass SI nur ein 1:4 Verhältnis haben wird:

http://forum.beyond3d.com/showpost.php?p=1608081&postcount=1926 öhmm .. das ist doch spätestens seit den ersten tests klar: Jede Vec16-Einheit kann pro Takt 16 FP-MAD-Operationen bei Single-Precision (32 bit) beziehungsweise 4 FP-MAD-Operationen bei Double-Precision (64 bit) beisteuern.
http://ht4u.net/reviews/2011/amd_radeon_hd_7900_southern_island_test/index4.php

[y33H@]

Ja, 1:4 DP zu SP - der Kollege von HT4U hat völlig Recht.

[Captain Future]

Eric Demers and GCN, Part II@Rage3D (http://www.rage3d.com/interviews/amdchats/eric_demers_dec_2011/)
12x64 KB L2-Cache.
Frontend unverändert, aber verbessert, was die Auas angeht.

Nur sagt das leider James, nicht Eric. Eric ist korrekt damit, von 50% more L2 caches zu sprechen. 4x1,5=6.

[Gipsel]

Übrigens, mal ein Urteil über Tahiti aus berufenem Munde: (http://forum.beyond3d.com/showthread.php?p=1608435#post1608435)
This is the best desktop graphics architecture and physical implementation ever.
Hmm, das "ever" ist vielleicht etwas übertrieben, "to date" hätte sicher auch gereicht. :rolleyes:

[mapel110]

Das ist auch so eine Null-Aussage. Ich war noch NIE so alt wie heute...

"Some rough edges, but that's the long and short of it." Bitte nicht vergessen. ;)

[Gipsel]

Das ist auch so eine Null-Aussage. Ich war noch NIE so alt wie heute...
Hmm, aber Du bist nicht der älteste Mensch aller Zeiten, oder? Rys beschränkt sich ja nicht nur auf AMD-Architekturen. ;)

[mapel110]

Hmm, aber Du bist nicht der älteste Mensch aller Zeiten, oder? Rys beschränkt sich ja nicht nur auf AMD-Architekturen. ;)
Mit einer neuen Architektur und einem neuen Fertigungsprozess sollte man auch besser sein als alles andere. Wirklich aussagekräftig beurteilen kann man es erst, wenn Kepler da ist.

[LovesuckZ]

Das ist auch so eine Null-Aussage. Ich war noch NIE so alt wie heute...

"Some rough edges, but that's the long and short of it." Bitte nicht vergessen. ;)

Ja, Fermi war 20 Monate lang "the best desktop graphics architecture and physical implementation ever." Die Aussage ist alleine schon aufgrund des weiterhin bemitleidenswerten Front-End unsinnig.

GCN ist ein evolutionärer Schritt im Gesamtmarkt. Nichts weltbewegendes und noch einiges zum Nachholen.

[kunibätt]

Es gibt schon GPGPU-Szenarien (Luxrender/Luxmark) in denen Tahiti mindestens 3 mal schneller ist als eine GTX580 (angenommen eine Gtx580 ist überhaupt 1,5x schneller als eine GTX570@625).
Wenn sich diese Ergebnisse auf Renderer wie Cycles oder V-Ray übertragen lassen sollten, ist das schon eine überaus schöne Karte für GPGPU-Zeug. Andere Präferenzen bleiben wie bekannt grün-rot geprägt.

[AnarchX]

Mal was zur IMC-Skalierbarkeit:
R3D: How granular can you be with disabling parts, can you get down to a 320-bit with reduced number of cores inside each CU?
Eric: : We don't have per channel selectivity but there are a lot of configurations, certainly 256-bit and 128-bit. I don't know that we'd do a 128-bit. There is some flexibility there, that the Tahiti Pro will take advantage of, if they so decide.
http://www.rage3d.com/interviews/amdchats/eric_demers_dec_2011/

[AnarchX]

Wohl doch nur 1:4 DP in HW bei Tahiti: http://forum.beyond3d.com/showpost.php?p=1609122&postcount=2172

[Coda]

Ja, das hat AMD auch so gesagt. War das nicht auf den Folien?

[LovesuckZ]

Ja, das hat AMD auch so gesagt. War das nicht auf den Folien?

Auf der Konferenz haben auf eine Zuschauerfrage geantwortet, dass GCN ab 1:2 nach unten skaliert. Jetzt wissen wir, das es dort nur um die abstrakte Architektur ging.

[Coda]

Sie haben gesagt, dass es 1:4 ist bei Tahiti, die Architektur für andere Chips aber auch 1:2 und 1:8 unterstützt.

[Felixxz2]

Also ist es noch nicht vom Tisch, dass GCN als FirePro dann doch 1:2 hat? In SP ist Tahiti im GPGPU Bereich schon ne Wucht, aber mit 1:2 DP wär das wohl ein ziemlicher hammer mit 1,9 TFLOP/s DP.

Für GPGPU führt wohl derzeit kein Weg an GCN vorbei. Eine GTX580 hat teils übles nachsehen. Mal sehen ob AMD hier gut einschlagen kann, ihr Produkt ist Top und die Schnittstellenunterstützung im Prinzip auch. Freu mich schon auf die ersten Supercomputer mit GCN.

[Skysnake]

naja, immer mal auf dem Teppich bleiben. Kepler muss erst mal erscheinen, und MIC muss auch noch berücksichtigt werden.

Der HPC-Markt ist stärker umkämpft als die Jahre zuvor.

[Skysnake]

Sorry fürn Doppelpost, aber sonst gehts sicherlich unter.

GCN ist ja jetzt schon ein paar Tage vorgestellt, und die ersten Karten landen bei den Leuten. Von einem Whitepaper und einem GCN Programmer-Guide ist aber weit und breit keine Spur.....

Hat jemand von euch Infos, wann die kommen sollen, oder hat jemand sogar einen Link parat?

Wäre wirklich gut. Will mich so langsam in GCN einarbeiten, was die Programmierbesonderheiten/Optimierungsstrategien betrifft.

[DrumDub]

war das schon bekannt?

In addition to everything else, Tahiti has a distinctive new capability called partially resident textures, or in the requisite TLA, PRTs. This feature amounts to hardware acceleration for virtual or streaming textures, a la the "MegaTexture" feature built into id Software's recent game engines, including the one for Rage. Tahiti supports textures up to 32 terabytes in size, and it will map and filter them. Large textures can be broken down into 64KB tiles and pulled into memory as needed, managed by the hardware.

AMD's internal demo team has created a nifty animated demonstration of this feature running on Tahiti. The program implements, in real time, a method previously reserved primarily for offline film rendering. In it, textures are mapped on a per-polygon basis, eliminating the need for an intermediate UV map serving as a two-dimensional facsimile of each 3D object. AMD claims this technique solves one of the long-standing problem with tessellation: the cracking and seams that can appear when textures are mapped onto objects of varying complexity.

The firm is hopeful methods like this one can remove one of the long-standing barriers to the wider use of tessellation in future games. Trouble is, Tahiti's PRT capability isn't exposed in any current or near-future version of Microsoft's DirectX API, so it's unlikely more than a handful of game developers—those who favor OpenGL—will make use of it anytime soon. We're also left wondering whether the tessellation hardware in AMD's prior two generations of DirectX 11 GPUs will ever be used as effectively as we once imagined, since they lack PRT support and are subject to the texture mapping problems Tahiti's new hardware is intended to solve. http://techreport.com/articles.x/22192/4

scheint mir ne ziemliche clevere sache zu sein.

[Gipsel]

Ohne mich damit jetzt genau auszukennen, aber das könnte auch mit DirectX funktionieren. Der Treiber meldet ja die maximal möglichen Texturgrößen. Wenn man einfach sehr große Texturen nutzt, kann die Hardware/der Treiber das Nachladen in den VRAM so handhaben, wie es beliebt. Da gibt es meines Wissens keine Vorgaben seitens Microsoft (lasse mich da aber auch korrigieren), so daß das PRT-Feature auch transparent für DirectX implementiert werden kann (wäre für den Programmierer wahrscheinlich sogar das einfachste, auch wenn vielleicht in einigen Situationen eine direkte Möglichkeit zur Steuerung wünschenswert wäre). Das Mapping der Texturkoordinaten erledigen ja sowieso Shader, das liegt also vollkommen in der Hand des Programmieres, da kann er also machen, was er will, da funkt DX nicht dazwischen.

[Hayab]

Gibts welche GPGU Renderbenches mit der 7970. zb, mit dem Quicksilver Hardwarerenderer von 3DSmax?
Ich find nur Spielebenches ueberall.

[Knuddelbearli]

http://www.tomshardware.de/AMD-GCN-Tahiti-Graphics_Core_Next-HD_7970,testberichte-240931-14.html

[Hayab]

Danke.

Bei Luxrenderer geht die 7970 echt gut ab.:eek:

So langsam werden die GPGU support fuer CAD Workstation sehr wichtig, weil die Hardwarerenderer qualitativ fast so gut sind wie die, die ueber CPU alleine Laufen. Brauchen aber nur ein Bruchteil der Rechenzeit.

[Bucklew]

So langsam werden die GPGU support fuer CAD Workstation sehr wichtig
So langsam? :ugly:

Den Markt hat AMD jetzt schon seit Jahren verpennt...

[Coda]

Der Treiber meldet ja die maximal möglichen Texturgrößen.
Nope. Das ist fest vorgegeben für DX10 und DX11 (8192^2 und 16384^2).

[Gipsel]

Nope. Das ist fest vorgegeben für DX10 und DX11 (8192^2 und 16384^2).
Stimmt, das ist als Maximum definiert. Zwar kann man auch die maximalen Texturdimensionen abfragen, aber das hilft dann ja überhaupt nicht weiter. Da brauchen wir dann also DX11.2 oder sowas in der Art.

[Coda]

Man braucht DX11.2 sowieso, weil die Shader auch das Verhalten bei Page-Faults etc. steuern können sollten.

[deekey777]

http://twitter.com/#!/ID_AA_Carmack/status/157512179749371907
Are you going to add support in Rage for the 7970's hardware PRT Mega texturing anytime soon?

7970 hardware virtual textures are limited to 32k, so it requires layout changes to avoid tex crossing. Doom will support.

[Gipsel]

http://twitter.com/#!/ID_AA_Carmack/status/157512179749371907
Hmm, AMD selber spricht von 16k x 16k x 8k als Maximum (also im Prinzip eine Sammlung von 8192 16k x 16k Texturen, ergibt maximal 32 TByte Texturgröße). Eine explizite Erwähnung der Maximalgröße mit nur 2 Indizes habe ich auf die Schnelle nicht gefunden.

Ein Beschränkung auf 16k (14 bit) oder maximal 32k in einer Dimension macht übrigens Sinn, da die zur Adressierung benutzten floats sonst keine gute "Positioniergenauigkeit" mehr aufweisen (die Filterqualität sinkt dann, ATIs bieten hier bisher 8 Bit oder gar 9 Bit Abstufungen der Filtergewichte zwischen den einzelnen Texeln, das wäre mit mehr als 16k bzw. 32k als Texturdimension nicht mehr möglich).

[deekey777]

Hier eine HD7900-Demo:
http://developer.amd.com/samples/demos/pages/AMDRadeonHD7900SeriesGraphicsReal-TimeDemos.aspx
The Leo demo showcases a real-time, DirectX® 11 based lighting pipeline that is designed to allow for rendering scenes made of arbitrarily complex materials (including transparencies), multiple lighting models, and minimal restrictions on the number of lights that can be used -- all while supporting hardware MSAA and efficient memory usage.

Specifically, this demo uses DirectCompute to cull and manage lights in a scene. The end result is a per-pixel or per-tile list of lights that forward-render based shaders use for lighting each pixel. This technique also allows for adding one bounce global illumination effects by spawning virtual point light sources where light strikes a surface. Finally, the lighting in this demo is physically based in that it is fully HDR and the material and reflection models take advantage of the ALU power of the AMD Radeon HD 7900 GPU to calculate physically accurate light and surface interactions (multiple BRDF equations, realistic use of index of refraction, absorption based on wavelength for metals, etc).

[boxleitnerb]

Sieht hervorragend aus auf künstlerischer Seite. Gefällt mir 1000x besser als diese Roboter-Kiddie-Demos, die es in letzter Zeit von AMD gab. Die Demo wirkt wie ein Pixarfilm und ist total glatt, kein Flimmern, gar nichts. Faszinierend, dass das jetzt schon in Echtzeit möglich ist.

[y33H@]

Am Anfang war ich skeptisch, aber mittlerweile muss ich sagen, es ist eine der besten Demos, die ich je gesehen habe =)

[boxleitnerb]

Läuft die auch auf Nvidias? :D

[mapel110]

Video ist offenbar down. :(
Läuft die auch auf Nvidias? :D
Laut Anforderungen Nein. Böses, böses AMD. :unono:

[y33H@]

Video ist offenbar down.http://videos.pcgameshardware.de/hdvideo/6523/LeoDemo-fuer-AMDs-Radeon-HD-7900
Läuft die auch auf Nvidias?Jupp, aber quälend langsam und heftigen Bildfehlern [oder besser gesagt fast nur schwarz], gerade mit der GTX 480 probiert.

[Gipsel]

Laut Anforderungen Nein. Böses, böses AMD. :unono:
Jupp, aber quälend langsam und heftigen Bildfehlern [oder besser gesagt fast nur schwarz], gerade mit der GTX 480 probiert.
Was meint ihr, fixed nV den Treiber für die AMD-Demo? Offensichtlich wird ja seitens AMD nichts blockiert. :rolleyes:

[boxleitnerb]

Das waren noch Zeiten, in denen die Techdemos prima auf den Konkurrenzkarten liefen. Gabs da nichtmal ne NV-Demo, die auf ner ATI 3x schneller gelaufen ist?

[mapel110]

Was meint ihr, fixed nV den Treiber für die AMD-Demo? Offensichtlich wird ja seitens AMD nichts blockiert. :rolleyes:
Warum soll nvidia eine Software supporten, die ganz klar als Anforderung eine AMD-Karte nennt?!

Bei mir hat die Demo gerade beim Start zu einem Hardlock des Systems geführt. Nichts ging mehr. Reset-Knopf musste herhalten.
Treiber 290.53/GTX 460

[[dzp]Viper]

Hier gibts die Demo auch als Video:
http://www.hardwareclips.com/hdvideo/6523/LeoDemo-fuer-AMDs-Radeon-HD-7900

Gefällt mir super und hätte ruhig noch 5 Minuten länger sein können :D

[Gipsel]

Warum soll nvidia eine Software supporten, die ganz klar als Anforderung eine AMD-Karte nennt?!Den Smiley gesehen? :rolleyes:
Bei mir hat die Demo gerade beim Start zu einem Hardlock des Systems geführt. Nichts ging mehr. Reset-Knopf musste herhalten.
Treiber 290.53/GTX 460
Kannst ja mal y33h@ fragen, welche Treiberversion er benutzt. Bei ihm läuft es ja zumindest (wenn auch mit sehr starken Grafikfehlern). Wirklich geblockt werden die nV Karten also offensichtlich nicht. Es ist vermutlich nur ein Treiberbug, wenn die Demo nicht irgendein AMD-exklusives Feature ohne vorherige Abfrage benutzt (was schlechte Programmierung wäre).

[boxleitnerb]

Gibts noch nen alternativen Downloadlink? Hab keinen Bock mich da zu registrieren.

[mapel110]

Gibts noch nen alternativen Downloadlink? Hab keinen Bock mich da zu registrieren.
http://download2-developer.amd.com/amd/GPU/AMD-Demo-Leo-v1.0.msi

[boxleitnerb]

Danke :)

[derguru]

leider keine einstellbaren settings,muss mal wohl auf den educational mode warten.
http://www.abload.de/thumb/leo_d3d112012-01-27194wj9z.png (http://www.abload.de/image.php?img=leo_d3d112012-01-27194wj9z.png)

[boxleitnerb]

Auch hier schwarz - schade.

[y33H@]

Kannst ja mal y33h@ fragen, welche Treiberversion er benutzt. Bei ihm läuft es ja zumindest (wenn auch mit sehr starken Grafikfehlern).290.54 unter x64.

leider keine einstellbaren settings,muss mal wohl auf den educational mode warten.Die übliche "sushi.ini" nutzen :biggrin:

[Gipsel]

290.54 unter x64.
Ich habe das mal spaßenshalber mit dem alten 270.61 ausprobiert, da schmiert auch nichts ab (Win7 x64). Allerdings sehe ich auch fast nichts. Bei mir läuft es mit ~2 fps auf einer GT425. :D

Vielleicht sollten das mal ein paar mit einer 5000er oder 6000er Radeon ausprobieren, ob es wenigstens da fehlerfrei läuft.

[Skysnake]

Ich setz mich später mal ran.

Was meint ihr, sieht man hier, und mit SSAA die ersten Ergebnisse der neuen Führung?

[MR2]

Läuft ohne jeden Fehler einwandfrei auf einer HIS HD 6950 IceQ XTurboX (880Mhz) und auch schön ruckelfrei:-)