T&L-Chip? [Archiv] - 3DCenter Forum

huha

2003-06-25, 17:39:10

Hallo!

Ich wollte hier mal eine Frage, die mich schon längere Zeit beschäftigt, reinstellen.
Transform&Lightning mag ja "ganz nett" sein, aber irgendwie wundert es mich, weshalb es für sowas nicht einen extra Chip aif der Grafikkarte gibt. Da ja - soweit ich das bisher verstanden habe - beim T&L immer die gleichen Befehle angewendet werden, könnte man nicht einfach einen speziellen T&L RISC-Prozessor auf die Grafikkarte integrieren, der dann natürlich höher getaktet wäre als der "Hauptchip"

Ist nur so n Gedankenspiel, aber was spricht dafür bzw. dagegen? Ich bin kein Grafikkarten-Guru, aber vielleicht hab ich ja einen wichtigen Aspekt übersehen :)

-huha

robbitop

2003-06-25, 18:24:57

das hatte 3dfx mit dem Spectre vor und es kamen mal Gerüchte, dass nVidia den VS Array in einen höher getakteten TTNL Chip packt (TrueTransformnLightening).

Doch TNL und auch übliche Vertexshader sind kalter Kaffee, bald werden Pixelshader und Vertexshader eines, da sie viele Gemeinsamkeiten haben. Sicher auch das könnte in einen Extra Chip, doch die Boards würden schier unbezahlbar werden. Weil: 2x Chips 2x Packagings, komplexeres PCB. Und viel helfen tut es auch nicht. Das erkannte damals auch 3dfx und hat sich mit dem Fusion auch für einen hoch integrierten singlechip entschieden, es ist ökonomisch einfach das beste.

Und es hängt sowieso viel vom Design ab, wie gut die Yields und die Takte sind...nicht nur von transistoranzahlen und Fertigung und dessen Prozess ;)

Gast

2003-06-25, 20:01:27

Haben die Grafikchips nicht eh genug Geometrieleistung für Spiele?
Würde sich eine schnellere Geometrie-Einheit also gar nicht lohnen?

robbitop

2003-06-25, 20:04:41

immo sind Füllrate und auch bandbreite bestimmend

aths

2003-06-25, 22:19:09

Original geschrieben von huha
Transform&Lightning mag ja "ganz nett" seinLighting (Beleuchtung) nicht Lightning (Blitzen.)

robbitop

2003-06-25, 22:20:55

sagmal Aths, musst du nich irgendwas lernen? :D

oder wie isses bei euch in Wismar mitm Studieren ? ;)

Ailuros

2003-06-26, 02:00:13

...das hatte 3dfx mit dem Spectre vor und es kamen mal Gerüchte.

Jein. RISC zwar schon, aber die T&L Einheiten bei Spectre (Sage) und Fear (SageII), waren nicht im chip integriert.

Doch TNL und auch übliche Vertexshader sind kalter Kaffee, bald werden Pixelshader und Vertexshader eines, da sie viele Gemeinsamkeiten haben.

Um auch zu keinen "stalls" zu kommen mit sehr langen Shadern. Obwohl es natuerlich workarounds gibt, halten die wohl auch nicht fuer immer wenn Shader immer komplizierter und laenger werden. Beispiel: ein sehr einfacher VS mit einem sehr komplizierten PS in einer Szene. In dem Fall besteht die Gefahr dass der VS auf die Vollendung des PS warten muss, was wohl den ganzen Prozess aufhalten kann.

könnte man nicht einfach einen speziellen T&L RISC-Prozessor auf die Grafikkarte integrieren, der dann natürlich höher getaktet wäre als der "Hauptchip"

Wie schon gesagt die alten festgedrahteten dx7 T&L Einheiten sind ausgestorben, wobei heutzutage moderne chips die DX7 T&L Befehle in den Vertex Shader Einheiten durchfuehren. Das alles ist sowieso schon "auf" dem chip integriert.

Was wir hier schon mal besprochen haben, waere vielleicht eine Moeglichkeit einen integrierten "Co-Prozessor" fuer den Shader-Wirrwarr zu entwickeln; vereinfacht sowie in etwa eine Art vollprogrammierbarer Prozessor Einheit, "getrennt" aber immer noch im chip "integriert". Keine Ahnung ob es eine gute Loesung sein koennte fuer die Zukunft, wenn die Transistoren-Anzahlen staendig erhoehen.

Das mit den asynchronen Taktraten ist wohl so ein Kapitel fuer sich. Ich persoenlich schaetze jedoch (wenn asynchron auch keine Probleme mit sich fuert), dass wenn wie im obrigen Beispiel den Geometrie-Prozessor teilweise "entkoppelt" vom rasterizer, dass eher der letztere das groessere Potential haben wird fuer hoehere Taktraten.

(Frei zur Korrigierung gestellt wie immer :) )

Ailuros

2003-06-26, 02:04:44

Original geschrieben von Gast
Haben die Grafikchips nicht eh genug Geometrieleistung für Spiele?
Würde sich eine schnellere Geometrie-Einheit also gar nicht lohnen?

Was ist genug bei Graphikchips? :D

Frage: muss man die CPU aufruesten nach einiger Zeit oder nicht wenn man staendig die letzten Schreie spielt und wenn ja warum?

anddill

2003-06-26, 03:09:28

PowerVR hat Boards für Spielhallenautomaten mit separaten T&L-Chips gebaut. Stand mal irgendwo im Mitrax-Forum.

betasilie

2003-06-26, 03:41:59

Original geschrieben von anddill
PowerVR hat Boards für Spielhallenautomaten mit separaten T&L-Chips gebaut. Stand mal irgendwo im Mitrax-Forum.
Profi-3Dkarten hatten früher auch sepearte T&L-Chips.

... Das PCB wäre viel zu teuer bei einer getrennten Lösung. Rate mal wieso die Mainboards auf SIS-Basis z.Zt. so günstig sind.

Das PCB diesewr Boards ist günstig, da North und Southbridge auf einem Chip sind. Der "Chipsatz" ist garnicht mal so günstig, aber die Hersteller können massig beim PCB sparen.

Demirug

2003-06-26, 07:05:51

Original geschrieben von Ailuros
Um auch zu keinen "stalls" zu kommen mit sehr langen Shadern. Obwohl es natuerlich workarounds gibt, halten die wohl auch nicht fuer immer wenn Shader immer komplizierter und laenger werden. Beispiel: ein sehr einfacher VS mit einem sehr komplizierten PS in einer Szene. In dem Fall besteht die Gefahr dass der VS auf die Vollendung des PS warten muss, was wohl den ganzen Prozess aufhalten kann.

Das ist jetzt schon ein akutes Problem und wird wie du schon sagst wohl erst mal noch schlimmer werden.

Was wir hier schon mal besprochen haben, waere vielleicht eine Moeglichkeit einen integrierten "Co-Prozessor" fuer den Shader-Wirrwarr zu entwickeln; vereinfacht sowie in etwa eine Art vollprogrammierbarer Prozessor Einheit, "getrennt" aber immer noch im chip "integriert". Keine Ahnung ob es eine gute Loesung sein koennte fuer die Zukunft, wenn die Transistoren-Anzahlen staendig erhoehen.

Die Vertex und Pixelshader werden ja immer mehr zu solchen "Co-Prozessoren".

Das mit den asynchronen Taktraten ist wohl so ein Kapitel fuer sich. Ich persoenlich schaetze jedoch (wenn asynchron auch keine Probleme mit sich fuert), dass wenn wie im obrigen Beispiel den Geometrie-Prozessor teilweise "entkoppelt" vom rasterizer, dass eher der letztere das groessere Potential haben wird fuer hoehere Taktraten.

(Frei zur Korrigierung gestellt wie immer :) )

Unterschiedliche Taktrate in unterschiedlichen Teilen der Pipeline sind eigentlich kein Problem nur müssen diese aufeinader abgestimmt sein (das doppelte, die hälfte usw) oder man braucht Cachespeicher der Read/Write Ports hat welche mit unterschiedlichem Takt laufen können.

Ailuros

2003-06-26, 09:51:41

Original geschrieben von anddill
PowerVR hat Boards für Spielhallenautomaten mit separaten T&L-Chips gebaut. Stand mal irgendwo im Mitrax-Forum.

Ach ja die Naomi2 Systeme meinst Du wohl mit dem uralten Elan chip (der aber sehr stark war fuer seine Zeit; 10M Polys/sec mit 6 HW lights auf Papier, aber noch staerker da er von der CPU des Systems aufgehalten wurde). Naomi2 hat sowieso zwei Serie2 rasterizer noch dazu; bei Arcade Maschinen ist ja auch der Preis kein Problem.

Nachtrag:

Zwischen TBDR's und IMR's gibt es da keine grosse Unterschiede. Fuer beide macht seit einiger Zeit ein getrennter Geometrie-chip keinen Sinn mehr.

Ailuros

2003-06-26, 10:01:07

Die Vertex und Pixelshader werden ja immer mehr zu solchen "Co-Prozessoren".

Schon; ich bin mir sicher dass Du Dich an die Debatte erinnern kannst, mit den Fragen was passiert wenn Transistoren Anzahl durch die Shader ueber die Kapazitaeten der Herstellungs-Prozesse steigen wuerden. Ich persoenlich sehe da momentan noch kein Problem, aber in einem theoretischen Fall wo wir heute schon 250M Trans brauchen wuerden und 0.09 unmoeglich waere, wuerde das aufspalten in z.b. 100+150M vielleicht helfen, zumindest in Theorie ;)

Unterschiedliche Taktrate in unterschiedlichen Teilen der Pipeline sind eigentlich kein Problem nur müssen diese aufeinader abgestimmt sein (das doppelte, die hälfte usw) oder man braucht Cachespeicher der Read/Write Ports hat welche mit unterschiedlichem Takt laufen können.

Hmmmm also wuerde es dann theoretisch so aussehen?

Core: 900-1000MHz
Co-Prozessor: 450-500MHz

aber nach Deinem letzten Post klingt es anders rum eher besser:

Core: 450-500MHz
Co-Prozessor: 900-1000MHz

Demirug

2003-06-26, 11:06:28

Original geschrieben von Ailuros
Schon; ich bin mir sicher dass Du Dich an die Debatte erinnern kannst, mit den Fragen was passiert wenn Transistoren Anzahl durch die Shader ueber die Kapazitaeten der Herstellungs-Prozesse steigen wuerden. Ich persoenlich sehe da momentan noch kein Problem, aber in einem theoretischen Fall wo wir heute schon 250M Trans brauchen wuerden und 0.09 unmoeglich waere, wuerde das aufspalten in z.b. 100+150M vielleicht helfen, zumindest in Theorie ;)

Eigentlich das falsche Forum weil doch alles sehr spekulativ. Ich denke das bevor eine Chipsatz Lösung (unterschiedliche Chips arbeiten zumsammen) kommt wir wieder MultiChip (2 oder mehr gleiche Chips sehen) Lösungen sehen werden. Von der Pixelshader/Fillrate Leistung stellt das ja heute schon kein Problem dar. Man müsste allerdings noch das Speicher und Vertexshader problem lösen.

Für den Speicher stelle ich mir das eine Lösung à la Opteron vor. Und das man die Vertexshaderleistung besser nutzten kann sollte durch einen zweiten Crosslink zwischen den Chips zum austauschen von Primitive informationen möglich sein.

Ich hätte da durchaus einige Ideen aber das ist hier wirklich zu abgehoben.

Hmmmm also wuerde es dann theoretisch so aussehen?

Core: 900-1000MHz
Co-Prozessor: 450-500MHz

aber nach Deinem letzten Post klingt es anders rum eher besser:

Core: 450-500MHz
Co-Prozessor: 900-1000MHz

Diese Frage würde wohl dadurch beantwortet werden welche Teile auf welchen Chip kommen.

Habe mir erlaubt, einen Schreibfehler zu berichtigen der das Verständis erheblich erschwert ("aller" - "à la") — aths

zeckensack

2003-06-27, 08:27:57

Brutale FF-T&L-Leistung brauchen die IHVs eigentlich nur für Spec Viewperf/ugs, um mit ihren Profikarten protzen zu können (ugs ist auch ein sehr schönes Beispiel für die Workstation-typische schlechtest mögliche Nutzung von Hardware-Ressourcen; gemischte Wortkomposition Substantiv/Adjektiv via Bindestrich rult alles weg; überhaupt rulen Bindestriche ziemlich stark).

Für 'vernünftige' Grafikapplikationen, wie es eben Spiele sind, ist das alles völlig übertrieben ... mal abgesehen vom fabulösen sceletal animation vertex shader für fuffzich Knochen, den ich aber erstmal sehen will, bevor ich ihn als Rechtfertigung für 4 VS @ 300+MHz benutze.

Ich habe so den Eindruck, dieser Teil der Pipeline wird mit Absicht total überdimensioniert, weil man dadurch der Problematik der gegenseitigen Blockade mehr oder weniger elegant aus dem Weg geht: bei so viel VS-Brutalität ist Geometrie nie der Flaschenhals. Um Entkopplung braucht man sich dann automatisch keine Gedanken mehr zu machen.

Füllratenlimitierung ist sowieso altbekannt und relativ angenehm, mit dem extra Vorteil, daß sogar CB und deren Leser damit umgehen können ("Ei, da muscht 'alt d'Aufläs nunnersetzet!").

Demirug

2003-06-27, 08:58:47

Original geschrieben von zeckensack
Ich habe so den Eindruck, dieser Teil der Pipeline wird mit Absicht total überdimensioniert, weil man dadurch der Problematik der gegenseitigen Blockade mehr oder weniger elegant aus dem Weg geht: bei so viel VS-Brutalität ist Geometrie nie der Flaschenhals. Um Entkopplung braucht man sich dann automatisch keine Gedanken mehr zu machen.

Da wiederspreche ich jetzt aber mal einfach. ;)

nehmen wir uns mal den R300 mit seinen 4 Vertexshader als Beispiel. Die übliche Positionstransformation ist eine Vector4*4x4Matrix Multiplikation = 4 Operationen pro Vertex. Da man in der Regel davon ausgeht das ein VS eine Operation pro Takt ausführt können wir normalisiert jeden Takt eine Vertexposition bestimmen. Gehen wir nun davon aus das die Culllogik des Chips pro Takt ein Dreieck verwerfen kann so können die 4 VS nur bei der Verwendung von Strips überhaupt schnell genug Vertexpositionen berechnen. Da ein Vertexshader programm aber ja aber nicht nur aus dem Berechnen der Position besteht sind selbst 4 VS nicht in der Lage in einer Cullsituation das Trisetup schnell genügend zu füttern was dann auch dazu führt das über kurz oder lang (abhängig vom Grad der Entkopplung und der Cachegrössen) auch der Rest der Pipeline (Pixelshader, ...) verhungert. Im Anbetracht das bei typischen geschlossenen Objekten durchaus die hälfte der Dreiecke mit Backfaceculling entfernt wird kommen Cullsituationen durchaus häufiger vor.

Aus diesem Grund plädiere ich ja auch für ein 2 Phasen Vertexprocessing.

1 Phase: Nur die Bestimmung der Position.

2 Phase (Nach dem Culling und dem Z-Test) Berechnen des Restprogramms.

Dummerweise braucht man dafür wieder eine komplexe Steuerlogigc welche die Resourcen (VS) auf diese zwei Aufgaben dynamisch verteilt.

Einem (TB)DR sollte so etwas noch mehr Speed bringen.

zeckensack

2003-06-29, 21:12:15

:D

Radeon 9800Pro:
Maximal 380MVerts/s ('brutto')

Da mache ich jetzt mal 60 MTris/s draus (2xOverdraw, 50% backfaces, nicht ganz optimale Strips).

Ich ziehe weitere 25% ab, für nicht ganz optimales Culling der Applikation.
=>45MTris/s sichtbare Dreicke ('netto').

Nehmen wir mal 'ne Bildschirmauflösung von 1600x1200

Tris/frame fps sichtbare Pixel pro Dreieck
100k 450 20
500k 90 4
1M 45 2

Sieht sauber aus. Die Größe der Dreiecke wird bei acht Pipes früher zum Problem, als die pure Geschwindigkeit der Geo-Einheit. Das ganze wird noch übler, wenn ich die Auflösung senke. Hier braucht man vielleicht Maßnahmen, um auch extrem kleine Dreiecke effizient durch die Pixelpipes zu kriegen, aber an roher Transformationsleistung mangelt es dieser Karte sicher nicht.

Das ganze wird natürlich spannender, wenn komplexere VS zu berechnen sind. Hmmm ... 20 Takte pro Vertex?

Tris/frame fps sichtbare Pixel pro Dreieck
100k 22,5 20
500k 4,5 4
1M 2,25 2

Das sieht schon relativ schlimm aus, zugegeben.
Bitte trotzdem daran denken, die 100k Tris sind 'netto', laut international anerkannten Spiele-und-Frühstücksflocken-Karton-Aufdruck-Richtlinien sind das ~600k Tris/frame.

Demirug

2003-06-29, 21:19:33

Zeckensack, was machst du den da? Das ist ja gandenloss über eine Sekunde gemittelt und alle Häufungen unterschlagen.

Gerade diese Häufungen mit einer einseitigen Belastung sind es ja was richtig schmerzhaft ist.

zeckensack

2003-06-29, 21:34:06

Original geschrieben von Demirug
Zeckensack, was machst du den da? Das ist ja gandenloss über eine Sekunde gemittelt und alle Häufungen unterschlagen.Ja klar :D
'Theoretische' Benchmarks eben :D

ernesto.che

2003-07-05, 01:01:50

Es gab übrigens auch mal eine Voodoo2 mit einer externen T&L Einheit. Habe die Quelle nicht mehr, waren aber japanische Freaks.

Ailuros

2003-07-05, 03:29:18

Dummerweise braucht man dafür wieder eine komplexe Steuerlogigc welche die Resourcen (VS) auf diese zwei Aufgaben dynamisch verteilt.

So kompliziert kann es nun auch wieder nicht sein, ausser Du meinst ausschliesslich VS Einheiten wie sie im R3xx ausgelegt sind. Wird das ganze mit multi-arrays und multi-threading nicht vereinfacht?

Uebrigens wieso soll ein TBDR da schneller sein?

Demirug

2003-07-05, 08:01:40

Original geschrieben von Ailuros
So kompliziert kann es nun auch wieder nicht sein, ausser Du meinst ausschliesslich VS Einheiten wie sie im R3xx ausgelegt sind. Wird das ganze mit multi-arrays und multi-threading nicht vereinfacht?

Uebrigens wieso soll ein TBDR da schneller sein?

Ob nun Einzelne Einheiten, Multi-Arrays oder Multi-Threading benutzt wird ist dabei eigentlich egal. Die schwierigkeit leigt darin zur gleichen Zeit mehr als VS-Programm aktiv sein muss und entsprechend auch alle Einheiten welche sich in der Pipeline vor dem VS befinden in der Lage sein müssen für unterschiedliche Programme Daten zu liefern.

Ein TBDR könnte dabei aus dem gleichen Grund schneller sein wie auch beim Pixelprocessing. Durch Ausnutzung der Regel: Was man nicht sieht braucht man auch nicht zu berechnen. Zum Tillen und Binning braucht man nur die Position. Verzögert man nun die Berechnung des Rests so lange bis feststeht das ein Vertex wirklich von einem sichtbaren Dreieck benutzt wird spart man die zusätzliche Berechungen für alle nicht sichtbaren Verticen ein. Bei einem Z-Pass wäre aber wieder kein unterschied zwischen IMR und TDDR drin.

2003-07-05, 10:37:21

Original geschrieben von ernesto.che
Es gab übrigens auch mal eine Voodoo2 mit einer externen T&L Einheit. Habe die Quelle nicht mehr, waren aber japanische Freaks.

Du meinst die hier:

http://www.golem.de/0006/8307.html

http://www.hardware.no/nyheter/juni00/v2t&l.html

Ailuros

2003-07-05, 14:56:21

Ein TBDR könnte dabei aus dem gleichen Grund schneller sein wie auch beim Pixelprocessing. Durch Ausnutzung der Regel: Was man nicht sieht braucht man auch nicht zu berechnen. Zum Tillen und Binning braucht man nur die Position. Verzögert man nun die Berechnung des Rests so lange bis feststeht das ein Vertex wirklich von einem sichtbaren Dreieck benutzt wird spart man die zusätzliche Berechungen für alle nicht sichtbaren Verticen ein. Bei einem Z-Pass wäre aber wieder kein unterschied zwischen IMR und TDDR drin.

http://www.beyond3d.com/forum/viewtopic.php?p=10148&highlight=bounding+boxes#10148

http://www.beyond3d.com/forum/viewtopic.php?p=111108&highlight=bounding+boxes#111108

Ob nun Einzelne Einheiten, Multi-Arrays oder Multi-Threading benutzt wird ist dabei eigentlich egal. Die schwierigkeit leigt darin zur gleichen Zeit mehr als VS-Programm aktiv sein muss und entsprechend auch alle Einheiten welche sich in der Pipeline vor dem VS befinden in der Lage sein müssen für unterschiedliche Programme Daten zu liefern.

Entschuldige aber ich hab es immer noch nicht verstanden.

Nochmal:

Dummerweise braucht man dafür wieder eine komplexe Steuerlogigc welche die Resourcen (VS) auf diese zwei Aufgaben dynamisch verteilt.

Was ich hier nicht verstehen kann, ist warume die oben erwaehnten VS Resourcen nicht durch multithreading dynamisch verteilt werden koennen (irgendwo hab ich es mal wieder geschafft, total Sachen durcheinander zu bringen arggghhh...).

Demirug

2003-07-05, 15:28:22

Original geschrieben von Ailuros
http://www.beyond3d.com/forum/viewtopic.php?p=10148&highlight=bounding+boxes#10148

http://www.beyond3d.com/forum/viewtopic.php?p=111108&highlight=bounding+boxes#111108

Ja so ein Verfahren habe ich auch schon mal irgendwo erwähnt. Das ist einer der Punkte wo ein IMR gegenüber einem TDBR einen klaren vorteil haben kann.

Entschuldige aber ich hab es immer noch nicht verstanden.

Nochmal:

Dummerweise braucht man dafür wieder eine komplexe Steuerlogigc welche die Resourcen (VS) auf diese zwei Aufgaben dynamisch verteilt.

Was ich hier nicht verstehen kann, ist warume die oben erwaehnten VS Resourcen nicht durch multithreading dynamisch verteilt werden koennen (irgendwo hab ich es mal wieder geschafft, total Sachen durcheinander zu bringen arggghhh...).

Ich glaube da haben wir uns missverstanden. Ich bezog mich mit der "komplexe Steuerlogic" auf alles was notwendig wäre um verzögertes Vertexprocessing zu betreiben. Der VS ist ja nur ein Teil der dabei zum tragen kommt.

Sobald Dynamic-Branchs (VS2.X, 3.0) ins Spiel kommen braucht man sowieso sowas wie Multithread fähiges Vertexprocessing weil ja jede Vertice einen anderen Weg durch den Code nehmen kann. Aber hier hätte man immer noch den Vorteil das man nur ein Programm hat. Bei verzögerten Vertex-Processing muss man mindestens 2 unterschiedliche Programme gleichzeitig laufen lassen.