NV40-Technik im Detail

[MikBach]

Man muss ja leider heute fragen: welche Fillrate?
Bestimmt nicht vom Speicher. ;D


Und wenn SM3 erst in drei Jahren auf den Markt käme, wäre die Situation dann anders?
Ähm, verstehe ich jetzt nicht. Was hat das mit NV40/SM3 zu tun?


Trotzdem gibt es noch genügend Situationen, in denen SM3.0 sich lohnt.

Diese wären?

Welche wären das? Ich habe beim Überblicken der OpenGL-Extensions bis auf Depth Bounds nichts signifikantes gefunden, also müssten das dann ja undokumentierte Features sein.

Korrekt.

[tokugawa]

Diese wären?


Algorithmen, wo die zusätzliche Macht von SM 3.0 benötigt wird. Raycasting im Shader etwa.

[MikBach]

Do you mean Vertex texture fetch,that is often called Virtual Displacement maping.But real DM needs a teselation unit.
You are right. But, there is more than a teselation unit.

[Xmas]

Do you mean Vertex texture fetch,that is often called Virtual Displacement maping.But real DM needs a teselation unit.
Nein, Virtual Displacement Mapping wird auch Parallax Mapping genannt, und hat mit Vertex Texturing gar nichts zu tun, sondern findet nur im PS statt. (Zumal beides in DX möglich ist)

Dass DM eine Tessellation-Einheit braucht, da stimme ich aber weitgehend zu.

[MikBach]

@ tokugawa

Deine Beispiele sind einleuchtend.
Allerdings geht es mir mehr um Spiele. Die Forschung-Fuzzies machen doch nur einen kleinen Teil der Käufer solcher Grakas aus. Das ist der Punkt.

[tokugawa]

Nein, Virtual Displacement Mapping wird auch Parallax Mapping genannt, und hat mit Vertex Texturing gar nichts zu tun, sondern findet nur im PS statt. (Zumal beides in DX möglich ist)

Dass DM eine Tessellation-Einheit braucht, da stimme ich aber weitgehend zu.

Zumindest dynamisches Displacement Mapping (bzw Displacement Mapping mit dynamischer Tesselation).

Ein static Tesselation Displacement Mapping wäre imo auch Displacement Mapping, wo man halt in einem fixen Grid mittels Heightmap (per Vertex) displacet statt über dynamisch tesselierte Geometrie.

Nur um mal die Begriffe exakt zu definieren :)

[MikBach]

Nein, Virtual Displacement Mapping wird auch Parallax Mapping genannt, und hat mit Vertex Texturing gar nichts zu tun, sondern findet nur im PS statt. (Zumal beides in DX möglich ist)

Ich will ja nicht an deiner Kompetenz rütteln, aber DM wird von den VS berechnet, da es sich um Geometrie-Verschiebungen handelt. Wäre mir neu, dass PS dafür verantwotlich sind.

[tokugawa]

@ tokugawa

Deine Beispiele sind einleuchtend.
Allerdings geht es mir mehr um Spiele. Die Forschung-Fuzzies machen doch nur einen kleinen Teil der Käufer solcher Grakas aus. Das ist der Punkt.

Mir geht's auch um Spiele. Mir geht es darum, endlich den Gamer-Nerds einzubläuen, dass die Forschung gerade im Bereich 3D-Grafik direkt beeinflußt und von daher 3D-Grafik von technischer Hinsicht niemals betrachtet werden kann ohne die Forschung.

Denn sieh's mal so: Hardware-Entwicklung wird ja sehr genau betrachtet, auch von Gamern. Aber wo kommt die Software her (bzw die Algorithmen, auf denen solche Software basiert?)? Genau, aus der Forschung.

Von daher muß man, will man 3D-Grafik-Technologie umfassend sowohl auf Hardware- als auch Software-Ebene betrachten, eben auch einen Blick in die aktuelle Forschung in der Echtzeitgrafik riskieren.

Immerhin ist gerade hier auch die Software/Algorithmen-Ebene sehr technisch.

[tokugawa]

Ich will ja nicht an deiner Kompetenz rütteln, aber DM wird von den VS berechnet, da es sich um Geometrie-Verschiebungen handelt. Wäre mir neu, dass PS dafür verantwotlich sind.

Er sprach auch von Virtual Displacement Mapping, die meinem Verständnis nach eine perspektivisch korrigierte Variante von Bump/Normalmapping ist und daher per Pixel durchgeführt wird.

[Xmas]

Bestimmt nicht vom Speicher. ;D
Z/Stencil
Color
Blending
FP16
FP16 Blending
FP32
MRT
oder gar Textur-Sampling-Rate (was ja auch manche als Fillrate bezeichnen)?

Ähm, verstehe ich jetzt nicht. Was hat das mit NV40/SM3 zu tun?
Das frage ich doch dich. Wenn NV40 kein SM3.0 hätte, und SM3.0 erst in drei Jahren in Hardware erschiene, wäre es dann "nötiger"?

Diese wären?
Überall wo Gradient Instructions (dsx/dsy/texldd), Branches mit langen Ästen (dynamic Branching) und mit kurzen Ästen (Predication) sowie Vertex Texturen eingesetzt werden können.

[Quasar]

Ich will ja nicht an deiner Kompetenz rütteln, aber DM wird von den VS berechnet, da es sich um Geometrie-Verschiebungen handelt. Wäre mir neu, dass PS dafür verantwotlich sind.
Deswegen der Zusatz "Virtual"....

Und jetzt erzähl'.... du bist in der Bringschuld und wir sind hier nicht in einem Rate-Thread. ;)

edit:
Nagut, ignoriere das mit dem DM, das haben dir ja schon zwei andere erklärt...

[MikBach]

Er sprach auch von Virtual Displacement Mapping, die meinem Verständnis nach eine perspektivisch korrigierte Variante von Bump/Normalmapping ist und daher per Pixel durchgeführt wird.
Nicht ganz. Virtual DM kann mehr als Bump/Normal-mapping. Die Demos mit dem sich veräderndem Terrain hast du aber gesehen?

[MikBach]

Das frage ich doch dich. Wenn NV40 kein SM3.0 hätte, und SM3.0 erst in drei Jahren in Hardware erschiene, wäre es dann "nötiger"?
Ja, da SM2 nicht mehr reichen würde. Die meisten Spiele, die jetzt verfügbar sind, geben sich mit SM2 zufrieden.


Überall wo Gradient Instructions (dsx/dsy/texldd), Branches mit langen Ästen (dynamic Branching) und mit kurzen Ästen (Predication) sowie Vertex Texturen eingesetzt werden können.
Das ist korrekt, allerdings bringt es beim NV40 wenig bis gar nichts an performance(wegen Designschwächen der GPU).

[Demirug]

Nicht ganz. Virtual DM kann mehr als Bump/Normal-mapping. Die Demos mit dem sich veräderndem Terrain hast du aber gesehen?

Natürlich kann es mehr. Es verändert Texturekoordinaten auf Pixelebene. Richtiges DM verändert aber die Geometrie.

[Xmas]

Nicht ganz. Virtual DM kann mehr als Bump/Normal-mapping. Die Demos mit dem sich veräderndem Terrain hast du aber gesehen?
"Virtual Displacement Mapping" = "Offset Mapping" = "Parallax Mapping"
Unglücklicherweise hat Epic mit der Unreal Engine 3 noch den Begriff "Virtual Displacement Mapping" eingeführt, obwohl es schon zwei andere Begriffe dafür gab.

Meinst du die Vertex Texturing Demo von NVidia? Das ist ja reales DM, kein VDM.

[tokugawa]

Nicht ganz. Virtual DM kann mehr als Bump/Normal-mapping. Die Demos mit dem sich veräderndem Terrain hast du aber gesehen?

Genau das sagte ich ja mit perspektivischer Korrektur.

Da ja Hügel und Erhebungen, je nachdem von welchem Winkel man draufschaut, jeweils anders ausschauen.

[Demirug]

Ja, da SM2 nicht mehr reichen würde. Die meisten Spiele, die jetzt verfügbar sind, geben sich mit SM2 zufrieden.

Weil es eben nicht mehr als SM2 gegeben hat. Warum warten bis es nicht mehr reicht?

Das ist korrekt, allerdings bringt es beim NV40 wenig bis gar nichts an performance(wegen Designschwächen der GPU).

Predication funktioniert perfekt. Beim Branching sind in den Pixelshader die Blockgrössen etwas gross aber im Vertexshader läuft es ganz gut. Aber selbst mit den grossen Blockgrössen kann man noch was anfangen.

[tokugawa]

Ja, da SM2 nicht mehr reichen würde. Die meisten Spiele, die jetzt verfügbar sind, geben sich mit SM2 zufrieden.


Käme SM3.0 in 3 Jahren raus, gäbe es dann auch nur Spiele, die sich mit SM2 zufrieden geben würden. Erst die verfügbare Hardware bedingt die entsprechende Entwicklung in Software.


Das ist korrekt, allerdings bringt es beim NV40 wenig bis gar nichts an performance(wegen Designschwächen der GPU).

Wie wär's mit etwas mehr als in den Raum geworfenen Thesen? Etwa eine Begründung deiner Thesen wäre nett.

[Xmas]

Ja, da SM2 nicht mehr reichen würde. Die meisten Spiele, die jetzt verfügbar sind, geben sich mit SM2 zufrieden.
Sie geben sich mit SM2 zufrieden, weil es fast keine Hardware für SM3 gibt. NVidia sorgt jetzt dafür, dass die Hardware da ist, so dass die Entwickler bald die Möglichkeit haben SM3 zu integrieren.

Das ist korrekt, allerdings bringt es beim NV40 wenig bis gar nichts an performance(wegen Designschwächen der GPU).
Verglichen zu was?

[IVN]

Zumindest dynamisches Displacement Mapping (bzw Displacement Mapping mit dynamischer Tesselation).

Ein static Tesselation Displacement Mapping wäre imo auch Displacement Mapping, wo man halt in einem fixen Grid mittels Heightmap (per Vertex) displacet statt über dynamisch tesselierte Geometrie.

Nur um mal die Begriffe exakt zu definieren :)

Are you sure that Parallax Mapping isn't =Offset mapping,and Virtual DM=Vertex texture fetch ??

[MikBach]

Natürlich kann es mehr. Es verändert Texturekoordinaten auf Pixelebene. Richtiges DM verändert ab die Geometrie.

Das "ab" sollte doch "aber" heissen?

[Demirug]

Das "ab" sollte doch "aber" heissen?

Natürlich

[MikBach]

Predication funktioniert perfekt. Beim Branching sind in den Pixelshader die Blockgrössen etwas gross aber im Vertexshader läuft es ganz gut. Aber selbst mit den grossen Blockgrössen kann man noch was anfangen.
Die Bremse ist die PS-Performance. VS-Power ist genug vorhanden.

[Demirug]

Die Bremse ist die PS-Performance. VS-Power ist genug vorhanden.

Die beim Vertextexturing aufgrund von Latenzen schnell aufgebraucht werden kann. Da kann es schon interesant sein ein Sample zu überspringen wenn man erkennt das man es eigentlich nicht braucht.

Auch wenn man mit einem Z-Only-Pass arbeitet kann der VS durchaus mal zur Bremse werde.

[tokugawa]

Are you sure that Parallax Mapping isn't =Offset mapping,and Virtual DM=Vertex texture fetch ??

To be honest, I don't really keep up with how things are called these days.

I see several classes of displacement mapping:

1) Static mesh displacement mapping. Given a polygon mesh (grid, for instance), use a heightmap that encodes the height at each position, and displace each vertex. This was up until now typically done on the CPU, but now, with Vertex Texture Fetch, can be done in the Vertex Program.

2) Dynamic mesh displacement mapping. This is basically analogous to 1), except that the mesh is dynamically tesselated (like some LOD Algorithms like ROAM do). To do this in hardware, a tesselation unit would be required.

3) Parallax Mapping (and whatever else it is called). Done in the Pixel Shader, it's basically a more advanced alternative to mere bumpmapping, where the "bumps" are actually perspectively distorted (bumps should look different from different angles, more than a plain planar map). So it basically takes into account the view vector. I have to admit that I know the least about this variant, but this is how I understood it. Correct me if I'm wrong.

[MikBach]

Die beim Vertextexturing aufgrund von Latenzen schnell aufgebraucht werden kann. Da kann es schon interesant sein ein Sample zu überspringen wenn man erkennt das man es eigentlich nicht braucht.

Auch wenn man mit einem Z-Only-Pass arbeitet kann der VS durchaus mal zur Bremse werde.
Was du hier ansprichst sind aber Ausnahmen. Ist auch auf den NV40 bezogen und somit richtig. Was anderes wollte ich nicht zum Ausdruck bringen.

[LovesuckZ]

Beim Branching sind in den Pixelshader die Blockgrössen etwas gross aber im Vertexshader läuft es ganz gut.

Warum bricht Nvidia mit "static flow control" im Gegensatz zu ATi so stark ein?

[Demirug]

tokugawa, es gibt noch eine weiter Art. Bei dieser verändert sich Texture welche die Verschiebungen enthält dynamisch. Schön für Wellenbewegungen.

[tokugawa]

Die Bremse ist die PS-Performance. VS-Power ist genug vorhanden.

Genau das ist eine Software-Frage. Man sollte idealerweise eine Engine (und die Szenen) so entwerfen, dass sie eine optimale Balance zwischen Geometrie- und Pixel-Einheiten bewirkt.

Mit anderen Worten, deine Behauptung ist falsch solange du nicht den folgenden Zusatz machst: "Je nach Software".

Ist zuviel Geometrie-Power (VS-Power) vorhanden, kann man mehr Vertizes pro Szene rendern (for free), um den Bottleneck PS-Power auszugleichen.

Das ist natürlich seit den programmierbaren Vertex und Pixeleinheiten etwas nichttrivialer geworden, aber der Grundsatz besteht noch immer.

[Demirug]

Warum bricht Nvidia mit "static flow control" im Gegensatz zu ATi so stark ein?

ATI kann in den Pixelshadern doch gar kein "static flow control", oder was meinst du jetzt?

[LovesuckZ]

ATI kann in den Pixelshadern doch gar kein "static flow control", oder was meinst du jetzt?

Nein, das bezug sich auf die Vertexshader.
War wohl nicht genug definiert :)

[MikBach]

Genau das ist eine Software-Frage. Man sollte idealerweise eine Engine (und die Szenen) so entwerfen, dass sie eine optimale Balance zwischen Geometrie- und Pixel-Einheiten bewirkt.

Mit anderen Worten, deine Behauptung ist falsch solange du nicht den folgenden Zusatz machst: "Je nach Software".

Ist zuviel Geometrie-Power (VS-Power) vorhanden, kann man mehr Vertizes pro Szene rendern (for free), um den Bottleneck PS-Power auszugleichen.

Das ist natürlich seit den programmierbaren Vertex und Pixeleinheiten etwas nichttrivialer geworden, aber der Grundsatz besteht noch immer.

Da muss ich zustimmen. Allerdings rede ich immer auf Spiele bezogen. Und hier ist meine Aussage richtig. Also nichts mit "falsch". ;)
Du kommst mir langsan so vor wie aths. Theorie-blabla, aber Praxis nichts.

[LovesuckZ]

Du kommst mir langsan so vor wie aths. Theorie-blabla, aber Praxis nichts.

Farcry, reicht doch, oder?
Immerhin ist es moeglich mit dem SM3.0 4 statt nur 3 Lichtquellen in einen Pass zu rendern.

[Quasar]

blabla, aber [sonst] nichts.
apropos..... bringst du dein Argument noch zu Ende, oder ist das auch nur "blabla" und sonst nichts?

Ich würde mich freuen, wenn du diese Features, die unter DX nicht ansprechbar wären, mit uns teilst. :)

[Quasar]

Farcry, reicht doch, oder?
Immerhin ist es moeglich mit dem SM3.0 4 statt nur 3 Lichtquellen in einen Pass zu rendern.
Nope, das ginge schon mit der FX, ist also nicht allein SM3 zuzurechnen.

[MikBach]

Farcry, reicht doch, oder?
Immerhin ist es moeglich mit dem SM3.0 4 statt nur 3 Lichtquellen in einen Pass zu rendern.
Und?
Performance?
Immer diese Theoriefuzzies.

@ Quasar
frag aths. Der kann es dir sicherlich besser erklären, weil er ein Guru ist.

[LovesuckZ]

Nope, das ginge schon mit der FX, ist also nicht allein SM3 zuzurechnen.

Hm, ich dachte, das laege an einer Eigenschaft (diese 10 Dinger statt 8), wodurch es moeglich sei, 4 statt nur 3 Lichtquellen zu berechnen, laut Demirug.
Aber gut, dann warten wir auf das naechste "SM3.0" Game.

[Quasar]

@ Quasar
frag aths. Der kann es dir sicherlich besser erklären, weil er ein Guru ist.

Wieso sollte ich? Du hast dir laut eigener Aussage irgendeine nicht näher beschrieben Aussage in einem (oder mehreren?) von aths 17.000+ Postings zu eigen gemacht - wenn du das als mehr verstanden wissen möchtest, als "heisse Luft mit nichts dahinter" wäre es sinnvoll, wenn du zumindest dieses ominöse Feature (oder sind es gar mehrere) mit einem Link zu einem dieser Postings belegst - eine Erklärung erwarte ich ja noch nichtmal....

[Demirug]

Nein, das bezug sich auf die Vertexshader.
War wohl nicht genug definiert :)

Gerüchteweise rollt ATI die Vertexshader im Treiber auf und entfernt dadurch die Branches.

[tokugawa]

Da muss ich zustimmen. Allerdings rede ich immer auf Spiele bezogen. Und hier ist meine Aussage richtig. Also nichts mit "falsch". ;)
Du kommst mir langsan so vor wie aths. Theorie-blabla, aber Praxis nichts.

Nein. Auch bei Spielen kommt es auf jedes Einzelexemplar an. Sogar ein einzelnes Spiel hat nicht dasselbe konstante Verhältnis Geometrie zu Pixelauslastung (geht gar nicht).

Folglich ist selbst "bei Spielen" deine Aussage nicht allgemeingültig richtig. Du mußt schon konkrete Exemplare nennen, oder zumindest zugeben, dass es nicht so sein muß, damit die Aussage korrekt wird.

Den Vergleich mit aths fasse ich als Kompliment auf.

Und übrigens, Theorie und Praxis sind verbunden und gehören unweigerlich zusammen, wenn man umfassend Wissen haben möchte.

Und deine Auffassung von "Theorie" teile ich ebenfalls nicht. Was ich bisher erwähnte, war alles Praxis (i.e. umgesetzt in wirklicher Software). Theorie wäre für mich, würde all das, was ich erwähnt habe, nur in White Papers existieren. Aber es gibt, wie gesagt, praktische Umsetzungen davon. Bloß weil diese Umsetzungen derzeit noch in der Forschung existieren (als Machbarkeits-Demonstration), macht es nicht weniger "praxisnah".

Und den engen Zusammenhang Forschung und Spiele will ich jetzt nicht zum x-ten Mal wiederholen. Vor allem für technisch Interessierte wie dich denke ich, dass gerade auch die Entwicklungen im Bereich Software genauso interessant sein sollten wie jene im Bereich Hardware. Immerhin sind die meisten "Effekte" auf die Algorithmen zurückzuführen. Pixelshader-Wasser gibt's z.B. auch nicht deswegen, weil es Pixel Shader gibt, sondern deswegen, weil sich Algorithmiker in der Computergrafik hingesetzt haben, und ebensolche Verfahren entwickelt haben.

[Hauwech]

Wenn ich teilweise hier so lese das SM3 "im Moment" nutzlos ist und wenn überhaupt, viel zu langsam. Mal ganz ehrlich, wie wären dann PS1.4 anzusehen? Immerhin habe ich auch noch kein "PS1.4 Spiel" gesehen aber PS1.4 hat mit den Weg zu SM2 geebnet. War also 1.4 so scheisse und nutzlos weil mit PS1.3 hätte man auch alles machen können?

Ich glaube nicht. ATI hat mit SM2 einen Anfang gemacht und bis jetzt kann man ja wohl behaupten das SM2 kein Blindgänger ist. Nvidia macht mit SM3 jetzt einen Anfang. Es ist seitens Microsoft auch für Enduser nutzbar was bei SM2 doch einige Zeit gedauert hat. Davon abgesehen, wann gab es nach Vorstellung des R300 das erste Spiel mit SM2 was "richtig" davon profitiert hat und nicht diese typischen anfänglichen Eye-Candies? Ich verlange gar nicht das SM2 bzw SM3 sofort und für alles eingesetzt wird. Macht aus wirtschaftlicher Sicht keinen Sinn und ist für die Programmierer bestimmt auch nicht "mal so eben" umsetzbar.

Wenn neue Sachen so sinnlos sind, warum entwickeln dann MS, OGL, ATI, NV und wie sie alle heissen 3D weiter obwohl nach Meinung einiger hier SM2.b von ATI doch schon für alles ausreichend ist? Tut mir leid aber sowas ist einfach kompletter Schwachsinn der teilweise sehr rot gefärbt ist. Ich will hier SM3 und den NV40 nicht in den Himmel loben aber es ist ein Anfang der viele Sachen erst nutzbar und interessant macht, auch wenn man es auf dem Schirm erstmal gar nicht sieht, genauso wie ATI es mit dem R300 gemacht hat. Und nicht vergessen, der NV40 ist erst seit kurzem draussen.

[Demirug]

Hm, ich dachte, das laege an einer Eigenschaft (diese 10 Dinger statt 8), wodurch es moeglich sei, 4 statt nur 3 Lichtquellen zu berechnen, laut Demirug.
Aber gut, dann warten wir auf das naechste "SM3.0" Game.

Auf die Art wie es Crytek implemnetiert hat kann man mit SM 2.A und SM 2.B bis zu 3 Lichtquellen und mit SM3 4 in einem Pass rendern. Man kann durch änderung des Verfahrens die Anzahl aber bei beiden Modelen noch erhöhen.

EDIT PS: Ich habe aber bis jetzt noch keine Stelle gefunden wo man 4 Lichtquellen auf einem Objekt hat.

[MikBach]

Wieso sollte ich? Du hast dir laut eigener Aussage irgendeine nicht näher beschrieben Aussage in einem (oder mehreren?) von aths 17.000+ Postings zu eigen gemacht - wenn du das als mehr verstanden wissen möchtest, als "heisse Luft mit nichts dahinter" wäre es sinnvoll, wenn du zumindest dieses ominöse Feature (oder sind es gar mehrere)mit einem Link zu einem dieser Postings belegst - eine Erklärung erwarte ich ja noch nichtmal....
Richtig, es sind mehrere,
Ich werde dir diesen Gefallen aber auch nicht tun.
Lesen bildet.

[tokugawa]

Und?
Performance?
Immer diese Theoriefuzzies.

@ Quasar
frag aths. Der kann es dir sicherlich besser erklären, weil er ein Guru ist.

Es ist IRL möglich. Daher gehört es in die Praxis.

Den Begriff den du mit "praxisnah" verwechselst ist "in plausiblen Rahmenbedingungen durchführbar" ("feasible").

Das mag für dich wie Nitpicking klingen, aber ich finde die Unterscheidung doch wichtig. Vieles heutzutage wird Theorie genannt, was nicht Theorie sondern Praxis ist. Und umgekehrt.

Und an Theorie ist nichts schlechtes. Es wird benötigt, um die Praxis zu verstehen.

[Quasar]

Richtig, es sind mehrere,
Ich werde dir diesen Gefallen aber auch nicht tun.
Lesen bildet.
Es ist kein Gefallen - es ist DEIN Argument.
Aber so bleibt es leider nichts weiter als heisse Luft, Posten um des Postens und der Aufmerksamkeit willen.

[IVN]

Nope, das ginge schon mit der FX, ist also nicht allein SM3 zuzurechnen.


Yes, you can also calculate 4 lights on an r420,but just like on an nv3x this isn't going to be fast.That could be done by rapeing the GPU.Ask Demirug for more details.




@LovesuckZ

8 and 10 input registers.But an nv3x has 8 just like r420.

[tokugawa]

Richtig, es sind mehrere,
Ich werde dir diesen Gefallen aber auch nicht tun.
Lesen bildet.

Lesen bildet wenn es neue Informationen bietet.

Wenn es nur rein der Suche nach irgendwas dient, was du erwähnt hast, für die Diskussion wichtig ist, aber du nicht näher spezifizieren möchtest, ist es nur Schikane, IMO.

Also sag's endlich!

[mapel110]

Lesen bildet...

....Diskutieren ohne Argumente nicht.

[Quasar]

Yes, you can also calculate 4 lights on an r420,but just like on an nv3x this isn't going to be fast.That could be done by rapeing the GPU.Ask Demirug for more details.
Yep, sorry, mein Fehler. Das hatte ich dann wohl falsch im Gedächtnis.

[MikBach]

Jungs, aths hat das schon paar mal erwähnt. Wäre zu einfach für euch.
Solltet ihr bis Montag keine Antwort gefunden haben, werde ich euch auf die Sprünge helfen.
Ich dachte wir hätten hier "wirkliche" Intelligenz am Start. Echt übel. ;)

[tokugawa]

Jungs, aths hat das schon paar mal erwähnt. Wäre zu einfach für euch.
Solltet ihr bis Montag keine Antwort gefunden haben, werde ich euch auf die Sprünge helfen.
Ich dachte wir hätten hier "wirkliche" Intelligenz am Start. Echt übel. ;)

Ehrlich, wenn du vage Behauptungen aufstellst, und meinst sie mit aths' Aussagen untermauern zu können, aber dann selber nicht in der Lage bist, jene Postings zu referenzieren, wieso mangelt es dann uns an Intelligenz? Gedanken lesen können wir noch nicht.

Außerdem was hat es mit Intelligenz zu tun, wenn man das von dir angesprochene aths-Posting nicht gelesen hat?

Da du anscheinend weißt, was du meinst (solltest du wohl), ist doch der effizienteste Weg, wenn du diese Argumente auch darlegst, wenn du schon nicht korrekt zitieren oder referenzieren kannst.

Bei einem White Paper werden Referenzen ja auch nicht in der Form "Jo, irgendwo in der Bibliothek steht's schon, sucht einfach!" gegeben, sondern zumindest das Buch genannt, manchmal sogar die Seiten. Also zumindest den THREAD des angesprochenen aths-Postings nenne uns, bitte.

[LovesuckZ]

Yes, you can also calculate 4 lights on an r420,but just like on an nv3x this isn't going to be fast.That could be done by rapeing the GPU.Ask Demirug for more details.

Imo sollte es auch auf den FX Karten moeglich sein *Fuege maximale Zahl des r420 ein* Lichter zu verwenden, dass es zur schnelleren Berechnung dient.
Shadermaeßig muesste er dazu in der Lage sein (ich geh davon aus, dass mit dem Patch 1.2 Farcry kein MRT und Centroid sampling verwendet).

@LovesuckZ
8 and 10 input registers.But an nv3x has 8 just like r420.

Input Register, das war es. Danke.

[robbitop]

Input Register, das war es. Danke.

waren es nicht Interpolatoren?

[MikBach]

Ehrlich, wenn du vage Behauptungen aufstellst, und meinst sie mit aths' Aussagen untermauern zu können, aber dann selber nicht in der Lage bist, jene Postings zu referenzieren, wieso mangelt es dann uns an Intelligenz? Gedanken lesen können wir noch nicht.
Außerdem was hat es mit Intelligenz zu tun, wenn man das von dir angesprochene aths-Posting nicht gelesen hat?
Immer ruhig! Wenn du die aths-postings nicht gelesen hast, tut es mir leid für dich. Da steht eigentlich alles. Ich werde euch morgen trotztdem aufklären.

Da du anscheinend weißt, was du meinst (solltest du wohl), ist doch der effizienteste Weg, wenn du diese Argumente auch darlegst, wenn du schon nicht korrekt zitieren oder referenzieren kannst.

Ich kann das schon belegen. Ich warte auf eure Intelligenz.

[IVN]

@robbitop

I'm not sure,but it shuld be input registers.
Anyway ask Demirug.I'm not the Guru,but he is. :D

[Demirug]

waren es nicht Interpolatoren?

Ist beides das gleiche.

Die Input register enthalten die von den Interpolatoren errechneten Werte.

[Quasar]

Ich warte auf eure Intelligenz.
Du magst gern provozieren, gell? Gut, daß ich heute recht ausgeglichener Stimmung bin, mir fiele da eine nette riposte zu ein.


Ich hoffe jedenfalls, daß zumindest deine Intelligenz reicht, um das Posting, worauf du deine Argumentation gründest, bis morgen zu wiederzufinden. =)

Dann können wir weiterreden, bis dahin beende ich mal dieses Gespräch mit einem unzuverlässigen Kolporteur.

[IVN]

Auf die Art wie es Crytek implemnetiert hat kann man mit SM 2.A und SM 2.B bis zu 3 Lichtquellen und mit SM3 4 in einem Pass rendern. Man kann durch änderung des Verfahrens die Anzahl aber bei beiden Modelen noch erhöhen.

EDIT PS: Ich habe aber bis jetzt noch keine Stelle gefunden wo man 4 Lichtquellen auf einem Objekt hat.


Is it possible to render more then 3 on an r420,and more then 4 lights on an nv40,with some other method that is diferent then that in FarCry engine.

[Demirug]

Is it possible to render more then 3 on an r420,and more then 4 lights on an nv40,with some other method that is diferent then that in FarCry engine.

Ja es ist möglich. Aber wie gesagt habe ich bei Farcry bisher noch nicht mal einen der 4 Lichtquellen Shader im Einsatz gesehen.

[IVN]

@Demirug

And what is the max. number of lights??

3Dmark 2001se has an test with 8 lights,is that in single pass??

[MikBach]

Du magst gern provozieren, gell? Gut, daß ich heute recht ausgeglichener Stimmung bin, mir fiele da eine nette riposte zu ein.


Ich hoffe jedenfalls, daß zumindest deine Intelligenz reicht, um das Posting, worauf du deine Argumentation gründest, bis morgen zu wiederzufinden. =)

Dann können wir weiterreden, bis dahin beende ich mal dieses Gespräch mit einem unzuverlässigen Kolporteur.
Lol.
Siehe mal das Posting von Bokill. Er kann dich in Sachen Cpus locker in die Tasche stecken(mit Hut). ;)
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=2139556&postcount=31
Und?
Mit wem werde ich im gleichen Atemzug genannt?
2 CPU-Gurus
1 3dGuru.
und jemandem, der sich in Sachen CPU wirklich gut auskennt.
Da kannst du einpacken, aber wirklich!

[Quasar]

Die meiste Consumer-Hardware unterstützt 8 TnL-Lichter (ich denke mal, daß damit Single-Pass gemeint ist).

Profi-OpenGL-Chips können und konnten schon länger, bis zu 32 HW-Lichter.

edit:
@MikBach:
Ja, schön für dein Ego.

[tokugawa]

Lol.
Siehe mal das Posting von Bokill. Er kann dich in Sachen Cpus locker in die Tasche stecken(mit Hut). ;)
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=2139556&postcount=31
Und?
Mit wem werde ich im gleichen Atemzug genannt?
2 CPU-Gurus
1 3dGuru.
und jemandem, der sich in Sachen CPU wirklich gut auskennt.
Da kannst du einpacken, aber wirklich!

Und was beweist das?

[tokugawa]

@Demirug

And what is the max. number of lights??

3Dmark 2001se has an test with 8 lights,is that in single pass??

But that was using fixed function rendering. In which case 8 lights is the minimum supported on common hardware these days (I think the minimum value for GL_MAX_LIGHTS is also 8 under OpenGL).

Illumination calculations in a shader are a different case.

[Demirug]

@Demirug

And what is the max. number of lights??

3Dmark 2001se has an test with 8 lights,is that in single pass??

Das sind Vertexlichter und keine Lichtquellen mit Per Pixel Bumpmapping. Die Lichtberechung beim 3dmark findet also vollständig in den Vertexshadern bzw im HT&L stat.

Die maximale Anzahl von beim Einsatz von Per Pixel Lichtquellen hängt auch ein wenig von der Art der Lichtquelle ab. Farcry unterstützt ja mehr als eine Sorte von Lichtquelle die auch jeweils unterschiedliche Anforderungen an die Resourcen stellen.

[MikBach]

Und was beweist das?
Diese Frage ist aber nicht Ernst? Oder?
Das soll bweisen, dass einige ohne Hitergrundwissen irgendein BS von sich geben!
Falls weitere Begründung gefragt ist, stehe ich gerne zur Verfügung.

[IVN]

Das sind Vertexlichter und keine Lichtquellen mit Per Pixel Bumpmapping. Die Lichtberechung beim 3dmark findet also vollständig in den Vertexshadern bzw im HT&L stat.

Die maximale Anzahl von beim Einsatz von Per Pixel Lichtquellen hängt auch ein wenig von der Art der Lichtquelle ab. Farcry unterstützt ja mehr als eine Sorte von Lichtquelle die auch jeweils unterschiedliche Anforderungen an die Resourcen stellen.


OK,i can't remember what kind of test that was. :(
I know only that it had 8 lights.
But what is the max. number of lights that could be calculated with shaders??

[MikBach]

edit:
@MikBach:
Ja, schön für dein Ego.
Nicht wirklich.
Schlecht für deine Reputation. Scheisse labbern kan jeder, aber mit Aegumenten kontern ist nicht deine Stärke.

[tokugawa]

Diese Frage ist aber nicht Ernst? Oder?
Das soll bweisen, dass einige ohne Hitergrundwissen irgendein BS von sich geben!
Falls weitere Begründung gefragt ist, stehe ich gerne zur Verfügung.

OK, da muß es mir an Intelligenz mangeln.

Also nochmal langsam, damit selbst ich Dummy es kapiere.

Dein Beweispfad war folgender:

1) du zeigt den Post irgendeines Typen, dem du großes Wissen bei CPUs attestierst.

2) dieser Typ erwähnt dich in einem Atemzug mit anderen designierten "CPU" und "3D"-Gurus

3) und deswegen bist du automatisch auch jemand, der sich super mit allem auskennt?

[tokugawa]

Nicht wirklich.
Schlecht für deine Reputation. Scheisse labbern kan jeder, aber mit Aegumenten kontern ist nicht deine Stärke.

Deine aber auch nicht. Wir warten ja noch immer auf deine Argumente. Du gibst nur Halbthesen, untermauerst sie nicht, und dein Argumentationspfad ist schwach und voller Argumentationsfehler.

Ich empfehle einen Kurs in mathematischer Logik :)

[Demirug]

OK,i can't remember what kind of test that was. :(
I know only that it had 8 lights.
But what is the max. number of lights that could be calculated with shaders??

Das hängt von zu vielen Faktoren ab als das man darauf eine allgemein gültige Antwort geben könnte. Man muss sich auch eher die Frage stellen wie viele Lichtquellen pro Pixel aus Performancegründen sinnvoll sind.

[mapel110]

Hm, gibts hier noch eine sachliche Diskussion, oder nurnoch Kompetenzgerangel?! Dann kann man den thread auch dicht machen.

@Mikbach entweder du kommst auf den Punkt oder du lässt das Posten hier sein. Andernfalls kann man das durchaus als Spam auffassen, was du hier machst. (für Rückfragen zu dieser Ermahnung bitte PN, weil hier wäre es offtopic.) Danke.

[IVN]

@Demirug

"Man muss sich auch eher die Frage stellen wie viele Lichtquellen pro Pixel aus Performancegründen sinnvoll sind."


So what's the answer??

[robbitop]

the popular answer would be 3, wouldn't it?

[Demirug]

@Demirug

"Man muss sich auch eher die Frage stellen wie viele Lichtquellen pro Pixel aus Performancegründen sinnvoll sind."


So what's the answer??

Sobald ich sie kenne sage ich es dir. ;)

Ernsthaft. Es gibt auf eine Frage wie diese keine richtige Antwort. Zum einen werden die Karten zwar immer schneller aber auch die Lichteffekte werden immer anspruchsvoller.

[IVN]

@LovesuckZ @Quasar @tokugawa @robbitop

You all don't have to wait long,it's only 1 1/2 hours until Monday. ;D


And then MikBach is going to tell us his secret. =)

[MikBach]

Shit!
Sorry Jungs!
Ich glaube ihr müsst euch noch bisschen gedulden. Ich kann den Post nicht mehr wieder finden. :frown:
Das ist mir jetzt aber echt peinlich.
Na ja, aths hat halt geschrieben, dass Branching beim NV40 nichts bringt. Es soll aber 3 oder 4 nette Sachen geben, die den NV40 beschleunigen könnten. Diese würden jedoch nicht in DX9 spezifiziert sein.
Vielleicht kann aths selbst was dazu sagen?
Ich habe mir es halt nicht gemerkt, da sie ja nicht in DX9 spezifiziert sind. Wäre aber sinnvol zu erfahren, welche Features das sind, auch wenn sie ausserhalb der Spezifikation liegen. Wie wir alle wissen, sind die Specs von DX "dehnbar", siehe Compilerprofile 2.a und 2.b. Die waren auch nicht von Anfang an geplannt, sind jetzt jedoch Bestandteil von DX9.
Ich kann auch nicht so recht verstehen, warum die IHV einige Features "verheimlichen". Wenn sie gut sind, sollte man es doch öffentlich machen, davon können nur alle profitieren.

Deine aber auch nicht. Wir warten ja noch immer auf deine Argumente. Du gibst nur Halbthesen, untermauerst sie nicht, und dein Argumentationspfad ist schwach und voller Argumentationsfehler.

Ich empfehle einen Kurs in mathematischer Logik :)

Danke für den Tip. ;)

Ich glaube das Problem ist, dass wir aneinander vorbei reden.
Ich stimme dir mit den Algorythmen usw. voll zu. Grundlagenarbeit muss sein.
Was interessiert das jedoch einen Gamer, der spielen will und sich nicht für so etwas begeistern kann.
Und die 6800 ist als Gamerkarte auf dem Markt.
Und hier zählt, was am Ende rauskommt. Wie es zustande kommt, juckt nur die wenigsten(mich schon). :)

[Demirug]

Wie wir alle wissen, sind die Specs von DX "dehnbar", siehe Compilerprofile 2.a und 2.b. Die waren auch nicht von Anfang an geplannt, sind jetzt jedoch Bestandteil von DX9.
Ich kann auch nicht so recht verstehen, warum die IHV einige Features "verheimlichen". Wenn sie gut sind, sollte man es doch öffentlich machen, davon können nur alle profitieren.

Das mit den Profilen war schon so geplannt. OK ist ausserhalb des Beta-Programms von MS nicht sonderlich publik gemacht worden.

[tokugawa]

Shit!
Sorry Jungs!
Ich glaube ihr müsst euch noch bisschen gedulden. Ich kann den Post nicht mehr wieder finden. :frown:
Das ist mir jetzt aber echt peinlich.
Na ja, aths hat halt geschrieben, dass Branching beim NV40 nichts bringt. Es soll aber 3 oder 4 nette Sachen geben, die den NV40 beschleunigen könnten. Diese würden jedoch nicht in DX9 spezifiziert sein.
Vielleicht kann aths selbst was dazu sagen?
Ich habe mir es halt nicht gemerkt, da sie ja nicht in DX9 spezifiziert sind. Wäre aber sinnvol zu erfahren, welche Features das sind, auch wenn sie ausserhalb der Spezifikation liegen. Wie wir alle wissen, sind die Specs von DX "dehnbar", siehe Compilerprofile 2.a und 2.b. Die waren auch nicht von Anfang an geplannt, sind jetzt jedoch Bestandteil von DX9.
Ich kann auch nicht so recht verstehen, warum die IHV einige Features "verheimlichen". Wenn sie gut sind, sollte man es doch öffentlich machen, davon können nur alle profitieren.


Danke für den Tip. ;)

Ich glaube das Problem ist, dass wir aneinander vorbei reden.
Ich stimme dir mit den Algorythmen usw. voll zu. Grundlagenarbeit muss sein.
Was interessiert das jedoch einen Gamer, der spielen will und sich nicht für so etwas begeistern kann.
Und die 6800 ist als Gamerkarte auf dem Markt.
Und hier zählt, was am Ende rauskommt. Wie es zustande kommt, juckt nur die wenigsten(mich schon). :)


Genau, die Gamer interessiert es nicht.

Technikinteressierte Gamer sollte es aber interessieren. Also quasi genau die Zielgruppe von 3DCenter.

Ach ja, die 6800 ist ziemlich universell ausgelegt, nicht nur für Gamer. Wurde von seiten NVIDIA ja auch an Forscher und Uni-Institute verschickt (wenn man sie beantragt). Was ich ziemlich positiv finde angesichts dessen, dass gerade bei Uni-Instituten NVIDIA ja nicht unbedingt exklusiv etwas zurückbekommt, wovon sie profitieren (es gibt ja keine Klausel dass Forschungsergebnisse NVIDIA zugespielt werden müssen oder ähnliches).

[Exxtreme]

Das mit den Profilen war schon so geplannt. OK ist ausserhalb des Beta-Programms von MS nicht sonderlich publik gemacht worden.
Naja, aber das mit den Profilen ist auch irgendwie... IMHO Murks. :|

IMHO wäre es besser wenn man den HLSL-Code direkt an den Treiber übergeben würde. Der Treiber könnte dann von sich aus besser optimieren. Man hätte zwar dann weniger Kontrolle über die verwendeten Shader-Level aber IMHO ist dies kein wichtiger Nachteil.

[Demirug]

Naja, aber das mit den Profilen ist auch irgendwie... IMHO Murks. :|

IMHO wäre es besser wenn man den HLSL-Code direkt an den Treiber übergeben würde. Der Treiber könnte dann von sich aus besser optimieren. Man hätte zwar dann weniger Kontrolle über die verwendeten Shader-Level aber IMHO ist dies kein wichtiger Nachteil.

Doch ist es. Damit wäre die Validierbarkeit von Shadern nicht mehr gegeben.

HLSL Code kann man erst übergeben wenn per Definition jeder Code ausgeführt werden muss.

Man hätte unter Umständen noch eine zweite Schnittstelle auf Highlevel eben als Option einbauen können.

Zudem sind viele Entwickler immer noch Paranoiker und wollen iheren HLSL Code gar nicht mit ausliefern.

[Exxtreme]

Doch ist es. Damit wäre die Validierbarkeit von Shadern nicht mehr gegeben.

HLSL Code kann man erst übergeben wenn per Definition jeder Code ausgeführt werden muss.
Naja, darum könnte sich der Treiber kümmern. Sprich, auf einer SM3.0-fähigen GraKa macht er einen LowLevel-Shader und auf einer SM2.0-GraKa deren fünf oder so. Jetzt hat man jeden Shader in vierfacher Ausführung auf der CD bloß weil jede GraKa eine andere Variante will.

Man hätte unter Umständen noch eine zweite Schnittstelle auf Highlevel eben als Option einbauen können.

Oder so.

Zudem sind viele Entwickler immer noch Paranoiker und wollen iheren HLSL Code gar nicht mit ausliefern.
Ist ja auch verständlich. Da steckt ja deren KnowHow drin.

[Demirug]

Naja, darum könnte sich der Treiber kümmern. Sprich, auf einer SM3.0-fähigen GraKa macht er einen LowLevel-Shader und auf einer SM2.0-GraKa deren fünf oder so. Jetzt hat man jeden Shader in vierfacher Ausführung auf der CD bloß weil jede GraKa eine andere Variante will.

Das meine ich nicht mit Validierbarkeit. Bei Hochsprachenshader ist es schwer abzuschätzen wie víele Resourcen man braucht. Man stelle sich vor das man einen Shader hat der auf einem R300 und NV3X läuft aber auf einem Deltachrom nicht weil er dort ein Limit überschritten hat. Zudem könnten Compielerfehler die sich in den Treiber eingeschmugelt haben dazu führen das mit einem neuen Treiber das Limit plötzlich überschritten wird.

Die Assemblerschnittstelle reduziert diese Gefahr ehrheblich.

Man kann den Shader auch als HLSL ausliefern und erst beim Endekunden kompilieren. Da in Zukunft sowieso verstärkt dynamische Shader kommen wird das eh üblich werden.

[aths]

Du kommst mir langsan so vor wie aths. Theorie-blabla, aber Praxis nichts.Was meine Praxis angeht, kann ich zwar nur einige sehr kleine OpenGL-Programme anbieten, aber das ist nicht nichts.

Ohne reines Theorie-Wissen hätte ich z. B. eine (sehr einfache, nur begrenzt einsetzbare) Schattenwurftechnik nicht programmieren können. (An Theorie brauchte ich: 3D-Transformation via Matrizenmultiplikation, Berechnung des Schnittpunktes einer Geraden mit einer Ebene, dazu Lösung eines linearen Gleichungssystems, der Einfachheit halber mit dem Cramer-Verfahren, wozu man die Determinanten einer Matrix berechnen muss. Für 3x3-Matrizen wären das LaPlace-Verfahren, was ich irgendwann man rekursiv in C geproggt habe aber übertrieben, weil das Saruss'sche Verfahren bei 3x3 noch funktioniert.)

(Ach ja, zur Beleuchtung musste ich mittels Kreuzprodukt aus 2 Vertices eines Dreiecks die Normale berechnen. Und um die Lichtquelle aus jedem Winkel darzustellen, musste ich das GL_Quad mit Alphablending-Textur erst mal "zurücktransformieren" bevor es mit der Kamera-Transformation dann wieder "hintransformiert" wird. Alles basiert auf reiner Mathematik, die mir beigebracht wurde ohne dass sofort Anwendungsmöglichkeiten in der Praxis genannt worden sind. Die finden sich schon.)

Shit!
Sorry Jungs!
Ich glaube ihr müsst euch noch bisschen gedulden. Ich kann den Post nicht mehr wieder finden. :frown:
Das ist mir jetzt aber echt peinlich.
Na ja, aths hat halt geschrieben, dass Branching beim NV40 nichts bringt. Es soll aber 3 oder 4 nette Sachen geben, die den NV40 beschleunigen könnten. Diese würden jedoch nicht in DX9 spezifiziert sein.
Vielleicht kann aths selbst was dazu sagen?Ja. Auf Teil 3 des NV40-Technikartikels warten. In Teil 1 steht ja schon drin, dass NV40 mit großen Quadbatches arbeitet. Es sieht so aus als ob die Entscheidung, nur einen oder doch beide Branches auszuführen nur per Batch getroffen werden kann. Nalu selbst (OpenGL hin oder her) profitiert kaum durch das Branchen.

Das Geile ist halt, dass man überhaupt bedingte Sprünge verwenden kann. Frage mal einen Programmierer, ob er sich eine Programm-Welt ohne bedingte Sprünge vorstellen kann.

Und die 6800 ist als Gamerkarte auf dem Markt.Unter anderem ist sie auch als Gamerkarte geeignet, ja.

[aths]

Und nochmal zum Mitschreiben: In der Praxis wird SM 3.0 schon verwendet, nur nicht in Spielen. Und zwar für Verfahren/Algorithmen und Techniken, die sicher - sobald jene Verfahren ausgereift sind - auch bald danach in Spielen Einzug nehmen werden.

Und wie oft soll ich noch die Gegenbeispiele Raycasting im Shader und Collision Detection im Shader erwähnen?... oder dass man mit WGF wahrscheinlich C auf der Grafikkarte ausführen kann? SM 3.0 ist ein Schritt dahin. SM 3.0 ist auch nützlich, um Rechenleistung gezielter einzusetzen. Dies beherrscht der NV40 im Moment zwar nur in Ansätzen – aber das ist besser als nix. Natürlich ist 3.0 nur ein Zwischenschritt hin zu WGF, aber WGF schließt ja alle 3.0-Features mit ein. Damit ist es zwangsläufig, dass "3.0-Features" genutzt werden.

Von ATI erwarte ich nichts anderes als einen Chip, der die 3.0-Spezifikation deutlich übertrifft. Vermutlich wird dann endlich die Einsicht kommen, dass 2.0 für vieles was die Graka leistungsmäßig liefern könnte, vom Featureset her doch zu begrenzt ist.

[aths]

Das ist korrekt, allerdings bringt es beim NV40 wenig bis gar nichts an performance(wegen Designschwächen der GPU).Nunja, die neuen Texturoperationen laufen praktisch außer Konkurrenz – zumindest bietet die Radeon sowas ja nicht an. Nvidia gibt in Entwickler-Unterlagen zu, dass einige neue Features recht langsam ausgeführt werden. Dafür wurden "alte" Features jetzt stark beschleunigt (bestimmte Texturoperationen die auf der FX noch langsam sind, sind auf dem NV40 sehr schnell.)

Gerade wenn es darum geht, für Pixelshader-Effekte den richtigen "LOD" zu berechnen, bietet der NV40 neue Features die das unterstützen. Bei der Radeon kann man nicht viel machen außer halt mit Pixelshader-Aliasing zu leben. Was ist nun besser: Der Zwang zum Aliasing oder die Option auf vernünftig gerenderte ("geshaderte") Materialien?

Selbst wenn NV40 noch nicht die Leistung hat, die neuen Effekte "flächendeckend" einzusetzen, so ließen sich wenigstens einige Bildteile besonders verschönern.

Xmas hatte sich mal eine Technologie-Demo überlegt, um ohne zusätzliche CPU- oder Vertexshader-Last Kachelböden mit sich abwechselnden Kacheln zu rendern. Geht mit CineFX (und damit auch mit 3.0) jedoch nicht mit 2.0. Da die Rechenleistung von GPUs schneller wächst als von CPUs ist es doch sinnvoll sich Verfahren zu überlegen, mehr Rechenlast auf die GPU zu legen. Womit heute experimentiert wird, davon profitieren wir morgen. Gäbe es kein SM 3.0 heute, müssten wir auf entsprechende Spiele noch länger warten.

[MikBach]

Was meine Praxis angeht, kann ich zwar nur einige sehr kleine OpenGL-Programme anbieten, aber das ist nicht nichts.
Das meine ich nicht. :)
Mir geht es darum, dass deine Artikel manchmal(oft) so von mir verstandenden werden, als ob diese Theorie auch in der Praxis so sein sollte. Was aber fast nie stimmt. Damit meine ich, dass du Peformance andeutest, wo sie in der Praxis(Spiele) nicht zum tragen kommt.
Vielleicht verstehe ich deine Artikel einfach nicht so, wie du sie meinst. ;)

Ja. Auf Teil 3 des NV40-Technikartikels warten. In Teil 1 steht ja schon drin, dass NV40 mit großen Quadbatches arbeitet. Es sieht so aus als ob die Entscheidung, nur einen oder doch beide Branches auszuführen nur per Batch getroffen werden kann. Nalu selbst (OpenGL hin oder her) profitiert kaum durch das Branchen.
Ja, ich warte schon gespannt darauf.

Das Geile ist halt, dass man überhaupt bedingte Sprünge verwenden kann. Frage mal einen Programmierer, ob er sich eine Programm-Welt ohne bedingte Sprünge vorstellen kann.
Nichts anderes habe ich behauptet. Klar, dass es sich mit Sprüngen für einen Programmierer viel bequemer arbeiten lässt.

Unter anderem ist sie auch als Gamerkarte geeignet, ja.
Und ich dachte das wäre das hauptsächliche(>80%) Einsatzgebiet.
"Unter anderem" versehe ich als "Nebenwirkung". ;)

[tokugawa]

Und ich dachte das wäre das hauptsächliche(>80%) Einsatzgebiet.
"Unter anderem" versehe ich als "Nebenwirkung". ;)

Vielleicht sind die Gamer die vermeintlichen "Gamer"-Karten kaufen auch nur die Schafe, mit denen die Hirten (Entwickler und Forscher) sich technische Entwicklungen und Fortschritt mittels Forschung finanzieren können? :D

Auch mal ein Blickpunkt.

Egal, NVIDIA hat jedenfalls nie "reine Gamerchips" gefertigt. Eigentlich immer waren die auf viele Einsatzgebiete angelegt (ATIs Chips eigentlich auch). Und Erstgenerationsfeatures sprechen - trotz Hype - meistens die Entwickler an, denn die sind es, die es als erstes nutzen. PR und Hype ist ja nur eine Masche, um die Spieler zum Kaufen zu animieren. Man muß PR und Hype allerdings auch etwas losgelöst von der Tatsache - dem Chip selbst - sehen. Immerhin ist PR und Hype das, was die Marketingabteilung aus einem bereits existierenden Produkt macht, und nicht umgekehrt (also nicht PR/Hype vor der Produktentwicklung, sondern erst wenn das Produkt steht, wird es medial ausgeschlachtet. Folglich werden Erstgenerationsfeatures vor allem in Anbetracht der Entwickler und auch Forscher von den Ingenieuren hinzugefügt. Dass die PR/Marketingabteilung dann versucht, daraus ein den Gamern schmackhaftes Feature zu machen, ist verständlich, sollte aber nicht überbewertet werden).

[IVN]

I know this is not truely on topic,but still really interesting.


Could it be possible to improve the speed of nv40 in UT3 engine,by exchangeing the Parallax Mapping (on PS) with Vertex texture fetch,to make the similar effect? PSs are anyway overburdened, useing the Vertex texture fetch would remove the bottleneck from the PSs and make UT3 a better balanced engine.

[aths]

Vielleicht verstehe ich deine Artikel einfach nicht so, wie du sie meinst. ;)Vielleicht wird auch nur nicht genau genug gelesen. Wenn ich z. B. in einem Artikel detailliert ausführe, warum NV40 pro Takt mehr arithmetische Instruktionen ausführen kann als R420, ist das natürlich nicht so zu verstehen, dass NV40 in jedem Benchmark besser abschneiden oder die bessere Gamerkarte darstellen müsste. In einem neuen Artikel (noch nicht veröffentlicht, arbeite ich noch dran) wird die Frage, ob lieber mehr Features oder lieber mehr Speed ebenfalls angeschnitten. Jedoch ist der NV40-Artikel auch auf einem "höheren" Niveau und setzt beim Leser den Willen voraus, ihn "richtig" zu verstehen. Dem NV40-Artikel Teil 1 ist es sogar völlig egal, welche Karte besser oder schlechter für dieses oder jenes ist. Es geht darum, wie die NV40 Pixelpipe intern ungefähr aussieht, und welche Vorteile sich daraus ergeben.

Nach meiner Auffassung hast du den Vorwurf der Theoriedominanz btw noch nicht begründet. Der NV40-Artikel nimmt kaum Bezug zu anderen Chips. Es ist kein Vergleich, welcher Chip besser sei. Was soll daran schlecht sein? Dass man daraus keine Kaufempfehlung ableiten kann? Dem Artikel geht es jedenfalls nicht ums kaufen, auch nicht um Balkenlängen, es geht um Technik. Wenn man nun fragt was man mit der schönen Theorie alles anfangen kann, Herrgott woher soll ich das wissen? Wo sich "Grundlagenforschung" auszahlt kann man immer erst hinterher sagen. Da finde ich deinen teilweise rüden Tonfall (auch in anderen Foren btw) ehrlich gesagt fehl am Platze.


Nichts anderes habe ich behauptet. Klar, dass es sich mit Sprüngen für einen Programmierer viel bequemer arbeiten lässt.Für Programmierer (und Entwickler) ist NV40 also klar der bessere Chip als R420. Wer erstellt die Spiele die wir spielen? Ein paar Monate Verspätung macht nichts, aber ATI sollte sich nicht zu lange Zeit lassen, da aufzuschließen.

Dass ATI noch immer sehr gut verkauft und einen (seltsam) hohen Börsenwert hat finde ich gut – ohne Geld keine Entwicklung. Hoffentlich machen sie was draus und das möglichst bald und möglichst gut.

Und ich dachte das wäre das hauptsächliche(>80%) Einsatzgebiet.
"Unter anderem" versehe ich als "Nebenwirkung". ;) Wie oft noch?

Hätte Nvidia z. B. den NV30 nur für das "hauptsächliche" Einsatzgebiet entwickelt, wäre die 5800 von der DX9-Leistung her der Radeon 9700 sicherlich mindestens ebenbürtig geworden. Doch die ganze Vorarbeit für SM 3.0 wäre damit aufgeschoben gewesen. NV40 jetzt wäre lange nicht auf dem Niveau, auf dem er jetzt ist.

Nach der GeForce256 gab es eine Phase der Fortschrittsarmut. NV schöpfte lieber Gewinne ab anstatt den Chip vernünftig weiterzuentwickeln. Irgendwann kam GeForce3, der mit nur geringfügigen Änderungen bis zur FX 5800 hielt. Außerdem fuhr Nvidia mit der GF4 MX auch noch die DX7-Schiene lange weiter.

So eine Entwicklung wünsche ich mir nicht zurück. Auch nicht von ATI.

NV entwickelt seit GF parallel für den professionellen Markt als auch für Gamer. Das mit den jeweils gleichen Chips. Daher verstehe ich weder deine noch tombmans Hinweise auf den zahlenmäßig großen Gamer-Anteil.

[aths]

I know this is not truely on topic,but still really interesting.


Could it be possible to improve the speed of nv40 in UT3 engine,by exchangeing the Parallax Mapping (on PS) with Vertex texture fetch,to make the similar effect? PSs are anyway overburdened, useing the Vertex texture fetch would remove the bottleneck from the PSs and make UT3 a better balanced engine.Nein. Parallax Mapping ist viel schneller als Displacement Mapping. Auch auf dem NV40. Ein Texture-Fetch im VS heißt, viele Takte Latenz, die man erst mal (mit anderen, vom Texturzugriff unabhängigen Befehlen) "verstecken" muss.

[LairD]

Wie oft noch?

Hätte Nvidia z. B. den NV30 nur für das "hauptsächliche" Einsatzgebiet entwickelt, wäre die 5800 von der DX9-Leistung her der Radeon 9700 sicherlich mindestens ebenbürtig geworden. Doch die ganze Vorarbeit für SM 3.0 wäre damit aufgeschoben gewesen. NV40 jetzt wäre lange nicht auf dem Niveau, auf dem er jetzt ist.



Hi!
Also hat nVidia bewusst die schlechte Performance der FX unter DX9 in Kauf genommen und verschenkt Marktanteile an die Konkurrenz,damit der Nachfolge-Chip mit dem nächsten Shadertyp besser läuft?

Sry aber diese Begründung warum die FX unter DX9 schlechter als die Radeon ist,ist für mich Humbug.

Kein Unternehmen verschenkt Marktanteile und bringt mit Vorsatz ein schlechteres Produkt,als die Konkurrenz auf den Markt.
Nur damit der nächste Chip supi wird.

[MadManniMan]

LairD,

nun, nV hatte zuersteinmal darauf gebaut, fp16 als Standard für DX9 zu wissen - hier wurde das größte Potential verschenkt.

Und letztendlich bot der NV3X vor allem Technik - und ward kein performanceoptimiertes Design wie der R300.

[LairD]

LairD,

nun, nV hatte zuersteinmal darauf gebaut, fp16 als Standard für DX9 zu wissen - hier wurde das größte Potential verschenkt.

Und letztendlich bot der NV3X vor allem Technik - und ward kein performanceoptimiertes Design wie der R300.

Das mag ja alles sein und das stelle ich auch nicht in Frage.
Das,von mir, zitierte Stück von aths Post hört sich aber so an,als ob nVidia die DX9 Performance locker auf R300 Niveau hätte bringen können.
Es aber nicht wollte,weil damit die Vorarbeit für NV40 und SM3.0 für die Katz gewesen wären.

Das bezweifel ich stark,denn nVidia hat durch den R300 viele Marktanteile,gerade bei den High-End Karten,verloren und kein Unternehmen verschenkt mit offenen Augen Kohle und Prestige.

[aths]

Das mag ja alles sein und das stelle ich auch nicht in Frage.
Das,von mir, zitierte Stück von aths Post hört sich aber so an,als ob nVidia die DX9 Performance locker auf R300 Niveau hätte bringen können.
Es aber nicht wollte,weil damit die Vorarbeit für NV40 und SM3.0 für die Katz gewesen wären.Ausgedrückt sollte werden (ist ja auch so im Artikel formuliert) dass entweder die supi-Features oder supi-Leistung möglich waren. ATI konnte die Geschwindigkeit nur schaffen, indem recht einfache Shadertechnik implementiert wurde. Nvidia steckte mehr in die Flexibilität bzw. in den Befehlssatz, aber opferte dafür Geschwindigkeit (bzw., ließ Designschwächen zu welche sich negativ auf die Performance auswirken.)

Mit dem NV40 hat NV die Shaderfeatures gar nicht mal sooo stark erweitert, die Kraft konnte jetzt in die Geschwindigkeitsverbesserung investiert werden.

[Pinoccio]

Seite 3, sowohl im englischen als auch auf deutsch:
" NRM
|x|. Betrag (=Länge) eines Vektors: Zunächst wird ein Faktor berechnet, in dem vom Skalarprodukt mit sich selbst der Kehrwert der Quadratwurzel genommen wird. Dann wird jede einzelne Komponente des originalen Vektors mit diesem Faktor multipliziert."


2.) Der englischen Beschreibung nach wird der Vektor normiert, dh zB aus (0,3,4) wird (0, 3/5, 4/5). Das ist etwas anderes als |x|.
Die deutsch Fassung übernimmt diesen Fehler.


Auf die Gefahhr eines Spam-Punktes hin:
Entweder jemand sagt mir jetzt mal bitte, daß ich falsch liege, oder ich hacke euren Server und ändere das selbst! :D
/edit: ich halt's im Kopf nicht aus, da redet Ihr auch sogar noch von "Normalization"!

mfg Sebastian

[Pinoccio]

*push*

wegen dem Beitrag darüber.

mfg Sebastian

[Leonidas]

Update:

Teil 2: Die Ausnutzung der NV40-Möglichkeiten
http://www.3dcenter.org/artikel/nv40_pipeline/index4.php

[RLZ]

"Die Texturformat-Konvertierungseinheiten im NVV40,"

Wieso steht bei den Shaderhochsprachen kein GLSlang dabei?
Der Compiler scheint bei NV zwar atm noch nicht so toll zu sein, aber das wird sich hoffentlich auch noch ändern...

[aths]

/edit: ich halt's im Kopf nicht aus, da redet Ihr auch sogar noch von "Normalization"!Ja muss noch gefixt werden, erklärt wird da nur das Skalarprodukt.

[aths]

"Die Texturformat-Konvertierungseinheiten im NVV40,"

Wieso steht bei den Shaderhochsprachen kein GLSlang dabei?Hätte ich mit aufzählen können, stimmt. Kommt auf die Fix-Liste :)

[catamaran]

Da wir nun HSLS (und Cg) haben,...


HSLS ???? Müsste das nicht HLSL ( HighLevelShaderLanguage ) heißen ?


Lasse mich aber gerne eines Besseren belehren. :smile:

[nino]

wieder mal ein sehr interessanter artikel, thx!

@catamaran yo, da haste imo recht

[Xmas]

Natürlich hat auch der NV40 seine Grenzen. Ein DP2ADD zum Beispiel wird in jedem Fall zwei Slots benötigen, da sowohl das DP als auch das ADD die ADD-Logik brauchen, die nur Unit 2 zur Verfügung stellt. Allerdings kann man dank der 2:2-Splitmöglichkeit zwei solcher DP2ADDs in diese beiden Slots packen, so dass eine solche Instruktion virtuell nur einen Takt benötigt ? sofern der Shader entsprechende Instruktionen beinhaltet, die mit Co-Issue kombiniert werden können
Das stimmt nicht, DP2ADD ist in einem Takt möglich, allerdings keine Vec2, sondern eine Vec3-Operation. DP2ADD ist schließlich eine vereinfachte DP3-Operation, bei der eine Z-Komponente zuvor gleich 1 gesetzt wird.

[aths]

kthx soweit, die erste Korrektur ist raus (und wird von Leo bald eingearbeitet, denke ich) und es ist absehbar, dass noch eine zweite Korrektur nötig sein wird.

[Demirug]

Das stimmt nicht, DP2ADD ist in einem Takt möglich, allerdings keine Vec2, sondern eine Vec3-Operation. DP2ADD ist schließlich eine vereinfachte DP3-Operation, bei der eine Z-Komponente zuvor gleich 1 gesetzt wird.

Eigentlich nicht.

Der ADD Teil von DP2ADD addiert einen beliegen Skalar der mit den beiden Vec2 für den DP2 Teil nichts zu tun haben muss.

[aths]

Eigentlich nicht.

Der ADD Teil von DP2ADD addiert einen beliegen Skalar der mit den beiden Vec2 für den DP2 Teil nichts zu tun haben muss.Hm, ich hab Leo gebeten, den Absatz mit DP2ADD zu streichen. Offenbar ist die genaue Realisierung unklar. So oder so kann NV40 in 2 Takten 2x DP2ADD ausführen.

[Xmas]

Eigentlich nicht.

Der ADD Teil von DP2ADD addiert einen beliegen Skalar der mit den beiden Vec2 für den DP2 Teil nichts zu tun haben muss.
Trotzdem ist es von der Abarbeitung her dieselbe Operation. Man muss natürlich dafür sorgen, dass die Crossbar-Logik die richtigen Werte im dritten Kanal zu den Einheiten schickt. Das sollte möglich sein, da man im Grunde für die Multiplikation Co-Issue nutzt und die Komponentenaddition zusammen lässt.

[Demirug]

Trotzdem ist es von der Abarbeitung her dieselbe Operation. Man muss natürlich dafür sorgen, dass die Crossbar-Logik die richtigen Werte im dritten Kanal zu den Einheiten schickt. Das sollte möglich sein, da man im Grunde für die Multiplikation Co-Issue nutzt und die Komponentenaddition zusammen lässt.

Ja, wenn man das Problem so lösen will kann man das auch so machen. Allerdings ist das nicht die einzige Lösung. Mit entsprechenden Crossbars kommt man auch mit 2 skalaren MULs und 2 skalaren ADDs aus.

Bei Rechenwerke ala 3dlabs würde ich es auf jeden Fall so machen.

[Banshee18]

Nein, ich will nicht spammen, sondern mich bei aths nur mal bedanken und ihm für diesen wieder sehr gelungenen Artikel ein Lob aussprechen. :up:
Das hat er sich redlich verdient und tut ihm sicherlich auch mal gut.

Danke, aths!!!

mfg

Banshee

[aths]

Die nächste Kolumne gibts erst, wenn der 2. Teil hier etwas mehr gelesen wird *droh* *mit den Armen fuchtel*.