Rampagetechnik bei GeForce 4?

[Sebuste]

meine Frage ist ob die Rampagetechnik bei der GeForce 4 zum einsatz kommt !?

ich denke mir es koennte sein das nvidia das AA von 3dfx kopiert hat und aus martktechnischen gründen erst jetzt verbastelt hat.

was meint ihr dazu und liege ich richtig mit meiner annahme ?

[ow]

Der GF4 nutzt sicher keine 3dfx Technik.

[HiddenGhost]

Originally posted by Sebuste
meine Frage ist ob die Rampagetechnik bei der GeForce 4 zum einsatz kommt !?

ich denke mir es koennte sein das nvidia das AA von 3dfx kopiert hat und aus martktechnischen gründen erst jetzt verbastelt hat.

was meint ihr dazu und liege ich richtig mit meiner annahme ?

Das ist immernoch nach Quincux FSAA aufgebaut. Einzig und allein der Drehwinkel wurde optimiert ,damit vertikale Struckturen besser geglättet werden .

mfg pcg

[aths]

PCGenius,

nee. Horizontale Strukuren werden besser geglättet. Es gibt auch keinen Drehwinkel, das Muster beim 4xS-Modus ist anders (schlechter) als bei der Voodoo5.

Quincunx hat mit dem 4xS Modus nichts zu tun. Quinunx ist nur ein Muster.

[aths]

Sebuste,

es wird damit gerechnet, dass 3dfx-Technik im NV30 zu finden sein wird. Das werden wir wahrscheinlich noch in diesem Jahr sehen. Die GeForce4 hat ihr Anti-Aliasing sehr wahrscheinlich nach der 3dfx-Methode (im VSA-100 eingesetzt) verschnellert.

[b0wle`]

Originally posted by ow
Der GF4 nutzt sicher keine 3dfx Technik.

Woher weißt du das? Arbeitest du bei nvidia ??? ;)

[Kennung Eins]

Originally posted by ow
Der GF4 nutzt sicher keine 3dfx Technik.
Die Quadro 4's nutzen (wenn mich meine Quelle nicht belügt) SLI ähnliche Technik. Adaptiert von 3Dfx.
Multichiplösung o.ä. (also nicht 2 Karten à la Voodoo2 sonder n chips à la Voodoo5)

[Villa Riva]

Originally posted by aths
Die GeForce4 hat ihr Anti-Aliasing sehr wahrscheinlich nach der 3dfx-Methode (im VSA-100 eingesetzt) verschnellert.

http://www.3dcenter.de/artikel/2002/02-11_a.php

Originally posted by aths
Das Downsampling für Quincunx wird mittels einem verbesserten Line-Cache deutlich effizienter als früher verwirklicht.

Versteh ich jetzt nicht. 3dfx machte Line Caching?

[aths]

Da sie kein Quincunx bieten, wohl kaum. Quincunx meint hier nur Quincunx und nicht das komplette nV-AA-Verfahren.

nVidia sagt, AccuView spart gegenüber HRAA einen Schreibzyklus pro Pixel eín. Offenbar wird beim Downsampling auf das Schreiben in den Framebuffer verzichtet, und die Buffer werden direkt im RAMDAC gemischt - wie im Napalm.

[ow]

Originally posted by aths
. Offenbar wird beim Downsampling auf das Schreiben in den Framebuffer verzichtet, und die Buffer werden direkt im RAMDAC gemischt - wie im Napalm.


Um serioese Quellen hierzu bitte ich dich.

[ow]

Originally posted by Kennung Eins

Die Quadro 4's nutzen (wenn mich meine Quelle nicht belügt) SLI ähnliche Technik. Adaptiert von 3Dfx.
Multichiplösung o.ä. (also nicht 2 Karten à la Voodoo2 sonder n chips à la Voodoo5)


Kannst du deine Quelle benennen?

Ansonsten halte ich das naemlich fuer ein Geruecht bzw. den plumpen Versuch, alle technischen Neuerung von NV jetzt als "3dfx-Technik" hinzustellen.

[Kennung Eins]

Originally posted by ow



Kannst du deine Quelle benennen?

Ansonsten halte ich das naemlich fuer ein Geruecht bzw. den plumpen Versuch, alle technischen Neuerung von NV jetzt als "3dfx-Technik" hinzustellen.
Kann ich, schick ich dir als pm.

[Villa Riva]

Originally posted by aths
nVidia sagt, AccuView spart gegenüber HRAA einen Schreibzyklus pro Pixel eín. Offenbar wird beim Downsampling auf das Schreiben in den Framebuffer verzichtet, und die Buffer werden direkt im RAMDAC gemischt - wie im Napalm.

Wo steht das AccuView einen Schreibzyklus spart? (Quelle?)

[aths]

ow,

nee, die meisten Neuerungen hat nV von ATI übernommen :)))

Ich kümmere mich mal um eine vernünftige Quelle bezüglich AccuView.

[aths]

Also auf die Schnelle finde ich nur was bei thg:

http://www6.tomshardware.com/graphic/02q1/020206/geforce4-04.html

"to produce the final anti aliased frame has been tweaked to save one complete frame buffer write"

Das AccuView-PDF von nVidia spricht nur generell von weiteren Daten-Pfaden und wird nicht konkret.

Die Bemerkung von THG bedeutet nicht zwingend, dass die Napalm-Technik verwendet wird. Allerdings erscheint das sehr vernünftig. Im gleichen Zuge würde übrigens auch mehr RAM für die Framebuffer gebraucht (genauer gesagt für die Backbuffer, da es ja keinen Framebuffer mehr gibt) und da GF4 über 128 MB RAM verfügt, sollte das wirklich kein Problem darstellen.

Nicht nur bei Quincunx, auch allgemein ist eine gestiegene Performance beim AA festzustellen, die offenbar nicht aus LMA2 resultiert. nVidia hat hier etwas verbessert - was THG sagt, ist naheliegend.

[Unregistered]

Originally posted by aths
Die Bemerkung von THG bedeutet nicht zwingend, dass die Napalm-Technik verwendet wird

Also ist das eine Spekulation.

Der Rest von dir ist ziemlich wirr. Der Back Buffer gehört zum Frame Buffer. Und wieso soll mehr RAM gebraucht werden?

[Leonidas]

Originally posted by Kennung Eins




Hehe, hoher Besuch!

[Villa Riva]

Originally posted by Kennung Eins

Kann ich, schick ich dir als pm.

Hehe, im nächsten GTU lässt sich SLI wohl per Registry-Eintrag aktivieren, LOL!

[aths]

Unreg,

wenn man auf das letzte Schreiben in den Framebuffer verzichtet, gibt es keinen Framebuffer mehr der das fertige Bild enthält. Für das Double Buffering braucht also jeder der 2 oder 4 Backbuffer seinen eigenen Frontbuffer, daher wird mehr RAM gebraucht.

Das ist nicht nur "reine Spekulation", hast du bessere Erklärungen anzubieten?

[Villa Riva]

Natürlich ist das Spekulation. Es ist völlig irrelevant, ob ich eine bessere Behauptung aufstelle oder nicht.

[aths]

Villa Riva,

wenn es gute Gründe gibt, eine Sache anzunehmen, ist es keine Spekulation mehr. Wenn man davon ausgeht, dass THG in diesem Punkt die Wahrheit sagt (der Artikel enstand in Zusammenarbeit mit Lars von Rivastation, welcher direkte Kontakte zu nVidia hat) dann liegt es nahe, dass die schon im Napalm verwendete Methode nun auch im NV25 einzug fand.

[ow]

@aths

wenn accuview im RAMDAC stattfindet (was ich nicht glaube), dann dürfte der Effekt auf Screenshots nicht zu sehen sein.

Oder:
Wie sehen denn Screenshots aus, wenn es (wie du spekulierst) keinen Frambuffer gibt, der das fertige Bild enthält?

[Xmas]

Ich glaube es ehrlich gesagt auch nicht, obwohl es eine denkbare Erklärung für diesen ominösen eingesparten Speicherzugriff ist. Allerdings wären Screenshots trotzdem möglich, wenn der Treiber beim auslesen aus dem Framebuffer automatisch das Filtern der Buffer veranlasst. Ging ja bei 3dfx auch...

[Edit: Nach ausführlicher Rechnung glaube ich nun doch eher, dass im RAMDAC gefiltert wird. ;)]

[Pengo]

3dgpu.com hat mal GF3 vs GF4 FSAA Screenshot gepostet und diese kurz darauf wieder rausgenommen. Ich hab bei Beyond3d gelesen daß der Grund war daß die Bilder auf dem Monitor mit den Screenshots nicht überein gestimmt haben.

[aths]

... und was sagt uns das, Pengo?

[Pengo]

Originally posted by aths
... und was sagt uns das, Pengo?

Daß es anscheinend über den RAMDAC geht.

[Villa Riva]

oder das 3dgpu zu doof istm Screenshots anzufertigen und korrekt zu beschriften.

[aths]

Ein weiteres Indiz für die RAMDAC-These :)

Ich sehe im Moment nur Punkte dir dafür sprechen, Villa Riva, und keinen der dagegen spricht. Auch wenn nVidia nichts offizielles verlauten lässt, lässt sich mit großer Sicherheit sagen, dass der NV25 hier eine Methode des VSA-100 verwendet.

[ow]

Kann mir jemand eine Quelle nennen, wie das beim VSA100 gemacht wird?

[Xmas]

http://www.hardware-one.com/reviews/gf2v5/downloads/SSAA-Analyzed.PDF

The front T-Buffers now contains the sub-samples of the scene we just rendered. The sub-samples now need to be combined to form the final anti-aliased image. This combining is done just before the RAMDAC by special video circuitry that mixes the various buffers together at the pixel level. [...]
The main advantage of this approach is that no down-sampled version of the image has to be stored and the color depth at the output level is higher than the color depth of an individual buffer.

[Legolas]

@ow

Einen Hinweis gibs hier:

http://www.3dconcept.ch/artikel/tbuffer/2.htm

Genaue Details hat 3dfx wohl nicht publik gemacht, aber der Bericht ist ja auch schon etwas älter. Ist aber auch nur eine Vermutung von ram.

edit

Da war Xmas wohl schneller und genauer :D

[Kennung Eins]

http://www.guru3d.com/-/20020221-03.jpg

[nggalai]

Hi Kennung Eins,

nur weil 2 Chips drauf sind heisst das noch lange nicht, dass da mit SLI gerendert wird. Sämtliche Unterlagen zum Thema Quadro4, welche ich auf dem Netz auftreiben konnte, sprechen von "mehr-chips-für-mehr-monitore," und nicht davon, dass die Rendering-Leistung verteilt werden soll. Wenn NV von wem abgekupfert hat, dann eher von Matrox als 3dfx. ;) Wenn Du andere Infos dazu hast, wäre das sehr interessant zu hören.

Du hattest ow was per PM geschickt, kannst Du das nicht auch hier posten? Wäre stark. :)

ta,
-Sascha.rb

Edit: gibt schon einen Thread dazu hier http://www.forum-3dcenter.org/vbulletin/showthread.php?s=&threadid=12416 .rb

[Quasar]

Ich hab mal ein paar Vergleiche gemacht (per Druck-Taste, was einem Framebuffer-Abgriff entspricht, oder?) sowohl in Quake3 als auch mit der IQ-Funktion vom 3DMark2000.

Ergebnis:
NoFSAA, 2xFSAA und Quincunx FSAA unterscheiden sich auf den Shots nicht.

4xFSAA und 4xS FSAA dagegen sehr wohl, hier kommt offenbar kein RAMDAC-Mixer zum Einsatz.

Wer die Bilder hosten möchte, sage Bescheid, hier Mini-Ausschnitte mit JPG40 reinzustellen hat wohl keinen Sinn.

[Quasar]

Ich habe mir mal ein paar Ausschnitte aus den Screenshots mittels schnellem Umschalten angesehen. Dafür habe ich die Shots aus 3DMArk2001 genommen, da man hier die Jaggies besser sieht und die Shots aus einer fixen Position aufgenommen werden.

Ich hatte den Eindruck, als wären die QC-FSAA und No-FSAA-Shots identisch, bis auf das das Framebuffer-Sample vom QC-Shot ein wenig verschoben aussah.

Das würde die RAMDAC-Theorie weiter unterstützen...oder?

[Kennung Eins]

Originally posted by nggalai
Hi Kennung Eins,

nur weil 2 Chips drauf sind heisst das noch lange nicht, dass da mit SLI gerendert wird. Sämtliche Unterlagen zum Thema Quadro4, welche ich auf dem Netz auftreiben konnte, sprechen von "mehr-chips-für-mehr-monitore," und nicht davon, dass die Rendering-Leistung verteilt werden soll. Wenn NV von wem abgekupfert hat, dann eher von Matrox als 3dfx. ;) Wenn Du andere Infos dazu hast, wäre das sehr interessant zu hören.

Du hattest ow was per PM geschickt, kannst Du das nicht auch hier posten? Wäre stark. :)

ta,
-Sascha.rb

Edit: gibt schon einen Thread dazu hier http://www.forum-3dcenter.org/vbulletin/showthread.php?s=&threadid=12416 .rb
Nein, leider darf ich das nicht, aber ich hab ihn ("die Quelle" ;) )dazu nochmal direkt gefragt, er meinte, er wüßte es selbst im Moment nicht.
Er hatte nur ein Quadro4 Sample zur Verfügung, welches sogar noch auf dem Quadro DCC Boarddesign beruhte (Also QuadroDCC videoboard + Quadro4 chip).
Eine Besonderheit war, daß neben der GPU noch viel Platz frei war für einen weiteren Chip + Platz für weiteren Speicher, die ganzen Kontakte waren schon aufgelötet, nur eben nicht GPU+Speicherchips.

Mehr kann / darf ich nicht sagen.

Das unterstützt sicherlich die These, daß es kein SLi sein wird, macht aber nix, denn bisher kann wohl wirklich nur NVidia sagen, was letztenendes daraus wird. Denn möglich ist SLI schon lange.

[ow]

Originally posted by nggalai
Hi Kennung Eins,

nur weil 2 Chips drauf sind heisst das noch lange nicht, dass da mit SLI gerendert wird. Sämtliche Unterlagen zum Thema Quadro4, welche ich auf dem Netz auftreiben konnte, sprechen von "mehr-chips-für-mehr-monitore," und nicht davon, dass die Rendering-Leistung verteilt werden soll. Wenn NV von wem abgekupfert hat, dann eher von Matrox als 3dfx. ;)
ta,
-Sascha.rb

Edit: gibt schon einen Thread dazu hier http://www.forum-3dcenter.org/vbulletin/showthread.php?s=&threadid=12416 .rb



Wenn ich nicht irre, dann beherrschen die "grossen" 3DLabs Boards (Oxygen GVX/Wildcat..) BEIDE Betriebsarten. Sowohl "SLI" als auch Mehrmonitor-Betrieb.