NV30, mit 128 oder 256 Bit

[Unregistere]

Original erstellt von TheShaft
[quote:]
--------------------------------------------------------------------------------
Und desweiteren kann man nVidia durchaus zutrauen, wie schon bisher eine effizientere Bandbreiten-Schon-Technologie als ATi auf die Beine zu stellen - bisher lag nVidia bei Generations-gleichen Chips diesbezüglich immer vorn.

radeon vs geforce 2 - gleiche chipgeneration, aber nur die radeon hat zu dem zeitpunkt eine bandbreiten-schonungstechnologie besessen... [/QUOTE]


Dann schau doch mal, wieviel spaeter die Radeon als die GF2 kam.

Und das Bandbreiten-(und Fillrate-)schonen der Radeon1 ist ein Witz, weil es selbst bei hohem Overdraw nicht mehr als 10% Mehr-Leistung bringt.

 

[DjDino]

Und mal sehen was Nvidia auf ATI´s Multi-Sampling Anti-Aliasing antwortet, desen 24fache Kompressionsrate macht die Radeon9700pro selbst bei 6x Antialiasing traumhaft schnell, unter UT2003 mit einem FPS-Verlust weit unter 30%

Schliesslich muss der NV30 auch bei FSAA überzeugen können - da ist der Radeon9700pro der schärfste Konkurent zur Zeit.

 

[Unregistere]

Das MSAA der R9700 ist zweifelsfrei sehr gut gelungen.

Die weniger als 30% Performance Verlust gibt's aber nur in eher CPU-limitierten Szenarien. Ansonsten sind es auch schon mal mehr.

 

[seahawk]

Ok ich ziehe meine Aussage über April zurück. Das ist ein Fehler vieler deutscher Internetseiten. Der CEO von NV sagte die NV30 wird im "January Quarter" in Massen ausgeliefert.

Das Geschäftsjahr von Nvidia ist aber nicht gleich dem Kalenderjahr.

Das vierte Quartal bei denen geht von November - Januar. Das wird oft als January Quarter bezeichnet. Vermutlich liegt hier also gar keine Verzögerung vor.

 

[Carsten]

Original erstellt von DjDino
@Carsten

http://www.beyond3d.com/articles/nv30r300/index.php?p=10
"Whether NV30 uses a 256bit memory interface or not is as yet unknown. In my opinion, NV30 has more chance to have a 128bit memory interface than a 256bit memory interface due to many hints. According to Samsung, its 1GHz DDRII memory module will be yielded volumetrically in the 3rd quarter, 2002."
"R300's raw memory bandwidth, advanced memory compression (12:1 on color, 24:1 on Z) and hierarchical Z (hit 64 pixels per cycle of raw fill) do impress us here, which is the basis of the excellent presentation of R300 on FSAA."

Kein Kommentar dazu?

nV30: Zephyr weiss auch nix genaueres (wie auch?). Die Info mit Samsung ist natürlich richtig, Massenproduktion von DDR-II mit 2,0ns läuft schon seit ein paar Wochen.

R300: Wobei die Framebufferkompression IMO nicht ganz unproblematisch ist. (Ich kann einige Artefakte erzeugen, die stark nach einer nicht wieder aufgelösten Kompression aussehen, näheres dazu später...).
HyperZ war, was das entfernen verdeckter Pixel angeht, der LMA schon immer überlegen, die GeForce konnte nur einen Bruchteil der Pixel zurückweisen, die der Radeon in einem Pass entfernte.

Original erstellt von Unregistere
Dann schau doch mal, wieviel spaeter die Radeon als die GF2 kam.
Und das Bandbreiten-(und Fillrate-)schonen der Radeon1 ist ein Witz, weil es selbst bei hohem Overdraw nicht mehr als 10% Mehr-Leistung bringt.

ATi hat einfach einen anderen Produktionszyklus als nVidia, einmal im Spätsommer anstelle Frühjahr/Herbst, insofern passt der Generationenvergleich schon.
HyperZ ist im Gegenteil von höchster Wichtigkeit besonders für die Ur-Radeons. Mit ihren zwei Pipelines und quasi der halben Pixel- und Texelfüllrate (333MPix/s vs 800MPix/s; 996MTex/s vs. 1600MTex/s) schafft die Radeon es, meist den Anschluss zu halten, wenn auch nicht wirklich häufig, die GeForce2 auszuperformen.
Ohne HyperZ sähe es da schon ein wenig anders aus.

Original erstellt von Unregistere
Das MSAA der R9700 ist zweifelsfrei sehr gut gelungen.
Die weniger als 30% Performance Verlust gibt's aber nur in eher CPU-limitierten Szenarien. Ansonsten sind es auch schon mal mehr.

Full ack.

 

[Droid999]

Wer sich mal das hier durchliest
http://www.nvidia.com/content/areyouready/story.html
wird zwei Aussagen bemerken :

1. there's simply no substitute for effective memory bandwidth
2. How much faster? "Hmmm, I won't let any numbers drop yet, but let me just say that I feel that no one will be disappointed."

Erstes deute ich mal so, das es wohl keine neue Super-Ultimative-Bandbreiten-Spar-Technik geben wird, weil halt nichts über echte Bandbreite hinausgeht. Sprich 256 Bit :-)

Die zweite Aussage ist wohl noch eindeutiger : Ich wäre enttäuscht wenn der NV30 nur 256 Bit hätte - hoffentlich gehöre ich nicht zu der "no one" Gruppe ;-)

Final Specs wohl erst in 9 Tagen... :-(

 

[DjDino]

Nur 128Bit-Speicher müsste rechnerisch doppelt hoch getaktet werden um die Leistung von 256Bitigen zu erreichen. Theoretisch auf 1240Mhz um dieselbe Bandbreite von 620Mhz(256Bit) der Radoen9700pro zu erreichen und selbst dann wäre es nur ein "erreichen" aber nicht übertrumpfen und ich gehe mal davon aus das Nvidia auch hier (wie gewohnnt) übertrumpfen wird und will.

Abgesehn davon sind trotz bandbreitenschonendes LMA III allein schon durch das höherbittigere-mögliche 40Bit-Rendering der DirectX9-Spezifikation höhere Anforderungen an fetteren, gösseren Textur(daten) (mit mehr Farbinformationen, also 24 Bit Texturen-Farbtiefe ) zu erfüllen und die brauchen auch Bandbreite.

Was nutz denn sonst bitte sonst so schön-hochbittiges Rendering wenn die Texturen in z.b. nur mageren und komprimierten, dadurch noch unschöneren 16Bit-Farbetiefe vorliegen ?

DX9 erfordert eine 40 Bit Rendering-fähige Architektur und wenn ich mich nicht irre steigt dadurch auch der Texturdatenaufwand durch nun mehr mögliche RGB-Farbinformationen was auch mehr Speicher-Bandbreite erzwingt, später soll gar 64-Bit-Rendering unter DirectX9 ermöglicht werden.Natürlich kann man durch z.b. Framebuffer-Komprimierung hier Daten einsparen aber so oder so glaube ich nicht das 128Bit-Speicher allein schon zur Einhaltung dieser Anforderungen ausreicht.

 

[S.t.A.L.k.e.R]

Parhelia war ne große ankündigungund was wars am ende. Ne Saubilige Graka mit n paar aliasing effekten sonst nix

 

[Unregistere]

Original erstellt von Carsten

HyperZ ist im Gegenteil von höchster Wichtigkeit besonders für die Ur-Radeons. Mit ihren zwei Pipelines und quasi der halben Pixel- und Texelfüllrate (333MPix/s vs 800MPix/s; 996MTex/s vs. 1600MTex/s) schafft die Radeon es, meist den Anschluss zu halten, wenn auch nicht wirklich häufig, die GeForce2 auszuperformen.
Ohne HyperZ sähe es da schon ein wenig anders aus.

Ich habe die Performance mit/ohne HyZ auf der Radeon ausführlich getestet. Macht zB. 38 zu 34 fps im VillageMark bei 1024x32. Bei weniger Overdraw sind´s auch mal weniger Unterschied.
Eine GF2 ausperformance kann man vergessen, manchmal reicht es nicht mal für eine GF2MX.

 

[Unregistere]

Original erstellt von DjDino
Nur 128Bit-Speicher müsste rechnerisch doppelt hoch getaktet werden um die Leistung von 256Bitigen zu erreichen. Theoretisch auf 1240Mhz um dieselbe Bandbreite von 620Mhz(256Bit) der Radoen9700pro zu erreichen und selbst dann wäre es nur ein "erreichen" aber nicht übertrumpfen und ich gehe mal davon aus das Nvidia auch hier (wie gewohnnt) übertrumpfen wird und will.

Derartige Rechnereien sind absolut uninteressant, weils nix als Zahlenspielereien sind. Die Effizienz des Interface wird dabei in keinster Weise berücksichtigt.

Abgesehn davon sind trotz bandbreitenschonendes LMA III allein schon durch das höherbittigere-mögliche 40Bit-Rendering der DirectX9-Spezifikation höhere Anforderungen an fetteren, gösseren Textur(daten) (mit mehr Farbinformationen, also 24 Bit Texturen-Farbtiefe ) zu erfüllen und die brauchen auch Bandbreite.

Was nutz denn sonst bitte sonst so schön-hochbittiges Rendering wenn die Texturen in z.b. nur mageren und komprimierten, dadurch noch unschöneren 16Bit-Farbetiefe vorliegen ?

DX9 erfordert eine 40 Bit Rendering-fähige Architektur und wenn ich mich nicht irre steigt dadurch auch der Texturdatenaufwand durch nun mehr mögliche RGB-Farbinformationen was auch mehr Speicher-Bandbreite erzwingt, später soll gar 64-Bit-Rendering unter DirectX9 ermöglicht werden.Natürlich kann man durch z.b. Framebuffer-Komprimierung hier Daten einsparen aber so oder so glaube ich nicht das 128Bit-Speicher allein schon zur Einhaltung dieser Anforderungen ausreicht.

Die Rendering-Genauigkeit von 40, 64 oder 128Bit bezieht sich auf die interne Genauigkeit des Chips und belastet das Speicherinterface überhaupt nicht mehr als normales 32Bit Rendern.
Der Framebuffer ist weiterhin nur 32Bit breit.

 

[M3phist0]

Allem in allen soll die neue G5 nichts schneller sein wie die derzeitige Ati Radeon 9700.
Mal sehen wie sich die Benchmarkteste schalgen werden.

 

[DjDino]

@Unregistered

Was hast du gegen Zahlenspielerei wenn die Rechnung stimmt ? Mögliche bessere Latenzeiten von DDR II nicht miteinbedacht, aber das war auch nicht beabsichtigt.

ZITAT :

"64 Bit Rendering - Sinn oder Unsinn : Allerdings nimmt auch die erforderliche Speicherbandbreite zu...Für 64-Bit-Rendering nur 16-Bit-Texturen einzusetzen, ist natürlich nicht befriedigend. Es müssten also neue Texturkompressions-Standards entwickelt werden, die mit 24 Bit Farbtiefe ("Truecolor" bzw. "Echtfarben") speichern...Der lokale Speicher von 64-Bit-Grafikkarten muss also auf jeden Fall ausreichend dimensioniert sein, wenn keine Leistung verschenkt werden soll"

Quelle : http://www.3dcenter.de/artikel/2001/07-26b.php

Hab ich gelessen, irre interssant.

Klar wird der NV30 mit Hilfe der sicher noch effizientieren LMA III-SpeicherBandBreitenSchonung, (hoffentlich) weniger Overdraw, Texturkompressionen, und 4 vielleicht (sogar dann jetzt auf 8?) gesplittert-dynamischeren Speichercontrollern,etc. die verfügbare Speicherbandbreite effizienter auschöpfen.

Die Gretchenfrage die ich eigentlich ansprechen wollte ist, ob all das eben reichen könnte falls nur 128Bit-Speicher zur Verfügung steht

Die \"interne Rechengenauigkeit\" ist mit 128 Bit bei der Radoen9700pro sowie dem NV30 schon klasse - dadurch weniger Rundungs-Rechenfehler für korrektere Blending-Operation - weniger mögliche "Falschfarben".

Nur 32-Bit-Texturen haben aber eine 24Bit-(EchtFarben)-Farbtiefe :
8Bit-AlphaWert/Transparenz + 8bit für Rot + 8Bit für Grün + 8Bit für Blau(RGB) = 32,32Bit.

Schön und gut also wenn der Chip hier intern so genau Farben, Blendings rechnen kann (Fliesskomma-Farben), aber was nutzt das wenn dafür Texturen mit viel niedriger Farbtiefe zum Einsatz kommen ? Nochdazu wo Texturkompression auch Farbkompression bewirkt ? (Ausnahme vielleicht Multitexturing wo dann insgesammt mehr mehr übrigbleibende Rechengenauigkeit pro Textur)

Deswegen sage ich das so hochbitiges Rendering prinzipiell nur noch mit "qualitativ vollwertigen" 32Bit-Texturen gemacht werden sollte und wohl auch wird müssen, oder aber es müssen bessere Textur-Kompressionsverfahren für weniger Qualitätsverlust sorgen und das geht nur mit weniger Kompression.

Ergibt in beiden Fällen einen höheren Bedarf an Texturdaten die in den Speicher geladen werden müssen was Bandbreite braucht.

Carmak selbst sagte mal das sogar 64Bit-Texturen als Grundlage hier eigentlich wünschenswert wären um bei "über-64Bit-Rendering" durch dieses mehr Vorteile ziehen zu können, der FrameBuffer müsste hier dann natürlich auf 64Bit ausgelegt sein (Geforce5?) - der TexturdatenStrom wäre dann in jedem Fall selbst bei Kompression enorm und ein 128Bit-SpeicherBus zu schmal. (Zugegeben 64Bit-Texturen ne ziemliche Zukunftsmusik jedoch unter DirectX9 durchaus sinnvoll)

Muss aber sagen die Rechenlogik steigt mir auch langsam über den Kopf

 

[Riptor]

Mal ne Frage: Was würde qualitativ 64Bit-Rendering für den Betrachter bringen? Meinen Infos nach bringt das nur was, wenn da noch mehrere Lichtquellen einfluß auf das geschehen haben... Korrigiert mich, wenn ich falsch liege!

Weiterhin: Im Framebuffer werden doch "Bilder" zwischengespeichert, die ausgegeben werden, oder?

Und: Was versteht man genau unter "Overdraw"? Laut 3DConcept ists ja die Überlagerung von Polygonen, die die Grafikkarte neu soriteren muss, damit der Betrachter kein Chaos auf dem Bildschirm bekommt... Geschieht dies auf Kosten des GPU-Taktes oder ist das einfach nur Bandspeicherfressend, also geht das auf die Speicheranbindung? Könntet mich ja mal ein wenig aufklären, alles weiß ich wirklich nicht so genau und man lernt ja immer dazu...

Und nochwas: WAS bringt es, wenn eine Grafikkarte intern höher rendern (rendern = darstellen? kann, aber das nicht ausgeben kann bzw. das menschliche Auge sowieso keinen Unterschied merkt? Wäre doch auch bei 64Bit-Texturen so, merkt ja keine Mensch im Vgl. zu 32Bit bzw. 24Bit verwendeter Farbtiefe! Oder kann man dadurch die wie bei 3D Center besagten "Zusatzeffekte" und noch genauere 3D-Darstellungen erlangen, sprich mehrere Lichtquellen geben ein exakteres Bild etc...?

 

[Riptor]

*ops*

 

[Carsten]

32Bit ist als Ausgabe-Farbtiefe völlig ausreichend, bei den 64Bit-Renderings geht es in erster Linie darum, interne Rundungsfehler und schlechte (weil lineare) Genauigkeitsverteilung (Das menschliche Auge ist z.B. was Farbabstufungen angeht, deutlich weniger empfindlich, als was Helligkeitsabstufungen angeht) zu kompensieren.
Ein 32Bit-Chip berechnet intern mit vielen Blendingoperationen etc. schon ein sichtbar falsches Bild, das ist so ähnlich, als wenn du eine Kopie einer Kopie einer Kopie einer Kopie anschaust, irgendwann siehst du die Verschlechterung.

Overdraw ist die Überlagerung von Polygonen bzw. Oberflächen im Allgemeinen. Was du da von 3dConcept zitierst, scheinst du aber etwas durcheinanderzubringen, die Sortierung erfolgt mittels des Z-Buffer, in dem die Tiefeninformationen für ein Objekt abgelegt werden, der Overdraw ist einfach nur der Faktor, mit dem die Oberflächen an den Grafikchip geschickt werden. Ein Overdraw von 3 bedeutet z.B., dass die Szene, so wie sie der Grafikchip bekommt, dreimal soviele Oberflächenpixel enthält, wie später auf dem Bildschirm ausgegeben werden.

Die "Zusatzeffekte", die aths anspricht, sind in erster Linie solche Dinge, wie Overbright Lighting, korrektere Refraktionsberechnungen von Licht durch transparente Oberflächen etc. Einfach nur "mehr" Lichtquellen sind auch heute schon möglich, ziehen jedoch zuviel Leistung.

EIn letztes noch....guck dir mal das Bild genau an, besonders den grün umrahmten Teil:

 

[Riptor]

@ Carsten: THX für die ausführliche Antwort! ... Aber warum EDIT?

Original erstellt von Carsten bei den 64Bit-Renderings geht es in erster Linie darum, interne Rundungsfehler und schlechte (weil lineare) Genauigkeitsverteilung[/b]

Würde dadurch wirklich ein merklich besseres Bild entstehen (sind die Rundungsfehler nicht doch nur eine zu vernachlässigende Nebenerscheinigung)? Mir würde auch ein "36Bit-Rendering" nach dem "22Bit" 3DFx-Muster reichen --> http://www.3dconcept.ch/artikel/dithering/index.html , denn ich denke 64Bit-Rendering würde dick auf die Performance gehen, oder täusch ich mich da? Ein bißchen die Augen verarschen und Performance sparen hört sich meiner Meinung nach sinnvoller an, aber wahrscheinlich entstehen dadurch nicht die gewünschten realistischen Bilder, die wir wollen bzw. mit 32Bit nicht mehr so ganz darstellbar sind...

Noch ne kleine Frage: Gibt es eigentlich in den meisten Spiele 24 oder 32Bit Texturen?

Ansonsten: Nochmals dankeschön, muss mir das mal alles ein wenig klarer werden lassen, ist ziemlich komplex.

 

[Carsten]

"edit" wegen deiner zwei Postings oben innerhalb von kurzer Zeit. Lass' es einfach nicht zur Gewohnheit werden...

Zu, 64Bit-Rendering:
Jein, bei heutigen Games wird bewusst auf Effekte und Darstellung verzichtet, bei denen solche Fehler stark auffallen würden, in denen würde eine Erhöhung auf 64Bit kaum auffallen. Aber Game-Designer könnten, wenn das Feature eine entsprechende Verbreitung erreicht hat (in zwei, drei Jahren) eben auch solche Effekte einsetzen und bräuchten weniger drumrumzutricksen.
Mir ist in der Zwischenzeit noch einfgefallen, dass nicht nur Licht, sondern auch Nebel von höherer Genauigkeit stark profitieren könnte, da dort auch eher Helligkeits- als Farbabstufungen zum Einsatz kommen.

Die Performance würde nur mäßig drunter leiden, IMO. Kommt allerdings ganz drauf an, wie die Chips ausgelegt sind: 32Bit-Chips mit angeflantschtem 64Bit-Modus brächen wohl stärker ein, als echte 64Bit-Chips, die quasi nebenbei 32Bit rendern könnten.

Die meisten Spiele verwenden Texturen so, wie sie gerade brauchen. Dafür gibt's in DX und OGL unterschiedliche Texturformate. Diese werden normalerweise nach ihren Auflösungen in den einzelnen Komponenten benannt RGAB (Red Green Blue Alpha).
Bei einer Auflösung von 32Bit könnte jeder Kanal maximal 8 Bit abbekommen, aber auch eine sinnvollere Aufteilung, bzw. platzsparendere wäre denkbar, z.B. kann eine Wandtextur meist ohne Alpha (=Transparenz) auskommen, so dass dort 24Bit (RGB888) völlig ausreichend wäre.

Hier gibt's eine Demo mit recht guter Erklärung (läuft auch auf Nicht-PowerVR-Karten)...

 

[DjDino]

Original erstellt von Carsten
...dass nicht nur Licht, sondern auch Nebel von höherer Genauigkeit stark profitieren könnte, da dort auch eher Helligkeits- als Farbabstufungen zum Einsatz kommen.

Da ist echt was dran, "16Bit-Nebel" kann man ja echt vergessen, die Render-Abstufungen sind zu deutlich zu sehen.

Nebel ist erst ab 32bit Farbtiefe "abstufungsfrei"-ansehnlich und erst 32Bit rastert auch nicht mehr so schirch-grünlich. (Schön zu sehen bei der Drachenszene von 3DMark2001SE)

Frage :

Wenn bei 32Bit-Texturen der AlphaKanal 256 Transparenzstufen haben kann, was könnte dann bei theoretischen 64Bit-Texturen die Qualität von Licht und Nebeleffekten mehr verbessern , die dadurch höher möglichen RGB-Farbabstufungen oder höher möglichen Transparenz-Abstufungen ?

Ich mein die möglichen Farbabstufungen sind bei 32Bit ja wohl schon ausreichend oder ? Nebel benötigt IMHO doch mehr Alpha Blending, um realistisch-transparenter zu erscheinen.

Sollte es so sein das hier nur mehr Transparenz-Abstufungen für noch mehr Qualität sorgen würde schon 64Bit-interne-Rendergenauigkeit da doch keinen Sinn machen wenn als Basis weiterhin "nur" Texturen mit gleichbleibenden 256 Alpha-Transparenzstufen verwendet werden, weniger Rundungs-Rechenfehler für korrektere Blending-Operationen sind schön aber auch durch Farb und Transparenz-Abstufungen der zu behandelnen "nur 32bit"-Texturen eingeschränkt ?

 

[Carsten]

Bei 64Bit Rendering entfielen erstens die sichtbaren Artekfakte von Mutlipass-Rendering in niedrigerer Farbauflösung und zweitens bringt DX9 (und OpenGL 2.0 sicher auch) wohl auch ein paar neue Texturformate mit, die dank der Ermöglichung von 64Bit Gesamtbreite hoffentlich auch den einzelnen Kanälen eine größere Breite als 8Bit ermöglichen, so dass man Spezialformate wie ein eben gerade von mir ausgedachtes ARGB von 10-5-7-5 (für hohe Alpha und immer noch gute Grünauflösung) zum Beispiel nutzen könnte.

Nebel an sich wird aber wohl besser nicht mit Texturen, sondern gleich als Vertex-Fog oder Volumetrisch erzeugt....zur Not auch mit Partikelsystemen...

edit:
Aber frag' mich lieber nicht weiter zu sowas aus...a) ist DX9 noch nichtmal final und b) hab ich von Programmierung herzlich wenig Ahnung.

 

[DjDino]

Wird es DirectX9 auch noch für Win98SE geben und wann kommt es in etwa final raus ? Leider sollen aber Spiele DirectX9-Erweiterungen kaum vor 2004 so richtig nutzen oder ?