Floating-Point-Einheiten der GPUs

[decimad]

Hallo,
hat jemand von euch eine Ahnung, wieviel Prozent der Die-Fläche einer "Compute"-Einheit für die optimierten Floating-Point-Berchnungen draufgehen?
Ich hätte gerne mal eine Vorstellung davon, wieviele Einheiten auf's Die draufpassen würden, wenn einfach alles in Fixed-Point durchgeführt würde... Ist natürlich klar, dass das schwer umzusetzen ist, aber wo man für die Geometrie ja sowieso schon LOD einsetzt, entspricht ja so ein LOD-Stufen-Wechsel eigentlich einem Basiswechsel bei der Fixed-Point-Berechnung, also ich stelle mir das eigentlich schon machbar vor, mit entsprechender Planung.

Viele Grüße

[Gipsel]

Hallo,
hat jemand von euch eine Ahnung, wieviel Prozent der Die-Fläche einer "Compute"-Einheit für die optimierten Floating-Point-Berchnungen draufgehen?
Ich hätte gerne mal eine Vorstellung davon, wieviele Einheiten auf's Die draufpassen würden, wenn einfach alles in Fixed-Point durchgeführt würde... Ist natürlich klar, dass das schwer umzusetzen ist, aber wo man für die Geometrie ja sowieso schon LOD einsetzt, entspricht ja so ein LOD-Stufen-Wechsel eigentlich einem Basiswechsel bei der Fixed-Point-Berechnung, also ich stelle mir das eigentlich schon machbar vor, mit entsprechender Planung.

Viele Grüße
Fixed/floating Point? Geht mir ein wenig durcheinander. Und nur mit fixed point müßte man die meisten Shader-Algorithmen deutlich umstellen, die verlassen sich auf floating point. Praktisch alles wird in den Shader-ALUs standardmäßig in fp32 gerechnet.

Aber egal, die eigentlichen Vektor-ALUs bei Tahiti nehmen etwa 21% der Die-Fläche ein (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=9197796#post9197796), wobei da die Vektor-Register schon mit dabei sind (beanspruchen ungefähr ein knappes Drittel der ALU-Fläche, irgendwoher müssen die Werte ja kommen, mit denen die ALUs rechnen) und die ALUs natürlich mehr als die reinen Recheneinheiten sind. Und natürlich kann man nicht das ganze Die nur mit ALUs vollpacken, das ergäbe keine funktionsfähige GPU.

[decimad]

Ja klar, es bedeutet natürlich Aufwand und viel Planung, Fixed-Point-Berechnungen umzusetzen, ist ja auch in der Mikrocontrollerprogrammierung immer ein Betätigungsfeld (wobei die größeren jetzt auch immer öfter eine FPU haben).
Aber dass nur 21% der Fläche auf die ALUs entfällt, überrascht mich jetzt doch ziemlich. Ich dachte, die würden den Mordsanteil der Fläche einnehmen. Laut der Tabelle geht aber die Hälfte der Fläche erstmal für I/O drauf und die Hälfte des Rests für Fixed-Function-Texturkram. Danke dafür, da macht es ja kaum Sinn, bei dem Shaderkram zu geizen. Ich bin halt aus historischen Gründen irgendwie davon ausgegangen, dass FPU-Einheiten echte Mordsteile sind, die man sich am liebsten sparen würde (und das eigentlich auch immer kann).

[Gipsel]

Ja klar, es bedeutet natürlich Aufwand und viel Planung, Fixed-Point-Berechnungen umzusetzen, ist ja auch in der Mikrocontrollerprogrammierung immer ein Betätigungsfeld (wobei die größeren jetzt auch immer öfter eine FPU haben).
Aber dass nur 21% der Fläche auf die ALUs entfällt, überrascht mich jetzt doch ziemlich. Ich dachte, die würden den Mordsanteil der Fläche einnehmen. Laut der Tabelle geht aber die Hälfte der Fläche erstmal für I/O drauf und die Hälfte des Rests für Fixed-Function-Texturkram. Danke dafür, da macht es ja kaum Sinn, bei dem Shaderkram zu geizen. Ich bin halt aus historischen Gründen irgendwie davon ausgegangen, dass FPU-Einheiten echte Mordsteile sind, die man sich am liebsten sparen würde (und das eigentlich auch immer kann).Nee, die Entwicklung ging und geht (z.B. bei TMUs) ja in die andere Richtung. Kein Mensch will sich heutzutage noch zu viel Gedanken über die Implementierung irgendeines Shaderalgorithmus auf FixedPoint-Einheiten machen, die früher (kombiniert mit limitierter Programmierbarkeit) in den GPUs verbaut waren. Aber seit DirectX7 mit Transform+Lighting gab es zumindest in den VertexShader-ALUs fp32 (weil man sonst nur schlecht mit 3D-Koordinaten klarkommt, zumindest im allgemeinen Fall), auch wenn die Pixelshader limitierter waren (fixed point, dann fp16 oder fp24). Aber die möglichen Effizienzgewinne und die weit flexibleren Einsatzmöglichkeiten für moderne Aufgabenstellungen favorisieren eigentlich unified Shader-Architekturen, in denen es dann sogar erforderlich ist, daß alle ALUs fp32 können (die Tegras im Mobilbereich waren wohl so ziemlich die letzten split-Shader Architekturen, in denen die Pixelshader nur fp24 konnten, die anderen Anbieter von Handheld Grafiklösungen waren schon unified mit fp32 Support überall).

Kurz, ohne fp32-Support ist man doch deutlich limitiert. Sicher spart man Transistoren und Platz für einige Aufgabenstellungen, die mit weniger auskommen würden. Aber wenn nicht, hat man ein Problem und verliert massiv Performance, wenn man das mit fixed point emulieren will. Und im Sinne der Standardisierung spricht heutzutage eigentlich kaum noch etwas gegen fp32 als Grundlage. Und wie Du schon sagst, soo groß sind fp32-ALUs nun auch nicht.

[Spasstiger]

Bevor man drüber nachdenkt, fx32 als Datenformat zum Einsparen von Resourcen einzusetzen, würde ich noch eher auf fp16 zurückgehen. Hat den gleichen Dynamikumfang und spart zudem Speicher, Registergröße und Datenleitungen. Die Mantissengenauigkeit ist zumindest für Pixelshaderberechnungen in der Regel auch ausreichend.