PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : NV50 mit 24 und mehr Pipes?


Gast
2004-08-30, 21:05:58
(Ausgabe 10/04 Seite 20)
In der neuen PC Games Hardware ist ein Interview mit Ujesh Desal zu lesen.
Darin heist es, Zitat:" Mit dem NV40 hat Nvidia die Messlatte für das NV50-Entwicklerteam hoch gelegt. In erster Linie wird die Anzahl der Pixelpipelines erhöht werden. Weiterhin soll die Programmierung einfacher und mit einer CPU vergleichbar werden. Nähere technische Details kann ich aber noch nicht nenne." Zitat ende

Als Kaffeesatz Leser interpretiere ich einfach mal hinein, das man etwas mehr "Brute Force Power" hinlegen will. Lässt sich der Chip nicht höher takten, macht man ihn halt "breiter" :)

ShadowXX
2004-08-30, 21:09:29
(Ausgabe 10/04 Seite 20)
In der neuen PC Games Hardware ist ein Interview mit Ujesh Desal zu lesen.
Darin heist es, Zitat:" Mit dem NV40 hat Nvidia die Messlatte für das NV50-Entwicklerteam hoch gelegt. In erster Linie wird die Anzahl der Pixelpipelines erhöht werden. Weiterhin soll die Programmierung einfacher und mit einer CPU vergleichbar werden. Nähere technische Details kann ich aber noch nicht nenne." Zitat ende

Als Kaffeesatz Leser interpretiere ich einfach mal hinein, das man etwas mehr "Brute Force Power" hinlegen will. Lässt sich der Chip nicht höher takten, macht man ihn halt "breiter" :)

Dann wirds aber "langsam" eng mit einer 256-Bit breiten Speicheranbindung.....

Oder Sie nehmen VIAs QBM.... ;D

IVN
2004-08-30, 21:15:19
What about Rambuses new memory child (XDR DRAM) 3.2 GHz effectiv + 256bit m.c.

robbitop
2004-08-30, 21:26:52
hm IMO Unsinn. Wenn man 24Pipelines einplant, kann man auch 32 einplanen.
Es sind eigentlich beim Planen 2er Potenzen wichtig.
Aber ich glaube, dass man beim NV50/R600 (R520 auf jeden Fall noch) nicht mehr von Pipelines spricht, sondern von einem Array.

Bevor QBM oder Yellowstone zum Zuge kommt, sollte IMO eine 512bit Verdratung eher statt finden.
Allerdings sind vorher noch andere Dinge bzgl des Cullings möglich.
Und da immer mehr arithmetische Shaderleistung wichtig wird, sollte chipinterne Bandbreite und Caches an Bedeutung gewinnen.
Das ganze haut ja nicht so rein, wie Farbwerte.

IVN
2004-08-30, 21:31:36
@robbitop


Why do you need 512bit,when you with an xdr 3.2GHz + 256bit already have 90+ GB of bandwidth??

IVN
2004-08-30, 21:38:16
Allerdings sind vorher noch andere Dinge bzgl des Cullings möglich.
Und da immer mehr arithmetische Shaderleistung wichtig wird, sollte chipinterne Bandbreite und Caches an Bedeutung gewinnen.
Das ganze haut ja nicht so rein, wie Farbwerte.


Yes,but this won't be the case with an nv50.It won't have enough shader power to use it for the whole image.Surfaces will be coverd with textures,and shaders will be used only for special effects.

ShadowXX
2004-08-30, 21:39:24
hm IMO Unsinn. Wenn man 24Pipelines einplant, kann man auch 32 einplanen.
Es sind eigentlich beim Planen 2er Potenzen wichtig.
Aber ich glaube, dass man beim NV50/R600 (R520 auf jeden Fall noch) nicht mehr von Pipelines spricht, sondern von einem Array.

Bevor QBM oder Yellowstone zum Zuge kommt, sollte IMO eine 512bit Verdratung eher statt finden.
Allerdings sind vorher noch andere Dinge bzgl des Cullings möglich.
Und da immer mehr arithmetische Shaderleistung wichtig wird, sollte chipinterne Bandbreite und Caches an Bedeutung gewinnen.
Das ganze haut ja nicht so rein, wie Farbwerte.

Das mit dem Array könnte natürlich auch kommen....aber ich glaube noch nicht daran, dass das SM4.0 Chips werden werden....

Gerade bei nV könnte ich mir tatsächlich einen aufgebohrten nv40 vorstellen (so in der Richtung r3x0->r420....mit verbesserten SM3.0 Eigenschaften).

Bei ATIs r520 muss man sehen...aber ich glaube nicht das dieser schon auf das "sagenumwobene" r400 Design aufsetzen wird....eher r420+SM3.0.

Man wird sehen was kommt....bis dahin fliesst noch viel Wasser die Elbe hinunter...

ShadowXX
2004-08-30, 21:43:11
@robbitop


Why do you need 512bit,when you with an xdr 3.2GHz + 256bit already have 90+ GB of bandwidth??

Ich glaube nicht das ATI/nV Rambus benutzen werden.

a.) ziemlich Teuer
b.) abhängigkeit von Rambus-Lizenzen
c.) Sony benutzt es ;D

IVN
2004-08-30, 21:51:21
Ich glaube nicht das ATI/nV Rambus benutzen werden.

a.) ziemlich Teuer
b.) abhängigkeit von Rambus-Lizenzen
c.) Sony benutzt es ;D


Yes,you are right.The last reason convinced me. ;D

robbitop
2004-08-30, 22:29:29
-Verfügbarkeit
-Kosten
-Latenzen

sind meine Gründe.

Ailuros
2004-08-31, 00:33:46
Ich denke gerade nostalgisch zurueck an all die moeglichen Spekulationen die R420/NV40 weit vor deren Ankuendigung betrafen.

Da hoerte man auch so manches merkwuerdiges wie 16MB eDRAM, quad pumped ram, TBDR, 8*1, nein warte 8*2, nein 12*1 oder doch noch 16*1, trilineare TMUs usw usw.

Die ewige Frage ist ob die Bandbreite fuer X oder Y ausreichen wird. Hier ist ein Anteil der vielleicht ein Teil der Wahrheit verborgen hat:

Weiterhin soll die Programmierung einfacher und mit einer CPU vergleichbar werden.

Hoehere arithmetische Effizienz braucht keine Unmengen von Bandbreite, ganz im Gegenteil wenn man sich die Rechenfaehigkeiten einer heutigen CPU anschaut. Theoretisch braeuchte man viel mehr Bandbreite um eine enorme Fuellrate zu fuettern und auch mehr samples als 4x oder 6x beim Antialiasing bzw. Multisampling. Ganz grob gaebe es zwei Moeglichkeiten hier die ich mir ausdenkenken koennte:

a) Rechenfaehigkeit aller Einheiten quasi verdoppeln und auf 4 quads vorruebergehend bleiben, oder....

b) Anzahl der Einheiten weiterhin skalieren.

Uebrigens ist ein 256bit bus bzw. die Bandbreite schon mit 4 quads zu eng. Es gab auch schon von seiten ATI Andeutungen fuer mehr "pipelines" bei der naechsten Generation, und man sieht ja heutzutage wie dicht die Beiden versuchen mit solchem Zeug zu konkurrieren; und das soll jetzt gar nichts heissen oder besser vieles ist moeglich. NVIDIA plant ja jetzt einen Q4 2005 release fuer NV50, was wohl aber auch heisst dass dieses auch nur einen sehr optimistischen Fall bedeutet, wo wirklich alles nach Plan laeuft.

Effektiv deutet der obrige Satz auch auf die Moeglichkeit eines Stream Prozessors zu. Pick your poison ;)

Ailuros
2004-08-31, 00:44:50
Das mit dem Array könnte natürlich auch kommen....aber ich glaube noch nicht daran, dass das SM4.0 Chips werden werden....

Gerade bei nV könnte ich mir tatsächlich einen aufgebohrten nv40 vorstellen (so in der Richtung r3x0->r420....mit verbesserten SM3.0 Eigenschaften).

Bei ATIs r520 muss man sehen...aber ich glaube nicht das dieser schon auf das "sagenumwobene" r400 Design aufsetzen wird....eher r420+SM3.0.

Man wird sehen was kommt....bis dahin fliesst noch viel Wasser die Elbe hinunter...

Es sieht nicht nach etwas besonderem ausserhalb der SM3.0 Komplianz aus bis zur Veroeffentlichung von WGF. Ein paar verstreute Features hier und da machen noch lange keine SM4.0 Komplianz; oder mal anders rum wieso sollten die Beiden Transistoren verschwenden fuer z.B. einen Geometrie-Shader wenn dieser bis zu WGF nur in OGL mit hauseigenen Extensionen eingesetzt werden kann?

Mir war uebrigens nie ein "sagenumworbenes" R4xx-"etwas" bewusst, dass im Grund ueber die SM3.0 Spezifikationen hinausging. Eher lag er irgendwo leicht hoeher als R520.

Man labert heutzutage von einem viel besser definierten und klarerem Bild was DX-Next frueher und WGF heutzutage betrifft. ATI labert hier schon ueber eine VS Einheit vor dem Geometrie-Shader und einer hinter dieser.

Die volle Konzentration was die Zukunft betrifft fuer beide IHVs wird auf NV60/R600 fallen. Das mag zwar als eine sich staendig wiederholende Geschichte klingen, aber es ist auch nicht die Schuld der IHVs wenn Microsoft ihr naechstes grosses OS staendig in die Zukunft verschiebt....

][immy
2004-08-31, 06:15:53
Hoehere arithmetische Effizienz braucht keine Unmengen von Bandbreite, ganz im Gegenteil wenn man sich die Rechenfaehigkeiten einer heutigen CPU anschaut. Theoretisch braeuchte man viel mehr Bandbreite um eine enorme Fuellrate zu fuettern und auch mehr samples als 4x oder 6x beim Antialiasing bzw. Multisampling. Ganz grob gaebe es zwei Moeglichkeiten hier die ich mir ausdenkenken koennte:


welche cpu ist denn jetzt wirklich effizient? also effizienter im berechnen als eine gpu?
soweit ich weiß liegen cpus noch weit hinter dem was eine gpu schafft. zwar ist es ein völlig anderer aufgabenbereich, aber cpus sind noch weit davon entfernt effizient zu arbeiten

oder hab ich dich jetzt einfach falsch verstanden?

klar würde eine grafikkarte durch mehr pipes wahrscheinlich schneller werden, aber desto höher die anforderungen (AA & co) desto eher besteht die gefahr, das die bandbreite limitiert und gpu-leistung quasi einfach verpufft weil entweder keine daten mehr kommen können so schnell wie sie berechnet werden, oder weil die daten nicht so schnell gesendet werden können wie sie berechnet werden

ShadowXX
2004-08-31, 08:59:01
Es sieht nicht nach etwas besonderem ausserhalb der SM3.0 Komplianz aus bis zur Veroeffentlichung von WGF. Ein paar verstreute Features hier und da machen noch lange keine SM4.0 Komplianz; oder mal anders rum wieso sollten die Beiden Transistoren verschwenden fuer z.B. einen Geometrie-Shader wenn dieser bis zu WGF nur in OGL mit hauseigenen Extensionen eingesetzt werden kann?

Mir war uebrigens nie ein "sagenumworbenes" R4xx-"etwas" bewusst, dass im Grund ueber die SM3.0 Spezifikationen hinausging. Eher lag er irgendwo leicht hoeher als R520.

Man labert heutzutage von einem viel besser definierten und klarerem Bild was DX-Next frueher und WGF heutzutage betrifft. ATI labert hier schon ueber eine VS Einheit vor dem Geometrie-Shader und einer hinter dieser.

Die volle Konzentration was die Zukunft betrifft fuer beide IHVs wird auf NV60/R600 fallen. Das mag zwar als eine sich staendig wiederholende Geschichte klingen, aber es ist auch nicht die Schuld der IHVs wenn Microsoft ihr naechstes grosses OS staendig in die Zukunft verschiebt....


Viele gingen beim r400 Design ja davon aus, das es schon SM4.0 erfüllen wird....das habe ich selber allerdings nie geglaubt...

Aber zumindest ist IMHO der r520 der grössere Unbekannte bei den beiden Chips....

Ich persönlich glaube auch nicht das er auf dem Xeon Design basieren wird, aber da kann ich natürlich auch völlig daneben liegen (und ja, mir ist klar, das es eigentlich unlogisch wäre, wenn er nicht auf dem Xeon basiert....just a feeling...)

Mit dem "verbesserten" SM3.0 beim nv50 meite ich übrigens nicht, das er nochmals neue Features spendiert bekommt, sondern nur das das SM3.0 effizienter wird (z.B. das Branching nicht mehr so viele Taktzyklen kostet..)

Aber wie schon erwähnt....dauert ja noch eine weil bis die Chips kommen.....

Ailuros
2004-08-31, 09:55:55
Viele gingen beim r400 Design ja davon aus, das es schon SM4.0 erfüllen wird....das habe ich selber allerdings nie geglaubt...

Aber zumindest ist IMHO der r520 der grössere Unbekannte bei den beiden Chips....

Ich persönlich glaube auch nicht das er auf dem Xeon Design basieren wird, aber da kann ich natürlich auch völlig daneben liegen (und ja, mir ist klar, das es eigentlich unlogisch wäre, wenn er nicht auf dem Xeon basiert....just a feeling...)

Mit dem "verbesserten" SM3.0 beim nv50 meite ich übrigens nicht, das er nochmals neue Features spendiert bekommt, sondern nur das das SM3.0 effizienter wird (z.B. das Branching nicht mehr so viele Taktzyklen kostet..)

Aber wie schon erwähnt....dauert ja noch eine weil bis die Chips kommen.....

Natuerlich werden zukuenftige chips effizienter mit branching sein und NV ist es auch bewusst dass man den einen oder anderen Aspekt auch effizienter loesen koennte in der Zukunft.

ATI:

http://users.otenet.gr/~ailuros/Save.ppt

Sooo unbekannt? Wenn ich mir solches Zeug durchlese, weiss ich viel weniger ueber NV50 am Ende.

Quasar
2004-08-31, 10:01:34
Nette Präsentation - woher kenne ich die noch gleich?

BTW,
But please do not sacrifice quality for speed!
That can be the user’s choice later on by selecting no-AA, low screen resolution etc
Wieso kommt mir das immer mehr wie blanker Hohn vor??

Ailuros
2004-08-31, 10:07:51
[immy']welche cpu ist denn jetzt wirklich effizient? also effizienter im berechnen als eine gpu?
soweit ich weiß liegen cpus noch weit hinter dem was eine gpu schafft. zwar ist es ein völlig anderer aufgabenbereich, aber cpus sind noch weit davon entfernt effizient zu arbeiten

Eine CPU ist und verbleibt eine generelle Recheneinheit. Fuer die Aufgaben wofuer sie aber bestimmt ist braucht sie auch nicht so viel Bandbreite, ja oder nein? Je mehr GPUs in die Richtung der CPU-Logik rechnen werden, desto weniger Bandbreite werden sie fuer Arithmetik brauchen.

(Das ppt im vorigen Post von ATI ist dazu auch eine gute Lektuere).

klar würde eine grafikkarte durch mehr pipes wahrscheinlich schneller werden, aber desto höher die anforderungen (AA & co) desto eher besteht die gefahr, das die bandbreite limitiert und gpu-leistung quasi einfach verpufft weil entweder keine daten mehr kommen können so schnell wie sie berechnet werden, oder weil die daten nicht so schnell gesendet werden können wie sie berechnet werden

Schlicht gesehen reicht theoretisch fuer 100%-ige Effizienz ein 256bit bus fuer 2 quads oder 8 pixel pro Takt aus. Wenn jetzt IHVs es geschafft haben mit 4 quads und etwa 35GB/sec Bandbreite trotzdem immer noch die Leistung zur vorigen Generation zu verdoppeln, dann sehe ich keinen besonderen Grund zur Unruhe fuer 6 quads und sagen wir mal 50GB/sec Bandbreite.

Es handelt sich in dem Fall um lediglich nur 2 quads mehr, oder anders rum nur 50% mehr quads und Bandbreite.

Schon mit 800MHz GDDR3 kann man die 50GB/sec Bandbreite ueberschreiten. Es gibt heute schon 550MHz GDDR3, in mehr als einem Jahr sollte hoeher spezifizierter Speicher wohl kein Problem sein.

Anstatt an die exotischten Loesungen zu denken wie sehr teuren Speicher, eingebetteten Speicher mit einer Ueberzahl von extra Transistoren oder sogar einen radikalen Umstieg zu Deferred Rendering, haben R420/NV40 durchaus gezeigt dass 4 quads doch moeglich waren und das mit stinknormalem DDR und interner Effizienz-erhoehungen.

Ailuros
2004-08-31, 10:09:26
Nette Präsentation - woher kenne ich die noch gleich?

BTW,

Wieso kommt mir das immer mehr wie blanker Hohn vor??

Gilt fuer beide IHVs. Was mir am meisten zum Hals heraushaengt ist dieser "monkey see monkey do" Trend....aechz.

Quasar
2004-08-31, 10:17:01
Kennst du die Präsentation über die neue Quadro? Da ist auch ein "Bildchen" drin, was der nV50 im Content-Creation noch übernehmen können soll, bzw. wieviel Zeitersparnis das bringt.

Leider kenne ich mich in dem Bereich überhaupt nicht aus - so daß ich keinerlei Schätzung abgeben kann, was das nun bedeutet.

Ailuros
2004-08-31, 10:33:10
Kennst du die Präsentation über die neue Quadro? Da ist auch ein "Bildchen" drin, was der nV50 im Content-Creation noch übernehmen können soll, bzw. wieviel Zeitersparnis das bringt.

Leider kenne ich mich in dem Bereich überhaupt nicht aus - so daß ich keinerlei Schätzung abgeben kann, was das nun bedeutet.


Nein noch nicht gesehen. Link bitte :)

Quasar
2004-08-31, 10:34:33
Das wird etwas schwierig - ich schau mal, ob sie auf dem FTP jetzt drauf ist.

edit:
Nein, scheint wohl immer noch nicht öffentlich zu sein.
Es geht da irgendwie um Offline-Content Rendering und die Zusammensetzung, die ein gerendertes Frame benötigt.
Vom nV25 bis inkl. nV4x sind dort Faktoren, die sich nicht verändern, IMO also von der CPU bestimmt werden.
Diese bislang "unveränderlichen" Zeitanteile sind im Balken für den nV5x nun ebenfalls geschrumpft worden.

Das läßt Raum für Spekulationen...

BlackBirdSR
2004-08-31, 11:30:24
[immy']welche cpu ist denn jetzt wirklich effizient? also effizienter im berechnen als eine gpu?
soweit ich weiß liegen cpus noch weit hinter dem was eine gpu schafft. zwar ist es ein völlig anderer aufgabenbereich, aber cpus sind noch weit davon entfernt effizient zu arbeiten

oder hab ich dich jetzt einfach falsch verstanden?



Dadurch, dass GPU und CPU ganz andere Aufgabenbereiche bedienen, und auch extra dafür ausgelegt werden, kann man das schlecht vergleichen.

Eine CPU weiss nicht welche Daten sie bekommt. Egal was es ist, es muss schnell und effizient abgearbeitet werden. Um das zu erreichen, muss man einen Mittelweg finden.
Die GPUs haben weiter den Vorteil, dass sie per Treiber direkt angesprochen werden. CPUs wie der Athlon64 oder P4 bekommen einen Code vorgesetzt, den sie nicht verstehen. Erst muss dieser in deren eigene Sprache umgesetzt werden. Das kostet.
So gesehen arbeiten CPUs schon recht effizient, im Rahmen des Machbaren.
Verglichen mit einem Chip, der nur für eine Aufgabe geschaffen wurde, und der auch noch Code bekommt der speziell auf ihn abgestimmt ist, fällt das natürlich mager aus.

Gast
2004-09-07, 20:40:38
Frage (bissl OT):
In einer der letzten PCGH´s vor der grossen nv40/r420 Veröffentlichung hatten die mal im Spielteil so ein Kürzestinterview mit Mark Rein im Heft, welcher ausplauderte, dass der nv50 Harwareoptimierungen für Unreal-Engine "3" haben soll. Nun, könnte das tatsächlich zutreffen und den nv-chips wie bei doom3 einen Performancevorsprung bringen bzw. hat jemand da mehr Infos??
(Das Heft besitz ich zufällig ich könnts auch raussuchen wenn das jemand wünscht)

Godmode
2004-09-07, 21:15:59
Könnte es sich dabei auch um die Schattentechnik handeln? Wie werden die Schatten bei der U3 Enginge gerendert? Stencil? oder ne andere Technik, hab mich leider noch nicht sehr damit auseinandergesetzt.

Tigerchen
2004-09-08, 06:31:02
Das mit dem Array könnte natürlich auch kommen....aber ich glaube noch nicht daran, dass das SM4.0 Chips werden werden....

Gerade bei nV könnte ich mir tatsächlich einen aufgebohrten nv40 vorstellen (so in der Richtung r3x0->r420....mit verbesserten SM3.0 Eigenschaften).

Bei ATIs r520 muss man sehen...aber ich glaube nicht das dieser schon auf das "sagenumwobene" r400 Design aufsetzen wird....eher r420+SM3.0.

Man wird sehen was kommt....bis dahin fliesst noch viel Wasser die Elbe hinunter...

Nein. Der R500 ist schon länger in der Entwicklung als der R420. Da kommt was wirklich Neues. Obs wirklich gut wird ist eine andere Frage.

ice cool69
2004-09-08, 07:29:43
Klar wirds gut, wieso sollte es nicht? Ich bin davon überzeugt dass es gut wird (die Entwickler des R300 machen den R520), die Frage ist ob es wieder für die Leistungskrone reicht.
Aber is ja auch egal ob NV50 oder R520 besser werden, ich hol mir die beste "obere Mittelklasse"-Karte für möglichst wenig Piepen.

robbitop
2004-09-08, 11:17:03
ich bin skeptisch, ob man tatsächlich ein xenon Derivat bringt. Der Name (R520) und SM3 geben Indizien auf etwas anderes.

wuzetti
2004-09-08, 17:32:32
ich bin da genauso skeptisch. wenn ich dave baumann richtig verstanden habe (finde leider das zitat nicht mehr), dann entstammt der R520 mehr oder weniger der R4XX linie. was wiederum heissen würde, dass es nix wird mit einem XENON derivat bzw. dass der R520 ein aufgepeppter R4XX mit SM 3. sein soll. :frown:

aber natürlich alles reine spekulation!

aths
2004-09-08, 19:04:32
Lässt sich der Chip nicht höher takten, macht man ihn halt "breiter" :)Ich frage mich, wieso nicht tiefer? Mehr als 16 Pipes erfordert den Einsatz einer neuen Speichertechnologie, also entweder QDR oder das 512-Bit-Interface. Es wäre einfacher, 16 Pipes mit je 3 (statt 2) Shader Units auszurüsten. Dazu noch 33% Mehrtakt, und man hätte (unter bestimmten Voraussetzungen) die zweifache arithmetische Leistung, verglichen mit NV40. Das wäre eine GPU mit sagen wir mal ~250 Mio Transistoren und 533 MHz. Nehmen wir weitere Verbesserungen (Texturfilter in den Vertexshader-TMUs, Beseitung von bestimmten Flaschenhälsen) käme man auf vielleicht 270 Mio Transistoren, aber sind wir größzügig und rechnen mit knapp 300. Das sollte zum NV50 einigermaßen passen. Ich gehe davon aus, dass NV50 (auch wenn NV von einer "neuen Architektur" reden wird) erkennbar auf dem NV40 basiert.

NV entwickelt bereits am NV60, wenn ich das anmerken darf. Der NV50 ist seit längerem praktisch fertig. Leider halten die Jungs dicht, was den Chip angeht. Bevor wir vom NV50 irgendwas sicheres erfahren, wird uns NV wohl erst mal Schritt für Schritt mit weiteren Mitgliedern der NV40-Familie beglücken. Bin gespannt, wie klein die kleinste Version wird.

Demirug
2004-09-08, 19:20:55
Ich frage mich, wieso nicht tiefer? Mehr als 16 Pipes erfordert den Einsatz einer neuen Speichertechnologie, also entweder QDR oder das 512-Bit-Interface. Es wäre einfacher, 16 Pipes mit je 3 (statt 2) Shader Units auszurüsten. Dazu noch 33% Mehrtakt, und man hätte (unter bestimmten Voraussetzungen) die zweifache arithmetische Leistung, verglichen mit NV40. Das wäre eine GPU mit sagen wir mal ~250 Mio Transistoren und 533 MHz. Nehmen wir weitere Verbesserungen (Texturfilter in den Vertexshader-TMUs, Beseitung von bestimmten Flaschenhälsen) käme man auf vielleicht 270 Mio Transistoren, aber sind wir größzügig und rechnen mit knapp 300. Das sollte zum NV50 einigermaßen passen. Ich gehe davon aus, dass NV50 (auch wenn NV von einer "neuen Architektur" reden wird) erkennbar auf dem NV40 basiert.

NV entwickelt bereits am NV60, wenn ich das anmerken darf. Der NV50 ist seit längerem praktisch fertig. Leider halten die Jungs dicht, was den Chip angeht. Bevor wir vom NV50 irgendwas sicheres erfahren, wird uns NV wohl erst mal Schritt für Schritt mit weiteren Mitgliedern der NV40-Familie beglücken. Bin gespannt, wie klein die kleinste Version wird.

Tiefer? Nicht unbedingt eine ideale Lösung. Ich würde viel breiter und sehr kurz bauen

aths
2004-09-08, 19:31:48
Imo sollten die Recheneinheiten von der Anzahl her die Häufigkeit der genutzten Operationen wiederspiegeln. So flach man auch baut, jede Pipe muss jede Instruktion ausführen können. Man braucht ja keine "Single Instruction Fillrate", die Pixel sollen mit möglichst langen Shadern berechnet werden. Imo tun es da auch tiefe Pipes ganz gut. Wenn sie so gebaut sind, dass man hohe Auslastung erzielt, natürlich.

Demirug
2004-09-08, 19:43:10
Imo sollten die Recheneinheiten von der Anzahl her die Häufigkeit der genutzten Operationen wiederspiegeln. So flach man auch baut, jede Pipe muss jede Instruktion ausführen können. Man braucht ja keine "Single Instruction Fillrate", die Pixel sollen mit möglichst langen Shadern berechnet werden. Imo tun es da auch tiefe Pipes ganz gut. Wenn sie so gebaut sind, dass man hohe Auslastung erzielt, natürlich.

Muss wirklich jede "Pipe" jede Anweisung ausführen?

Tiefe Pipes sind eben problematisch was den Speicher für die Temps angeht.

aths
2004-09-08, 19:50:13
Muss wirklich jede "Pipe" jede Anweisung ausführen?Sonst sind es (Kraft meiner Wassersuppe) keine Pixelpipelines mehr.

Tiefe Pipes sind eben problematisch was den Speicher für die Temps angeht.Mir wurde gesagt (Chipdesign ist nicht mein Fachgebiet) dass frei zuweisbare Recheneinheiten auch problematisch seien. Ich weiß nicht, wie viele Transistoren es kostet, ein 128-Bit-Register zu realisieren. Das dürfte doch aber so viel nicht sein?

Demirug
2004-09-08, 19:55:07
Sonst sind es (Kraft meiner Wassersuppe) keine Pixelpipelines mehr.

NV40 hat ja auch schon keine Pipes in üblichen Sinn mehr. NV50 wurde ja mal mit ILDP in Verbindung gebracht.

Mir wurde gesagt (Chipdesign ist nicht mein Fachgebiet) dass frei zuweisbare Recheneinheiten auch problematisch seien. Ich weiß nicht, wie viele Transistoren es kostet, ein 128-Bit-Register zu realisieren. Das dürfte doch aber so viel nicht sein?

Eines kostet nicht viel aber man hat ja zum ausgleichen der Latenzen viele Pixel in der Pipe und braucht entsprechend auch viele Register.

aths
2004-09-08, 20:07:42
NV40 hat ja auch schon keine Pipes in üblichen Sinn mehr.Abgesehen vom "superskalaren" Design sehen die Pipes doch recht üblich aus, oder?
Eines kostet nicht viel aber man hat ja zum ausgleichen der Latenzen viele Pixel in der Pipe und braucht entsprechend auch viele Register. Wenn die Pipe 50% länger wird, sollten es 50% neue Tempregister tun, oder nicht? Afaik kann die NV40-Pipe 2 oder 4 temporäre 128-Bit-Register anbieten.

Demirug
2004-09-08, 20:17:00
Abgesehen vom "superskalaren" Design sehen die Pipes doch recht üblich aus, oder?

Die entkoppelten ROPs sind eigentlich nicht üblich.

Wenn die Pipe 50% länger wird, sollten es 50% neue Tempregister tun, oder nicht? Afaik kann die NV40-Pipe 2 oder 4 temporäre 128-Bit-Register anbieten.

Es hängt davon ab wo man die Pipe wie verlängert. Einfach an einer Stelle ein Stück reinsetzten ist da aufgrund des Grunddesigns nicht so einfach möglich. 4 wären etwas wenig da kommt man schnell an seine Grenzen.

Das Hauptproblem bezüglich des NV50 Designs dürfte aber darin liegen das wir nicht wissen ob der schon für WGF entworfen wurde oder nicht. WGF erfordert ja ein Umdenken.

aths
2004-09-08, 20:28:14
Die entkoppelten ROPs sind eigentlich nicht üblich.Ja. Ist imo aber eine gute Möglichkeit, Transistoren sinnvoll einzusetzen.

Es hängt davon ab wo man die Pipe wie verlängert. Einfach an einer Stelle ein Stück reinsetzten ist da aufgrund des Grunddesigns nicht so einfach möglich. 4 wären etwas wenig da kommt man schnell an seine Grenzen.Soweit ich das weiß, haben die NV40-Pipes da noch immer einen Schwachpunkt. Bei 3 Shader Units 8 Temps pro Pipe, immerhin 16 bei _PP, klingt für mich auf den ersten Moment gut. Allerdings stecke ich da nicht in der Materie, und wenn NV mal was zum NV40 sagt, bekommt man höchstens nebulöse Andeutungen.

marco42
2004-09-08, 21:30:37
Das Hauptproblem bezüglich des NV50 Designs dürfte aber darin liegen das wir nicht wissen ob der schon für WGF entworfen wurde oder nicht. WGF erfordert ja ein Umdenken.

erlaubt eigentlich WFG den framebuffer aus dem fragment shader zu lesen? dann muessten sie die pipes doch zwangslaeufig kurz bauen, bloss mit dem breit wird dass dann auch ein Problem, wenn ich das richtig sehe.

Demirug
2004-09-08, 22:33:55
erlaubt eigentlich WFG den framebuffer aus dem fragment shader zu lesen? dann muessten sie die pipes doch zwangslaeufig kurz bauen, bloss mit dem breit wird dass dann auch ein Problem, wenn ich das richtig sehe.

Es war in einer der vorläufigen Specs aufgeführt nur ob es in der Finalen noch drin steht ist mir nicht bekannt.

Ailuros
2004-09-09, 04:33:50
Ich bezweifle dass nur ATI ihre roadmap geaendert hat in letzter Zeit.

Sonst stimme ich auch ein dass "tiefere SIMDs" = hoehere Latenzen. Wie dem auch sei gibt es natuerlich Stellen am NV4x-Design die etwas merkwuerdig sind, und es werden wohl die ersten Stellen sein wo man Aenderungen vorgenommen hat.

Es wäre einfacher, 16 Pipes mit je 3 (statt 2) Shader Units auszurüsten. Dazu noch 33% Mehrtakt, und man hätte (unter bestimmten Voraussetzungen) die zweifache arithmetische Leistung, verglichen mit NV40.

Nicht unbedingt; schon ueberhaupt nicht wenn man die grundlegenden Konzepte des NV40 verfolgt hat.

Der NV50 ist seit längerem praktisch fertig.

Nein. Und ich hab auch nicht die blasseste Ahnung in welchem Sinn hier "fertig" gemeint ist. Auf jeden Fall wuerde es heute dementsprechend ausgereifte kleinere Herstellungsprozesse geben, waere er nicht mal in der Naehe produktionsreif genannt zu werden. Das erst nach etwa einem Jahr von heute aus.

Siehe ersten Satz oben....

DrumDub
2004-09-09, 12:06:10
Nein. Und ich hab auch nicht die blasseste Ahnung in welchem Sinn hier "fertig" gemeint ist. Auf jeden Fall wuerde es heute dementsprechend ausgereifte kleinere Herstellungsprozesse geben, waere er nicht mal in der Naehe produktionsreif genannt zu werden. Das erst nach etwa einem Jahr von heute aus.

ich denk mal aths meint das design. wobei das natütlich nicht sein kann, wenn der nv50 nen wgf-kompatiber chip werden soll und die finalen specs der wgf noch nicht verabschiedet sind.

ShadowXX
2004-09-09, 14:21:20
ich denk mal aths meint das design. wobei das natütlich nicht sein kann, wenn der nv50 nen wgf-kompatiber chip werden soll und die finalen specs der wgf noch nicht verabschiedet sind.

Weder der nv50 noch der r520 werden IMHO schon WGF Chips sein, bzw. überhaupt in die nähe davon kommen...

Es wäre reine Transitorverschwendung.....

Beide (nv50 und r520) werden "reinrassige" SM3.0 Chips sein...beim nv50 gehe ich davon aus, dass es bei diesem wesentlich besser mit SM3.0 "klappen" wird....und bei ATI wird man sehen müssen, inwieweit Ihr "erster" SM3.0 Chip gleich "gut" oder sogar "sehr gut" im SM3.0 Bereich wird....

DrumDub
2004-09-09, 14:42:08
Weder der nv50 noch der r520 werden IMHO schon WGF Chips sein, bzw. überhaupt in die nähe davon kommen...

Es wäre reine Transitorverschwendung.....

Beide (nv50 und r520) werden "reinrassige" SM3.0 Chips sein...beim nv50 gehe ich davon aus, dass es bei diesem wesentlich besser mit SM3.0 "klappen" wird....und bei ATI wird man sehen müssen, inwieweit Ihr "erster" SM3.0 Chip gleich "gut" oder sogar "sehr gut" im SM3.0 Bereich wird....

jo. das sehe ich auch so. insofern denke ich, dass aths mit seiner aussage recht hat, dass der nv50 fertig ist.

Godmode
2004-09-09, 15:09:39
Und wie lange dauerts dann noch bis man fertige Chips sieht? Heißt fertig hier vom Konzept her? oder fertig im Sinne von bereit zum verkauf?

robbitop
2004-09-09, 16:24:36
wenn dann ersteres ;)

ice cool69
2004-09-09, 17:20:19
Für wann sind denn R520 und NV50 geplant?
Im übrigen denke ich nicht dass die beiden sich viel nehmen werden, ich sehe sowieso ein Patt vorraus. Schließlich taktet ATI seine Karten ja nur deshalb so hoch weil ihr Chip technisch gesehn weniger stark ist.
Sobald ATI aber auch wieder technisch gleichgezogen hat werden sie sicherlich nicht mehr so hoch züchten wie beim R420.

robbitop
2004-09-09, 17:41:42
ATi taktet ihre Chips höher weil sie es können. Lowk erlaubt es ihnen und auch die geringe Komplexität tut ihres dazu.
Zudem müssen sie es. Pro Takt ist das NV4x Design nicht zu schlagen.

Sollte R520 ein R3xx/4xx Nachfolger sein, sehe ich da schwarz.

egdusp
2004-09-09, 17:42:48
Beide (nv50 und r520) werden "reinrassige" SM3.0 Chips sein...beim nv50 gehe ich davon aus, dass es bei diesem wesentlich besser mit SM3.0 "klappen" wird....und bei ATI wird man sehen müssen, inwieweit Ihr "erster" SM3.0 Chip gleich "gut" oder sogar "sehr gut" im SM3.0 Bereich wird....

Wie meinst du das?
Das ATI mit ihrem ersten SM3 Chip mindestens so gut wie NV mit ihrem 2nd Generation Sm3 Chip sein müssen? Warum? Oder ist das "gleich" nicht vergleichend zwischen ATI und NV sondern im Sinne von "direkt beim ersten Versuch" gemeint?

mfg
egdusp

ShadowXX
2004-09-09, 18:32:18
Wie meinst du das?
Das ATI mit ihrem ersten SM3 Chip mindestens so gut wie NV mit ihrem 2nd Generation Sm3 Chip sein müssen? Warum? Oder ist das "gleich" nicht vergleichend zwischen ATI und NV sondern im Sinne von "direkt beim ersten Versuch" gemeint?

mfg
egdusp

Letzteres...es ist nicht als Vergleich zwischen nV und ATI gemeint...

Gast
2004-09-09, 20:34:28
Das "Problem" für Ati sehe ich ja net im den SM3 Einheiten, sondern der Umstieg von 24Bit auf 32Bit Rechengenauigkeit. Da kann man ja eigentlich von vielen Neuerungen ausgehen, wobei man ja Atis Sparbrötchen Verhalten net auser acht lassen sollte, irgendwo wird der Chip vieleicht nicht all das bieten was nV50 bringen wird (vieleicht sogar unter nV40 Niveau, Feature mäßig).
Zumindest Spekuliere ich darauf, das sie was finden werden, das man Einsparen kann, Taktrate zählt auch bei nem 16+ Pipeline Chip.

Gast
2004-09-09, 20:41:03
Zum NV50, nun Vorstellung zu Weihnachten 2005 +/- 1-2 Monate, das wird recht eng, nochwas in den Chip "einzubauen" wenn WGF nicht bis April/Mai 2005 Fertig spezifiziert ist. Man muss ja nahe dran sein, da große Änderungen der Zeitplan nicht gestattet, oder der NV40 krigt nen 3. Refresh gezaubert, oder gar "breiter" gemacht o.O
Dann könnte man den NV50 erweitern/umdesingen um WGF Komform zu sein, das ist das schöne an Spekulationen :)

Ich glaube nicht das NV nochmal den NV30 erleben will, sicher ist das schwer vergleichbar, ich bin da auch nicht so in der Materie was man groß falsch machen könnte (damals wars ja eigentlich ne Frage der Rechengenauigkeit und das "drumherum" für Shader Berechnungen). Aber sie sind gewarnt ^^

aths
2004-09-09, 22:28:17
Das "Problem" für Ati sehe ich ja net im den SM3 Einheiten, sondern der Umstieg von 24Bit auf 32Bit Rechengenauigkeit.Darin (in FP32) sehe ich nun das geringste Problem.

robbitop
2004-09-09, 23:25:34
Darin (in FP32) sehe ich nun das geringste Problem.

ja. bereits R3xx rechnet viele Dinge intern mit FP32. Nur musste man Transistoren sparen. Die Umstellung wäre nicht wirklich schlimm. Nur brauchbares SM3 geht mit der R3xx Architektur nicht mehr. Lediglich noch als Checklistfeature.

aths
2004-09-10, 00:03:46
ja. bereits R3xx rechnet viele Dinge intern mit FP32. Vertexshader und die Texturopationen arbeiten mit FP32, die arithmetischen Shader-Units mit FP24.
Nur brauchbares SM3 geht mit der R3xx Architektur nicht mehr. Lediglich noch als Checklistfeature. Selbst als Checklist-Feature wäre SM 3.0 wohl nur schwierig implementierbar.

Ailuros
2004-09-10, 08:30:58
ich denk mal aths meint das design. wobei das natütlich nicht sein kann, wenn der nv50 nen wgf-kompatiber chip werden soll und die finalen specs der wgf noch nicht verabschiedet sind.

WGF = NV60, sonst HW-Verschwendung.

So wie es momentan aussieht wird es drei SM3.0 Loesungen bis zu WGF geben: NV4x, R5xx und NV5x.

Dann könnte man den NV50 erweitern/umdesingen um WGF Komform zu sein, das ist das schöne an Spekulationen.

Erweitern inwiefern? Selbst die heutigen dx9.0 Loesungen sind theoretisch per SW WGF kompatibel.

Man wird in =/>2006 entweder WGF Komplianz haben oder eben nicht und diesmal hat Microsoft dafuer gesorgt dass eine Unmenge von Features Pflicht sein werden.

Es kann durchaus sein dass NV die Grundlagen fuer zukuenftige Designs im NV5x schon gelegt hat, aber das heisst noch bei weitem nicht dass fuer NV50 Grund oder Zweck besteht fuer WGF Komplianz wenn bevor LONGHORN ein sehr grosser Teil des chips nur bloed herumhockt.


----------------------------------------------------------

Darf ich mal ein bisschen tiefer buddeln, oder waere ein solches Topic besser im Tech-forum aufgehoben?

Wie stellen sich unsere Gurus einen Geometry Shader oder eben einen generellen PPP in einem zukuenftigen chip vor?

Ein einfacherer SIMD (4-way oder mehr?), oder eben doch auch ein MIMD eventuell? Vor dem VS SIMD/MIMD oder dahinter oder einfach dazwischen (VS <-> GS <-> VS)? ALUs?

(ich frag mal wieder zu viel)

Demirug
2004-09-10, 09:11:53
Darf ich mal ein bisschen tiefer buddeln, oder waere ein solches Topic besser im Tech-forum aufgehoben?

Wie stellen sich unsere Gurus einen Geometry Shader oder eben einen generellen PPP in einem zukuenftigen chip vor?

Ein einfacherer SIMD (4-way oder mehr?), oder eben doch auch ein MIMD eventuell? Vor dem VS SIMD/MIMD oder dahinter oder einfach dazwischen (VS <-> GS <-> VS)? ALUs?

(ich frag mal wieder zu viel)

MIMD wäre wohl aufgrund der Aufgabenstellung besser.

Die Position ist dann schon etwas schwieriger zu bestimmen und hängt auch stark von der Sichtweise ab. Geht man davon aus das die Verticen in der richtigen Reihenfolge vorne eingespeisst werden müssen muss ein Geometry Shader am Anfang der Pipeline sein. Nimmt man dagegen das Model bei dem das Trisetup von Vertexshader immer die 3 nächsten für ein Dreieck benötigten Verticen anfordert muss ein Geometry Shader unmittelbar vor dem Trisetup sein. Das Trisetup würde dann vom Geometry Shader das nächste Dreieck anfordern. Dieser wiederum würde die VS mit den entsprechenden Grunddaten füttern und die berechneten Ergebnisse an das Trisetup weiter geben. Bringt man jetzt noch Tesselation ins Spiel wird das ganze noch komplexer. Ein mögliches Model wäre das der Geometry Shader nur den VS vor der Tesselation mit Daten versorgt und dann eben nicht ein Dreieck sondern viele bekommt. Dazu könnte man ihm noch die Kontrolle darüber geben welches dieser Dreiecke wirklich zum Trisetup durchkommt.

Ailuros
2004-09-10, 10:06:47
MIMD wäre wohl aufgrund der Aufgabenstellung besser.

Aber auch wesentlich teurer in HW oder? Aus dem Sichtpunkt sieht es schon danach aus als ob NV irgendwo die ersten Bausteine fuer zukuenftige WGF Architekturen Stueck fuer Stueck einsetzt.

Ich frage mich immer noch ob MIMD wirklich notwendig war fuer NV40/VS.

Geht man davon aus das die Verticen in der richtigen Reihenfolge vorne eingespeisst werden müssen muss ein Geometry Shader am Anfang der Pipeline sein.

Werden denn vertices in allen Faellen in der richtigen Reihenfolge eingespeisst? In einem "Ungluecksfall" wo es doch mal zu "out of order" vertices kommen sollte, spricht wohl MIMD dann auch nicht unbedingt dafuer denke ich.

Nimmt man dagegen das Model bei dem das Trisetup von Vertexshader immer die 3 nächsten für ein Dreieck benötigten Verticen anfordert muss ein Geometry Shader unmittelbar vor dem Trisetup sein. Das Trisetup würde dann vom Geometry Shader das nächste Dreieck anfordern. Dieser wiederum würde die VS mit den entsprechenden Grunddaten füttern und die berechneten Ergebnisse an das Trisetup weiter geben. Bringt man jetzt noch Tesselation ins Spiel wird das ganze noch komplexer. Ein mögliches Model wäre das der Geometry Shader nur den VS vor der Tesselation mit Daten versorgt und dann eben nicht ein Dreieck sondern viele bekommt. Dazu könnte man ihm noch die Kontrolle darüber geben welches dieser Dreiecke wirklich zum Trisetup durchkommt.

Ich fragte eigentlich nur weil ATI mal was darueber erwaehnte, wo nach ihrem Sichtpunkt der idealste Fall nach ihrer Meinung waere, wenn eine VS Einheit davor und eine VS Einheit dahinter steckt. Wieso das jetzt besser sein soll kann ich mit meiner Fantasie nicht unbedingt ausdenken.

Noch ne womoeglich bloedere Frage: warum nicht gleich eine universalere Einheit entwickeln die gleichzeitig GS und VS Aufgaben ausfuehren kann, oder wird die Einheit dann viel zu gross?

Demirug
2004-09-10, 10:14:33
Aber auch wesentlich teurer in HW oder? Aus dem Sichtpunkt sieht es schon danach aus als ob NV irgendwo die ersten Bausteine fuer zukuenftige WGF Architekturen Stueck fuer Stueck einsetzt.

Ich frage mich immer noch ob MIMD wirklich notwendig war fuer NV40/VS.

Werden denn vertices in allen Faellen in der richtigen Reihenfolge eingespeisst? In einem "Ungluecksfall" wo es doch mal zu "out of order" vertices kommen sollte, spricht wohl MIMD dann auch nicht unbedingt dafuer denke ich.

Ich fragte eigentlich nur weil ATI mal was darueber erwaehnte, wo nach ihrem Sichtpunkt der idealste Fall nach ihrer Meinung waere, wenn eine VS Einheit davor und eine VS Einheit dahinter steckt. Wieso das jetzt besser sein soll kann ich mit meiner Fantasie nicht unbedingt ausdenken.

Noch ne womoeglich bloedere Frage: warum nicht gleich eine universalere Einheit entwickeln die gleichzeitig GS und VS Aufgaben ausfuehren kann, oder wird die Einheit dann viel zu gross?

Wenn wir das ganze unter dem WGF Gesichtspunkt sehen ist der Geometrieshader überall. WGF schreibt generalisierte Shader sowohl was die programmierung wie auch die Hardware angeht vor.

Wenn man einen Geometrieshader lediglich als bessere Tesselationseinheit sieht ist es wirklich sinnvoll einen VS davor und dahinter zu haben. Im Kontext von WGF heisst das dann aber das man für die Verticen vor und nach der Tesselation ein Shaderprogramm ausführen kann.

Bei WGF gibt es zwei Pipelines. Die echte im Chip und das Model einer Pipeline welches der Programmierer nutzt. Viele Einheiten welche im Model an unterschiedlichen stellen sind entsprechende aber dem gleichen Block in der Hardware. Die Frage ist also welche Wege (vorwärts und rückwärts) erlaubt der Chip.

Ailuros
2004-09-10, 11:22:31
Wenn wir das ganze unter dem WGF Gesichtspunkt sehen ist der Geometrieshader überall. WGF schreibt generalisierte Shader sowohl was die programmierung wie auch die Hardware angeht vor.

Ausserhalb von WGF macht wohl ein GS auch momentan nicht viel Sinn.

Wenn man einen Geometrieshader lediglich als bessere Tesselationseinheit sieht ist es wirklich sinnvoll einen VS davor und dahinter zu haben. Im Kontext von WGF heisst das dann aber das man für die Verticen vor und nach der Tesselation ein Shaderprogramm ausführen kann.

Hmmmm das klingt aber etwas begrenzt, falls ATI tatsaechlich sowas vorhaben sollte oder sich eben mehr auf Tesselation konzentrieren sollte.

Bei WGF gibt es zwei Pipelines. Die echte im Chip und das Model einer Pipeline welches der Programmierer nutzt. Viele Einheiten welche im Model an unterschiedlichen stellen sind entsprechende aber dem gleichen Block in der Hardware. Die Frage ist also welche Wege (vorwärts und rückwärts) erlaubt der Chip.

Nach dem dritten durchlesen hab ich den Paragraph glaube ich kapiert ;) Danke.

Demirug
2004-09-10, 11:27:15
Hmmmm das klingt aber etwas begrenzt, falls ATI tatsaechlich sowas vorhaben sollte oder sich eben mehr auf Tesselation konzentrieren sollte.

Falls sie das Vorhaben ist der Chip nicht WGF konform. WGF schreibt nämlich einen Geometryshader zusätzlich zur Tesselation vor. Zudem muss man aufgrund der Anforderungen an den Geometryshader auch davon ausgehen das hier von MS mehr als nur Tesselation gefordert wird.

Tigerchen
2004-09-10, 16:10:27
Wie meinst du das?
Das ATI mit ihrem ersten SM3 Chip mindestens so gut wie NV mit ihrem 2nd Generation Sm3 Chip sein müssen? Warum? Oder ist das "gleich" nicht vergleichend zwischen ATI und NV sondern im Sinne von "direkt beim ersten Versuch" gemeint?

mfg
egdusp

R500 muß ein Knüller wie der R300 werden. Sonst sind sie ziemlich deutlich auf der Verliererstraße.

Gast
2004-09-10, 16:23:41
Darin (in FP32) sehe ich nun das geringste Problem.

Es kostet aber Transistoren ohne direkt Mehrleistung in fps gemessen zu bringen. Und das schmerzt ATi sicher schon, wo die doch so aufs Transitorsparen und hohe Takte bedacht sein.

DrumDub
2004-09-10, 16:40:16
Es kostet aber Transistoren ohne direkt Mehrleistung in fps gemessen zu bringen. Und das schmerzt ATi sicher schon, wo die doch so aufs Transitorsparen und hohe Takte bedacht sein.

tjo, die sm 3.0 specs sind nunmal eindeutig. da hilft auch kein rumheulen. ;)

Ailuros
2004-09-10, 16:45:16
R500 muß ein Knüller wie der R300 werden. Sonst sind sie ziemlich deutlich auf der Verliererstraße.


Blah beide IHVs haben genau die gleichen Sorgen stets eine effizientere Loesung als die Konkurrenz liefern zu koennen; den Stress hat NV genauso. Keiner der Beiden koennen sich Fehler leisten und es ist ihnen auch bewusst. Genauso wie es intern bei ATI den Kerlen bewusst ist, dass die R420 nicht unbedingt das heisseste technologische Eisen auf dem Markt ist; aber wie schon mal gesagt ein sehr bewusster Schachzug von ATI.

Es ist uebrigens R520 und ist quasi ein Ur-R400-Abschlag, mit ein paar wichtigen Aenderungen nach unten die nur in der Xenon-VPU vorhanden sein werden.

Koennten sowohl ATI als auch NVIDIA sich mal was effizienteres und qualitativeres in Sachen Textur-filterung ausdenken? Diese uebertriebene Konzentration nur auf Leistung geht mir so langsam auf die Nerven. Da gibts eigentlich mehr Grund zum meckern, als was fuer eine Shader Version der eine oder andere unterstuetzt.

marco42
2004-09-10, 17:23:41
Falls sie das Vorhaben ist der Chip nicht WGF konform. WGF schreibt nämlich einen Geometryshader zusätzlich zur Tesselation vor. Zudem muss man aufgrund der Anforderungen an den Geometryshader auch davon ausgehen das hier von MS mehr als nur Tesselation gefordert wird.

wird sich MS nicht eher an den IHVs orientieren als umgekehrt? ich persoenlich wuerde ja einen VS bevorzugen, bei dem man neue vertices generieren kann oder verwerfen. hmm, hab bloss nicht darueber nachgedacht, ob das effizient geht. zb schick mit 4 vertices und ich tesseliere daraus ein kurvensegment.

Demirug
2004-09-10, 17:25:25
wird sich MS nicht eher an den IHVs orientieren als umgekehrt? ich persoenlich wuerde ja einen VS bevorzugen, bei dem man neue vertices generieren kann oder verwerfen. hmm, hab bloss nicht darueber nachgedacht, ob das effizient geht. zb schick mit 4 vertices und ich tesseliere daraus ein kurvensegment.

Die Hardwarespec wurde zusammen von MS und den IHV geschrieben.

Robbitop@Mobile
2004-09-11, 12:34:00
Es ist uebrigens R520 und ist quasi ein Ur-R400-Abschlag, mit ein paar wichtigen Aenderungen nach unten die nur in der Xenon-VPU vorhanden sein werden.


Hört sich gut an (man hat sicher auch die Anzahl der Ausführungseinheiten erhöt oder?). Woher hast du die Infos und wie gewiss sind diese?

Ailuros
2004-09-11, 14:05:17
Hört sich gut an (man hat sicher auch die Anzahl der Ausführungseinheiten erhöt oder?). Woher hast du die Infos und wie gewiss sind diese?

Dass ATI ihre gesamte roadmap umgeworfen hat seit dem R3xx, ist wohl nichts Neues.

R420 wurde ein R3xx Abschlag und in der Mehrzahl R400=> R520 und R500=> R6xx.

Leistung zur Seite, feature-maessig sollte Xenon irgendwo zwischen R5xx und R6xx liegen, wobei aber ein Console-Design meistens ein ganz anderes Bier ist.

Leistung nochmal zur Seite (und ja im Grunde muss R520 um einiges schneller sein als Xenon sonst wird es wohl eher eine Enttaeuschung), R520 ist hoechstwahrscheinlich nichts anderes als ein SM3.0 chip, mehr als das macht ja sowieso bis zu WFG wohl nicht mehr viel Sinn.

ATI scheint der einzige IHV zu sein wo man Zitate ueber vereinte PS/VS Einheiten finden kann (R400) und scheint auch nicht viel von Stream-Prozessoren zu halten. Falls NVIDIA tatsaechlich sich in die Stream-Richtung orientieren sollte (obwohl ehrlich gesagt mir NV5x irgendwie zu frueh klingt, aber nur ein persoenliches Gefuehl), dann kann man wohl schwer voraussagen wer die naechste Runde gewinnen wird.

Um ehrlich zu sein erwarte ich fundamentale Aenderungen fuer Beide doch erst um den WGF Zeitraum, denn darauf muessen sie sich auch am meisten konzentrieren. 2005 sieht mir eher hauptsaechlich nach Leistungssteigerungen aus; ob dieses nun durch hoehere Frequenzen, mehr Ausfuehrungseinheiten, Erhoehung der Effizienz der vorhandenen Einheiten oder sogar einer Kombination von allen drei kommen wird, ist mir eigentlich egal.

Es gibt ja auch von Seiten ATI diese fast14 verwandte Geruechte, die mir aber momentan immer noch nicht als moeglich erscheinen.