G80: Geometry-Shader-Performance

[Coda]

Ich habe gerade zu meinem erstaunen festgestellt, dass das CubeMapGS-Demo aus dem D3D10-SDK mit dem neusten Treiber jetzt sehr flüssig läuft.

Es ist zum Glück wohl also doch nicht so, dass der GS auf G80 nicht benutzbar wäre. Die Performance scheint jetzt vollkommen in Ordnung zu sein.

[Deathcrush]

Techdemo heisst ja noch lange nicht das sie im Spiel auch ihr volles Potential zeigen können. Die Demo wird schon so programmiert sein, das sie auf die Perfomance der Karte zurecht geschnitten ist.

[AnarchX]

Die Demo wird schon so programmiert sein, das sie auf die Perfomance der Karte zurecht geschnitten ist.
das CubeMapGS-Demo aus dem D3D10-SDK
... und das kommt immernoch von M$.;)

Aber AFAIR stimmte die GS-Performance schon zum 2900XT-Release.

[Gast]

Aber AFAIR stimmte die GS-Performance schon zum 2900XT-Release.

Hab ich auch so in Erinnerung.
Nur die ersten DX10 Treiber von NV (100.xx) haben da Schwächen gezeigt.

[Cpl. Dwayne Hicks]

Angeblich soll der GS auf dem R600 ja um Einiges stärker sein, gibts da auch konkrete Artikel bzw. infos zu?!
Gibts eigentlich irgendwelche benches wo der GS von G80 gegen den vom R600 getestet wird?

[Nighthawk13]

Zum Thema GS-Perfomance hat Humus mal geschrieben:

http://www.humus.ca/index.php?page=Comments&ID=187


Nah, that's because the 8800 is incredibly slow on the GS.



Greg, only Nvidia would know for sure, but from our testing it appears to be the G80 architecture. I don't think improved drivers will be able to salvage it.


Natürlich war Humus zur Postingzeit noch ATI-Mitarbeiter und damit nicht gerade neutral in der Sache;) Aber wer sich seine sonstigen Postings(auch im OpenGL Forum) liest hat nicht den Eindruck als würde er Marketing-FUD verbreiten.

Fände es schade wenn die G80 hier einen Schwachpunkt hätte, bei der hohen Verbreitung der G80 würde das Spieleentwickler vom Einsatz des Geometry Shaders evtl. abhalten.

[Gast]

Auf was ist denn die Geometry Shader Performance des R600 zurück zu führen? Reine Arithemitsche Leistung oder greift da was ineinander... dieser Hardwarebrocken der nicht genutzt werden kann mangels Softwareunterstützung?

[Spasstiger]

Fände es schade wenn die G80 hier einen Schwachpunkt hätte, bei der hohen Verbreitung der G80 würde das Spieleentwickler vom Einsatz des Geometry Shaders evtl. abhalten.
Naja, auf die Architekturschwächen der GeForce 7 wurde auch keine Rücksicht genommen. Siehe Oblivion, Gohtic 3, Anno 1701 oder auch Need for Speed Carbon.
Wenn sich Geometry Shader als praktisch und sinnvoll erweisen und wenn eine gewisse Hardwarebasis dafür da ist, werden sie schon ihren Weg in Spiele finden.

[dargo]

Ich habe gerade zu meinem erstaunen festgestellt, dass das CubeMapGS-Demo aus dem D3D10-SDK mit dem neusten Treiber jetzt sehr flüssig läuft.

Es ist zum Glück wohl also doch nicht so, dass der GS auf G80 nicht benutzbar wäre. Die Performance scheint jetzt vollkommen in Ordnung zu sein.
Dann lags nur an den Treibern? Hast du mal Bench-Vergleiche?

[AnarchX]

Hier hatte man damals die D3D10-SDK-Demos getestet:
http://www.presence-pc.com/tests/AMD-Radeon-2900-XT-22674/24/
... wo G80 als klarer Sieger bei CubemapGS hervorging.

Ein aktueller Vergleich wäre durchaus interessant.

[dargo]

Hier hatte man damals die D3D10-SDK-Demos getestet:
http://www.presence-pc.com/tests/AMD-Radeon-2900-XT-22674/24/
... wo G80 als klarer Sieger bei CubemapGS hervorging.

Ein aktueller Vergleich wäre durchaus interessant.
Huch, da siehts aber ganz schön mager für den R600 aus. Ich dachte beim GS wäre es eher andersrum. :confused:

[Nighthawk13]

Huch, da siehts aber ganz schön mager für den R600 aus. Ich dachte beim GS wäre es eher andersrum. :confused:

Nochmals Humus:
The truth is that the G80's GS performance is poor except for trivial shaders. If you do any form of geometry amplification (which is the main motivation behind the GS in the first place) the performance drops off exponentially.

Was in dem Demo auf der französischen Seite gemacht wird, ist ein dynamisches Cubemap Update, d.h. jedes Dreieck wird auf die entsprechende Cubemap-Seite(n) ausgegeben(Nur in wenigen Fällen auf mehr als eine).

Wenn die G80 eine Schwäche bei der "geometry amplification" hat, würde es in dem Test nicht auffallen...

Es gab doch mal ne Demo wo Pflanzen an nem Zaun hochwuchern, das wäre vermutlich ein guter Test.

[Raff]

Wie hoch sind die Chancen, dass beim G92 da etwas getunt wurde?

MfG,
Raff

[AnarchX]

Wie hoch sind die Chancen, dass beim G92 da etwas getunt wurde?


PCGH:
Did you improve the geometry shader amplification performance, esp. under heavy load?

Nvidia:
No, it's the same as G80.
http://extreme.pcgameshardware.de/showthread.php?t=4190
;)

Aber wenn ihr Zeit habt könntet ihr ja mal R600, RV670, G80, G92 nochmal durch die Demos jagen, die hier ihre Last haben.

[Raff]

Oh, das ist jetzt irgendwie (fast) peinlich. ;D Danke.

MfG,
Raff

[reunion]

ATi hat übrigens bei RV670 die GS-Leistung laut eigenen Angaben steigern können:

Darüber hinaus hat ATi auf dem RV670 nach eigenen Angaben die Performance bei Geometry-Shader-Berechnungen steigern können, was in Direct3D-10-Anwendungen (falls diese Gebrauch vom Geometry-Shader machen) einen Geschwindigkeitsschub bringen soll.

http://www.computerbase.de/artikel/hardware/grafikkarten/2007/test_ati_radeon_hd_3870_rv670/3/#abschnitt_technik_im_detail_part_1

[Gast]

Welche Recheneinheiten sind eigentlich für den GS zuständig? Ich dachte das wäre alles unified?

[Gast]

Welche Recheneinheiten sind eigentlich für den GS zuständig? Ich dachte das wäre alles unified?


ist auch so, die frage ist nur wie effizient diese einheiten bei der ausführung von GS sind.♠♠

[Coda]

Auch das Motion-Blur-Demo das einen Geometry-Shader benützt um diesen zu erzeugen ist wesentlich schneller geworden. Das war am Anfang auch ein Kandidat für SPF statt FPS.

Aber AFAIR stimmte die GS-Performance schon zum 2900XT-Release.
Nein sicher nicht. Gerade das CubeMapGS-Demo mit angezeigtem Auto war und das MotionBlur-Demo waren noch unglaublich lahm.

Ich bezweifle übrigens nicht, dass die R6xx-Architektur dort weiterhin einen Vorteil hat, aber zum Glück kann man das Ding auch auf G8x verwenden, wenn man nicht so riesige Amplification hat. Da gäbe es nämlich so einiges was mir in den Sinn kommen würde.

[Nighthawk13]

Welche Recheneinheiten sind eigentlich für den GS zuständig? Ich dachte das wäre alles unified?
Wenn ich das alles richtige verstehe, ist die Ausführung des Geometry Shader nicht das Problem, vielmehr die Weiterverarbeitung der erzeugten Dreicke.

Angenommen dein GS führt hochkomplexe Berechnung durch und spuckt nachher nur ein Dreick aus, ist die G80 nicht langsamer als die R600.

Wenn du stattdessen aus einem Punkt 100te Dreiecke erzeugst(um z.B. eine Kugel um den Punkt darzustellen), kommt die Pipeline der G80 ins Stocken. Was da genau bremst k.A.

[dargo]

Wenn ich das alles richtige verstehe, ist die Ausführung des Geometry Shader nicht das Problem, vielmehr die Weiterverarbeitung der erzeugten Dreicke.

Angenommen dein GS führt hochkomplexe Berechnung durch und spuckt nachher nur ein Dreick aus, ist die G80 nicht langsamer als die R600.

Wenn du stattdessen aus einem Punkt 100te Dreiecke erzeugst(um z.B. eine Kugel um den Punkt darzustellen), kommt die Pipeline der G80 ins Stocken. Was da genau bremst k.A.
Aber genau die zweite Variante macht am meisten Sinn. Nämlich, mit möglichst wenig Rechenaufwand viel zu erzeugen. Oder sehe ich das falsch? Sorry, kenne mich auf diesem Gebiet nicht so aus.

[Nighthawk13]

Aber genau die zweite Variante macht am meisten Sinn. Nämlich, mit möglichst wenig Rechenaufwand viel zu erzeugen. Oder sehe ich das falsch? Sorry, kenne mich auf diesem Gebiet nicht so aus.

Stimmt schon. Die Idee ist das man wenig Dreiecke zur Grafikkarte schickt, die dann im Geometry Shader verfeinert werden, evtl in Abhängigkeit zum Betrachterabstand(für Level-of-Detail) und mit Hilfe von Texturen(Displacement Mapping). Deshalb meint Humus ja auch:

If you do any form of geometry amplification (which is the main motivation behind the GS in the first place)...

Wobei es schon auch wichtige Anwendungen für den GS gibt, wo nicht so viele Dreicke erzeugt werden:
- dynamische Cubemaps
- Isoflächen zur Volumendarstellung
- Shadowvolumes(?)

[Coda]

Aber genau die zweite Variante macht am meisten Sinn. Nämlich, mit möglichst wenig Rechenaufwand viel zu erzeugen. Oder sehe ich das falsch? Sorry, kenne mich auf diesem Gebiet nicht so aus.
Es ist relativ sinnlos z.B. 100 gleiche Dreiecke auszugeben, deshalb ist der Rechenaufwand auch bei vielen Dreiecken natürlich meistens linear zu deren Anzahl.

Und für extreme Geometry Amplification ist der GS gar nicht ausgelegt. Viel zu limitiert dafür.

[Godmode]

Welche Recheneinheiten sind eigentlich für den GS zuständig? Ich dachte das wäre alles unified?

Die ALUs des G80 werden dazu verwendet.

Die Koordinaten für die neuen Dreiecke müssen irgendwo hin geschrieben werden. Direkte Zugriffe auf den Grafikkartenspeicher, sind extrem langsam, im Vergleich zum sehr schnellen Shared memory auf dem Chip. Jeder Cluster (8 ALUs) besitzt einen Shared memory von 16kb und 8192 32 bit Register. IMO werden die neuen Eckpunkte in den Shared Memory geschrieben.

Solange der Sharded memory nicht überläuft oder Bankconflicts auftreten, hast du keine Probleme, da die Zugriffszeit darauf sehr kurz ist (4 Clocks). Sobald aber wärend einer Berechnung auf den DRAM zugegriffen wird, hast du hohe Wartezeiten. Der Threadsheduler versucht diese Wartezeiten zu verstecken, was aber nicht immer möglich ist, vor allem dann, wenn zu wenig Arithmetik-Arbeit zur Verfügung steht.

Wenn der GS viele Eckpunkte erzeugt (16kb / 16 = 1024 Eckpunkte), könnte der Fall eintreten, dass der Shared memory voll wird und eben ein DRAM Zugriff notwendig wird. Früher oder später müssen die Daten jedenfalls in einen Vertexbuffer oder ähnliches in den DRAM der Grafikkarte geschrieben werden.

[Nighthawk13]

Nochmal ein Benchmark zum GS:
http://www.digit-life.com/articles2/video/g92-part2-page6.html

Die obere Teil("Galaxy") ist eher uninteressant, es werden nur massig Pointsprites gerendert(dieser Fall ist im GS imho besonders optimiert). Hier sind beide Architekturen ungefähr gleich schnell.

Beim "Hyperlight" sieht man deutliche Unterschiede zwischen Architekturen.

Hyperlight is the second geometry test that uses several techniques: instancing, stream output, buffer load. It employs dynamic generation of geometry by rendering into two buffers, as well as a new Direct3D 10 feature - stream output. The first shader generates ray directions, their speed and growth vectors. These data are stored in a buffer, which is used by the second shader for rendering. Each ray point is used to generate 14 vertices in a circle, up to a million output points.

The new type of shader programs is used to generate rays. If "GS load" is set to "Heavy", it's also used for rendering. That is in Balanced mode, geometry shaders are used only to generate and grow rays. Output is up to instancing. The geometry shader also outputs data in the Heavy mode.

- Nur mit GS ist die 2900xt ~doppelt so schnell wie die 8800gts
- Mit GS+Instancing ist die 8800gts ~doppelt so schnell wie die 2900xt (und ca. 20% schneller als die 2900xt mit GS only)

Welche Implementierung würde man wohl als Spieleprogrammierer wählen? ;)

[Gast]

Hier sind beide Architekturen ungefähr gleich schnell.


von der rohleistung her müsste der R600 allerdings in einem GS-bench eher auf 8800GTX-niveau sein, von daher kann man nicht sagen dass beide architetkuren gleich schnell sind.

die hyperlight-tests sind allerdings sehr interessant, mal die eine, mal die andere architektur extrem weit vorne ;)