Archiv verlassen und diese Seite im Standarddesign anzeigen : DX- Object Instancing
Demirug
2004-07-29, 20:48:17
Zur fortsetzung der OT Diskussion von dort (http://www.forum-3dcenter.org/vbulletin/showthread.php?s=&threadid=157931).
Demirug
2004-07-29, 21:00:43
Original geschrieben von micki
im dx sdk steht explizit "This feature allows a subset of the input registers to be initialized at a less frequent rate. This feature is supported by all devices that support vs_3_0." und auf der "6800leagues under the sea" hat NV ebenfalls die frequency divider als neues feature erwähnt das erst ab SM3.0 möglich ist.
dafür mußte an FC natürlich etwas am renderpfad geändert werden, sodass er SM3.0 features nutzt.
Welche DX Dokumenatation hast du den? 2003 oder 2004?
Object Instancing funktioniert wenn es eine Karte kann mit jeder Shaderversion. Laut definition kann jede Karte mit mit´VS 3.0 auch Object Instancing. Da sonst aber kein Capsbit dafür definiert wurde dürfen es eigentlich auch nur Karten mit VS 3.0.
Die Runtime prüft nun aber wenn man die entsprechenden Funktion benutzt nicht nach ob die Karte auch wirklich VS 3.0 unterstützt sondern gibt die Einstellung einfach zum Treiber weiter. Dieser würde wenn er kein OI beherscht das ganze einfach ignorieren. Der entsprechenden ATI Treiber tut diese aber nicht sondern verhält sich so wie man es von einem Chip mit OI erwarten kann.
Da die benutzung von OI auf einem nicht OI fähigen Chip/Treiber aber zu renderfehlern führt muss man als Entwickler ja nun feststellen können ob es geht oder nicht. Das offizielle Zeichen ist wie schon gesagt die Unterstüzung von VS 3.0. Da ATI das aber nicht kann haben sie sich mit einem FOURCC Format ein Ersatzzeichen gebaut.
Original geschrieben von Demirug
Da die benutzung von OI auf einem nicht OI fähigen Chip/Treiber aber zu renderfehlern führt muss man als Entwickler ja nun feststellen können ob es geht oder nicht. Das offizielle Zeichen ist wie schon gesagt die Unterstüzung von VS 3.0. Da ATI das aber nicht kann haben sie sich mit einem FOURCC Format ein Ersatzzeichen gebaut. Gibt es das "Ersatz"-FourCC-Format auch "richtig"? Wenn ja, was für ein Texturformat ist das?
Original geschrieben von aths
Gibt es das "Ersatz"-FourCC-Format auch "richtig"? Wenn ja, was für ein Texturformat ist das?
Natürlich nicht. Es heißt INST, und kann einfach nirgends verwendet werden.
micki
2004-07-30, 09:10:38
Original geschrieben von Demirug
Welche DX Dokumenatation hast du den? 2003 oder 2004?
Ich hab alle (seit dx3 ;D) und seit der ersten dx9sdk-beta bis zur aktuellsten version steht das in allen drinne (soweit ich hier sehen konnte, hab mir ja jetzt nich wieder alle installieren mögen)
Original geschrieben von Demirug
Object Instancing funktioniert wenn es eine Karte kann mit jeder Shaderversion. Laut definition kann jede Karte mit mit´VS 3.0 auch Object Instancing. Da sonst aber kein Capsbit dafür definiert wurde dürfen es eigentlich auch nur Karten mit VS 3.0.
"Stream frequency is ignored for both indexed primitives and if the current vertex shader set is less than version 3_0 (including fixed function). " das nochmal aus dem neusten sdk und auf msdn (http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/directx9_c/directx/graphics/reference/Shaders/VertexShader3_0/VertexStreamFrequency.asp)
Damit wiederspricht deiner definition die definition von m$.
Original geschrieben von Demirug
Das sind IMHO ganz andere Diemensionen wie das einfache ändern des Compilerprofils.
jup, da stimm ich dir zu, nur das Compilierprofil zu ändern ist viel weniger als ne umschreibung des renderpaths. deswegen ist die namensgebung in FC für das umschreiben dessen (wo sie ja HDR,objectinstancing... zusätzlich haben), dass auf den SM2.0 karten laut denen so nicht möglich ist, auch gerechtfertigt. den mehr macht doom3 auch nicht wenn zwischen dem nv30 und nv40 renderpath unterschieden wird.
mir scheint als würdet ihr hier meinen dass zum SM3.0 nur vs3.0 und ps3.0 gehören, aber dazu gehört noch einiges mehr, dass FC keine dynamischen branches nutzt weil einige defizite von dx9 die möglichen vorteile nicht erlauben und deswegen die shader auf 2.0 sind, heißt noch lange nicht dass der rest des renderpaths nicht features nutzt die laut dx9sdk und NV erst da möglich sind.
zu dem von dir gesagtem FOURCC format finde ich leider nur videocodecs, bitte um link zu der info damit ich mal sehen kann ob das läuft (wäre klasse wenn ich es hier auch auf nicht sm3.0 karten zum laufen bekäme) :D
MfG
micki
Demirug
2004-07-30, 09:45:24
Original geschrieben von micki
"Stream frequency is ignored for both indexed primitives and if the current vertex shader set is less than version 3_0 (including fixed function). " das nochmal aus dem neusten sdk und auf msdn (http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/directx9_c/directx/graphics/reference/Shaders/VertexShader3_0/VertexStreamFrequency.asp)
Damit wiederspricht deiner definition die definition von m$.
Dokumentationsfehler. Wurde schon vor längerem auf der DX Entwicklerliste geklärt.
jup, da stimm ich dir zu, nur das Compilierprofil zu ändern ist viel weniger als ne umschreibung des renderpaths. deswegen ist die namensgebung in FC für das umschreiben dessen (wo sie ja HDR,objectinstancing... zusätzlich haben), dass auf den SM2.0 karten laut denen so nicht möglich ist, auch gerechtfertigt. den mehr macht doom3 auch nicht wenn zwischen dem nv30 und nv40 renderpath unterschieden wird.
Es gibt keinen NV30/NV40 Renderpath bei D3. Nur noch ARB2 weil JC sonst nämlich keine programmierbaren Shader in die Engine bekommen hätte ohne das die Designer ausgeflipt wären.
Ich bleibe aber dabei das es Blödsinn ist einen Variante zur Darstellung von Effekten nach dem benutzten Shadermodel zu bezeichnen. Dabei ist SM20B im falle von Farcry noch blödsinniger als SM30. Object Instancing was ein Teil diese Pfads ist gehört nicht zu SM20B. ps_2_b ist ein Pixelshaderprofil. Object Instancing ist aber an den Vertexshader gebunden und dort an die Version 3.0. Der R420 hat nur die Version 2.0 2.B gibt es da überhaupt nicht. Die Multilight geschichte wiederum benutzt keine 2.B Shader sondern 2.X Shader die von jeder 2.X Karte welche um die 100 A-Ops pro Pass ausführen kann beherschbar ist.
mir scheint als würdet ihr hier meinen dass zum SM3.0 nur vs3.0 und ps3.0 gehören, aber dazu gehört noch einiges mehr, dass FC keine dynamischen branches nutzt weil einige defizite von dx9 die möglichen vorteile nicht erlauben und deswegen die shader auf 2.0 sind, heißt noch lange nicht dass der rest des renderpaths nicht features nutzt die laut dx9sdk und NV erst da möglich sind.
Ja es gibt eine Liste mit Caps die ein SM3 Chips unterstützen muss. Allerdings ist das hier egal weil diese Caps soweit ich das geprüft habe auch von den SM2 Chips beherscht werden oder von farcry im besagten Renderpfad nicht genutzt werden.
zu dem von dir gesagtem FOURCC format finde ich leider nur videocodecs, bitte um link zu der info damit ich mal sehen kann ob das läuft (wäre klasse wenn ich es hier auch auf nicht sm3.0 karten zum laufen bekäme) :D
MfG
micki
Es gibt keinen Link weil ATI das ganze nicht öffentlich zugänglich macht.
LovesuckZ
2004-07-30, 10:03:04
Das hat zwar nur wenig mit Object Instancing, aber mit FOURCC:
Gibt es die Moeglichkeit, dass Nvidia ebenso vorgehen koennte, um ihre FP Texturen und auch "Ultrashadow" in DX zu "pressen"?
Demirug
2004-07-30, 10:22:18
Original geschrieben von LovesuckZ
Das hat zwar nur wenig mit Object Instancing, aber mit FOURCC:
Gibt es die Moeglichkeit, dass Nvidia ebenso vorgehen koennte, um ihre FP Texturen und auch "Ultrashadow" in DX zu "pressen"?
Die FP-Texturen werden schon als FOURCC Texturen zur verfügung gestellt. Dafür ist dieser Mechanismuss ja auch gedacht.
Im Prinzip könnte man auch Ultrashadow auf diese Art zugänglich machen. Aber schön wäre das nicht.
Original geschrieben von Demirug
Im Prinzip könnte man auch Ultrashadow auf diese Art zugänglich machen. Aber schön wäre das nicht.
Wie das? Muss die DX runtime nicht diese Funktion(en) erst mal ueberhaupt unterstuetzen?
ATi bastelt sich doch nur ein Caps Bit, die Unterstuetzung fuer OI ist doch in DX schon drin.
Demirug
2004-07-30, 11:34:29
Original geschrieben von ow
Wie das? Muss die DX runtime nicht diese Funktion(en) erst mal ueberhaupt unterstuetzen?
ATi bastelt sich doch nur ein Caps Bit, die Unterstuetzung fuer OI ist doch in DX schon drin.
Man nehme eine Textur mit einem FOURCC Format. Das ganze ist nun erst mal nur ein Speicherbereich in den man irgendwas reinkopieren kann. Irgendwas könnte auch eine Datenstruktur zum steuern von einer Funktion sein.
Original geschrieben von Demirug
Man nehme eine Textur mit einem FOURCC Format. Das ganze ist nun erst mal nur ein Speicherbereich in den man irgendwas reinkopieren kann. Irgendwas könnte auch eine Datenstruktur zum steuern von einer Funktion sein.
Das wuerde aber schon weit ueber das hinausgehen, was ATi mit der Implementierung ihres OI-CapsBit tut.
@Demirug
What do you think,does the r420 has an advantage while
using OI against the nv40 ? That shuld be the case,r420
has a higher VS power. ???
Demirug
2004-07-31, 16:14:25
Original geschrieben von IVN
@Demirug
What do you think,does the r420 has an advantage while
using OI against the nv40 ? That shuld be the case,r420
has a higher VS power. ???
The VS Power will not count in case of OI. OI do not change the number of vertex the VS have to calculate. OI only change the overhead between the application and the driver/chip in the case of rendering many small equal objects.
vBulletin®, Copyright ©2000-2025, Jelsoft Enterprises Ltd.