Die aktuelle Entwicklung bei S3 Graphics
22. November 2005 / von robbitop / Seite 2 von 4
Die Chrome-2X-Serie kann sogar noch mehr: Pro Pixelpipeline sind nun zwei Pixelshader-Rechenwerke vorhanden. Laut unseren Informationen entspricht jede dieser ALUs noch der GammaChrome-Serie. Der Trend der Auslegung aktueller Pipelines scheint sich seit einiger Zeit in Richtung arithmetischer Stärke anstatt reiner Texturleistung zu verlagern. Auch S3 ging mit dem GammaChrome und nun mit der Chrome-2X-Serie diesen Weg.
Nach einer genaueren Untersuchung des anisotropen Texturfilters fielen uns zwei grobe Schwächen auf: Erstens scheint bei der Nutzung des anisotropen Filters die trilineare Filterung nicht zu funktionieren. Es wird also nur bilinear anisotrop gefiltert. Dies kann zu störenden Bugwellen führen. Dieser Aspekt ist laut Beyond3D im GammaChrome noch immer vorhanden.
Eine weitere unangenehme Entdeckung ist die Neigung zum Schimmern in ungewöhnlichen Maßen bei relativ hochfrequenten Texturen unter Nutzung des anisotropen Filters. Der trilineare Filter selbst macht diesbezülich noch keine Probleme. Aber sobald der anisotrope Filter wirkt, ergibt sich bei hochfrequenten Texturen ein unschönes Flimmern und Bildung von Moiré-Mustern.
Im hinteren Bereich des Bodens fällt das Moiré-Muster deutlich auf. In Bewegung wirkt das ganze noch drastischer (Klicken für große Ansicht). |
Mit Änderung des LOD (Level of Detail) in den positiven Bereich ergibt sich eine Besserung, doch wird die Schärfe des anisotropen Filters dadurch wieder zerstört. Ob das Shimmering-Problem im GammaChrome behoben wurde, können wir leider mangels Testsample nicht beurteilen.
Wie bereits erwähnt, verfügt der DeltaChrome über ein Sparsed Grid Supersampling Anti-Aliasing. Dieses kann mit 2, 5 oder 9 Samples betrieben werden. Da die maximale Rendergröße (Rendertargetsize) auf 2048x2048 beschränkt ist, wird der Bereich der nutzbaren Anti-Aliasing Modi deutlich verringert. Beim Supersampling Anti-Aliasing Verfahren, welches beim DeltaChrome (und allen anderen Columbia-basierenden Produkten) zum Einsatz kommt, rendert der Chip intern die Szene mit höherer Auflösung. Beispielsweise wird also 1024x768 mit 2x Supersampling dadurch erzeugt, daß das Bild intern in der Größe von 1024x1536 oder 2048x768 (Verdopplung einer der beiden Kanten) gerendert und dann zur Ausgabe auf 1024x768 wieder heruntergerechnet wird.
Die Performance des DeltaChromes ist jedoch in den meisten Fällen sowieso zu gering, um ein Supersampling mit höherer Sampleanzahl (wie 5x oder 9x) spielbar zu gestalten. Allerdings veranlassten uns das Subpixelmuster, die "krummen" AA-Modi und die Rendertargetsize zum Nachdenken. Ein Grafikchip auf Sparsed Grid Supersampling auszulegen kostet viel Mühe und Transistoren. Eine Restriktion dieses hohen Aufwandes über das Rendertargetsize erscheint dann unlogisch. Die Subpixel sind außerdem äußerst untypisch gleichmäßig zueinander verteilt.
Dies impliziert, dass der DeltaChrome eigentlich nur ein ordered Grid unterstützt. Wir sind somit der Meinung, dass das zu rendernde Bild in Wirklichkeit um den gewünschten Winkel um die Z-Achse gedreht und dann gerendert wird. Die Abtastung der Subpixel bleibt natürlich gleich. Nach dem Rendern dreht der Pixelshader das Bild zurück, daraus resultiert rein praktisch ein sparsed Grid. Allerdings ergibt sich dadurch ein Verschnitt beim Rendern, der allerdings weder auf die Render Taget Size noch auf die Performance einen maßgeblichen Einfluss hat. Dieser wird nämlich vor dem eigentlichen Rendern von den HSR Units "weggecullt".
Der Treiber dreht die gesamte Szene auf geometrischem Weg und lässt diese rendern.
Der Ausschnitt im obigen Bild wird nun "herausgeschnitten" und mittels Pixelshader gedreht: et voila Sparsed Grid Anti-Aliasing.
Etwas anderes ist uns zudem bei den Untersuchungen des DeltaChrome außerdem aufgefallen: Seit dem G1-Treiber ist S3 offenbar ein Fehler bei oben genannter Prozedur zum Drehen des Gitters unterlaufen.
So sollte es sein ... | ... so aber sieht es aus. |
Das resultierende Subpixelmuster bei 2x SSAA ist nun suboptimal ausgerichtet. Die beiden Samples liegen nun exakt auf dem Rand des Pixels und überlappen zwischen mehreren Pixeln. Auf den ersten Blick sieht das Muster nach 4 Samples aus. Nach genauerem Hinsehen fällt auf, dass es sich hierbei um überlappende Samples aus anderen Pixeln und diesem Pixel handelt. Das Ergebnis ist ebenfalls als suboptimal zu bezeichnen. Die Kanten in Spielen werden im Gegensatz zu vorher kaum noch geglättet. Aus unserer Sicht ein großer faux pas, der trotz mehrfacher Meldung bei S3 bisher noch nicht korrigiert worden ist (seit mehr als 6 Monaten).
Im GammaChrome ist das zweifache Anti-Aliasing, wie auch im DeltaChrome, aufgrund der suboptimalen Subpixelmaske leider ebenfalls eher unbrauchbar. Jedoch hat S3 die Rendertarget Size nun auf 4096x4096 erhöht. Somit ist das fünffache Antialiasing nun auch durchgängig funktional. Leider genügt die Performance in keinem der S3 Graphics Produkte, um diesen Modus sinnvoll einzusetzen.
Bei einigen Nachuntersuchungen des DeltaChromes fiel uns auf, dass dieser bei Nutzung von Alpha Blending extrem einbrach - weit stärker als dies üblich ist. Flüssig laufende Spiele wurden auf einmal zu einer regelrechten Ruckelorgie. Beispielsweise brach bei Need for Speed: Underground die Performance drastisch ein, sobald durch Reifendurchdrehen etwas Qualm erzeugt wurde. Bei Max Payne 2 ergibt sich ein ähnliches Bild. Das gesamte Spiel läuft auf dem DeltaChrome mit einer überraschend hervorragenden Leistung. Kommt jedoch ein wenig Rauch ins Spiel, ist nur noch ein Bruchteil der ursprünglichen Performance nutzbar.
Alphablending ist ein Verfahren, um Transparenzeffekte mit 256 Intensitäten (8 Bit Integer) zu gewährleisten. Darunter fällt beispielsweise Rauch oder transparenter Nebel, der die dahinterliegende Umgebung sanft oder ganz verdeckt. Hierfür ist die Vorsortierung des Rendervorganges nötig, damit die Transparenz richtig angewandt werden kann. Das kostet CPU-Leistung und Bandbreite (Texturwechsel lässt die Texturcaches leer laufen). Der Einsatz von Alphablending ist also relativ kostspielig.
Auf Anfrage bei S3 Graphics ergab sich, dass es sich hierbei um einen Bug im DeltaChrome handelt. Dieser müsste per Treiber an jedes einzelne Spiel angepasst werden, das kostet viel Zeit. Im GammaChrome ist dieser Bug allerdings bereits in Hardware gefixt.