Wann gibts endlich Overdraw-freie Games? [Archiv]

Neomi

2006-06-14, 16:18:31

Auf Overdraw würdest du nicht wirklich verzichten wollen, wenn Transparenz im Spiel ist. Aber gehen wir mal von den nichttransparenten Teilen der Szene aus...

Wenn man durch ein Lock in einer Wand einen Teil eines größeren Dreiecks sieht, was glaubst du ist effizienter? Das Dreieck rendern und den Z-Buffer die einzelnen Pixel prüfen lassen, ist die gängige Methode. Willst du den Overdraw komplett eliminieren, müßtest du aus dem Loch eine 2D-Kontur erzeugen, das Dreieck mit dieser Kontur zu einem Vieleck beschneiden und das wahrscheinlich nichtmal konvexe Vieleck neu triangulieren, all das per CPU natürlich. Und da du eine pro Frame neu geschnittene Geometrie ncht statisch im Speicher der Karte halten kannst, muß die Geometrie ständig über den Bus wandern, in dem Fall würde PCIe 16x im Endresultat doppelt so schnell sein wie PCIe 8x. Nein, nicht wirklich, denn die CPU kann nicht annähernd schnell genug neu geschnittene Dreiecke liefern. Du hättest zwar keinen Overdraw mehr und köntest dadurch den Z-Buffer sparen, aber die Performance sinkt ins bodenlose. Das ist es nicht, was du willst. Da also keine Dreiecke geschnitten werden sollen, ist schonmal zwangsweise ein wenig Overdraw vorhanden. Was also, wenn man alle Dreiecke verwirft, die gar nicht zu sehen sind? Ein Teil eines Dreiecks kann auch dann zu sehen sein, wenn weder eine Ecke noch ein Teil einer Kante sichtbar ist. Es läuft also darauf hinaus, arithmetisch zu schneiden und zu schauen, ob etwas übrigbleibt. Die Performance ist also wieder unterirdisch.

Was übrig bleibt, sind Methoden, um grob die potentielle Sichtbarkeit von Objekten zu prüfen. Potentiell deshalb, weil ein Objekt auch geschickt verdeckt werden kann, ohne seine Bounding Box komplett zu verdecken (es sei denn, das Objekt ist eine Box). Bei bestimmten CPU-basierter Prüfung muß auch die überdeckende Geometrie vereinfacht werden, ein dünner Pfosten würde dann wegen geringer Erfolgsaussichten erst gar nichts zu verdecken versuchen. GPU-basierte Methoden gibt es auch (Occlusion Queries), aber die haben ebenfalls Nachteile. Und was kommt z.B. in einem CPU-limitierten Spiel dabei raus? Richtig, eine niedrigere Geschwindigkeit. Sogar bei den GPU-basierten Methoden, da es auch da einen gewissen CPU-Overhead gibt. Die Performance wäre zwar nicht annähernd so schlecht wie bei vollkommener Vermeidung von Overdraw, aber sie kann dennoch leiden. Solche Sachen lohnen sich nur bei grafiklimitierten Sachen oder dann, wenn die Prüfung weniger Zeit benötigt, als nachher an Overhead für nicht erfolgte Drawcalls gespart wird.

Abgesehen davon kostet Overdraw nicht so viel Leistung, wie du vielleicht glaubst. Early-Z funktioniert ganz gut, Vertexshader und Triangle Setup sind keine wirklichen Flaschenhälse. Wenn man von vorne nach hinten zeichnet (oder eine Z-Pass vorschaltet), gewinnt man sogar Geschwindigkeit, da keine komplexen Beleuchtungsoperationen für hinterher eh überschriebene Pixel ausgeführt werden. Und könnten Timedemos schneller sein als das eigentliche Spiel, wenn die Grafikkarte limitiert? Bei gleicher Grafik, aber eben anderer CPU-Last? Nein, nicht wirklich. Manchmal ist stupides zeichnen besser. Während der schlaue Algorithmus noch überlegt, ob das Objekt gezeichnet werden muß, ist der "dumme" Algorithmus schon viel weiter. Hängt natürlich vom Einzelfall ab.

Gast

2006-06-14, 17:08:57

Grad bei 3D-RPGs ist Overdraw aber daran schuld, daß die Performance bei einer 180-Drehung von 40 auf 10 fps einbricht. U9 lief dagegen auf der Kyro konstant mit 30fps. Nur weiß doch jeder, daß diese heute nicht mehr verwendet wird, aber die Devs schieben das Problem auf die Graka-Entwickler. Die werden natürlich auch einen Teufel tun, dies Problem zu beheben. Und so haben alle was davon, bis auf den User natürlich. Der Vorteil "offener PC" ist wieder mal Hauptnachteil zu Konsole

Frage: Ist das so schwer, mal ne Anti-Overdraw-Library zu entwickeln, das das noch nie gemacht wurde.

Neomi

2006-06-14, 17:24:04

Gast[/POST]']Frage: Ist das so schwer, mal ne Anti-Overdraw-Library zu entwickeln, das das noch nie gemacht wurde.

Klar gibt es da einige Techniken für, wie kommst du auf "noch nie gemacht"? Aber man kann natürlich keinen IMR zu einem TBDR machen, egal was man programmiert.

2006-06-14, 18:37:05

was ist overdraw?

Neomi

2006-06-14, 18:41:41

3d[/POST]']was ist overdraw?

Overdraw bedeutet frei übersetzt Überzeichnen (nein, keine Karikatur). Objekte (oder Landschaftsteile, was auch immer) werden gezeichnet, später aber von anderen Dingen überdeckt. Die Arbeit, die in die Darstellung der nicht sichtbaren Dinge fließt, ist quasi verschenkt.

PS: diese Frage in Kombination mit deinem Nick und deiner Postingzahl in diesem Forum verwundert mich schon sehr.

Knötchen

2006-06-14, 20:51:34

Und was ist der / die / das IMR und der / die / das TBDR?

tokugawa

2006-06-14, 20:52:39

Gast[/POST]']
Frage: Ist das so schwer, mal ne Anti-Overdraw-Library zu entwickeln, das das noch nie gemacht wurde.

Eine allgemeine Anti-Overdraw-Library wird nie gehen, da das meistens tief in die Grafik-Engine eingreift, und daher immer an die Grafikengine angepasst werden muß.

Aber natürlich gibt es in der Forschung und auch in echten Grafik-Engines bereits Algorithmen, die gegen Overdraw ankämpfen. Ein Beispiel dafür ist das auf unserem Institut entwickelte Coherent Hierarchical Culling (CHC), das geschickt die Latenzen von GPU Occlusion Queries versteckt (sh. GPU Gems 2). Erfordert im Prinzip nur eine hierarchisch-spatiale Szenestruktur, die im Prinzip jede Engine hat, und ist ein Visibility-Algorithmus, der auch und speziell mit dynamischen (beweglichen) Objekten/Geometrien gut funktioniert (was etwa bei Portals nicht der Fall ist).

CHC ist außerdem Teil des Gametools-Projekts (www.gametools.org), das diese Algorithmen in den Engines Ogre (OpenSource-Engine) und Shark3D (kommerzielle Multiplattform-Engine, wird z.B. in Dreamfall verwendet) integrieren will und teilweise bereits getan hat, sowie Industrie-Partnern aus der Spieleindustrie (inklusive sogenannten "Serious Games" wie etwa Simulatoren zu Trainingszwecken) zur Verfügung stellen will.

Also, hier kann man nicht sagen dass sich hier nichts tut - man muß nur in die aktuelle Forschung in der Echtzeitgrafik schauen (was viele Spiele-Entwickler auch tun).

2006-06-14, 23:23:19

PS: diese Frage in Kombination mit deinem Nick und deiner Postingzahl in diesem Forum verwundert mich schon sehr
ja, ist mir auch etwas peinlich.
hab das alles schonmal gehört aber es gibt ja so viel davon.
ich hab mit der materie auch nicht so viel zu tun.
bin nur amateur (aber großer 3d fan)
gibt ja leider keinen, der das ganze thema mal auf deutsch zusammenfasst und etwas erklärt.

=Floi=

2006-06-18, 12:19:09

ist es praktisch nicht günstiger wenn die ganzen objekte vorher schon mitgerechnet werden auch wenn es zB noch hinter einer ecke ist?
da ja spätestens wenn ich um die ecke komme das objekt sichtbar wird und dann zB die CPU das ebjekt erstellen muß

die D3 engine macht das doch selbst so wenn ich mich nicht irre (was nicht sichtbar ist wird weggelassen) und da sind ja leider auch die laderuckler beim türenäffnen bekannt

auch sehe ich da eher probleme mit shadern und duchsichtigen objekten @ kyro(2)

tokugawa

2006-06-18, 16:45:56

=Floi=[/POST]']ist es praktisch nicht günstiger wenn die ganzen objekte vorher schon mitgerechnet werden auch wenn es zB noch hinter einer ecke ist?
da ja spätestens wenn ich um die ecke komme das objekt sichtbar wird und dann zB die CPU das ebjekt erstellen muß

"Geladen", also im Speicher vorhanden, ist es sowieso schon. Es geht hier nicht darum dass ein Objekt erst geladen wird wenn es sichtbar ist.

Bei Overdraw geht es um das tatsächliche Zeichnen. Ein Objekt das nicht sichtbar ist, sollte auch nicht gezeichnet werden. Die Regel lautet "das am schnellsten gerenderte Objekt ist das, was man gar nicht rendern muß".

=Floi=[/POST]']
die D3 engine macht das doch selbst so wenn ich mich nicht irre (was nicht sichtbar ist wird weggelassen) und da sind ja leider auch die laderuckler beim türenäffnen bekannt

Das hat mich auch schon gewundert, aber vom "Laden" reden wir hier gar nicht.

=Floi=[/POST]']
auch sehe ich da eher probleme mit shadern und duchsichtigen objekten @ kyro(2)

Ja, transparente Objekte muß man natürlich bei einem Sichtbarkeits-Algorithmus berücksichtigen.

Haarmann

2006-06-19, 08:51:21

Overdraw zu vermeiden braucht recht viel Hirn und Zeit. GPUs werden aber zZ noch so schnell leistungsfähiger, dass man damit leben kann.

Schon diese wahnwitzigen Polygonzahlen sollte man mal genauer ansehen. Wer 1 mio Polygone pro Bild möchte, der wird feststellen, dass bei 1280*1024 das einzelne Polygon nur mehr knapp mehr denn nen Pixel bedeckt im Schnitt. Da stimmt ja dann auch irgendwas nicht mehr. Subpixelpolygone und Texturen sind ja dann nicht wirklich das Ziel.

Matrox hat versucht hier nen Anstoss zu geben, aber Niemand hat den Ball angenommen - schade.

tokugawa

2006-06-19, 13:27:48

SavageX

2006-06-19, 13:46:18

Overdraw sollte heutzutage keine grosse Rolle spielen. Fixed function interessiert keinen mehr (oder dürfte auf die programmierbaren Shader abgebildet werden) - und die Pixelshader berechnen dank early z verdeckte Pixel sowieso (grösstenteils) nicht.

Oder erzähl ich hier bulls**t?

tokugawa

2006-06-19, 15:15:14

SavageX[/POST]']Overdraw sollte heutzutage keine grosse Rolle spielen. Fixed function interessiert keinen mehr (oder dürfte auf die programmierbaren Shader abgebildet werden) - und die Pixelshader berechnen dank early z verdeckte Pixel sowieso (grösstenteils) nicht.

Oder erzähl ich hier bulls**t?

Also: Early-Z greift nur in sehr speziellen Fällen (z.b. darf man im Pixelshader nicht in die Depth schreiben).

Zweitens hat Overdraw prinzipiell nichts damit zu tun, weil man im schlechtesten Fall quasi von "hinten" nach "vorn" rendert, womit selbst bei aktivem Early Z alles gerendert wird, was nachher wieder überdeckt wird.

Falls man sowieso mehrere Szenepasses machen muß, kann man aber mittels Depth-First-Pass (vorrendern von Depth-Only, und beibehalten des aufgebauten Z-Buffers) optimieren. Ob das was in der Praxis bringt, ist allerdings sehr szeneabhängig.

Jedenfalls ist Overdraw auch heute noch - je nach Szene - vorhanden.

SavageX

2006-06-19, 15:24:40

tokugawa[/POST]']Also: Early-Z greift nur in sehr speziellen Fällen (z.b. darf man im Pixelshader nicht in die Depth schreiben).

Zweitens hat Overdraw prinzipiell nichts damit zu tun, weil man im schlechtesten Fall quasi von "hinten" nach "vorn" rendert, womit selbst bei aktivem Early Z alles gerendert wird, was nachher wieder überdeckt wird.

Falls man sowieso mehrere Szenepasses machen muß, kann man aber mittels Depth-First-Pass (vorrendern von Depth-Only, und beibehalten des aufgebauten Z-Buffers) optimieren. Ob das was in der Praxis bringt, ist allerdings sehr szeneabhängig.

Jedenfalls ist Overdraw auch heute noch - je nach Szene - vorhanden.

Ah, vielen Dank für diese Berichtigung.

fluxxxor

2006-06-19, 15:45:50

wenn man liest, das der overdraw bei 2,5 liegt, kann man wohl nicht von 'vernachlässigenswert' reden. im endeffekt nur 40% wirkungsgrad

Xmas

2006-06-19, 23:52:35

Haarmann[/POST]']Schon diese wahnwitzigen Polygonzahlen sollte man mal genauer ansehen. Wer 1 mio Polygone pro Bild möchte, der wird feststellen, dass bei 1280*1024 das einzelne Polygon nur mehr knapp mehr denn nen Pixel bedeckt im Schnitt. Da stimmt ja dann auch irgendwas nicht mehr. Subpixelpolygone und Texturen sind ja dann nicht wirklich das Ziel.
In der Regel sind solche Angaben ja auch nicht auf das sichtbare Bild begrenzt, sondern beinhalten alles was zum Rendern an die Grafikkarte übergeben wurde. Davon sind dann durchaus schon mal 80% gar nicht im fertigen Bild zu sehen (außerhalb des Sichtbereichs, backfacing, von anderen Objekten verdeckt oder einfach nur zu klein um einen Pixel zu belegen)

Matrox hat versucht hier nen Anstoss zu geben, aber Niemand hat den Ball angenommen - schade.
Matrox hat allerdings nie so recht demonstriert wie effizient ihre dynamische Tessellation denn wirklich ist. Es ist ja nicht so als ob es keine Geometrie-LOD-Algorithmen im Einsatz gäbe.

tokugawa[/POST]']Also: Early-Z greift nur in sehr speziellen Fällen (z.b. darf man im Pixelshader nicht in die Depth schreiben).
Diese "sehr speziellen" Fälle sind aber die deutlich am meisten vorkommenden. ;)

tokugawa

2006-06-20, 00:38:03

Xmas[/POST]']
Diese "sehr speziellen" Fälle sind aber die deutlich am meisten vorkommenden. ;)

Ja, ich muß zugeben dass ich hier ein bisserl meine eigene Arbeit hernehme für die Beurteilung als "sehr speziell". Bei den Sachen die ich mache/gemacht hab hat Early-Z nur sehr selten geholfen (entweder es war nicht aktiv weil ich einen kranken Shader geschrieben hab, oder wenn es aktiv war hat es nicht wahnsinnig viel Performance gebracht). In der (Spiele-)Praxis mag das anders aussehen, auch weil man da sicher auch daraufhinarbeitet dass Early-Z greift. Ist aber sowieso alles ziemlich Szene-abhängig.

Monger

2006-06-20, 08:21:53

fluxxxor[/POST]']wenn man liest, das der overdraw bei 2,5 liegt, kann man wohl nicht von 'vernachlässigenswert' reden. im endeffekt nur 40% wirkungsgrad

Ist das denn der Flaschenhals bei einer Grafikkarte? Ich glaube nicht! ;)

Modulor

2006-06-20, 10:06:33

Xmas[/POST]']In der Regel sind solche Angaben ja auch nicht auf das sichtbare Bild begrenzt, sondern beinhalten alles was zum Rendern an die Grafikkarte übergeben wurde. Davon sind dann durchaus schon mal 80% gar nicht im fertigen Bild zu sehen (außerhalb des Sichtbereichs, backfacing, von anderen Objekten verdeckt oder einfach nur zu klein um einen Pixel zu belegen)

Dazu habe ich vor ein paar Jahren ein schönes Bespiel gefunden:
Mit Einzug der als "Slipstream" bezeichneten Overdraw reduzierenden Funktion des P9 auf der als Consumerkarte beworbenen Creative Labs Graphics Blaster Picture Perfect konnte man den Treiber über einen Eintrag in der Registry anweisen den Overdraw durch Einfärbung sichtbar zu machen. Als schönes Beispiel dafür fand ich No One Lives Forever 2. Kate Archer steht vor einem grossen Holztor das eine freie Sicht auf das dahinterliegende Dorf komplett verwehrt,als Spieler sieht man also wirklich nur das Holztor.

http://tilebase.de/reviews/VP560/pix/NOLF2_gate_normal_small.jpg
Um so erstaunter war ich als ich sah was die VP760 (links) ohne Slipstream gegenüber der VP560 (rechts) mit P9 auf dem Bildschirm ausgibt:

http://tilebase.de/reviews/VP560/pix/NOLF2_Gate_VP760_small.gif http://tilebase.de/reviews/VP560/pix/OverdrawLevel.gif http://tilebase.de/reviews/VP560/pix/NOLF2_Gate_VP560_small.gif

Das ganze hatte jedoch nur mit D3D funktioniert und da war die VP560 bis 800x600 der von den Rohdaten her weitaus leistungsstärkeren VP760 überlegen.
Natürlich ist weder Funktion noch Ausstattung oder Leistung der VPs heute noch maßgebend aber imho zeigen diese beiden Chips im direkten Vergleich tendenziell was heute mit einem DR möglich wäre...

Gast

2006-06-20, 13:37:58

am boden ein overdraw von 2 erscheint mir ehrlich gesagt nicht wirklich realistisch, oder wird hier einfach irgendwas multipass gemacht?

Modulor

2006-06-20, 14:55:10

Gast[/POST]']am boden ein overdraw von 2 erscheint mir ehrlich gesagt nicht wirklich realistisch, oder wird hier einfach irgendwas multipass gemacht?

Ich glaube das ist bei der Szene nicht nötig gewesen,der Boden im Vordergrund scheint wirklich nur aus einer Textur zu bestehen...
Du kannst dir das ganze mal in Originalauflösung 1024x768 angucken (alle Bilder mit Mouseover Effekt :naughty: ) :

VP760 ohne Slipstream (http://tilebase.de/reviews/VP560/NOLF2_Gate_VP760.html)
VP560 mit Slipstream (http://tilebase.de/reviews/VP560/NOLF2_Gate_VP560.html)

StefanV

2006-06-20, 14:58:36

@Modulor
Und der Himmel? ;)

Modulor

2006-06-20, 15:08:06

StefanV[/POST]']@Modulor
Und der Himmel? ;)

Ach ja - der ist blau :biggrin:

Gast

2006-06-20, 18:01:07

Das komische Overdraw-Removement von 3DLabs sieht einfach so aus als würde man über nen hierarchischen Z-Buffer gleich ganze Polygone raushauen. Das macht ATI auch - nix neues.

Zum Thema: Nie.

Modulor

2006-06-20, 18:25:24

Gast[/POST]']Das komische Overdraw-Removement von 3DLabs sieht einfach so aus als würde man über nen hierarchischen Z-Buffer gleich ganze Polygone raushauen. Das macht ATI auch - nix neues.
...

Natürlich nicht,darum ging es mir ja auch gar nicht. Es trägt zum Thema bei da man damit (afaik) erstmals sehen kann was man nicht sieht und somit die gleiche Frage wie der Threadtitel aufwirft: Warum wird der Polygon"müll" hinter dem Tor überhaupt an die Karte geliefert ? Und ich kann mich nicht daran erinnern daß die Lithtech Engine bei den Kritikern durchgefallen wäre...
Die Programmierer wissen heute daß es effektive Mechanismen in den Grafichips gibt die die Arbeit für sie erledigen - warum sollen sie sich also die Mühe machen das im Vorfeld gleich durch die Engine erledigen zu lassen ? Zeit und Geld gespart - das geben ATI und NVIDIA - und somit auch der Kunde - dafür um so reichlicher aus...

StefanV

2006-06-20, 19:45:50

Modulor[/POST]']Ach ja - der ist blau :biggrin:
Sicher, das der nicht im Hintergrund gerendert wird? ;)

loewe

2006-06-20, 19:54:24

@Modulor

Da läßt sich heute mit Portalen wie bei Doom3 usw. sicher was machen, sprich man muss nicht alles rendern was hinter einer Wand liegt, braucht aber entsprechenden Softwareaufwand.

Zum Thema

Jagt doch alle eure GPUs mal über dieses kleine Programm von Humus: GL_Extreme (http://www.humus.ca/index.php?page=3D&ID=3)

Wenn eure Hier-Z, Early-Z gut sind, erreichen sie etwa solche Ergebnisse:

Overdraw/HSR:
-------------
Overdraw factor 3, back to front: 353.97 fps
Overdraw factor 3, front to back: 354.03 fps
Overdraw factor 3, random order: 351.35 fps

Overdraw factor 8, back to front: 306.03 fps
Overdraw factor 8, front to back: 305.61 fps
Overdraw factor 8, random order: 305.80 fps

Wobei es mir nicht auf die fps sondern auf die Konstanz der FPS ankommt. ;)

Es gibt keine gleichmäßige Verteilung von Overdraw in einer Szene, aber damit eine Szene realistisch aussieht muss es Bereiche mit großem Overdraw geben, da dort eine Häufung von Gegenständen vorhanden ist.
Vergleicht doch mal eure Zimmer bzw. Häuser mit denen aus Spielen, ich denke ein Overdraw von 5 - 10 in der Realität ist nicht übertrieben und das allein in einem Raum, Portale schon voraus gesetzt.

Mastermind

2006-06-20, 20:05:16

loewe[/POST]']@Modulor

Da läßt sich heute mit Portalen wie bei Doom3 usw. sicher was machen, sprich man muss nicht alles rendern was hinter einer Wand liegt, braucht aber entsprechenden Softwareaufwand.

Zum Thema

Jagt doch alle eure GPUs mal über dieses kleine Programm von Humus: GL_Extreme (http://www.humus.ca/index.php?page=3D&ID=3)

Wenn eure Hier-Z, Early-Z gut sind, erreichen sie etwa solche Ergebnisse:

Overdraw/HSR:
-------------
Overdraw factor 3, back to front: 353.97 fps
Overdraw factor 3, front to back: 354.03 fps
Overdraw factor 3, random order: 351.35 fps

Overdraw factor 8, back to front: 306.03 fps
Overdraw factor 8, front to back: 305.61 fps
Overdraw factor 8, random order: 305.80 fps

Wobei es mir nicht auf die fps sondern auf die Konstanz der FPS ankommt. ;)

Es gibt keine gleichmäßige Verteilung von Overdraw in einer Szene, aber damit eine Szene realistisch aussieht muss es Bereiche mit großem Overdraw geben, da dort eine Häufung von Gegenständen vorhanden ist.
Vergleicht doch mal eure Zimmer bzw. Häuser mit denen aus Spielen, ich denke ein Overdraw von 5 - 10 in der Realität ist nicht übertrieben und das allein in einem Raum, Portale schon voraus gesetzt.
Ich lass hier mal die Hosen runter, damit keiner meinen Fehler wiederholt. Und zwar hab ich vergessen, dass ich per Treiber VSync erzwingen lasse. Dementsprechend konstant waren auch die FPS. :biggrin:

Xmas

2006-06-21, 00:29:08

Eine Reihe von Beiträgen wurde hier entfernt. Das Technologieforum ist für ernsthafte Diskussionen gedacht, Herumstänkern gehört dazu nicht.

StefanV[/POST]']Sicher, das der nicht im Hintergrund gerendert wird? ;)
Mir ist nicht ganz klar was du damit sagen willst.

StefanV

2006-06-21, 00:41:02

Xmas[/POST]']
Mir ist nicht ganz klar was du damit sagen willst.
Naja, ich wundere mich ein wenig arg drüber das der Boden keinen Overdrawfaktor von 1 hat sondern 2 :|

Die einzige Erklärung, die ich dafür hab, ist, dass der Boden überm Himmel liegt, denn nur die Bereiche, wo nur Himmel zu sehen ist, haben den Faktor 1.

Mastermind

2006-06-21, 01:52:35

StefanV[/POST]']Naja, ich wundere mich ein wenig arg drüber das der Boden keinen Overdrawfaktor von 1 hat sondern 2 :|

Die einzige Erklärung, die ich dafür hab, ist, dass der Boden überm Himmel liegt, denn nur die Bereiche, wo nur Himmel zu sehen ist, haben den Faktor 1.
Du hast sicher recht. Die olle Skybox. :smile:

Gast

2006-06-21, 11:18:19

Mastermind[/POST]']Ich lass hier mal die Hosen runter, damit keiner meinen Fehler wiederholt. Und zwar hab ich vergessen, dass ich per Treiber VSync erzwingen lasse. Dementsprechend konstant waren auch die FPS. :biggrin:

welcher monitor schafft denn bitte 350Hz+?

Mastermind

2006-06-21, 11:26:37

Gast[/POST]']welcher monitor schafft denn bitte 350Hz+?
Kleines Missverständnis! Die Zahlen stammen nicht von mir. Habe den Post gequotet weil ich mich auf den "Bench" da drin bezogen hab. Ich selbst hatte durchgehend 85 FPS bei 1600x1200. ;) (100 geht auch, aber dann leidet die Bildschärfe)

Gast

2006-06-21, 16:07:30

also bei mir taugt der bench grade mal zum freeze der feinsten sorte!

Mastermind

2006-06-21, 16:31:10

Gast[/POST]']also bei mir taugt der bench grade mal zum freeze der feinsten sorte!
Wenn das alles ist, was du uns mitteilst, dann können wir dir auch nicht helfen. Zumindest geht er bei einigen, liegt vielleicht also gar nicht am Bench.

Simon

2006-06-21, 16:46:07

loewe[/POST]']Wobei es mir nicht auf die fps sondern auf die Konstanz der FPS ankommt. ;)
Ja, wirklich sehr konstant (X1800XT) :|

Overdraw/HSR:
-------------
Overdraw factor 3, back to front: 994.46 fps
Overdraw factor 3, front to back: 1374.52 fps
Overdraw factor 3, random order: 1335.40 fps

Overdraw factor 8, back to front: 389.20 fps
Overdraw factor 8, front to back: 1472.88 fps
Overdraw factor 8, random order: 1004.16 fps

Mastermind

2006-06-21, 16:58:10

Simon[/POST]']Ja, wirklich sehr konstant (X1800XT) :|

Overdraw/HSR:
-------------
Overdraw factor 3, back to front: 994.46 fps
Overdraw factor 3, front to back: 1374.52 fps
Overdraw factor 3, random order: 1335.40 fps

Overdraw factor 8, back to front: 389.20 fps
Overdraw factor 8, front to back: 1472.88 fps
Overdraw factor 8, random order: 1004.16 fps
Falls ich nichts falsch verstehe, dann soll man schauen wie konstant die Werte bleiben. Und wenn sie nicht konstant sind, wie bei dir, dann ist das einfach schlecht! :D

Ailuros

2006-06-21, 23:15:37

Simon[/POST]']Ja, wirklich sehr konstant (X1800XT) :|

Overdraw/HSR:
-------------
Overdraw factor 3, back to front: 994.46 fps
Overdraw factor 3, front to back: 1374.52 fps
Overdraw factor 3, random order: 1335.40 fps

Overdraw factor 8, back to front: 389.20 fps
Overdraw factor 8, front to back: 1472.88 fps
Overdraw factor 8, random order: 1004.16 fps

Ein TBDR mit der Groesse einer X1800 wuerde in etwa gleiche Werte in allen Tests abgeben. Um wieviel Prozent sinkt die Leistung hier zwischen front to back und back to front?

loewe

2006-06-21, 23:36:37

Es gibt keine und wird auch keine Overdraw freien Games geben!

Overdraw/HSR:
-------------
Overdraw factor 3, back to front: 157.36 fps
Overdraw factor 3, front to back: 215.43 fps
Overdraw factor 3, random order: 189.43 fps

Overdraw factor 8, back to front: 91.98 fps
Overdraw factor 8, front to back: 216.68 fps
Overdraw factor 8, random order: 155.43 fps

Diese Werte sind von meiner FX5900XT, etwas moderneres habe ich im Moment nicht.
Wie man leicht erkennt, es gibt beträchtliche Unterschiede zwischen "front to back" und "back to front" oder besser gesagt, random order, was eher einem normalem Verhalten in einem Spiel entspricht, ist noch recht weit entfernt vom Idealfall "front to back".
Die X1800XT ist doch gar nicht so schlecht! :)

Es ist nicht wirklich möglich einen IMR Renderer unempfindlich bzgl. Overdraw zu machen, das Problem muss immer durch Ansätze wie "Hier-Z, Early-Z" "gelöst" werden, die aber nicht wirklich greifen können da sie nicht "wissen" was noch kommt.

Nur TBDRs könnne hier nahezu gleiche Werte bringen.

Meine Werte,

Overdraw/HSR:
-------------
Overdraw factor 3, back to front: 353.97 fps
Overdraw factor 3, front to back: 354.03 fps
Overdraw factor 3, random order: 351.35 fps

Overdraw factor 8, back to front: 306.03 fps
Overdraw factor 8, front to back: 305.61 fps
Overdraw factor 8, random order: 305.80 fps

sind von der KYRO II SE, einer 400 MPixel Karte, einem billig Design aber einem TBDR! ;)

aths

2006-06-22, 12:29:49

loewe[/POST]']Es gibt keine und wird auch keine Overdraw freien Games geben!

Overdraw/HSR:
-------------
Overdraw factor 3, back to front: 157.36 fps
Overdraw factor 3, front to back: 215.43 fps
Overdraw factor 3, random order: 189.43 fps

Overdraw factor 8, back to front: 91.98 fps
Overdraw factor 8, front to back: 216.68 fps
Overdraw factor 8, random order: 155.43 fps

Diese Werte sind von meiner FX5900XT, etwas moderneres habe ich im Moment nicht.
Wie man leicht erkennt, es gibt beträchtliche Unterschiede zwischen "front to back" und "back to front" oder besser gesagt, random order, was eher einem normalem Verhalten in einem Spiel entspricht, ist noch recht weit entfernt vom Idealfall "front to back".
Die X1800XT ist doch gar nicht so schlecht! :)

Es ist nicht wirklich möglich einen IMR Renderer unempfindlich bzgl. Overdraw zu machen, das Problem muss immer durch Ansätze wie "Hier-Z, Early-Z" "gelöst" werden, die aber nicht wirklich greifen können da sie nicht "wissen" was noch kommt.

Nur TBDRs könnne hier nahezu gleiche Werte bringen.Dafür benötigen sie Zusatzlogik, welche dann – bei gleicher Tranistorzahl – bei den TMUs oder ALUs fehlt. Early-Z greift sehr gut bei Front-to-Back-Rendering. Bestimmte Rendering-Methoden müssen eh erst den Z-Buffer rendern, so dass der Overdraw bei den teuren Pixelshader-Berechnungen praktisch enfällt. Die Messungen mit dem Overdrawfaktor von 8 sind insofern unrealistisch, da der übliche Overdrawfaktor in Spielen in etwa 3 ist. Bei Halbtransparenz hat auch der TBDR entsprechenden Overdraw. Deine synthetischen Messungen in denen die Kyro 2 eine FX 5900 abrult, sind in der Spiele-Praxis irrelevant. Kyro 2 hat zwei TMUs, die FX 5900 hat acht TMUs – und taktet doppelt so schnell.

Gast

2006-06-22, 13:36:41

Neue Engines geben ja immer an mit "wir können Echtzeitschatten, Parallaxmapping, HDR" aber keiner gibt damit an, daß er F2B einbaut oder unsichtbares gar nicht zeichnet. Die Presse sollte mal mehr da nachhaken und auch mal motzen, wenn die meisten Spiele schlechter performen als gut/clever programmierte. Aber die Reviewer kriegen eh 1/2jährlich neue HW, da fällt schlechte Perf gar nicht mehr auf, beindruckt wird man dann nur von Burnout auf PS2 im Vgl zu NFSMW. EA ist überhaupt son Perf-Fresserkandidat, Ubi's King Kong ist mir auch unangenehm aufgefallen

Cyphermaster

2006-06-22, 13:47:46

Wozu sollten die Programmierer das tun? Bislang gibt's keinen Anreiz. Engine nachfeilen kostet Mannstunden, Mannstunden kosten Geld. Optische Effekte geben in Tests schöne bunte Bilder, und damit den "BOAH!!!-Effekt", durch den der Kunde zum Kauf verleitet wird. Und rein über die Anzahl Verkäufe spielt ein Spiel Geld ein...

Performance-Sparen ist bislang schlichtweg vom Kunden nicht gefordert, bzw. wird nicht honoriert. Da wird viel lieber das Spiel raubkopiert, um sich noch schnellere Hardware leisten zu können. Ist genau dasselbe wie der vielbeschworene "Content"! Bis den Usern fehlende Nebenhandlungen im Effekt-Gewitter überhaupt auffallen, ist die wichtige, erste Kaufwelle doch schon lange vorbei. Beispiel? Doom³. Für die Spielehersteller angenehmer Nebeneffekt: Dem Spieler ist schnell das Spiel langweilig, man kann also den gleichen Müll mit einem anderen Spiel flott hinterher-programmieren - auch das wird wieder gekauft.

Gast

2006-06-22, 15:05:17

Gast[/POST]']Neue Engines geben ja immer an mit "wir können Echtzeitschatten, Parallaxmapping, HDR" aber keiner gibt damit an, daß er F2B einbaut oder unsichtbares gar nicht zeichnet.

was soll das bringen. marketing mit einem feature was 90% der potentiellen kunden eh nicht verstehen?

seit jahren versucht jede engine soviel wie möglich F2B zu rendern, und vor allem in innenarealen funktioniert das auch sehr gut. in außenarealen wird es etwas schwieriger, allerdings wird auch hier versucht overdraw zu vermeiden.

polygone die zum nächsten raum gehören und beispielsweise durch eine tür nicht sichtbar sind werden erst garnicht zur graka geschickt, das konnte bereits serious sam 1.

doom3 beispielsweise ist ein spiel welches keinen einzigen unsichtbaren pixel zeichnet, aber warum sollte man damit marketing betreiben?

Gast

2006-06-22, 19:49:54

können können es wohl viele, bezweifle nur stark, das sich heute alle auch die mühe machen. bei gothic konnte man mit cheat dies überprüfen. da wurde im alten lager dann alles hinter einem im Zelt ausgeblendet. Physik ist auch so ein leidiges Thema, bei Flatout liefs noch gut & realistisch, neue Titel brauchen ,wdG warum, viel mehr mit geringerem Ergebnis.

tokugawa

2006-06-22, 19:50:22

Modulor[/POST]']Natürlich nicht,darum ging es mir ja auch gar nicht. Es trägt zum Thema bei da man damit (afaik) erstmals sehen kann was man nicht sieht und somit die gleiche Frage wie der Threadtitel aufwirft: Warum wird der Polygon"müll" hinter dem Tor überhaupt an die Karte geliefert ? Und ich kann mich nicht daran erinnern daß die Lithtech Engine bei den Kritikern durchgefallen wäre...
Die Programmierer wissen heute daß es effektive Mechanismen in den Grafichips gibt die die Arbeit für sie erledigen - warum sollen sie sich also die Mühe machen das im Vorfeld gleich durch die Engine erledigen zu lassen ? Zeit und Geld gespart - das geben ATI und NVIDIA - und somit auch der Kunde - dafür um so reichlicher aus...

Nicht ganz richtig. Visibility-Algorithmen, die effektiv Overdraw reduzieren, sowie das dazugehörige Culling, werden sehr wohl heute verwendet.

Lies dich mal ein in State-of-the-Art-Echtzeitgrafik (sh. GPU Gems 2).

Gast[/POST]']Neue Engines geben ja immer an mit "wir können Echtzeitschatten, Parallaxmapping, HDR" aber keiner gibt damit an, daß er F2B einbaut oder unsichtbares gar nicht zeichnet.

Weil z.B. Frustum Culling totaler Standard ist, und außerdem trivial? Aber jede Engine macht irgendwas in die Richtung Visibility Culling, von einfachem Frustum Culling bis zu anderen Visibility-Techniken.

Würden die Entwickler tatsächlich alles auf die GPU rotzen ohne zu optimieren, wie du das unterstellst, könnten wir nicht die heutige Grafikqualität genießen.

Gast[/POST]']
Die Presse sollte mal mehr da nachhaken und auch mal motzen, wenn die meisten Spiele schlechter performen als gut/clever programmierte. Aber die Reviewer kriegen eh 1/2jährlich neue HW, da fällt schlechte Perf gar nicht mehr auf, beindruckt wird man dann nur von Burnout auf PS2 im Vgl zu NFSMW. EA ist überhaupt son Perf-Fresserkandidat, Ubi's King Kong ist mir auch unangenehm aufgefallen

Die Presse kann da nicht viel helfen wenn die Presse sich nicht mit Grafik-Algorithmen auskennt. Ich kenne keine Zeitschrift der Spieletesterpresse, die qualifiziert dafür wäre.

Aber moderne Engines müssen cullen, sonst kämen sie nicht auf die Performance, die sie bereits haben.

Den Entwicklern zu unterstellen dass sie heutzutage so ineffizienten Code schreiben, ist absoluter Blödsinn. Sie setzen die Mehrleistung der GPUs wirklich um, aber die kann nie genug sein.

Cyphermaster[/POST]']Wozu sollten die Programmierer das tun? Bislang gibt's keinen Anreiz. Engine nachfeilen kostet Mannstunden, Mannstunden kosten Geld. Optische Effekte geben in Tests schöne bunte Bilder, und damit den "BOAH!!!-Effekt", durch den der Kunde zum Kauf verleitet wird. Und rein über die Anzahl Verkäufe spielt ein Spiel Geld ein...

Performance-Sparen ist bislang schlichtweg vom Kunden nicht gefordert, bzw. wird nicht honoriert. Da wird viel lieber das Spiel raubkopiert, um sich noch schnellere Hardware leisten zu können. Ist genau dasselbe wie der vielbeschworene "Content"! Bis den Usern fehlende Nebenhandlungen im Effekt-Gewitter überhaupt auffallen, ist die wichtige, erste Kaufwelle doch schon lange vorbei. Beispiel? Doom³. Für die Spielehersteller angenehmer Nebeneffekt: Dem Spieler ist schnell das Spiel langweilig, man kann also den gleichen Müll mit einem anderen Spiel flott hinterher-programmieren - auch das wird wieder gekauft.

Effizienz ist auch notwendig wenn man "optische Effekte" einsetzen will. Den diese kosten die Performance die man bei der Optimierung eingespart hat.

Performance-Sparen wird sehr stark durchgeführt. Nur ist gleichzeitig die Anforderung gestiegen weil um einiges mehr gemacht wird insgesamt.

Bitte: schreibt hier nicht so unqualifizierte Meldungen über Entwickler, die angeblich so ineffizienten Code schreiben, wenn ihr nicht wirklich selbst Erfahrung damit habt! Das tut mir (und einigen anderen sonst hier) sonst nur im Schädel weh (vom Kopfschütteln).

Ailuros

2006-06-22, 21:47:07

aths[/POST]']Dafür benötigen sie Zusatzlogik, welche dann – bei gleicher Tranistorzahl – bei den TMUs oder ALUs fehlt. Early-Z greift sehr gut bei Front-to-Back-Rendering. Bestimmte Rendering-Methoden müssen eh erst den Z-Buffer rendern, so dass der Overdraw bei den teuren Pixelshader-Berechnungen praktisch enfällt. Die Messungen mit dem Overdrawfaktor von 8 sind insofern unrealistisch, da der übliche Overdrawfaktor in Spielen in etwa 3 ist. Bei Halbtransparenz hat auch der TBDR entsprechenden Overdraw. Deine synthetischen Messungen in denen die Kyro 2 eine FX 5900 abrult, sind in der Spiele-Praxis irrelevant. Kyro 2 hat zwei TMUs, die FX 5900 hat acht TMUs – und taktet doppelt so schnell.

Kommt ganz drauf an was fuer einen Overdraw-Faktor man genau meint. Opague overdraw duerfte tatsaechlich irgendwo bei 3.0 oder etwas weniger liegen, generelles Overdraw aber wohl doch um einiges hoeher. Schon die erste SS engine reichte ueber 4.0 und ich will ernsthaft bezweifeln dass heutige und noch mehr zukuenftige Spiele bei nur 3.0 im Durchschnitt liegen.

Early Z und noch mehr in Kombination mit Hierarchical Z oder aehnlichen Methoden koennen sich schon ziemlich effizient zeigen, aber ein echter TBDR spart hier immer noch etwas mehr Bandbreite. Plus die Ausnahmen wo es schwer ist back to front zu entgehen und natuerlich die sehr hohen Z/stencil Raten.

Zwar liegt das Ganze im Raum der reinen These, aber ich will mir nicht vorstellen was fuer einen Overdraw-Faktor die UE3 engine genau haben koennte, noch wie sich ein high end TBDR rein hypothetisch in dem Ding verhalten wuerde.

tokugawa

2006-06-22, 21:54:35

Ein Overdraw von 1 wäre bei einem traditionellen Renderer sowieso nicht erstrebenswert. Die Algorithmen um pixelgenau zu erreichen, dass man nie einen Pixel umsonst rendert würden wohl länger brauchen als eine gewisse Menge an "false positives" (bzw. "falsely detected as visible") zuzulassen.

Das liegt aber nicht an der Unfähigkeit der Entwickler, sondern generell an der Hardware-Architektur, bzw. deren Ansteuerung. Hat ja auch damit zu tun, dass längere Batches besser sind als viele kleine (welche nötig wären wenn man ein feingranulareres Visibility-Checking implementieren will). Die Granularität, mit der eine Szene in Batches geteilt wird, muß gut balanciert werden.

Jedenfalls ist zwar hoher Overdraw nicht gut, aber Overdraw selbst ist sicher keine lineare Performancegröße. Man kann nicht sagen dass ein geringerer Overdraw automatisch höhere Performance bringt, sondern muß jede Engine, oder gar jede einzelne Szene in ein und derselben Engine dahingehend analysieren.

Schimi1983

2006-06-22, 22:12:03

Overdraw/HSR:
-------------
Overdraw factor 3, back to front: 1084.03 fps
Overdraw factor 3, front to back: 2247.00 fps
Overdraw factor 3, random order: -185189.48 fps

Overdraw factor 8, back to front: 471.80 fps
Overdraw factor 8, front to back: -634271.15 fps
Overdraw factor 8, random order: 984.78 fps

Fillrate:
---------
Pixel fillrate: -733477.28 MegaPixels / s
Texel fillrate: 11281.88 MegaTexels / s

T&L/High polygon count static display list:
-------------------------------------------
Pure transform: -16451456300 vertices / s
2 point lights: -3867975526 vertices / s
8 point lights: -5225071515 vertices / s
2 directional lights: 153942063 vertices / s
8 directional lights: 93049027 vertices / s

High memory bandwidth load/texture cache efficiency:
----------------------------------------------------
One 1024x1024x32 texture: 1534.91 fps
Four 1024x1024x32 textures: -111994.27 fps

X1800XT

Gast

2006-06-22, 22:33:09

Ailuros[/POST]']Kommt ganz drauf an was fuer einen Overdraw-Faktor man genau meint. Opague overdraw duerfte tatsaechlich irgendwo bei 3.0 oder etwas weniger liegen, generelles Overdraw aber wohl doch um einiges hoeher. Schon die erste SS engine reichte ueber 4.0 und ich will ernsthaft bezweifeln dass heutige und noch mehr zukuenftige Spiele bei nur 3.0 im Durchschnitt liegen.

ein DR kann aber auch nur opaquen overdraw verhindern, overdraw durch transparenzen nicht. der overdraw-faktor (vor allem der nicht-opaque-overdraw) hängt auch kaum von der engine sondern vom content ab.

Gast

2006-06-22, 22:33:26

Schimi1983[/POST]']X1800XT

deine pixelfüllrate ist aber schwach ;)

Schimi1983

2006-06-22, 22:59:55

es liefen noch andere sachen, bzw da hat sich nen anderes windows versucht in den vordergrund zu stellen, habe keienn reinen test gemacht, weiss abe rnicht ob sichd as window ausgewirkt hat...

Mastermind

2006-06-22, 23:05:27

Schimi1983[/POST]']es liefen noch andere sachen, bzw da hat sich nen anderes windows versucht in den vordergrund zu stellen, habe keienn reinen test gemacht, weiss abe rnicht ob sichd as window ausgewirkt hat...
Natürlich hat es das! Darum sind die Werte ja auch versaut.

Gast

2006-06-22, 23:11:58

Schimi1983[/POST]']es liefen noch andere sachen, bzw da hat sich nen anderes windows versucht in den vordergrund zu stellen, habe keienn reinen test gemacht, weiss abe rnicht ob sichd as window ausgewirkt hat...

naja, aber das sie gleich negativ ist, da hatte ja eine voodoo1 mehr ;)

Ailuros

2006-06-23, 06:22:30

Gast[/POST]']ein DR kann aber auch nur opaquen overdraw verhindern, overdraw durch transparenzen nicht. der overdraw-faktor (vor allem der nicht-opaque-overdraw) hängt auch kaum von der engine sondern vom content ab.

Tatsaechlich. Und dabei sollte man sowieso sagen dass ein DR sowie ein IMR es genauso schwer hat, wenn die Daten-verwerfung in der engine Schwaechen zeigt.

Gast

2006-06-23, 12:54:25

Das die devs alles tun, na ja. Bei EA-Sports ist alles ja noch auf DX7-Level und die Videos ruckeln immer, auf meiner 1,5GHz Kiste laufen WMV-HD-Videos (1024x768) und die bringen es nicht zustande, ein 640er Video flüssig laufen zu lassen. Genauso hab ich seit meiner C64/Amiga-Zeit kein anständiges Scrolling mehr gesehen. Man braucht nur Uridium mit Diablo2 zu vergleichen.Schon komisch.

Mastermind

2006-06-23, 13:37:07

Wie bitte? Soll das mit DX7 in modernen Spielen euer ernst sein?
Heutzutage will doch jedes zweite spiel die neueste Version von DX9.0c haben! Und manche installieren das sogar ohne zu fragen bei der installation! Also das mit DX7 kommt mir echt komisch vor! Warum sollte man sich mit so einer alten Technik rumschlagen, zumal DX9 auch für Win98 verfügbar ist?

loewe

2006-06-23, 16:52:06

aths[/POST]']Dafür benötigen sie Zusatzlogik, welche dann – bei gleicher Tranistorzahl – bei den TMUs oder ALUs fehlt. Early-Z greift sehr gut bei Front-to-Back-Rendering. Bestimmte Rendering-Methoden müssen eh erst den Z-Buffer rendern, so dass der Overdraw bei den teuren Pixelshader-Berechnungen praktisch enfällt. Die Messungen mit dem Overdrawfaktor von 8 sind insofern unrealistisch, da der übliche Overdrawfaktor in Spielen in etwa 3 ist. Bei Halbtransparenz hat auch der TBDR entsprechenden Overdraw.
Wir brauchen nicht weiter über die Transitorzahlen zu streiten, solange es keine neuen TBDRs mit entsprechender Leistung gibt, werde ich den Nachweis schuldig bleiben, dass ein TBDR bei geringerer Transitorzahl gleiche Leistung bringen kann.
Es ist nun einmal nicht möglich immer nur Front-to-Back zu rendern und selbst wenn, wäre der Aufwand in Software gewaltig. Nach wie vor gilt, das Pixel das gar nicht gerendert werden muß, ist das am schnellsten gerenderte Pixel. Overdraw ist nicht wirklich vermeidbar, kann höchstens mit entweder hohem Aufwand oder durch Vereinfachung der Szene klein gehalten werden.
Es würde die Programmierer sicher nicht sehr stören, wenn sie sich nicht darum kümmern müßten. Dem ist nicht so, also muß man sich damit beschäftigen!
aths[/POST]']Deine synthetischen Messungen in denen die Kyro 2 eine FX 5900 abrult, sind in der Spiele-Praxis irrelevant. Kyro 2 hat zwei TMUs, die FX 5900 hat acht TMUs – und taktet doppelt so schnell.
Nur falls es Dir nicht aufgefallen sein sollte, ich hatte extra betont das mich die Höhe der FPS nicht interessiert. Und selbst mir ist klar, das eine Kyro eine FX5900 nicht "abrult", sonst hätte ich heute immer noch Kyro in meinem Rechner.
Ansonsten, wir werden wohl doch noch irgendwann zu sehen bekommen, was ein leistungsstärkerer TBDR anrichten kann.

loewe

2006-06-23, 16:59:04

Schimi1983[/POST]']X1800XT
:rolleyes:
Mit solch hohen Werten hatte Humus wohl nie gerechnet und du hast hier einen Überlauf drin?!
Welche Auflösung war das?

loewe

2006-06-23, 17:00:04

Ailuros[/POST]']Tatsaechlich. Und dabei sollte man sowieso sagen dass ein DR sowie ein IMR es genauso schwer hat, wenn die Daten-verwerfung in der engine Schwaechen zeigt.

Ich denke der IMR hat es schwerer! :)

aths

2006-06-23, 18:06:55

loewe[/POST]']Wir brauchen nicht weiter über die Transitorzahlen zu streiten, solange es keine neuen TBDRs mit entsprechender Leistung gibt, werde ich den Nachweis schuldig bleiben, dass ein TBDR bei geringerer Transitorzahl gleiche Leistung bringen kann.
Es ist nun einmal nicht möglich immer nur Front-to-Back zu rendern und selbst wenn, wäre der Aufwand in Software gewaltig. Nach wie vor gilt, das Pixel das gar nicht gerendert werden muß, ist das am schnellsten gerenderte Pixel. Overdraw ist nicht wirklich vermeidbar, kann höchstens mit entweder hohem Aufwand oder durch Vereinfachung der Szene klein gehalten werden.
Es würde die Programmierer sicher nicht sehr stören, wenn sie sich nicht darum kümmern müßten. Dem ist nicht so, also muß man sich damit beschäftigen!

Nur falls es Dir nicht aufgefallen sein sollte, ich hatte extra betont das mich die Höhe der FPS nicht interessiert. Und selbst mir ist klar, das eine Kyro eine FX5900 nicht "abrult", sonst hätte ich heute immer noch Kyro in meinem Rechner.Beim Gitternetz-Rendering (ok, für Spiele irrelevant) oder bei halbtransparenten Polygonen (für viele Spiele relevant) brechen IMR wie TBDR ein – letzterer jedoch stärker. Die Konstanz in der Leistung gilt für den Fall, dass es kein Alphablending gibt, sowie dass alle Dreiecke in den Speicher passen. Gerade weil ich ein Befürworter von DR-Technik bin, wäre es mir Recht, wenn auch die Nachteile solcher Architekturen genannt werden. Mich interessiert im Spiel (neben der Grafikqualität) gerade die Höhe der fps. Mit konstanten 10 fps kann ich im Spiel nichts anfangen.

Dreieckssortierung der Hardware zu überlassen ist im Prinzip eine gute Idee. Allerdings bieten Dualcore-CPUs hier neuen Spielraum – was wieder ein mal das Leben des IMRs verlängern könnte. Eigentlich sehe ich es seit Jahren darauf hinauslaufen, dass jede 3D-Lösung vermeidbaren Overdraw weitgehend vermeidet. Leider ist das bis heute noch nicht eingetroffen. Dafür die Gründe zu finden und nicht nur zu meinen, dass NV und ATI einfach ihre bisherigen Konzepte nicht aufgeben wollten oder nicht die Technik hätten (mindestens NV hat sie) halte ich für sinnvoll.

Ein wesentlicher Grund ist aus meiner Sicht, dass heutige IMR sehr viel effizienter sind als noch zu GeForce2-GTS-Zeiten – als Kyro und Kyro2 zurecht als Effizienzwunder gefeiert wurden. Nebenbei erwähne ich gerne noch die Bumpmappig-Fähigkeiten, und die Multitexturing-Fähigkeiten, die damaliger Highend-GeForce-Technik deutlich überlegen war.

loewe[/POST]']Ansonsten, wir werden wohl doch noch irgendwann zu sehen bekommen, was ein leistungsstärkerer TBDR anrichten kann.Seit Jahren deutest du an, dass man von PVR nicht vielleicht doch noch mal was sehen könne – inzwischen imo so abgenutzt wie der Running Gag mit Duke Nukem Forever. Wenn PVR ein Design an Intel lizensiert wahrscheinlich nicht, damit 3D-Grafik im oberen Leistungsbereich realisiert wird.

Gast

2006-06-23, 18:56:08

Mastermind[/POST]']Wie bitte? Soll das mit DX7 in modernen Spielen euer ernst sein?
Heutzutage will doch jedes zweite spiel die neueste Version von DX9.0c haben! Und manche installieren das sogar ohne zu fragen bei der installation! Also das mit DX7 kommt mir echt komisch vor! Warum sollte man sich mit so einer alten Technik rumschlagen, zumal DX9 auch für Win98 verfügbar ist?

Mit meiner r96tx seh ich jedenfalls nix shadriges oder sonstiges, was auch nur über dx6 hinaus geht bei fifawm06, aber wahrscheinlich liegts an meiner SM2.0 Graka, und in den Stadien gibts überall SM3.0 HDR 'Ironie off'

2006-06-23, 19:12:22

Mastermind[/POST]']Wie bitte? Soll das mit DX7 in modernen Spielen euer ernst sein?
Heutzutage will doch jedes zweite spiel die neueste Version von DX9.0c haben! Und manche installieren das sogar ohne zu fragen bei der installation! Also das mit DX7 kommt mir echt komisch vor! Warum sollte man sich mit so einer alten Technik rumschlagen, zumal DX9 auch für Win98 verfügbar ist?
Er meint wohl D3D7-Techlevel, das bedeutet, dass nur Funktionen aus D3D9 benutzt werden, die auch von D3D7 schon angeboten wurden.
Theoretisch kannst du auch mit D3D9c Voodoo1-kompatible Programme schreiben.

Edit: Rechtschreibfehler gehorsamst ausgebessert.

aths

2006-06-23, 19:49:47

T.[/POST]']Er meint wohl D3D7-Techlevel, das bedeutet, dass nur Funktionen aus D3D9 benutzt werden, die auch von D3D7 schon angeboten wurden.
Theoretisch kannst du auch mit D3D9c Vodoo1-kompatible Programme schreiben.Voodoo (beides mal zwei o.) Soweit ich weiß, kann die Voodoo einiges, was es in D3D so nicht gibt (weil man es nicht mehr braucht.)

Xmas

2006-06-24, 02:28:51

aths[/POST]']Beim Gitternetz-Rendering (ok, für Spiele irrelevant) oder bei halbtransparenten Polygonen (für viele Spiele relevant) brechen IMR wie TBDR ein – letzterer jedoch stärker. Die Konstanz in der Leistung gilt für den Fall, dass es kein Alphablending gibt, sowie dass alle Dreiecke in den Speicher passen.
Da ein TBDR für Alphablending keine externe Bandbreite benötigt, hat er dabei immer noch einen Vorteil.

Ailuros

2006-06-24, 06:33:46

loewe[/POST]']Ich denke der IMR hat es schwerer! :)

Die Quake3 engine hatte zwar ein ziemlich fortschrittliches BSP fuer ihre Zeit, aber eine der Schwaechen war dass es der engine nicht bewusst war wo die Camera genau orientiert ist. Manchmal hatte es zum Resultat dass die Leistung unerklaerlich sank wenn man vor einer leeren Wand stand. Genau eben weil hinter dieser Wand Gott weiss wass gezeichnet wurde und der engine nicht bewusst war wo die Camera orientiert ist, kam es dazu dass unnoetig Daten berechnet wurden und da macht es keinen besonderen Unterschied mehr ob IMR oder TBDR.

Natuerlich nur ein Beispiel der Vergangenheit, wie wichtig das Verhalten und die Effizienz einer Spiele-engine fuer HSR eigentlich ist. Bei einer "dummen" Engine kann ein TBDR den Tag auch nicht retten.

Ailuros

2006-06-24, 07:00:54

aths[/POST]']
Seit Jahren deutest du an, dass man von PVR nicht vielleicht doch noch mal was sehen könne – inzwischen imo so abgenutzt wie der Running Gag mit Duke Nukem Forever. Wenn PVR ein Design an Intel lizensiert wahrscheinlich nicht, damit 3D-Grafik im oberen Leistungsbereich realisiert wird.

Ohne high HW wird sich auch in absehbarer Zeit nichts daran aendern; es wird stets im hypothetischen Raum bleiben.

Vergleiche sind momentan nur im PDA/mobilen Markt moeglich. Warum haben hier z.B. Imageon oder AR1x noch kein early-Z? Weil es Transistoren kostet vielleicht? Mir kann keiner weiss machen dass ATI/NVIDIA nichts besseres aus deren Portofolio zaubern konnten als Voodoo-alike oder TNT-Niveau chips.

Fuellrate und Bandbreite sind auf beiden vorerwaehnten unbefriedigend und noch schlimmer die Geometrie-Leistung ist genauso unterirdisch, wobei es doch staendlich heisst dass TBDRs ein Problem mit Geometrie haben sollten dank Parameter-Bandwidth. Es werden zwar in mehreren Faellen 1M Polys/s als Beispiel angegeben, aber ironischerweise kann nur der TBDR diese Raten erreichen.

Zum eigentlichen Thema: Intel hat wohl tatsaechlich nichts fuer mainstream oder high end Bereiche des Markts lizensiert und es ist immer noch unbekannt fuer was sie genau Eurasia benutzen werden ausser PDA/mobiles.

Ich sag es mal anders: eine Strategie von unten nach oben zu entwickeln hat ebenso Limitierungen wie von oben nach unten. Wenn man eine Familie von Grafik-kernen primaer fuer Pda/mobile entwickelt dann ist es verstaendlich fuer mich dass man das Ganze nur bis zu Grad X skalieren kann und nicht unendlich. Gleiches gilt fuer mich auch umgekehrt, deshalb wundert mich der TNT Level in AR1x auch nicht besonders.

In beiden Faellen muessen A oder B mehr Resourcen auflegen fuer zusaetzliche Designs. IMG hat bis jetzt keine guten Intensiven/Moeglichkeiten etwas fuer den high end Markt zu entwickeln und ATI/NVIDIA muessen erst Resourcen aufschaufeln um fundamentalere Designs fuer PDA/mobile zu entwickeln.

Frage ich aber wo hier der Strom- und Speicher- und Bandbreiten-Verbrauch besser ist in diesem Markt, werden ich hoffentlich nicht IMR als Antwort bekommen. Und es gibt bis jetzt keinen greifbaren Beweiss dass dieses nicht auch fuer eine rein hypothetische high end GPU gelten koennte. Nur rendert eben Theorie keine Pixel auf den Bildschirm.

Silver Surfer

2006-06-24, 11:35:33

Aktuelles Beispiel, also immer noch nicht gefixt bei Mr. Ferrari-Fahrer Carmack: Prey Demo

Fraps starten, Demo laden. Man geht anfangs in die Toilette und schaut mal auf die Wand links, mal auf die Wand rechts. Wenn man also in Richtung Bar schaut, sinken die Frames von 50 auf 12 auf ner r300.

MacLeod

2006-06-24, 11:40:21

Man könnte glauben, die Graka-Firmen bezahlen für Overdraw

Mastermind

2006-06-24, 12:27:32

Silver Surfer[/POST]']Aktuelles Beispiel, also immer noch nicht gefixt bei Mr. Ferrari-Fahrer Carmack: Prey Demo

Fraps starten, Demo laden. Man geht anfangs in die Toilette und schaut mal auf die Wand links, mal auf die Wand rechts. Wenn man also in Richtung Bar schaut, sinken die Frames von 50 auf 12 auf ner r300.
Was hat Prey mit Carmack zu tun? Prey wurde von Human Head in Zusammenarbeit mit 3D Realms entwickelt. Nur so als Anmerkung. ;)

Coda

2006-06-24, 13:47:46

Was hier für ein Blödsinn verbreitet wird ist echt unglaublich. Natürlich macht jede moderne Engine HSR, aber dies perfekt zu machen wäre einfach unglaublich dämlich, weil man dafür jedes Polygon auf der CPU anschauen müsste und die Daten nur dynamisch pro Frame an die GPU schicken könnte.

Was man macht ist das Zeug grob in einen Scenetree zu stopfen und dann Nodes komplett anzuzeigen oder eben nicht. Das rendert man dann noch Front-to-Back mit einem sehr geringen effektiven Overdraw, dank Hier-Z oder ähnlichen Maßnahmen.

Es gibt natürlich auch Beispiele die richtig mies sind und man die Entwickler wirklich schlagen sollte, dazu gehörte damals z.B. Morrowind das definitiv gar kein HSR gemacht hat. Falls das in Oblivion immer noch so ist, erklärt das manches (ATi hat ein effektiveres System um Overdraw zu verringern).

Gast[/POST]']doom3 beispielsweise ist ein spiel welches keinen einzigen unsichtbaren pixel zeichnet
Unsinn. Das ist gar nicht machbar (dazu müsstest du ja Polygone abschneiden - ich will jetzt gar nicht genau über den nötigen Aufwand nachdenken). Außerdem zeigt "r_showtris 3" natürlich was ganz anderes.

Was Doom macht ist ein Z-First-Pass wodurch sämtliche Pixelshader nur für sichtbare Pixel durchlaufen.

Ailuros[/POST]']Die Quake3 engine hatte zwar ein ziemlich fortschrittliches BSP fuer ihre Zeit
HA?!? BSP gabs schon in der Grafik-Steinzeit (Doom).

Ailuros[/POST]']aber eine der Schwaechen war dass es der engine nicht bewusst war wo die Camera genau orientiert ist
Meinst du "wie sie orientiert ist"? Weil wo die Kamera war war nämlich der einzig Faktor beim Quake-HSR (Lookup per Sektor welche anderen Sektoren von diesem aus sichtbar sind).

aths[/POST]']Dreieckssortierung der Hardware zu überlassen ist im Prinzip eine gute Idee. Allerdings bieten Dualcore-CPUs hier neuen Spielraum
Nein tun sie nicht. Wenn man anfängt pro Frame einzelne Polygone anzufassen hat man verloren - ganz egal wieviel CPU-Zeit man zur Verfügung hat.

aths

2006-06-24, 14:42:36

Coda[/POST]']Nein tun sie nicht. Wenn man anfängt pro Frame einzelne Polygone anzufassen hat man verloren - ganz egal wieviel CPU-Zeit man zur Verfügung hat.Selbst mit dreiecksgenauer Sortierung hätte man noch Overdraw, insofern braucht man es auf CPUs ohnehin nicht dreicksgenau machen. "Dreiecke sortieren" war insofern eine ungünstige Formulierung von mir.

aths

2006-06-24, 14:56:32

Ailuros[/POST]']Ohne high HW wird sich auch in absehbarer Zeit nichts daran aendern; es wird stets im hypothetischen Raum bleiben.Genau das ist ja das Problem: Highend- oder wenigstens Midend-HW von PVR steht nicht in Aussicht.

Was die Leistung angeht: Ich hab gestern mit jemandem ein wenig über 3D-Wunschleistung beim NDS philosophiert, und da stellte sich heraus, dass ein MBX Lite zu schwachbrüstig wäre.

Zum Glück hat man im PC-Bereich ganz andere Möglichkeiten bezüglich Chipgröße und Stromverbrauch. Aber wir sehen von PVR nichts – seit Jahren. Insofern halte ich es für nicht sinnvoll, anzudeuten, dass eine PVR-Highendlösung tatsächlich Highendleistung bieten würde. Soweit ich weiß ist SGX nicht mal in der größten Ausbaustufe das, was wir heute unter Highend verstehen.

Gast

2006-06-24, 15:59:37

Coda[/POST]']

Unsinn. Das ist gar nicht machbar (dazu müsstest du ja Polygone abschneiden - ich will jetzt gar nicht genau über den nötigen Aufwand nachdenken). Außerdem zeigt "r_showtris 3" natürlich was ganz anderes.

Was Doom macht ist ein Z-First-Pass wodurch sämtliche Pixelshader nur für sichtbare Pixel durchlaufen.

du widersprichst dir gerade selbst. doom3 macht wie du schon gesagt hast einen z-first-pass. beim eigentlichen rendering im 2. pass werden dann nur mehr die sichtbaren pixel gerendert.

natürlich werden auch nicht sichtbare polygone an die grafikkarte geschickt, gerendert (rendering= ermitteln des endgültigen farbwertes für jeden pixel) werden aber nur mehr sichtbare oberflächen.

Coda

2006-06-24, 16:19:54

Das Rendering ist alles zusammen, nur weil man es zerlegt ist es noch lange nicht Overdraw-frei.

# Rendering (computer graphics) is the process of producing the pixels of an image from a higher-level description of its components.
Überhaupt ist das hier in der Diskussion völlig irrelevant, weil der Overdraw eben doch da ist, man spart nur die ALU-Leistung ein.

tokugawa

2006-06-24, 19:08:29

Gast[/POST]']du widersprichst dir gerade selbst. doom3 macht wie du schon gesagt hast einen z-first-pass. beim eigentlichen rendering im 2. pass werden dann nur mehr die sichtbaren pixel gerendert.

natürlich werden auch nicht sichtbare polygone an die grafikkarte geschickt, gerendert (rendering= ermitteln des endgültigen farbwertes für jeden pixel) werden aber nur mehr sichtbare oberflächen.

Rendering umfasst alles, auch ein reiner Z-Pass ist ein Renderpass.

Coda[/POST]']Was hier für ein Blödsinn verbreitet wird ist echt unglaublich. Natürlich macht jede moderne Engine HSR, aber dies perfekt zu machen wäre einfach unglaublich dämlich, weil man dafür jedes Polygon auf der CPU anschauen müsste und die Daten nur dynamisch pro Frame an die GPU schicken könnte.

100% Zustimmung! Danke!

Endlich jemand der auch mitaufsteht und mal klar sagt dass die Entwickler heut nicht faul sind und nicht mehr unsichtbares cullen, suboptimal programmieren, oder gar eine Verschwörung haben mit der Hardware-Industrie, um mehr Hardware zu verkaufen!

Hatte schon die Befürchtung dieser Punkt geht in der Diskussion etwas unter (da keiner auf mein letztes Posting geantwortet hat).

aths

2006-06-24, 20:39:17

Bei Doom 3 weiß ich allerdings nicht, inwieweit der Z-Pass der Performance hilft. Für die Stencil-Schatten braucht man Z sowieso, ansonsten müsste man testen, ob man den Color-Overdraw besser inkauf nimmt, wenn man dafür auf den ersten Pass verzichten kann.

loewe

2006-06-24, 21:00:11

aths[/POST]']Genau das ist ja das Problem: Highend- oder wenigstens Midend-HW von PVR steht nicht in Aussicht.
Das gilt erst einmal abzuwarten.
aths[/POST]']
Was die Leistung angeht: Ich hab gestern mit jemandem ein wenig über 3D-Wunschleistung beim NDS philosophiert, und da stellte sich heraus, dass ein MBX Lite zu schwachbrüstig wäre.
Wofür?
Was erwartest du von einem 25 MPixel Core?
Zeige mir einen Core mit mehr 3D Leistung bei weniger Stromverbrauch.
aths[/POST]']
Zum Glück hat man im PC-Bereich ganz andere Möglichkeiten bezüglich Chipgröße und Stromverbrauch. Aber wir sehen von PVR nichts – seit Jahren. Insofern halte ich es für nicht sinnvoll, anzudeuten, dass eine PVR-Highendlösung tatsächlich Highendleistung bieten würde. Soweit ich weiß ist SGX nicht mal in der größten Ausbaustufe das, was wir heute unter Highend verstehen.
Ja man hat andere Möglichkeiten, aber ob das gut ist?
Intel will mit Viiv in die Wohnzimmer, also am besten lüfterlose PCs. Da können sie keine Grafikkarte gebrauchen, die allein 500 W braucht. Ja ich weiß ich übertreibe.
Welche Leistung wird gebraucht? Sagen wir mal es sollten 1280x1024 bei 60 FPS möglich sein, schalte da noch 4xFSSA ein, da bist du sicher im Wohnzimmer gut bedient. Das alles bei geringem Stromverbrauch und möglichst billig. Highend muss es nicht sein, aber ausreichend. :)
Von SGX sind bisher 3 Versionen angekündigt, mehr erfolgt bei Bedarf.
SGX = Serie 5 = Eurasia, wir reden von einer Serie, die bisher nur für Handheld angekündigt ist und die auf jeden Fall 3 Serien weiter entwickelt ist als KYRO und ja, ich kann Zählen. ;)

Ailuros

2006-06-25, 08:37:32

Coda[/POST]']
HA?!? BSP gabs schon in der Grafik-Steinzeit (Doom).

Nur etwas fortschrittlicher in Quake3.

Meinst du "wie sie orientiert ist"? Weil wo die Kamera war war nämlich der einzig Faktor beim Quake-HSR (Lookup per Sektor welche anderen Sektoren von diesem aus sichtbar sind).

Ich meinte einfach dass die engine nicht in allen Faellen weiss in welche Richtung ich als Spieler glotze. Klingt's besser so?

Ailuros

2006-06-25, 09:01:49

aths[/POST]']Genau das ist ja das Problem: Highend- oder wenigstens Midend-HW von PVR steht nicht in Aussicht.

Gilt genauso fuer jeden "kleinen" IHV die in letzter Zeit der eine nach dem anderen verschluckt wird. Serie5 scheiterte in 2004 an Resourcen-Mangel. Das und mit IP kommt man sowieso nicht weit. Nur mit Dreamcast hatte damals Videologic gleichzeitig Glueck und Pech; Glueck weil es fuer seine Zeit tatsaechlich ein high end Design war und Pech weil die Console leider ein so miserables Schicksal hatte.

Dabei ist Videologic/IMG der einzige kleine der je etwas High end je vorgestellt hat und auch der einzige heutzutage der eine ziemlich geringe (zugegeben) Chance haette das Ganze zu wiederholen in der weniger absehbaren Zukunft.

Sie koennen froh sein dass sie immer noch unabhaengig sind.

Was die Leistung angeht: Ich hab gestern mit jemandem ein wenig über 3D-Wunschleistung beim NDS philosophiert, und da stellte sich heraus, dass ein MBX Lite zu schwachbrüstig wäre.

Low-end PDA/mobile. Vergleich aber dann gleich bitte gegen einen Imageon oder GoForce4500/4800.

Zum Glück hat man im PC-Bereich ganz andere Möglichkeiten bezüglich Chipgröße und Stromverbrauch. Aber wir sehen von PVR nichts – seit Jahren. Insofern halte ich es für nicht sinnvoll, anzudeuten, dass eine PVR-Highendlösung tatsächlich Highendleistung bieten würde. Soweit ich weiß ist SGX nicht mal in der größten Ausbaustufe das, was wir heute unter Highend verstehen.

Siehe meine vorigen Beitraege. Dass heisst aber nicht dass die Moeglichkeit nicht besteht mit X zusaetzlichen Features pro Watt Stromverbrauch bessere Leistung erreichen zu koennen. Und es nicht gerade so als ob heutzutage noch mehr Speicher-/Strom und Bandbreiten-Verbrauch nachgelassen haben.

Viele schielen momentan in Richtung Intel und was die mit Serie5 und den Thalia-L/Muse/Athena cores zu tun haben koennten. Als high end klingt das Zeug auch nicht; bevor es so weit kommen wuerde, koennte ich mir eher vorstellen dass Intel IMG einfach aufkauft, was mir als Idee nicht besonders gut bekommt persoenlich.

Eine Architektur die Speicher und Bandbreite spart waere fuer Intel's zukuenftige integrierten Designs ideal. Geht jetzt Intel noch einen Schritt weiter und traeumt von standalone GPUs dann kann es langfristig noch bunter aussehen. Ich glaub zwar selber noch nicht richtig dran aber:

http://www.jonpeddie.com/index.shtml

aths

2006-06-25, 14:06:44

loewe[/POST]']Das gilt erst einmal abzuwarten.Wie lange noch?

loewe[/POST]']Wofür?
Was erwartest du von einem 25 MPixel Core?
Zeige mir einen Core mit mehr 3D Leistung bei weniger Stromverbrauch.Bevor man fragt, wie viel der Chip pro Stromverbrauch (oder pro Transistor oder was auch immer) bringt, interessiert mich zunächst, ob er die gewünschte 3D-Leistung erreicht. Dann kann man gucken, welcher Chip, der die gewünschte Leistung bietet, wenig Strom frisst. Nun hat der NDS im Vergleich mit dem MBX Lite natürlich einen deutlich schwächeren 3D-Chip, es war auch nur eine Gedankenspielerei was man für Füllarte bräuchte bei zwei Texturen mit trilinear 2x AF (und 4x Antialiasing.) Gerade im mobilen Bereich wäre – erst recht bei der überschaubaren Dreiecks-Zahl, wie der NDS erlaubt – TBDR natürlich eine sehr gute Idee.

loewe[/POST]']Ja man hat andere Möglichkeiten, aber ob das gut ist?
Intel will mit Viiv in die Wohnzimmer, also am besten lüfterlose PCs. Da können sie keine Grafikkarte gebrauchen, die allein 500 W braucht. Ja ich weiß ich übertreibe.
Welche Leistung wird gebraucht? Sagen wir mal es sollten 1280x1024 bei 60 FPS möglich sein, schalte da noch 4xFSSA ein, da bist du sicher im Wohnzimmer gut bedient. Das alles bei geringem Stromverbrauch und möglichst billig. Highend muss es nicht sein, aber ausreichend. :)
Von SGX sind bisher 3 Versionen angekündigt, mehr erfolgt bei Bedarf.
SGX = Serie 5 = Eurasia, wir reden von einer Serie, die bisher nur für Handheld angekündigt ist und die auf jeden Fall 3 Serien weiter entwickelt ist als KYRO und ja, ich kann Zählen. ;)In Dingen Füllraten-Effizienz dürfte nicht mehr allzu viel zu machen gewesen sein. Eine 1280-er Auflösung mit 4x AA ohne aktive Grafikkühlung bringt bei vielen Spielen eine passive 6600 GT; ich fühle mich mit meiner passiven 7600 GT sehr gut bedient. Das ist aber kein Highend, dazu müssten Monster à la 7900 GX2 geschlagen werden. Ich behaupte mal dreist dass PowerVR derzeit nicht die Technologie hat, einen Chip zu bauen dessen Grafikkarten zu GTX-Preisen realisierbar wären und dabei gleiche oder bessere Leistung erzielt. Aber persönlich halte ich – bei allem Fortschritt, der notwendig ist – Highend-Karten für den Großteil der Nutzer für völlig uninteressant. 6600-GT-Niveau, meinetwegen 7600-GT-Niveau (bzw. ATIs Pendants dazu) dürfte für den normalen Spieler völlig ausreichend sein. Hier wäre mit TBDR-Technik vermutlich eine kühlere Grafikkarte möglich, zudem hat PowerVR eine 3D-Architektur entwickelt die die SM3-Forderungen übererfüllt. Leider scheint sich niemand im Desktop-Bereich dafür zu interessieren.

Während Kyro zu GF2-Zeiten etwa um Faktor 4 überlegen war, schätze ich den heutigen Vorteil einer DR-Architektur auf (knapp) Faktor 2. Angesichts heutiger Architekturbreiten dürfte sich die Dreiecks-Speicherung und das vorgezogene HSR eigentlich lohnen.

Gast

2006-06-25, 14:52:02

Coda[/POST]']Was hier für ein Blödsinn verbreitet wird ist echt unglaublich. Natürlich macht jede moderne Engine HSR, aber dies perfekt zu machen wäre einfach unglaublich dämlich, weil man dafür jedes Polygon auf der CPU anschauen müsste und die Daten nur dynamisch pro Frame an die GPU schicken könnte.

so dann erklär mir mal einer dieses phänomen mit etwas anderem als unfähigkeit/faulheit/nvidia/ati:

Wenn man in Richtung Bar schaut, unterscheiden sich die Frames von 50 zu 12fps auf ner r300, es ist, wohlgemerkt, außer der klozellenwand li oder rechts nichts zu sehen

aber ihr habt dafür eben auch keine antwort und basht dann argumente-los rum

StefanV

2006-06-25, 14:54:03

Den ATi Karten fehlt ein Befehl zur Schattenberechnung, der bei einigen Spielen 'nachgestellt' wird, was entsprechend viel Performance kostet.

Gab letztens einen Thread darüber, wie dieser Befehl hieß, ist mir gerad entfallen :|

tokugawa

2006-06-26, 01:10:16

Gast[/POST]']so dann erklär mir mal einer dieses phänomen mit etwas anderem als unfähigkeit/faulheit/nvidia/ati:

Wenn man in Richtung Bar schaut, unterscheiden sich die Frames von 50 zu 12fps auf ner r300, es ist, wohlgemerkt, außer der klozellenwand li oder rechts nichts zu sehen

aber ihr habt dafür eben auch keine antwort und basht dann argumente-los rum

Bashen tun nur die, die unwissenderweise den Entwicklern Faulheit vorwerfen.

Wir bashen nicht, wir wissen nur faktisch, dass dem ganz einfach nicht so ist.

Dass es zeitweise - natürlich szeneabhängig und nicht verallgemeinbar - zu Slowdowns irgendwelcher Art kommen kann, liegt nicht an "Unoptimiertheit" oder "Faulheit", sondern daran, dass man in der Echtzeitgrafik immer Kompromisse schließen muß. Jeder Algorithmus in der Echtzeitgrafik hat seine Schwachstellen, es gibt keinen einzigen Algorithmus, der für alle Fälle optimal geeignet ist.

Daher versucht man als Leveldesigner etwa, die Levels entsprechend der Engine-Technik zu bauen. Dass dem nicht immer so ist, dafür können die Programmierer nichts.

Vielleicht interessant in diesem Zusammenhang, dass auf dem Eurographics Symposium on Rendering in Zypern dieses Jahr von unserem Institut auch ein Beitrag da ist, bei dem es auch um bessere Visibility-Verfahren geht (vor allem im Vergleich zu BSP). Obwohl ich kaum glaube dass irgendjemand von euch dort sein wird :) - aber das Paper wird es wohl danach wohl öffentlich verfügbar geben.

Ailuros

2006-06-27, 06:45:03

Während Kyro zu GF2-Zeiten etwa um Faktor 4 überlegen war, schätze ich den heutigen Vorteil einer DR-Architektur auf (knapp) Faktor 2.

Faktor "4" inwiefern wenn man KYRO2 mit einer MX2 vergleicht? Kommt natuerlich ganz drauf was Du genau mit dem Faktoren-Zeug meinst.

Irgendwie klingt mir aber der Faktor 4 im ersten Vergleich uebertrieben; trotzdem wenn man diesen theoretischen Faktor halbieren wuerde, heisst es immer noch nicht dass heutige TBDRs an Vorteilen verloren haben. Du scheinst zu vergessen was fuer Vorteile DRs mit allem floating point generell haben. Wenn es IMRs schaffen langfristig schaffen alle floating point OPs effizienter mit Filterung und AA kombinieren zu koennen, dann wuerde ich erstmal von einem kleinere hypothetischen "Faktor" reden.

Anders und vereinfacht gefragt wo wuerde jemand den Speicher- und Bandbreiten-Verbrauch fuer nur 4xMSAA + 64bpp HDR in 1280*1024 genau einschaetzen?

6600-GT-Niveau, meinetwegen 7600-GT-Niveau (bzw. ATIs Pendants dazu) dürfte für den normalen Spieler völlig ausreichend sein. Hier wäre mit TBDR-Technik vermutlich eine kühlere Grafikkarte möglich, zudem hat PowerVR eine 3D-Architektur entwickelt die die SM3-Forderungen übererfüllt. Leider scheint sich niemand im Desktop-Bereich dafür zu interessieren.

Das aus verstaendlichen Gruenden keiner interessiert ist ein so grosses Risiko einzugehen und sich gegen ATI/NVIDIA zu schlagen sollte wohl klar sein. Aber die vaporware S5-GPU wuerde sich auch heute noch ausgezeichnet mit mainstream GPUs schlagen. Vorraussetzung waere eben zumindest 400MHz Taktrate.

***edit: hier ist wohl die brennende Frage wer so ein Ding bauen und vermarkten wuerde? Und warum wuerde IMG zu guter letzt in so ein Projekt investieren wenn sie mit standalone GPUs nur einen miserablen Bruchteil an Einheiten (siehe royalties pro chip) bekommen wuerden im Vergleich zu dem was der PDA/mobile nur als einziges Beispiel bringen kann. In knapp zwei Jahren sind sie bald ueber 11M Einheiten nur mit MBX. Hat KYRO damals viel mehr als 2M Einheiten in 2 Jahren verkauft?

Coda

2006-06-27, 10:11:52

Gast[/POST]']Wenn man in Richtung Bar schaut, unterscheiden sich die Frames von 50 zu 12fps auf ner r300, es ist, wohlgemerkt, außer der klozellenwand li oder rechts nichts zu sehen
Welches Spiel meinst du jetzt?

Ailuros[/POST]']Nur etwas fortschrittlicher in Quake3.
Nö.

Ailuros[/POST]']Ich meinte einfach dass die engine nicht in allen Faellen weiss in welche Richtung ich als Spieler glotze. Klingt's besser so?
Sie weiß es, aber sie macht nichts damit was HSR angeht.

loewe

2006-06-27, 20:00:13

aths[/POST]']Wie lange noch?
Eine sehr schwere Frage, aber da ist Licht am Ende des Tunnels und selbst ImgTec hat PC-Grafik wieder in der Pipeline. :)
aths[/POST]']Bevor man fragt, wie viel der Chip pro Stromverbrauch (oder pro Transistor oder was auch immer) bringt, interessiert mich zunächst, ob er die gewünschte 3D-Leistung erreicht. Dann kann man gucken, welcher Chip, der die gewünschte Leistung bietet, wenig Strom frisst. Nun hat der NDS im Vergleich mit dem MBX Lite natürlich einen deutlich schwächeren 3D-Chip, es war auch nur eine Gedankenspielerei was man für Füllarte bräuchte bei zwei Texturen mit trilinear 2x AF (und 4x Antialiasing.) Gerade im mobilen Bereich wäre – erst recht bei der überschaubaren Dreiecks-Zahl, wie der NDS erlaubt – TBDR natürlich eine sehr gute Idee.
Es entzieht sich völlig meiner Kenntnis warum NDS oder PSP oder ähnliche Geräte nicht auf PowerVR Technologie setzen, aber TBDR wäre sicher dort überall eine gute Idee.
aths[/POST]']In Dingen Füllraten-Effizienz dürfte nicht mehr allzu viel zu machen gewesen sein. Eine 1280-er Auflösung mit 4x AA ohne aktive Grafikkühlung bringt bei vielen Spielen eine passive 6600 GT; ich fühle mich mit meiner passiven 7600 GT sehr gut bedient. Das ist aber kein Highend, dazu müssten Monster à la 7900 GX2 geschlagen werden. Ich behaupte mal dreist dass PowerVR derzeit nicht die Technologie hat, einen Chip zu bauen dessen Grafikkarten zu GTX-Preisen realisierbar wären und dabei gleiche oder bessere Leistung erzielt.
Da werden wir uns sicher nicht einig werden! *g*
Ich bin sicher das sie die Technologie haben. ;)
Serie 5 ist auf jeden Fall Direct3D10 kompatible, auch wenn gegenwärtig nur Dx9+ genannt wird, was sicher für die angekündigten SGX Cores auch stimmen wird.
Was noch fehlt ist Leistung und die sollte mit dieser sehr flexiblen Architektur möglich sein.
aths[/POST]']Aber persönlich halte ich – bei allem Fortschritt, der notwendig ist – Highend-Karten für den Großteil der Nutzer für völlig uninteressant. 6600-GT-Niveau, meinetwegen 7600-GT-Niveau (bzw. ATIs Pendants dazu) dürfte für den normalen Spieler völlig ausreichend sein. Hier wäre mit TBDR-Technik vermutlich eine kühlere Grafikkarte möglich, zudem hat PowerVR eine 3D-Architektur entwickelt die die SM3-Forderungen übererfüllt. Leider scheint sich niemand im Desktop-Bereich dafür zu interessieren.
Hier stimme ich Dir absolut zu. Ich weiß nicht ob intel oder wer auch immer einen Kampf mit ATI und NV aufnehmen will, aber wir werden sehen.
aths[/POST]']Während Kyro zu GF2-Zeiten etwa um Faktor 4 überlegen war, schätze ich den heutigen Vorteil einer DR-Architektur auf (knapp) Faktor 2. Angesichts heutiger Architekturbreiten dürfte sich die Dreiecks-Speicherung und das vorgezogene HSR eigentlich lohnen.
Du gehst sehr viel höher ran als ich es tun würde.
PowerVR ist nach wie vor recht effizient und ich bleibe bei etwa einem Faktor von 2.
AiL hat es schon gesagt, die alte Serie 5 (hat nicht viel mit der jetzigen gemein), also die die SEGA lizensiert hat, würde sich im Mittelklasse Segment sicher noch recht gut schlagen, gescheitert ist sie AFAIK letztendlich wieder an der zu geringen Leistung.

aths

2006-06-27, 21:19:42

Ailuros[/POST]']Faktor "4" inwiefern wenn man KYRO2 mit einer MX2 vergleicht? Kommt natuerlich ganz drauf was Du genau mit dem Faktoren-Zeug meinst.Kyro 2 zur GeForce 2.

loewe[/POST]']Da werden wir uns sicher nicht einig werden! *g*
Ich bin sicher das sie die Technologie haben. ;)
Serie 5 ist auf jeden Fall Direct3D10 kompatible, auch wenn gegenwärtig nur Dx9+ genannt wird, was sicher für die angekündigten SGX Cores auch stimmen wird.
Was noch fehlt ist Leistung und die sollte mit dieser sehr flexiblen Architektur möglich sein.Dann wirst du dich eben nicht mit mir einig – nur hast du außer Vermutungen wenig anzubieten. Worauf beruht zum Beispiel deine Sicherheit, dass Serie 5 D3D10-kompatibel sein soll?

loewe[/POST]']Hier stimme ich Dir absolut zu. Ich weiß nicht ob intel oder wer auch immer einen Kampf mit ATI und NV aufnehmen will, aber wir werden sehen.Warum sollte Intel das tun? XGI ist (ziemlich kläglich) gescheitert, Matrox seit Jahren abgemeldet – die verdienen schon noch im Profi-Bereich, auch im 3D-Bereich, aber Volumenabsatz zieht anders aus. Von 3DLabs höre ich in letzter Zeit auch sehr wenig. Ob man irgendwelche Hoffnungen in S3 setzen kann, halte ich für immer unwahrscheinlicher. Und ATI und Nvidia decken jeweils praktisch den gesamten Markt ab. Um einen Konkurrenten in einem bestimmten Bereich aus dem Feld zu drücken, hätten beide vermutlich auch die finanziellen Ressourcen.

loewe[/POST]']Du gehst sehr viel höher ran als ich es tun würde.Kyro 2 kann mit 2 TMUs bei geringerem Takt die GeForce 2 GTS mit 8 TMUs öfters schlagen.

Gast

2006-06-27, 21:32:13

aths[/POST]']

Kyro 2 kann mit 2 TMUs bei geringerem Takt die GeForce 2 GTS mit 8 TMUs öfters schlagen.

öfters würde ich nicht gerade sagen, vor allem wenn trilineare filterung zum einsatz kommt, hat sie praktisch keine chance mehr gegen die GF2GTS.

aths

2006-06-28, 00:47:24

Gast[/POST]']öfters würde ich nicht gerade sagen, vor allem wenn trilineare filterung zum einsatz kommt, hat sie praktisch keine chance mehr gegen die GF2GTS.Stimmt auch wieder. Außerdem kann die GF2 quasi-perfektes 2x AF, und hat eben die T&L-Unit, die in (einigen, wenigen für die GTS brauchbaren Spiele) etwas mithilft.

Gast

2006-06-28, 14:21:17

dafür hat die kyro
- viel schnelleres fsaa, das gabs bei der gf2 afaik noch gar nicht
- einen 16bit hq modus, der fast 32bit qualität bringt im ggs. zur 16bit nvidia
- embm
- soft t&l
- 8 layertexturen
- konstantere fps wg. konstanteren polycounts

Gast

2006-06-28, 14:51:54

Gast[/POST]']dafür hat die kyro
- viel schnelleres fsaa, das gabs bei der gf2 afaik noch gar nicht

nicht wirklich, gerade beim FSAA hat sich die geringe füllrate schmerzlich bemerkbar gemacht, es war auch nur OG und hatte damit auch keine qualitätsvorteile. die voodoo5 hatte mit ihrem RGSSAA eine deutlich bessere qualität, schon bei 2 samples.
das FSAA der kyro und GF2 GTS war gleich (un)brauchbar.

- einen 16bit hq modus, der fast 32bit qualität bringt im ggs. zur 16bit nvidia

stimmt, zusätzlich gab es mit 32bit praktisch keinen leistungsverlust.
nicht so schön dagegen, dass die kyro mit trilinearer filterung (die eigentlich seit der GF1 standard war) ziemlich stark eingebrochen ist und AF erst garnicht im angebot hatte.
mit trilinearer filterung war die kyro2 dann "nur" mehr ein guter GF2MX-konkurrent, hatte gegen (die natürlich deutlich teurere) GF2GTS allerdings keine chance mehr.

ob einem die bessere (und schnellere) texturfilterung oder 32bit-rendering wichtiger war ist natürlich geschmacksache. imo hat man 16bit bei den damaligen spielen noch kaum gesehen, mip-banding stört mich allerdings seit die texturfilterung erfunden wurde ;)
auf beiden seiten musste man jedenfalls kompromisse eingehen (es sei denn man kaufte sich gleich eine GF2GTS, da gab es schnelles 32bit-rendering+ gute und schnelle texturfilterung)

- embm

stimmt, spielte zwar genauso wie dot3-bump-mapping keine praktische rolle (beides erlebte eigentlich erst als shader sein revival), man kann aber nvidia durchaus vorwerfen die entwicklung durch das weglassen dieses features gebremst zu haben.

- soft t&l

kam erst sehr spät, und was soll daran ein vorteil sein? hw-t&l ist auf jeden fall besser (ohne jetzt mal auf den praktischen nutzen des ganzen t&l-hypes einzugehen)

- 8 layertexturen

sicher nice to have, aber was bringt es, erst recht mit so wenig füllrate?

- konstantere fps wg. konstanteren polycounts
???
was soll das heißen? wieso sollten die polygonzahlen bei der kyro konstanter sein?
die grafikkarte hat jene polygone zu bearbeiten welche ihr von der grafikengine übergeben werden und hat dabei garkeine wahl.
möglich dass die fps in gewissen szenen, wenn plötzlich viel overdraw aufgetreten ist konstanter waren, das zu verallgemeinern halte ich allerdings für gewagt.

Ailuros

2006-06-29, 00:47:26

aths[/POST]']Kyro 2 zur GeForce 2.

KYRO2 war GF2 MX Konkurrenz, vom Preis alleine schon her. Und mit einem durchschnittlichen Faktor "4" schlug die K2 selbst die MX garantiert nicht. Faktor 2 waere dann schon naeher an der damaligen Realitaet mit 32bpp und/oder SSAA.

Dann wirst du dich eben nicht mit mir einig – nur hast du außer Vermutungen wenig anzubieten. Worauf beruht zum Beispiel deine Sicherheit, dass Serie 5 D3D10-kompatibel sein soll?

Es wuerde mich verdammt wundern wenn Serie5 nicht D3D10 kompliant waere. Natuerlich erwarte ich nicht ein solches Niveau fuer low end PDA/mobile chips, aber wo steckst Du procedural geometry genau ein?

Warum sollte Intel das tun? XGI ist (ziemlich kläglich) gescheitert, Matrox seit Jahren abgemeldet – die verdienen schon noch im Profi-Bereich, auch im 3D-Bereich, aber Volumenabsatz zieht anders aus. Von 3DLabs höre ich in letzter Zeit auch sehr wenig. Ob man irgendwelche Hoffnungen in S3 setzen kann, halte ich für immer unwahrscheinlicher. Und ATI und Nvidia decken jeweils praktisch den gesamten Markt ab. Um einen Konkurrenten in einem bestimmten Bereich aus dem Feld zu drücken, hätten beide vermutlich auch die finanziellen Ressourcen.

Nochmal ich erwarte bis jetzt was den mainstream oder high end Markt betrifft absolut nichts von Intel. Ich bezweifle sogar dass sie sich in der Zukunft ausserhalb von IGPs bewegen werden, aber falls sie tatsaechlich irgendeine merkwuerdige budget standalone Loesung planen sollten, dann auch nur weil Intel langfristig Angst hat dass ATI/NVIDIA auf die eine oder andere Art in Intel's Maerkte eingreift. Erstens stehen stream Prozessoren bzw. (faehigere) GPGPUs vor der Tuer und zweitens plant NV in den render farm Markt einzudringen. Was machen normalerweise grosse Firmen in solchen Faellen? Sie greifen jeden potentiellen Konkurrenten (oder versuchen zumindest) in seinem eigenen Spielfeld an.

Ob, wie und wann so etwas Intel vorhaben koennte ist mir unbekannt, aber die Geruechte haeufen sich auf und selbst irgendeine Billig-loesung von Intel wuerde ich momentan nicht ausschliessen. Ob und wie dabei PVR IP benutzt wird ist nebensaechlich. Wie gesagt je ambitionsreicher Intel's Plaene sind desto groesser die Chancen dass sie im Notfall IMG aufkaufen anstatt grosse Summen an Royalties abzuzahlen.

Wo ich mich umdrehe in letzter Zeit gibt es nicht einen einzigen Verbraucher der potentiellere low-end Produkte (jeglicher Art) nicht wuenschen wuerde. Ja Intel's Umsatz vom IGP Geschaeft koennte man als ausreichend ansehen, aber wer genau sagt dass Intel ihren Umsatz nicht steigern will oder dass sie genau das obrigen schon seit einiger Zeit nicht erkannt haben?

Kyro 2 kann mit 2 TMUs bei geringerem Takt die GeForce 2 GTS mit 8 TMUs öfters schlagen.

Unter ein paar Vorraussetzungen ja, aber im Durchschnitt war und verbleibt die K2 GF2MX Konkurrenz. Schaltet man TC ab und trilinear an, ist eine K2 hoffnungslos verloren gegen eine GTS. Das soll jetzt nicht zum Wiederspruch zu allem anderen kommen, aber KYRO erschien auf dem Markt als low-end Produkt und ich bin ein klein bisschen allergisch gegen Uebertreibungen. Gegen die MX dieser Zeit positionierte sich die K2 ausgezeichnet und noch besser gegen die damaligen budget-Radeon Loesungen.

aths

2006-06-29, 12:07:24

Gast[/POST]']dafür hat die kyro
- viel schnelleres fsaa, das gabs bei der gf2 afaik noch gar nichtDoch, gabs.
Gast[/POST]']- einen 16bit hq modus, der fast 32bit qualität bringt im ggs. zur 16bit nvidiaAuf der GeForce 2 GTS hat man dann halt in 32 Bit gespielt.
Gast[/POST]']- embmSpiele haben damals leider sogut wie ne EMBM genutzt, auch Dot3 BM war extrem selten.
Gast[/POST]']- soft t&lSoftware-T&L gibts für jede D3D7-kompatible Karte.
Gast[/POST]']- 8 layertexturenPerformance-Frage, auf der GeForce 2 war dann Multipass nötig.
Gast[/POST]']- konstantere fps wg. konstanteren polycountsDas verstehe ich jetzt nicht.

aths

2006-06-29, 12:17:27

Ailuros[/POST]']KYRO2 war GF2 MX Konkurrenz, vom Preis alleine schon her. Und mit einem durchschnittlichen Faktor "4" schlug die K2 selbst die MX garantiert nicht. Faktor 2 waere dann schon naeher an der damaligen Realitaet mit 32bpp und/oder SSAA.Soweit ich mich erinnere, war schon Kyro 1 ungefähr auf dem Leistungsniveau der GeForce 2 MX – und grub ihr in 32 Bit das Wasser ab.

Ailuros[/POST]']Es wuerde mich verdammt wundern wenn Serie5 nicht D3D10 kompliant waere. Natuerlich erwarte ich nicht ein solches Niveau fuer low end PDA/mobile chips, aber wo steckst Du procedural geometry genau ein? Nur weil dieses Feature vielleicht auf D3D10-Niveau ist, muss es der Rest noch lange nicht sein. Wann wurde Serie 5 entwickelt?

Ailuros[/POST]']Ob, wie und wann so etwas Intel vorhaben koennte ist mir unbekannt, aber die Geruechte haeufen sich auf und selbst irgendeine Billig-loesung von Intel wuerde ich momentan nicht ausschliessen. Ob und wie dabei PVR IP benutzt wird ist nebensaechlich. Wie gesagt je ambitionsreicher Intel's Plaene sind desto groesser die Chancen dass sie im Notfall IMG aufkaufen anstatt grosse Summen an Royalties abzuzahlen.Gleich ganz IMG aufkaufen? Die haben doch noch Felder, die Intel nicht interessieren dürften.

Ailuros[/POST]']Unter ein paar Vorraussetzungen ja, aber im Durchschnitt war und verbleibt die K2 GF2MX Konkurrenz. Schaltet man TC ab und trilinear an, ist eine K2 hoffnungslos verloren gegen eine GTS. Das soll jetzt nicht zum Wiederspruch zu allem anderen kommen, aber KYRO erschien auf dem Markt als low-end Produkt und ich bin ein klein bisschen allergisch gegen Uebertreibungen. Gegen die MX dieser Zeit positionierte sich die K2 ausgezeichnet und noch besser gegen die damaligen budget-Radeon Loesungen.Ok, einigen wir uns darauf, dass es stark von den Grafiksettings abhängt, welche Lösung der anderen überlegen war? Ohne TC ist die Kyro bei trilinearer Filterung wirklich arschlahm. Also Low-End würde ich aber weder Kyro noch Kyro 2 betrachten.

Gast

2006-06-29, 12:25:45

aths[/POST]']Soweit ich mich erinnere, war schon Kyro 1 ungefähr auf dem Leistungsniveau der GeForce 2 MX – und grub ihr in 32 Bit das Wasser ab.

nicht wirklich, die kyro2 war meistens nur etwas schneller als die GF2MX.

mit 16bit+tri-filterung war sogar meistens die GF2MX schneller, erst mit 32bit konnte man das blatt wenden.

GF2GTS-niveau war nur in sehr seltenen fällen mit extremen overdraw möglich, im durchschnitt war sie nur knapp über der GF2MX.

Gast

2006-06-29, 13:23:28

aths[/POST]']Doch, gabs.
Auf der GeForce 2 GTS hat man dann halt in 32 Bit gespielt.
Das verstehe ich jetzt nicht.

die k2 war preislich auch nicht die gts sondern die mx konkurrenz.
wegen overdraw-resistenz konstantere frameraten bei hohem od in ultima9 z.B.

aths

2006-06-29, 14:14:50

Gast[/POST]']die k2 war preislich auch nicht die gts sondern die mx konkurrenz.
wegen overdraw-resistenz konstantere frameraten bei hohem od in ultima9 z.B.Ultima IX lief anfangs noch auf einer GeForce 3 schlechter als auf einer Kyro 1 – das war iirc ein Problem im Treiber. Jede Voodoo 3 kann andererseits Ultima IX anständig rendern, und das wo Voodoo 3 nicht mal Early-Z hat.

Gast[/POST]']nicht wirklich, die kyro2 war meistens nur etwas schneller als die GF2MX.

mit 16bit+tri-filterung war sogar meistens die GF2MX schneller, erst mit 32bit konnte man das blatt wenden.

GF2GTS-niveau war nur in sehr seltenen fällen mit extremen overdraw möglich, im durchschnitt war sie nur knapp über der GF2MX.Angesichts der 16-Bit-"Qualität" auf Nvidia-Karten rate ich bei GeForce dazu, wann immer möglich, den 32-Bit-Modus zu nehmen – nur war das gerade auf der MX angesichts den dann herrschenden Frameraten nicht immer möglich. Da die Kyro in 16 Bit eine mit 32 Bit fast gleichwertige Grafik bot, wäre es aber in jedem Fall unfair, Kyro- und GeForce-Leistung in 16 Bit zu vergleichen. In 32 Bit konnte die Kyro 2, jedenfalls bei bilinearer Filterung oder Verwendung von komprimierten Texturen (die ja komprimiert deutlich besser aussahen als auf der GeForce) soweit ich weiß oft mit der GeForce 2 GTS mithalten.

Ein Nachfolger mit 4 statt 2 Pipes und etwas höherem Takt (sagen wir 233 MHz) sowie DX8-Compliance (im Pixelteil dürfte nicht viel gefehlt haben) hätte wahrscheinlich die GeForce 3 abrulen können.

Gast

2006-06-29, 14:24:45

Also ich finde, dass die 16Bit Qualität der Geforce sich mit der Qualität jeder anderen Karte (ausgenommen Kyro) messen kann. Habe selbst ATI, Nvidia, 3dfx und Kyro Karten gehabt und auch wenn es Unterschiede in der 16 Bit Qualität (im Dithering) gibt, so hat jede der Karten ihre Vor- und Nachteile.

Gast

2006-06-29, 14:49:33

Gast[/POST]']Also ich finde, dass die 16Bit Qualität der Geforce sich mit der Qualität jeder anderen Karte (ausgenommen Kyro) messen kann. Habe selbst ATI, Nvidia, 3dfx und Kyro Karten gehabt und auch wenn es Unterschiede in der 16 Bit Qualität (im Dithering) gibt, so hat jede der Karten ihre Vor- und Nachteile.

die 16bit-qualität von 3dfx war auch besser, ATI, matrox etc. waren aber auf gleichem niveau.

Ailuros

2006-06-30, 06:55:39

aths[/POST]']Soweit ich mich erinnere, war schon Kyro 1 ungefähr auf dem Leistungsniveau der GeForce 2 MX – und grub ihr in 32 Bit das Wasser ab.

Nach der K1 drehten sich aber nicht besonders viele damals um, ausser ein paar Techfreaks.

Nur weil dieses Feature vielleicht auf D3D10-Niveau ist, muss es der Rest noch lange nicht sein. Wann wurde Serie 5 entwickelt?

Wo genau hat D3D10 programmierbare Tesselation oder entgeht mir hier etwas?

Unter anderen Umstaenden waere die S5 GPU auf Regalen erschienen mit getrennten PS/VS. Eurasia hat vereinte Einheiten und hat Metagence's multi-/super-threading zusaetzliche Optimierungen.

Gleich ganz IMG aufkaufen? Die haben doch noch Felder, die Intel nicht interessieren dürften.

Welche dieser Felder waeren genau "nutzlos" fuer Intel? Wo wird Ensigma/Metagence IP genau eingesetzt und wieso wuerde Intel davon nicht profitieren?

Relevante Lektuere mit etwas IMG marketing Weihrauch natuerlich:

http://www.audiodesignline.com/showArticle.jhtml?articleID=183701195

Ok, einigen wir uns darauf, dass es stark von den Grafiksettings abhängt, welche Lösung der anderen überlegen war? Ohne TC ist die Kyro bei trilinearer Filterung wirklich arschlahm. Also Low-End würde ich aber weder Kyro noch Kyro 2 betrachten.

$150 MSRP fuer K2. Und ich bestehe immer noch darauf nach all den Jahren dass man die original geplante K3@166MHz nicht fuer die K2 haette stornieren sollen. K3 hatte nicht nur doppelt so viele pipelines und (faehigere) TMUs, DDR support, schnelles trilinear als auch 16xAF gehabt sondern auch eine T&L Einheit die noch staerker als Elan/Arcade gewesen waere. Der Preis waere zwar auf GF2 GTS gelegen zu der Zeit aber diese K3 haette genau dass einer GTS angerichtet was die K2 der MX vermerkte. Noch ein Stueck weiter die Lebenszeit waere laenger gewesen.

K2 war als mainstream zu low-end geplant, genau eben weil ST Micro ein paar Luecken bei TSMC fuellen wollte und viel zu wenig investiert hat damals. ST' Malta FAB produzierte nur 250nm billig-Zeug und fuer 180nm hatten sie damals einen fixen Vertrag bei TSMC.