Geforce FX (NV30) TOP oder FLOP?

[nagus]

dieser thread hat noch gefehlt....


alle pro und kontra argumente und gedanken zum NV30 bitte hier rein.


DANKE!
mfg, nagus


... angesichts der verspätung tendiere ich persönlich eher zu FLOP (aber es gibt noch keine vernünftigen reviews... kann noch "umschalgen" ;)

[Exxtreme]

Ich tendiere eher zu TOP auch wenn es kein Überflieger-Chip sein wird wenn man die jetzigen Erkenntnisse nimmt.

[Quasar]

So, er fehlt (http://www.forum-3dcenter.org/vbulletin/showthread.php?s=&threadid=40837) also noch...
Was eher fehlt, ist ein Anruf bei der :cop: Troll-Polizei :cop:

[Ailuros]

...alle pro und kontra argumente und gedanken zum NV30 bitte hier rein.

Basierend auf was? Papier-Spezifikationen? Erst mal sehn (in real time dann bitte), dann Tee trinken.

Was ich sagen kann, ist dass NVIDIA nicht davon abscheuen wird Verluste vom NV30 einzuleiten so wie es aussieht, da sowieso die dicken Moneten im mainstream/budget Markt liegen. Schlimmstenfalls aendert sich die vorige 55-40% Relation zwischen NV und ATI zu 50-50 oder weniger fuer NV. Da verbrenne ich keine graue Zellen darueber.

Es ist schon komisch genug wie auf diversen boards toll getrommellt wurde dass NV30 kein richtiges DM in hardware beherrscht, und dabei letztendes herauskam dass R300 da auch nicht besser dasteht. Sandkasten-Material im besten Fall (nein um Gottes Willen nicht persoenlich gemeint); aber ich bin hoechstwahrscheinlich zu alt fuer solche Affaeren :)

[VoodooJack]

Meine Spekulation: das Topmodell (500/1000mhz) wird Top sein, leistungsmäßig und preismäßig.

[seahawk]

Hardware, die es nicht zu kaufen gibt, ist ein Flop.

Hardware, die nur per Paperlaunch angekündigt wird, ist ein Flop.

Hardware, die sogar bei den zugehörigen Demos abstürzt, ist ein Flop.

Hardware, die bei AA der Konkurenz unterlegen ist, ist ein Flop.

Hardware, die einen unerträglich lauten Kühler hat, ist ein Flop.


-> Allerdings weiß noch keiner ob das alles für den NV 30 stimmt. Daher kann man das imho erst nach den ersten Reviews entscheiden.

[tEd]

eigentlich alles was man wissen müsste um zu entscheiden ob es flop oder top wird fehlen noch.

ein paar gedanken trotzdem:

nur bis 8xAF -> find ich nicht gut
AF quality slider -> find ich gut
AA qualtät - speed -> muss sich noch zeigen
SS und MS mixed -> find ich gut , fand ich schon vorher gut(alpha texturen aliasing find ich scheisse)

[Hotzenplotz]

TOP

[Unregistered]

Originally posted by seahawk
Hardware, die es nicht zu kaufen gibt, ist ein Flop.

Hardware, die nur per Paperlaunch angekündigt wird, ist ein Flop.

Hardware, die sogar bei den zugehörigen Demos abstürzt, ist ein Flop.

Hardware, die bei AA der Konkurenz unterlegen ist, ist ein Flop.

Hardware, die eine unerträglich lauten Kühler hat, ist ein Flop.


-> Allerdings weiß noch keiner ob das alles für den NV 30 stimmt. Daher kann man das imho erst nach den ersten Reviews entscheiden.

da fehlt noch ein Argument

Hardware, die die Kartenhersteller bei der Präsentation auch zum ersten Mal sehen, ist ein Flop (oder zumindest extrem spät dran)


Ich selber habe mich noch nicht entschieden, tendiere aber zu einem Flop, weil selbst die Pixel-shader @500MHz anscheinend nur unwesentlich schneller sind als die Pixelshader der R300 @ 325MHz

GFfx : 500 x 2 16fp ops = 1000Mops (16bit floating Point)
R300 : 325 x 3 24fp ops = 975Mops (24bit floating Point)

schaut nach allem was ich so mitbekommen habe zumindest so aus.

[Demirug]

Originally posted by Unregistered
Ich selber habe mich noch nicht entschieden, tendiere aber zu einem Flop, weil selbst die Pixel-shader @500MHz anscheinend nur unwesentlich schneller sind als die Pixelshader der R300 @ 325MHz

GFfx : 500 x 2 16fp ops = 1000Mops (16bit floating Point)
R300 : 325 x 3 24fp ops = 975Mops (24bit floating Point)

schaut nach allem was ich so mitbekommen habe zumindest so aus.

Das stimmt so nicht ganz.

Der R300 kann gleichzeitig pro Pipeline:
eine Textur auslesen (tri linear)
eine Textur Addresse berechnen
eine Vector3 Operation (RGB-Farb-Wert)
eine Skalar Operation (Alpha-Wert)

Eine Presentation von ATI läst nun noch darauf schliessen das pro Pixelshaderbefehl 2 Takte benötigt werden weil man die Leistung mit 1200 M PS-Ops/s angibt aber 300 M*8 = 2400 M Operations Takte zur Verfügung stehen. Die Presentation ging noch von 300 MHz aus. Bei den 325 MHZ die am ende möglich waren ergeben sich also 1300 M PS-Ops/s

Vom NV30 wissen wir nur das 32 Pixel gleichzeit durch die Pixelpiplines laufen und die TMUs unabhängiger von den Pipelines geworden sind.

Es stehen also 32*500M = 16000 M Mathematische operationen pro Sekunde zur verfügung. Eine solche Operation entspricht aber sicher nicht einer PSOps sonder nur einem Teil. Es ist allerdings davon auszugehen das pro Takt eine PS-Op pro Pipeline ausgeführt werden kann (8*500M = 4000M Ops). Was allerdings noch nicht geklärt ist wäre:

Bei den PS ist es möglich auf den Vector (RGB) und den Skalar (A)unterschiedliche Operationen im gleichen Befehlsslot anzuwenden. Der R300 führt auch solche Operationen Parralel aus wie sich der NV30 verhält ist noch unbekannt.

Der R300 benutzt zum berechnen von Textur Addressen unabhängige Einheiten. Wo diese Aufgabe beim NV30 erledigt wird ist unbekannt.

Beim NV30 wird für das Auslesen eines Texturwerts wohl auch ein Befehlsslot in der Pixelpipline belegt. In wie fern beim R300 das Auslesen von Texturen rückwirkungen auf die Pixelpipline hat ist noch nicht vollständig geklärt.


Was allerdings auch noch erwähnt werden muss ist das der NV30 für die DX8 PS und die DX7 Pipeline immer noch über die vom NV25 bekannten Registercombinder verfügt. In wie weit diese nun mit der DX9 Pipeline identisch sind ist unbekannt. Sie könnten von dieser nachgebildet werden oder sogar noch als eigenständige Einheiten auf dem Chip verfügbar sein.

[Ailuros]

Hmmm wie waer's mal mit einem AA-Blindtest? (aths wird freundlichst gebeten mal den anderen das Raetsel zu hinterlassen).

Also welche Karte und welcher AA-Modus?

http://users.otenet.gr/~ailuros/Mystery1.jpg

http://users.otenet.gr/~ailuros/Mystery2.jpg

Gemein eh? :D

[Exxtreme]

Ich sage oben: R9700, unten: GF4.

Ich hoffe ich liege damit richtig.

[Scream]

Also ich weiß, ich werde bei meinem Tipp total falsch liegen, aber ich gebe ihn mal trotzdem ab:
oben: GeforceFX (könnte auch 3 oder 4 seinmit Treiberemulation) mit 6xS Anti-Aliasing
==> erzeugt kleine, na ja, wie soll ich sagen, Risse im Gitter
unten: GeforceFX (könnte auch 3 oder 4 sein mit Treiberemulation) mit 8x Anti-Aliasing

[Unregistered]

das sieht ja aus wie bei meiner geforce unten das
oben das ist einfach nur zu gut um wahr (bezahlbar/spielbar) zu sein

[zeckensack]

Ich war kurz davor zu sagen "beides R300, aber jeweils andere Gammaeinstellungen".

Unten hat's aber mindestens acht Subpixel, das ist entweder (seeehr unwahrscheinlich) eine Parhelia, oder etwas völlig anderes.
Könnte 8xS im Simulationsmodus sein.
Oder irgendwas neues von 3DLabs ...

[Iceman346]

Das unterscheidet sich beides nicht sonderlich von ner 9700Pro mit 6x AA. Zuordnen kann ichs nicht.

[Quasar]

Der Boden impliziert Supersampling....(oder du hast den REF genommen, in 2048 gerendert und runtergerechnet....?).
Edit:
Warum sind bei "Mystery2" eigentlich nur die linken Seiten des Röhrensystems richtig geglättet?

[-error-]

Originally posted by Unregistered
das sieht ja aus wie bei meiner geforce unten das
oben das ist einfach nur zu gut um wahr (bezahlbar/spielbar) zu sein

Sorry, aber ich sehe da keinen Unterchied!

[Liquaron]

Originally posted by Powerd by ATI


Sorry, aber ich sehe da keinen Unterchied!


jup ich auch net.


Ailuros kannste das Rätsel jetzt nicht mal auflösen?

[turboschlumpf]

wegen den 2 bildern, keine ahnung.

zu nv30:

derbe verspätung --> flop
erst gross klappe aufgerissen, jetzt doch nix besonderes --> flop
aa und af nur aufguss --> flop

3dfx techniker sollen am chip mitgearbeitet haben --> top
name anlehnung an 3dfx --> top
sonstige undefinierbare sachen die sich erst bei ausführlichen tests zeigen --> top

hrhrhr.

[Iceman346]

Originally posted by Quasar
Der Boden impliziert Supersampling....(oder du hast den REF genommen, in 2048 gerendert und runtergerechnet....?).

Der Boden sieht aus wie bei mir mit AF

[Ailuros]

Hoffentlich liest jeder jetzt seine Spekulationen nochmal durch. Theoretisch ist von Seiten EER ATI's 6xSGMS die qualitativ beste Loesung. Was aber fuer den normalen Durchschnitts-Verbraucher wichtig sein sollte ist ob er und wo Unterschiede zwischen Methoden entdecken kann und bis zu welchem Grad. Dass so manchen die Bilder identisch erschienen, imponiert mir nicht im geringsten.

Stellt Euch vor um wieviel besser Reviewer Reviews schreiben koennten, wenn sie nicht die geringste Ahnung haetten, um welche Karten es sich handelt ;)

Mystery1= GF4/8xS
Mystery2= R300/6xSGMS

Wer das tubesdemo auf seinem System ausprobieren will:

http://www.pvrdev.com/fE/DX7/D3DTubes_EXE.zip

Nur 283kb gross; uebrigens kann man sich mit der mouse im Raum frei bewegen, um auch andere Winkel zu untersuchen.

edit: typos

[VoodooJack]

Ich bin diesen Thread von vorn nach hinten durchgegangen. Es freut mich, dass mir Mystery2 "auf den ersten Blick" besser gefallen hat.

[betasilie]

Ich finde das Verhältnis zwischen Erscheinungsdatum und wahrscheinlichem Leistungsvorsprung garnicht gut! :-(

[Ailuros]

Originally posted by VoodooJack
Ich bin diesen Thread von vorn nach hinten durchgegangen. Es freut mich, dass mir Mystery2 "auf den ersten Blick" besser gefallen hat.

Es gibt bei beiden Methoden Stellen wo die eine besser aussieht als die andere. Nur muss man dann die Nase auf die Roehre kleben oder ein hoch-trainiertes Auge haben wenn es zu EER kommt.

Jemand koennte beide jpegs auf 500% aufblaehen und die Stellen wo's nicht so gut aussieht zum Vorschein bringen. Wie relevant jedoch so was zu real-time rendering ist im End-Effekt ist wohl eine ganz andere Affaere.

Zu Zeiten R200 vs NV20/5, war die ATI Argumentation zu Gunsten von Texturen Filterung Effizienz von Supersampling. Nun da es aussieht dass ATI momentan auf MSAA konzentriert und NV auf hybride MS/SS Loesungen (wobei der Supersampling Teil Vorsprung nimmt in Anzahl von samplen ueber 6xS), wird die Argumentation sich wieder in die andere Richtung drehen.

Der Unterschied ist ob jemand eine Methode bevorzugt fuer dass was sie gut ist, oder nur weil Firma X gerade dieselbe Methode als optimal vermarktet ;)

[Quasar]

Full ACK @ ailuros.

Nur werden das einige gar nicht gerne lesen....

[Ailuros]

Ich denke nicht dass es mich auch wirklich interessiert. Ich kauf mir meistens was zu jeder gegebenen Zeit das beste Preis/Performance Verhaeltnis darstellt und dabei ist mir der Name auf der Box vollkommen gleichgueltig.

Wuerde ich im Moment meine Graphikkarte aufruesten, wuerde ich mich sowieso nach einer 9500PRO oder einfachen 9700 (je nach Verfuegbarkeit und lokalen Preisen) umsehen.

Was FSAA betrifft, wuerde ich liebend gerne eine RGSS Implementation sehen, wobei der Algorithmus auf sattem 32-tap aniso Niveau Texturen filtert. Nur sind die Ansprueche was Fuellrate/Bandbreite betrifft, selbst heute noch viel zu hoch.

Daher ist mir dann eine MSAA/aniso Kombination auch lieber. NV's hybride Modi sehen gut aus, aber ich wuerde selbst dann noch mindestens 16-tap aniso hinzufuegen. Eine Szene zu ueberfiltern macht weniger Sinn, als beim vorigen Paragraph. ;)

[Ailuros]

OT: Hab ich jetzt erst bemerkt:

Doom3 wird ein Mix zwischen DirectX8 und DirectX9 sein.

....ach du liebe Zeit :D

[Quasar]

Jaja, der liebe Borsti ;D

Was AA/AF angeht, so ziehe ich generell erst einmal eine höhere Auflösung vor, das erhöht Textur- und Kantenqualität für mein optisches Empfinden am deutlichsten.
1600 mit einem 2xRGAA und dazu irgendwas in Richtung 4xAF (mehr sieht man bei den meisten Games eh nicht) sind momentan meine Ansprüche.

P/L-mäßig ist die R9500pro sicher nicht übel, auch die kleineren Schwächen des AF fallen in-game weniger auf, vor allem, wenn es keinen direkten Vergleich gibt. FSAA gibt's quasi umsonst dazu :) und ffür Preise um 230EUR kann man nicht meckern, imo.

[Xmas]

Originally posted by Ailuros
Es gibt bei beiden Methoden Stellen wo die eine besser aussieht als die andere. Nur muss man dann die Nase auf die Roehre kleben oder ein hoch-trainiertes Auge haben wenn es zu EER kommt.
Oder nen guten TFT haben ;)
Wenn man weiß worauf man achten muss kann man die Shots leicht identifizieren.
Beim ersten erkennt man am Boden das Supersampling, und die Kanten sind in alle Richtungen sehr glatt. Diese Kombination bietet zur Zeit nur 8xS.
Beim zweiten kann man erkennen dass es Gamma-korrigiert ist, und das bietet zur Zeit nur R300. Allerdings war ich mir nicht sicher ob es 4x oder 6x ist. Denn "dank" der Gamma-Korrektur sieht das zweite Bild auf meinem Monitor merklich schlechter aus als das erste, so seltsam das auch klingen mag. Außerdem scheinen ein paar Kanten "ausgefranst".

[Ailuros]

Was AA/AF angeht, so ziehe ich generell erst einmal eine höhere Auflösung vor, das erhöht Textur- und Kantenqualität für mein optisches Empfinden am deutlichsten.
1600 mit einem 2xRGAA und dazu irgendwas in Richtung 4xAF (mehr sieht man bei den meisten Games eh nicht) sind momentan meine Ansprüche.

Wer sagt dass mein oben erwaehntes Szenario dass ausschliessen wuerde? VGA's verbrauchen heutzutage einfach zu viele Transistoren fuer hoehere Programmierbarkeit, sonst waere es gar nicht unmoeglich ein bisschen mehr Hartware aufzuopfern.

PS:

Hab ich fast uebersehen:

P/L-mäßig ist die R9500pro sicher nicht übel, auch die kleineren Schwächen des AF fallen in-game weniger auf, vor allem, wenn es keinen direkten Vergleich gibt.

Na ja ich wuerde vielleicht die aniso-Winkel Schwaechen in meinen flight sims sehen, aber ich koennte damit leben. Was mich eigentlich mehr bei den R300-ern stoert ist dass man bei manchen Spielen mit aggressiven default LOD Anpassungen schlecht ueber texture aliasing hinwegkommt. Dafuer hat NV fuer optimale Faelle 4xS in D3D oder im schlimmsten Fall die Quincunx-Blur modi.

Trotz allem wenn ich alles durch den Durchschnitt rennen lasse, wuerde ich heute mindestens eine 9500PRO kaufen. Nichts ist perfekt letztenendes ;)

[Ailuros]

Originally posted by Xmas

Oder nen guten TFT haben ;)
Wenn man weiß worauf man achten muss kann man die Shots leicht identifizieren.
Beim ersten erkennt man am Boden das Supersampling, und die Kanten sind in alle Richtungen sehr glatt. Diese Kombination bietet zur Zeit nur 8xS.
Beim zweiten kann man erkennen dass es Gamma-korrigiert ist, und das bietet zur Zeit nur R300. Allerdings war ich mir nicht sicher ob es 4x oder 6x ist. Denn "dank" der Gamma-Korrektur sieht das zweite Bild auf meinem Monitor merklich schlechter aus als das erste, so seltsam das auch klingen mag. Außerdem scheinen ein paar Kanten "ausgefranst".

TFT? Igittigitt (wenn ich mir so 'n Ausdruck erlauben darf). TFT's sind meiner Meinung nach exzellente Loesungen fuer alles ausser 3D gaming ;)

Was die Screenshots betrifft, beim R300 shot kommen vielleicht auch ein paar Kompressions-fehler zu Tage. Ich haette png's verwenden koennen, aber dafuer hab ich nicht allzu viel upload space frei fuer ~900kb png's. Aechz sollte mal meinen Kram ein bisschen aufraeumen :rolleyes:

[Xmas]

Originally posted by Ailuros
TFT? Igittigitt (wenn ich mir so 'n Ausdruck erlauben darf). TFT's sind meiner Meinung nach exzellente Loesungen fuer alles ausser 3D gaming ;)

Was die Screenshots betrifft, beim R300 shot kommen vielleicht auch ein paar Kompressions-fehler zu Tage. Ich haette png's verwenden koennen, aber dafuer hab ich nicht allzu viel upload space frei fuer ~900kb png's. Aechz sollte mal meinen Kram ein bisschen aufraeumen :rolleyes:
Für Shooter vielleicht nur bedingt geeignet (auch wenn ich gern CS oder HLDM im LAN spiele), aber wenns um Sachen wie AoM geht... außerdem verbringe ich wenig Zeit am Rechner mit Spielen. Da ist ein TFT die perfekte Wahl.
PNG wäre besser gewesen, allerdings sind weder die ausgefransten Kanten noch die Gamma-Korrektur Kompressionsartefakte. Kann man die Gammakorrektur beim AA eigentlich auch regulieren?

[Pussycat]

Originally posted by Ailuros
Nun da es aussieht dass ATI momentan auf MSAA konzentriert und NV auf hybride MS/SS Loesungen (wobei der Supersampling Teil Vorsprung nimmt in Anzahl von samplen ueber 6xS), wird die Argumentation sich wieder in die andere Richtung drehen.


Ich frage mich ab NV dass freiwillig macht. In benches ist es nicht gut (da 4x gegen 4x gebencht wird, ob's jetzt 4xs, 4xMS oder 4xSS ist), und für die qualität (bei Kanten!!) die die derzeitigen 'skewed grid' verfahren auch nicht optimal (auch wenn's eher akademisch anfängt zu werden :) (ich fand übrigens gleich bild 2 besser))

Vielleicht haben die bei NV das neue Triangle setup nicht rechtzeitig hingekriegt und daher kein echtes RG eingeführt.

Oder man hat bewusst MS gewählt. Dann wäre aber immer noch ein MS grid mit teilweise MS besser gewesen.

Also: auf keinen Fall wars freiwillig. Aber warum ist es dann so, wie es ist?

[Pussycat]

Ich habe auch sehr viel spass mit meinem TFT. Vor allem da ich viel Zeit hier im Forum verschwende :)

[Ailuros]

Originally posted by Pussycat


Ich frage mich ab NV dass freiwillig macht. In benches ist es nicht gut (da 4x gegen 4x gebencht wird, ob's jetzt 4xs, 4xMS oder 4xSS ist), und für die qualität (bei Kanten!!) die die derzeitigen 'skewed grid' verfahren auch nicht optimal (auch wenn's eher akademisch anfängt zu werden :) (ich fand übrigens gleich bild 2 besser))

Vielleicht haben die bei NV das neue Triangle setup nicht rechtzeitig hingekriegt und daher kein echtes RG eingeführt.

Oder man hat bewusst MS gewählt. Dann wäre aber immer noch ein MS grid mit teilweise MS besser gewesen.

Also: auf keinen Fall wars freiwillig. Aber warum ist es dann so, wie es ist?

Transistoren Anzahl. Ein neuer Algorithmus als Accuview haette noch ein paar Transistoren gekostet.

Irgendwann im Sommer kamen die ersten komplett toten chip-samples von TSMC zurueck. Es war so schlecht dass ueberhaupt kein software darauf laufen wuerde, ergo 0% yields, wobei es bei allen graphikkarten mit .13um genauso war (bevor jetzt ATI fans wieder jubeln heh....)

So langsam bekamen sie Schnitt wie so etwa die R300 aussehehn wird und da ein 256 bit bus bei denen sicher war und NV30 durch .13 viel zu verspaetet wurden noch mal ein paar Millionen Transistoren draufgeschraubt um hoehere Taktfrequenzen gewinnen zu koennen. Daher bin ich mir auch fast sicher das eine Taktfrequenz fuer das high end Modell bei 500MHz schon gegeben ist.

Es war nicht so dass ein anderer Algorithmus je geplant war, aber Transistoren-Anzahl war meiner Meinung nach der Grund.

Uebrigens hab ich nie verborgen dass ich ein TBR fan bin, obwohl ich nicht immer in der Vergangenheit auf verfuegbare Tiler zugegriffen habe. Wenn ich mich nicht irre ist es bei Dir auch nicht anders hm? Wie hoert es sich an wenn ich Dir sagen wuerde dass Simon Fenney (ach nur der Herr der Algorithmen bei PowerVR entwickelt *cough*) erst vorige Woche bei B3D angegeben hat, dass Ihm ordered grid weniger stoerende Resultate gibt im Labor?

Auf jeden Fall ich hab 8xS auf ner GF4 und 6x sparsely sampled auf ner R300 in F1 2002 und FS 2002 ausprobiert. Dreimal darfst Du raten welche Methode mir bessere Resultate - alle Aspekte mitinberechnet - gegeben hat. Glatte Ecken sind ja toll aber nicht wenn der Rest der Szene konstant flimmert, und das kann Dir kein Screenshot zeigen. FSAA muss man in real-time sehen.

Uebrigens:

http://users.otenet.gr/~ailuros/8xS.jpg

[zeckensack]

Originally posted by Ailuros
Auf jeden Fall ich hab 8xS auf ner GF4 und 6x sparsely sampled auf ner R300 in F1 2002 und FS 2002 ausprobiert. Dreimal darfst Du raten welche Methode mir bessere Resultate - alle Aspekte mitinberechnet - gegeben hat. Glatte Ecken sind ja toll aber nicht wenn der Rest der Szene konstant flimmert, und das kann Dir kein Screenshot zeigen. FSAA muss man in real-time sehen.Ich würde das Problem an anderer Stelle suchen ...

Eine texturierte Szene flimmert nicht, solange man nicht irgendwelche exotischen ('kaputt' wäre das richtigere Wort) Projektionsmatrizen benutzt, oder am LOD-Bias rumstellt.

Das ist so in Stein gemeißelt und gesichert, und zwar in Form der Rasterization Rules für sowohl OpenGL als auch D3D. Die drei Seiten die dafür draufgehen sind nicht umsonst geschrieben worden.

Womit wir bei der Frage ankommen, warum machen die Leute sowas? Warum muß ein Spiel den LOD-Bias senken? IMO ganz klar ein Problem in der art section. Wenn die Texturen dort überfiltert werden und man dann mit dem Bias nachregeln muß, um überhaupt Schärfe ins Bild zu kriegen, dann ist das einfach keine praktikable Lösung. Man verschwendet unnütz Bandbreite (Texelfetch) und kriegt eben dieses scheiß Flimmern, wenn man nicht genau aufpaßt.

Kommt in den besten Familien vor, UT2k3 ist AFAIR auch betroffen (Daniel hat leider darauf nicht mehr geantwortet).

PS: Ich bin schon mindestens seit dem Gf4Ti-Launch eher ein Multisampling+AF-Verfechter, und das hat nun wirklich nichts mit meiner aktuellen Graka zu tun (R200 :naughty: ). Die Technik ist einfach in der Summe (IMO) die elegantere.
PPS: Supersampling hat auch Schwächen (nicht-skalierbare 2D-Elemente wie Schrift, HUDs uä).

[Ailuros]

Uhhhm zeckensack,

Ich wuerde erwarten dass hier jemand notiert, dass ATI's Karten bei default aggressivere LOD Anpassungen hat, als andere IHV's.

Texture aliasing ist nun mal da in mehr als nur einem Spiel, und dabei ist leider die beste Loesung immer noch Supersampling, selbst wenn nur Bruchteile davon in einer hybriden Methode vorhanden sind.

Obwohl ich zustimme dass eine MS/AF Kombination im Moment das beste fuer heute ist, hab ich immer noch in racing/flight sims (wo jede Form von anti-aliasing auch wichtiger ist) mindestens einen Schnitt von SS mit MS/AF lieber. Bei mir ist in D3D Spielen 4xS mit 32-tap AF so gut wie festgemauert in Rivatuner ;)

Was UT2003 betrifft, LOD ist aggressiver in openGL wie in D3D. Warum, na da lass ich es lieber D.Vogel beantworten (wenn er kann).

Supersampling hat auch Schwächen (nicht-skalierbare 2D-Elemente wie Schrift, HUDs uä).

Das gilt fuer jede Methode. NV haette ein bisschen mehr Platz opfern sollen um RG auch mit 4x samplen zu erlauben. Alternative waere auch RG mit dem SS Teil. 4xS mit 2xRGMS + 2xRGSS waere um so einiges besser (oder sparsely sampled immer noch besser). Aber man kann nie alles haben.

[ow]

Originally posted by Ailuros
Uhhhm zeckensack,

Ich wuerde erwarten dass hier jemand notiert, dass ATI's Karten bei default aggressivere LOD Anpassungen hat, als andere IHV's.



???

Also bei ATi, NV und PVR liegt der Default lod-bias exakt dort, wo er zu liegen hat. Kann man mit dem 3DWinbench2000 ueberpruefen.

Die einzige mir bekannte Karte, die beim lodbias voellig versagt ist die Savage2000. Dort liegt der lodbias in Richtung 'Schaerfe' derart daneben, dass in allen Anwendungen sehr starkes Texturalising auftritt. Der korrekte Null-Level liegt fuer den S2k bei mipmap-lodbias +1 (mit Xmas' Aniso-Tester nachgewiesen).

[aths]

Originally posted by Ailuros
(wobei der Supersampling Teil Vorsprung nimmt in Anzahl von samplen ueber 6xS), wird die Argumentation sich wieder in die andere Richtung drehen.Bereits ab 6xS ist der SS-Anteil höher als der MS-Anteil. Wobei ich 6xS ziemlich unsinnig finde, weil dieser Modus gewisse Artefakte produziert.

[zeckensack]

Originally posted by ow
???

Also bei ATi, NV und PVR liegt der Default lod-bias exakt dort, wo er zu liegen hat. Kann man mit dem 3DWinbench2000 ueberpruefen.Danke, ow. Ich war schon kurz davor dafür noch'n Testprogramm zu schreiben :)

@Ailuros:
Die Radeon 8500 hat soweit ich das beurteilen kann die unrühmliche Fähigkeit zu Mipmap dithering anstatt trilinearem Filter. Je nach Treiberversion sieht's deshalb manchmal etwas komisch aus. Ich kann dir aber versichern daß der aktuelle offizielle Treiber 6200c korrekt trilinear filtert (zumindest unter OGL), was zugegebermaßen nicht immer so war. Onkel Nyquist wäre zufrieden.

(AF nutze ich auf der Karte übrigens überhaupt nicht)

[Ailuros]

@aths,

Korrekt. Es haette so aussehen sollen: =/> 6xS. Ich versuche hart mit meinem verrosteten Deutsch mitzuhalten, was nicht unbedingt immer leicht ist.

@zeckensack

Genau das gleiche gilt hier auch wie oben (mit der Sprach-Barriere). Wie jeder weiss LOD=level of detail, aber nicht unbedingt LOD bias mipmap adjustments.

Da ow PVR erwaehnt hat: bei KYRO ist LOD in openGL "festgenagelt" (ausser man bricht den OGL Treiber auf...), aber in D3D ist LOD modifizierbar durch die Registry. Was Ihr meint waere bei PVR dann MIPmapThreshold (wobei 1-10; 5=0; 1= konservativ; 10=aggressiv). Aber es gibt auch DAdjust (wobei 10-1/descending values; 10=konservativ; 1=aggressiv). Ich halte mich zurueck um in Kleinigkeiten damit zu gehen, aber vielleicht erinnert sich jemand an die Comanche4 shots beim R300 launch; wobei eine endlose Debatte bei B3D enstand warum die NV25 so verwaschen aussieht im Gegenteil zur R300. Ich postete damals einen 4xS screenshot, aber wenige kamen darauf dass Supersampling normalerweise auch mit einem -0.5 LOD offset kommt.

Als ich mir die R300 ausgeleiht hatte (mit C2.2 Treibern), war in SS:SE texture aliasing ein bisschen zu extrem. Die Loesung war Filtering method/effect filtering method zu maximum und Texture LOD bias mindestens zwei Stufen nach links (zu blur). Ob es nun mit Treiber Versionen variiert, ob es an den Spielen liegt oder was immer auch ist mir gleichgueltig. Was mir wichtiger ist, ist wie jede Szene aussieht und wie ich stoerende Seiten-Effekte ueberwaeltigen kann.

An anderes (zugegeben schlechtes) Beispiel waere NFS:PU. Soweit ich weiss benutzte der Developer dummerweise einen LOD offset auf manchen Strassen Texturen (nicht in allen tracks) von -3.0. Ob nun normal oder abnormal wer Lust hat kann einen screenshot vom Spiel posten (ohne Supersampling natuerlich ;) ), und ausser dass sich in 2.3 oder 2.4 Sachen so grandios geaendert haben, bezweifle ich dass ich so viel road texture aliasing nicht mal mit einem D3D mipmap offset von -3.0 bekomme.

[zeckensack]

SeSam habe ich auf der R200 auch mal kurz durchgespielt ... aufgefallen ist mir eigentlich nichts. War irgendwann im August AFAIR.
Wobei ich mich natürlich schon gewundert habe, wozu da ein Regler für den Mipmap-Bias drin ist :|

Aber eigentlich ging es mir auch nicht um die Radeon, sondern allgemein darum daß Texturflimmern normalerweise* ein Softwareproblem ist. Mit Supersampling kann man das natürlich schön bekämpfen. Vielleicht sollte man aber auch mal die Entwickler aufklären, wie Texturfilter überhaupt funktionieren, und wofür sie ursprünglich mal erfunden wurden ...

Das kann doch wohl nicht wahr sein, daß tatsächlich Spiele verkauft werden wo Texturen mit einem bias von -3 (!!) unterfiltert werden :bonk:

*wenn sich die IHVs an die Specs halten

[Ailuros]

Das kann doch wohl nicht wahr sein, daß tatsächlich Spiele verkauft werden wo Texturen mit einem bias von -3 (!!) unterfiltert werden.

NFS PU wurde damals auf einer Voodoo entwickelt. Nicht nur hatten Voodoos mehr konservative LOD Einstellungen, sondern gingen nicht ueber -2.0 hinaus soweit ich weiss. Der Herr der das Spiel entwickelt hat, hat wohl mit -3.0 herumgespielt, fand dass es keinen Unterschied macht und liess es so bleiben.

Es gibt schlimmeres von Electronic Arts LOL. Du haettest F1 2001 sehen sollen. So verkorktes mipmapping und eine engine die dummerweise zu viele Texturen zu allokieren versucht ist kein Spiel mehr sondern ein Alptraum.

Aber eigentlich ging es mir auch nicht um die Radeon, sondern allgemein darum daß Texturflimmern normalerweise* ein Softwareproblem ist. Mit Supersampling kann man das natürlich schön bekämpfen. Vielleicht sollte man aber auch mal die Entwickler aufklären, wie Texturfilter überhaupt funktionieren, und wofür sie ursprünglich mal erfunden wurden ...

Ist es auch. Und das war auch genau mein Punkt. SSAA stand als Not-Loesung bei vermotzten Spielen zur Verfuegung, was laut Launch-Kampagne bei der R300 auch da sein sollte. Das oder einen 100% operativen LOD slider fuer beide API's der sich auf jede Applikation aufzwingen kann. Uebrigens hat sich dass Treiberteam bei ATI nach der R100 gigantisch aufgeputzt. ATI hat momentan NV den Teppich regelrecht unter den Fuessen weggezogen.

Tut uns Verbrauchern auch gut. NV ist schon seit 2000 viel zu selbstsicher gewesen. ;)

[zeckensack]

Originally posted by Ailuros
NFS PU wurde damals auf einer Voodoo entwickelt. Nicht nur hatten Voodoos mehr konservative LOD Einstellungen, sondern gingen nicht ueber -2.0 hinaus soweit ich weiss. Der Herr der das Spiel entwickelt hat, hat wohl mit -3.0 herumgespielt, fand dass es keinen Unterschied macht und liess es so bleiben.Also in meinen streng geheimen Unterlagen ( :naughty: ) steht daß die Vooodoo 1 mipmap biases zwischen -8 und 7.75 in 0.25er Schritten beherrscht.

Und natürlich wird auch dort ausdrücklich vor negativem bias gewarnt.

Es gibt schlimmeres von Electronic Arts LOL. Du haettest F1 2001 sehen sollen. So verkorktes mipmapping und eine engine die dummerweise zu viele Texturen zu allokieren versucht ist kein Spiel mehr sondern ein Alptraum.Nee danke, das will ich garnicht sehen :D

Ist es auch. Und das war auch genau mein Punkt. SSAA stand als Not-Loesung bei vermotzten Spielen zur Verfuegung, was laut Launch-Kampagne bei der R300 auch da sein sollte. Das oder einen 100% operativen LOD slider fuer beide API's der sich auf jede Applikation aufzwingen kann.Tja, dann waren wir uns wohl doch die ganze Zeit einig :)
Es wäre mir schon lieber wenn die Spiele funktionieren würden, aber zur Not einen lod slider zu haben ... hmmm!
Kann nicht schaden.
Uebrigens hat sich dass Treiberteam bei ATI nach der R100 gigantisch aufgeputzt. ATI hat momentan NV den Teppich regelrecht unter den Fuessen weggezogen.

Tut uns Verbrauchern auch gut. NV ist schon seit 2000 viel zu selbstsicher gewesen. ;) Ist das wirklich so?
Ich habe nur bemerkt, daß auf einmal haufenweise Leute auf R300ern entwickeln (ogl-Forum). Aber der Devsupport könnte IMO wirklich besser sein. Nicht daß einem bei Fragen nicht geholfen wird, das schon. Aber wenn man sich NV's Seite so anschaut und was man dort alles an Codefetzen, Demos und Whitepapers kriegen kann ... dagegen sieht ATI's Seite richtig erbärmlich aus :|

[Exxtreme]

Originally posted by zeckensack

Ich habe nur bemerkt, daß auf einmal haufenweise Leute auf R300ern entwickeln (ogl-Forum). Aber der Devsupport könnte IMO wirklich besser sein. Nicht daß einem bei Fragen nicht geholfen wird, das schon.
Halte ich für ein Gerücht. Frag mal nach wie man HierarchicaZ oder HyperZ abschaltet.
;)

Zum HierarchicalZ habe keine Antwort bekommen aber zum HyperZ sagte Herr Chiang, daß es nicht abschaltbar ist. Ausserdem unterstützt ATi keine "third party tweaker" und sie werden mir dazu keine anderen Fragen beantworten.

Danke ATi. :P

[Demirug]

Originally posted by Exxtreme

Halte ich für ein Gerücht. Frag mal nach wie man HierarchicaZ oder HyperZ abschaltet.
;)

Zum HierarchicalZ habe keine Antwort bekommen aber zum HyperZ sagte Herr Chiang, daß es nicht abschaltbar ist. Ausserdem unterstützt ATi keine "third party tweaker" und sie werden mir dazu keine anderen Fragen beantworten.

Danke ATi. :P

Exxtreme, das versteht man ja auch im Allgemeinen nicht unter Devsupport. Dabei geht es dann eher darum den Leuten zu erklären wie diese oder jene OpenGL Erweiterung funktioniert. Oder wie man die optimale Performances aus der Karte holt.

[ow]

Originally posted by Demirug


Exxtreme, das versteht man ja auch im Allgemeinen nicht unter Devsupport. Dabei geht es dann eher darum den Leuten zu erklären wie diese oder jene OpenGL Erweiterung funktioniert. Oder wie man die optimale Performances aus der Karte holt.


Das schon, aber dennoch sollte sich bei ATi niemand zu schade sein, auch einfache Fragen nach Reg-Keys etc. zu beantworten.


@Exxtreme

Ich vermute, dass dieselben Keys wie auf der Radeon1 benutzt werden (wie es bei HW T&L wohl auch der Fall ist). Die da heissen IIRC:

"DisableHierachicalZ" (0/1)
"EnableFastZClear" (0/1)
"DisableHyperZ" (0/1)

[Exxtreme]

Originally posted by Demirug
Exxtreme, das versteht man ja auch im Allgemeinen nicht unter Devsupport. Dabei geht es dann eher darum den Leuten zu erklären wie diese oder jene OpenGL Erweiterung funktioniert. Oder wie man die optimale Performances aus der Karte holt.
Das Problem ist, daß sich die Typen bei ATi das rTool angeschaut haben und mir Unterstützung angeboten haben. Und dann fragt man nach ein Paar Registry-Werten und dann passiert sowas. Sicherlich ist der Support eher auf die Programmierung von 3D-Anwendungen/Spielen ausgerichtet aber das hätte man vorher sagen können. Am besten hätten die mich gar nicht als Developer aufgenommen dann wüsste ich woran ich bin.

[Exxtreme]

Originally posted by ow




Das schon, aber dennoch sollte sich bei ATi niemand zu schade sein, auch einfache Fragen nach Reg-Keys etc. zu beantworten.

Eben.
Originally posted by ow
@Exxtreme

Ich vermute, dass dieselben Keys wie auf der Radeon1 benutzt werden (wie es bei HW T&L wohl auch der Fall ist). Die da heissen IIRC:

"DisableHierachicalZ" (0/1)
"EnableFastZClear" (0/1)
"DisableHyperZ" (0/1)
Nein, das stimmt leider nicht. Die Keys sind nicht identisch. Ich habe diese ausgetestet. :)
HyperZ lässt sich nicht komplett abschalten, nur das HierarchicalZ. Und dies erreicht man durch den String "HierarchicalZEnable". Hex-Editor r00l3z. Ich habe es ausprobiert mit Villagemark und die Performance geht von 175 fps auf 154 fps runter. Es gibt noch andere interessante Sachen im Treiber. Wenn ich dazu komme, dann poste ich es heute abend.

[Demirug]

Originally posted by Exxtreme

Das Problem ist, daß sich die Typen bei ATi das rTool angeschaut haben und mir Unterstützung angeboten haben. Und dann fragt man noch ein Paar Registry-Werten und dann passiert sowas. Sicherlich ist der Support eher auf die Programmierung von 3D-Anwendungen/Spielen ausgerichtet aber das hätte man vorher sagen können. Am besten hätten die mich gar nicht als Developer aufgenommen dann wüsste ich woran ich bin.

OK wenn sie dir explizit Unterstüzung für das rTool angeboten haben ist das dann wirklich eine schwache Leistung wenn man dir dann wenn du wirklich mal was wissen möchtest nicht helfen will.

[Ailuros]

Also in meinen streng geheimen Unterlagen ( ) steht daß die Vooodoo 1 mipmap biases zwischen -8 und 7.75 in 0.25er Schritten beherrscht.

Und natürlich wird auch dort ausdrücklich vor negativem bias gewarnt.

Ich meinte eher was in den letzten Treibern zu finden war. Fruehe V5 Treiber hatten so hohe (ich glaube es war -8/+8) LOD Werte in den Treibern, was dann spaeter von -2/+2 ersetzt wurde.

3dfx hatte schon immer komische Methoden Sachen auszurechnen. Bin mir zwar nicht mehr sicher aber ich glaube die haben eine Zeit Texel Fuellrate mit Anzahl von Texturen/pass wenn MT multipliziert.

Ist das wirklich so?
Ich habe nur bemerkt, daß auf einmal haufenweise Leute auf R300ern entwickeln (ogl-Forum). Aber der Devsupport könnte IMO wirklich besser sein. Nicht daß einem bei Fragen nicht geholfen wird, das schon. Aber wenn man sich NV's Seite so anschaut und was man dort alles an Codefetzen, Demos und Whitepapers kriegen kann ... dagegen sieht ATI's Seite richtig erbärmlich aus.

Es kann ja nicht alles von einem Tag auf den anderen passieren. R100 war eine unendliche Schnecke mit allem anderen ausser win9x OS's. Developer-support (was Probleme mit Spielen betrifft) war in Sachen "response time" noch Meilenweit entfernt, zu dem Punkt wo sie heute sind.

Uebrigens bei einer Grafikkarte wo es staendig an etwas hapert, muss es nicht unbedingt und immer an Treibern liegen. Manchmal kann ein potentielles Treiber-team fuer viel schlimmere Missgeschicke aufdecken.

Derek Smart hat ja ATI dick rund um's Netz angegriffen. Nur leider hat er meiner Meinung nach viel zu viel und dazu noch das falsche Team angegriffen.

[ow]

Originally posted by Ailuros


Ich meinte eher was in den letzten Treibern zu finden war. Fruehe V5 Treiber hatten so hohe (ich glaube es war -8/+8) LOD Werte in den Treibern, was dann spaeter von -2/+2 ersetzt wurde.




Die haben AFAIK nur die Skalierung der Anzeige im Controlpanel geaendert, die Reg-Werte bleiben die gleichen.

Also aus -8,8 haben die im Panel -2,2 gemacht ohne das sich sonst irgendwas geaendert haette.

[Ailuros]

Hmmmm so hab ich's auch gemeint :D

[Chris Lux]

aehm ich moecht noch zum eigentlichen thema was sagen:

damals war ich scharf wie ratte auf ne voodoo3, welche auch gross angepriesen wurde und hab mir dann aber eine tnt2 gekauft, weil die imo damals einfach die bessere karte war. irgendwie kommt mir das zZ grad genauso vor. ich freu mich wie sau auf die gfFX (~voodoo3) aber es zieht so leise ein neuer stern auf (R300-350) wie damals die TNT und TNT2.... hoffentlich sind die ati treiber dann auch auf nvidia nivau wenn man sich entscheiden muss.

[Ailuros]

Technisch genommen (in Ansicht Komplianz und Programmierungs-Faehigkeiten) sieht es eher aus als ob NV30 den Vorsprung hat. Selbst wenn man theoretisch R300 und NV30 auf die gleiche Schwelle stellt, ist der V3 vs TNT Vergleich total irrelevant.

16bpp und 256x256 Texturen? Also bitte......

[Quasar]

Originally posted by Ailuros
16bpp und 256x256 Texturen? Also bitte......
96Bit und 2048x2048 Texturen vs.
128Bit und 16384x16384 Texturen: ;) ;) ;)

[Pussycat]

Originally posted by Ailuros
16bpp und 256x256 Texturen?

Wenn's in Spielen eh keine größere Texturen gab und 32 bit zu langsam war (22-bit Filter aber sehr brauchbar), kein Problem. Meine GF2 benutze ich nur in 16 bit, und ein 22-bit Filter wäre mich da sehr gerne gewesen.

Also bitte......

....Dankeschön!

[Thowe]

Originally posted by Ailuros


Mystery1= GF4/8xS
Mystery2= R300/6xSGMS



Jupp, hätte ich gewusst - da ich es kenne ;)

Aber mal ehrlich, wer kein TFT hat und einen relativ billigen Monitor, der sieht wirklich kaum einen Unterschied. Wobei ich zugeben muss das gerade der höhere "Schärfegrad" den die GF FX bieten wird vielleicht doch noch mich reizen wird sie zu kaufen. Naja, bis zur PowerVR Serie5, da erwarte ich besseres AA/AF.

[Thowe]

Ach ja, zur Frage ob die GF FX TOP oder FLOP wird.

*thumbsup* -> TOP

Die Geschwindigkeit ist vermutlich nicht überragend, aber sie ist ein nettes "Spielzeug" und kombiniert mit hoffentlich keinen Hardware oder Treiberfehler wird sie durchaus zu Recht genügend Käufer finden.

[Ailuros]

Originally posted by Pussycat


Wenn's in Spielen eh keine größere Texturen gab und 32 bit zu langsam war (22-bit Filter aber sehr brauchbar), kein Problem. Meine GF2 benutze ich nur in 16 bit, und ein 22-bit Filter wäre mich da sehr gerne gewesen.



....Dankeschön!

Wenn Du meinen vorige Argumentation nochmal durchliest dann verstehst Du vielleicht dass der Vergleich zwischen V3/TNT und R300/NV30 wenig gemeinsam hat.

Damals (1999 - Gott ist das schon lange her :D ) hatte ich auch ne V3 3000; das hielt mich auch damals nicht ab der Wahrheit ins Auge zu sehen.

Uebrigens wann genau wurde der S3TC pack in UT brauchbar gemacht, und wann nochmal erschien q3a?

[Rampage 2]

Originally posted by tEd

AF quality slider -> find ich gut

Toll, wirklich beeindruckend :bonk:

[Unregistered]

Originally posted by Ailuros
Uebrigens wann genau wurde der S3TC pack in UT brauchbar gemacht, und wann nochmal erschien q3a?

Wenn ich ehrlich bin, habe ich echt keine Ahnung. Hatte damals auch noch kein internet.

[3dfx Voodoo5 5500]

Originally posted by Ailuros

Uebrigens wann genau wurde der S3TC pack in UT brauchbar gemacht, und wann nochmal erschien q3a?


ersteres mitte 2000 und q3 erschien glaube ich ende 1999.

hoffe habe das noch richtig im kopf. :)

[Ailuros]

Originally posted by Wolfsheim1983



ersteres mitte 2000 und q3 erschien glaube ich ende 1999.

hoffe habe das noch richtig im kopf. :)

Beide Spiele waren die groessten Erfolge zur Zeit auf dem Markt; beide unterstuetzen 32bpp und beide groessere Texturen als 256x256. Darum ging es ja eigentlich.

[[fu]121Ah]

UT lief auf einer v3 mit 22bit wohl einiges schöner als auf ner gayforce mit 32bit. zum ersten, q3 ist da was anderes, stimmt...

[ow]

Originally posted by [fu]121Ah
UT lief auf einer v3 mit 22bit wohl einiges schöner als auf ner gayforce mit 32bit.


Kann gar nicht sein.
Wieso soll 16Bit und verwaschene Texturen besser aussehen als 32Bit und hoch aufgeloeste Texturen?

[FormatC]

Originally posted by ow
Kann gar nicht sein.
Wieso soll 16Bit und verwaschene Texturen besser aussehen als 32Bit und hoch aufgeloeste Texturen?

Durch Optimierung seitens UT auf Voodoos.

Edit: Die hochaufgelösten UT Texturen standen doch nur Savage2000 Karten per Metal API zur Verfügung, oder?

[ow]

D3D und OGL unter Unreal/UT sind sicher nicht Voodoo-optimiert, das ist ja nur Glide.

Ich glaube, dass UT auch standardmaessig schon Texturen ueber 256*256 nutzt. Weiss da jemand was genaues (ich kann ja auch irren)?

Die hochaufgeloesten Texturen sind komprimierte Texturen und zunaechst nur fuer S3 Metal verfuegbar, das ist richtig.

[FormatC]

Ja, Glide meinte ich ja auch mit Optimierung. :)

[Salvee]

Originally posted by ow
Weiss da jemand was genaues (ich kann ja auch irren)?


Sogar im Ur-Unreal gab es einzelne grössere Texturen (512x512), der Engel (?) mit den 4 'Boobs' beispielsweise ;)

[aths]

Originally posted by ow
Kann gar nicht sein.
Wieso soll 16Bit und verwaschene Texturen besser aussehen als 32Bit und hoch aufgeloeste Texturen? Ist aber so: Die Texturen sahen teilweise besser aus in Glide als in 32 bpp D3D! (Z.B. Weltraum-Hintergrund-Objekte bei CTF_Faces.)

16 Bit D3D war dann noch deutlich schlechter als Glide.

[zeckensack]

Einfache Erklärung:
Der Glide-Renderer spielt an der Gamma-Einstellung, OGL/D3D nicht (das hat damals, als U1 aktuell war sowieso auf keiner Karte funktioniert ...).

Alleine dadurch ergibt sich schonmal ein großes Qualitätsplus, weil plötzlich Textursampling, Blending und alles andere in einem linearen Farbraum ablaufen.

[Ailuros]

Zwischen 16bit D3D und 22bit post-gefiltertes Glide, sah das letztere schon besser aus, aber nur bis zu diesem Punkt.

Epic verdankt vieles Herrm Vogel; damals war es mehr oder weniger ein Witz fuer uns dass Epic Daniel endlich professionell angagieren sollte. Na der Witz wurde wahr :D

Uebrigens soweit ich weiss ist Glide eigentlich nicht auf 256x256 beschraenkt, nur das was 3dfx veroeffentlichte. Ich glaube das es maximal bis zu 2048x2048 Texturen faehig war.

Alleine dadurch ergibt sich schonmal ein großes Qualitätsplus, weil plötzlich Textursampling, Blending und alles andere in einem linearen Farbraum ablaufen.

3dfx hatte generell komische Gamma Einstellungen, wobei es vieleicht beim oberen noch mehr geholfen hat. Um ehrlich zu sein, hab ich bis jetzt nicht eine einzige Karte besessen wo ich nicht Gamma (2D/3D) kalbriert habe.

zeckensack,

Hmmm ein glide emulator hm? Hab ich gerade erst bemerkt. Werde ich gleich mal ausprobieren aus purer Neugierde.

edit: blah nur fuer Radeons :-( Dafuer hab ich einen paar andere Emulatoren ausprobiert; ich hatte total vergessen wie crapalicious Spiele ohne AA/aniso aussehen... :pukes:

[FormatC]

Originally posted by Ailuros
Uebrigens soweit ich weiss ist Glide eigentlich nicht auf 256x256 beschraenkt, nur das was 3dfx veroeffentlichte. Ich glaube das es maximal bis zu 2048x2048 Texturen faehig war.


Möglich. Jedenfalls waren die Voodoos bis zur Nr.3 auf 256² Texturen beschränkt :)

[aths]

Originally posted by zeckensack
Einfache Erklärung:
Der Glide-Renderer spielt an der Gamma-Einstellung, OGL/D3D nicht (das hat damals, als U1 aktuell war sowieso auf keiner Karte funktioniert ...).

Alleine dadurch ergibt sich schonmal ein großes Qualitätsplus, weil plötzlich Textursampling, Blending und alles andere in einem linearen Farbraum ablaufen. (Zurückdenk...) Das könnte in der Tat dafür verantwortlich sein. Danke, zecki!

[aths]

Originally posted by FormatC
Möglich. Jedenfalls waren die Voodoos bis zur Nr.3 auf 256² Texturen beschränkt :) Schon für Banshee gabs von Creative Labs Treiber, welche auch 512² ermöglichten :D (Wie auch immer sie das realisiert haben...)

[FormatC]

Originally posted by aths
Schon für Banshee gabs von Creative Labs Treiber, welche auch 512² ermöglichten :D (Wie auch immer sie das realisiert haben...)

Ich habe (vor Äonen ;)) gelesen das die Textur zum Zeichnen irgendwie in 256er Stückchen zerteilt wurde.
Aber von eigentlichen technischen Hintergrund habe ich keine Ahnung.

[StefanV]

Originally posted by FormatC


Möglich. Jedenfalls waren die Voodoos bis zur Nr.3 auf 256² Texturen beschränkt :)

Nope, das ist so nicht ganz richtig!

Die Hardware konnte maximal 256² Texturen, die Treiber können durchaus größere Texturen in 256² häppchen zerlegen...

Ich hab mal Haarmann ein paar Q3 Shots von meiner V3 mit WGL geschossen, er meinte, daß der WGL die größeren Texturen zerlegt...

[ow]

Originally posted by Stefan Payne


Nope, das ist so nicht ganz richtig!

Die Hardware konnte maximal 256² Texturen, die Treiber können durchaus größere Texturen in 256² häppchen zerlegen...

Ich hab mal Haarmann ein paar Q3 Shots von meiner V3 mit WGL geschossen, er meinte, daß der WGL die größeren Texturen zerlegt...

Das ist so schon richtig. Die Voodoos bis zur V3 können nur 256² in Hardware. Irgendwelche Treiberfrickeleien zählen da nicht.

[StefanV]

Originally posted by ow


Das ist so schon richtig. Die Voodoos bis zur V3 können nur 256² in Hardware. Irgendwelche Treiberfrickeleien zählen da nicht.

1. hab ich was anderes gesagt??

2. wichtig ist, was hinten rauskommt, wie das geschiet ist egal, die V3 kann mit entsprechenden Treibern (Wicked GL) Texturen, die größer als 256² sind korrekt ausgeben.
Wie das in Treiber geschiet ist letztendlich egal...

[ow]

jo, SP. Also kann jede Graka Texturen bis ....sagen wir 128k², muss ja nur im Treiber drin sein.:bonk:

wieso bist du eigentlich so sicher, dass das Treiberverfahren immer korrekt funktioniert? Und wieso gab´s das nicht von 3dfx, sondern nur in nem Creative Treiber?

[Demirug]

Originally posted by ow
jo, SP. Also kann jede Graka Texturen bis ....sagen wir 128k², muss ja nur im Treiber drin sein.:bonk:

wieso bist du eigentlich so sicher, dass das Treiberverfahren immer korrekt funktioniert? Und wieso gab´s das nicht von 3dfx, sondern nur in nem Creative Treiber?

Ganz einfach weil Creative ein Patent für diese Technik hat: US-Patennummer: 6,437,791

[FormatC]

Originally posted by Stefan Payne
2. wichtig ist, was hinten rauskommt, wie das geschiet ist egal, die V3 kann mit entsprechenden Treibern (Wicked GL) Texturen, die größer als 256² sind korrekt ausgeben.


Vielleicht habe ich es einfach übersehen, weil recht wenig 512² Texturen in Quake III Arena gibt, aber ich konnte keine Verbesserung der Bildqualität durch den WickedGL Treiber, auf meiner Voodoo3 feststellen.

Hat mich enttäuscht, da ich gehofft hatte das der es irgendwie packt. :)
Kann aber auch sein, das ichs einfach nicht gemerkt habe. Ich war damals nicht annähernd so versiert wie heute, was 3D Spiele angeht.

[ow]

Originally posted by Demirug


Ganz einfach weil Creative ein Patent für diese Technik hat: US-Patennummer: 6,437,791

AH ja.:) Hab´s mal kurz überflogen. Was ist denn davon in der Praxis zu halten? Und lohnt der Aufwand? Ich meine....selbst ein S3Virge hat schon 512² Texturen verarbeitet.:D

[Demirug]

Originally posted by ow


AH ja.:) Hab´s mal kurz überflogen. Was ist denn davon in der Praxis zu halten? Und lohnt der Aufwand? Ich meine....selbst ein S3Virge hat schon 512² Texturen verarbeitet.:D

Im Detail kenne ich das Patent auch nicht. Es bassiert aber einfach auf dem Prinzip der Dreieckszerlegung. Mit mehr als 2 Texturkoordinaten pro Vertex ist das ganze sowieso für die Tonne. Ansonsten erkauft man sich die bessere Texturauflösung durch reine CPU-Leistung (für das zerlegen) und die Tatsache das am Ende ein wesentlich grössere Polycount zur Karte geschickt werden muss.

Irgendwie erinnert mich das stark an TruForm in Treiber. Softwareemulation von Features damit die Featureliste die man angeben kann länger wird.

[zeckensack]

Trivialpatente find' ich scheiße :P

[aths]

Originally posted by ow
Das ist so schon richtig. Die Voodoos bis zur V3 können nur 256² in Hardware. Irgendwelche Treiberfrickeleien zählen da nicht. Wichtig ist, was hinten rauskommt.

Voodoo4/5 haben auf Wunsch "HW T&L" nach DX7-Spezifikation, GeForce4 MX hat DX8 "Vertex Shader 1.1"... alles durch den Treiber.

[Demirug]

Originally posted by aths
Wichtig ist, was hinten rauskommt.

Voodoo4/5 haben auf Wunsch "HW T&L" nach DX7-Spezifikation, GeForce4 MX hat DX8 "Vertex Shader 1.1"... alles durch den Treiber.

Ja wobei es bei der GF4MX ja wohl keine reine Treibersache ist. Angeblich können bestimmte Teile eines Shader doch von der Hardware beschleuningt werden..

[aths]

Originally posted by Demirug
Ja wobei es bei der GF4MX ja wohl keine reine Treibersache ist. Angeblich können bestimmte Teile eines Shader doch von der Hardware beschleuningt werden.. nVidia redet da allerdings so sehr um den heißen Brei, dass ich ziemlich sicher bin, dass die MX genau DX7 HW T&L hat.

[Demirug]

Originally posted by aths
nVidia redet da allerdings so sehr um den heißen Brei, dass ich ziemlich sicher bin, dass die MX genau DX7 HW T&L hat.

Es wird eine minimal aufgeborte DX7 HW T&L sein. Bei NVIDIA war ja schon das DX7 HW T&L (wenn man den patenten glauben darf) eine Art Vertex Shader. Dieser ist nur nicht ganz so flexibel wie der welcher ab den NV20 zum Einsatz kamm.

[ow]

Originally posted by aths
Wichtig ist, was hinten rauskommt.

Voodoo4/5 haben auf Wunsch "HW T&L" nach DX7-Spezifikation, GeForce4 MX hat DX8 "Vertex Shader 1.1"... alles durch den Treiber.


Willst du jetzt auch drüber diskutieren, was welche HW kann und was welche SW kann?

->

Softwareemulation von Features damit die Featureliste die man angeben kann länger wird.


Mehr als Kundenverarsche bleibt also nicht übrig.

[aths]

Originally posted by ow
Willst du jetzt auch drüber diskutieren, was welche HW kann und was welche SW kann? Ich kaufe doch das Produkt, dass sich da zusammensetzt aus Verpackung, Karte, Handbuch und - Treiber.

[aths]

Originally posted by Demirug
Es wird eine minimal aufgeborte DX7 HW T&L sein. Bei NVIDIA war ja schon das DX7 HW T&L (wenn man den patenten glauben darf) eine Art Vertex Shader. Dieser ist nur nicht ganz so flexibel wie der welcher ab den NV20 zum Einsatz kamm. Meine Frage wäre, inwiefern sowas den VS "helfen" kann. Eine Emulation wird doch vollständig von der CPU ausgeführt? Man wird wohl kaum Daten zur Karte senden und diese wieder zurückschicken, damit die CPU Sachen macht, welche die T&L der MX nicht beherrscht. Wo wäre die Möglichkeit gegeben, dass die T&L einen Vertex Shader unterstützt?

[Demirug]

Originally posted by aths
Meine Frage wäre, inwiefern sowas den VS "helfen" kann. Eine Emulation wird doch vollständig von der CPU ausgeführt? Man wird wohl kaum Daten zur Karte senden und diese wieder zurückschicken, damit die CPU Sachen macht, welche die T&L der MX nicht beherrscht. Wo wäre die Möglichkeit gegeben, dass die T&L einen Vertex Shader unterstützt?

Dabei wird nichts wieder zurückgeschickt denn das wäre echt unsinng.

Wie gesagt ist (zumindestens bei NVIDIA) die "Fixed" T&L auch programmierbar also sowas wie VS 0.x. Wird nun ein VS an D3D übergeben kann der Treiber prüfen ob die möglichkeiten der Karte ausreichen um in komplett dort auszuführen. Falls ja wird das entsprechende Mircoprogramm erzeugt und für die spätere Verwendung gespeichert. Ist es nicht möglich den shader komplett durch die Karte abarbeiten zu lassen hat der Treiber noch die option Teile davon in der Karte laufen zu lassen. Diese Teile müssen allerdings in der Verarbeitung am ende kommen. Soll heisen das kein nicht auf der Karte ausführbarer teil auf ergebnisse von auslagerbaren Teilen angewisen sein darf. Ein gutes Beispiel wäre eine Vektor-Matrix Muliplikation um die Position des Vertex zu bestimmen. Wird die Position direkt auf das Outputregister übertragen kann man diese Operation auf der Karte durchführen. Der Treiber muss da natürlich abwägen ob es sich lohnt oder nicht.