NV35 - Int-Units, Anzahl Texturen

[aths]

Gibt es nun sichere Informationen darüber, ob der NV35 keine Integer-Einheiten mehr hat und alles via FP-Arithmetik gelöst wird, oder ist das nach wie vor nur eine Vermutung, dass die Integer-Units durch FP-Einheiten ersetzt wurden?

Dann hätte ich noch eine Frage zum Textursampling. Schon beim NV30 wurde von 16 Texturen pro Takt gesprochen, und das bei nur 8 bilinearen TMUs. Wie das mit den 16 Texturen gemeint ist, habe ich noch immer nicht ganz verstanden, könnte sich jemand die Zeit nehmen, mich zu erleuchten? :D

[Demirug]

Original geschrieben von aths
Gibt es nun sichere Informationen darüber, ob der NV35 keine Integer-Einheiten mehr hat und alles via FP-Arithmetik gelöst wird, oder ist das nach wie vor nur eine Vermutung, dass die Integer-Units durch FP-Einheiten ersetzt wurden?

Nein da gibt es nichts gesichertes.

Dann hätte ich noch eine Frage zum Textursampling. Schon beim NV30 wurde von 16 Texturen pro Takt gesprochen, und das bei nur 8 bilinearen TMUs. Wie das mit den 16 Texturen gemeint ist, habe ich noch immer nicht ganz verstanden, könnte sich jemand die Zeit nehmen, mich zu erleuchten? :D

Es wurde nie von 16 Texturen pro Takt sondern immer nur von 16 Texturen pro Pass gesprochen. Das ganze heist also einfach nur das die NV3x Chips wie jeder DX9 Chip über 16 virtuelle Texturesampler verfügen.

[Quasar]

Was die INT- oder FPU-Einheiten angeht: So gibt es m.W. nur die Aussage, dass der nV35 hier doppelt so leistungsfähige 2.0-Pixelshader ausführen kann, wie der nV30.

Entweder kann das m.E. darauf zurückzuführen sein, daß in den 4 Pipelines, die jeweils zwei herkömmliche TMUs und eine PS-ALU haben sollen, die TMUs durch je eine weitere PS-ALU ausgetausch worden ist, oder, und das ist meiner Meinung nach die wahrscheinlichere Theorie, dass die "Registerknappheit", durch die die nV30 ausgebremst werden soll, beim nV35 beseitigt wurde.

Weiterhin geht die Spekulation, dass der nV31 bereits auf dem Design des nV35 basieren soll. Das halte ich für Unsinn. Eher denke ich, daß aufgrund der verminderten PS-ALUs bei evtl. gleichem Registerstand diese Schwäche oder Fehler nicht so stark auffällt.

edit:
zu den "16 Texturen" siehe: http://www.beyond3d.com/previews/nvidia/nv30launch/index.php?p=2

We know that GeForce FX has a total of 8 pixel pipelines running at 500MHz, however how many texture mapping units does it feature per pipeline?

Well, as we move into programmable shading the old conventions of fixed pipelines are becoming less important and less accurate, so with that caveat let me go back and answer your question.
We have 8 pipelines and they can each apply one texture per clock so we can apply 8 textures per clock.

Does that apply for both FP32 (128-bit) as well as FP16 (64-bit)? For example can FP16 do two texture reads per clock?

No, you're limited to 8 textures applied per clock. However, we can do addressing for 16 textures at any one time. So even though you can only rigidly apply 8 per clock, you can line up the next 8 then apply them in the next clock. So that level of flexibility is very important as we move to procedural shading and sophisticated shader programs, so they key thing is how many textures can you queue up and address and how quickly can you apply them in a shader program.

[robbitop]

also ich ging bei der NV30 immer von 2 ALUs pro Pipeline aus.
Und würde man die Anzahl dieser Verdoppeln, wäre die Differenz der beiden Chips wohl deutlich grösser, als sie derzeit ist.

btw ein nicht unbeatlicher Teil des NV30 ist Massetransitoren um das teil zum laufen zu bringen. kA ob das beim NV35 noch so massiv zutrifft.

[Endorphine]

Könnte man nicht mit einem angepassten Archmark nachweisen, wo die internen Aufbauveränderungen des NV35 ggü. NV30 liegen? :)

[Demirug]

Original geschrieben von Endorphine
Könnte man nicht mit einem angepassten Archmark nachweisen, wo die internen Aufbauveränderungen des NV35 ggü. NV30 liegen? :)

Schwer sehr schwer. Vorallem weil man bis heute noch nicht ausgetüftelt hat wie die ganzen NV3x Chips im Detail funktionieren. Mir sind zwar einige generelle Dinge bekannt aber wenn es dann in die Details geht gibt es absolute nichts von nVidia.

[aths]

Original geschrieben von Demirug
Schwer sehr schwer. Vorallem weil man bis heute noch nicht ausgetüftelt hat wie die ganzen NV3x Chips im Detail funktionieren. Mir sind zwar einige generelle Dinge bekannt aber wenn es dann in die Details geht gibt es absolute nichts von nVidia. Ebendeshalb müsste man das testen :) Das heißt, da müssten Leute ran, die etwas davon verstehen, und da fallen mir 2, 3 Namen ein, mit dieser Menge bin ich natürlich disjunkt.

[Demirug]

Original geschrieben von aths
Ebendeshalb müsste man das testen :) Das heißt, da müssten Leute ran, die etwas davon verstehen, und da fallen mir 2, 3 Namen ein, mit dieser Menge bin ich natürlich disjunkt.

Da müsste man unsummen von Shadern schreiben und dann jeweils die Fillrate messen. Das ginge ja noch einigermassen aber wenn ich mir dann die Arbeit der Auswertung auch nur vorstelle...

[ScottManDeath]

Hi

das mit den unsummen an shadern könnte man vielleicht mittels code generation ausprobieren, z.b. für 4 register, 4 befehle und 4 textursamples alle kombinationen durchspielen und das programm halt 4 tage durchlaufen lassen und automatisch die performance messen lassen.Wenn man feststellt welche kombinationen einfluss auff die performance haben, dann "nachgrasen"

Bye
ScottManDeath