Demirug erklärt wie NV die Shaderleistung des R420 mit dem NV 40 erreichen könnte [Archiv]

Demirug

2004-02-20, 12:40:49

Definieren wir zuerst einmal was zu schlagen ist. Der R420 ist ein 8 Pipeline Chip mit "Extremen Pipelines". Da man bei ATI mindestens eine Verdopplung der Leistung anstrebt gehen wir der Einfachheit wegen davon aus das jede Pipeline nun 2 FPUs enthält. Ob diese zusätzliche FPU den ganzen Modifiziere überbau den man für DX7 und DX8 braucht bekommen sei mal dahingestellt. Dort ist ja Rechenleistung in der Regel kein Problem. Bei PS 2.0 kann man diese Modifizierer kaum gebrauchen. Also R420 = 2*R300 FPU. Eine R300 FPU kann nun bis zu 2 Arithmetik-Ops pro Takt verarbeiten. Ein R420 würde also 4 erreichen (2*Vector3+2*Skalar). Bei 8 Pipelines sind das 8*4 = 32 Ops/Takt.

Kommen wir nun zum NV40. Der NV35 hat zwei FP-Rechenwerke. Den Shadercore und einen Combiner. Da der Shadercore auch für die Textur-Ops zuständig ist lassen wir in erst mal weg. Der Combiner kann bis zu 2 unabhängige Vector4 Ops ausführen. nVidia hat nun aber die Option diesen Combiner teilbar zu machen. Dann hätten wir es mit 4 Ops zu tun. Erweitert man diesen Combiner noch etwas (Modifiziere) lässt er sich auch für DX7;DX8 Zwege benutzten. nVidia kann dann die beiden FX12 Combiner entfernen und durch einen der neuen ersetzen. Womit für DX7;DX8 Anwendungen weiterhin 2 Combiner zur verfügung stehen. Für PS 2.0 haben wir aber nun bis zu 2*4 Ops = 8 pro Takt. Wenn die Anweisungen nicht unabhängig sind kommen wir noch auf 4 pro Takt. Baut nVidia jetzt noch 8 Pipelines rein haben wir einen gleichstand von 32 Ops/Takt. Sind es nur 6 kommen wir auf 24 Ops/Takt. Beim 6X2 Model wird aber davon ausgegangen das die VS mitbenutzt werden können wodurch ja wiederum einige Ops hinzukommen. Nun müssen wir auch noch mal den Shadercore einbeziehen. In jedem takt in dem er nicht für texturops gebraucht wird kann er pro Pipeline eine Op beisteuern. Ist er ebenfalls teilbar sind sogar 2 oder 3 Ops möglich. In Summe sind das also bei einem 6 Pipelinedesign bis zu 66 Ops/Takt und bei einem 8 Pipe Design 88 Ops/Takt. Natürlich wird dieser Maxwert nur schwer zu erreichen sein.

Bleibt noch das letzte Problem des NV35. Der Tempspeicher. Dieser ist zu klein was dazu führt das zu viele Ops ungenutzt bleiben. Die Lösung ist das Teil einfach größer zu machen. Hat nVidia dies getan (davon ist auszugehen) ist aus dieser Richtung kein Problem mehr zu erwarten.

Trotz der denkbaren höheren Ops/Takt Leistung die nVidia so erreichen kann sehe ich bei der Durchschnittlichen Ops/Takt Leistung einen gleichstand zwischen ATI und nVidia weil bei nVidia die volle Nutzbarkeit an viel mehr Randbedingungen geknüpft ist (Shadercompiler nötig). Der Takt könnte daher das Zünglein an der Wage sein. Sollte ATI allerdings sogar 3 FPUs verbaut haben (was ich aber nicht glaube) muss nVidia ebenfalls 3 Combiner haben um dagegen zu halten.

Ailuros

2004-02-20, 12:48:56

Hmmmmmm....

Beim 6X2 Model wird aber davon ausgegangen das die VS mitbenutzt werden können wodurch ja wiederum einige Ops hinzukommen. Nun müssen wir auch noch mal den Shadercore einbeziehen. In jedem takt in dem er nicht für texturops gebraucht wird kann er pro Pipeline eine Op beisteuern. Ist er ebenfalls teilbar sind sogar 2 oder 3 Ops möglich. In Summe sind das also bei einem 6 Pipelinedesign bis zu 66 Ops/Takt und bei einem 8 Pipe Design 88 Ops/Takt. Natürlich wird dieser Maxwert nur schwer zu erreichen sein.

Denkst Du hier an VS3.0 spezifische TMUs oder verstehe ich wieder Bahnhof?

Demirug

2004-02-20, 12:55:24

Original geschrieben von Ailuros
Hmmmmmm....

Denkst Du hier an VS3.0 spezifische TMUs oder verstehe ich wieder Bahnhof?

Nein, der erste Satz hat mit dem Rest nichts zu tun. Hätte ich klarer trennen sollen.

Der erste Satz meint das von Uttar aufgezeigte Model.

Der rest bezieht sich auf die schon im NV30 vorhanden universal FPU die T und A Ops rechnen kann. Die Combiner können ja nur A Ops und dort auch nicht alle.

Ailuros

2004-02-20, 13:06:25

Jetzt mal ne andere dumme Frage: wie sieht es mit der ganz verrueckten These von 4 FPUs pro SIMD aus? Transistor-budget oder einfach nutzloser Ueberfluss?

Demirug

2004-02-20, 13:35:39

Original geschrieben von Ailuros
Jetzt mal ne andere dumme Frage: wie sieht es mit der ganz verrueckten These von 4 FPUs pro SIMD aus? Transistor-budget oder einfach nutzloser Ueberfluss?

Rechenleistung kann man eigentlich nie genügend haben.

Bei meinem NV40 Model könnte man bei entsprechender (kreativer) Zählweise ja von einem 5 FPU Model sprechen.

1. Shadercore
2. 1 Combiner 1 Kanal
3. 1 Combiner 2 Kanal
4. 2 Combiner 1 Kanal
5. 2 Combiner 2 Kanal

Jeder Kanal teilt sich dann noch in einen Vektor3 und Skalar Anteil.

Ailuros

2004-02-20, 13:43:48

:schleich: (....so langsam wird mir das Ganze zu kompliziert).

*steckt den Kopf in die Tiefkuehltruhe*

reunion

2004-02-20, 13:52:08

Original geschrieben von Demirug
Definieren wir zuerst einmal was zu schlagen ist. Der R420 ist ein 8 Pipeline Chip mit "Extremen Pipelines". Da man bei ATI mindestens eine Verdopplung der Leistung anstrebt gehen wir der Einfachheit wegen davon aus das jede Pipeline nun 2 FPUs enthält. Ob diese zusätzliche FPU den ganzen Modifiziere überbau den man für DX7 und DX8 braucht bekommen sei mal dahingestellt. Dort ist ja Rechenleistung in der Regel kein Problem. Bei PS 2.0 kann man diese Modifizierer kaum gebrauchen. Also R420 = 2*R300 FPU. Eine R300 FPU kann nun bis zu 2 Arithmetik-Ops pro Takt verarbeiten. Ein R420 würde also 4 erreichen (2*Vector3+2*Skalar). Bei 8 Pipelines sind das 8*4 = 32 Ops/Takt.

Kommen wir nun zum NV40. Der NV35 hat zwei FP-Rechenwerke. Den Shadercore und einen Combiner. Da der Shadercore auch für die Textur-Ops zuständig ist lassen wir in erst mal weg. Der Combiner kann bis zu 2 unabhängige Vector4 Ops ausführen. nVidia hat nun aber die Option diesen Combiner teilbar zu machen. Dann hätten wir es mit 4 Ops zu tun. Erweitert man diesen Combiner noch etwas (Modifiziere) lässt er sich auch für DX7;DX8 Zwege benutzten. nVidia kann dann die beiden FX12 Combiner entfernen und durch einen der neuen ersetzen. Womit für DX7;DX8 Anwendungen weiterhin 2 Combiner zur verfügung stehen. Für PS 2.0 haben wir aber nun bis zu 2*4 Ops = 8 pro Takt. Wenn die Anweisungen nicht unabhängig sind kommen wir noch auf 4 pro Takt. Baut nVidia jetzt noch 8 Pipelines rein haben wir einen gleichstand von 32 Ops/Takt. Sind es nur 6 kommen wir auf 24 Ops/Takt. Beim 6X2 Model wird aber davon ausgegangen das die VS mitbenutzt werden können wodurch ja wiederum einige Ops hinzukommen. Nun müssen wir auch noch mal den Shadercore einbeziehen. In jedem takt in dem er nicht für texturops gebraucht wird kann er pro Pipeline eine Op beisteuern. Ist er ebenfalls teilbar sind sogar 2 oder 3 Ops möglich. In Summe sind das also bei einem 6 Pipelinedesign bis zu 66 Ops/Takt und bei einem 8 Pipe Design 88 Ops/Takt. Natürlich wird dieser Maxwert nur schwer zu erreichen sein.

Bleibt noch das letzte Problem des NV35. Der Tempspeicher. Dieser ist zu klein was dazu führt das zu viele Ops ungenutzt bleiben. Die Lösung ist das Teil einfach größer zu machen. Hat nVidia dies getan (davon ist auszugehen) ist aus dieser Richtung kein Problem mehr zu erwarten.

Trotz der denkbaren höheren Ops/Takt Leistung die nVidia so erreichen kann sehe ich bei der Durchschnittlichen Ops/Takt Leistung einen gleichstand zwischen ATI und nVidia weil bei nVidia die volle Nutzbarkeit an viel mehr Randbedingungen geknüpft ist (Shadercompiler nötig). Der Takt könnte daher das Zünglein an der Wage sein. Sollte ATI allerdings sogar 3 FPUs verbaut haben (was ich aber nicht glaube) muss nVidia ebenfalls 3 Combiner haben um dagegen zu halten.

Das NV theoretisch die Leistung des R420 erreicht, daran zweifle ich nicht, der NV35 ist ja theoretisch auch kaum langsamer als der R350, was in der Praxis offensichtlich ja ganz anders aussieht.

Die Frage ist nur ob NV die ineffizienz von Cine FX verbessern kann. Sind die Tempspeicher wirklich der einzige Grund für die ineffizienz des NV35?

Demirug

2004-02-20, 14:01:06

Original geschrieben von reunion
Die Frage ist nur ob NV die ineffizienz von Cine FX verbessern kann. Sind die Tempspeicher wirklich der einzige Grund für die ineffizienz des NV35?

Es sind 3 primäre Dinge.

1. Temp Speicher (bei mehr als 2 FP32 Register fängt die Bremse an zu wirken)
2. Kein Split in Vektor3 + Skalar. Bei den meisten Shadern die ich mir bisher angeschaut habe lassen sich durch diese Sache im Mittel 50% der Takte sparen.
3. Die Combiner FPU ist zwar zweikanalig aber unterliegt einigen Begrenzungen bezüglich der benutzung des zweiten Kanals. Das ist wie bei der U und V Pipe beim ersten Pentium.

Werden diese 3 Probleme beseitigt (so wie oben geschrieben) sehe ich ein Patt mit einem ganz kleinen Vorteilfür nV wenn ATI beim R420 wirklich einfach die R300 FPU verdoppelt hat.

Es gibt noch ein paar andere Kleinigkeiten wie Read-Port Limits die sich aber durch umsortieren der Codereihenfolge oft umgehen lassen.

Winter[Raven]

2004-02-20, 14:12:31

Werden diese 3 Probleme beseitigt

Demirug, wie gut stehen die Chancen dafür das diese "Engpässe" im NV40 nicht mehr vorhanden sein werden, deiner Meinung nach ?

Demirug

2004-02-20, 14:19:24

Original geschrieben von Winter[Raven]
Demirug, wie gut stehen die Chancen dafür das diese "Engpässe" im NV40 nicht mehr vorhanden sein werden, deiner Meinung nach ?

IMHO sehr gut. nVidia wusste sehr genau wo die Probleme lagen. Die Frage ist nur was wird der neue Engpass sein?

Ailuros

2004-02-20, 14:23:33

Original geschrieben von Demirug
IMHO sehr gut. nVidia wusste sehr genau wo die Probleme lagen. Die Frage ist nur was wird der neue Engpass sein?

Latenz? :kratz2:

Demirug

2004-02-20, 14:29:37

Original geschrieben von Ailuros
Latenz? :kratz2:

Welche? Die gibt es ja massenhaft in einem solchen Chip. Ich persönlich würde eher mal wieder die Speicherbandbreite als kritisch ansehen. Das hängt aber letzten Endes davon ab welcher RAM nun wirklich benutz wird.

Gast

2004-02-20, 14:44:44

Original geschrieben von Demirug
IMHO sehr gut. nVidia wusste sehr genau wo die Probleme lagen. Die Frage ist nur was wird der neue Engpass sein?

Nvidia weiß jetzt über die Probleme Bescheid. Die Frage ist doch haben sie über die Probleme auch schon im April 2002 Bescheid gewusst, als die NV40-Serienentwicklung gestartet wurde?

Ich tendiere hier eher zu einem Nein, da sie zu der Zeit auch noch keine NV30 - Erfahrungen hatten und der Chip nur als Emulation vorhanden war.

Es ist jetzt leicht zu sagen, klar das wissen sie. Das hilft ihnen aber nicht weiter, wenn sie es nicht schon vor jetzt fast genau 2 Jahren gewusst haben.

Der imho einzige Lichtblick könnte sein, das sie den NV40 anscheinend ja umkonstruiert haben und der jetzige NV40 eigentlich ein NV45 ist (wenn die Gerüchte stimmen). Die ca. 20Mio zusätzlichen Transistoren könnten zum Teil zumindest in erweiterte und verbesserte Register geflossen sein.

Winter[Raven]

2004-02-20, 14:51:57

April 2002 Bescheid gewusst, als die NV40-Serienentwicklung gestartet wurde?

Tut mir leit Gast, aber du glaubst doch nicht in wirklichkeit das die Entwicklung einer neuen Generation <=12 Monat einnimmt, oder?

Nvidia wusste sicherlich schon zu derzeit als sie den NV30 entwickelt haben wo die Probleme liegen, ihnen gingen schlichtt und einfach die Transitoren aus um diese "Engpässe" auszubügeln. Den 130 millen @ 0.13µ war neuland.

Und wie kommst du auf 20millen mehr ? Gerüchten zufolge besteht der Nv40 aus ca 170-175 Millionen Transistoren, das wären 40-45 millionen Transis mehr auf den NV35 bezogen.

Demirug

2004-02-20, 15:01:18

Original geschrieben von Gast
Nvidia weiß jetzt über die Probleme Bescheid. Die Frage ist doch haben sie über die Probleme auch schon im April 2002 Bescheid gewusst, als die NV40-Serienentwicklung gestartet wurde?

Ich tendiere hier eher zu einem Nein, da sie zu der Zeit auch noch keine NV30 - Erfahrungen hatten und der Chip nur als Emulation vorhanden war.

Es ist jetzt leicht zu sagen, klar das wissen sie. Das hilft ihnen aber nicht weiter, wenn sie es nicht schon vor jetzt fast genau 2 Jahren gewusst haben.

Der imho einzige Lichtblick könnte sein, das sie den NV40 anscheinend ja umkonstruiert haben und der jetzige NV40 eigentlich ein NV45 ist (wenn die Gerüchte stimmen). Die ca. 20Mio zusätzlichen Transistoren könnten zum Teil zumindest in erweiterte und verbesserte Register geflossen sein.

Sie wussten schon beim Design NV35 wo das Problem des NV30 lag. Allerdings konnte man dort nicht mehr genug ändern.

Das Tempfile war ursprünglich grösser geplannt aber sie sind damit über das Limit desen was bei TSMC machbar war hinausgeschossen. Der Split bei den FP-Rechenwerken war nach der Meinung von nVidia ja nicht nötigt weil diese ja ursprünglich nur für das Berechnen von Texturkoordinaten genutzt werden sollten. Die FX12 Rechenwerke haben den Split. Und das die FX12 Rechenwerke überhaupt noch vorhanden sind hängt eben auch mit dem nVidia-Shadermodel zusammen das MS nicht gefallen hat. Im Prinzip wusste nVidia bei der Verabschiedung der entgültigen DX9 Spec das sie ein grosses Problem haben. Die Spec wurde verabschiedet bevor das Design des NV40 begonnen wurde.

Demirug

2004-02-20, 15:02:47

Original geschrieben von Winter[Raven]
Tut mir leit Gast, aber du glaubst doch nicht in wirklichkeit das die Entwicklung einer neuen Generation <=12 Monat einnimmt, oder?

Doch das mit April 2004 stimmt (+- einen Monat).

Godmode

2004-02-20, 15:13:24

Original geschrieben von Demirug
Welche? Die gibt es ja massenhaft in einem solchen Chip. Ich persönlich würde eher mal wieder die Speicherbandbreite als kritisch ansehen. Das hängt aber letzten Endes davon ab welcher RAM nun wirklich benutz wird.

Also beim Speicher bin ich mir fast schon sicher das sie GDDR3 verwenden da auch der R420 diesen Speicher verwendet und die News vor ein paar Tagen hat ja das ganze noch einmal gefestigt. Ich wette fast das Nvidia den aller schnellst möglichen Speicher den es für Geld zu kaufen gibt auf die Ultra Boards drauf machen wird. Wenn sie 800MHz schaffen haben sie sicherlich weniger Probs mit der Speicherbandbreite. Naja wird werden es ja bald erfahren was sie uns liefern werden.

Quasar

2004-02-20, 15:23:21

Könnte ein MOD mal bitte den Thread-Titel ändern?

Momentan steht da "...Sahderleistung..." statt "Shaderleistung"

Gast

2004-02-20, 15:24:53

Der R420 soll 3.0 Schader unterstützen (http://www.tweakpc.de/mehr_all.php?news_id=5372&s=0&s1=8)

Demirug

2004-02-20, 15:30:18

Original geschrieben von Gast
Der R420 soll 3.0 Schader unterstützen (http://www.tweakpc.de/mehr_all.php?news_id=5372&s=0&s1=8)

Würde dort (http://lists.netsys.com/pipermail/full-disclosure/2004-February/017613.html) besser passen.

Ist eine xbit-Meldung abgeschrieben/übersetzt. Diese haben wiederum die Featureliste des R420 bei Anand abgeschrieben und dabei die 3.0 Shader hinzugefügt.

Winter[Raven]

2004-02-20, 15:51:27

@ Gast

guchst du hier:

http://80.237.203.42/vbulletin/showthread.php?s=&threadid=126074

Gast

2004-02-20, 16:13:34

Original geschrieben von Gast
Der R420 soll 3.0 Schader unterstützen (http://www.tweakpc.de/mehr_all.php?news_id=5372&s=0&s1=8)
Leider wieder nichts handfestes, da TweakPC auch gern von anderen Seiten abschreibt (was ja an sich nicht wirklich schlimm ist). Nur falls diese Infos teilweise reine Mundpropaganda sind, wird plötzlich aus einer Wahrheit eine ganz andere.

marco42

2004-02-20, 16:24:34

Original geschrieben von Demirug
Der Combiner kann bis zu 2 unabhängige Vector4 Ops ausführen. nVidia hat nun aber die Option diesen Combiner teilbar zu machen. Dann hätten wir es mit 4 Ops zu tun. Erweitert man diesen Combiner noch etwas (Modifiziere) lässt er sich auch für DX7;DX8 Zwege benutzten. nVidia kann dann die beiden FX12 Combiner entfernen und durch einen der neuen ersetzen. Womit für DX7;DX8 Anwendungen weiterhin 2 Combiner zur verfügung stehen.

Ich hatte deinen Artikel so verstanden, dass sie es schon beim NV35 so gemacht haetten.

NV_fragment_program
What is the interaction with NV_register_combiners?

RESOLVED: Register combiners are not available when fragment programs
are enabled.

Previous version of this specification supported the notion of
combiner programs, where the result of fragment program execution was
a set of four "texture lookup" values that fed the register combiners.

Das hier habe ich dann auch so interpretiert. Oder habe ich da was falsch verstanden?

robbitop

2004-02-20, 16:41:56

@Demirug
sagmal wäre es auch möglich die R300 Pipelines im R420 mit je 2 TMUs auszustatten? Schliesslich hat man nach deiner These ja nun 2 FPUs, welche jeweils an eine TMU einen Farbwert übergeben können. Oder ginge dies erst nach größeren Umbauten? Denn trilineare TMUs und deren Anbindung zu realisieren ist sicher auch keine Einfache Sache und in der Praxis sollte 8x2bi flexibler sein als 8x1tri.

Demirug

2004-02-20, 16:44:05

Original geschrieben von marco42
Ich hatte deinen Artikel so verstanden, dass sie es schon beim NV35 so gemacht haetten.

In meinem Artikel ging ich damals nur auf PS 2.0 ein. Bezüglich der verarbeitung von DX7, DX8 Shadertechnik steht da überhaupt nichts.

Das hier habe ich dann auch so interpretiert. Oder habe ich da was falsch verstanden?

Ja und Nein. Du kannst die Registercombiner Extension und die neuen Fragmentprogramm Extension nicht gleichzeitig nutzen. Die Fragment Extension erlaubt aber einen Zugriff auf die FX12 Rechenwerke. Aufgrund von bestimmten Schaltungen ist es aber nicht möglich im gleichen Takt die FP und die FX Combiner zu nutzen. Darum muss sich aber der Shadercompiler kümmern.

Demirug

2004-02-20, 16:48:37

Original geschrieben von robbitop
@Demirug
sagmal wäre es auch möglich die R300 Pipelines im R420 mit je 2 TMUs auszustatten? Schliesslich hat man nach deiner These ja nun 2 FPUs, welche jeweils an eine TMU einen Farbwert übergeben können. Oder ginge dies erst nach größeren Umbauten? Denn trilineare TMUs und deren Anbindung zu realisieren ist sicher auch keine Einfache Sache und in der Praxis sollte 8x2bi flexibler sein als 8x1tri.

Sicherlich kann ATI da auch eine 2 TMU und einen zusätliche Einheit für T-OPS verbauen. Mir ging es ja hier nur um die Rechenleistung die bei PS >= 2.0 ja zunehmend wichtiger als die Texturleistung wird.

Ob sie nun 2 bi oder eine Tri reinbauen kommt von Designaufwand etwa auf das gleiche heraus. 2 Bis würde aber mehr transitoren brauchen. Da heute sowieso fast alles Tri oder besser gefiltert wird scheint mir eine TRI-TMU wahrscheinlicher. Gerade weil der Chip und Speichertakt wohl relative Syncron ausfallen soll.

marco42

2004-02-20, 23:10:01

Original geschrieben von Demirug
Ja und Nein. Du kannst die Registercombiner Extension und die neuen Fragmentprogramm Extension nicht gleichzeitig nutzen. Die Fragment Extension erlaubt aber einen Zugriff auf die FX12 Rechenwerke. Aufgrund von bestimmten Schaltungen ist es aber nicht möglich im gleichen Takt die FP und die FX Combiner zu nutzen. Darum muss sich aber der Shadercompiler kümmern.

Ja, und genau deshalb dachte ich, dass sie schon beim NV35 die Register Combiner durch Float Arithmethic Combiner ausgetauscht haben.

Demirug

2004-02-20, 23:12:55

Original geschrieben von marco42
Ja, und genau deshalb dachte ich, dass sie schon beim NV35 die Register Combiner durch Float Arithmethic Combiner ausgetauscht haben.

Der einen Float Combiner hat nicht genügend Rechenleistung um die FX Combiner zu ersetzten. Es ist wahrscheinlich das bestimmte Transitoren gemeinsam benutzt werden.

marco42

2004-02-20, 23:20:36

Original geschrieben von Demirug
Der einen Float Combiner hat nicht genügend Rechenleistung um die FX Combiner zu ersetzten. Es ist wahrscheinlich das bestimmte Transitoren gemeinsam benutzt werden.

Hmm, da fuer viele Farbberechnungen ja 16 bit fixed point voll ausreichen wuerden. Wuerde mich mal interessieren, ob sie sowas in HLSL drin haben. Ok, da ich fuer sowas ja sowieso oft funktionen wie mix(src, dest) verwende, macht das nicht so viel aus, wenn nicht. Aber interessant waere es schon. GLSlang kennt ja nur Integer und Float.

Pauke

2004-02-22, 15:32:15

Hallo ,

Hoffen wir mal, das es dann auch in 10 Jahren die passenden Games dazu gibt.:-(

Gruß

Godmode

2004-02-23, 15:39:49

Original geschrieben von Pauke
Hallo ,

Hoffen wir mal, das es dann auch in 10 Jahren die passenden Games dazu gibt.:-(

Gruß

Warum die passenden Games?? Also zb kann man alte Spiele schnell patchen fals es die Engine zulässt und neue Spiele werden 3.0 Shader nützen. Du glaubst doch nicht im ernst das John Carmack und Co. nicht auf Shader 3.0 setzen werden?. Diese GPUs gehören in 3 Jahren auch wieder zum alten Eisen und du kannst damit die neuen Games nicht mehr gut Spielen. Oder du meinst doch damit das die Games fast nichts von den Features untestützen die eine moderne GPU bietet? Oder verstehe ich dich hier falsch?

ice cool69

2004-02-24, 15:58:14

Nützen und ausnützen ist ein Unterschied, Doom3 ist in der gleichen Qualität auch auf einer DX7-Karte möglich, Shader werden nur zur Geschwindigkeitsoptimierung verwendet.

Wenn der Speed stimmt isses egal ob Shader 2.0 oder 3.0

Demirug

2004-02-24, 16:33:40

Original geschrieben von ice cool69
Nützen und ausnützen ist ein Unterschied, Doom3 ist in der gleichen Qualität auch auf einer DX7-Karte möglich, Shader werden nur zur Geschwindigkeitsoptimierung verwendet.

Jaein. Wenn möglich (ab DX9 Karten) wird das normalisieren von Vektoren mathematisch gemacht. Alle anderen Karten nutzen eine Cubemap dafür. Das rechnen ist etwas etwas genauer.

Wenn der Speed stimmt isses egal ob Shader 2.0 oder 3.0

Wenn der Speed stimmt ist es doch immer egal warum, oder?

Es ist aber durchaus denkbar das mit 3.0 Shaderhardware der eine oder andere Takt eingespart werden kann.

Godmode

2004-02-24, 20:32:29

Ich hab jetz schon öfters was davon gehört das mit man mit Shader 3.0 Physikberechnungen auf der GPU ausführen könnte, zb für Stoffe (PCGH 02/04 Artikel Wissen: VGA Trends 2004) Ist da was dran, oder ist das wieder nur Unfug und viel zu aufwändig/langsam um es in ein Spiel zu implementieren?

aths

2004-02-27, 23:30:44

Original geschrieben von bans3i
Ich hab jetz schon öfters was davon gehört das mit man mit Shader 3.0 Physikberechnungen auf der GPU ausführen könnte, zb für Stoffe (PCGH 02/04 Artikel Wissen: VGA Trends 2004) Ist da was dran, oder ist das wieder nur Unfug und viel zu aufwändig/langsam um es in ein Spiel zu implementieren? Ist begrenzt möglich, denke aber nicht, dass das bald in Spielen zu sehen ist.

ice cool69

2004-03-02, 12:20:05

Wenn der R420 so schnell sein wird bei Shadern 2.X wie nvidia bei 3.0 sehe ich keine Nachteile, da man unter 3.0 keine exklusiven Effekte bekommt.
Es kommt meiner Meinung nach viel mehr auf die Shader-Performance an welche sich eindeutig nicht aus der Ziffer 2 oder 3 alleine zusammensetzt.
Schon nvidias Shader 2.0+ waren deutlich langsamer als ATIs Shader 2.0 trotz geringerer Komplexität.

Es erscheint mir ja logisch dass sich hier der eine oder andere Crack wie Demirug über mehr Komplexität freut, für den Spieler ist das aber gänzlich uninteressant, hier zählt nur das Endergebnis und da hats bei nvidia schon immer düsterer ausgesehen als auf den Tec-Sheets.

LovesuckZ

2004-03-02, 12:21:50

Godmode

2004-03-02, 12:44:41

Original geschrieben von ice cool69
hier zählt nur das Endergebnis und da hats bei nvidia schon immer düsterer ausgesehen als auf den Tec-Sheets.

Also das es schon "immer" düster ausgesehen hat, da kann ich dir nicht zustimmen!! Geforce1-4 waren ja wirklich zu ihrer Zeit die schnellsten Grafikkarten die es auf dem Markt gab. Nur mit der FX-Serie hat es Nvidia nicht mehr geschaft diese Dominanz in Geschwindigkeit weiterzuführen. Sie hatten sich die Ziele einfach zu hoch gesteckt!! 0,13 war für so einen rießen Chip einfach noch etwas zu früh!! Da hats ATI besser gemacht, und zuerst die Mainstream Chips in 0,13 gefertigt.

2004-03-02, 13:52:18

aths

2004-03-02, 14:17:19

Original geschrieben von ice cool69
Wenn der R420 so schnell sein wird bei Shadern 2.X wie nvidia bei 3.0 sehe ich keine Nachteile, da man unter 3.0 keine exklusiven Effekte bekommt. The future is not written yet.

Wäre ich NV, würde ich aus der Portokasse was locker machen, um den Einsatz von 3.0 für exklusive Effekte zu fördern. Ob das Sinn macht, also der Effekt nicht doch auch mit 2.0 darstellbar wäre, wäre mir als Vermarktungs-Fuzzi egal.

robbitop

2004-03-02, 15:35:17

@aths
aber in ca 12 Monaten wird ATi mit dem R500 ebenfalls eine mind PS3 fähige VPU haben und wenn du JETZT was aus der Portokasse erst zahlst, dann bringt es zeitlich wohl kaum noch Vorteile...das hätte man schon vor einer Weile machen sollen.

r@w

2004-03-02, 15:38:49

Original geschrieben von robbitop
@aths
aber in ca 12 Monaten wird ATi mit dem R500 ebenfalls eine mind PS3 fähige VPU haben und wenn du JETZT was aus der Portokasse erst zahlst, dann bringt es zeitlich wohl kaum noch Vorteile...das hätte man schon vor einer Weile machen sollen. Und warum sollte dies nicht Fall gewesen sein ?
Schließlich kann man auch proggen, ohne zu 'probieren' !
:D

Razor

aths

2004-03-02, 17:10:13

Original geschrieben von robbitop
@aths
aber in ca 12 Monaten wird ATi mit dem R500 ebenfalls eine mind PS3 fähige VPU habenDas ist zu hoffen, ja.

Original geschrieben von robbitop
und wenn du JETZT was aus der Portokasse erst zahlst, dann bringt es zeitlich wohl kaum noch Vorteile...das hätte man schon vor einer Weile machen sollen. Ja, NV müsste natürlich versuchen, das Image technologischer Führerschaft wiederzugewinnen, bevor ATI (mindestens) aufgeholt hat.

egdusp

2004-03-02, 17:37:06

Original geschrieben von ice cool69
Wenn der R420 so schnell sein wird bei Shadern 2.X wie nvidia bei 3.0 sehe ich keine Nachteile, da man unter 3.0 keine exklusiven Effekte bekommt.

Falsch. Es läßt sich zwar jeder PS 3.0 Shader in PS 2.0 nachbilden, aber teilweise nur mit einem Bruchteil der Geschwindigkeit. Bisher gibt es in Spielen keine PS 2.0 Shader die durch PS 3.0 stark profitieren würden, aber umgekehrt ist es ohne weiteres möglich, dass es PS 3.0 "exklusive" Effekte gibt, da die Ausführungsgeschwindigkeit in PS 2.0 zu langsam wäre.
Original geschrieben von ice cool69
Es kommt meiner Meinung nach viel mehr auf die Shader-Performance an welche sich eindeutig nicht aus der Ziffer 2 oder 3 alleine zusammensetzt.
Schon nvidias Shader 2.0+ waren deutlich langsamer als ATIs Shader 2.0 trotz geringerer Komplexität.

Da ziehst du falsche Kausalschlüsse. NV Shader waren nicht lngsamer weil sie komplexer waren, sondern weil sie einen enormen Engpass hatten (Temp Register zu klein) (dies hat nichts mit der Komplexität der Shader zu tun) und weil der Shadercode meistens auf ATI optimiert war, was NV nicht geschmeckt hat (hat ebenfalls nichts direkt mit der Komplexität der Shader zu tun).

Wie eigentlich Demis Erklärungen am Anfang dieses Thread zeigen (die du sicher gelesen hast, da du hier postest), kann die NV Architektur prinzipiell trotz höherer Komplexität sehr wohl performancemäßig mit ATI mithalten, sofern die Engpässe beseitigt werden und zwar auch bei PS 2.0

Original geschrieben von ice cool69
Es erscheint mir ja logisch dass sich hier der eine oder andere Crack wie Demirug über mehr Komplexität freut, für den Spieler ist das aber gänzlich uninteressant, hier zählt nur das Endergebnis und da hats bei nvidia schon immer düsterer ausgesehen als auf den Tec-Sheets.

Immer? Auf den Spec Sheets war der R200 der GF3 und sogar der GF4 überlegen, aber in der Realität sah es dann doch anders aus.

mfg
egdusp

Sphinx

2004-03-03, 00:45:04

Original geschrieben von egdusp

und weil der Shadercode meistens auf ATI optimiert war, was NV nicht geschmeckt hat (hat ebenfalls nichts direkt mit der Komplexität der Shader zu tun).

mfg
egdusp

Falsch.

Winter[Raven]

2004-03-03, 01:02:48

Original geschrieben von Sphinx
Falsch.

Naja man kann für "optimiert" auch das Wort Falsches DX SDK Runtime setzen. Das numal nicht so dolle den Code für FX kompilieren konnte.

Ailuros

2004-03-03, 01:07:25

Original geschrieben von Winter[Raven]
Naja man kann für "optimiert" auch das Wort Falsches DX SDK Runtime setzen. Das numal nicht so dolle den Code für FX kompilieren konnte.

Oder man kann auch (wie bei NV intern) einsehen, dass die ganze Design-Idee doch nicht so toll war. Noch ein paar Monate und NV wird von NV3x nicht mehr viel hoeren wollen.

egdusp

2004-03-03, 02:01:25

Original geschrieben von Sphinx
Falsch.

Falsch auf "optimiert für ATI" oder "hat NV nicht so geschmeckt"?

AFAIK ist der überwiegende Teil des PS 2.0 Shadercodes in Spielen auf ATI optimiert.

mfg
egdusp

robbitop

2004-03-03, 09:09:30

naja afair indirekt.
R300 kam als erster und somit richteten sich die Entwickler nach dem R300. Der NV3x brauchte einen eigenen Shadercompiler, weil der von MS dem Design nur zugesetzt hat. Ich denke mal man hat sich mit NV30 verkalkuliert.
Ursprünglich wollte man wohl 2002 auf den Markt kommen und hat nicht mit einem so starken R300 gerechnet, so dass die Developer gleich alle auf CineFX setzten.

r@e

2004-03-06, 05:30:51

Original geschrieben von robbitop
naja afair indirekt.
R300 kam als erster und somit richteten sich die Entwickler nach dem R300. Der NV3x brauchte einen eigenen Shadercompiler, weil der von MS dem Design nur zugesetzt hat. Ich denke mal man hat sich mit NV30 verkalkuliert.
Ursprünglich wollte man wohl 2002 auf den Markt kommen und hat nicht mit einem so starken R300 gerechnet, so dass die Developer gleich alle auf CineFX setzten. Und Du meinst also nicht, dass die M$ Entscheidung, die DX9-Mindestanforderungen exakt (!) auf den R300 zuzuschneiden, damit zusammen hängen könnte, dass es da noch so etwas wie die XBOX im Interessenfeld von M$ gibt ?
:???:

Der neue Kontrakt mit ATI und auch die Unzufriedenheit mit nVidia in diesem Kontext spricht Bände...
Microsoft hat wieder mal in den Hardware-Markt 'eingegriffen' und damit das Kräfteverhältnis vom einen zum anderen hin verschoben. Vorher eindeutige Marktdominanz von nVidia (und damit verbunden die teuren XBÖXchen ;-), nun ist nVidia noch immer Marktführer, aber mit einem deutlich geringeren Abstand. Und des nächste XBÖXchen wird viel, viel günsitiger (in der Herstellung)...

Ende gut, alles gut...
...oder ?

Razor

mapel110

2004-03-06, 05:42:35

Wusste M$, dass Nvidia so derbe Performance-Probleme bei voller Präzision bekommt?
(btw ist übrigens ja nicht die einzige Design-Schwäche der GPU )

Ansonsten, es legt halt immer der technologisch niedrigste Chip das low end für DX fest.

Gast

2004-03-06, 06:53:50

Original geschrieben von mapel110
Wusste M$, dass Nvidia so derbe Performance-Probleme bei voller Präzision bekommt?
(btw ist übrigens ja nicht die einzige Design-Schwäche der GPU )

Ansonsten, es legt halt immer der technologisch niedrigste Chip das low end für DX fest.

ich denke schon das M$ wusste, dass die NV3x Reihe zwar FP32 beherrscht aber eher auf FP16 ausgelegt war. Die Entwicklung begann ja schon recht früh und deutlich vor ATI und vor allem vor dem Festlegen der DX9 Spec.

M$ hat sich da einfach auf seine Art und Weise bedankt, weil sie bei der x-box1 geschlafen haben.
Allein deshalb ist mir Nvidia schon sympatisch. Es sind die ersten, die so dreist waren und MS mal richtig die Hosen ausgezogen haben wie es sich gehört. Wenns nach mir ginge, würde diese Firma noch sehr viel mehr bezahlen und bei DX9 kein Wörtchen mehr mitreden dürfen. Windows Monopol ist schon schlimm genug.

r@e

2004-03-06, 08:07:09

Original geschrieben von mapel110
Wusste M$, dass Nvidia so derbe Performance-Probleme bei voller Präzision bekommt?
(btw ist übrigens ja nicht die einzige Design-Schwäche der GPU )Völlig uninteressant...
Original geschrieben von mapel110
Ansonsten, es legt halt immer der technologisch niedrigste Chip das low end für DX fest. Das wäre dann ja wohl der NV30 gewesen, der mit INT12 und fp16 daher kam.
Wieso das wohl nicht unteres Limit geworden ist ?

Und Wieso also gerade fp24 ?
Also oberes Limit und nicht unteres ?
Naaaaaa ?
;-)

Razor

P.S.: Das der RefRast keine fp24 beherrscht, dürfte hier wohl Bände sprechen...

r@e

2004-03-06, 08:20:54

Original geschrieben von Gast
...M$ hat sich da einfach auf seine Art und Weise bedankt, weil sie bei der x-box1 geschlafen haben. <snap> Es sind die ersten, die so dreist waren und MS mal richtig die Hosen ausgezogen haben wie es sich gehört....Jo, aber man hat gut gesehen, dass sich selbst eine Firma wie nVidia nicht mit DEM Software-Giganten anlegen kann, ohne Federn zu lassen.

Man möge sich vorstellen, was passiert wäre, wenn die unteren Specs von DX9 auf Basis des NV30 festgelegt worden wären. Das Bild würde sich vermutlich umgekehrt darstellen. INT12 und fp16 wären per default 'erlaubt' und ausreichend, ATI hätte aber auch in diesen Fällen mit fp24 rechnen müssen.

Aber dieses "was-wäre-wenn"-Spielchen macht IMO nur wenig Sinn, denn es führt einfach zu nichts.

Interessant wird es nun mit dem NV40, weil nVidia ja nun von Anfang an die (finalen) DX9-Specs 'kannte' und diese somit nun in der neuen Architektur berücksichtigen konnte. Eine kleine Aussicht darauf gibt es ja schon: Volle VS/PS3.0-Unterstützung...

-

Was mich allerdings wundert, ist, dass ATI wohl nicht in der Lage war, die VS/PS 3.0-Specs zu implementieren. So scheinen nunmehr doch diejenigen recht zu behalten, die damals behaupteten, dass sich nVidia reichlich weit mit der NV30-Architektur as dem Fenster lehnte, bei Umsetzung der vollen DX9-Specs aber nicht die Probleme haben würden, vor denen ATI nun zu stehen scheint.

-

Und ach ja... gibt es überhaupt schon einen anderen DX9-Chip mit einer fp24-Präzision ?
:D

Razor

Exxtreme

2004-03-06, 08:21:47

Original geschrieben von r@e
Völlig uninteressant...
Das wäre dann ja wohl der NV30 gewesen, der mit INT12 und fp16 daher kam.
Wieso das wohl nicht unteres Limit geworden ist ?

FP16 wäre tatsächlich gar nicht so schlecht gewesen als "unteres" Limit ... zumindest bei der Farbtiefe. Bei Textur-Adressierung kommst du mit 16 Bit FP nicht sehr weit.
Original geschrieben von r@e
Und Wieso also gerade fp24 ?
Also oberes Limit und nicht unteres ?
Naaaaaa ?
;-)

Razor

Siehe oben.
Original geschrieben von r@e
P.S.: Das der RefRast keine fp24 beherrscht, dürfte hier wohl Bände sprechen...
Was habt ihr denn immer mit dem RefRast? Das Teil ist ein Diagnose-Tool und ist nicht dazu gedacht als allgemeingültige Referenz zu dienen. Das Teil ist dazu da damit die Entwickler prüfen können ob ein Programm eine korrekte Ausgabe produziert.

r@e

2004-03-06, 08:34:47

Original geschrieben von Exxtreme
FP16 wäre tatsächlich gar nicht so schlecht gewesen als "unteres" Limit ... zumindest bei der Farbtiefe. Bei Textur-Adressierung kommst du mit 16 Bit FP nicht sehr weit.Was der Grund dafür sein dürfte, warum nVidia schon seit jeher mit fp32 'rechnet'...
Auch fp24 sind doch wohl eigentlich zu 'unpräzise', oder ?
;-)
Original geschrieben von Exxtreme
Was habt ihr denn immer mit dem RefRast? Das Teil ist ein Diagnose-Tool und ist nicht dazu gedacht als allgemeingültige Referenz zu dienen. Das Teil ist dazu da damit die Entwickler prüfen können ob ein Programm eine korrekte Ausgabe produziert. Korrekte Ausgabe ?
Worauf ?
:???:

Schließlich sieht's auf 'ner ATI etwas anders aus, als auf 'ner nVidia, oder ?
Aber mir ist schon klar, was Du damit sagen willst...

Nur mein Anliegen ist eingentlich ein anderes:
- wo finden sich in DX9 sonst noch Hinweise auf diese uminösen fp24 ?
- warum wurde die Mindestpräzision nicht bei fp16 (oder gar int12) festgelegt und nur da mit einer höheren Präzision belegt, wo es Sinn macht (wie eben bei der von Dir genannten Texturadressierung) ?

-

Für mich ist es absolut eindeutig, dass nVidia hier ein mächtiger 'Dämpfer' aufgesetzt wurde. Was aber IMO eine - auch für den Endkunden zuträgliche - 'Marktbereinigung' ausgelöst hat (fast Pari zwischen den Großen), M$ aber einen vermutlich äusserst lukrativen Deal für die XBOX2 einbrachte und damit gleichzeitig ein Signal setzte, sich nicht mit dem Großmogul der Computerwelt anzulegen...

OK, klang jetzt vermutlich etwas theatralisch, oder ?
:D

Razor

Exxtreme

2004-03-06, 08:36:21

Original geschrieben von r@e
Man möge sich vorstellen, was passiert wäre, wenn die unteren Specs von DX9 auf Basis des NV30 festgelegt worden wären. Das Bild würde sich vermutlich umgekehrt darstellen. INT12 und fp16 wären per default 'erlaubt' und ausreichend, ATI hätte aber auch in diesen Fällen mit fp24 rechnen müssen.

Dieser Umstand hätte beim R300 keinerlei negative Auswirkungen. Der R300 macht alles mit 24 Bit FP egal ob FX9, FX12 oder FP16. Der NV3x hätte hier Vorteile ggü. der jetzigen Situation, der R300 aber keine NAchteile.
Original geschrieben von r@e
Eine kleine Aussicht darauf gibt es ja schon: Volle VS/PS3.0-Unterstützung...

... die einige Leute hier ziemlich überschätzen. Und ob tatsächlich VS3.0 unterstützt wird, habe ich noch nirgends nachlesen können ... ausser bei :cop: FUAD :cop:. VS3.0 finde ich eigentlich viel interessanter als PS3.0. Mit VS3.0 wird "echtes" Displacement Mapping möglich.

PS3.0 verhält sich zu PS2.0 ähnlich wie PS1.4 zu PS1.3. Und wie du über die PS1.4 denkst, das wissen so ziemlich alle hier. Und deshalb wundert es mich, daß dir die PS3.0 so gefallen.
Original geschrieben von r@e
Was mich allerdings wundert, ist, dass ATI wohl nicht in der Lage war, die VS/PS 3.0-Specs zu implementieren. So scheinen nunmehr doch diejenigen recht zu behalten, die damals behaupteten, dass sich nVidia reichlich weit mit der NV30-Architektur as dem Fenster lehnte, bei Umsetzung der vollen DX9-Specs aber nicht die Probleme haben würden, vor denen ATI nun zu stehen scheint.

Vielleicht waren die Vorteile, die PS/VS3.0 mit sich bringen, für ATi nicht groß genug um dafür Millionen von Transistoren zu opfern. Die wahren Gründe kennt wohl nur ATi.
Original geschrieben von r@e
Und ach ja... gibt es überhaupt schon einen anderen DX9-Chip mit einer fp24-Präzision ?
:D

Razor
Deltachrome von S3.

r@e

2004-03-06, 08:59:54

Original geschrieben von Exxtreme
Dieser Umstand hätte beim R300 keinerlei negative Auswirkungen. Der R300 macht alles mit 24 Bit FP egal ob FX9, FX12 oder FP16. Der NV3x hätte hier Vorteile ggü. der jetzigen Situation, der R300 aber keine NAchteile.Du willst mich nicht verstehen, oder ?
Klar wäre der R300 benachteiligt, wenn er alles mit voller interner Präzision rechnen müsste, obwohl dies gar nicht erforderlich ist.

Aber wenn Du es so sehen willst:
Der Vorteil des einen ist der Nachteil des anderen.
Oder siehst Du auch das anders ?
Original geschrieben von Exxtreme
... die einige Leute hier ziemlich überschätzen. Und ob tatsächlich VS3.0 unterstützt wird, habe ich noch nirgends nachlesen können ... ausser bei :cop: FUAD :cop:. VS3.0 finde ich eigentlich viel interessanter als PS3.0. Mit VS3.0 wird "echtes" Displacement Mapping möglich. Solange nichts Offizielles von den Herstellern kommt, ist doch wohl alles Spekulation, oder ?
Das die VS3.0 interessanter sind, unterschreibe ich Dir aber keinesfalls. Allerdings wären auch sie sehr interessant, gell ?
;-)
Original geschrieben von Exxtreme
PS3.0 verhält sich zu PS2.0 ähnlich wie PS1.4 zu PS1.3. Und wie du über die PS1.4 denkst, das wissen so ziemlich alle hier. Und deshalb wundert es mich, daß dir die PS3.0 so gefallen.Ganz und gar nicht.
Ich habe nun von der 3D-Programmierung so gut wie keine Ahnung (wenn überhaupt ;-), aber stell Dir mal die klassische Programmierung ohne 'Branching' vor (und das ist nur ein Teil von PS3.0).

Keine Verzweigung innerhalb von Programmen möglich ?
Ja nicht einmal eine Form von Modularisierung (erinnere mich da noch schauderhaft an Modulus 2 ;-) ?

Der Schritt von PS2.0 zu PS3.0 ist gewaltig, erlaubt es doch eine ganz andere Programmiertechnik, als bisher. Schau Dir doch einfach mal HL2 und die Handstände an, die die Entwickler zur Realisierung bestimmter Effekte da machen mussten... und dass die PS3.0 ganz andere (neue) Anforderung an den Pixel-Prozessor stellen, als es die PS2.0 tun, versteht sich damit ja wohl fast von selbst...
Original geschrieben von Exxtreme
Vielleicht waren die Vorteile, die PS/VS3.0 mit sich bringen, für ATi nicht groß genug um dafür Millionen von Transistoren zu opfern. Die wahren Gründe kennt wohl nur ATi.Wenn wir jetzt mal die bisher bekannten 'Spekulationen' für wahr nehmen...

Instruction-Count wurde beim R420 nur auf 512 erhöht ?
Sieht einfach nur nach ein bissel mehr Speicher für die Programme aus, meinst Du nicht ?

Und wenn das die einzige 'Neuerung' im R420 ist (auf DX bezogen), dann ist er nichts anderes, als ein technisch (minimal) aufgebohrter R300 und mehr nicht. Das daraus resultierende Fazit wäre schlicht, dass ATI überhaupt keine (oder nur marginale) Entwicklung in den R420 'investierte'...

So frei nach dem Motto, wenn schon keine Innovation, dann zumindest Power.
Ich drücke ihnen wirklich die Daumen, wenn das stimmen sollte, denn...
Original geschrieben von Exxtreme
Deltachrome von S3. Echt ?
Gibt's dazu schon was Offizielles ?
Würde mich wirklich brennend interessieren !

Razor

LovesuckZ

2004-03-06, 09:02:15

Original geschrieben von r@e
Echt ?
Gibt's dazu schon was Offizielles ?
Würde mich wirklich brennend interessieren !
Razor

Sie unterstuetzen auch FP16.

StefanV

2004-03-06, 09:02:45

Original geschrieben von r@e
Jo, aber man hat gut gesehen, dass sich selbst eine Firma wie nVidia nicht mit DEM Software-Giganten anlegen kann, ohne Federn zu lassen.

Hm, hätte nV sich nicht mit M$ angelegt, dann würden sie jetzt wohl nicht ganz so dumm dastehen, wie sie es mit dem nV30 taten :|

Exxtreme

2004-03-06, 09:04:52

Original geschrieben von r@e
Was der Grund dafür sein dürfte, warum nVidia schon seit jeher mit fp32 'rechnet'...
Auch fp24 sind doch wohl eigentlich zu 'unpräzise', oder ?
;-)

Die 24 Bit FP stoßen erst bei riesigen Texturen an ihre Grenzen. Ich glaube nicht, daß die Gamer Monitore haben, die solche Texturen darstellen können. Um eine solche hochaufgelöste Textur überhaupt zu sehen, muss man mindestens die selbe Auflösung fahren. Ansonsten greift hier das LOD-Bias-System der Grafikhardware ein und man sieht eine "kleinere" Version der Textur damit Pixelflimmern vermieden wird. Von daher reichen 24 Bit FP "noch".
Original geschrieben von r@e
Korrekte Ausgabe ?
Worauf ?
:???:

Schließlich sieht's auf 'ner ATI etwas anders aus, als auf 'ner nVidia, oder ?
Aber mir ist schon klar, was Du damit sagen willst...

Auf die 0,00003625% Abweichung zwischen beiden Kontrahenten kommt es auch mehr an. RefRast ist eigentlich ein Entwicklertool zur Diagnose. Man sieht dann ob die Farben stimmen, oder der eigene Code nur Mist ausgibt. Das Tool ist nicht weder dazu gedacht um Unterschiede aufzudecken, die man eh' mit der Lupe oder per Differenzbild suchen muss, noch dazu da um irgendwelche "Cheats" aufzudecken. Daß es einige Websites dazu nutzen um genau sowas zu tun ... tja, ist halt so.
Original geschrieben von r@e
Nur mein Anliegen ist eingentlich ein anderes:
- wo finden sich in DX9 sonst noch Hinweise auf diese uminösen fp24 ?
- warum wurde die Mindestpräzision nicht bei fp16 (oder gar int12) festgelegt und nur da mit einer höheren Präzision belegt, wo es Sinn macht (wie eben bei der von Dir genannten Texturadressierung) ?

Naja, die absolute Mindestpräzision ist ja FP16. Man muss diese nur explizit aktivieren. Und hier sind jetzt die Spiele-Developer gefragt. Dummerweise ist die R300-HW mit 24 Bit FP oft sehr viel schneller als die NV3x-HW mit FP16. FX12 halte ich für zu gering. Je länger ein Shader ist, desto höher die Wahrscheinlichkeit, daß es zu Rundungsfehlern kommt.
Original geschrieben von r@e
Für mich ist es absolut eindeutig, dass nVidia hier ein mächtiger 'Dämpfer' aufgesetzt wurde. Was aber IMO eine - auch für den Endkunden zuträgliche - 'Marktbereinigung' ausgelöst hat (fast Pari zwischen den Großen), M$ aber einen vermutlich äusserst lukrativen Deal für die XBOX2 einbrachte und damit gleichzeitig ein Signal setzte, sich nicht mit dem Großmogul der Computerwelt anzulegen...

OK, klang jetzt vermutlich etwas theatralisch, oder ?
:D

Razor
Ich kann mir durchaus vorstellen, daß es eine politische Entscheidung war, die Specs für DX9 so festzusetzen wie sie jetzt sind um NV eins reinzuwürgen. Microsoft traue ich in dieser Hinsicht wirklich alles zu.

r@e

2004-03-06, 09:06:57

Original geschrieben von LovesuckZ
Sie unterstuetzen auch FP16. Ah ja ?
Dann auch an Dich die Frage: gibt's dazu etwas Offizielles ?
:???:

Razor

r@e

2004-03-06, 09:07:37

Original geschrieben von Stefan Payne
Hm, hätte nV sich nicht mit M$ angelegt, dann würden sie jetzt wohl nicht ganz so dumm dastehen, wie sie es mit dem nV30 taten :| Ganz im Gegenteil...
:D

Razor

StefanV

2004-03-06, 09:08:05

Original geschrieben von r@e
Instruction-Count wurde beim R420 nur auf 512 erhöht ?
Sieht einfach nur nach ein bissel mehr Speicher für die Programme aus, meinst Du nicht ?

Und wenn das die einzige 'Neuerung' im R420 ist (auf DX bezogen), dann ist er nichts anderes, als ein technisch (minimal) aufgebohrter R300 und mehr nicht. Das daraus resultierende Fazit wäre schlicht, dass ATI überhaupt keine (oder nur marginale) Entwicklung in den R420 'investierte'...

So frei nach dem Motto, wenn schon keine Innovation, dann zumindest Power.
Ich drücke ihnen wirklich die Daumen, wenn das stimmen sollte, denn...
Echt ?
Gibt's dazu schon was Offizielles ?
Würde mich wirklich brennend interessieren !

Razor

Ja, und??

Hat nVidia doch auch gemacht, hat damals gegen die R200 auch funktioniert, warum sollte es jetzt bei ATI nicht auch funktionieren??

Der R420 muss ja 'nur' schneller als der NV40 sein und schon ging ATIs 'Plan' auf...

StefanV

2004-03-06, 09:12:12

Original geschrieben von r@e
Ganz im Gegenteil...

Razor

Nö, lies mal die Infos, die Demi zu diesem Thema rausgelassen hat...

Für mich hörte es sich so an, als ob M$ nV 'einen verpasst' hat, denn nV wollte auch mit Festpunkt arbeiten, eigentlich, nur das ging 'irgendwie' in die Hose...

Exxtreme

2004-03-06, 09:21:02

Original geschrieben von r@e
Du willst mich nicht verstehen, oder ?
Klar wäre der R300 benachteiligt, wenn er alles mit voller interner Präzision rechnen müsste, obwohl dies gar nicht erforderlich ist.

Nein, das hat beim R300 keinerlei Auswirkungen. Der R300 rechnet IMMER mit 24 Bit FP. DirectX verbietet es nicht mit höherer Präzision zu rechnen als erforderlich. Und auch wenn es ein wenig paradox klingt, die Wahrscheinlichkeit, daß DX8-Shader auf dem R300 langsamer laufen als vergleichbare DX9-Shader, ist höher als umgekehrt.
Original geschrieben von r@e
Aber wenn Du es so sehen willst:
Der Vorteil des einen ist der Nachteil des anderen.
Oder siehst Du auch das anders ?
Solange nichts Offizielles von den Herstellern kommt, ist doch wohl alles Spekulation, oder ?

Der Vorteil des einen ist der Nachteil des anderen ... ja das kommt in diesem Fall hin.
Original geschrieben von r@e
Ganz und gar nicht.
Ich habe nun von der 3D-Programmierung so gut wie keine Ahnung (wenn überhaupt ;-), aber stell Dir mal die klassische Programmierung ohne 'Branching' vor (und das ist nur ein Teil von PS3.0).

Keine Verzweigung innerhalb von Programmen möglich ?
Ja nicht einmal eine Form von Modularisierung (erinnere mich da noch schauderhaft an Modulus 2 ;-) ?

Durch Branching kann man die Geschwindigkeit erhöhen da nicht benötigte Codeteile übersprungen werden können. Neue Effekte bringt das aber nicht. Beim PS2.0 kann man sich hier auch behelfen indem man je nach Situation verschiedene Shader auf die GraKa lädt. Hat fast den gleichen Effekt, ist aber langsamer.
Original geschrieben von r@e
Der Schritt von PS2.0 zu PS3.0 ist gewaltig, erlaubt es doch eine ganz andere Programmiertechnik, als bisher. Schau Dir doch einfach mal HL2 und die Handstände an, die die Entwickler zur Realisierung bestimmter Effekte da machen mussten... und dass die PS3.0 ganz andere (neue) Anforderung an den Pixel-Prozessor stellen, als es die PS2.0 tun, versteht sich damit ja wohl fast von selbst...

Heutzutage werden die Shader eh' in HLSL geschrieben und dann entsprechenden Profilen compiliert. Von einer ganz anderen Programmiertechnik kann man hier kaum sprechen.
Original geschrieben von r@e
Wenn wir jetzt mal die bisher bekannten 'Spekulationen' für wahr nehmen...

Instruction-Count wurde beim R420 nur auf 512 erhöht ?
Sieht einfach nur nach ein bissel mehr Speicher für die Programme aus, meinst Du nicht ?

Ja, wahrscheinlich arbeitet der F-Buffer jetzt korrekt. :D
Original geschrieben von r@e
Und wenn das die einzige 'Neuerung' im R420 ist (auf DX bezogen), dann ist er nichts anderes, als ein technisch (minimal) aufgebohrter R300 und mehr nicht. Das daraus resultierende Fazit wäre schlicht, dass ATI überhaupt keine (oder nur marginale) Entwicklung in den R420 'investierte'...

So frei nach dem Motto, wenn schon keine Innovation, dann zumindest Power.

Wenn man sich ausschliesslich auf die Shader bezieht, dann gebe ich dir recht. Aber die Shader sind nur ein Aspekt von vielen, die eine gute GraKa ausmachen.

r@e

2004-03-06, 09:34:13

Original geschrieben von Exxtreme
Die 24 Bit FP stoßen erst bei riesigen Texturen an ihre Grenzen. Ich glaube nicht, daß die Gamer Monitore haben, die solche Texturen darstellen können. Um eine solche hochaufgelöste Textur überhaupt zu sehen, muss man mindestens die selbe Auflösung fahren. Ansonsten greift hier das LOD-Bias-System der Grafikhardware ein und man sieht eine "kleinere" Version der Textur damit Pixelflimmern vermieden wird. Von daher reichen 24 Bit FP "noch".Leider scheint Du bei dieser Betrachtung zu vergessen, dass nVidia hier 'zweigleisig' fährt. Schließlich werden die nVdia GPU's auch auf professionellen Karten verwendet und Du wirst mir hoffentlich zustimmen, dass dort sogar eine 64Bit Präzision bei der Texturadressierung 'sinnvoll' wäre.

Das dürfte dann auch der Grund gewesen sein, warum nVidia selbst beim NV20 intern schon mit 32Bit gerechnet hat (oder gar schon beim NV10 ?).

Mal ganz davon zu schweigen, dass für eine VS/PS3.0-compliance 32Bit doch wohl Voraussetzung sind, oder liege ich da falsch ?
Original geschrieben von Exxtreme
Auf die 0,00003625% Abweichung zwischen beiden Kontrahenten kommt es auch mehr an. RefRast ist eigentlich ein Entwicklertool zur Diagnose. Man sieht dann ob die Farben stimmen, oder der eigene Code nur Mist ausgibt. Das Tool ist nicht weder dazu gedacht um Unterschiede aufzudecken, die man eh' mit der Lupe oder per Differenzbild suchen muss, noch dazu da um irgendwelche "Cheats" aufzudecken. Daß es einige Websites dazu nutzen um genau sowas zu tun ... tja, ist halt so.Meinst Du nicht, dass dieses Tool auch von den Hardware-Entwicklern benötigt wird, um die Ausgabe der Treiber gegen zu checken ?

Aber trotzdem nochmal meine Frage:
Was bitte weist in den DX9-Specs noch auf die fp24 hin ?
Nichts ?
Original geschrieben von Exxtreme
Naja, die absolute Mindestpräzision ist ja FP16. Man muss diese nur explizit aktivieren. Und hier sind jetzt die Spiele-Developer gefragt. Dummerweise ist die R300-HW mit 24 Bit FP oft sehr viel schneller als die NV3x-HW mit FP16. FX12 halte ich für zu gering. Je länger ein Shader ist, desto höher die Wahrscheinlichkeit, daß es zu Rundungsfehlern kommt. Warum soll es ein Entwickler nicht selbst in der Hand haben, in welchem Format gerechnet werden soll ? Und wo bitte kann ich Deine Behauptung nachprüfen, dass die R3x0-Hardware unter fp24 'oft' schneller ist, als die NV3x-Hardware unter fp16 ? Inbesonders auf die NV35+ möchte ich hier das Augenmerk legen...

Das Ergebnis für 2x2 ist sowohl unter INT12, wie auch fp16, fp24 und fp32 immer das gleiche...
Original geschrieben von Exxtreme
Ich kann mir durchaus vorstellen, daß es eine politische Entscheidung war, die Specs für DX9 so festzusetzen wie sie jetzt sind um NV eins reinzuwürgen. Microsoft traue ich in dieser Hinsicht wirklich alles zu. Nicht nur, um nVidia "eins reinzuwürgen", sondern auch, um der Hardware von ATI einen Vorteil zu verschaffen (funktioniert ja in beide Richtungen ;-).

Wenn dem so wäre - wirklich ein gelungener Deal:
ATI bekommt mehr Martanteile und M$ günstige XBOX2-Hardware. Dass nVidia zusätzlich einen Dämpfer bekommt, dürfte im GraKa-Markt sicher auch ein Zeichen gesetzt haben...

Spekulation ist schon was Feines, gell ?
:D

Razor

Exxtreme

2004-03-06, 09:48:02

Original geschrieben von r@e
Leider scheint Du bei dieser Betrachtung zu vergessen, dass nVidia hier 'zweigleisig' fährt. Schließlich werden die nVdia GPU's auch auf professionellen Karten verwendet und Du wirst mir hoffentlich zustimmen, dass dort sogar eine 64Bit Präzision bei der Texturadressierung 'sinnvoll' wäre.

Das dürfte dann auch der Grund gewesen sein, warum nVidia selbst beim NV20 intern schon mit 32Bit gerechnet hat (oder gar schon beim NV10 ?).

Naja, intern rechnet schon die Voodoo1 mit 32 Bit Farbtiefe. Bitte hier nicht Farbtiefe mit Shadergenauigkeit verwechseln.
Original geschrieben von r@e
Mal ganz davon zu schweigen, dass für eine VS/PS3.0-compliance 32Bit doch wohl Voraussetzung sind, oder liege ich da falsch ?
Meinst Du nicht, dass dieses Tool auch von den Hardware-Entwicklern benötigt wird, um die Ausgabe der Treiber gegen zu checken ?

Aber trotzdem nochmal meine Frage:
Was bitte weist in den DX9-Specs noch auf die fp24 hin ?
Nichts ?

NEin, für PS3.0 sind 24 Bit Mindestvoraussetzung. Die Vertexshader arbeiten immer mit 32 Bit Genauigkeit selbst auf DX8-HW.
Original geschrieben von r@e
Warum soll es ein Entwickler nicht selbst in der Hand haben, in welchem Format gerechnet werden soll ? Und wo bitte kann ich Deine Behauptung nachprüfen, dass die R3x0-Hardware unter fp24 'oft' schneller ist, als die NV3x-Hardware unter fp16 ? Inbesonders auf die NV35+ möchte ich hier das Augenmerk legen...

Das Ergebnis für 2x2 ist sowohl unter INT12, wie auch fp16, fp24 und fp32 immer das gleiche...

Der Entwickler hat es ja in der Hand welche Genauigkeit er nutzen will. Man kann FP16 pro Anweisung ja explizit einschalten.

Und daß die R350-HW schneller ist als die NV3x-HW bezüglich Shader, zeigen viele theoretische Tests.
Original geschrieben von r@e
Nicht nur, um nVidia "eins reinzuwürgen", sondern auch, um der Hardware von ATI einen Vorteil zu verschaffen (funktioniert ja in beide Richtungen ;-).

Wenn dem so wäre - wirklich ein gelungener Deal:
ATI bekommt mehr Martanteile und M$ günstige XBOX2-Hardware. Dass nVidia zusätzlich einen Dämpfer bekommt, dürfte im GraKa-Markt sicher auch ein Zeichen gesetzt haben...

Spekulation ist schon was Feines, gell ?
:D

Razor
Möglich. Halte ich hier für nicht ausgeschlossen wenn man sich die Geschäftspraktiken von MS so anschaut.

r@e

2004-03-06, 09:49:02

Original geschrieben von Exxtreme
Nein, das hat beim R300 keinerlei Auswirkungen. Der R300 rechnet IMMER mit 24 Bit FP. DirectX verbietet es nicht mit höherer Präzision zu rechnen als erforderlich. Und auch wenn es ein wenig paradox klingt, die Wahrscheinlichkeit, daß DX8-Shader auf dem R300 langsamer laufen als vergleichbare DX9-Shader, ist höher als umgekehrt.Ja und ?
Wo habe ich etwas anderes behauptet ?
:???:
Original geschrieben von Exxtreme
Durch Branching kann man die Geschwindigkeit erhöhen da nicht benötigte Codeteile übersprungen werden können. Neue Effekte bringt das aber nicht. Beim PS2.0 kann man sich hier auch behelfen indem man je nach Situation verschiedene Shader auf die GraKa lädt. Hat fast den gleichen Effekt, ist aber langsamer.Wie gesagt, übertrage das bitte auf die klassische Programmierung und erzähle mir dann nochmal, dass so etwas sinnvoll ist. Vor allem, wenn man komplexe Architekturen (wie beim NV3x) zugrunde legt... der Grad an Flexibilität, den man durch Verweigungen und Instruction-Lenght erhält, ist einfach durch nichts zu ersetzen. Das, was derzeit im HLSL-Compiler passiert, um Programme im PS2-Rendertarget hinein zu 'quetschen' ist einfach haarsträubend und äusserst ineffizient.

Und ich könnte mir schon vorstellen, dass noch ganz andere Effekte möglich wären, würde die derzeitige Hardware nicht dermaßen 'beschränkt' sein... schließlich muss das Zeugs ja zumindest auf einer R3x0-Architektur 'vernünftig' laufen, oder ?
;-)
Original geschrieben von Exxtreme
Heutzutage werden die Shader eh' in HLSL geschrieben und dann entsprechenden Profilen compiliert. Von einer ganz anderen Programmiertechnik kann man hier kaum sprechen. Nun ja, dann stell Dir mal vor, dass die Shader einfach nur nochmal durch den Compiler gejagt werden müssen, um diese über ein PS3.0-Profil auf PS3.0-Hardware 'lauffähig' zu machen. Ein einfaches Update der Game-Engine und schon werden aus 20 (oder mehr) PS2-Shadern bei HL2 nur ein einziger PS3-Shader, der dann auch noch schneller abgearbeitet werden kann (kein Eingriff mehr durch die Engine und damit auch noch weniger CPU-Rechenzeit ;-)...
Original geschrieben von Exxtreme
Ja, wahrscheinlich arbeitet der F-Buffer jetzt korrekt. :D:lolaway:
Original geschrieben von Exxtreme
Wenn man sich ausschliesslich auf die Shader bezieht, dann gebe ich dir recht. Aber die Shader sind nur ein Aspekt von vielen, die eine gute GraKa ausmachen. Und da gebe ich Dir zu 100% recht !
Sind wir uns also zumindest in diesem Punkt einig, gell ?
:D

Razor

r@e

2004-03-06, 09:57:33

Das wird langsam anstrengend...
(muss auch gleich frühstücken)
;-)
Original geschrieben von Exxtreme
Naja, intern rechnet schon die Voodoo1 mit 32 Bit Farbtiefe. Bitte hier nicht Farbtiefe mit Shadergenauigkeit verwechseln. Ich rede hier aber nicht (nur) von Farbtiefe...
Original geschrieben von Exxtreme
NEin, für PS3.0 sind 24 Bit Mindestvoraussetzung. Die Vertexshader arbeiten immer mit 32 Bit Farbtiefe selbst auf DX8-HW.Siehe oben.
Original geschrieben von Exxtreme
Der Entwickler hat es ja in der Hand welche Genauigkeit er nutzen will. Man kann FP16 pro Anweisung ja explizit einschalten.Und warum muss die Präzision nicht grundsätzlich angefordert werden ?
(kein Default, oder meinetwegen Default = INT12)
Warum 'darf' nicht in INT12 gerechnet werden ?
:???:

Ich weiß auch, dass M$ das so festgelegt hat, aber...
Original geschrieben von Exxtreme
Und daß die R350-HW schneller ist als die NV3x-HW bezüglich Shader, zeigen viele theoretische Tests.Ich habe hier explizit fp16 nVidia (NV35+) und fp24 ATI angesprochen...
Von welchen Tests also redest Du ?
Original geschrieben von Exxtreme
Möglich. Halte ich hier für nicht ausgeschlossen wenn man sich die Geschäftspraktiken von MS so anschaut. Das passt auch ganz hervorragend zu den Geschäftspraktiken von ATI und nVidia !
Schließlich hätte (oder hat) es nVidia ja genauso gemacht, wären sie dazu in der Lage gewesen...
:D

Razor

Exxtreme

2004-03-06, 10:11:55

Original geschrieben von r@e
Ja und ?
Wo habe ich etwas anderes behauptet ?
:???:

Original geschrieben von r@e
Klar wäre der R300 benachteiligt, wenn er alles mit voller interner Präzision rechnen müsste, obwohl dies gar nicht erforderlich ist.

Das ist so nicht wahr. :)

Original geschrieben von r@e
Wie gesagt, übertrage das bitte auf die klassische Programmierung und erzähle mir dann nochmal, dass so etwas sinnvoll ist. Vor allem, wenn man komplexe Architekturen (wie beim NV3x) zugrunde legt... der Grad an Flexibilität, den man durch Verweigungen und Instruction-Lenght erhält, ist einfach durch nichts zu ersetzen. Das, was derzeit im HLSL-Compiler passiert, um Programme im PS2-Rendertarget hinein zu 'quetschen' ist einfach haarsträubend und äusserst ineffizient.

Von "klassischer" Programmierung kann man bei den GPUs gar nicht reden. Eigentlich sind deren Rechenwerke abstrakt gesehen äusserst primitiv. Sowas wie Branching konnten die CPUs schon anfangs der 80'er Jahre. Und jetzt wird das als Revolution gefeiert. :D

Und in einem PS2.0-Shader muss man gar nichts quetschen. Einfach ein PS3.0-Profil auswählen und nochmal kompilieren. Aufwand praktisch Null. Man muss halt beide Shader dann ausliefern. Die Anwendung kann dan entscheiden, was für Shader geladen werden.
Original geschrieben von r@e
Und ich könnte mir schon vorstellen, dass noch ganz andere Effekte möglich wären, würde die derzeitige Hardware nicht dermaßen 'beschränkt' sein... schließlich muss das Zeugs ja zumindest auf einer R3x0-Architektur 'vernünftig' laufen, oder ?
;-)

Mit PS3.0 kommen "kaum" neue Effekte hinzu. Gut, man könnte jetzt argumentieren, daß man bedingt durch den Speed-Up, die Quantität/Qualität der Effekte erhöhen könnte, ohne daß die Frameraten einbrechen. Nur hier würde ich jetzt die finale HW der beiden Kontrahenten abwarten.
Original geschrieben von r@e
Nun ja, dann stell Dir mal vor, dass die Shader einfach nur nochmal durch den Compiler gejagt werden müssen, um diese über ein PS3.0-Profil auf PS3.0-Hardware 'lauffähig' zu machen. Ein einfaches Update der Game-Engine und schon werden aus 20 (oder mehr) PS2-Shadern bei HL2 nur ein einziger PS3-Shader, der dann auch noch schneller abgearbeitet werden kann (kein Eingriff mehr durch die Engine und damit auch noch weniger CPU-Rechenzeit ;-)...

Siehste, das ist ein Speed-Up ... genauso wie PS1.4 ggü. PS1.3. :) Für die Entwickler ist das kein Aufwand. Einfach alles in HLSL schreiben und durch den Shadercompiler jagen mit verschiedenen PRofilen.

Exxtreme

2004-03-06, 10:24:33

Original geschrieben von r@e
Das wird langsam anstrengend...
(muss auch gleich frühstücken)
;-)
Ich rede hier aber nicht (nur) von Farbtiefe...
Siehe oben.
:???: Welche Genauigkeit meinst du dann? Der NV10 hatte keine Shader.
Original geschrieben von r@e
Und warum muss die Präzision nicht grundsätzlich angefordert werden ?
(kein Default, oder meinetwegen Default = INT12)
Warum 'darf' nicht in INT12 gerechnet werden ?
:???:

Ich weiß auch, dass M$ das so festgelegt hat, aber...

Die Gründe kennt nur MS. Wenn man FX9 oder FX12 braucht, dann kann man auch einen PS1.x-Shader schreiben. Wird ja auch oft so gemacht.
Original geschrieben von r@e
Ich habe hier explizit fp16 nVidia (NV35+) und fp24 ATI angesprochen...
Von welchen Tests also redest Du ?

Shadermark z.B. :D

r@e

2004-03-06, 10:29:23

Original geschrieben von Exxtreme
Das ist so nicht wahr. :)Dann einigen wir uns einfach darauf, dass dies Definitionssache ist, OK ?
;)
Original geschrieben von Exxtreme
Von "klassischer" Programmierung kann man bei den GPUs gar nicht reden. Eigentlich sind deren Rechenwerke abstrakt gesehen äusserst primitiv. Sowas wie Branching konnten die CPUs schon anfangs der 80'er Jahre. Und jetzt wird das als Revolution gefeiert. IMO etwas zu 'einfach' gesehen...
Das, was GPU's heute leisten können selbst große, spezialisierte Rechenzentren nicht mehr leisten. Aber wollen wir uns wirklich über den Begriff 'Spezialisierung' unterhalten ?
Original geschrieben von Exxtreme
Und in einem PS2.0-Shader muss man gar nichts quetschen. Einfach ein PS3.0-Profil auswählen und nochmal kompilieren. Aufwand praktisch Null. Man muss halt beide Shader dann ausliefern. Die Anwendung kann dan entscheiden, was für Shader geladen werden.Ein komplexer in HLSL geschriebener Shader wird entweder in 20 PS2-Shader 'zerlegt' und der Hardware (damit auch der Game-Engine) 'vorgeworfen' oder eben in nur einen PS3 Shader.

Läuft ein solch 'zerlegter' PS2-Shader auf keiner Hardware mehr performant, hat er sich ganz einfach 'erledigt'.

Wie gesagt, irgendwie habe ich das Gefühl, dass Du mich wohl nicht verstehen willst. Aber eines hast Du sehr schön heraus gestellt: Der Aufwand, um einen komplexen HLSL-Shader nochmals via PS3.0-Target zu kompilieren ist gleich null... insofern die 6 oder 7 mal höhere Performance eines NV40 kein 'Marketing-Trick' mehr sein müsste...
;-)
Original geschrieben von Exxtreme
Mit PS3.0 kommen "kaum" neue Effekte hinzu. Gut, man könnte jetzt argumentieren, daß man bedingt durch den Speed-Up, die Quantität/Qualität der Effekte erhöhen könnte, ohne daß die Frameraten einbrechen. Nur hier würde ich jetzt die finale HW der beiden Kontrahenten abwarten.Auf jeden Fall...
Womit wir dann beim eigentlichen Thema dieses Threads wären, gell ?
:D
Original geschrieben von Exxtreme
Siehste, das ist ein Speed-Up ... genauso wie PS1.4 ggü. PS1.3. :) Für die Entwickler ist das kein Aufwand. Einfach alles in HLSL schreiben und durch den Shadercompiler jagen mit verschiedenen PRofilen. Wenn Du so argumentierst, könnte man auch DX8-Hardware also 'Speed-up' zur DX7-Hardware sehen. Schließlich gibt es KEINEN Effekt, den ich nicht mit viel CPU-Aufwand und Multi-Texturing erreichen könnte...

Ein Stichwort wäre hier "Software-X-Ray-Renderer", die eine Qualität des Dargestellten zutage fördern, die auch ein R500 oder ein NV50 nicht zustande bringen und nur eine 2D-Grafikkarte benötigen, dafür aber eine umso 'potentere' CPU, oder ?

Aber das würde hier doch 'etwas' zu sehr abschweifen...
:D

Razor

P.S.: musste Dir leider einen Smilie 'klauen'... ;-)

r@e

2004-03-06, 10:35:21

Original geschrieben von Exxtreme
:???: Welche Genauigkeit meinst du dann? Der NV10 hatte keine Shader.Dann vergiß den NV10...
(hatte ich oben mit 'nem Fragezeichen versehen, wenn Du Dich recht erinnerst ;-)
Original geschrieben von Exxtreme
Die Gründe kennt nur MS. Wenn man FX9 oder FX12 braucht, dann kann man auch einen PS1.x-Shader schreiben. Wird ja auch oft so gemacht.Ausser in HL2...
;)

Und über die Gründe von M$ haben wir uns ja schon ausgelassen.
Du würdest mir also zustimmen, dass es keinen Sinn macht, INT12 nicht als Format zu zulassen oder aber fp16 nicht als Default-Format zu nutzen ?
Original geschrieben von Exxtreme
Shadermark z.B. :D :lolaway:

OK, das war das Wort zum Sonntag...
Insofern ich mich erst einmal verabschiede, um meinem Mäuserl und mir Brötchen zu holen !

Bis nachher

Razor

Exxtreme

2004-03-06, 10:42:53

Original geschrieben von r@e

IMO etwas zu 'einfach' gesehen...
Das, was GPU's heute leisten können selbst große, spezialisierte Rechenzentren nicht mehr leisten. Aber wollen wir uns wirklich über den Begriff 'Spezialisierung' unterhalten ?

Trotzdem sind die Möglichkeiten der GPUs sehr begrenzt. "Klassisch" kann man die Teile nicht programmieren. Klar, das was die Rechenwerke können, das können sie brutal schnell.
Original geschrieben von r@e
Ein komplexer in HLSL geschriebener Shader wird entweder in 20 PS2-Shader 'zerlegt' und der Hardware (damit auch der Game-Engine) 'vorgeworfen' oder eben in nur einen PS3 Shader.

Läuft ein solch 'zerlegter' PS2-Shader auf keiner Hardware mehr performant, hat er sich ganz einfach 'erledigt'.

Und genau deswegen schrieb ich, daß man finale Hardware abwarten soll. Und daß PS3.0 6x bis 7x Mal schneller ist sollte man auch nicht annehmen. Das ist von Shader zu Shader unterschiedlich. Und ich gehe davon aus, daß der R420 und der NV40 für "ausgewachsene" PS2.X-Shader nicht wirklich schnell genug sein werden.
Original geschrieben von r@e
Wie gesagt, irgendwie habe ich das Gefühl, dass Du mich wohl nicht verstehen willst. Aber eines hast Du sehr schön heraus gestellt: Der Aufwand, um einen komplexen HLSL-Shader nochmals via PS3.0-Target zu kompilieren ist gleich null... insofern die 6 oder 7 mal höhere Performance eines NV40 kein 'Marketing-Trick' mehr sein müsste...
;-)

Ich würde eher bis zu 7x schneller annehmen da sich immer was konstruieren lässt, womit sich dieser Geschwindigkeitsvorteil zeigen lässt. Es kann aber gut sein, daß der PS3.0-Shader keinerlei Geschwindigkeitsvorteile ggü. einem PS2.0-Shader hat.
Original geschrieben von r@e
Wenn Du so argumentierst, könnte man auch DX8-Hardware also 'Speed-up' zur DX7-Hardware sehen. Schließlich gibt es KEINEN Effekt, den ich nicht mit viel CPU-Aufwand und Multi-Texturing erreichen könnte...

So ist das. :) Gut, das Wasser ist mit DX8 zu einer Quecksilberlache mutiert (Nature-Demo, Morrowind) und wurde erst mit PS2.0 richtig schön.

Gast

2004-03-06, 10:58:42

Mal ne Frage, wechselt ATI jetzt zu FP 32?

LovesuckZ

2004-03-06, 11:00:31

Original geschrieben von Gast
Mal ne Frage, wechselt ATI jetzt zu FP 32?

Nein. Das waeren zu große Eingriffe in die vorhandene Shaderarchitektur.

robbitop

2004-03-06, 11:49:00

afaik wäre das möglich. Teile der R300 Architektur sind FP32. Jedoch musste man sich aufgrund des knappen Transistorbudget gegen FP32 entscheiden.

Die Umstellung sollte schon machbar sein.

Xmas

2004-03-06, 13:57:47

Xmas

2004-03-06, 14:16:06

Ailuros

2004-03-07, 12:28:51

Original geschrieben von robbitop
afaik wäre das möglich. Teile der R300 Architektur sind FP32. Jedoch musste man sich aufgrund des knappen Transistorbudget gegen FP32 entscheiden.

Die Umstellung sollte schon machbar sein.

Ausser ich schiesse mir gerade wieder in's Bein, gibt es bei ATI den Unterschied was Praezision betrifft, zwischen reads und writes. Erfordert eine Applikation FP32 (wenn ich es nicht falsch verstanden habe) dann werden zwar 128bits gelesen, aber es spuckt eben nur FP24 am anderen Ende raus.

Machbar ist es schon, aber eine geteilte Praezision werden sie wohl auch nicht entgehen koennen fuer PS.

Demirug

2004-03-07, 12:51:47

Original geschrieben von Ailuros
Ausser ich schiesse mir gerade wieder in's Bein, gibt es bei ATI den Unterschied was Praezision betrifft, zwischen reads und writes. Erfordert eine Applikation FP32 (wenn ich es nicht falsch verstanden habe) dann werden zwar 128bits gelesen, aber es spuckt eben nur FP24 am anderen Ende raus.

Machbar ist es schon, aber eine geteilte Praezision werden sie wohl auch nicht entgehen koennen fuer PS.

Ja, wenn ein FP32 Texturformat benutzt wird ergänzt der R300 das FP24 auf FP32 beim Schreiben und beim einlesen wird wieder auf FP24 gekürzt.

Die Interpolation der Texturkoordinaten erfolgt mit FP32. Auch die TMUs arbeiten zum Teil mit FP32. Sobald man aber eine Texturkoordinate einmal in ein Tempregister im Pixelshader umkopiert hat sind die 32 Bit weg und man hat nur noch 24.

Ailuros

2004-03-07, 13:03:23

Tja aber auf ausschliesslich FP32 aus Bandbreiten-Gruenden werden sie wohl auch nicht setzen koennen.

Ich meine dass jetzt so: bei PS/FP24 bis jetzt werden unter allen Umstaenden (egal was fuer eine Praezision die Applikation verlangt) FP24 ausgespuckt. Den Trend erwarte ich aber nicht, wenn dann auf FP32 gesteigert wird.

Demirug

2004-03-07, 13:18:30

Original geschrieben von Ailuros
Tja aber auf ausschliesslich FP32 aus Bandbreiten-Gruenden werden sie wohl auch nicht setzen koennen.

Ich meine dass jetzt so: bei PS/FP24 bis jetzt werden unter allen Umstaenden (egal was fuer eine Praezision die Applikation verlangt) FP24 ausgespuckt. Den Trend erwarte ich aber nicht, wenn dann auf FP32 gesteigert wird.

Du meinst jetzt auch für alle Texturen? Am Ende der Shader kommen FP24 heraus diese werden dann aber in das richtige Format (FX8, FP16, FP32, ...) gewandelt welches der Zielbuffer hat.

Ailuros

2004-03-08, 00:34:25

Nein ich meinte dass wenn ATI die Praezision fuer PS von FP24 auf FP32 erhoehen wird, dass ich es als unmoeglich ansehe, dass sie nicht noch ein niedrigeres Praezisions-format auch noch unterstuetzen werden (wie FP16 z.B.).

aths

2004-03-08, 02:58:25

Original geschrieben von r@e
P.S.: Das der RefRast keine fp24 beherrscht, dürfte hier wohl Bände sprechen... FP16 beherrscht er ebensowenig. Der Ref nutzt aus Performance-Gründen FP-Formate, die es in der CPU gibt.

Original geschrieben von r@e
Was der Grund dafür sein dürfte, warum nVidia schon seit jeher mit fp32 'rechnet'...
Auch fp24 sind doch wohl eigentlich zu 'unpräzise', oder ?
;-)Statt zu ";-)"-en würde ich empfehlen, eine Radeon 9600 zu kaufen und auszuprobieren, wie "unpräzise" FP24 in der Praxis ist. Weder scheint mir, dass die die Theorie klar ist, noch, dass du hier Praxiserfahrung hast.

Original geschrieben von r@e
- wo finden sich in DX9 sonst noch Hinweise auf diese uminösen fp24 ?Weist diese Frage darauf hin, dass du die DX9SDK-Doku nicht kennst? Da steht eigentlich alles, was es zu sagen gibt.

aths

2004-03-08, 02:59:50

Original geschrieben von Exxtreme
FP16 wäre tatsächlich gar nicht so schlecht gewesen als "unteres" Limit ... zumindest bei der Farbtiefe. Bei Textur-Adressierung kommst du mit 16 Bit FP nicht sehr weit.Richtig. Für Farben ist FP16 *oft* ausreichend, für Texturen letztlich unbrauchbar. (Ausnahme: Sehr kleine Texturen.)

Original geschrieben von Exxtreme
Und ob tatsächlich VS3.0 unterstützt wird, habe ich noch nirgends nachlesen können ... Wird es. Ganz sicher.

aths

2004-03-08, 03:06:27

Original geschrieben von r@e
Du willst mich nicht verstehen, oder ?
Klar wäre der R300 benachteiligt, wenn er alles mit voller interner Präzision rechnen müsste, obwohl dies gar nicht erforderlich ist.Der R300 ist dermaßen schnell, dass man nicht wirklich von einem "Nachteil" sprechen könnte.

Original geschrieben von r@e
Instruction-Count wurde beim R420 nur auf 512 erhöht ?
Sieht einfach nur nach ein bissel mehr Speicher für die Programme aus, meinst Du nicht ?Und mehr Bits für den Instruction Counter. Mehr als 512 Instruktionen lässt DX9 im PS 2.X-Bereich nicht zu, deshalb verstehe ich dein "nur" nicht.

aths

2004-03-08, 03:14:04

Original geschrieben von Stefan Payne
Für mich hörte es sich so an, als ob M$ nV 'einen verpasst' hat, denn nV wollte auch mit Festpunkt arbeiten, eigentlich, nur das ging 'irgendwie' in die Hose... Imo richtig so. FP16 ist schon besser als FX12, und so viele Formate … Für Sinus z. B. sind Mindestgenauigkeiten angegeben, die wären von FX12 bei kleinen Zahlen wohl nur schwer einzuhalten gewesen.

aths

2004-03-08, 03:17:21

aths

2004-03-08, 03:19:10

Original geschrieben von Exxtreme
NEin, für PS3.0 sind 24 Bit Mindestvoraussetzung. So steht es auch in meinem SDK. Wichtige Leute behaupten, die Spec wurde jetzt auf FP32 angehoben.
Original geschrieben von Exxtreme
Die Vertexshader arbeiten immer mit 32 Bit Genauigkeit selbst auf DX8-HW. Genau wie bei T&L auf DX7-HW.

Original geschrieben von Exxtreme
Und daß die R350-HW schneller ist als die NV3x-HW bezüglich Shader, zeigen viele theoretische Tests.Und die Praxis-Erfahrungen belegen das auch.

Original geschrieben von Exxtreme
Wenn man FX9 oder FX12 braucht, dann kann man auch einen PS1.x-Shader schreiben. Wird ja auch oft so gemacht.BINGO =)

aths

2004-03-08, 03:21:09

Original geschrieben von r@e
Und ich könnte mir schon vorstellen, dass noch ganz andere Effekte möglich wären, würde die derzeitige Hardware nicht dermaßen 'beschränkt' sein... schließlich muss das Zeugs ja zumindest auf einer R3x0-Architektur 'vernünftig' laufen, oder ?
;-)Schlimmer ist es, dass es auch auf NV3x noch 'vernünfig' laufen muss ;-)

r@e

2004-03-08, 05:40:32

Original geschrieben von aths
FP16 beherrscht er ebensowenig. Der Ref nutzt aus Performance-Gründen FP-Formate, die es in der CPU gibt.Das ist doch mal Hinweis, mit dem ich was anfangen kann...
Original geschrieben von aths
Statt zu ";-)"-en würde ich empfehlen, eine Radeon 9600 zu kaufen und auszuprobieren, wie "unpräzise" FP24 in der Praxis ist. Weder scheint mir, dass die die Theorie klar ist, noch, dass du hier Praxiserfahrung hast.Habe mir seinerzeit eine R9500np zugeleget...
Original geschrieben von aths
Weist diese Frage darauf hin, dass du die DX9SDK-Doku nicht kennst? Da steht eigentlich alles, was es zu sagen gibt. Du weißt es also auch nicht ?
:???:

Razor

r@e

2004-03-08, 05:44:16

Original geschrieben von aths
Der R300 ist dermaßen schnell, dass man nicht wirklich von einem "Nachteil" sprechen könnte.Und woher nimmst Du die Gewißheit, dass er mit fp16 (oder gar fx12) nicht schenller sein könnte ?
...voraus gesetzt, dies wäre architektonisch berücksichtigt worden...
Original geschrieben von aths
Und mehr Bits für den Instruction Counter. Mehr als 512 Instruktionen lässt DX9 im PS 2.X-Bereich nicht zu, deshalb verstehe ich dein "nur" nicht. Also wirklich nur ein weiterer "R3x0"...
...mit funktionierendem F-Buffer, wie Exxtreme mutmaßte...
:D

Razor

r@e

2004-03-08, 05:51:02

Original geschrieben von aths
Schlimmer ist es, dass es auch auf NV3x noch 'vernünfig' laufen muss ;-) Ahhh...
Wieder so ein "falsch verstehen ist shick" Ding !
;-)

Wenn es gar keine GPU mehr gibt, die einen PS2.<irgendwas> Effekt darstellen kann (performance-seitig), dann macht dieser Effekt schlicht keinen Sinn !

Jetzt kapiert ?

Aber vielleicht reißts dann ja der R420 heraus, wenn er als einzige PS2-GPU einen PS2-Effekt darstellen kann (HL2-'Exxtreme' ;-), der auf andren (ex-High-End) GPU's, die rein technisch dazu in der Lage wären, trotzdem nicht mehr (performant) läuft.

Razor

aths

2004-03-08, 06:24:40

Original geschrieben von r@e
Habe mir seinerzeit eine R9500np zugeleget...Sind die Texturen dort denn "unpräzise"? Meine Tests mit der 9600 zeigen, dass die Karte für Spiele sehr gut ist.
Original geschrieben von r@e
Du weißt es also auch nicht ?
:???::???: Ich weiß, dass für 2.x (also 2.0- und 2.X) Pixelshader die Full Presision-Genauigkeit FP24 mit s16e7 ist. Imo eine sinnvolle Entscheidung.

Original geschrieben von r@e
Und woher nimmst Du die Gewißheit, dass er mit fp16 (oder gar fx12) nicht schenller sein könnte ?Der R300 hat keine echten Fixpoint-Einheiten mehr (höchstens für Modifier für DX8, aber mit Modifiern alleine kannste kaum rechnen), wäre demzufolge mit FX12 nicht schneller. Das gleiche gilt für FP16. FP16-Units (statt FP24-Units) wären zwar kleiner, aber nicht schneller.

FP32-Einheiten sind bekanntlich auch nicht langsamer als FP24-Einheiten, lediglich benötigen sie rund 50% mehr Transistoren.
Original geschrieben von r@e
Also wirklich nur ein weiterer "R3x0"...
...mit funktionierendem F-Buffer, wie Exxtreme mutmaßte...
:DATI hat das wohl nicht über einen F-Buffer realisiert, sondern die Hardware "wirklich" aufgebohrt.

aths

2004-03-08, 06:33:57

Original geschrieben von r@e
Ahhh...
Wieder so ein "falsch verstehen ist shick" Ding !
;-)

Wenn es gar keine GPU mehr gibt, die einen PS2.<irgendwas> Effekt darstellen kann (performance-seitig), dann macht dieser Effekt schlicht keinen Sinn !
Jetzt kapiert ?Was gibts da zu "kapieren", wenn solche Banalitäten an den Tag gelegt werden?

Original geschrieben von r@e
Aber vielleicht reißts dann ja der R420 heraus, wenn er als einzige PS2-GPU einen PS2-Effekt darstellen kann (HL2-'Exxtreme' ;-), der auf andren (ex-High-End) GPU's, die rein technisch dazu in der Lage wären, trotzdem nicht mehr (performant) läuft.Ich würde mich freuen, wenn nicht immer alles durcheinandergewürfelt würde. Man kann mit hoher Wahrscheinlichkeit davon ausgehen, dass der neue Chip von ATI Takt für Takt die doppelte Arbeit leisten könnte, verglichen mit R300 (bzw. R360.)

Rein technisch wäre eine FX 5200 mit 64-Bit-Bus in der Lage, deutlich aufwändigere Shader zu rendern, als ATIs in kürze kommender Chip.

Mit hoher Wahrscheinlichkeit ist die pure Rechenpower im NV40 gegenüber dem NV35 verdoppelt worden. Die große Frage ist "nur", wie effizient ATI bzw. NV das in Frames umsetzen können. So könnte einige relativ kleine Änderung am NV35 dessen Shader-Leistung "bis zu" 100% erhöhen. Wäre beim NV40 dann schon bis zu 4x Rechenleistung gegenüber NV35.

Das heißt, am Ende dürfte es auf ungefähren Gleichstand hinauslaufen. Um 10 oder 20% will ich da nicht streiten. NV30 war dem R300 in Dingen DX9-Shaderpower um Faktor 2-4 unterlegen, solche krassen Unterschiede sind bei der kommenden Generation nicht zu erwarten. (Bei krasser Zählweise ist der NV30 theoretisch sogar um bis zu Faktor 6 unterlegen.)

Die Neuerungen durch Pixelshader 3.0 sollte man nicht unter-, aber auch nicht überbewerten. (Deiner Argumentation á la Pixelshader 1.4 wäre 3.0 ja ein reiner NV-Standard, den ATI halt irgendwann mit den 4.0-Shadern mit unterstützt.) (Diese Argumentation wäre hier gar nicht mal so falsch übrigens, hätte sich ATI frühzeitig in Richtung 3.0 orientiert, würde es wohl kaum eine so stringente Spec geben.)

Es ist nicht davon auszugehen, dass die 3.0-Power überragend ist. Das war bei NV jetzt immer so: Egal, ob 32-Bit-Rendering, T&L, oder auch DX8-Pixelshading, oder zuletzt DX9-Pixelshading: Erst kommen die Features, dann gibts ein Speedupgrade im Refresh, aber die richtige Power gibts erst mit der nächsten Generation.

LovesuckZ

2004-03-08, 10:55:09

Original geschrieben von aths
Es ist nicht davon auszugehen, dass die 3.0-Power überragend ist. Das war bei NV jetzt immer so: Egal, ob 32-Bit-Rendering, T&L, oder auch DX8-Pixelshading, oder zuletzt DX9-Pixelshading: Erst kommen die Features, dann gibts ein Speedupgrade im Refresh, aber die richtige Power gibts erst mit der nächsten Generation.

Da die "3.0-Power" imo in Abhaengigkeit zur 2.0-Power stehe, sollte man mit solchen Aussagen vorsichtig sein.

StefanV

2004-03-08, 11:00:10

Original geschrieben von aths
Imo richtig so. FP16 ist schon besser als FX12, und so viele Formate … Für Sinus z. B. sind Mindestgenauigkeiten angegeben, die wären von FX12 bei kleinen Zahlen wohl nur schwer einzuhalten gewesen.

Ich neige dazu dir zuzustimmen, bei FX12 wäre der 'Fortschritt' IMO zu klein...

Von daher kann ich die M$ Entscheidung gut nachvollziehen, die nV Entscheidung hingegen weniger...

StefanV

2004-03-08, 11:01:05

Original geschrieben von LovesuckZ
Da die "3.0-Power" imo in Abhaengigkeit zur 2.0-Power stehe, sollte man mit solchen Aussagen vorsichtig sein.

Nein, warum??

Demi sagte irgendwann mal, daß man entweder tolle PS2 HW bauen kann oder aber tolle PS3 HW; beides gleichzeitig ist laut ihm nur schwer möglich.

LovesuckZ

2004-03-08, 11:04:29

Original geschrieben von Stefan Payne
Nein, warum??

Weil FX12 keine bedeutung mehr habe? Wozu also Altlasten mitherumschleppen? Und da FP16/32 sowieso weiter verwendet werden koennen, sollte sich der PS3.0 Speed nicht so deutlich unterscheiden wie es die leistung der PS2.0 beim NV30 tun.

Demi sagte irgendwann mal, daß man entweder tolle PS2 HW bauen kann oder aber tolle PS3 HW; beides gleichzeitig ist laut ihm nur schwer möglich.

Hm, wenn ich tolle PS3.0 HW haette, sollte die PS2.0 Leistung nicht im Keller sein...

Exxtreme

2004-03-08, 11:11:32

Original geschrieben von r@e
Und woher nimmst Du die Gewißheit, dass er mit fp16 (oder gar fx12) nicht schenller sein könnte ?
...voraus gesetzt, dies wäre architektonisch berücksichtigt worden...

Razor
Der R300 wird von einer Reduzierung der Genauigkeit kaum profitieren. Dieser hat nämlich keine dedizierten FX-Einheiten. Alles wird durch FP-Einheiten durchgeführt. Und da ist es egal ob es eine "echte" FX-Genauigkeit ist oder alles mit FP-Genauigkeit gerechnet wird. Und da weder DirectX noch OpenGL es verbieten mit höherer Genauigkeit zu rechnen, hat es ATi einfach unterlassen, das in die Treiber einzubauen. Und beim Thema 16 FP ... stell dir vor, du schickst auf einer 3-spurigen Autobahn 2 Autos durch.

Ailuros

2004-03-08, 11:45:21

Und da weder DirectX noch OpenGL es verbieten mit höherer Genauigkeit zu rechnen, hat es ATi einfach unterlassen, das in die Treiber einzubauen.

Das waere wohl die doofste Aufforderung von jeglichem API ueberhaupt. Wenn minimale Voraussetzungen gedeckt werden, kann es logischerweise keinen Einwand geben.

Meine Frage steht aber immer noch: wenn auch immer ATI die PS-Prazision auf FP32 maximal erhoeht, wird es ein ausschliessliches Praezisions-format sein, oder wird es doch noch ein niedrigeres Praezisions-format geben?

Mit ausschliesslich FP32, scheint es mir zumindest, dann irgendwo mit der framebuffer Bandbreite zu hapern. Noch "merkwuerdiger" erscheint mir das Ganze wenn ich einen Schritt weiter dann an "unified grids" fuer DX-Next denke. Kann mir jemand in Kuerze das Ganze aufklaeren?

Exxtreme

2004-03-08, 11:52:21

Original geschrieben von Ailuros
Das waere wohl die doofste Aufforderung von jeglichem API ueberhaupt. Wenn minimale Voraussetzungen gedeckt werden, kann es logischerweise keinen Einwand geben.

Naja, einige Programmierer neigen manchmal dazu irgendwelche komischen Lösungen zu programmieren, die auf Nachfolge-HW nicht mehr richtig laufen oder nur noch per Emulation. A20-Gate ahoi. ;)

Ailuros

2004-03-08, 12:01:24

Original geschrieben von Exxtreme
Naja, einige Programmierer neigen manchmal dazu irgendwelche komischen Lösungen zu programmieren, die auf Nachfolge-HW nicht mehr richtig laufen oder nur noch per Emulation. A20-Gate ahoi. ;)

Schon aber verbieten kann man dass eigentlich durch's API dann wohl auch nicht gerade (ist sowas ueberhaupt schon mal passiert?).

Im Fall von interner Praezision klingt mir das eher merkwuerdig, fast sogar so aehnlich wie bei alten 16bpp-only Spielen. Wenn da ein Accelerator intern mit 32bpp rechnet und dann zu 16bpp dithert, kann man doch nicht via API verlangen, dass die HW intern nur mit 16bpp rechnet. Wie es die HW+Treiber anstellen, sollte dem API eigentlich egal sein, solange keine Grundregelen verletzt werden.

Exxtreme

2004-03-08, 14:48:35

Original geschrieben von Ailuros
Schon aber verbieten kann man dass eigentlich durch's API dann wohl auch nicht gerade (ist sowas ueberhaupt schon mal passiert?).

Im Fall von interner Praezision klingt mir das eher merkwuerdig, fast sogar so aehnlich wie bei alten 16bpp-only Spielen. Wenn da ein Accelerator intern mit 32bpp rechnet und dann zu 16bpp dithert, kann man doch nicht via API verlangen, dass die HW intern nur mit 16bpp rechnet. Wie es die HW+Treiber anstellen, sollte dem API eigentlich egal sein, solange keine Grundregelen verletzt werden.
Sehe ich auch so. Eine künstliche Begrenzung wäre Schwachsinn. Und deswegen hat ATi den Aufwand gescheut, da noch extra auf FX12 oder FP16 zu machen eben weil 24 Bit FP immer erlaubt sind.

aths

2004-03-09, 06:13:08

Original geschrieben von LovesuckZ
Da die "3.0-Power" imo in Abhaengigkeit zur 2.0-Power stehe, sollte man mit solchen Aussagen vorsichtig sein. Die Frage ist, was passiert, wenn man Sprünge nutzt, und für nebeneinander stehende Pixel letztlich unterschiedliche Instruktionen kommen.

Original geschrieben von Exxtreme
Sehe ich auch so. Eine künstliche Begrenzung wäre Schwachsinn. Und deswegen hat ATi den Aufwand gescheut, da noch extra auf FX12 oder FP16 zu machen eben weil 24 Bit FP immer erlaubt sind. Was ja auch keine dumme Idee ist, immer mit FP24-Genauigkeit zu rechnen, ob man die nun braucht, oder nicht. Sofern die HW mit FP-Rechnungen schnell genug ist, natürlich (was man vom NV30 nicht sagen kann.) ATI hat's aber gepackt.

r@e

2004-03-11, 20:28:56

Original geschrieben von Exxtreme
Und beim Thema 16 FP ... stell dir vor, du schickst auf einer 3-spurigen Autobahn 2 Autos durch. Jo, satte 33% an Performance 'verpufft'...

Und stell Du Dir bitte vor, Du schickst 4 Auto's durch eine 4-spurige Autobahn... im Gegensatz zu 4 Auto's durch 'ne 3-spurige.
Got it ?
:D

Dass dies (derzeit) nur in der Theorie der Fall ist, brauchst Du mir hingegen nicht auf die Nase zu binden.

Razor

Gast

2004-03-13, 11:22:29

Original geschrieben von Stefan Payne
Nein, warum??

Demi sagte irgendwann mal, daß man entweder tolle PS2 HW bauen kann oder aber tolle PS3 HW; beides gleichzeitig ist laut ihm nur schwer möglich.

Diesbezüglich hatte ich gestern ein interessantes Gespräch und im Grunde hat Stefan bzw. Demirug recht!

Entweder PS3.0 Performance oder PS2.0 Performance, der Zwischenschritt wird nicht realisierbar sein!

LovesuckZ

2004-03-13, 11:27:54

Original geschrieben von Gast
Entweder PS3.0 Performance oder PS2.0 Performance, der Zwischenschritt wird nicht realisierbar sein!

Erklaere das doch mal bitte.

Demirug

2004-03-13, 11:38:22

Original geschrieben von Stefan Payne
Nein, warum??

Demi sagte irgendwann mal, daß man entweder tolle PS2 HW bauen kann oder aber tolle PS3 HW; beides gleichzeitig ist laut ihm nur schwer möglich.

Das sehe ich ja jetzt erst. Wann und wo soll ich das gesagt haben?

Meine Aussage zu dem Thema war. Das eine Hardware die schlecht mit 2.0 Shadern umgehen kann diesen Nachteil auch bei 3.0 Shadern haben wird.

Man kann 3.0 Shader nutzen um weniger (bzw selektiver) 2.0 Anweisungen auszuführen. Es ist dann zwar möglich das die eingesparten Anweisungen reichen um eine gute 2.0 Hardware zu schlagen nur muss es dafür auch Einsparmöglichkeiten geben. Darum ist die Grundlage für eine gute 3.0 Hardware immer eine Hardware die 2.0 Operationen schnell ausführen kann.