Hat nv die Schwierigkeiten der Compiler-Programmierung unterschätzt?

[DrumDub]

hab das grad bei b3d gefunden, udn wollte es hier zur diskussion stellen. ich finde die these recht interessant:

DemoCoder

Posted: Fri Oct 24, 2003 5:50 am Post subject: Re: 5700, 5600, 9600 'Pure' DX9 Performances

--------------------------------------------------------------------------------

DaveBaumann wrote:
Despite the improved PS2.0 performance they are still quite significantly behind ATI's "Pure" DX9 performance, and in the shadermark tests the new MS 2_a compiler for the FX series isn't making much of a difference - this likely suggests that the compiler optimiser that is now in the 52.16 drivers is already getting close to the performance of the HLSL compiled code in the first place, not not their optimal performance for Sahder Assembly reordering. Despite the 5700 being a new chip, entirely designed an built after DX9 was finalised they haven't altered the FX architecture at all do improve some of the missing areas - still no float buffer support and still no MRT's etc.
--------------------------------------------------------------------------------



I don't think you can draw that conclusion from the data. I've been consistently arguing in these forums over the past year for improved compiler technology, and the fact that the instruction scheduling issues are non-trivial. It seems a majority of people subscribed to the view just months ago that there are no improvements left to NV3x drivers to increase PS2.0 speed that don't involve hacks to IQ.

The more likely story all along is that NVidia underestimated the difficulties their architecture would pose for their driver team, and they didn't really have enough inhouse compiler technology talent (which is why they've been hiring lots of compiler positions this past year) That's why it too so long to get a driver with a good optimizer that doesn't generate buggy code.

This was clear if you looked at the output of the Cg compiler, that Nvidia's first compiler efforts were straightforward "get something working" efforts. It more than likely would take them about half a year to get the first optimizing compiler done.

Therefore, I feel it is premature to conclude on this first major in-compiler optimization effort that there is no room left for improvement. We don't really know. Perhaps these drivers just represent the implementation of a better register allocator and instruction scheduler. But both those algorithms are NP-complete, and there is a lot of room for tweaking, but more than that, there are lots of other optimizations that perhaps are not doing yet.

And of course, per my arguments in other threads, there are probably optimizations that cannot do at all, because they have to deal with the output of MS's compiler instead of doing the compilation themselves from the source.

I don't think this is the end of the story, I think it is merely the beginning. As GPUs/VPUs become even more complex (vs3.0/ps3.0 and beyond), issues related to compiler optimization will move to the forefront.

I predict on NV40/R420 release, these cards will run at only a fraction of their true potential due to early drivers being developed for correctness. Neither ATI nor NVidia is going to hold back the release of their new cards to wait for new drivers for new architectures to mature fully.

That said, I still doubt that the NV3x can keep up with the R3x0 in any PS2.0 capacity, but that isn't to say there isn't more room for improvement. At a time where most people thought the NV3x was "maxed out", we see that new compiler technology develiver quite nice performance increases this late in the game. It is only natural to speculate "ok, they pulled it off this time, but obviously there can't be anymore, besides, I don't trust NV and they might use IQ hacks to go further" But, let's wait and see. It takes a while to go from scratch, having no compiler, to have a a mature one. Ditto for initial driver releases.
http://www.beyond3d.com/forum/viewtopic.php?t=8623

[Quasar]

Hm, ja.

Shadermark. IMHO integrieren die 52.16er Detos den 2.a-Pfad treiberseitig, da ist dann natürlich nicht mehr viel zu holen.

Mit dem 45.23er konnten die FXen noch ein wenig hinzugewinnen, mit dem 52.16er ist die Grundperformance schon stark gestiegen.

[Demirug]

Auf die Treadfrage bezogen. Ja und Nein. Sie haben nicht unbedingt die Schwierigkeit unterschätzt. Das Cg Team wurde ja von jemadem geleitet der schon mal an einen Hochsprachencompiler für Shader mitgearbeitet hat. Das Problem war der Zeitfaktor. nVidia hat sich schlicht und ergreifend dabei verschätzt wie schnell PS 2.0 in den produktiven Einsatz gehen. Man wollte wieder mal die übliche "First safe than fast" Tour fahren. Das ging aber tierisch in die Hose.

EDIT: PS: Das hier ist noch ganz interesant in diesem Zusammenhang: http://www.nvidia.com/object/IO_9292.html

[Demirug]

Original geschrieben von Quasar
Hm, ja.

Shadermark. IMHO integrieren die 52.16er Detos den 2.a-Pfad treiberseitig, da ist dann natürlich nicht mehr viel zu holen.

Mit dem 45.23er konnten die FXen noch ein wenig hinzugewinnen, mit dem 52.16er ist die Grundperformance schon stark gestiegen.

Ja, die meisten Optimierungen die der 2.A an den Shadermark shadern vornimmt können die 5X.XX Treiber inzwischen auch selber. Die richtig hübschen 2.A Sachen nutzt der Shadermark ja nicht.

[DrumDub]

Original geschrieben von Demirug
Auf die Treadfrage bezogen. Ja und Nein. Sie haben nicht unbedingt die Schwierigkeit unterschätzt. Das Cg Team wurde ja von jemadem geleitet der schon mal an einen Hochsprachencompiler für Shader mitgearbeitet hat. Das Problem war der Zeitfaktor. nVidia hat sich schlicht und ergreifend dabei verschätzt wie schnell PS 2.0 in den produktiven Einsatz gehen. Man wollte wieder mal die übliche "First safe than fast" Tour fahren. Das ging aber tierisch in die Hose.

jo. so in etwa meinte ich es.

die architektur des nv3x ist einfach zu komplex, so dass es zum launch mit den vorhandenen resourcen nicht möglich war einen compiler in den treiber zu integrieren, der die hardware ausreizt. dies hat nvidia nun nachgeholt. bleibt die frage, inwieweit wir jetzt mit deto 52.16 von der maximalen ps-leistung der nv3x entfernt sind (vs scheint ja nicht das problem zu sein).

EDIT: PS: Das hier ist noch ganz interesant in diesem Zusammenhang: http://www.nvidia.com/object/IO_9292.html

jo. das wurde ja schon woanders hier auszugsweise gepostet, wobei ich als laie mit den code-beispielen absolut nix anfangen kann. ;)
die grafik am anfang des pdfs macht aber auch für jemanden wie mich sinn:

[ow]

.

[KM]

Original geschrieben von DrumDub
jo. so in etwa meinte ich es.

die architektur des nv3x ist einfach zu komplex, so dass es zum launch mit den vorhandenen resourcen nicht möglich war einen compiler in den treiber zu integrieren, der die hardware ausreizt. dies hat nvidia nun nachgeholt. bleibt die frage, inwieweit wir jetzt mit deto 52.16 von der maximalen ps-leistung der nv3x entfernt sind (vs scheint ja nicht das problem zu sein).

jo. das wurde ja schon woanders hier auszugsweise gepostet, wobei ich als laie mit den code-beispielen absolut nix anfangen kann. ;)
die grafik am anfang des pdfs macht aber auch für jemanden wie mich sinn:
Die Abbildung von DX nach NV erinnert mich irgendwie an Visual Basic. :)

[Ailuros]

Man wollte wieder mal die übliche "First safe than fast" Tour fahren. Das ging aber tierisch in die Hose.

Ich wuerde eher sagen dass sie unter Zeitdruck lagen, was mir persoenlich aber auch nicht viel Sinn macht, wenn ich bedenke dass man Treiber schon mit Simulatoren optimieren kann (oder nicht?).

I don't think this is the end of the story, I think it is merely the beginning. As GPUs/VPUs become even more complex (vs3.0/ps3.0 and beyond), issues related to compiler optimization will move to the forefront.

I predict on NV40/R420 release, these cards will run at only a fraction of their true potential due to early drivers being developed for correctness. Neither ATI nor NVidia is going to hold back the release of their new cards to wait for new drivers for new architectures to mature fully.

Also wenn ich von den Shadern 2.0 ausgehe, dann wuerde ich mit meinem einfachen Verstehen sagen dass mehr oder weniger hier das gleiche gilt. Da muesste die Auslage der HW auch eine grosse Rolle spielen, ausser dass die 3.0 Shader so verkorkst sind dass kein IHV ein gutes Medium finden kann, was ich aber bezweifle.

[Demirug]

Original geschrieben von Ailuros
Ich wuerde eher sagen dass sie unter Zeitdruck lagen, was mir persoenlich aber auch nicht viel Sinn macht, wenn ich bedenke dass man Treiber schon mit Simulatoren optimieren kann (oder nicht?).

Für diese Optimierungen braucht man eigentlich noch nicht mal einen Simulator. Wenn man die Struktur genau kennt kann man ja genau ausrechnen wie schnell ein Shader laufen wird. Wie gesagt habe ich hier die Aussage vom Devsupport (ich weiss das man sowas nicht auf die Goldwage legt) das man sich erst einmal darum gekümmert hat das es überhaupt läuft. Zudem würde das Dokument zu dem "unified Compiler" die Sache sehr vereinfacht darstellen. Soll heisen das beim optimieren nicht nur der eigentliche Shader sondern sein gesamtes Umfeld einbezogen werden muss.

Also wenn ich von den Shadern 2.0 ausgehe, dann wuerde ich mit meinem einfachen Verstehen sagen dass mehr oder weniger hier das gleiche gilt. Da muesste die Auslage der HW auch eine grosse Rolle spielen, ausser dass die 3.0 Shader so verkorkst sind dass kein IHV ein gutes Medium finden kann, was ich aber bezweifle.

3.0 ist eben noch eine Spur komplexer und verlangt wesentlich mehr von der Hardware.

[Ailuros]

3.0 ist eben noch eine Spur komplexer und verlangt wesentlich mehr von der Hardware.

Hab ich auch nicht bezweifelt. Ich dachte nur dass je mehr programmierbarer eine Architektur ist, desto einfacher muesste es sein solche Probleme zu umgehen oder nicht?

[Demirug]

Original geschrieben von Ailuros
Hab ich auch nicht bezweifelt. Ich dachte nur dass je mehr programmierbarer eine Architektur ist, desto einfacher muesste es sein solche Probleme zu umgehen oder nicht?

Die Programierbarkeit ist kein Faktor an dem man die Komplexität eines Compilers messen kann. Die gewählte Architektur hat hier einen viel grösseren Einfluss. Gerade aufgrund des dynamischen Branchings können und werden da wieder ganz neue Probleme auftauchen.

[DrumDub]

Original geschrieben von ow
Also Demirug sprach imo von was ganz anderem als du. Nicht von zu komplexer Architektur sondern von einer falschen Annahme, wie schnell die PS2.x zum Einsatz kämen.

zu komplex kann eine architektur von der hardwareseite ja gar nicht sein (nur zu komplex um sie mit den vorhandenen produktionsprozessen umzusetzen).
ich meinte damit schon dasselbe, nämlich dass man zum launch nicht einen treiber liefern konnte, der optimal mit der hardware harmoniert, was eben darauf zurückzuführen ist, dass man bei nv glaubte, das dies zum launch nicht nötig sei, wegen den nicht vorhandenen spielen mit ps 2.x support. insofern war die problematik zum launch bei nv ja noch gar nicht bekannt, sondern konnte erst mit der entwicklung und dem erscheinen solcher spiele akut werden.

[Razor]

Original geschrieben von DrumDub
zu komplex kann eine architektur von der hardwareseite ja gar nicht sein (nur zu komplex um sie mit den vorhandenen produktionsprozessen umzusetzen).
Die Architektur eines Chips ist eng mit dem Fertigungsprozeß verknüpft. Es ist eben nicht so ohne weiteres möglich, eine auf die Besonderheiten der 0.15 Fertigung ausgelegte Chiparchitektur auf einen anderen Prozeß umzumünzen.

Oder was meinst Du, warum sich nVidia damit so schwer getan hat, die 0.13 Fertigung zum Laufen zu bekommen und ATI in diesem Segment noch immer keine komplexen Architekturem auf Basis der 0.13 Fertigung anzubieten hat ?
Original geschrieben von DrumDub
ich meinte damit schon dasselbe, nämlich dass man zum launch nicht einen treiber liefern konnte, der optimal mit der hardware harmoniert, was eben darauf zurückzuführen ist, dass man bei nv glaubte, das dies zum launch nicht nötig sei, wegen den nicht vorhandenen spielen mit ps 2.x support. insofern war die problematik zum launch bei nv ja noch gar nicht bekannt, sondern konnte erst mit der entwicklung und dem erscheinen solcher spiele akut werden. Die Treiber werden schon optimal mit der Hardware harmonieren, nur ist die Shader-Sache eine ganz andere Problematik. Gerade mit den 2.x-Shadern und noch sehr viel mehr mit den 3.x-Shadern wurde das Ganze wieder stark Architektur-Abhängig. Als dann noch erschwerend hinzu kam, dass die ersten Shader-Proggis (sehr viel früher als erwartet) auch noch ATI-optimierte Compilate mitbrachten, war der Ofen für nVidia erst mal aus.

Auch scheint die Architektur der NV3x-Serie nicht wirklich einfach zu handhaben sein, wie Demirug ja nun sehr versiert und mit viel Hintergrund dargelegt hat. Das bedeutet also, dass selbst wenn 'perfekte' Compilate an den Treiber gereicht werden, diese noch immer auf die unterschiedlichen Sub-Architekturen 'gemappt' werden müssen und wohl auch in ihren Wechselwirkkungen zu den anderen Anforderungen - also schon fast ganzheitlich - betrachtet und behandelt werden müssen.

Wenn Du aber sagst, dass die ersten Treiber nicht perfekt mit DX9 hamonierten, dann gebe ich Dir mal zu 100% recht...
;)

Razor

[Razor]

Original geschrieben von Demirug
Wie gesagt habe ich hier die Aussage vom Devsupport (ich weiss das man sowas nicht auf die Goldwage legt) das man sich erst einmal darum gekümmert hat das es überhaupt läuft.
Und hier dürfte ein wahrer Kern zu finden sein...

nVidia ist schon immer (!) so vorgegangen. Erst einmal muss es laufen, später begibt man sich an's optimieren. Bei allen vorherigen Architekturen war das offenbar einfacher (man erinnere sich an das Thema gf3 zu gf2u, bei dem der 'Vorteil' der neuen Architektur zuerst auch nicht ersichtlich war), aber mit der immer größeren Nähe zur Arbeitsweise einer CPU scheit auch der Aufwand für Optimierungen prozedural zu steigen.

Laufen tut mit den 52.16 ja alles wunderprächtig (selbst DX9-Proggi's wie Halo, welches ja von nVidia 'Entwicklungshilfe' bekommen hat ;-). Insofern 'darf' sich nVidia nun ausschließlich mit den Shader-Optimierungen befassen. Und wenn ich das richtig sehe und sich die NV4x-Architektur nicht massiv von der des NV3x unterschieden wird, dann kommt der jetzige Aufwand durchaus auch der zukünftigen Architektur zugute.

Mal schaun', was da so demnächst noch kommt.

Razor

[Mad-Marty]

Original geschrieben von Razor
Und hier dürfte ein wahrer Kern zu finden sein...

nVidia ist schon immer (!) so vorgegangen. Erst einmal muss es laufen, später begibt man sich an's optimieren. Bei allen vorherigen Architekturen war das offenbar einfacher (man erinnere sich an das Thema gf3 zu gf2u, bei dem der 'Vorteil' der neuen Architektur zuerst auch nicht ersichtlich war), aber mit der immer größeren Nähe zur Arbeitsweise einer CPU scheit auch der Aufwand für Optimierungen prozedural zu steigen.

Laufen tut mit den 52.16 ja alles wunderprächtig (selbst DX9-Proggi's wie Halo, welches ja von nVidia 'Entwicklungshilfe' bekommen hat ;-). Insofern 'darf' sich nVidia nun ausschließlich mit den Shader-Optimierungen befassen. Und wenn ich das richtig sehe und sich die NV4x-Architektur nicht massiv von der des NV3x unterschieden wird, dann kommt der jetzige Aufwand durchaus auch der zukünftigen Architektur zugute.

Mal schaun', was da so demnächst noch kommt.

Razor


Eigentlich kann man nur hoffen das die vermurkste nv3x architektur komplett weggeschmissen wird und ein ordentlich effizienter nv4x kommt.

Und ich glaube das wissen die selber und werden vermutlich das auch tun, nichtmal nv ist so dumm und schlägt sich mit einer schlechten architektur länger herum als unbedingt nötig.

[Demirug]

Original geschrieben von Mad-Marty
Eigentlich kann man nur hoffen das die vermurkste nv3x architektur komplett weggeschmissen wird und ein ordentlich effizienter nv4x kommt.

Und ich glaube das wissen die selber und werden vermutlich das auch tun, nichtmal nv ist so dumm und schlägt sich mit einer schlechten architektur länger herum als unbedingt nötig.

Die Architektur ist nicht wirklich total vermurkst. Sie harmoniert nur nicht sonderlich gut mit DirectX.

Du kannst sicher sein das die Grundkomponeten der NV3X Arichitektur auch im NV4X wieder zu finden sein werden. Man wird sie allerdings etwas anders anordnen. Wenn man den Gerüchten glauben darf wird man mehr in die breite bauen und weniger in die Tiefe.

[Razor]

Original geschrieben von Mad-Marty
Eigentlich kann man nur hoffen das die vermurkste nv3x architektur komplett weggeschmissen wird und ein ordentlich effizienter nv4x kommt.
Die letzten Posts hier hast Du aber schon gelesen, oder ?

Diese 'vermurkste' Architektur krankt momentan daran, zu komplex und nicht korrekt von Anfang unterstützt worden zu sein (erste Implemtierungen rein auf ATI optimiert !).
Original geschrieben von Mad-Marty
Und ich glaube das wissen die selber und werden vermutlich das auch tun, nichtmal nv ist so dumm und schlägt sich mit einer schlechten architektur länger herum als unbedingt nötig. Ganz sicher werden sie die Architektur nicht 'wegschmeißen'. Was ja auch völliger Humbug wäre...

Sie sorgen jetzt einfach dafür, dass die Architektur bei zukünftigen und derzeitigen Entwicklungen berücksichtigt wird. Der Anfang mit dem angepaßten, offiziellen DX9-SDK-Compiler ist getan (alternative Compiler-Targets nun möglich) und wenn so die 'Editor's Days' richtig wahrgenommen hat, dann reagieren nun auch die Spiele-Hersteller (von einigen Marketing-Aktionen mal abgesehen ;-).

Im Prinzip läuft doch (zumindest jetzt) alles wunderprächtig für nV.
Jetzt müssen sie sich noch ein wenig um die Shader-Performance kümmern und schon sieht die Welt wieder gaaaanz anders aus.

Und im Q1/2 wird's ja den neuen Chip geben, der vermutlich auf CineFXII aufbauen, aber sich noch einige Überraschungen bereit haben wird. Die Unterstützung von VS/PS 3.0 scheint als gesichert...

Schaun' wir mal, ob ATI da mitkommen wird !
:D

Razor

[ow]

.

[sth]

Alle reden von Anpassungen von wegen DirectX 9, einem ominösen DX 9.1 mit Optimierungen etc.

Was mich aber interessiert ist die OpenGL-Performance, genauer gesagt die von GL_ARB_FRAGMENT_PROGRAM, der ersten herstellerunabhängigen OpenGL-Extension für PixelShader (Fragment-Shader unter OGL).

Leider kann ich mich mangels PS/VS 2.0-fähiger Graka momentan noch nicht damit mit beschäftigen :(

Klar hat ATI den besseren Chip momentan, nur frage ich mich halt, in wie weit die Performance hier real differiert (gemessen an den aktuellen 52.16er-Treibern unter Windows, da unter Linux momentan noch Stand 44.96 ist).

[tb]

Original geschrieben von sth
Alle reden von Anpassungen von wegen DirectX 9, einem ominösen DX 9.1 mit Optimierungen etc.

Was mich aber interessiert ist die OpenGL-Performance, genauer gesagt die von GL_ARB_FRAGMENT_PROGRAM, der ersten herstellerunabhängigen OpenGL-Extension für PixelShader (Fragment-Shader unter OGL).

Leider kann ich mich mangels PS/VS 2.0-fähiger Graka momentan noch nicht damit mit beschäftigen :(

Klar hat ATI den besseren Chip momentan, nur frage ich mich halt, in wie weit die Performance hier real differiert (gemessen an den aktuellen 52.16er-Treibern unter Windows, da unter Linux momentan noch Stand 44.96 ist).

Dies könnte man sicher recht einfache mittels Humus OpenGL Demos testen, leider hab ich keine NV3x Karte mehr :(

http://esprit.campus.luth.se/~humus/3D/index.php?
page=OpenGL

Thomas

[Crushinator]

^^

Humus OpenGL Demos (http://esprit.campus.luth.se/~humus/3D/index.php?page=OpenGL)

[Razor]

Original geschrieben von sth
Was mich aber interessiert ist die OpenGL-Performance, genauer gesagt die von GL_ARB_FRAGMENT_PROGRAM, der ersten herstellerunabhängigen OpenGL-Extension für PixelShader (Fragment-Shader unter OGL).Sind das nicht Extensions für OGL 2.0 ?
:???:

Razor

[Razor]

Ups... sorry.
GL_ARB_FRAGMENT_PROGRAMM funktioniert natürlich...
(hab' mir mal das 'Chess' gezogen ;-)

Habe das mit GL_ARB_FRAGMENT_SHADER verwechselt.

Razor

[ow]

.

[loloi]

Original geschrieben von ow
unsere 3D-Gurus fragen.:D

und das bin ich :D
zum thema: 3dfx mitarbeiter haben es den nvidianern heimgezahlt, was anderes kann ich mir nicht vorstellen harhar :deal:

[Demirug]

ARB_Vertex_Shader: Ist für die Shaderhochsprache (OpenGL 2.0)

ARB_Vertex_Program: Ist für die Assemblerähnliche Sprache.

[ow]

.

[Demirug]

Original geschrieben von ow
Daraus folgere ich mal, dass OGL2.0 Shader nicht mehr nach Assembler übersetzt werden, ist das richtig?

Ja, der Treiber bekommt direkt glslang Code.