Archiv verlassen und diese Seite im Standarddesign anzeigen : SM3.0 vs SM2.0/a/b
Hab letztens ne Diskussion über SM3.0 gehabt und mich mal gefragt, was mit SM3.0 effektetechnisch oder im allgemeinen möglich wäre, was mit SM2.0/a/b nicht realisierbar ist. Kann mir da jemand helfen? ;)
Crushinator
2004-12-07, 16:17:14
Prinzipiell lassen sich alle erdenklichen Effekte auch irgendwie per SM2x realisieren, die Frage dabei lautet nur in welcher Geschwindigkeit und zu welchem Aufwand für den Entwickler? Das dynamische Branching, was mit SM3 eingeführt wurde, erlaubt es (Siehe dazu Demirugs Artikel (http://www.3dcenter.de/artikel/2004/03-31_a.php)) in sehr langen Shadern u.A. dynamisch zu entscheiden, wann eine ggf. sehr aufwendige Berechnung für einen Effekt abgebrochen und die Rechenzeit für sinnvollere Dinge verbraucht werden kann. Auf dieser Weise ist es möglich einfacher mehr Effekte in Titeln zu integrieren ohne die Hardware ggf. zu überfordern.
Desweiteren gibt es beispielsweise Lichtberechnungen (http://www.forum-3dcenter.org/vbulletin/showpost.php?p=2525236&postcount=311), die mit einer geringeren Präzision als FP32 im Pixelshader (eine der Voraussetzungen für SM3) nicht mehr die gewünschten Ergebnisse liefern.
:)
Prinzipiell lassen sich alle erdenklichen Effekte auch irgendwie per SM2x realisieren,
Und wieso löschst du dann meine Antwort ? War doch dasselbe ;)
Crushinator
2004-12-07, 16:26:44
Ich löschte Deine Antwort nicht, habe jedoch Verständnis für ihre Entsorgung, denn ein einfaches "Nichts!" ist mit Sicherheit weder Technologieforumstauglich, noch hätte es den Threadstarter weitergebracht. ;)
ShadowXX
2004-12-07, 16:56:09
Prinzipiell lassen sich alle erdenklichen Effekte auch irgendwie per SM2x realisieren, die Frage dabei lautet nur in welcher Geschwindigkeit und zu welchem Aufwand für den Entwickler? Das dynamische Branching, was mit SM3 eingeführt wurde, erlaubt es (Siehe dazu Demirugs Artikel (http://www.3dcenter.de/artikel/2004/03-31_a.php)) in sehr langen Shadern u.A. dynamisch zu entscheiden, wann eine ggf. sehr aufwendige Berechnung für einen Effekt abgebrochen und die Rechenzeit für sinnvollere Dinge verbraucht werden kann. Auf dieser Weise ist es möglich einfacher mehr Effekte in Titeln zu integrieren ohne die Hardware ggf. zu überfordern.
Desweiteren gibt es beispielsweise Lichtberechnungen (http://www.forum-3dcenter.org/vbulletin/showpost.php?p=2525236&postcount=311), die mit einer geringeren Präzision als FP32 im Pixelshader (eine der Voraussetzungen für SM3) nicht mehr die gewünschten Ergebnisse liefern.
:)
Man sollte aber auch nicht vergessen, das SM3.0 nicht nur aus PS3.0 besteht....mit den VS3.0 Einheiten kann man schon sachen machen, die mit VS2.0 nun völlig unmöglich sind (z.B. hat ein VS3.0 sowas wie Textureinheiten, die man eben überhaupt nicht mit einem VS2.0 nachstellen kann)
Man sollte aber auch nicht vergessen, das SM3.0 nicht nur aus PS3.0 besteht....mit den VS3.0 Einheiten kann man schon sachen machen, die mit VS2.0 nun völlig unmöglich sind (z.B. hat ein VS3.0 sowas wie Textureinheiten, die man eben überhaupt nicht mit einem VS2.0 nachstellen kann)
Doch, das macht dann die CPU, mit dem VS kann man sowas noch machen, PS schon nicht mehr.
betasilie
2004-12-07, 17:08:41
Prinzipiell lassen sich alle erdenklichen Effekte auch irgendwie per SM2x realisieren, die Frage dabei lautet nur in welcher Geschwindigkeit und zu welchem Aufwand für den Entwickler? Das dynamische Branching, was mit SM3 eingeführt wurde, erlaubt es (Siehe dazu Demirugs Artikel (http://www.3dcenter.de/artikel/2004/03-31_a.php)) in sehr langen Shadern u.A. dynamisch zu entscheiden, wann eine ggf. sehr aufwendige Berechnung für einen Effekt abgebrochen und die Rechenzeit für sinnvollere Dinge verbraucht werden kann. Auf dieser Weise ist es möglich einfacher mehr Effekte in Titeln zu integrieren ohne die Hardware ggf. zu überfordern.
Desweiteren gibt es beispielsweise Lichtberechnungen (http://www.forum-3dcenter.org/vbulletin/showpost.php?p=2525236&postcount=311), die mit einer geringeren Präzision als FP32 im Pixelshader (eine der Voraussetzungen für SM3) nicht mehr die gewünschten Ergebnisse liefern.
:)
Die frage ist imo nun, wann SM3.0 wirklich sinnvoll wird. Also wann SM2.0b an seine Grenzen stößt, so dass SM3.0 wirklich von Nöten wäre.
Man sollte aber auch nicht vergessen, das SM3.0 nicht nur aus PS3.0 besteht....mit den VS3.0 Einheiten kann man schon sachen machen, die mit VS2.0 nun völlig unmöglich sind (z.B. hat ein VS3.0 sowas wie Textureinheiten, die man eben überhaupt nicht mit einem VS2.0 nachstellen kann)
Warum nicht?
Ein Texturzugriff ist nichts anders als für jedes Vertex zusätzliche Daten anzugeben. Die Daten kann man auch einfach als zusätzliches Vertexattribut angeben. Lässt sich genauso wie eine Textur jederzeit getrennt vom Rest an den Treiber übergeben.
Einzige Nachteile sind dabei, dass die CPU das Filtering berechnen muss und man bei Texturen, die durch R2T entstanden sind leichte Probs machen.
Na gut. Kostet auch noch mehr Platz. :D
Aber es geht ;)
Die frage ist imo nun, wann SM3.0 wirklich sinnvoll wird. Also wann SM2.0b an seine Grenzen stößt, so dass SM3.0 wirklich von Nöten wäre.
Wenn beim Branching nicht mehr >1000 Pixel immer das selbe Ergebnis haben müssen um eine Einsparung zu erzielen. :naughty:
Crushinator
2004-12-07, 17:38:37
Die frage ist imo nun, wann SM3.0 wirklich sinnvoll wird. Also wann SM2.0b an seine Grenzen stößt, so dass SM3.0 wirklich von Nöten wäre. Ja, man kann es auch so sehen. SM3 wird früher oder später allerdings von Nöten sein. Denn irgendwann muß man im Shader so branchen, weil es ansonsten einfach keinen Sinn macht sich zu Tode zu rechnen. Bei der aktuellen Hardware ist's wie man sieht noch nicht so von Nöten, weil wo es wirklich Sinn macht dynamisch zu branchen die Power möglicherweise eh' kaum ausreicht um den Shader in Echtzeit auszuführen. Aber auch da bestätigen Ausnahmen wie so oft im Leben die Regel. :)
Prinzipiell lassen sich alle erdenklichen Effekte auch irgendwie per SM2x realisieren
Falsch, die Branches im PS lassen sich nicht emulieren, falls man mehr als einen hat.
Falsch, die Branches im PS lassen sich nicht emulieren, falls man mehr als einen hat.Bestimmte Texturoperationen dürften ebenfalls schwer zu emulieren sein.
Die frage ist imo nun, wann SM3.0 wirklich sinnvoll wird. Also wann SM2.0b an seine Grenzen stößt, so dass SM3.0 wirklich von Nöten wäre.SM3 ist von Nutzen auch ohne dass man vorher an die Grenzen von SM2 stoßen muss, daher auch sinnvoll ohne dass SM2-HW bereits an seine Grenzen gelangt ist.
betasilie
2004-12-07, 18:48:18
SM3 ist von Nutzen auch ohne dass man vorher an die Grenzen von SM2 stoßen muss, daher auch sinnvoll ohne dass SM2-HW bereits an seine Grenzen gelangt ist.
Ok, das mag sein, nur sollte man nicht solange SM2.0 den Markt dominiert dort erstmal alles rausholen, um dem Großteil der Kunden möglichst ansehnliche Resultate zu liefern?
Crushinator
2004-12-07, 18:56:00
Falsch, die Branches im PS lassen sich nicht emulieren, falls man mehr als einen hat. Achso, daß Branch ein grafischer Effekt sein soll, ist mir wohl entgangen, Sry. ;)
Jesus
2004-12-07, 18:57:01
Falsch, die Branches im PS lassen sich nicht emulieren, falls man mehr als einen hat.
Doch, in gewissem Sinne auch:
http://www.humus.ca/index.php?page=3D&ID=50
LovesuckZ
2004-12-07, 19:11:41
Nichts, eigentlich braucht man keine Shadermodell, gibt naemlich die CPU. Die kann auch alles.
betasilie
2004-12-07, 19:18:30
Doch, in gewissem Sinne auch:
http://www.humus.ca/index.php?page=3D&ID=50
Ja, da sieht man mal wieder was alles möglich ist, wenn man nur will. :up:
Doch, in gewissem Sinne auch:
Man beachtet: "Falls man mehr als einen hat"
Hat die Demo mehr als einen Branch? Nein. Lesen - denken - posten.
StefanV
2004-12-07, 19:39:37
Nichts, eigentlich braucht man keine Shadermodell, gibt naemlich die CPU. Die kann auch alles.
Und was glaubst du, warum die '3DBeschleuniger' eingeführt wurden?! :|
StefanV
2004-12-07, 19:40:58
SM3 ist von Nutzen auch ohne dass man vorher an die Grenzen von SM2 stoßen muss, daher auch sinnvoll ohne dass SM2-HW bereits an seine Grenzen gelangt ist.
Könntest du das näher Erläutern, ohne die Werbetrommel für SM3 zu rühren?! :|
Denn irgendwie bringt uns der obige Teil nicht wirklich weiter...
PS: MMX war auch 1998 auf dem Pentium MMX von Nutzen...
Achso, daß Branch ein grafischer Effekt sein soll, ist mir wohl entgangen, Sry.
Nein, aber für manche "grafischen Effekte" braucht man halt Branches.
Könntest du das näher Erläutern, ohne die Werbetrommel für SM3 zu rühren?!
SM3 hat mehr Interpolatoren = mehr Lichter auf einmal möglich
Daraus resultiert jetzt schon eine bessere Performance in Far Cry.
Auch lassen sich allgemeine Swizzles verwenden, kann ebenfalls zu besserer Performance führen (geht mit nV 2.0 Karten aber auch schon)
Dann hallt das Totschlagargument Branches, das absolut nicht mit PS2.0 zu emulieren ist, wenn man es mal konsequent eingesetzt wird. Vor allem Loops kann man vergessen.
ShadowXX
2004-12-07, 19:46:53
Und was glaubst du, warum die '3DBeschleuniger' eingeführt wurden?! :|
Naja....wenn die Hälfte der Leute damit anfängt alle möglichen Szenarien aufzuzählen, was alles noch möglich ist, wenn man die CPU bei SM2.0 mit einbezieht, kann ich seinen Kommentar schon verstehen....
@RLZ
dann reallisierst du aber das ganze nicht mehr über den VS alleine....und ich glaub es ging bei der Frage mehr daru, was SM3.0 denn so alles in HW Kann......nciht arum wie man es um alle möglichen Enden und Ecken per CPU & Co. emulieren kann...
Dann stimmt nämlich die Aussage von Lovesuckz und wir brauchen gar keine PS/VS sondern machen es eben gleich alles über die CPU....
Crushinator
2004-12-07, 19:48:59
Nichts, eigentlich braucht man keine Shadermodell, gibt naemlich die CPU. Die kann auch alles. Das läßt sich IMHO nicht so vergleichen. Wenn man keinen dynamischen Branch kann, führt es nur zu Multipassrendering, was wiederum nicht unbedingt extrem viel langsamer sein muß als Singlepass, sprich der Effekt könnte in vielen Fällen immer noch in Echtzeit dargestellt werden. :)
Wenn man keinen dynamischen Branch kann, führt es nur zu Multipassrendering, was wiederum nicht unbedingt extrem viel langsamer sein muß als Singlepass
Ich wiederhole mich nur ungern, aber es gibt genügend Fälle wo dynamisches Branching nicht durch Multipass emuliert werden kann.
Crushinator
2004-12-07, 19:55:47
Nein, aber für manche "grafischen Effekte" braucht man halt Branches. (...) Wäre es möglich einen solchen Effekt und den Shader dazu zu sehen zu bekommen?
Ich wiederhole mich nur ungern, aber es gibt genügend Fälle wo dynamisches Branching nicht durch Multipass emuliert werden kann. Ich möchte auch nicht einen Branch emulieren, sondern den Effekt ohne Branch realisieren. Warum genau sollte er nicht ohne dynamischen Branch möglich sein?
betasilie
2004-12-07, 19:55:54
Ich wiederhole mich nur ungern, aber es gibt genügend Fälle wo dynamisches Branching nicht durch Multipass emuliert werden kann.
Was für Fälle? Hast Du da praktische Beispiele oder einfach nur irgendwelche rein theoretische Überlegungen.
Jopp, ein Loop dessen Durchläufe abhängig sind von einem ausgerechneten Wert. Völlig unmöglich per Multipass.
Wäre es möglich einen solchen Effekt und den Shader dazu zu sehen zu bekommen?
Displacement Mapping, das auf Distanz auf Bumpmapping umschwenkt zur beschleunigung, oder Fur das in der Entfernung approximiert wird, etc.
Aber was soll das ganze? Ohne Technologie keine Anwendung, also wird bisher auch nicht viel in diese Richtung inverstiert worden sein.
Aber es gibt definitiv Möglichkeiten SM3.0-only Effekte nicht nur theoreitsch zu erstellen. Vielleicht sollte ich mir mal was überlegen.
Crushinator
2004-12-07, 19:59:28
Jopp, ein Loop dessen Durchläufe abhängig sind von einem ausgerechneten Wert. Völlig unmöglich per Multipass. Erster Loop, Wert sichern, zweitem Loop mitgeben, dessen Werte sichern und dem nächsten mitgeben usw.
Das geht nicht, weil du auf der CPU nicht weißt wieviel Loop durchläufe es gibt und Readbacks is nich.
Desweiteren kann es ja unterschiedlich viele Loop Durchläufe per-Pixel geben.
Crushinator
2004-12-07, 20:01:01
(...) Displacement Mapping, das auf Distanz auf Bumpmapping umschwenkt zur beschleunigung, oder Fur das in der Entfernung approximiert wird, etc. Gib mir den Shader und er wird nicht aufgrund des fehlenden Branching auf SM2x Hardware laufen. ;)
Das geht nicht, weil du auf der CPU nicht weißt wieviel Loop durchläufe es gibt und Readbacks is nich. Man nehme den Humusweg und do while {Ergebnis();} dann weiß die CPU davon.
LovesuckZ
2004-12-07, 20:01:27
Das läßt sich IMHO nicht so vergleichen. Wenn man keinen dynamischen Branch kann, führt es nur zu Multipassrendering, was wiederum nicht unbedingt extrem viel langsamer sein muß als Singlepass, sprich der Effekt könnte in vielen Fällen immer noch in Echtzeit dargestellt werden. :)
Mit einer schneller CPU lassen sich gewissen "Faelle" auch in Echtzeit darstellen. ;)
Man nehme den Humusweg und [i]do while {Ergebnis();}" dann weiß die CPU davon.
Woher soll die CPU das wissen ob sie jetzt 10 oder 20 Passes abschicken muss? Man kann von der GPU auf keinen Fall zurücklesen, sonst hast du SPF und keine FPS mehr.
ib mir den Shader und er wird nicht aufgrund des fehlenden Branching auf SM2x Hardware laufen.
In einem Pass geht das auf keinen Fall auf SM2.0 und das lässt sich ja noch beliebig erweitern.
Tigerchen
2004-12-07, 20:05:31
Prinzipiell lassen sich alle erdenklichen Effekte auch irgendwie per SM2x realisieren, die Frage dabei lautet nur in welcher Geschwindigkeit und zu welchem Aufwand für den Entwickler? Das dynamische Branching, was mit SM3 eingeführt wurde, erlaubt es (Siehe dazu Demirugs Artikel (http://www.3dcenter.de/artikel/2004/03-31_a.php)) in sehr langen Shadern u.A. dynamisch zu entscheiden, wann eine ggf. sehr aufwendige Berechnung für einen Effekt abgebrochen und die Rechenzeit für sinnvollere Dinge verbraucht werden kann. Auf dieser Weise ist es möglich einfacher mehr Effekte in Titeln zu integrieren ohne die Hardware ggf. zu überfordern.
Desweiteren gibt es beispielsweise Lichtberechnungen (http://www.forum-3dcenter.org/vbulletin/showpost.php?p=2525236&postcount=311), die mit einer geringeren Präzision als FP32 im Pixelshader (eine der Voraussetzungen für SM3) nicht mehr die gewünschten Ergebnisse liefern.
:)
Reicht denn die Leistung für lange Shader + branching beim nV40 für Echtzeiteffekte?
Oder ist es da nicht eher ein Checklist-Feature und die Leistung wird dann beim GeForce7 nachgeliefert?
Nein, aber sie reicht für mittellange mit Branches, vor allem wenn sich die Branches in einem Quad nicht sehr häufig unterscheiden.
Außerdem geht es hier gerade um SM3.0-only Effekte und nicht wie schnell diese dann laufen.
Crushinator
2004-12-07, 20:08:29
Selbstverständlich kann man von der GPU zurücklesen. Ob es dabei zu SPFs kommt hängt dabei ganz davon ab was man alles zurücklesen muß. Wenn's generell dazu führen würde, daß es zu SPFs führt, dürfte eigentlich doch auch Multipassrendering meist dazu führen.
In einem Pass geht das auf keinen Fall auf SM2.0 und das lässt sich ja noch beliebig erweitern. Ich sagte auch kein Wort von einem einzigen Pass. Wir reden doch die ganze Zeit davon, ob ein Effekt durch PS2x gänzlich unrealisierbar sei oder nicht, und ich meine eben nicht. Wie aufwendig es für den Entwickler letztendlich wäre, steht natürlich auf einem anderen Blatt. ;)
LovesuckZ
2004-12-07, 20:10:42
Kann mir bitte jemand beantworten, warum MS mit den Profilen 2.a/2.b die Shaderlaenge erhoeht hat, wenn Mulipassrendering doch vollkommen ausreichend waere?
Nein, das synchronisiert brutalst die GPU und CPU und führt bei beiden zu übelsten Wartezyklen.
Vor allem weil die GPU sofort wieder wissen muss was sie machen soll. das führt definitiv zu SPF.
Vor allem bekommt man max. 500MB/s auf dem Rückkanal bei ner AGP Karte und dann stallt es noch die komplette Pipeline.
Vergiss es. Selbst normale Readbacks sind evil.
Kann mir bitte jemand beantworten, warum MS mit den Profilen 2.a/2.b die Shaderlaenge erhoeht hat, wenn Mulipassrendering doch vollkommen ausreichend waere?
Ja ist Dummfug. Durch Multipassrendering verringerst du den Transformationsdurchsatz um das n-fache (n Passes) und zusätzlich beanspruchst du Füllrate und Speichebandbreite.
StefanV
2004-12-07, 20:12:29
Reicht denn die Leistung für lange Shader + branching beim nV40 für Echtzeiteffekte?
Oder ist es da nicht eher ein Checklist-Feature und die Leistung wird dann beim GeForce7 nachgeliefert?
Eher letzteres...
Zumal das Branching auf dem nV40 ziemlich lahm ist...
Die aktuellen sind alle nicht wirklich für lange Shader geeignet...
http://www.ati.com/developer/dx9/ATI-DX9_Optimization.pdf
Seite 7 / 3.2
In general it is a bad idea to read back from the buffers allocated in D3DPOOL_DEFAULT memory pool, because reads from AGP and especially video memory are slow.
Falls das jemand mit den Readbacks anzweifeln sollte.
Crushinator
2004-12-07, 20:20:42
(...) Ja ist Dummfug. Durch Multipassrendering verringerst du den Transformationsdurchsatz um das n-fache (n Passes) und zusätzlich beanspruchst du Füllrate und Speichebandbreite. Leider gilt dieser Dummfug eben nicht in allen Fällen, schon gar nicht wenn es um sehr komplexe Shader geht, denn die sind ohnehin schon allesfressend. Wo ist der Unterschied zwischen einem solchen Shader wobei die Hardware aus der Puste kommt und mehreren kleineren, die möglicherweise selbiges oder weniger schlimmes bewirken? Es muß dafür ja nicht zwingend pro Shader 500 MB über den Rückkanal zurückfließen.
[url] (...) Falls das jemand mit den Readbacks anzweifeln sollte. Ich wollte keinen großen Buffer zurücklesen sondern nur das Ergebnis eines Loops bzw. kleine Variablen, die mir ermöglichen könnten zu entscheiden wie oft noch was geloopt werden soll.
Du verstehst es einfach nicht. Ein VRAM Readback stallt die Parallelität zwischen GPU und CPU, das vernichtet deine Performance auch schon bei einem Pixel readback pro Frame, vor allem wenn weitere Berechnungen der GPU davon abhängen.
Wo ist der Unterschied zwischen einem solchen Shader wobei die Hardware aus der Puste kommt und mehreren kleineren, die möglicherweise selbiges oder weniger schlimmes bewirken?
Weil die Geometrieleistung eben beim langen Shader nur einmal verbraucht wird? 1+1+1 > 1? Was ist daran jetzt schwer zu verstehen?
Eher letzteres...
Zumal das Branching auf dem nV40 ziemlich lahm ist...
Die aktuellen sind alle nicht wirklich für lange Shader geeignet...
Nv 40 is really good for long shaders.There is an effect called scene
raytrace (in nvidia's SDK) , it has 300+ instructions in real time. ;)
Ok, das mag sein, nur sollte man nicht solange SM2.0 den Markt dominiert dort erstmal alles rausholen, um dem Großteil der Kunden möglichst ansehnliche Resultate zu liefern?Angenommen, für SM3 würde FP24 noch ausreichen, und R420 hätte ansonsten die SM3-Features (clockwise) in NV40-Performance integriert. Dann könnte man viele Effekte schneller rechnen.
NV40 bietet weniger Takt, aber pro Pipe mehr Recheneinheiten und mehr Effizienz (insbesondere für lange Shader.) R420 mit "SM3-Effizienz" wäre schneller als der R420 mit "SM2-Effizienz" ist. Je mehr sich SM3+ mit der Zeit durchsetzen wird, desto mehr wird aus jedem Transistor rausgeholt. Außerdem bietet SM3 dank neuer Freiheiten die Möglichkeit, ohne Rohleistungssteigerung neue Effekte in Echtzeit zu rendern. Allerdings geht dies Hand in Hand mit der Integration dedizierter "HDR-Units" (nenn ich mal so).
SM3 ist mehr als dynamic branching im Pixelshader. SM3 erfordert eine lange Liste an Features, und vernünftige SM3-HW (wozu ich die 6200 also nicht zähle) hat außerdem FP-Alphablender und FP-Texturfilter. (Richtig gute SM3-HW sollte außerdem TMUs mit Texturfilter im Vertexshader anbieten, mindestens trilinear.)
Natürlich werden Entwickler bei aktuellen Titeln eher darum bemüht sein, die SM2-Möglichkeiten auszureizen, weil es da eine breite Palette gibt. In Rücksichtnahme auf die GeForce FX muss sogar das SM1 hin und wieder bemüht werden. Doch nur weil es bei HL2 mit DX8-Karten möglich ist, fast genau so gute Grafik zu rendern wie mit DX9-Karten werden ja die DX9-Karten deswegen nicht sinnlos. Schon deshalb weil man mit DX9-HW DX8-Effekte effizienter rendern kann – mit Ausnahme der kompletten GeForce-FX-Reihe, allerdings.
Daraus sehen wir, dass es nicht nur darauf ankommt, welches Shader Model genutzt wird. Reizt man jetzt SM2 voll aus, deckt man nur ATI-Grakas ab 9500 ab.
Ehe sich SM3-fähige HW breit durchgesetzt haben wird, das dauert noch lange. Wenn bis dahin keiner anfängt, richtig was in SM3 zu machen, wirst auch du mit deiner zukünftigen SM3+-HW fluchen.
ShadowXX
2004-12-07, 20:27:16
Ich glaube, wir sollten mal damit anfangen, darüber zu reden, was man alles mit SM2.0 nachstelle kann, wenn man nicht noch zusätzlich die CPU benutzt.
Denn darum gehts eigentlich....
Crushinator
2004-12-07, 20:28:56
(...) Weil die Geometrieleistung eben beim langen Shader nur einmal verbraucht wird? 1+1+1 > 1? Was ist daran jetzt schwer zu verstehen? Also nochmal: Es gibt zig Titeln da draußen, wo Mulipass Verwendung darin findet. Laufen sie alle deswegen nicht mehr in Echtzeit? Ich glaube langsam, Du möchtest mich nicht verstehen. ;)
Ja, vor allem weil die CPU auf keinen Fall in Frage kommt wie ich schon mehrfach erwähnt habe. Auch sämtliche Optimierungsguides von allen IHVs sagt das gleiche aus.
Also nochmal: Es gibt zig Titeln da draußen, wo Mulipass Verwendung darin findet. Laufen sie alle deswegen nicht mehr in Echtzeit? Ich glaube langsam, Du möchtest mich nicht verstehen.
Ich sage nur das Singlepass immer langsamer ist.
Und hör endlich auf Sache zu erdichten von denen du anscheinend nichts verstehst.
Ach ja: Meine Posts sind nicht pro-nVidia sondern anti-Falschaussagen, nur dass das klargestellt ist.
Crushinator
2004-12-07, 20:32:38
(...) Ich sage nur das Singlepass immer langsamer ist. ...und ich sage, es kommt auf den Shader an. Beim dynamischen Branching kann die dadurch entstandene Verzögerung (weil ein Branch technisch immer nur suboptimal ist) dafür sorgen, daß Multipass auf anderer Hardware trotzdem gleich schnell wäre.
Und hör endlich auf Sache zu erdichten von denen du anscheinend nichts verstehst. Warum denn so energisch? Ob ich davon was verstehe oder nicht steht hier weder zur Diskussion, noch kannst Du Deine felsenfesten Behauptungen, daß es so sei nicht in der Praxis erbringen.
Selbst wenn NV40 immer den ersten Zweig nehmen würde (keine Branch Prediction, was ich nicht glaube) wäre er in 50% der Fälle optimal. (...) Klar, man sieht's ja auch am Humus-Beispiel. *hint* ;)
Wie dem auch sei, danke daß ich Deine Zeit so in Anspruch nehmen durfte, EOD.
...und ich sage, es kommt auf den Shader an. Beim dynamischen Branching kann die dadurch entstandenen Verzögerung (weil ein Branch technisch immer nur suboptimal ist) dafür sorgen, daß Multipass auf anderer Hardware trotzdem gleich schnell wäre.
Selbst wenn NV40 immer den ersten Zweig nehmen würde (keine Branch Prediction, was ich nicht glaube) wäre er in 50% der Fälle optimal.
Desweiteren sparst du dir mindestens einen kompletten framebuffer read und write, das macht sicherlich nen Unterschied.
Jesus
2004-12-07, 20:59:44
Desweiteren sparst du dir mindestens einen kompletten framebuffer read und write, das macht sicherlich nen Unterschied.
Könnte man ja mal testen, lt. Humus solls mit Mulitpass ja teilw. schneller sein als durch ne Verzweigung im Shader, geht natürlich nur wenn man nur eine hat(richtig? ).
Andererseits wieviele Instruktionen pro Shader brächte man überhaupt damit sich mehr als ein Branch, geschweige denn ein Loop überhaupt lohnt?
Nv 40 is really good for long shaders.There is an effect called scene
raytrace (in nvidia's SDK) , it has 300+ instructions in real time. ;)
iirc Demirug said nv40 still had some problems with long shaders (and 300 is still within the 2.0b instruction limit;) )
(and 300 is still within the 2.0b instruction limit;) )
But this effect uses dynamic branches.So,bye,bye ATI. :naughty:
R 420 would probably die calculating so many instructions.
Crushinator
2004-12-07, 21:12:12
(...) R420 would probably die calculating so many instructions. ...probably not, if you could realise that effect splitting them into separate shaders and multipass them.
Jesus
2004-12-07, 21:18:51
btw nur mal theoretisch, wäre es nicht denkbar selbst loops zu simulieren. Der Compiler müsste sowas doch theoretisch selbst korrekt erzeugen können wenn er nur schlau genug wäre (und bspw. den F-Buffer nutzen um Zwischenergebnisses zu speichern) ?
btw nur mal theoretisch, wäre es nicht denkbar selbst loops zu simulieren. Der Compiler müsste sowas doch theoretisch selbst korrekt erzeugen können wenn er nur schlau genug wäre (und bspw. den F-Buffer nutzen um Zwischenergebnisses zu speichern) ?
Nein, weil die CPU von dem Ergebniss wissen müsste, weil die Grafikkarte einfach nicht dynamisch vergleichen kann.
Das hat auch nix mit dem Instruction Limit oder ähnlichem zu tun.
Und ich bezweifle mal ganz stark das sich das Raytracing Demo splitten lässt. (da wäre die sogar Geometrieperformance mal nebensächlich)
Könnte man ja mal testen, lt. Humus solls mit Mulitpass ja teilw. schneller sein als durch ne Verzweigung im Shader, geht natürlich nur wenn man nur eine hat(richtig? ).
Schneller als was? Es gibt ja keinen Vergleich weil es eben keinen SM3.0 R420 gibt. Auf NV40 läuft das Demo ziemlich lahm btw, da wären die Shader wohl deutlich schneller.
Jesus
2004-12-07, 21:31:39
Nein, weil die CPU von dem Ergebniss wissen müsste, weil die Grafikkarte einfach nicht dynamisch vergleichen kann.
Das hat auch nix mit dem Instruction Limit oder ähnlichem zu tun.
Und wenn mans so macht wie Humus, zumindest für bestimmte Fälle (oder die meisten ? ;) ) bei denen Pixel im Alphatest (oder Stencil) verworfen werden können ?
/Edit: LOL (google: "humus ati loop")
No f-buffer yet, but the compiler is very informative. "Loop contructs is not yet implemented" is what you get back if there's a loop construct. The link results also includes stuff like "this shader will run in hardware" alternatively "this shader will run in software".
Demirug
2004-12-07, 21:33:23
Schneller als was? Es gibt ja keinen Vergleich weil es eben keinen SM3.0 R420 gibt. Auf NV40 läuft das Demo ziemlich lahm btw, da wären die Shader wohl deutlich schneller.
Das sie auf dem NV40 so lahm ist liegt daran das aufgrund der Art wie es programmiert wurde auf diesem das Fast Stencil Cull nicht funktioniert.
Naja, man könnte ja den Alpha- oder Stencilbuffer im Moment auch für was anderes gebrauchen können und PS sind nunmal generisch.
Entweder sie tun immer oder gar nicht.
Der Humus Fall ist bei weitem nicht immer anwendbar, gerade aus diesem Grund.
Das sie auf dem NV40 so lahm ist liegt daran das aufgrund der Art wie es programmiert wurde auf diesem das Fast Stencil Cull nicht funktioniert.
Glaubst du oder weißt du ob es wenn es richtig implementiert wäre schneller als ein Shader Branch ist?
No f-buffer yet, but the compiler is very informative. "Loop contructs is not yet implemented" is what you get back if there's a loop construct. The link results also includes stuff like "this shader will run in hardware" alternatively "this shader will run in software".
Der F-Buffer erweitert das Instruction Limit. Der HW fehlt eine Einheit um dynamisch zu vergleichen, da bringt auch ein F-Buffer nix.
Jesus
2004-12-07, 21:37:58
Der F-Buffer erweitert das Instruction Limit. Der HW fehlt eine Einheit um dynamisch zu vergleichen, da bringt auch ein F-Buffer nix.
Eh und wie erzeugt man dann einen Loop (Befehl?) der dann vom Compiler erkannt wird mit der entsprechenden Fehlermeldung (not yet implemented), wenn das gar nicht möglich ist?
Btw. der F-Buffer erweiter das Instruktoin limit nicht. Er ist nur eine verbesserte schnellere Multipass Methode (speichert alle Pixel unabhängig von Farbe ,Reihenfolge o.ä... afaik ;) )
Demirug
2004-12-07, 21:39:11
Und wenn mans so macht wie Humus, zumindest für bestimmte Fälle (oder die meisten ? ;) ) bei denen Pixel im Alphatest (oder Stencil) verworfen werden können ?
Eines der Probleme bei einer solchen Lösung ist das man sowas einen Effektframework recht schwer beibringen kann. Ein anderes ist das bei mehr als einen IF die sache Langsam kompliziert wird. Vorallem wenn diese dann noch dependet sind. Shader sollen das Leben ja einfacher machen.
Jesus
2004-12-07, 21:41:43
Eines der Probleme bei einer solchen Lösung ist das man sowas einen Effektframework recht schwer beibringen kann. Ein anderes ist das bei mehr als einen IF die sache Langsam kompliziert wird. Vorallem wenn diese dann noch dependet sind. Shader sollen das Leben ja einfacher machen.
Daher meine ich ja, man könnte sowas doch dem Compiler beibringen, zumindest in vereinfachter Form. Neuen Loop Befehl oder was auch immer (Extension ? )
Eh und wie erzeugt man dann einen Loop (Befehl?) der dann vom Compiler erkannt wird mit der entsprechenden Fehlermeldung (not yet implemented), wenn das gar nicht möglich ist?
ATi meint wohl spätere HW.
Btw. der F-Buffer erweiter das Instruktoin limit nicht. Er ist nur eine verbesserte schnelere Multipass Methode (Speicher alle Pixel unabhängig von Farbe ,Reihenfolge o.ä... afaik )
So, dann erklär mir jetzt mal wie ein F-Buffer eine dynamische Branchunit ersetzen soll?
Eine statische seh ich ja noch ein, aber darum geht's ja gar nicht.
Demirug
2004-12-07, 21:42:50
Eh und wie erzeugt man dann einen Loop (Befehl?) der dann vom Compiler erkannt wird mit der entsprechenden Fehlermeldung (not yet implemented), wenn das gar nicht möglich ist?
Btw. der F-Buffer erweiter das Instruktoin limit nicht. Er ist nur eine verbesserte schnelere Multipass Methode (Speicher alle Pixel unabhängig von Farbe ,Reihenfolge o.ä... afaik ;) )
Es gibt auch Loops mit einer statischen Anzahl von Durchläufen.
Die Aufgabe des F-Buffers ist es Shader auszuführen die über das Resourcenlimit der Shader Hardware gehen. Wie das Abläuft kann man zum Teil mit Rendermonkey sehen weil dort ein Shaderssplitter eingebaut ist.
Jesus
2004-12-07, 21:45:07
ATi meint wohl spätere HW.
So, dann erklär mir jetzt mal wie ein F-Buffer eine dynamische Branchunit ersetzen soll?
Eine statische seh ich ja noch ein, aber darum geht's ja gar nicht.
Bsp (ich hab noch nie PS programmiert ;) ):
Irgendwas machen->Ergebnis zwischenspeichern (f-Buffer)->wieder irgendwas machen mit neuem Ergebnis in selbem Shader = Loop. Oder nicht ? ;)
Edit: Abbruch irgendwie mit Alphatest ;)
Demirug
2004-12-07, 21:47:48
Daher meine ich ja, man könnte sowas doch dem Compiler beibringen, zumindest in vereinfachter Form. Neuen Loop Befehl oder was auch immer (Extension ? )
Nichts da. Entweder es wird automatisch aus der Hochsprache erzeugt oder es wird nicht angenommen. Wie gesagt will man sich mit den Shadern das Leben einfacher und nicht schwerer machen.
Zum Teil könnte man solche Sachen natürlich automatisch zerlegen. Das Problem ist aber das der Stencilbuffer eine Resource ist welche nicht der Shadereinheit untersteht. Wenn man also den Stencilbuffer anderweitig braucht war es das.
Demirug
2004-12-07, 21:50:15
Glaubst du oder weißt du ob es wenn es richtig implementiert wäre schneller als ein Shader Branch ist?
Keine Ahnung aber bei nVidia müsste man ja einen Shader schreiben welcher alle Lichtquellen in einem Pass rendert.
Demirug
2004-12-07, 21:52:52
Bsp (ich hab noch nie PS programmiert ;) ):
Irgendwas machen->Ergebnis zwischenspeichern (f-Buffer)->wieder irgendwas machen mit neuem Ergebnis in selbem Shader = Loop. Oder nicht ? ;)
Nein F-Buffer funktioniert anders.
Die ergebnisse welche in den F-Buffer geschrieben werden benutzt dann ein weiterer Shader in einem nachfolgenden Pass.
Der Vorteil des F-Buffers ist nur das man sich um das zerlegen nicht kümmern muss und es nach aussen hin so aussieht als würde alles mit einem Shader gerendert werden.
Jesus
2004-12-07, 21:57:42
Nein F-Buffer funktioniert anders.
Die ergebnisse welche in den F-Buffer geschrieben werden benutzt dann ein weiterer Shader in einem nachfolgenden Pass.
Der Vorteil des F-Buffers ist nur das man sich um das zerlegen nicht kümmern muss und es nach aussen hin so aussieht als würde alles mit einem Shader gerendert werden.
hm, also doch Instruction limit erweitern ? Irgendwo hab ich mal gelesen das ATI genau das nicht mit dem F-Buffer erreichen will, sondern eine vereinfachte Multipassmethode erreichen will , glaube das war sogar von nem ATI Typen.
Es lebe google :)
At this point, we will not use the F-Buffer to expose new features on R3xx. We will expose the F-Buffer directly to the applications so that they can use it any way they see fit (in OGL), such as easier multi-pass. But we won't increase D3D instruction count using F-Buffer.
LovesuckZ
2004-12-07, 22:01:16
iirc Demirug said nv40 still had some problems with long shaders (and 300 is still within the 2.0b instruction limit;) )
Link, zum Zitat.
Ich habe nur in Errinnerung, dass der Compiler probleme mit laengen Shadern habe.
Wobei, wenn man einen deutlichen Leistungssprung (imo über 50%) im Shadermark2.1 beim dynamic Branching Test gegenüber dem ohne sieht, koennen die Probleme nicht so schlimm sein (wenn ein vernuenftiges Profil verwendet werde).
Demirug
2004-12-07, 22:02:26
hm, also doch Instruction limit erweitern ? Irgendwo hab ich mal gelesen das ATI genau das nicht mit dem F-Buffer erreichen will, sondern eine vereinfachte Multipassmethode erreichen will , glaube das war sogar von nem ATI Typen.
Es lebe google :)
Wann nimmt man Multipass? Wenn die Resourcen (Instruction Limit) nicht reichen. Wenn also irgendwas Multipass unsichtbar für die Anwendung macht dann wird aus der Sicht der Anwendung automatisch das Instruction Limit erhöht.
Mehr zum F-Buffer gibt es dort: http://graphics.stanford.edu/projects/shading/pubs/hwws2001-fbuffer/
Ist nämlich keine ATI erfindung.
Jesus
2004-12-07, 22:06:08
Mehr zum F-Buffer gibt es dort: http://graphics.stanford.edu/projects/shading/pubs/hwws2001-fbuffer/
Ist nämlich keine ATI erfindung.
Danke, aber den kannte ich schon (hab ich hier auch schonmal gepostet, nur noch nicht gelesen :) )
also man kann mit CG auch if/for Statements auseinandernehmen lassen. das geht aber nur wenn man zur Compilezeit weiß wie die Vergleiche aussehen. Zur Runetime lässt sich da echt wenig machen, es sei denn man hat PS3.0.
Demirug
2004-12-07, 22:28:44
also man kann mit CG auch if/for Statements auseinandernehmen lassen. das geht aber nur wenn man zur Compilezeit weiß wie die Vergleiche aussehen. Zur Runetime lässt sich da echt wenig machen, es sei denn man hat PS3.0.
Solche statischen Branches kann auch der MS Compiler aus dem DX SDK ausrollen. Valve hat das ja zum Beispiel bei der Source Engine genutzt um aus wenigen HLSL Shadern viele hundert shader zu erzeugen.
Nein F-Buffer funktioniert anders.
Die ergebnisse welche in den F-Buffer geschrieben werden benutzt dann ein weiterer Shader in einem nachfolgenden Pass.
Der Vorteil des F-Buffers ist nur das man sich um das zerlegen nicht kümmern muss und es nach aussen hin so aussieht als würde alles mit einem Shader gerendert werden.Somit kann man auch das Abhängigkeitslimit von 4 Ebenen umgehen?
Nv 40 is really good for long shaders.There is an effect called scene
raytrace (in nvidia's SDK) , it has 300+ instructions in real time. ;)At least, NV40 is the best "consumer GPU" for long shaders, not only in execution speed but in precision also.
At least, NV40 is the best "consumer GPU" for long shaders, not only in execution speed but in precision also.
You don't say? I really didn't know that. :ulol: *irony*
betasilie
2004-12-08, 03:25:27
Angenommen, für SM3 würde FP24 noch ausreichen, und R420 hätte ansonsten die SM3-Features (clockwise) in NV40-Performance integriert. Dann könnte man viele Effekte schneller rechnen.
NV40 bietet weniger Takt, aber pro Pipe mehr Recheneinheiten und mehr Effizienz (insbesondere für lange Shader.) R420 mit "SM3-Effizienz" wäre schneller als der R420 mit "SM2-Effizienz" ist. Je mehr sich SM3+ mit der Zeit durchsetzen wird, desto mehr wird aus jedem Transistor rausgeholt. Außerdem bietet SM3 dank neuer Freiheiten die Möglichkeit, ohne Rohleistungssteigerung neue Effekte in Echtzeit zu rendern. Allerdings geht dies Hand in Hand mit der Integration dedizierter "HDR-Units" (nenn ich mal so).
SM3 ist mehr als dynamic branching im Pixelshader. SM3 erfordert eine lange Liste an Features, und vernünftige SM3-HW (wozu ich die 6200 also nicht zähle) hat außerdem FP-Alphablender und FP-Texturfilter. (Richtig gute SM3-HW sollte außerdem TMUs mit Texturfilter im Vertexshader anbieten, mindestens trilinear.)
Natürlich werden Entwickler bei aktuellen Titeln eher darum bemüht sein, die SM2-Möglichkeiten auszureizen, weil es da eine breite Palette gibt. In Rücksichtnahme auf die GeForce FX muss sogar das SM1 hin und wieder bemüht werden. Doch nur weil es bei HL2 mit DX8-Karten möglich ist, fast genau so gute Grafik zu rendern wie mit DX9-Karten werden ja die DX9-Karten deswegen nicht sinnlos. Schon deshalb weil man mit DX9-HW DX8-Effekte effizienter rendern kann – mit Ausnahme der kompletten GeForce-FX-Reihe, allerdings.
Daraus sehen wir, dass es nicht nur darauf ankommt, welches Shader Model genutzt wird. Reizt man jetzt SM2 voll aus, deckt man nur ATI-Grakas ab 9500 ab.
Ehe sich SM3-fähige HW breit durchgesetzt haben wird, das dauert noch lange. Wenn bis dahin keiner anfängt, richtig was in SM3 zu machen, wirst auch du mit deiner zukünftigen SM3+-HW fluchen.
Ein gutes Posting. :) So mag ich es, wenn Du von Sm3.0 schwärmst. :up: Weniger, wenn du nicht wenigstens ein bischen auf den zeitlichen Faktor eingehst.
Sm3.0 oder + werden sicherlich wieder einen Sprung in den grafischen Mölichkeiten darstellen, jedenfalls für das achtsame Auge, nur mag ich es nicht, wenn man verschweigt, wie lange es noch dauert, bis man die Vorzüge von SM3.0 in modernen Titeln, als echte SM3.0 Effekte zu sehen bekommen wird. Mit dem NV40 wird das jedenfalls nicht der Fall sein, einmal wegen der relativ schlechten Performance des NV40 und zum anderem wegen der Verbreitung von SM3.0 Hardware.
betasilie
2004-12-08, 03:35:57
hm, also doch Instruction limit erweitern ? Irgendwo hab ich mal gelesen das ATI genau das nicht mit dem F-Buffer erreichen will, sondern eine vereinfachte Multipassmethode erreichen will , glaube das war sogar von nem ATI Typen.
Nun, Multipass wird ja bei den Shadern erst angewendet, wenn es nicht mehr passt, von daher .... ;)
Aber da sin dwir auch beim Sinn von F-Buffer und SM3.0 Hardware für die nächsten 12 Moante. Was meint ihr wieviele Spiele wirklich zwingend darauf angewiesen sind das SM2_b zu überschreiten. :naughty:
Demirug
2004-12-08, 06:26:26
Somit kann man auch das Abhängigkeitslimit von 4 Ebenen umgehen?
Natürlich. Ich habe ja schon vor langer Zeit auch einen Post geschrieben wie man mit einem F-Buffer PS 3.0 implementieren könnte.
Demirug
2004-12-08, 06:30:22
Nun, Multipass wird ja bei den Shadern erst angewendet, wenn es nicht mehr passt, von daher .... ;)
Aber da sin dwir auch beim Sinn von F-Buffer und SM3.0 Hardware für die nächsten 12 Moante. Was meint ihr wieviele Spiele wirklich zwingend darauf angewiesen sind das SM2_b zu überschreiten. :naughty:
Ich erweitere die Frage indem ich sie auf SM2.0 begrenze. Man könnte wohl sogar noch auf SM1 herunter gehen.
IMHO ist die interesante eher wie viele Spiele werden optional Dinge nutzen die über 2B hinaus gehen? Für die Vorhersage das auch weiterhin technologische Althardware unterstützt wird braucht man noch nicht mal eine Kristalkugel.
Ein gutes Posting. :) So mag ich es, wenn Du von Sm3.0 schwärmst. :up: Weniger, wenn du nicht wenigstens ein bischen auf den zeitlichen Faktor eingehst.
Sm3.0 oder + werden sicherlich wieder einen Sprung in den grafischen Mölichkeiten darstellen, jedenfalls für das achtsame Auge, nur mag ich es nicht, wenn man verschweigt, wie lange es noch dauert, bis man die Vorzüge von SM3.0 in modernen Titeln, als echte SM3.0 Effekte zu sehen bekommen wird. Mit dem NV40 wird das jedenfalls nicht der Fall sein, einmal wegen der relativ schlechten Performance des NV40 und zum anderem wegen der Verbreitung von SM3.0 Hardware.
Danke dann ATI für ihre technische Bremsleistung in Bezug auf SM3 Hardware Verbreitung. Das eine 6200 nicht der Abräumer in Bezug auf SM3 wird ist klar, nur wird er wahrscheinlich mal wieder genau dafür zerissen werden. Dafür sorgt sie für eine hoffentlich rasche SM3 Verbreitung. Kauf dir lieber eine Nvidia Karte und du wirst SM3-only Effekte eher zu sehen kriegen.
Wie lange es noch dauert weiss keiner. Ist rein eine Geldfrage imho.
Danke dann ATI für ihre technische Bremsleistung in Bezug auf SM3 Hardware Verbreitung. Das eine 6200 nicht der Abräumer in Bezug auf SM3 wird ist klar, nur wird er wahrscheinlich mal wieder genau dafür zerissen werden. Dafür sorgt sie für eine hoffentlich rasche SM3 Verbreitung. Kauf dir lieber eine Nvidia Karte und du wirst SM3-only Effekte eher zu sehen kriegen.
Wie lange es noch dauert weiss keiner. Ist rein eine Geldfrage imho.
Ich glaube einige peilen es einfach nicht.
Ist zwar schön, daß Nvidia SM3 anbietet, weil die Entwickler jetzt schon damit experimentieren können. Füe den Kunden wird aber noch mindestens ein Jahr vergehen, bis SM3 für ihn interessant ist. Was nutzen mir tollsten Features, wenn die Hardware zu langsam ist, um diese in ansprechender Geschwindigkeit auszuführen. Siehe PF. Eine Analogie zu FX-Serie sehe ich hier auch. Super Features verglichen mit der R3x0 Serie, das Problem ist halt nur, dass die FX-Serie von diesen Features nicht profitieren kann, weil ihr schon viel früher die Puste ausgeht.
Das ist beim NV40 und SM3 genauso.
Asmodeus
2004-12-08, 10:37:50
Ich, aus meiner Programmiersicht, wäre froh, wenn dynamisches Verzweigen endlich treiberseitig von Nvidia unterstützt würde. Denn es gibt sehr wohl Fälle, bei denen durch die Fähigkeit des dynamischen Branchens ein Geschwindigkeitsvorteil gegenüber jeder anderen Variante erziehlt wird.
Beispiel aus meinen Shadern:
Ein Blatt eines Baumes besteht aus einigen Dreiecken. Typisch für ein Blatt ist nunmal, dass sowohl Vorder- als auch Rückseite sichtbar sein können. Würde man die Vorder- und Rückseite mit jeweils eigenen Dreiecken modellieren würde sich die Dreiecksanzahl verdoppeln, also unpraktikabel. Also muss ich im Shader abtesten, ob das aktuelle Fragment gerade zur Vorderseite oder zur Rückseite des Blattes gehört, da sich abhängig davon das Beleuchtungsmodell ändert. Ausserdem kann sich natürlich ständig ändern, welche Seite des Blattes die Vorder- und welches die Rückseite ist. Denn das bestimmt wieder der Betrachterstandpunkt in Relation zur Lichtquelle.
Und sollte dynamisches Verzweigen funktionieren, hätte man einen Branch für die Vorderseitenberechnung, und einen für die Rückseitenberechnung. Und alle anderen Möglichkeiten, das nachzubilden, sind auf jeden Fall langsamer.
Gruss, Carsten.
Und alle anderen Möglichkeiten, das nachzubilden, sind auf jeden Fall langsamer.
Gruss, Carsten.
glaube ich nicht.
Asmodeus
2004-12-08, 10:55:04
glaube ich nicht.
Sagen wir so, ich hab da ziemlich lang dran gesessen und keine der getesteten anderen Varianten war schneller. Im Grunde sieht es jetzt so aus, auf ATI Karten werden halt immer beide Branches abgearbeitet, und auf Nvidia Karten ab NV40 sollte, sobald es der OGL-Treiber unterstützt dann wirklich nur der jeweilige Branch abgearbeitet werden.
Gruss, Carsten.
Eine Analogie zu FX-Serie sehe ich hier auch. Super Features verglichen mit der R3x0 Serie, das Problem ist halt nur, dass die FX-Serie von diesen Features nicht profitieren kann, weil ihr schon viel früher die Puste ausgeht.
Das ist beim NV40 und SM3 genauso.Bestimmte SM3-Features, die über SM2 Profil 2_B hinaus gehen, sind auf dem NV40 sehr performant umgesetzt.
marlurau
2004-12-08, 12:40:14
Ich erweitere die Frage indem ich sie auf SM2.0 begrenze. Man könnte wohl sogar noch auf SM1 herunter gehen.
IMHO ist die interesante eher wie viele Spiele werden optional Dinge nutzen die über 2B hinaus gehen? Für die Vorhersage das auch weiterhin technologische Althardware unterstützt wird braucht man noch nicht mal eine Kristalkugel.
Wenn ich das recht verstehe , heißt dies doch im Umkehrschluß: Manche "sammeln " Fähigkeiten ihrer GPU an(durch den Kauf ), die erst in JAHREN richtig nutzbar sind. Das ist ja wie bei Eichhörnchen ;) , bloß die kümmert ja der nächste Winter.
Der VORteil , den uns die Werbung verspricht,besteht also zu 99,5 % in unserer Phantasie. Die eigentliche WIRKUNG besteht dann darin,daß die große Mehrheit der Grakabesitzer das GEFÜHL der miesen ,alten Graka vermittelt wird.
Diese kaufen irgendwann was neues. DANN endlich wird die neue GPU- Fähigkeit in WIRKLICHKEIT genutzt und gebraucht !!
Die ERST-und Technikkäufer sind also zugleich "unbezahlte HELFER" der Hersteller und zahlen HÖHERE Preise als in 14 Monaten !! Schließlich bilden sie die unbezahlten "Tester " der neuen Technik/ Shader usw.
SIE leisten den Großteil der "Arbeit des Veralterungsdruckes", bewegen andere zum Nachkauf usw. !
Erstaunlich: Keinerlei echte Belohnung dieser Arbeit durch die GPU- Hersteller !! Meisterhafte psychologische und religiöse Vorgehensweise der an den Geldscheinen interessierten Akteure der Herstellerwerke.
Die ERST-und Technikkäufer sind also zugleich "unbezahlte HELFER" der Hersteller und zahlen HÖHERE Preise als in 14 Monaten !! Schließlich bilden sie die unbezahlten "Tester " der neuen Technik/ Shader usw.
SIE leisten den Großteil der "Arbeit des Veralterungsdruckes", bewegen andere zum Nachkauf usw. !
Erstaunlich: Keinerlei echte Belohnung dieser Arbeit durch die GPU- Hersteller !! Meisterhafte psychologische und religiöse Vorgehensweise der an den Geldscheinen interessierten Akteure der Herstellerwerke.Begeisterte adaptieren früh. Das sieht die Marketing-Forschung ganz emotionslos. Zahlen muss schließlich jeder.
Crushinator
2004-12-08, 12:49:43
Bestimmte SM3-Features, die über SM2 Profil 2_B hinaus gehen, sind auf dem NV40 sehr performant umgesetzt. :up:
Dem ist nicht viel hinzuzufügen, außer daß performant in diesem Zusammenhang nicht relativiert werden kann, weil es z.Z. mangels anderer Hardware keine direkte Vergleichsmöglichkeit gibt.
Also fassen wir nochmal zusammen
- Zuerst behauptet einer SM 3.0 kann vollständig in SM 2.0 emuliert werden
- Er wird wiederlegt
- Das alte Spiel von der nicht vorhandenen SM 3.0 Performance von NV40 beginnt.
Bissel lächerlich oder? NV40 ist sehr wohl schnell genug um SM3.0 auch ausnützen zu können, vor allem die großen Modelle.
DrumDub
2004-12-08, 13:12:27
Also fassen wir nochmal zusammen
- Zuerst behauptet einer SM 3.0 kann vollständig in SM 2.0 emuliert werden
- Er wird wiederlegt
sicher? ich hab das hier anders verstanden: http://www.forum-3dcenter.org/vbulletin/showpost.php?p=2528563&postcount=77
obs sinnvoll ist, ist eine andere frage. wobei vs 3.0 wohl nicht möglich sind. zumindest nicht über die gpu.
Crushinator
2004-12-08, 13:14:11
Also fassen wir nochmal zusammen
- Zuerst behauptet einer SM 3.0 kann vollständig in SM 2.0 emuliert werden Nein, ich glaub' da ist etwas mißverstanden worden. Die Frage lautete, ob es Effekte gibt, die nur mit SM3 realisiert werden können. Die Antwort lautete: Prinzipiell nicht, es ist immer eine Frage der Geschwindigkeit und des Aufwandes.
- Er wird wiederlegt Das habe ich noch nicht so vernommen.
- Das alte Spiel von der nicht vorhandenen SM 3.0 Performance von NV40 beginnt. Da scheine ich was zu übersehen. Wie kann man behaupten, daß NV40 keine oder nur eine schlechte SM3-Perfomance hätte, wenn es dazu keine andere SM3-Hardware (also, keine Vergleichsmöglichkeit) gibt?
Bissel lächerlich oder? NV40 ist sehr wohl schnell genug um SM3.0 auch ausnützen zu können, vor allem die großen Modelle. Ich denke, das Problem liegt darin, daß es bisher in der Praxis noch nicht so vermittelt werden kann. Was wir hier und da alles in Realworld-Anwendungen an SM3-Einsatz sehen dienen zwar dazu den jeweiligen Titel auf dem NV40 zu beschleunigen, aber die Tatsache, daß es oft genung Beispiele dafür gibt, daß der selbe Titel auf einer nicht SM3-fähigen Hardware gleich schnell oder noch schneller ausgeführt wird, gestaltet eine grundsätzliche Aussage, daß NV40 der SM3-Performanceking sei schwer vermittelbar.
Das habe ich noch nicht so vernommen.
Ich ebenfalls nicht. Bisher hab ich hier nur Beispiele gesehen wo ein SM3 "only" Feature mit SM2.0(b) eben doch irgendwie emuliert wurde.
Demirug
2004-12-08, 13:18:57
sicher? ich hab das hier anders verstanden: http://www.forum-3dcenter.org/vbulletin/showpost.php?p=2528563&postcount=77
obs sinnvoll ist, ist eine andere frage. wobei vs 3.0 wohl nicht möglich sind. zumindest nicht über die gpu.
Stop. In dem Moment wenn man das macht würde man das ja als PS 3.0 melden. Die DX Spec verbietet es ja nicht die Funktion über solche Tricks wie einen F-Buffer zu erreichen.
seahawk
2004-12-08, 13:23:41
Ein gutes Posting. :) So mag ich es, wenn Du von Sm3.0 schwärmst. :up: Weniger, wenn du nicht wenigstens ein bischen auf den zeitlichen Faktor eingehst.
Sm3.0 oder + werden sicherlich wieder einen Sprung in den grafischen Mölichkeiten darstellen, jedenfalls für das achtsame Auge, nur mag ich es nicht, wenn man verschweigt, wie lange es noch dauert, bis man die Vorzüge von SM3.0 in modernen Titeln, als echte SM3.0 Effekte zu sehen bekommen wird. Mit dem NV40 wird das jedenfalls nicht der Fall sein, einmal wegen der relativ schlechten Performance des NV40 und zum anderem wegen der Verbreitung von SM3.0 Hardware.
Wo wir wieder bei dem Henne und Ei Problem sind. Ohne entsprechende verfügbare hArdware entwicklet niemand entsprechende Software.
d. h. -> kein NV40 -> SM3.0 wird entsprechend später in der Software umgesetzt.
DrumDub
2004-12-08, 13:24:03
Stop. In dem Moment wenn man das macht würde man das ja als PS 3.0 melden. Die DX Spec verbietet es ja nicht die Funktion über solche Tricks wie einen F-Buffer zu erreichen.
es ging mir eigentlich nur möglichkeit es auf ps 2.0 hw zu machen, die ich damit als gegeben sehe. der grund, warum es ati nur in opengl anbietet, ist ja offensichtlich.
Das habe ich noch nicht so vernommen.
Ein dynamischer Loop lässt sich nicht emulieren, wie oft noch?
Zumindest nicht mit der GPU alleine, und alles andere kommt nicht in Frage.
Demirug
2004-12-08, 13:26:01
es ging mir eigentlich nur möglichkeit es auf ps 2.0 hw zu machen, die ich damit als gegeben sehe. der grund, warum es ati nur in opengl anbietet, ist ja offensichtlich.
Wirklich anbieten tun sie es im Moment ja noch überhaupt nicht. Unter DX funktioniert es laut ATI aus technischen Gründen nicht. Die wollte man aber nicht genauer spezifizieren.
Crushinator
2004-12-08, 13:27:05
Ein dynamischer Loop lässt sich nicht emulieren, wie oft noch? Das läßt sich nur mit einer Gegenfrage beantworten: Ist ein dynamischer Loop die einzige Möglichkeit einen Effekt zu rendern?
Das läßt sich nur mit einer Gegenfrage beantworten: Ist ein dynamischer Loop die einzige Möglichkeit einen Effekt zu rendern?
Wenn er für diesen Effekt gebraucht wird - ja, definitiv.
Aber hör endlich mit deinen Effekten auf. In HL² besteht das ganze Bild aus Shadern, würdest du jede Mauer als Effekt bezeichnen?
Es gibt z.B. einen Schattenalgorithmus der die Kanten auf Basis der Distanz blurt, dafür braucht man einen Loop. Den kannst du mit SM 2.0 nicht implementieren.
Crushinator
2004-12-08, 13:33:26
Wenn er für diesen Effekt gebraucht wird - ja, definitiv. Das kann man als Meinung stehen lassen, ohne stichhaltige Beweise bleibt es eben nur Theorie. Ich würde mich gerne in der Praxis davon überzeugen. :)
Aber hör endlich mit deinen Effekten auf. Sorry, ich habe noch keine Regeln entdeckt, die einem verbieten könnten nicht von Effekten zu sprechen, vielleicht könntest Du mir da auf die Sprünge helfen.
In HL² besteht das ganze Bild aus Shadern, würdest du jede Mauer als Effekt bezeichnen? Gegenfrage: Würdest Du jeden Effekt (Bumpmapping) als Shader bezeichnen?
Es gibt z.B. einen Schattenalgorithmus der die Kanten auf Basis der Distanz blurt, dafür braucht man einen Loop. Den kannst du mit SM 2.0 nicht implementieren. Sorry, ich komme Deinen ständigen Edits nicht immer hinterher. Wie dem auch sei: Könntest Du mir genau erklären, warum man es gar nicht mit einem anderen Algo machen könnte, und ob Du so freundlich wärst und mir den Algo oder den Shader verlinkst?
Demirug
2004-12-08, 13:34:43
Ein dynamischer Loop lässt sich nicht emulieren, wie oft noch?
Das geht schon es wird nur tendenziel sehr unperformant.
Nur sehe ich ehrlich gesagt jetzt keinen Sinn darin Tricks zu suchen wie man bestimmte Dinge nachbildet. Unter dieser Vorgehensweise bräuchten wir auch keine 2.B Shaderhardware die ja nun laut ATI der letzte Schrei ist der alles kann. Denn mit 2.0 kann man alles nachbilden was mit 2.B geht.
Das kann man als Meinung stehen lassen, ohne stichhaltige Beweise bleibt es eben nur Theorie. Ich würde mich gerne in der Praxis davon überzeugen.
Was gibt's da zu beweisen? Ich meine, dann bräuchte die CPUs ja auch keine dynamischen Loops wenn man jeden Algorithmus ohne machen könnte.
Versuch endlich mal bisschen mitzudenken. Es gibt nunmal Algorithmen die in einer Schleife enden die abhängig ist von einer Rechnung.
Das geht schon es wird nur tendenziel sehr unperformant.
Nicht tendeniziel, es ist verdammt unperformant durch die Readbacks.
Sorry, ich habe noch keine Regeln entdeckt, die einem verbieten könnten nicht von Effekten zu sprechen, vielleicht könntest Du mir da auf die Sprünge helfen.
Gibt es nicht, nur ist es einfach nicht passend, weil dann jedes Polygon ein Effekt sein müsste, weil sich alles mit PS ausführen lässt.
Gegenfrage: Würdest Du jeden Effekt (Bumpmapping) als Shader bezeichnen?
Nein, ich verstehe aber nicht was daran relevant sein soll? Ich würde Bumpmapping noch nicht mal als Effekt ansehen.
DrumDub
2004-12-08, 13:37:03
Wirklich anbieten tun sie es im Moment ja noch überhaupt nicht.
also ist der f-buffer immer noch ein "marketing-gespenst"?
Unter DX funktioniert es laut ATI aus technischen Gründen nicht. Die wollte man aber nicht genauer spezifizieren.
ich glaube nicht, dass es aus technischen gründen nicht funktioniert.
Asmodeus
2004-12-08, 13:38:53
So richtig versteh ich manche Argumente hier nicht ganz. Im Grunde kann man diese Diskussion auch einfach auf die CPU umlegen. Sicher ist es z.B. in C und C++ auch möglich, Algorithmen so umzuschreiben, dass sie ohne Schleifen oder ohne Verzweigungen auskommen. Aber da würde niemand auf die Idee kommen, eben, weil es schon so lange Standart ist. Und warum sollte man mit SM3.0 jetzt darauf verzichten, diese "Annehmlichkeiten" zu nutzen, nur weil es auch mit SM2.0 umständlicher geht. Das Humus Beispiel ist dafür doch prima geeignet. Ist ein "riesiger" Aufwand, nur um die Sache auch ohne SM3.0 so nutzen zu können.
Gruss, Carsten.
Standard mit d bitte ;)
Sicher ist es z.B. in C und C++ auch möglich, Algorithmen so umzuschreiben, dass sie ohne Schleifen oder ohne Verzweigungen auskommen
Sobald die Schleife dynamisch ist, geht das nicht mehr. Weil man hier eben auch nicht wüsste wie weit man ausrollen muss (entspricht den Passes beim Rendern)
Crushinator
2004-12-08, 13:45:46
@Asmodeus
Absolut richtig, und ich entnehme keinem Posting, daß gefordert würde, man solle auf SM3 verzichten. Schon gar nicht, wenn es einem (dem Entwickler) das Leben leichter gestaltet. Viel mehr geht's eingentlich darum herauszufinden, was alles ohne SM3-Hardware völlig unpraktikabel (weil beispielsweise nicht mehr in Echtzeit renderbar) sei. Ich denke, es wird noch einige Zeit vergehen, bis man auf SM3 gar nicht mehr verzichten kann, den Entwicklern zuliebe hoffentlich nicht sehr lange. :)
Standard mit d bitte ;)
Sobald die Schleife dynamisch ist, geht das nicht mehr. Weil man hier eben auch nicht wüsste wie weit man ausrollen muss (entspricht den Passes beim Rendern)
Eh, seit wann muss man wissen wie lange man "ausrollen" muss ? Alles was man braucht ist ein Abbruchkriterium, und das könnte man bspw. mit einem Test in Alpha realisieren.
Demirug
2004-12-08, 13:47:49
Nicht tendeniziel, es ist verdammt unperformant durch die Readbacks.
Mit Querys geht es etwas besser als mit Readbacks aber machen würde ich das ganze trotzdem nicht. Ist einen höllischen Aufwand. Auf einer Hardware die nicht dynamischen Loopen kann würde ich halt die maximalzahl durchlaufen lassen.
Demirug, könntest du das mit dem PS3.0 und F-Buffer bitte mal etwas genauer erleutern ? Irgendwie kommt mir das etwas aus dem Zusammenhang gegriffen vor...
Eh, seit wann muss man wissen wie lange man "ausrollen" muss ? Alles was man braucht ist ein Abbruchkriterium, und das könnte man bspw. mit einem Test in Alpha realisieren.
Weil die Anzahl der Renderpasses nunmal durch "DrawPrimitive" o.ä. von der CPU resultiert, also muss diese wissen wieviel Passes sie abschicken muss.
Auf einer Hardware die nicht dynamischen Loopen kann würde ich halt die maximalzahl durchlaufen lassen.
Ja, aber das ist auch keine Lösung für alle Sachen, vor allem wenn nur wenige Pixel viele Loops benötigen.
Gegenfrage: Würdest Du jeden Effekt (Bumpmapping) als Shader bezeichnen?
Es wird dabei was geshadet, also ists ein Shader.
Genaugenommen wird immer geshadet, ob jetzt Flatshading, Phongshading, Wardshading, mit oder ohne Textur/Bumpmapping oder sonstwas.
Mit Effekten hat das nichts zu tun.
Früher wurde das Shading festverdrahtet gemacht und heute ists frei programmierbar. Sonst hat sich nichts geändern.
Demirug
2004-12-08, 13:49:27
also ist der f-buffer immer noch ein "marketing-gespenst"?
Ja, in den offiziellen Treibern ist noch nichts davon zu sehen.
ich glaube nicht, dass es aus technischen gründen nicht funktioniert.
ATI behauptet das sie mit ihrem F-Buffer Konzept Probleme hätten die DX-Spec einzuhalten.
Crushinator
2004-12-08, 13:49:54
(...) ich glaube nicht, dass es aus technischen gründen nicht funktioniert. Wenn es die API nicht ermöglicht einen den Specs nach zu langen Shader API-Konform zu übergeben, kann man diplomatischerweise auch von einem technischen Grund sprechen. ;)
Demirug
2004-12-08, 13:51:03
Eh, seit wann muss man wissen wie lange man "ausrollen" muss ? Alles was man braucht ist ein Abbruchkriterium, und das könnte man bspw. mit einem Test in Alpha realisieren.
2.0/2.X Shaderhardware kann nicht abbrechen. Ein Shader muss immer komplett durchlaufen.
Demirug
2004-12-08, 13:54:51
Wenn es die API nicht ermöglicht einen den Specs nach zu langen Shader API-Konform zu übergeben, kann man diplomatischerweise auch von einem technischen Grund sprechen. ;)
Beim R300 hätten sie aufgrund der Spec bis 512 Anweisungen hoch gehen können. Das Problem das ATI aber wohl hat ist das sie die Lauffähigkeit nicht sicherstellen können. Die Spec schreibt ja vor das jeder Shader der im Rahmen der Caps liegt auch funktionieren muss. Bei OpenGL darf man ja bei einer Extension regeln aussser Kraft setzten. Ich habe mal gehört das es bei der ATI Variante des F-Buffers Probleme mit dem Alphablend geben soll. Unter OpenGL können sie es ja einfach in die Extension schreiben das man es eben nicht benutzten darf bei DX geht das nicht.
Asmodeus
2004-12-08, 14:00:34
2.0/2.X Shaderhardware kann nicht abbrechen. Ein Shader muss immer komplett durchlaufen.
Ich glaub, dass die meisten genau diesen Aspekt immer gern vergessen, unter SM3.0 resultiert der Geschwindigkeitsvorteil ja nur zum einen aus der Möglichkeit des dynamischen Branchen. Der andere Teil des Vorteils ist eben, dass nach dem Abarbeiten des einen oder anderen Branches auch wirklich Schluss ist, und nicht der Rest des Shaderprogramms auch noch durchlaufen werden muss.
Gruss, Carsten.
DrumDub
2004-12-08, 14:02:29
Nur sehe ich ehrlich gesagt jetzt keinen Sinn darin Tricks zu suchen wie man bestimmte Dinge nachbildet. Unter dieser Vorgehensweise bräuchten wir auch keine 2.B Shaderhardware die ja nun laut ATI der letzte Schrei ist der alles kann. Denn mit 2.0 kann man alles nachbilden was mit 2.B geht.
sicher, die diskussion ist ja hier auch arg theoretisch. die frage, die sich mir stellt, ist die, welche dinge dann noch über die gpu realisiert werden können und welche dinge nur noch über die cpu. interssant wäre für mich z.b. die sache mit dem vs 3.0 wasser bei pacific fighters.
VertexShader lassen sich immer auf der CPU abarbeiten.
Halt, ich muss mich korrigieren. Wenn Texture Fetches enthalten sind die auf eine dynamischen von der GPU gerenderte Textur zugreifen dann geht es nicht.
DrumDub
2004-12-08, 14:14:16
VertexShader lassen sich immer auf der CPU abarbeiten.
ja, die frage ist nur wie schnell das geht. besonders weil es ja vertex texturing ist.
Crushinator
2004-12-08, 15:01:38
Es wird dabei was geshadet, also ists ein Shader. Nunja, mit einem Shader asoziiere ich programmierbare Einheiten im Chip oder eben Programme für Ausführungseinheiten in eigener dafür vorgesehenen Sprache. Diese Programme lassen sich in bestimmte Spezifikationen/Modelle einordnen, also spreche zumindest ich in diesem Zusammenhang immer von Shader-Anweisungen nach Modell X oder Y.
Genaugenommen wird immer geshadet, ob jetzt Flatshading, Phongshading, Wardshading, mit oder ohne Textur/Bumpmapping oder sonstwas.
Mit Effekten hat das nichts zu tun. In diesem Zusammenhang benutzt man entweder Shader nach obiger Definition um Effekte zu realisieren oder man ruft ggf. API-Funktionen auf, die das tun. Wenn ich jetzt nur eine Surface texturiere, bei dem der Eindruck entsteht als sei etwas darin gespiegelt, was habe ich dann realisiert? Einen Shader oder einen Effekt?
Früher wurde das Shading festverdrahtet gemacht und heute ists frei programmierbar. Sonst hat sich nichts geändern. Ich glaube eher, daß man einen Shader mit dem allgemeinen Begriff "shading" verwechselt. Man kann es ja auch gerne von mir aus tun, es spricht nichts dagegen, hauptsache wir wissen, was genau gemeint wäre.
BTW: Als ich gerade paar ehemalige Kollegen bei einem IHV fragte, wie sie es mit dem Unterschied von Shader zu einem Effekt sähen, kam die prompte Antwort, daß ein Effekt mehr das Ergebnis des Redervorganges bezeichnet, während Shader (im Sinne von VS/PS nach der Norm x) hauptsächlich als mögliche Wege bezeichnet werden um Effekte zu realisieren.
Wenn ich jetzt nur eine Surface texturiere, bei dem der Eindruck entsteht als sei etwas darin gespiegelt, was habe ich dann realisiert? Einen Shader oder einen Effekt?
Einen Effekt durch einen Shader.
Shader ist ein doofer Begriff, deshalb heißen die Dinger in OpenGL ja auch Fragment und Vertex Program.
nVidia hat ja auch bei der GeForce 2 GTS schon von Gigatexel Shader gesprochen und die Register Combiner als das verkauft.
Sie sind im Prinzip auch PixelShader 0.x, weil PS 1.1-1.3 funktioniert genauso, ist nur programmierbarer.
daß ein Effekt mehr das Ergebnis des Redervorganges bezeichnet, während Shader (im Sinne von VS/PS nach der Norm x) hauptsächlich als mögliche Wege bezeichnet werden um Effekte zu realisieren.
Ja richtig, deshalb finde ich es auch problematisch das du immer von Effekten redest. Nicht alles auf dem Bild was ein Shader berechnet würde ein DAU als "Effekt" bezeichnen.
Nunja, mit einem Shader asoziiere ich programmierbare Einheiten im Chip oder eben Programme für Ausführungseinheiten in eigener dafür vorgesehenen Sprache. Diese Programme lassen sich in bestimmte Spezifikationen/Modelle einordnen, also spreche zumindest ich in diesem Zusammenhang immer von Shader-Anweisungen nach Modell X oder Y.
In diesem Zusammenhang benutzt man entweder Shader nach obiger Definition um Effekte zu realisieren oder man ruft ggf. API-Funktionen auf, die das tun. Wenn ich jetzt nur eine Surface texturiere, bei dem der Eindruck entsteht als sei etwas darin gespiegelt, was habe ich dann realisiert? Einen Shader oder einen Effekt?
Ich glaube eher, daß man einen Shader mit dem allgemeinen Begriff "shading" verwechselt. Man kann es ja auch gerne von mir aus tun, es spricht nichts dagegen, hauptsache wir wissen, was genau gemeint wäre.
Von der Theorie ist da eigentlich nichts zu verwechseln oder hineinzudeuten.
Der Begriff Shader ist schon alt und in der Computergrafik seit Jahrzehnten gebräuchlich.
Dass jetzt im "Gamerbereich" Shader mit was was programmierbarem asoziiert wird mag ja sein, liegt aber nur dran, dass IHV irgendwann angefangen haben mit programmierbaren Shadern (nicht mit mit dem einzelnen Begriff Shader!)zu werben und die Leute mit dem unbekannten Begriff Shader konfrontiert wurden. Dabei wurde irrtümlicherweise in den Köpfen programmierbar und Shader fest miteinander verknüpft...
Was machst du jetzt wenn jemand im Raytracing von Shadern spricht? Versuchst du da auch ein Shadermodel (2.0/3.0) zuzuordnen?
Crushinator
2004-12-08, 15:43:59
(...) Was machst du jetzt wenn jemand im Raytracing von Shadern spricht? Versuchst du da auch ein Shadermodel (2.0/3.0) zuzuordnen? Nein, tu' ich natürlich nicht. Aber hier gings von Anfang an nicht um Shader nach welcher Definition auch immer, sondern im Grunde genommen nur darum, was man nicht zu sehen bekommt allein aufgrund fehlender SM3-Fähigkeit. Ich denke wenn ich ehrlich sein soll, daß vermutlich jeder in diesem Thread verstanden hat, wovon ich gesprochen habe, wenn ich von Effekten sprach, vorausgesetzt er wollte es.
Naja ich finde es gibt nen Unterschied zwischen
"Zeig mir einen Effekt der SM 3.0 braucht" und "Zeig mir einen Shader der SM 3.0 braucht"
Letzteres ist viel einfacher zu konstruieren, bei einem Effekt müsste man ein konkretes Beispiel erstellen.
Demirug
2004-12-08, 16:31:25
Demirug, könntest du das mit dem PS3.0 und F-Buffer bitte mal etwas genauer erleutern ? Irgendwie kommt mir das etwas aus dem Zusammenhang gegriffen vor...
Es ist auch Offtopic. Ich habe es nur eingeworfen weil es eben auch um die Frage ging was macht den Unterschied zwichen einem SM3 und SM2 aus. Im Pixelshader bereich kann das durchaus ein F-Buffer mit leichten erweiterungen sein.
Naja ich finde es gibt nen Unterschied zwischen
"Zeig mir einen Effekt der SM 3.0 braucht" und "Zeig mir einen Shader der SM 3.0 braucht"
Letzteres ist viel einfacher zu konstruieren, bei einem Effekt müsste man ein konkretes Beispiel erstellen.
Ack. Genau darum geht es. Für welche Effekte braucht man SM 3?
Beim SM 2 war es noch recht simpel Effekte zu finden, die mit PS1.3/1.4 nicht machbar waren oder sehr bescheiden aussahen. Refraction (Glas) ist nur ein Beispiel.
Was darf man da von SM 3 erwarten? Entweder mir geht die Vorstellungskraft aus oder SM 3 wird keine neuen Effekte bieten. Wird zwar alles flexibler zu programmieren sein, teilweise kann man hier und da etwas beschleunigen, aber an wirklich neue Effekte kann ich atm nicht glauben. :)
Asmodeus
2004-12-08, 16:50:20
Ack. Genau darum geht es. Für welche Effekte braucht man SM 3?
Beim SM 2 war es noch recht simpel Effekte zu finden, die mit PS1.3/1.4 nicht machbar waren oder sehr bescheiden aussahen. Refraction (Glas) ist nur ein Beispiel.
Was darf man da von SM 3 erwarten? Entweder mir geht die Vorstellungskraft aus oder SM 3 wird keine neuen Effekte bieten. Wird zwar alles flexibler zu programmieren sein, teilweise kann man hier und da etwas beschleunigen, aber an wirklich neue Effekte kann ich atm nicht glauben. :)
Ja und, Intel meinte damals doch auch, durch MMX wird das Internet schneller und bunter. :wink: Auch wenn das natürlich Werbeblabla war und das Internet dadurch nicht sichtbar schneller und bunter wurde, so hatte die Einführung von MMX doch auch einige Vorteile, z.B. für Programmierer.
Und ein neuer Effekt wäre z.B. die Transluzenz / Reflexion bei Pflanzen. Siehst Du heute in noch keinem Spiel, einfach, weil es wie gemacht für dynamisches Branchen ist und auf herkömmlichen Wegen viel zu viel Performance kostet, ohne SM3.
Gruss, Carsten
Hier haben wir doch ein schönes Bsp. Refraction wird ab einem bestimmten Winkel zu Reflexion
http://freespace.virgin.net/gareth.james/virtual/Optics/Refraction/refraction.html
Also könnte man einen Shader machen der das dynamisch prüft und entweder eine Cubemap für die Spiegelung oder eine Textur für die Refraktion sampled.
Das wird mit SM 2.0 wirklich schwer, vor allem wenn man Alpha/Stencil für etwas anderes braucht.
Selbst wenn man das per Humus Trick implementiert, würde man trotzdem immer beides samplen und berechnen, das kann unmöglich gleich schnell sein.
Tigerchen
2004-12-08, 17:12:30
So richtig versteh ich manche Argumente hier nicht ganz. Im Grunde kann man diese Diskussion auch einfach auf die CPU umlegen. Sicher ist es z.B. in C und C++ auch möglich, Algorithmen so umzuschreiben, dass sie ohne Schleifen oder ohne Verzweigungen auskommen. Aber da würde niemand auf die Idee kommen, eben, weil es schon so lange Standart ist. Und warum sollte man mit SM3.0 jetzt darauf verzichten, diese "Annehmlichkeiten" zu nutzen, nur weil es auch mit SM2.0 umständlicher geht. Das Humus Beispiel ist dafür doch prima geeignet. Ist ein "riesiger" Aufwand, nur um die Sache auch ohne SM3.0 so nutzen zu können.
Gruss, Carsten.
Niemand soll auf SM 3.0 verzichten der es brauchen kann. Gibts gar nichts dran auszusetzen. Der nV40 ist ein großer Wurf. Wenn du den brauchst; kaufen! Ich hab meine eigenen Prioritäten und entscheide mich anders. So ist das eben.
Das Problem mit den ganzen NV Fanboys ist daß sie behaupten man müßte einen nV40 haben weil jetzt Stalker und HDR und dynamic branching für alle kommt und die ATI-Jünger dann ganz schnell in die Röhre gucken. Und das sehen eben einige von der roten Seite gelassener.
Das Problem mit den ganzen NV Fanboys ist daß sie behaupten man müßte einen nV40 haben weil jetzt Stalker und HDR und dynamic branching für alle kommt und die ATI-Jünger dann ganz schnell in die Röhre gucken. Und das sehen eben einige von der roten Seite gelassener.
Ack. Das ist soweit definitiv richtig.
Es ging hier aber um den allgemeinen Sinn von SM3.0 und der ist sicherlich gegeben.
Nur weil es ATi nicht hat meinen manche hier es schlechtreden zu müssen.
Demirug
2004-12-08, 17:28:22
Hier haben wir doch ein schönes Bsp. Refraction wird ab einem bestimmten Winkel zu Reflexion
http://freespace.virgin.net/gareth.james/virtual/Optics/Refraction/refraction.html
Also könnte man einen Shader machen der das dynamisch prüft und entweder eine Cubemap für die Spiegelung oder eine Textur für die Refraktion sampled.
Das wird mit SM 2.0 wirklich schwer, vor allem wenn man Alpha/Stencil für etwas anderes braucht.
Selbst wenn man das per Humus Trick implementiert, würde man trotzdem immer beides samplen und berechnen, das kann unmöglich gleich schnell sein.
Der Stenciltrick funktioniert auch dort. Allerdings wird das ganze ein 3 Pass Effekt.
Und ein neuer Effekt wäre z.B. die Transluzenz / Reflexion bei Pflanzen. Siehst Du heute in noch keinem Spiel, einfach, weil es wie gemacht für dynamisches Branchen ist und auf herkömmlichen Wegen viel zu viel Performance kostet, ohne SM3.
Gruss, Carsten
Darüber habe ich auch schon nachgedacht als ich das Unreal3 Engine Video gesehen habe. Die transluzenten Flügel der Monster sahen vielversprechend aus. Bei Pflanzen wäre ich aber skeptisch. Sagen wir mal wir wollen den Dschungel in Far Cry mit transluzenten Pflanzen ausstatten, die Rechenleistung wird in absehbarer Zeit einfach nicht da sein.
Asmodeus
2004-12-08, 17:42:34
Darüber habe ich auch schon nachgedacht als ich das Unreal3 Engine Video gesehen habe. Die transluzenten Flügel der Monster sahen vielversprechend aus. Bei Pflanzen wäre ich aber skeptisch. Sagen wir mal wir wollen den Dschungel in Far Cry mit transluzenten Pflanzen ausstatten, die Rechenleistung wird in absehbarer Zeit einfach nicht da sein.
Würde ich nicht ganz so pessimistisch sehen. Ende 2005 / Anfang 2006 halte ich es durchaus für machbar, mit ein paar Abstrichen, was die Genauigkeit der transluzenten Lichtberechnung angeht.
Gruss, Carsten.
Würde ich nicht ganz so pessimistisch sehen. Ende 2005 / Anfang 2006 halte ich es durchaus für machbar, mit ein paar Abstrichen, was die Genauigkeit der transluzenten Lichtberechnung angeht.
Gruss, Carsten.
:eek:
Du willst doch nicht behaupten das ein NV50/47 (wie auch immer) oder ein R520 performant genug sein wird um den FarCry Dschungel mit transluzenten Pflanzen auszustatten. Das kann ich mir nicht vorstellen. Das ist Wunschdenken.
Asmodeus
2004-12-08, 18:04:03
:eek:
Du willst doch nicht behaupten das ein NV50/47 (wie auch immer) oder ein R520 performant genug sein wird um den FarCry Dschungel mit transluzenten Pflanzen auszustatten. Das kann ich mir nicht vorstellen. Das ist Wunschdenken.
Von der Geometriekomplexität würde sich ja nichts ändern. Man bräuchte pro Pflanze dann eben z.B. nur noch ein paar Transluzenztexturen, um die Sache im Shader nicht berechnen zu müssen, sondern eben dann die Texturen dafür zu verwenden. Und dann eben die dynamische Unterscheidung, ob es sich beim aktuellen Fragment um eins mit Transluzenzeffekt handelt oder um eins mit Reflexionseffekt. Wie gesagt, das wäre keine "botanisch korrekte" Transluzenz, aber würde den Effekt wenigstens überhaupt mal ins Spiel bringen.
Gruss, Carsten.
StefanV
2004-12-08, 18:17:32
Es ging hier aber um den allgemeinen Sinn von SM3.0 und der ist sicherlich gegeben.
Eher andersrum:
Hier gehts drum, darzulegen, das SM3 wirklich effekte Ermöglicht, die mit SM2 nicht möglich sind.
PS: bisher hab ich davon nicht wirklich viel gesehen, nur das übliche 'geflame' :|
Von der Geometriekomplexität würde sich ja nichts ändern. Man bräuchte pro Pflanze dann eben z.B. nur noch ein paar Transluzenztexturen, um die Sache im Shader nicht berechnen zu müssen, sondern eben dann die Texturen dafür zu verwenden. Und dann eben die dynamische Unterscheidung, ob es sich beim aktuellen Fragment um eins mit Transluzenzeffekt handelt oder um eins mit Reflexionseffekt. Wie gesagt, das wäre keine "botanisch korrekte" Transluzenz, aber würde den Effekt wenigstens überhaupt mal ins Spiel bringen.
Gruss, Carsten.
Das Problem wäre noch die Lichtquelle (Sonne). Wenn du dich unter/neben eine Pflanze stellst, werden die Blätter von deinem Betrachtungswinkel aus unter verschiedenen Winkeln bestrahlt. Die Berechnung wird ziemlich aufwändig, außerdem müsste man bei den Blättern extrem viele Details (Polygone) verwenden, damit man von einer Transluzenz sprechen kann.
Hier gehts drum, darzulegen, das SM3 wirklich effekte Ermöglicht, die mit SM2 nicht möglich sind.
Dann würde es SM 3.0 wohl gar nicht geben, logisch nicht?
Eher andersrum:
Hier gehts drum, darzulegen, das SM3 wirklich effekte Ermöglicht, die mit SM2 nicht möglich sind.
PS: bisher hab ich davon nicht wirklich viel gesehen, nur das übliche 'geflame' :|
Wenn du das so siehst, welche SM2 Effekte sind denn mit Sm1 nicht möglich?
Es ist auch Offtopic. Ich habe es nur eingeworfen weil es eben auch um die Frage ging was macht den Unterschied zwichen einem SM3 und SM2 aus. Im Pixelshader bereich kann das durchaus ein F-Buffer mit leichten erweiterungen sein.
Hm intressant. Wäre es denkbar das ATI das ganze F-Buffer Gerüst dazu nutzt um sowas in der Art in ihrem nächste (Refresh ? ;) ) Chip zu machen ? Es halten sich ja Gerüchte das sie SM3.0 womöglich gar nicht mehr einbauen wollen (und die WGF Folien die gestern aufgetaucht sind lassen mich auch eher sowas glauben).
Jesus
2004-12-08, 18:50:41
^^ :rolleyes:
oder anders gefragt, wäre es, auch wenn man es als exploit betrachte, rein treibertechnisch möglich sowas schon jetzt auf der heutigen HW zu realisieren ?
Demirug
2004-12-08, 18:55:22
Hm intressant. Wäre es denkbar das ATI das ganze F-Buffer Gerüst dazu nutzt um sowas in der Art in ihrem nächste (Refresh ? ;) ) Chip zu machen ? Es halten sich ja Gerüchte das sie SM3.0 womöglich gar nicht mehr einbauen wollen (und die WGF Folien die gestern aufgetaucht sind lassen mich auch eher sowas glauben).
Ich habe ja schon in einem anderen Thread geschrieben das ich seit Tagen sowas wie F-Buffer III immer wieder vor meinem geistigen Auge auftauchen sehen.
Demirug
2004-12-08, 18:57:13
^^ :rolleyes:
oder anders gefragt, wäre es, auch wenn man es als exploit betrachte, rein treibertechnisch möglich sowas schon jetzt auf der heutigen HW zu realisieren ?
Solange ATI keine Details zu ihere F-Buffer implementierung rausgibt kann man darüber nur spekulieren.
IMHO fehlen da aber aktuelle noch Teile um volle SM3 Fähigkeit zu erreichen.
Wenn du das so siehst, welche SM2 Effekte sind denn mit Sm1 nicht möglich?
Naja, alles was höhere Präzision als FX12 braucht. Das ist schon einiges heute :rolleyes:
Asmodeus
2004-12-09, 10:45:53
Das Problem wäre noch die Lichtquelle (Sonne). Wenn du dich unter/neben eine Pflanze stellst, werden die Blätter von deinem Betrachtungswinkel aus unter verschiedenen Winkeln bestrahlt. Die Berechnung wird ziemlich aufwändig, außerdem müsste man bei den Blättern extrem viele Details (Polygone) verwenden, damit man von einer Transluzenz sprechen kann.
In über einem Jahr, und mit etwas ausgedünnter Vegetation, und etwas weniger Dreiecken sollte so etwas (Transluzenz/Reflexion) mit durchaus akzeptablen Frameraten laufen (30+):
Beispiel (http://www.inf.uni-konstanz.de/~colditz/Wald03.jpg)
Gruss, Carsten.
SM3.0 (und zum großen teil auch das Profil 2.a) sollen Shader effizienter abarbeiten und dadurch auch Effekte mit einer wesentlicheren hoeheren Geschwindigkeit darstellen.
Hoehere Geschwindigkeit => Mehr Effekte => bessere Bildqualitaet.
Natuerlich kann ich auch alles mit Multipass erledigen, wenn die Hardware nur schnell genug.
Aber genauso irrsinnig waere es, statt Arbeiten auf eine GPU zu uebertragen, einfach die Serverfarm zu verwenden.
LovesuckZ
Also für mich hört sich F-Buffer nach einem Marketinggespenst an, um Nachteile der Radeon9800 ggü. der FX5900 auszubügeln. Wenn der R520 SM3.0 ist (was ich angesichts des R500 als sicher erachte), dann ist F-Buffer sowieso kein Thema mehr.
Demirug
2004-12-10, 08:40:03
Also für mich hört sich F-Buffer nach einem Marketinggespenst an, um Nachteile der Radeon9800 ggü. der FX5900 auszubügeln. Wenn der R520 SM3.0 ist (was ich angesichts des R500 als sicher erachte), dann ist F-Buffer sowieso kein Thema mehr.
Und wie wäre es mit SM3 via F-Buffer?
Und wie wäre es mit SM3 via F-Buffer?Wenn man davon ausgeht, dass R520 im PS durchgehend mit FP32 rechnet, kann man imo auch mit "echtem" PS3 rechnen – oder lässt sich "descent performance" auch mittels F-Buffer realisieren?
Wenn man davon ausgeht, dass R520 im PS durchgehend mit FP32 rechnet, kann man imo auch mit "echtem" PS3 rechnen – oder lässt sich "descent performance" auch mittels F-Buffer realisieren?
Dieser Typo könnte glatt einem Schmäh-PDF eines großen IHV entsprungen sein. :lol:
Ich glaube, es wäre einfacher, einfach nur die Rechenbreite der Einheiten anzupassen, anstatt für eine kurzfristige Übergangslösung den Chip komplett umzubasteln.
Kurz:
Entweder R520 wird schon "unified shader" haben und auch SM3.0, also quasi ein R500 sans edram, oder es wird eine weiter aufgebohrte R300-Variante.
Demirug
2004-12-10, 10:02:09
Wenn man davon ausgeht, dass R520 im PS durchgehend mit FP32 rechnet, kann man imo auch mit "echtem" PS3 rechnen – oder lässt sich "descent performance" auch mittels F-Buffer realisieren?
FP32 ist die kleinste Herausforderung. Solche Dinge wie unlimited dependent Read sind viel komplexer.
Ein F-Buffer ist solange Bandbreite da ist recht performant. Das Rausschreiben und einlesen der Fragmente kann man dann in der Regel gut verstecken. Ausser man baut hinterhältige theoretische Spezialkonstruktionen.
Das einzige was von der Argumentation kompliziert werden könnte ist die Tatsache das ein F-Buffer durchaus unterschiede zwischen FP16 und FP32 machen kann. Wenn man nur FP16 Fragmente schreibt sollte das schneller und Bandbreiten schonender sein.
Den Performanceblick hat ATI bisher immer versucht auf die Branchperformance zu legen. Gerade da lassen sich mit einem F-Buffer recht gute Resultate erreichen. Man setzt einfach jeden Branchzweig in einen eigenen Pass und lässt die Fragmente welche die Bedingung nicht erfüllen schon vor den Pixelprozessoren verwerfen (Early-Z / Stencil prinzip). Damit verliert man dann maximal einen Takt. Wenn die Pixelprozessoren aber sowieso noch rechen verliert man nichts. Damit könnte man dann sagen pro Branchbefehl einen Takt und Branching auf Quad ebene.
Wobei das ja schon fast gefährlich gut wäre da ich beim R500 das Branching auf 64 Pixel Block ebene erwarte.
DrumDub
2004-12-10, 12:06:24
Kurz:
Entweder R520 wird schon "unified shader" haben und auch SM3.0, also quasi ein R500 sans edram, oder es wird eine weiter aufgebohrte R300-Variante.
ich denke letzteres. wobei fudo schon wieder was von sm3.0+ labert... aber der labert viel, wenn der tag lang ist. :D
ich denke letzteres. wobei fudo schon wieder was von sm3.0+ labert... aber der labert viel, wenn der tag lang ist. :D
Kann ich mir echt net vorstellen, dass sie die wirklich innovatiove R500 Technologie ignorieren. Der R520 kann eigentlich nur ne Abwandlung dessen sein.
Demirug
2004-12-10, 13:09:59
Kann ich mir echt net vorstellen, dass sie die wirklich innovatiove R500 Technologie ignorieren. Der R520 kann eigentlich nur ne Abwandlung dessen sein.
Ist er nicht.
Unified pipelines from ATI will exist before WGF, but not on the PC.
DrumDub
2004-12-10, 13:37:22
Ist er nicht.
eben. keine unified shader im r520.
Godmode
2004-12-10, 22:03:10
Wobei das ja schon fast gefährlich gut wäre da ich beim R500 das Branching auf 64 Pixel Block ebene erwarte.
Wird das nicht sehr ineffizient mit 64 Pixel? Und mit wieviel Pixel arbeitet den da der NV4x?
Demirug
2004-12-10, 22:12:09
Wird das nicht sehr ineffizient mit 64 Pixel? Und mit wieviel Pixel arbeitet den da der NV4x?
Etwa 1000. 64 wäre ja ein 8*8 Pixel block. Das ist nicht sonderlich gross.
Godmode
2004-12-10, 22:37:02
Ok, dachte das ist recht viel, da habe ich mich wohl geirrt.
Bezüglich SM3.0 beim R520, ich habe jetzt kurz mal die aktuelle PCGH durchkämmt und bin auf etwas gestoßen:
Seite 66, Kasten Grafikkarten, kleiner Kasten:
Mit dem R5xx wird auch ATI das Shader Model 3 unterstützen
kann das sein das die das schon vorher wussten, oder haben sie das einfach nur mal angenommen? Hast du eigentlich schon Informationen die du aber nicht publik machen darfst bezüglich NDA??
betasilie
2004-12-10, 22:42:02
Ok, dachte das ist recht viel, da habe ich mich wohl geirrt.
Bezüglich SM3.0 beim R520, ich habe jetzt kurz mal die aktuelle PCGH durchkämmt und bin auf etwas gestoßen:
Seite 66, Kasten Grafikkarten, kleiner Kasten:
Mit dem R5xx wird auch ATI das Shader Model 3 unterstützen
kann das sein das die das schon vorher wussten, oder haben sie das einfach nur mal angenommen? Hast du eigentlich schon Informationen die du aber nicht publik machen darfst bezüglich NDA??
Es ist schon seit Moanten bekannt, dass der R520 SM3.0 unterstützen wird.
Godmode
2004-12-10, 22:43:01
Es ist schon seit Moanten bekannt, dass der R520 SM3.0 unterstützen wird.
Hm ich dachte wir haben vor ein paar Tagen noch diskutiert ob er nun SM3 hat oder nicht?
Demirug
2004-12-10, 22:58:46
Bei solchen Ausblick Artikel lag die PCGH auch schon mal daneben zudem fällt R500 ja auch unter R5XX. Wobei ich aber davon ausgehe das auch der R520 iregendwie SM3 unterstützten wird.
Demirug
2004-12-10, 23:00:03
Es ist schon seit Moanten bekannt, dass der R520 SM3.0 unterstützen wird.
Beim R420 war auch so einiges "bekannt".
Godmode
2004-12-10, 23:02:27
Hast du eigentlich schon Informationen die du aber nicht publik machen darfst bezüglich NDA??
Wenn du das nicht beantworten darfst, dann schreib einfach nichts ;)
Demirug
2004-12-10, 23:06:33
Hast du eigentlich schon Informationen die du aber nicht publik machen darfst bezüglich NDA??
Wenn du das nicht beantworten darfst, dann schreib einfach nichts ;)
Zum R520 habe ich Null. Ich bekomme solche Sachen auch nicht ewig vorher. Ein paar tage vielleicht aber mehr auch nicht.
betasilie
2004-12-10, 23:16:20
Beim R420 war auch so einiges "bekannt".
Da hast Du natürlich Recht. ;( ... Trotzdem gab es definitv Aussagen von ATI, dass der R520 SM3.0 hat, was natürlich nicht heißen muss, das R520 und R500 die selbe Architektur benutzen.
Ich bin mal gespannt wie effizient das ganze dann ist, aber ATi ist ja berühmt aus wenig viel zu machen ;)
Der einfache Weg ist manchmal sogar der durchdachtere. Aber wir werden sehen, Spekulationen führen zu nichts.
Ich freu mich jetzt schon auf das Marketing ;)
Thomas
Quasar
2004-12-12, 11:44:54
Da hast Du natürlich Recht. ;( ... Trotzdem gab es definitv Aussagen von ATI, dass der R520 SM3.0 hat, was natürlich nicht heißen muss, das R520 und R500 die selbe Architektur benutzen.
Link?
In den "speech notes" aus dem bekannten PDF steh m.W. nur "blabla until R5xx shows up with decent performance...".
Wo anders hat ATi sich noch dazu 'definitiv' geäußert? *interessiert_ist*
vBulletin®, Copyright ©2000-2025, Jelsoft Enterprises Ltd.