NV30 wird ein HSR Chip!?

[Unregistered]

hi leutz!
hab ein paar (jdf. für mich) interessante details aus nem nvmax artikel ausgegraben.

>NV30 is different from its predecessors because it focuses more on the GPU rather than the memory. The shift means that the performance bottleneck shifts from memory efficiency to computing efficiency. In addition to this the NV30 includes better algorithms for detecting when hidden pixels that applications are not rendered through the system. This is known as an extension to Hidden Surface Removal and will be a part of a new system NVIDIA said we couldn't talk about, at this time.


hmm, wird eswegen dem nv30 eine höhere performance als dem r300 bescheinigt? bzw. weiss einer inwieweit der nv25 bzw. r300 hsr renderer sind?

2.

>John Carmack, ID Software, notes in a release NVIDIA gave at SISGraph that the convergence of customer realtime and professional offline rendering is such a step forward that all his previous work, including that on Doom shall be outdated - simply because upto NV30 there were just extensions / additional features to the original chipsets. He states that his next generation of work will be designed around what is possible on the NV30.

wird also erst das game nach doom3(quake4?) direkt die features des nv30 ausnutzen oder wie hab ich das zu verstehen, denn der nv25 ultra soll ja beim erscheinen von doom3 gerade mal so damit zurechtkommen ????

[zeckensack]

Was hat das mit der Überschrift zu tun?

hmm, wird eswegen dem nv30 eine höhere performance als dem r300 bescheinigt?IMO kann der NV30 garnicht schneller sein als der R300, es sei denn er hat eine höhere Speicherbandbreite. "Computational efficency" lege ich so aus, daß komplexe Shader schnell ausgeführt werden. Was anders nicht zu erwarten ist, da die erlaubte Programmlänge im Vergleich enorm ist. Dh man kann auf Multipass weitgehend verzichten. Das äußert sich aber dann erst bei Hardcore-Shadern (die in DX9.0 nicht erlaubt sind, frühestens ab DX9.1). Wie schnell sowas außerhalb von 3DMurks und Co praxisrelevant wird, das haben wir in der Vergangenheit bereits gesehen. Nämlich erst dann, wenn die entsprechenden Chips eigentlich schon wieder veraltet sind.

bzw. weiss einer inwieweit der nv25 bzw. r300 hsr renderer sind?Überhaupt nicht. Es sein denn, man betrachtet Z-Buffering als HSR, dann sind aber auch die Voodoo 1 und Matrox Mystique HSR-Renderer.

wird also erst das game nach doom3(quake4?) direkt die features des nv30 ausnutzen oder wie hab ich das zu verstehen, denn der nv25 ultra soll ja beim erscheinen von doom3 gerade mal so damit zurechtkommen ?Die Komplexität der Doom3-Shader steht fest und wird sich nicht mehr ändern. R200 kann's in einem Pass, Geforce4 nicht, aber NV30 wird es wohl auch in einem Pass können.
Dann noch die Stencil-Schatten, die auf der R200 nicht schnell genug sind, aber bereits auf der Geforce4 gut laufen.

->IMO ist alles ab R300 und NV30 für Doom3 optimal, weil alle Shader in einem Pass gemacht werden können und die Stencil-Ops auch gut flutschen. Restliche Features liegen brach, dann geht's erstmal wieder rein um die Geschwindigkeit (bis zur nächsten Engine).

[Demirug]

Originally posted by zeckensack

IMO kann der NV30 garnicht schneller sein als der R300, es sei denn er hat eine höhere Speicherbandbreite.


Da sind wir ja bekanntermassen unterschiedlicher Meinung.


"Computational efficency" lege ich so aus, daß komplexe Shader schnell ausgeführt werden. Was anders nicht zu erwarten ist, da die erlaubte Programmlänge im Vergleich enorm ist. Dh man kann auf Multipass weitgehend verzichten. Das äußert sich aber dann erst bei Hardcore-Shadern (die in DX9.0 nicht erlaubt sind, frühestens ab DX9.1).


Ob die Shader schneller arbeiten hängt von zwei Faktoren ab. Anzahl der Pipelines und ALUs pro Pipeline. IMO ist es einfacher die Anzahl der Pipelines zu erhöhen.

DX9 und maximale Programmlänge. Sicher???


Wie schnell sowas außerhalb von 3DMurks und Co praxisrelevant wird, das haben wir in der Vergangenheit bereits gesehen. Nämlich erst dann, wenn die entsprechenden Chips eigentlich schon wieder veraltet sind.


Ich denke auch das man beim 3dmurks keine NV30 Only Tests einbauen wird.


Überhaupt nicht. Es sein denn, man betrachtet Z-Buffering als HSR, dann sind aber auch die Voodoo 1 und Matrox Mystique HSR-Renderer.


Ich denke NV will da auf Occulusion Culling und Early Z raus.


Die Komplexität der Doom3-Shader steht fest und wird sich nicht mehr ändern. R200 kann's in einem Pass, Geforce4 nicht, aber NV30 wird es wohl auch in einem Pass können.
Dann noch die Stencil-Schatten, die auf der R200 nicht schnell genug sind, aber bereits auf der Geforce4 gut laufen.


Full Ack.

Ja das neue Feature für Stencilops dürfte die Schatten wesentlich beschleuningen.


->IMO ist alles ab R300 und NV30 für Doom3 optimal, weil alle Shader in einem Pass gemacht werden können und die Stencil-Ops auch gut flutschen. Restliche Features liegen brach, dann geht's erstmal wieder rein um die Geschwindigkeit (bis zur nächsten Engine).

Sehe ich auch so. Die neuen Features werden erst mal im Profi-Bereich interesant sein.

[zeckensack]

Originally posted by Demirug
Da sind wir ja bekanntermassen unterschiedlicher Meinung.Touche :D
Ich sehe das ganze so:
Beide Chips haben Early Z (ATI hat zusätzlich noch hierarchical Z, NV30 unbekannt ("occlusion culling" ist evtl nur ein anderer Begriff dafür)
"Tiling is bad", "Kyro is crap" <- NV wird uns wohl kaum mit einem Deferred Renderer überraschen.
Von daher ist's wieder ausgeglichen und hängt nur noch von Füllrate und Bandbreite ab.

Bandbreite:
Z-Compression hat ATI, Color Compression möglicherweise auch (hattest du das nicht mal geschrieben ???)
NVIDIA wird hier gleichziehen müssen.
Füllratentechnisch reizt der R300 sein Speicherinterface AFAIK voll aus. Sollte NV30 16 Pipelines haben, wird sich das in der Rohpower überhaupt nicht äussern können, weil einfach nicht genug Bandbreite vorhanden wäre.
Ich sehe da einfach keinen Punkt, den NVIDIA deutlich besser machen kann.

Wenn der NV30 tatsächlich nur 128bittiges RAM hat, dann wird das nichts. Bei 256bit sehe ich ungefähr Gleichstand, soweit die Takte und Bandbreiten vergleichbar ausfallen.
DX9 und maximale Programmlänge. Sicher???Nicht wirklich, alles nur vom Hörensagen. Ich war nur der Ansicht, daß der R300 PS2.0 und VS2.0 vollständig erfüllt ???

Ich denke NV will da auf Occulusion Culling und Early Z raus.Jau. Nur auch hier sehe ich wieder Gleichstand.
Early Z/hierarchical Z beim R300
Early Z/occlusion culling(???) beim NV30

Full Ack.

Ja das neue Feature für Stencilops dürfte die Schatten wesentlich beschleuningen.Meinst du damit two-sided-stencil oä?
Das wäre natürlich sehr interessant.

[Demirug]

Originally posted by zeckensack
Touche :D
Ich sehe das ganze so:
Beide Chips haben Early Z (ATI hat zusätzlich noch hierarchical Z, NV30 unbekannt ("occlusion culling" ist evtl nur ein anderer Begriff dafür)
"Tiling is bad", "Kyro is crap" <- NV wird uns wohl kaum mit einem Deferred Renderer überraschen.
Von daher ist's wieder ausgeglichen und hängt nur noch von Füllrate und Bandbreite ab.

Bandbreite:
Z-Compression hat ATI, Color Compression möglicherweise auch (hattest du das nicht mal geschrieben ???)
NVIDIA wird hier gleichziehen müssen.
Füllratentechnisch reizt der R300 sein Speicherinterface AFAIK voll aus. Sollte NV30 16 Pipelines haben, wird sich das in der Rohpower überhaupt nicht äussern können, weil einfach nicht genug Bandbreite vorhanden wäre.
Ich sehe da einfach keinen Punkt, den NVIDIA deutlich besser machen kann.

Wenn der NV30 tatsächlich nur 128bittiges RAM hat, dann wird das nichts. Bei 256bit sehe ich ungefähr Gleichstand, soweit die Takte und Bandbreiten vergleichbar ausfallen.


Fragment AA oder A-Buffer ??? Wäre aufgrund eines Vortrags von David Kirk der nächste logische Schritt für NV.

(SS AA-> MS AA -> A-Buffer/Fragment AA)

Und damit spart man ganz erheblich Bandbreite. Und ja ich meine FAA mit z und Stencil.


Nicht wirklich, alles nur vom Hörensagen. Ich war nur der Ansicht, daß der R300 PS2.0 und VS2.0 vollständig erfüllt ???


Keine Panic tut er ja auch. Allerdings ist die maximale Programmlänge keine fest vorgegebene Konstante. Es gibt da wohl noch eine obergrenze aber die ist ja schnell geändert :D


Jau. Nur auch hier sehe ich wieder Gleichstand.
Early Z/hierarchical Z beim R300
Early Z/occlusion culling beim NV30


occlusion culling gibts doch schon seit GF3. Leider nur im XDK und mit OpenGL (NV_occlusion_query). Bei DX9 gibts das jetzt auch.


Meinst du damit two-sided-stencil oä?
Das wäre natürlich sehr interessant.

Ich weis jetzt nicht was du mit two-sided-stencil meinst. Das neue Stencilfeature funktioniert wie folgt.

Man kann jetzt beim Render 2 verschiedene Stencilfunktionen wählen. Eine falls die vorderseite des Dreiecks sichtbar ist und eine für die Rückseite. Damit lassen sich die Schattenvolumen in einem Durchlauf rendern. R300 wird AFAIK das unterstützen (DX9 und OpenGL).

[zeckensack]

Originally posted by Demirug
Fragment AA oder A-Buffer ??? Wäre aufgrund eines Vortrags von David Kirk der nächste logische Schritt für NV.

(SS AA-> MS AA -> A-Buffer/Fragment AA)

Und damit spart man ganz erheblich Bandbreite. Und ja ich meine FAA mit z und Stencil.Aha, das kannte ich nicht.
Effizientes AA ist natürlich immer was feines, aber erstmal will ich sehen, daß der NV30 den R300 ohne FSAA schlagen kann, dafür reicht's halt IMO nicht (bzw hängt am 256 Bit Speicherinterface). Selbst die beste AA-Technik kann die Performance doch nicht steigern, höchsten möglichst wenig (ideal wäre 0) verringern.
Keine Panic tut er ja auch. Allerdings ist die maximale Programmlänge keine fest vorgegebene Konstante. Es gibt da wohl noch eine obergrenze aber die ist ja schnell geändert :DDirty tricks and politics :P
;)occlusion culling gibts doch schon seit GF3. Leider nur im XDK und mit OpenGL (NV_occlusion_query). Bei DX9 gibts das jetzt auch.Jetzt weiß ich auch, was du meintest. In der HP_blabla Version kann das auch schon der R200 (auch asynchron, allerdings nur eine einzige Anfrage 'in flight' im Gegensatz zu vielen Anfragen in der bisherigen NV-Version).
Ob der gewagten Spekulation "NV30 wird schneller als R300" erlaube ich mir die (IMO wesentlich weniger gewagte), daß der R300 das auch bieten kann.
Ich weis jetzt nicht was du mit two-sided-stencil meinst. Das neue Stencilfeature funktioniert wie folgt.

Man kann jetzt beim Render 2 verschiedene Stencilfunktionen wählen. Eine falls die vorderseite des Dreiecks sichtbar ist und eine für die Rückseite. Damit lassen sich die Schattenvolumen in einem Durchlauf rendern. R300 wird AFAIK das unterstützen (DX9 und OpenGL). Genau das meinte ich damit.

[Demirug]

Originally posted by zeckensack
Aha, das kannte ich nicht.
Effizientes AA ist natürlich immer was feines, aber erstmal will ich sehen, daß der NV30 den R300 ohne FSAA schlagen kann, dafür reicht's halt IMO nicht (bzw hängt am 256 Bit Speicherinterface). Selbst die beste AA-Technik kann die Performance doch nicht steigern, höchsten möglichst wenig (ideal wäre 0) verringern.


Für die reinen Rohpower (Ohne Texturfilter) reicht ein 128 bit interface erst mal aus. Aber wir wollen ja Texturfilter:D. Die frage ist halt ob dort NV auch irgendwas geniales eingefallen ist. Falls ja ist in Verbindung mit FAA IMO ein 128 Bit Interface ausreichend. Aber ich denke das wir dort einfach auf mehr Infos von NV warten müssen.


;)Jetzt weiß ich auch, was du meintest. In der HP_blabla Version kann das auch schon der R200 (auch asynchron, allerdings nur eine einzige Anfrage 'in flight' im Gegensatz zu vielen Anfragen in der bisherigen NV-Version).
Ob der gewagten Spekulation "NV30 wird schneller als R300" erlaube ich mir die (IMO wesentlich weniger gewagte), daß der R300 das auch bieten kann.


Ein Query ist nur zuwenig um damit was sinnvolles zu machen. Ich hoffe mal schwer das der R300 das kann. Ich kann dieses Feature wahrscheinlich gut brauchen.

[aths]

Originally posted by Demirug
Aber wir wollen ja Texturfilter:D. Die frage ist halt ob dort NV auch irgendwas geniales eingefallen ist.Was sollte das, bis auf extrem große Texture Caches, denn sein? Da sehe ich als Ausweg nur erzwungene Textur-Kompression, was sich aber wegen dem Qualitätsverlust nicht beliebig weit treiben lässt.

[Unregistered]

Originally posted by Demirug
Für die reinen Rohpower (Ohne Texturfilter) reicht ein 128 bit interface erst mal aus.Und genau da trennen sich unsere Meinungen ;)

Bei 128bittigem Interface und 8x2 Architektur braucht das Ding schon 50% höheren Speichertakt und effektive Kompression für Z und Farbwerte (pi mal Daumen muß alles halbiert werden), um nicht bandbreitenlimitiert zu sein (schon ganz ohne Texturen) und um überhaupt mit der R300 gleichzuziehen.
Eine 16x1 Architektur wäre mit diesem Speicherinterface IMO die reinste Verschwendung. Was nützen mir 16 Z/Stencil-Ops pro Takt, wenn die Bandbreite nur für acht davon ausreicht (immer noch unter Annahme von 2:1 Kompression)?

Das mag jetzt albern klingen, aber ich will einen Quake 3-Benchmark sehen, oder die Bestätigung, daß doch ein 256 Bit Interface verbaut wird, vorher glaube ich nicht daran, daß der R300 in Punkto Balance geschlagen werden kann.

[zeckensack]

Originally posted by Unregistered
Und genau da trennen sich unsere Meinungen ;)Scheiß Einlog-Probleme :jedifire:

[Demirug]

Originally posted by Unregistered
Und genau da trennen sich unsere Meinungen ;)

Bei 128bittigem Interface und 8x2 Architektur braucht das Ding schon 50% höheren Speichertakt und effektive Kompression für Z und Farbwerte (pi mal Daumen muß alles halbiert werden), um nicht bandbreitenlimitiert zu sein (schon ganz ohne Texturen) und um überhaupt mit der R300 gleichzuziehen.
Eine 16x1 Architektur wäre mit diesem Speicherinterface IMO die reinste Verschwendung. Was nützen mir 16 Z/Stencil-Ops pro Takt, wenn die Bandbreite nur für acht davon ausreicht (immer noch unter Annahme von 2:1 Kompression)?

Das mag jetzt albern klingen, aber ich will einen Quake 3-Benchmark sehen, oder die Bestätigung, daß doch ein 256 Bit Interface verbaut wird, vorher glaube ich nicht daran, daß der R300 in Punkto Balance geschlagen werden kann.

2:1 Kompression ist gar nichts. LMA II kommt beim Z-Buffer auf 4:1 und ATi behauptet ja das der R300 bei 6xAA bis auf 24:1 kommt.

Stencilschatten:
Z Lessen 24 Bit C= 6Bit
Stencil Lessen 8 Bit C = 4Bit
Stencil Schreiben 8 Bit C= 4Bit

Gesamt 40 Bit C= 14Bit

14*16 = 228 bit. Dabei habe ich beim Stencil nur eine 2:1 Kompression angenommen. In der Realität sollte eine bessere Kompression erreichbar sein. Wir hätten natürlich auch noch verschnitt aufgrund der Tilekompression was den Bandbreitenbedarf wieder etwas erhöht. In Summe liegen 16 Pipelines beim Stencilschatten hart am limit. Aber selbst wenn man dabei nur 12-14 Pipelines wirklich nutzen könnte wäre man einem 8*2 Pipelines Desgin überlegen.

[aths]

Originally posted by Demirug
2:1 Kompression ist gar nichts. LMA II kommt beim Z-Buffer auf 4:1 und ATi behauptet ja das der R300 bei 6xAA bis auf 24:1 kommt.Wenn LMA den Z-Wert komprimieren kann, dann auf (maximal) 8 Bit. Klappt das nicht, wird er unkomprimiert übertragen. Ich schätze, dass nur 60-70% der Z-Werte (höchstens!) komprimiert werden können.

ATIs "24:1" berücksichtigt die Vorteile durch den FAA-Buffer, und das trifft wohl nur a) innerhalb des Polygons und b) bei gut komprimierbaren Z-Werten zu.

[Demirug]

@aths, zeckensack:

Können wir uns auf folgendes einigen?

Wenn NV wirklich 16 TMUs verbaut hat müssen sie entweder ein 256 Bit Interface oder ein paar verdammt gute Idee zur Reduktion des Bandbreitenverbrauchs gehabt haben.

Von meiner Meinung das ein 16*1 Aufbau beim PS 2.0 sinnvoller als 8*2 ist werde ich allerdings nicht abrücken bis mir jemand ein wirklich gutes Argument liefert.

[HOT]

Geforce3 und Geforce4 sind schon mit einer 4x2 Architektur arg Bandbreitenlimitiert. Der Leistungsvorsprung der Geforce4 besteht ja im Grossen und Ganzen ja nur durch höheren Takt und das verbesserte Speicherinterface. Meiner Meinung nach lässt sich da auch ohne wirkliches HSR nicht mehr sehr viel reissen. ATI gab dem R300 nur eine TMU, weil die 2. nicht mehr hätte versorgt werden können vom ATI Speicherinterface. Sicherlich könnte NV im NV30 jetzt das 256Bit Speicherinterface soweit optimieren, dass sich die 2. TMU lohnt, dann wäre der NV30 in der Tat schneller als der R300 bei gleichem Takt, zumindest theoretisch. Ich bin aber auch Zeckensacks Meinung, dass NV erstmal am R300 vorbei muss, wichtig ist hier jede Disziplin. Der R300 ist meiner Meinung nach extrem effizient von der Bandbreitenausnutzung seiner 8 Pipes, auch das Trianglesetup und die Vertexshader passen einfach zur Renderingunit.
Einen besseren IMR wird es wohl vorerst nicht geben. Der NV30 muss mir erst seine Effizinz beweisen.

Na ja, mal sehen ob wir nich noch eine andere Überraschung erleben im Herbst :D ;)

[zeckensack]

Originally posted by Demirug
@aths, zeckensack:

Können wir uns auf folgendes einigen?

Wenn NV wirklich 16 TMUs verbaut hat müssen sie entweder ein 256 Bit Interface oder ein paar verdammt gute Idee zur Reduktion des Bandbreitenverbrauchs gehabt haben.

Von meiner Meinung das ein 16*1 Aufbau beim PS 2.0 sinnvoller als 8*2 ist werde ich allerdings nicht abrücken bis mir jemand ein wirklich gutes Argument liefert. Klar, einverstanden :)

[AmenophisIII]

was gibts eigentlich außer dem zitat "tileing is bad" für FAKTEN, die gegen einen tbr sprechen?
3dfx hatte leute und patente mit erfahrung in dem bereich, warum sollten die nicht in die entwicklung des nv30 eingeflossen sein?

[Demirug]

Originally posted by AmenophisIII
was gibts eigentlich außer dem zitat "tileing is bad" für FAKTEN, die gegen einen tbr sprechen?
3dfx hatte leute und patente mit erfahrung in dem bereich, warum sollten die nicht in die entwicklung des nv30 eingeflossen sein?

Also die Patente kann man vergessen. Die sind von 1999 und mit den dort benutzten Verfahren wäre die CineFX Technik nicht mit vertretbarer Geschwindigkeit zu implementiren.

[Xmas]

Originally posted by AmenophisIII
was gibts eigentlich außer dem zitat "tileing is bad" für FAKTEN, die gegen einen tbr sprechen?
NVidias aktuelle Empfehlungen an Entwickler. Für einen TBR würde man keinem empfehlen, zuerst in einem extra Pass den Z-Buffer zu rendern.

[Tatwaffe]

höhere computing efficiency deute ich aber mal mit weg von der
Brute-Force, egal mit welchen techniken das hinterher erreicht wird, könnte das schon einiges an leistung freisetzen.

was ich mir vorstellen könnte wären rams mit niedrigeren latenzen (edram?), tiler, caches mit besserer voraussage, effektiveres speicherinterface.

aber die hundert(e) nv-entwickler haben sich da bestimmt noch was neues ausgedacht, die machen ja den ganzen tag nix anderes.

[GloomY]

Originally posted by Tatwaffe
was ich mir vorstellen könnte wären rams mit niedrigeren latenzen (edram?), tiler, caches mit besserer voraussage, effektiveres speicherinterface.
Latenzen spielt bei Graka-RAM kaum eine Rolle, da hauptsäachlich in Bursts gelesen und geschrieben wird. Da ist Speicherbandbreite das Entscheidende (man erinnere sich an den Leistungszuwachs von GF1 SDR auf GF1 DDR).

An Caches kann man imho nur noch die Größe ändern. Sonst sehe ich keine großen Optimierungsmöglichkeiten (eventuell noch Assoziativität). Die Größe wirkt sich aber dann doch realtiv stark auf die Transistorenanzahl und damit auf die Herstellungskosten aus, womit auch hier ein gewisses Limit für Optimierungen abzusehen ist.

Beim Speicherinterfaces sind - von der Breite der Anbindung mal abgesehen - auch so langsam die Grenzen erreicht. Man kann den Speicherbus natürlich immer noch verbreitern, man erkauft sich damit aber wiederum einen Effizienzrückgang, da die einzelnen Stücke, in die die gesamte Bandbreite vom Controller aufgeteilt wird, auch größer wird (GF4: 256 Bit -> 4x 64 Bit, R300: 512 Bit-> 4x128 Bit).
Eventuell kann man an der Anzahl der "Stücke" noch was ändern, aber irgendwo ist dann aber auch die Grenze erreicht, schliesslich gibt es nur eine endliche Anzahl an Anschlussleitungen an die Speicherchips ;)

Und was bleibt jetzt noch groß übrig?

Tiler? Hmm, ich erinnere dann mal an "Tiling is bad!"

Mal schauen, was nV uns diesmal beschehrt...

[TheRealTentacle]

Wäre nicht eine Multi Chip verfahren Effektiver? Sicher sind die sehr Teuer, aber der R200 und auch der NV 30 sollen (angeblich) MS unterstützen! NVidea hat da ja anscheinend von 3Dfx gelehrnt (siehe externer Geometrichip auf Rampage) Das Multichip GKs Effektiv sind, hat ja schon die V5 gezeigt (auch wenn nur in 2xFSAA)

[Quasar]

Wenn Multi-Chip auch sonst nichts ist, aber es befähigt das Gesamtdesign wohl zu deutlich höheren Taktraten, als es ein komplexer Riesen-Die erlaubte.

Ich wäre ja immer noch für dedizierte Interfaces für die verschiedenen Speicherbereiche und möglichst einen on-Die (eDRAM oder sowas) Z-Buffer.

Profi-OpenGL Beschleuniger hatten auch lange Zeit getrennte Speicher für Framebuffer und Texturen....wieso wohl?? ;)