Archiv verlassen und diese Seite im Standarddesign anzeigen : Wofür verbraten die NV3x ihre Transistoren?
egdusp
2003-09-14, 19:28:45
Wie kommt es, dass die NV3x so viel mehr Transistoren als die R3xx haben, obwohl diese:
- Gleich viel oder mehr Pixel ausgeben können (AA Sampler)
- sie das aufwändigere Tri Setup haben (RG AA)
- sie mehr PS2.0 Einheiten haben (doppelt so viele?)
- sich verhältnismäßig höher takten lassen (RV350 - NV31)
Liegt es an der fp32 Fähigkeit? An den PS2.0+ Fähigkeiten?
An der Unfähigkeit der NV Ingenieure?
mfg
egdusp
StefanV
2003-09-14, 19:54:48
Original geschrieben von egdusp
Wie kommt es, dass die NV3x so viel mehr Transistoren als die R3xx haben, obwohl diese:
- Gleich viel oder mehr Pixel ausgeben können (AA Sampler)
- sie das aufwändigere Tri Setup haben (RG AA)
- sie mehr PS2.0 Einheiten haben (doppelt so viele?)
- sich verhältnismäßig höher takten lassen (RV350 - NV31)
Liegt es an der fp32 Fähigkeit? An den PS2.0+ Fähigkeiten?
An der Unfähigkeit der NV Ingenieure?
mfg
egdusp
Sagen wirs mal andersrum:
das liegt daran, daß NV mehr alten Schrott mit sich rumschleppt, als es ATI jemals getan hat...
Demirug
2003-09-14, 20:21:45
Was die AA-Sampler/ROPs angeht sind die unterschiede scheinbar gar nicht so gross wie man glaubt. Messerergebnisse lassen einen glauben das R300/R350 nur über 2 Z und 3 Color ROPs pro Pixeloutput verfügt. Beim NV30 haben so wie es aussieht von beiden jeweils 4 pro Output.
NV3X Chips haben ein komplexeren AF Rechner.
32 Bit sind 33% mehr als 24 Bit was sich entsprechend auch in der Transitorenanzahl niederschlägt. Die zusätzlichen Features schlagen auch noch ein bischen zu und der native Sinus/Cosinus Support dürfte auch ein bischen was kosten.
Dann haben wir da noch einen VS der fast 3.0 beherscht und wohl immer noch ein paar Transitoren zum Beschleunigen von HT&L verbrät.
Das läbert sich so langsam zusammen.
Salvee
2003-09-15, 07:00:55
Original geschrieben von Demirug
32 Bit sind 33% mehr als 24 Bit was sich entsprechend auch in der Transitorenanzahl niederschlägt.
Ich meine, bei B3D gelesen zu haben, dass für 32FP zwei 16FP Pipelines zusammengeschaltet werden müssen.
Damit wäre dieses Feature kein 'Transistorengrab'.
Möglich, dass mir diese Info noch aus frühen NV3x Spekulationen im Gedächtnis ist.
Demirug
2003-09-15, 07:50:44
Original geschrieben von Salvee
Ich meine, bei B3D gelesen zu haben, dass für 32FP zwei 16FP Pipelines zusammengeschaltet werden müssen.
Damit wäre dieses Feature kein 'Transistorengrab'.
Möglich, dass mir diese Info noch aus frühen NV3x Spekulationen im Gedächtnis ist.
Das wäre mir neu. Das hat man mal ganz an Anfang vermutet.
robbitop
2003-09-15, 10:29:27
es ist afair bekannt, dass die FPUs 32bit"tig" ausgelegt worden sind. Wieso solch ein Performancedrop entsteht, weiss ich leider nicht. Sicher irgendein Flaschenhals in der Pipeline.
Zur Transistoranzahl: Ich darf betonen, dass nVidia damals um den NV30 lauffähig zu bekommen eine Menge an Massetransistoren verbauen durfte...nicht wenige wie ich gehört habe...
aber kA inwiefern die im NV35/40 noch vorhanden sind. Ich denke mal dass im NV35 weniger davon da sind und sich das Delta der realen Transistoren zw NV30 - NV35 weiter erhöt. Also mehr als Detla 5 Mio.
Tja und vieleicht hat der NV38 wieder ein paar Massetransistoren mehr für höheren Takt...ich weiss es nicht
Hmmm, was sind bitte "Massetransitoren" ?
Gruss mrdigital
robbitop
2003-09-15, 11:10:25
Transistoren, die die Signale verstärken afaik
aber ich glaube Demirug kann dies besser beantworten als ich
[ncp]EasyChiller
2003-09-15, 11:14:14
ich vermute einfach mal Transistoren ohne weitere direkte Funktion außer eben mal irendwo ein Signal (Störsignale wegfiltern) auf Masse (quasi Null-Level) zu ziehen und somit für eine bessere Signalqualität im Chip zu sorgen. ... so ganz genau kann ich das allerdings nicht sagen - bin ja kein Silicon-Bäcker! :bäh:
Also wenn die "Massetransitoren" in Wahrheit Transfergatter (zur Signalregeneration) sind, warum nennt ihr das Kind nicht so, statt nebulöse (und evtl. auch falsche?) Begriffe zu verwenden (und damit nicht gerade das Niveau zu heben) ?
Nichts für ungut, ich will hier ja keinen Streit vom Zaun brechen, bin aber dafür, dass man wenn man schon über solche spezifischen Details spricht, auch wissen sollte worum es dabei geht ( nicht das ich hier nun der "Chip Interna Pro" wäre ;) )...
Gruss mrdigital
robbitop
2003-09-15, 11:28:40
das ist der Ausdruck der in der Szene und afaik unter Entwickeln geläufig ist, ergo nicht unsere Erfindung.
Weiterhin haben wir uns die Bedeutung selbst hergeleitet (für die Richtigkeit der Definition kann ich nicht garantieren).
Achja sorry für meine "Unwissenheit" und Niveaulosigkeit :D
Jo passt schon ;) Ich will ja nicht dich persönlich anmachen ( wegen "Niveaulosigkeit" :) ) Es war sozusagen ein allgemeingültiger "Hinweis" der für mich ja auch gilt (ich rede ja auch viel bis zum abend :) ).
Weiss einer von euch, in welcher Prozesstechnologie nV und Konsorten ihre Chips backen (CMOS oder ähnliches ?) ?
Gruss mrdigital
robbitop
2003-09-15, 11:42:44
kein Problem =)
ich glaube es waren 3 Arten die Verbaut waren....leider scheint Demi nich dazu sein
StefanV
2003-09-15, 11:54:23
Original geschrieben von Gast
Weiss einer von euch, in welcher Prozesstechnologie nV und Konsorten ihre Chips backen (CMOS oder ähnliches ?) ?
Gruss mrdigital
ATI: 150nm, ev. Copper interconnects ev auch nicht (bin mir nicht sicher)
nV: gedacht war für den nV30 130nm, low-K (copper interconnects).
Geworden ists 130nm mit copper interconnects.
der nV34 wird aber noch in 0,15µ gefertigt.
Beide fertigen bei TMSC, nur ATI lässt deren RV2x0 bei UMC fertigen.
robbitop
2003-09-15, 11:59:59
äääh Stefan, wenn du genauer liesst, will er NICHT den Fertigungsprozess sondern die Art der Schaltkreise wissen (CMOS ist nämlich keine Fertigungstechnik in diesem Sinne)
Tigerchen
2003-09-15, 15:52:20
Original geschrieben von Salvee
Ich meine, bei B3D gelesen zu haben, dass für 32FP zwei 16FP Pipelines zusammengeschaltet werden müssen.
Damit wäre dieses Feature kein 'Transistorengrab'.
Möglich, dass mir diese Info noch aus frühen NV3x Spekulationen im Gedächtnis ist.
Hätte man sich eigentlich nicht denken können daß 32 Bit FP für den praktischen Einsatz zu langsam sind?
technisch spricht nichts dagegen einen 32bit Floating Point unit zu bauen die genauso schnell (oder schneller) ist wie eine 16bit Einheit. Dabei ist es natürlich wesentlich aufwendiger eine 32bit Einheit zu bauen als eine 16bit Einheit. Wenn man nun zwei 16 bit Einheiten zu einer 32 bittigen verküpft, halbiert man seine Rechenleistung (wobei auch das nicht so direkt aufgehen muss, es gibt Recheneinheiten die sich nicht einfach so aus zwei Hälften zusammen setzten lassen (z.B. ein Multiplizierer, der in einem Takt das Ergebniss liefern soll) )
Wie gesagt, alles nur eine Frage des (Transistor)Aufwands, den man betreiben will...
Gruss mrdigital
robbitop
2003-09-15, 16:37:57
wie gesagt die FPUs sind mit 128bit Präzision ausgestattet..es wird irgendwo in der Pipeline haken
Kampf Ameise
2003-09-15, 18:12:03
Original geschrieben von egdusp
Wie kommt es, dass die NV3x so viel mehr Transistoren als die R3xx haben, obwohl diese:
- Gleich viel oder mehr Pixel ausgeben können (AA Sampler)
- sie das aufwändigere Tri Setup haben (RG AA)
- sie mehr PS2.0 Einheiten haben (doppelt so viele?)
- sich verhältnismäßig höher takten lassen (RV350 - NV31)
Liegt es an der fp32 Fähigkeit? An den PS2.0+ Fähigkeiten?
An der Unfähigkeit der NV Ingenieure?
mfg
egdusp
die VooDoo Priester lassen niemanden ungeschoren davon , deshalb :D *eg*
Original geschrieben von robbitop
äääh Stefan, wenn du genauer liesst, will er NICHT den Fertigungsprozess sondern die Art der Schaltkreise wissen (CMOS ist nämlich keine Fertigungstechnik in diesem Sinne)
Ist alles CMOS.
Bipolare Transis oder normale FETs sind für hochintegrierte Schaltungen unbrauchbar.
zeckensack
2003-09-15, 19:45:58
OT @ ow,
Einer der frühen Alphas war AFAIR bipolar. Das wird aber noch zu Zeiten von >=0,5µ gewesen sein.
zeckensack
2003-09-15, 19:53:23
@Topic,
Original geschrieben von Stefan Payne
Sagen wirs mal andersrum:
das liegt daran, daß NV mehr alten Schrott mit sich rumschleppt, als es ATI jemals getan hat... Ack.
NV30 hat die reg combiners ala NV25, nochmals aufgebohrt auf 12 Bit pro Kanal, und verbraucht dafür bestimmt nicht wenige Transistoren*. Ursprünglich war geplant, die reg combiner als letzte Stufe am Ende des Pixelshaders einzusetzen. Es gab auch eine enstprechende GL-Extension (NV_fragment_combiner IIRC).
Das ganze Konzept wurde dann aber gekippt, die Extension wieder aus den Treibern entfernt (weswegen btw auch eine beliebte Alpha-Version nicht mehr mit neuen Treibern läuft), und die reg combiner sitzen jetzt bei Verwendung von PS >1.3 nur noch dumm rum.
*4x2 Combiner-Blöcke mit jeweils acht Skalar-Multiplizierern, acht Skalar-Addierern und noch ein wenig Kleinkram für Bitshifts, Inversion, Mux.
Demirug
2003-09-15, 19:58:42
Original geschrieben von zeckensack
@Topic,
Ack.
NV30 hat die reg combiners ala NV25, nochmals aufgebohrt auf 12 Bit pro Kanal, und verbraucht dafür bestimmt nicht wenige Transistoren*. Ursprünglich war geplant, die reg combiner als letzte Stufe am Ende des Pixelshaders einzusetzen. Es gab auch eine enstprechende GL-Extension (NV_fragment_combiner IIRC).
Das ganze Konzept wurde dann aber gekippt, die Extension wieder aus den Treibern entfernt (weswegen btw auch eine beliebte Alpha-Version nicht mehr mit neuen Treibern läuft), und die reg combiner sitzen jetzt bei Verwendung von PS >1.3 nur noch dumm rum.
*4x2 Combiner-Blöcke mit jeweils acht Skalar-Multiplizierern, acht Skalar-Addierern und noch ein wenig Kleinkram für Bitshifts, Inversion, Mux.
Unter OpenGL kann man sie bei den Fragmentprogrammen immer noch nutzen indem man die Integer Befehle benutzt.
Die ursprüngliche Idee war mir sowieso etwas suspekt.
Bei den PS >= 2.0 waren sie ja sowieso nicht nutzbar. Mit 1.4 könnte es zum Teil in der zweiten Phase aber noch gehen wenn sichergestellt ist das die Range [-2,+2] ausreicht.
zeckensack
2003-09-15, 20:25:36
Original geschrieben von Demirug
Unter OpenGL kann man sie bei den Fragmentprogrammen immer noch nutzen indem man die Integer Befehle benutzt.
Die ursprüngliche Idee war mir sowieso etwas suspekt.
Bei den PS >= 2.0 waren sie ja sowieso nicht nutzbar. Mit 1.4 könnte es zum Teil in der zweiten Phase aber noch gehen wenn sichergestellt ist das die Range [-2,+2] ausreicht. Ich denke doch, genau das war der Plan.
Unter der Voraussetzung daß alle dependent reads bereits im Fließkommateil behandelt wurden (die alten "texture shader"-Blöcke fehlen AFAIR im NV30, es geht also garnicht anders), ging man davon aus, daß gegen Ende des Shaders die benötigte Präzision unter gewissen Umständen (=> Rausschreiben in einen Integer-Framebuffer) kleiner ist als zu Anfang.
Die Extension konnte in Kombination mit {ARB|NV}_fragment_program eingesetzt werden. Also zwei Teil-Shader, der Anfang mit Fließkomma, das Ende mit Integer.
Daß die Architektur ziemlich komisch ist, möglicherweise eine ganz dumme Idee, das würde ich unterschreiben :)
IMO wollte NV hier einfach auf Nummer sicher gehen, um 'alte' Software und die Teile des Treibers, die Reg-Combiners nutzen/steuern direkt übernehmen zu können.
Demirug
2003-09-15, 20:41:04
Original geschrieben von zeckensack
Ich denke doch, genau das war der Plan.
Unter der Voraussetzung daß alle dependent reads bereits im Fließkommateil behandelt wurden (die alten "texture shader"-Blöcke fehlen AFAIR im NV30, es geht also garnicht anders), ging man davon aus, daß gegen Ende des Shaders die benötigte Präzision unter gewissen Umständen (=> Rausschreiben in einen Integer-Framebuffer) kleiner ist als zu Anfang.
Die Textureshader wurden durch den Shadercore ersetzt. wenn man sich die entsprechenden Patente ansieht (OK ich weiss das es nichta lles 1 zu 1 stimmen muss) erkennt man IMHO sehr gut das der Shadercore grosse Ähnlichkeit mit dem Textureshader hat.1
Die Extension konnte in Kombination mit {ARB|NV}_fragment_program eingesetzt werden. Also zwei Teil-Shader, der Anfang mit Fließkomma, das Ende mit Integer.
Ich weiss. Wenn ich die Sache richtig verstanden haben konnte man erst ein Fragment_programm laufen lassen. Das auch schon die Integereinheiten nutzen konnte. Zum Abschluss des Programms mussten sich dann die 4 Werte für die Regcombiner in den ersten 4 Tempregister befinden. Das Fragment-programm hätte dann in diesem Fall einfach einen flexibleren Textureshader dargestellt.
Ich vermute mal das man das ganze wieder herausgenommen hat dürfte daran gelegen haben das es erforderlich gewesen wäre jedesmal wenn man ein anderes Regcombiner Setup oder ein anderes Fragmentprogramm nutzt einen neuen (internen) Shader daraus zusammenzubauen. Ein Horror für die Treinerentwickler.
Daß die Architektur ziemlich komisch ist, möglicherweise eine ganz dumme Idee, das würde ich unterschreiben :)
Die Grundidee war möglicherweise gar nicht so schlecht. Das man bei MS aber auf taube Ohren bezüglich der 3 Datenformte gestossen ist macht die ganze Sache unnötig kompliziert. Zudem hat man entweder die Pipeline zu lang oder das Registerfile zu klein gemacht. Neben ein paar anderen kleineren Sünden.
IMO wollte NV hier einfach auf Nummer sicher gehen, um 'alte' Software und die Teile des Treibers, die Reg-Combiners nutzen/steuern direkt übernehmen zu können.
Mich würde es nicht wundern wenn die Chip sogar noch die gleichen Hardwareregister/bzw Kommandocodes hat. Man sollte mal echt einen Pre NV30 Deto nehmen, das Inf file patchen und schauen was passiert.
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.