Archiv verlassen und diese Seite im Standarddesign anzeigen : Kyro: BM, aber keine "Register Combiner"
Wie macht Kyro eigentlich Dot3- bzw. EMBM, wenn er eine fixed function pipe hat? Ließe sich eine BM-fähige festverdrahtete Pipe nicht relativ einfach "programmierbar" (Level ersten Pixelshader-Generation) gestalten?
Demirug
2003-09-03, 12:02:39
Dot3 und EMBM sind aber zwei vollkommen unterschiedliche Sachen.
Dot3 ist eine reine Arithmetikoperation
EMBM erfordert eine dependent textureread.
Der Arithmetikteil eines erste Generation Pixelshader entspricht im wesentlichen der DX7 Texturestage pipeline mit mehr Möglichkeiten der Registerwahl.
Der Texturteil ist jedoch doch um einiges komplizierter
Original geschrieben von Demirug
Dot3 und EMBM sind aber zwei vollkommen unterschiedliche Sachen. Jo, für EMBM braucht man
Original geschrieben von Demirug
EMBM erfordert eine dependent textureread.
Original geschrieben von Demirug
Der Arithmetikteil eines erste Generation Pixelshader entspricht im wesentlichen der DX7 Texturestage pipeline mit mehr Möglichkeiten der Registerwahl.
Der Texturteil ist jedoch doch um einiges komplizierter Heißt das, Kyro mangelt es weniger am Combiner, eher an zu unflexiblen TMUs?
Demirug
2003-09-03, 13:57:14
Original geschrieben von aths
Heißt das, Kyro mangelt es weniger am Combiner, eher an zu unflexiblen TMUs?
Ja so könnte man das sagen.
Könntest du da noch ein wenig konkreter werden? Was fehlt den TMUs denn?
Demirug
2003-09-03, 15:54:58
Den TMUs fehlt eigentlich nichts aber zusätzlich zu den TMUs muss eben noch ein Rechenwerk her (NV2X Ansatz) oder eben ein Rückkanal welcher es erlaubt die Ergebnisse aus dem vorhandenen Rechenwerk wieder als Texturekorrdinaten zu nutzen (R2XX und Rampage Ansatz).
Original geschrieben von Demirug
Den TMUs fehlt eigentlich nichts aber zusätzlich zu den TMUs muss eben noch ein Rechenwerk her (NV2X Ansatz) oder eben ein Rückkanal welcher es erlaubt die Ergebnisse aus dem vorhandenen Rechenwerk wieder als Texturekorrdinaten zu nutzen (R2XX und Rampage Ansatz). EMBM wird also "primitiver" gemacht? Ich dachte, genau das sei für EBMB notwendig... *verwirrt sei*
Demirug
2003-09-03, 16:49:58
Original geschrieben von aths
EMBM wird also "primitiver" gemacht? Ich dachte, genau das sei für EBMB notwendig... *verwirrt sei*
EMBM ist wenn es nicht über einen "normalen" Pixelshader implementiert ist meist nur eine Einheit welche nur genau die eine für EMBM notwendige Vector2 mal 2x2Matrix multiplikation beherscht. Für einen Pixelshader braucht man schon ein bischen mehr.
Original geschrieben von Demirug
EMBM ist wenn es nicht über einen "normalen" Pixelshader implementiert ist meist nur eine Einheit welche nur genau die eine für EMBM notwendige Vector2 mal 2x2Matrix multiplikation beherscht. Für einen Pixelshader braucht man schon ein bischen mehr. Ja. Meine orginale Frage war, ob sich nicht eine Logik, die Dot3-Berechnungen und EMBM-Fähigkeiten hat, relativ einfach auf "Register Combiner" / Pixelshader der 1. Generation erweitern ließe, um damit implizit die Frage in den Raum zu stellen, wieso Kyro solche Fähigkeiten scheinbar fehlen.
Demirug
2003-09-03, 16:59:43
Original geschrieben von aths
Ja. Meine orginale Frage war, ob sich nicht eine Logik, die Dot3-Berechnungen und EMBM-Fähigkeiten hat, relativ einfach auf "Register Combiner" / Pixelshader der 1. Generation erweitern ließe, um damit implizit die Frage in den Raum zu stellen, wieso Kyro solche Fähigkeiten scheinbar fehlen.
Machbar ist das schon (so wollte ja 3dfx den Rampage bauen). Man muss eben die combiner breiter machen einen Loopback um das ganze bauen und die Latenzprobleme in den Griff bekommen.
Original geschrieben von Demirug
Machbar ist das schon (so wollte ja 3dfx den Rampage bauen). Man muss eben die combiner breiter machen einen Loopback um das ganze bauen und die Latenzprobleme in den Griff bekommen. *Nachhak* Zur PS1.1-compliance wäre also gar nicht so viel Aufwand oder gar ein Neudesign der Pipe notwendig? Ja schade, dass es Kyro3 nicht geschafft hat...
Demirug
2003-09-03, 18:44:43
Original geschrieben von aths
*Nachhak* Zur PS1.1-compliance wäre also gar nicht so viel Aufwand oder gar ein Neudesign der Pipe notwendig? Ja schade, dass es Kyro3 nicht geschafft hat...
Da wäre ein zusätzlicher Loopback nötigt gewesen sowas schüttelt man nicht so einfach aus dem Handgelenk. Von Grobdesign ist es nicht viel aber im Detail muss man die Pipe eben doch überarbeiten.
zeckensack
2003-09-03, 18:45:39
Original geschrieben von aths
Ja. Meine orginale Frage war, ob sich nicht eine Logik, die Dot3-Berechnungen und EMBM-Fähigkeiten hat, relativ einfach auf "Register Combiner" / Pixelshader der 1. Generation erweitern ließe, um damit implizit die Frage in den Raum zu stellen, wieso Kyro solche Fähigkeiten scheinbar fehlen. "Register Combiner"!=Pixelshader 1.x.
Register Combiner sind ein Teil der Hardwarebasis, der andere wichtige Teil sind die "Texture shader", deren (IMO lachhafte) Funktionsweise hier (http://oss.sgi.com/projects/ogl-sample/registry/NV/texture_shader.txt) aufgeschlüsselt ist.
Btw, daß EMBM viel kann aber wenig erlaubt, darüber habe ich mich bereits auch gewundert und beschwert. Suchfunktion ahoi :(
Demirug,
Loopback braucht's dafür wie man sieht nicht (wobei es für den Rechenteil natürlich sinnvoll ist) :)
Demirug
2003-09-03, 18:47:25
Original geschrieben von zeckensack
Demirug,
Loopback braucht's dafür wie man sieht nicht (wobei es für den Rechenteil natürlich sinnvoll ist) :)
Für EMBM oder einen PS 1.1?
zeckensack
2003-09-03, 18:57:13
Original geschrieben von Demirug
Für EMBM oder einen PS 1.1? Weder noch.
Loopbacks senken nur die Granularität (zB von 4x1 auf 2x2, siehe Geforce 3 vs Parhelia) und erhöhen dadurch die durchschnittlich nutzbare Performance bei vergleichsweise geringem Transistorcount.
Demirug
2003-09-03, 19:01:23
Original geschrieben von zeckensack
Weder noch.
Loopbacks senken nur die Granularität (zB von 4x1 auf 2x2, siehe Geforce 3 vs Parhelia) und erhöhen dadurch die durchschnittlich nutzbare Performance bei vergleichsweise geringem Transistorcount.
Ja, OK es geht auch ohne aber sehr sinnvoll ist ein solches Design IMHO nicht.
zeckensack
2003-09-03, 19:07:22
Original geschrieben von Demirug
Ja, OK es geht auch ohne aber sehr sinnvoll ist ein solches Design IMHO nicht. Ack ;)
Ich dachte nur, wir wären gerade dabei "Minimal-Anforderungen" für PS1.x-HW aufzustellen :)
loewe
2003-09-03, 19:13:13
Original geschrieben von aths
Ja. Meine orginale Frage war, ob sich nicht eine Logik, die Dot3-Berechnungen und EMBM-Fähigkeiten hat, relativ einfach auf "Register Combiner" / Pixelshader der 1. Generation erweitern ließe, um damit implizit die Frage in den Raum zu stellen, wieso Kyro solche Fähigkeiten scheinbar fehlen.
Auch wenn wir hier im Technikforum sind, deine Fragestellung ist falsch.
KYRO ist designed als sehr preiswerte Billiglösung mit der Konkurrenz GF2MX, ähnlicher Leistung und ähnlichem Featuresatz und bewußter Einsparung der T&L Einheit.
Dot3 BM konnte schon die Neon und EMBM war ein must have Feature 1999/2000 und recht einfach in KYRO zu integrieren. Für einen Chip der 2001 im Spätherbst durch KYRO III ersetzt werden sollte, K2SE war für August/September 2001 vorgesehen, war das ausreichend.
PowerVR hatte schon in der Naomi 2 (http://www.segatech.com/arcade/naomi2/index.html)eine Hardware T&L Einheit, es wäre also kein Problem gewesen.
Demirug
2003-09-03, 19:14:19
Original geschrieben von zeckensack
Ack ;)
Ich dachte nur, wir wären gerade dabei "Minimal-Anforderungen" für PS1.x-HW aufzustellen :)
Ja natürlich. Also wenn man auf den Loopback verzichten möchte brauchen wir 4 TMUs und eine Recheneinheit die das:
2*[(N*E)/(N*N)]*N - E
ohne Loopback hinbekommt. Zudem noch mindestens 7 weitere Recheneinheiten. Ich glaube das hätte jedes Transitorenlimit zum Zeitpunkt des Kyro 2 geschlagen.
Original geschrieben von zeckensack
"Register Combiner"!=Pixelshader 1.x. Hrr hrr.
Original geschrieben von zeckensack
Register Combiner sind ein Teil der Hardwarebasis, der andere wichtige Teil sind die "Texture shader", deren (IMO lachhafte) Funktionsweise hier (http://oss.sgi.com/projects/ogl-sample/registry/NV/texture_shader.txt) aufgeschlüsselt ist.Daraus wurde ich leider nicht richtig schlau :| Was sind jetzt "Texture Shader"? (Ich denke, RC verrechnen einfach gesampelte Textur-Farben... und nur die RC selbst "shaden"?)
Original geschrieben von zeckensack
Btw, daß EMBM viel kann aber wenig erlaubt, darüber habe ich mich bereits auch gewundert und beschwert. Suchfunktion ahoi :(Mit einer "flexiblen" EMBM-Lösung (und Dot3) sollten relevante (also tatsächlich genutzt) "Pixelshader-Effekte" doch auch möglich sein? Afaik kann Kyro alle möglichen BM-Arten, Pixelshader <=1.3 wird ja meist nur für BM eingesetzt, wenn ich das richtig sehe.
Original geschrieben von loewe
Auch wenn wir hier im Technikforum sind, deine Fragestellung ist falsch.
KYRO ist designed als sehr preiswerte Billiglösung mit der Konkurrenz GF2MX, ähnlicher Leistung und ähnlichem Featuresatz und bewußter Einsparung der T&L Einheit.
Dot3 BM konnte schon die Neon und EMBM war ein must have Feature 1999/2000 und recht einfach in KYRO zu integrieren. Für einen Chip der 2001 im Spätherbst durch KYRO III ersetzt werden sollte, K2SE war für August/September 2001 vorgesehen, war das ausreichend.
PowerVR hatte schon in der Naomi 2 (http://www.segatech.com/arcade/naomi2/index.html)eine Hardware T&L Einheit, es wäre also kein Problem gewesen. Wieso ist die Fragestellung "falsch"? Ich frage, wieso die Kyro, die offenbar eine recht mächtige Fixed-Function-Multitexturingpipe hat, nicht gleich sowas wie Register Combiner spendiert bekam. Davon ausgehend meinte ich, sollte die Pipe für Kyro3 dann relativ einfach Richtung Pixelshader erweiterbar sein. 1999 war EMBM meines Wissens noch kein Must-Have, der damalige (und heutige) Marktführer Nvidia bot das Feature erst seit 2001 an :bawling:
Von T&L war meinerseits gar nicht die Rede?!
zeckensack
2003-09-03, 19:36:35
Original geschrieben von aths
Hrr hrr.Nein, wenn du jetzt meinst, wovon ich meine daß du es meinst: das meinte ich nicht :)
Ich hätte sagen sollen: RCs allein befähigen nicht zu PS1.x. Die Textur-Ops fehlen.
Daraus wurde ich leider nicht schlau :|Versuch's erstmal damit:
Link sez:
Each texture shader stage runs one of 21 canned texture shader
programs. These programs support conventional OpenGL texture
mapping but also support dependent texture accesses, dot product
texture programs, and special modes.
Mit einer "flexiblen" EMBM-Lösung (und Dot3) sollten relevante (also tatsächlich genutzt) "Pixelshader-Effekte" doch auch möglich sein? Eine flexible EMBM-Einheit ist per definitionem in der Lage, 2x2 Matrix-Transformationen auf Textursamples auszuführen und Rechenergebnisse in Addressregister zu schreiben.
In anderen Worten: wenn du EMBM genügend aufbohrst, und die Anforderungen an Texturanzahl und Programmlänge halten kannst, dann ist das eine mögliche PS1.x-Hardware.
Original geschrieben von zeckensack
In anderen Worten: wenn du EMBM genügend aufbohrst, und die Anforderungen an Texturanzahl und Programmlänge halten kannst, dann ist das eine mögliche PS1.x-Hardware. Ebendth. R100 z.B. hat ja z.B. quasi "PS.1.0 mit 3 Texturen", soweit ich weiß. Macht imo Sinn.
Original geschrieben von zeckensack
Nein, wenn du jetzt meinst, wovon ich meine daß du es meinst: das meinte ich nicht :)
Ich hätte sagen sollen: RCs allein befähigen nicht zu PS1.x. Die Textur-Ops fehlen.
Versuch's erstmal damit:
Link sez:
Each texture shader stage runs one of 21 canned texture shader
programs. These programs support conventional OpenGL texture
mapping but also support dependent texture accesses, dot product
texture programs, and special modes.Zur Hülf! Das "sophisticateste", was ich je mit OpenGL machte, war Single Texturing mit Gouraud-Lighting und multiplikativem Blending :D, und das war auch nur weitgehend von Xmas abgeschriebener Code...
Original geschrieben von zeckensack
Eine flexible EMBM-Einheit ist per definitionem in der Lage, 2x2 Matrix-Transformationen auf Textursamples auszuführen und Rechenergebnisse in Addressregister zu schreiben.Ah, solche Matrix-Transformationen sind also ebenfalls noch Voraussetzung für Pixelshader 1.0, wenn ich dich richtig interpretiere, und wenn ich Demirug richtig verstehe, ist das TMU-Arbeit und hat nix mit dem Combiner zu tun. Vielleicht könnte ja jemand, der sich damit auskennt *mit dem Zaunpfahl wink* einen Artikel schreiben "Wir bauen uns einen Pixelshader 1.0". Immer schön im Urschleim anfangen, sonst glaubt man, zu verstehen, und versteht doch nicht. (So glaubte ich in meinem jugendlichen Leichtsinn, die HW-Voraussetzungen für Pixelshader 1.0 durchschaut zu haben, doch irrte ich, in meinem Wahn...)
*Nochmal wink* Interessant wäre auch ein Programm, welches PS.1.0 "hardwarenah" emuliert (also nicht performance-optimiert arbeitet, sondern quasi HW-Funktionen nachbildet.) (Reines Software-Rendering.)
loewe
2003-09-03, 20:00:18
Original geschrieben von aths
Wieso ist die Fragestellung "falsch"? Ich frage, wieso die Kyro, die offenbar eine recht mächtige Fixed-Function-Multitexturingpipe hat, nicht gleich sowas wie Register Combiner spendiert bekam. Davon ausgehend meinte ich, sollte die Pipe für Kyro3 dann relativ einfach Richtung Pixelshader erweiterbar sein. 1999 war EMBM meines Wissens noch kein Must-Have, der damalige (und heutige) Marktführer Nvidia bot das Feature erst seit 2001 an :bawling:
Von T&L war meinerseits gar nicht die Rede?!
1999 war von folgenden Anwendungen bekannt, dass sie EMBM nutzen bzw. nutzen werden:
Slave Zero von Accolade
Messiah von Interplay/Shiny
Expendable von Rage
BattleZone II von Activision/Pandemic
Hostile Waters von Rage
Rally Masters von Gremlin/Digital Illusions
AirRage von Infogrames/DID Ka-52
Jump Runner von Kuju/Simis
Final Countdown von Diversal/Sylynium
Speed Busters von Ubi Soft
Drakan von Psygnosis/Surreal
Incoming Forces von Rage
Dark Reign II von Activision/Pandemic
Black & White von EA/Lionhead
Typhoon von Infogrames/DID
Team Alligator von Kuju/Simis
Kick Engine von Kick
Descent III von Interplay/Outrage
Dungeon Keeper II von EA/Bullfrog
PowerRender von Egerter Software
(Die Liste ist von ram http://www.3dconcept.ch/artikel/bump/8.htm)
Dot3 BM war überhaupt nicht im Gespräch, insofern ist die Aussage schon richtig, wenn ein BM, dann EMBM.
Du hast recht, T&L hast du nicht genannt, aber auch KYRO III hat/hatte nur eine DX7 kompatible fest verdrahtete T&L Einheit und nichts anderes. Auch hier sollte es billig bleiben.
Erst die Serie 5 von STM, KYRO IV, hätte Pixelshader bekommen.
Das die Textureinheit von KYRO recht mächtig ist, ist ein alter Hut. Sie muss aber nun mal gesondert angesprochen werden, was einige Spielehersteller wiederum nicht taten. Z.B. hat deshalb Evolva auf KYRO niemals wirklich BM erhalten, obwohl eine KYRO kompatible Version hergestellt wurde und bei PowerVR auch existiert.
zeckensack
2003-09-03, 20:07:54
Original geschrieben von aths
Ah, solche Matrix-Transformationen sind also ebenfalls noch Voraussetzung für Pixelshader 1.0, <...>Jein. Diese Matrix-Operation ist Teil der Arbeitsweise von EMBM*. Und da man wollte, daß PS1.x einer Übermenge der bisherigen DXschen Technologie wird, mithin auch zu EMBM-fähig ist ...
Für 'richtige' Shader-HW ala R200 sind das einfach nur Rechenoperationen.
wenn ich dich richtig interpretiere, und wenn ich Demirug richtig verstehe, ist das TMU-Arbeit und hat nix mit dem Combiner zu tun.Es hat insofern erstmal weniger mit dem Combiner zu tun, weil das erste Textursample bei EMBM nicht als Farbe 'verkombiniert' wird. Das Ergebnis des DRs allerdings schon. EMBM verlässt quasi für eineinhalb Stufen die Fixed function-Pipeline, um dann sein Ergebnis in selbige zurückzufüttern.
Vielleicht könnte ja jemand, der sich damit auskennt *mit dem Zaunpfahl wink* einen Artikel schreiben "Wir bauen uns einen Pixelshader 1.0". Immer schön im Urschleim anfangen, sonst glaubt man, zu verstehen, und versteht doch nicht. (So glaubte ich in meinem jugendlichen Leichtsinn, die HW-Voraussetzungen für Pixelshader 1.0 durchschaut zu haben, doch irrte ich, in meinem Wahn...)Thilo interessiert sich auch (schon seit Monaten, drängelnd) für sowas, nur ehrlich gesagt weiß ich überhaupt nicht wo ich da anfangen soll, und wie das Niveau-technisch überhaupt zu bewältigen ist :|
*zB hier dokumentiert (http://oss.sgi.com/projects/ogl-sample/registry/ATI/envmap_bumpmap.txt)
The method exposed by this extension is to use a dependent texture
read on a bumpmap (du,dv) texture to offset the texture coordinates
<used to> read into a map on another texture unit. This (du,dv) offset is also
rotated through a user-specified rotation matrix to get the texture
coordinates into the appropriate space.
PS: Du mußt auch OpenGL dafür nicht verstehen. Bleib erstmal beim "Overview" und suche dann nach Begriffen, die dich näher interessieren. Extension-Specs sind deswegen formal hervorragende Quellen, weil sie die logische Funktionsweise definieren, und nicht nur Beispiele aufzeigen und anschließend sagen, daß das alles ganz toll ist.
Ich dachte eigentlich, das der Kyro "besseres" EMBM kann, da man es auch für prozedurales Texturing benutzen kann.
Link : http://www.pvrdev.com/pub/PC/eg/h/Fire.htm
Demo von Kristof Beets
Demirug
2003-09-03, 21:06:39
aths, Pixelshading mit 1.1-1.3 Shader besteht aus 2 Teilen.
Der erste Teil (Texture) bekommt 4 Texturekoordinaten und erzeugt daraus 4 Ausgangwerte. Der zweite Teil (Arithemetik) bekommt die 4 Ausgangswerte aus Teil 1 und zusätzlich 2 Werte welche über die Dreiecksfläche interpoliert werden. Durch Verechnung wird nun die entgültige Farbe für den Pixel erzeugt. Nur der erste Teil darf auf die im Speicher hinterlegte Texturen zugreifen.
IIIIIIIIII
I TMU I
IIIIIIIIII
|
|
TK1 ->IIIIIIIIIII->IIIIIIIIIIIIII
TK2 ->I Texture I->I I
TK3 ->I I->I I
TK4 ->IIIIIIIIIII->I Arithmetik I---> Pixelfarbe
I I
Vertexfarbe1------>I I
Vertexfarbe2------>IIIIIIIIIIIIII
In beiden Teilen läuft nun ein kleines Programm. In Teil 1 darf dieses Programm maximal 4 Anweisungen haben. Im Teil 2 sind es 8 Anweisungen. Jede der 4 Anweisungen im textureteil versorgt das entsprechende Ausgangsregister mit einem Wert. Dabei ist aber jede Anweisung fest einer Texturekoordinate und Texture zugeordnet. Die erste Anweisung darf nur die erste Texture und Koordinate benutzen. Die zweite Anweisung entsprechend die zweite Texture und Koordinate usw. Die Besonderheit ist nun das es bestimmte Anweisungen gibt welche neben der Texture und der Koordinate auch auf den Wert aus dem Ausgangsregister einer bereits ausgeführten Anweisung zurückgreifen können. Da nennt man dann "Dependet Read".
Die Programme werden nun dadurch erzeugt das man ein mathematische Model entsprechend umsetzt.
Demirug
2003-09-03, 21:17:43
Original geschrieben von Gast
Ich dachte eigentlich, das der Kyro "besseres" EMBM kann, da man es auch für prozedurales Texturing benutzen kann.
Link : http://www.pvrdev.com/pub/PC/eg/h/Fire.htm
Demo von Kristof Beets
Das ist das ganz normale EMBM nur etwas kreativer genutzt.
ScottManDeath
2003-09-03, 22:17:49
die textureshader legen fest wie die texturen gesampelt werden, mit welchen texturkoordinaten welche texel aus der texture gesampelt werden. danach kommen die werte (im allgemeinen rgba) zu den combinern die dann den rest berechnen, aber keine neuen werte aus der textur sampeln können
beispiele für die sample modi sind 1D,2D,3D,cube,rect, dependent2D, dependent3D....
bezüglich der funktion der texture shader gibts von nv ein paar schöne ppt/pdf files
http://developer.nvidia.com/object/texture_shaders.html
http://developer.nvidia.com/object/IO_20010903_3281.html
http://developer.nvidia.com/object/gdc2001_texture_shaders.html
und wie Zeckensack bereits sagte, die extension spezifikationen sind immer einen blick wert :D
Ailuros
2003-09-04, 03:08:03
Dumme Frage: hatte KYRO auch ROPs und wenn ja fuer was waeren sie gut gewesen?
Original geschrieben von Ailuros
Dumme Frage: hatte KYRO auch ROPs und wenn ja fuer was waeren sie gut gewesen? Eine ROP pro Pipe wird er schon haben...
Demirug
2003-09-04, 08:51:41
Original geschrieben von aths
Eine ROP pro Pipe wird er schon haben...
Da bin ich mir nicht so sicher. Die Funktionen des ROP sind ja bei den KYROs anders verteilt. Die Z und Stencil-Operationen werden ja schon beim HSR mit erledigt. Das Alpha-Blending als zweite wichtige Funktion des ROP ist dann an einer anderen Stelle und es ist schwer zu sagen ob die Kyros für diese Funktion nicht einfach die gleichen Combiner benutzte wie auch fürs Multitexturing.
zeckensack
2003-09-04, 09:00:46
Und Alpha-Test?
Demirug
2003-09-04, 09:09:12
Original geschrieben von zeckensack
Und Alpha-Test?
Wenn die Combiner entsprechned gebaut sind sollte das auch machbar sein. MUX spielereien eben.
loewe, ich fürchte, du verteidigst Dinge die kein Mensch angegriffen hat ;) Welche Spiele EMBM unterstützen, ist mir in diesem Thread eigentlich schnurzpiepe, mich interessiert in diesem Thread die Frage, wie flexibel EMBM-fähige Pipes sein müssen und wie viel man ändern muss um mindestens Pixelshader 1.0-Compliance zu erreichen.
Original geschrieben von loewe
1999 war von folgenden Anwendungen bekannt, dass sie EMBM nutzen bzw. nutzen werden:
Slave Zero von Accolade
Messiah von Interplay/Shiny
Expendable von Rage
BattleZone II von Activision/Pandemic
Hostile Waters von Rage
Rally Masters von Gremlin/Digital Illusions
AirRage von Infogrames/DID Ka-52
Jump Runner von Kuju/Simis
Final Countdown von Diversal/Sylynium
Speed Busters von Ubi Soft
Drakan von Psygnosis/Surreal
Incoming Forces von Rage
Dark Reign II von Activision/Pandemic
Black & White von EA/Lionhead
Typhoon von Infogrames/DID
Team Alligator von Kuju/Simis
Kick Engine von Kick
Descent III von Interplay/Outrage
Dungeon Keeper II von EA/Bullfrog
PowerRender von Egerter SoftwareDrei bis vier Namen sagen mir was. Dass angekündigt wird, irgendwelche Features zu benutzen, ist nichts neues. Ich wage mal zu behaupten, dass 3/4 dieser Spiele auf Karten, die kein EMBM unterstützen, exakt gleich aussehen. Damit möchte ich nicht den möglich Nutzen von EMBM kleinreden, im Gegenteil.
Original geschrieben von loewe
Dot3 BM war überhaupt nicht im Gespräch, insofern ist die Aussage schon richtig, wenn ein BM, dann EMBM.Afaik nutzen zumindest einige OpenGL-Spiele Dot3 BM.
Original geschrieben von loewe
Du hast recht, T&L hast du nicht genannt, aber auch KYRO III hat/hatte nur eine DX7 kompatible fest verdrahtete T&L Einheit und nichts anderes. Auch hier sollte es billig bleiben.Nirgendwo forderte ich Vertexshader 1.1 für Kyro 3... :|
Original geschrieben von loewe
Erst die Serie 5 von STM, KYRO IV, hätte Pixelshader bekommen. Darum ging es mir. Wieviel Aufwand hätte PVR, ausgehend vom Kyro treiben müssen, um den Chip PS.1.0 (oder 1.2-) compliant zu bekommen. Die Kyro-Pipe kann rechnen (Dot3) und beherrscht dependend reads (EMBM.) Warum dann nicht gleich "Register Combiner" (oder bietet PowerVR in OpenGL sowas in der Art an??)
Quasar
2003-09-04, 10:45:26
Wie war das eigentlich mit der G400 (und wohl auch G450)?
EMBM konnten sie und für D3D melden sie sogar eine dritte TMU auf ihrer Pipeline.
Ist dort 'nur' der benötigte Transistorcount für EMBM verbaut worden oder waren das auch Tricksereien mit den vorhandenen TMUs? Loop-Back gehörte ja damals nicht zu Matrox' Stärken, IIRC.
Ailuros
2003-09-04, 17:01:56
Original geschrieben von Demirug
Da bin ich mir nicht so sicher. Die Funktionen des ROP sind ja bei den KYROs anders verteilt. Die Z und Stencil-Operationen werden ja schon beim HSR mit erledigt. Das Alpha-Blending als zweite wichtige Funktion des ROP ist dann an einer anderen Stelle und es ist schwer zu sagen ob die Kyros für diese Funktion nicht einfach die gleichen Combiner benutzte wie auch fürs Multitexturing.
Ich hab ein bisschen in altem Kram nachgewuehlt und da stand irgendwo 3 ROPs drin. Ob das jetzt auch so ist, oder ob die Zahl auch Sinn macht mit der KYRO Architektur hab ich keine Ahnung.
Ailuros
2003-09-04, 17:27:37
Drei bis vier Namen sagen mir was. Dass angekündigt wird, irgendwelche Features zu benutzen, ist nichts neues. Ich wage mal zu behaupten, dass 3/4 dieser Spiele auf Karten, die kein EMBM unterstützen, exakt gleich aussehen. Damit möchte ich nicht den möglich Nutzen von EMBM kleinreden, im Gegenteil.
http://www.matrox.com/mga/3d_gaming/enhanced.cfm
(siehe EMBM flash demo rechts)
EMBM demos & stuff von Matrox:
http://www.matrox.com/mga/products/mill_g400/applications/3d_graphics.cfm
BM whitepapers von PVR:
http://www.powervr.com/pdf/BumpMapping.pdf
http://www.pvrdev.com/pub/PC/doc/f/Bump%20Mapping%20Comparison.htm
Keine Ahnung ob Du das Zeug schon gesehen hast.
Original geschrieben von loewe
1999 war von folgenden Anwendungen bekannt, dass sie EMBM nutzen bzw. nutzen werden:
Slave Zero von Accolade
Messiah von Interplay/Shiny
Expendable von Rage
BattleZone II von Activision/Pandemic
Hostile Waters von Rage
Rally Masters von Gremlin/Digital Illusions
AirRage von Infogrames/DID Ka-52
Jump Runner von Kuju/Simis
Final Countdown von Diversal/Sylynium
Speed Busters von Ubi Soft
Drakan von Psygnosis/Surreal
Incoming Forces von Rage
Dark Reign II von Activision/Pandemic
Black & White von EA/Lionhead
Typhoon von Infogrames/DID
Team Alligator von Kuju/Simis
Kick Engine von Kick
Descent III von Interplay/Outrage
Dungeon Keeper II von EA/Bullfrog
PowerRender von Egerter Software
(Die Liste ist von ram http://www.3dconcept.ch/artikel/bump/8.htm)
Dot3 BM war überhaupt nicht im Gespräch, insofern ist die Aussage schon richtig, wenn ein BM, dann EMBM.
Du hast recht, T&L hast du nicht genannt, aber auch KYRO III hat/hatte nur eine DX7 kompatible fest verdrahtete T&L Einheit und nichts anderes. Auch hier sollte es billig bleiben.
Erst die Serie 5 von STM, KYRO IV, hätte Pixelshader bekommen.
Das die Textureinheit von KYRO recht mächtig ist, ist ein alter Hut. Sie muss aber nun mal gesondert angesprochen werden, was einige Spielehersteller wiederum nicht taten. Z.B. hat deshalb Evolva auf KYRO niemals wirklich BM erhalten, obwohl eine KYRO kompatible Version hergestellt wurde und bei PowerVR auch existiert. dein hätte bekommen
soll das bedeuten serie 5 kommt auch wieder nicht?
Original geschrieben von Gast
dein hätte bekommen
soll das bedeuten serie 5 kommt auch wieder nicht?
Genau lesen: "Serie 5 von STM"
Also der Chip der gekommen wäre wenn ST Micro nicht ausgestiegen wäre.
Original geschrieben von Xmas
Genau lesen: "Serie 5 von STM"
Also der Chip der gekommen wäre wenn ST Micro nicht ausgestiegen wäre. hmm Ok :)
Aber wäre nett wen der loewe sich nochmals äußert
Ailuros
2003-09-05, 02:05:04
Serie5 die ST Micro lizenzierte hat fast gar nichts gemeinsam mit dem was wir heute unter Serie5 verstehen.
Thowe
2003-09-06, 20:33:02
Original geschrieben von Ailuros
Serie5 die ST Micro lizenzierte hat fast gar nichts gemeinsam mit dem was wir heute unter Serie5 verstehen.
Zum Glück aller, in der Form wie er damals wohl geplant war, hätte er wenn er in naher Zukunft kommt keine Daseinsberechtigung mehr am Markt. Was der kommende S5 bringen mag, wer weiss, aber deutlich mehr als der ursprünglich geplante.
Ailuros
2003-09-07, 05:59:09
Original geschrieben von Thowe
Zum Glück aller, in der Form wie er damals wohl geplant war, hätte er wenn er in naher Zukunft kommt keine Daseinsberechtigung mehr am Markt. Was der kommende S5 bringen mag, wer weiss, aber deutlich mehr als der ursprünglich geplante.
Der alte Design hatte als Ziel NV35/R350, ergo war er wohl fuer Fruehjahr 2003 projeziert.
zeckensack
2003-09-11, 19:35:00
Original geschrieben von Quasar
Wie war das eigentlich mit der G400 (und wohl auch G450)?
EMBM konnten sie und für D3D melden sie sogar eine dritte TMU auf ihrer Pipeline.
Ist dort 'nur' der benötigte Transistorcount für EMBM verbaut worden oder waren das auch Tricksereien mit den vorhandenen TMUs? Loop-Back gehörte ja damals nicht zu Matrox' Stärken, IIRC. IMO ja. Ich vermute hier eine ähnliche Spielerei wie beim R100. Dessen dritte 'TMU' ist auch unter OpenGL offengelegt, und dort sieht man auch, daß sie einen ziemlich großen Hirnschaden hat, insofern als daß sie eigentlich nur für typische EMBM-Arbeiten nutzbar ist.
Sie kann definitiv weniger als die ersten beiden 'TMUs'.
zeckensack
2003-09-11, 19:50:44
Original geschrieben von ow
Kannst du das näher ausführen? Was kann denn die dritte TMU nicht? Und ist es sicher, dass da nicht nur Treiberbugs die Funktion einschränken? Wenn das Treiberbugs sein sollen, dann sind sie seit 18 Monaten bekannt, aber trotzdem nicht gefixt worden. Ich hab's selbst gemeldet :|
Snip:
description of issue:
When the third texture environment is configured to perform a DOT3 operation, the results of this operation are wrong. More specifically, the output of the DOT3 operation is not
even
a scalar but a seemingly random full color result. This happens only on the third texture environment.
Außerdem kann die letzte Einheit keine Output-Skalierung, das habe ich irgendwann später erst herausgefunden ...
Unter D3D6 ist sowas egal, weil, wie Demirug sagte, der Treiber jedes gewünschte Setup "ohne Angabe von Gründen" ablehnen kann.
Unter OpenGL ist's eine Spec-Verletzung, weil einmal beworbene Fähigkeiten immer für alle Units gelten und zu funktionieren haben.
Ganz Spec-konform dürfte der R100 unter OpenGL entweder nur zwei Textureinheiten melden, oder er müßte auf ARB_texture_env_combine und ARB_texture_env_dot3 verzichten.
zeckensack
2003-09-11, 20:05:22
Original geschrieben von ow
Ich glaube nicht, dass ATi noch irgendwas an den R100 Treibern fixed. Und das schon seit längerem.Da muß ich dich enttäuschen. Ich habe hier zwei selbstgebaute den R100 betreffende Bug-Reports rumfliegen, die inzwischen 'resolved' sind ;)
Achso, ich dachte auch unter D3D müssten die TMUs einheitlich funktionieren, da die Caps Bits ja nicht getrennt nach TMUs spezifiziert sind. Aber wenn der Treiber da natürlich bei jedem Setup immer das letzte Wort hat.....wie war das noch mit gutem API-Design(?)....:D;) Hrhr :D
DX7 könnte anders aussehen, aber da fragen wir am besten den Experten :)
zeckensack
2003-09-11, 20:14:47
Original geschrieben von ow
Schön, das zu hören.:)
Aber zu deinem DOT3 Problem hat sich ATi wohl nicht geäussert, so in der Art "iss nich zu fixen"?Sagen wir mal so:
Wie verhält sich eine Firma, wenn sie mit einem brutalen HW-Designfehler konfrontiert wird, über den sie eigentlich nicht sprechen möchte? Nicht darüber sprechen? ;)
edit: nicht so geschehen bei ATI.
Ich kann die Antwort nicht posten (NDA-Problem), aber sie haben reagiert, und auf IMO angemessene Weise.
Demirug
2003-09-11, 20:29:23
Original geschrieben von ow
DEEEEEMIIIII :D
Kann man nicht mal in Ruhe was zwischen die Kauleiste schieben.
Bei DX7 funktioniert das in zwei stufen.
1. Die Capsbits melden was im Prinzip zur Verfügung steht.
2. Die Pipeline wird komplett konfiguriert und dann wird dieses Setup noch einmal validiert. Dafür gibt es eine Funktion.
Ja, Zecki ich weiss das das nicht unbedingt das beste ist aber wie willst du sonst den ganzen Schrott den es zu dieser Zeit gegeben hat unter einen Hut bringen wenn jeder IHV darauf besteht das seine Features benutzbar sind und der KGN ein Witz ist?
zeckensack
2003-09-11, 20:33:46
Original geschrieben von Demirug
Kann man nicht mal in Ruhe was zwischen die Kauleiste schieben.
Bei DX7 funktioniert das in zwei stufen.
1. Die Capsbits melden was im Prinzip zur Verfügung steht.
2. Die Pipeline wird komplett konfiguriert und dann wird dieses Setup noch einmal validiert. Dafür gibt es eine Funktion.
Ja, Zecki ich weiss das das nicht unbedingt das beste ist aber wie willst du sonst den ganzen Schrott den es zu dieser Zeit gegeben hat unter einen Hut bringen wenn jeder IHV darauf besteht das seine Features benutzbar sind und der KGN ein Witz ist? Aussagekräftige und bindende Caps-Bits :)
Ein Treiber muß alles fressen, was er zu können vorgibt.
Wenn es Umstände gibt, unter denen das nicht gewährleistet werden kann, dann dürfen die Features eben nicht beworben werden.
Was das für R100 bedeuten würde, habe ich oben schon geschrieben. Die 'lasche' Interpretierbarkeit von D3D war aber sicher auch ein Grund für diese Sorte Design-Sünden.
Demirug
2003-09-11, 20:45:15
Original geschrieben von zeckensack
Aussagekräftige und bindende Caps-Bits :)
Ein Treiber muß alles fressen, was er zu können vorgibt.
Wenn es Umstände gibt, unter denen das nicht gewährleistet werden kann, dann dürfen die Features eben nicht beworben werden.
Dann wäre bei den meisten Chips nichts mehr übrig geblieben. Gerade wenn es dann zu Sache wie bi oder tri in Verbindung mit bestimmten Setup gekommen ist...
Es fehlte eben an allen Ecken und Enden bei diesen Chips.
Was das für R100 bedeuten würde, habe ich oben schon geschrieben. Die 'lasche' Interpretierbarkeit von D3D war aber sicher auch ein Grund für diese Sorte Design-Sünden.
Ja dann hätte der Chip entweder kein DOT3 oder keine 3 TMUs (und damit kein Enviroment Bump Mapping) melden dürfen. Obwohl ja beides möglich ist.
zeckensack
2003-09-11, 20:53:04
Original geschrieben von Demirug
Dann wäre bei den meisten Chips nichts mehr übrig geblieben. Gerade wenn es dann zu Sache wie bi oder tri in Verbindung mit bestimmten Setup gekommen ist...
Es fehlte eben an allen Ecken und Enden bei diesen Chips.Die Filter-Caps sind eine harte Nuß, zugegeben. Vielleicht wäre hier eine Extrawurst machbar, die die möglichen Bi/Tri-Kombinationen bewirbt.
Oder ganz anders, die API interpretiert die Filter nur als 'application hints', so wie es heute (leider) gängige Praxis ist.
Ja dann hätte der Chip entweder kein DOT3 oder keine 3 TMUs (und damit kein Enviroment Bump Mapping) melden dürfen. Obwohl ja beides möglich ist. So wie er letztendlich auf den Markt kam: ja.
Ich behaupte aber doch, daß der R100 eine vollwertige dritte TMU gehabt hätte (oder eben garkeine), wäre DX6/7 nicht so unsäglich lasch.
Demirug
2003-09-11, 21:04:37
Original geschrieben von zeckensack
Die Filter-Caps sind eine harte Nuß, zugegeben. Vielleicht wäre hier eine Extrawurst machbar, die die möglichen Bi/Tri-Kombinationen bewirbt.
Oder ganz anders, die API interpretiert die Filter nur als 'application hints', so wie es heute (leider) gängige Praxis ist.
Ja, da gab es aber noch mehr witzige Sachen an die ich mich gar nicht mehr alle erinnere.
So wie er letztendlich auf den Markt kam: ja.
Ich behaupte aber doch, daß der R100 eine vollwertige dritte TMU gehabt hätte (oder eben garkeine), wäre DX6/7 nicht so unsäglich lasch.
MS hatte mit DX6/7 IMHO noch nicht genügend normende Kraft um die Hersteller auf eine Linie zu bekommen.
zeckensack
2003-09-11, 21:41:21
Original geschrieben von Demirug
MS hatte mit DX6/7 IMHO noch nicht genügend normende Kraft um die Hersteller auf eine Linie zu bekommen. ATI und Matrox haben ihre HW sicher nicht auf Glide ausgerichtet. Das R100-Design widerspricht dem OpenGL-Konzept "Features sind auf allen Stages gleich".
Wenn das nicht nach den Bedürfnissen von D3D6/7 ausgerichtet ist, wonach dann?
Damals wurde ja noch dieser Mythos von wegen "Direct3D ist eine 3D-API ganz speziell für Spiele" verbreitet, und die IHVs haben auch schön mitgespielt.
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.