PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : S3 Graphics & Shader-Compiler


stickedy
2004-03-25, 19:22:06
Für den Fall, dass es übersehen wird:

"Just like NVIDIA and ATI S3 Graphics is currently developing a special improved compiler for shaders to incorporate it into its drivers. The new compiler will bring a performance advantage to the DeltaChrome chips, but its main target is the GammaChrome architecture. It is possible to expect that GammaChrome will take a very substantial advantage of the compiler in addition to generally revamped architecture."
http://www.xbitlabs.com/articles/editorial/display/cebit2004-3.html

Damit dürfte die mäßige PS-Performance des DeltaChromes ansteigen. Falls da ähnliche Sprünge wie bei NVidias Shader-Compiler möglich sind, sogar ein ganzes Stück...

Demirug
2004-03-25, 19:29:47
Zwischen dem Marketing und der Realität liegt beim S3 im Moment der Faktor 3. Zumindestens aufgrund der letzten Testdaten die ich gesehen habe.

Gast
2004-03-28, 17:57:28
ha, es gibt keinen deltachrome im Markt.

VooDoo7mx
2004-03-28, 18:08:42
Wenn man das Marketinggeblubber jetzt mal außen vor lässt, scheint der DeltaChrome sozusagen das 1. Experiment von S3 sein, wieder im Markt einzusteigen. Der Gammachrome könnte von der Mehrperformance ein ähnlicher Refresh wie der NV30-->NV35 erfahren, gepaart mit dem neuen Treiber+ höheren Taktraten undguter Lieferbarkeit, könnte uns ein sehr interessanter Grafikchip erwarten.


Oops ich sehe gerade, wir sind hier nicht im Spekulationsforum ;)

robbitop
2004-03-28, 18:46:15
war Gammacrome nicht ein DC mit nativem PCI-E Support?
Das einzig neue was ich beim Gammachrome gesehen habe war das Flip Chip Package.
S3 arbeitet bereits am DC Nachfolger, ich glaube nicht, dass Ressourcen/Zeit für größere Änderungen da war.

Xmas
2004-03-29, 15:34:55
GammaChrome ist mehr als ein DeltaChrome mit PCI-E. Wieviel mehr, weiß ich allerdings nicht.

robbitop
2004-03-29, 18:07:50
naja was vA fehlt ist ein CBMC Pendant.
Colorcompression braucht man ja erst ab MSAA und das werden sie wohl nicht mehr reinbekommen haben

Gast
2004-03-29, 20:56:26
Original geschrieben von robbitop
naja was vA fehlt ist ein CBMC Pendant.
Colorcompression braucht man ja erst ab MSAA und das werden sie wohl nicht mehr reinbekommen haben

Colorcompression braucht man nicht nur bei MSAA, und wie ich heute in einem älteren PDF gelesen habe gibt es sogar Möglichkeiten FB- und ZB-Kompression ohne MSAA zu realisieren. Man erreicht sogar lossless Kompressionsfaktoren bis >4. Gerade der DeltaChrome mit seiner 128bit-Speicheranbindung würde davon also besonders stark profitieren.

robbitop
2004-03-29, 21:39:00
eine Colorcompression ohne AA ist denkbar aber auch deutlich komplexer und ineffizienter.
Z-Compression geht doch auch so

Gast
2004-03-30, 10:32:32
Original geschrieben von robbitop
eine Colorcompression ohne AA ist denkbar aber auch deutlich komplexer und ineffizienter.
Z-Compression geht doch auch so

Natürlich ist es komplizierter, aber wenn du bei der Z-Buffer und Frame-Buffer Bandbreite (auch ohne MSAA) 75% einsparen kannst, dann lohnen sich die Transistoren schon.

Laut dem PDF haben sie im Mittel eine 4fache Kompression bei einer Tilegröße von 16x16 und mit Fixed DDCPM als Kompressionsalgo erreicht.

Damit würde dann eine 64bit Speicheranbindung dieselbe Leistung erreichen wie eine 256bit Anbindung (natürlich nur theoretisch, da die Texturen außen vor sind, aber die Tendenz stimmt). Zusammen mit 4xMSAA könnte man dann eine ~16fache Kompression erreichen. Wenn sich das nicht lohnt, dann weiß ich auch nicht mehr.

robbitop
2004-03-30, 10:46:58
das sind theoriefälle, nicht mehr und nicht weniger.
75% Bandbreite wird im Normalfall sicher nicht eingespart, zumal sie ohne MSAA deutlich ineffektiver ist. Denn hier sind alle Subpixel des Bildes (bis auf die Polygonkanten und Stencilschattenkanten) gleichfarbig pro Pixel..

ohne MSAA gibts eben keine Subpixelfarbinfos die man komprimieren kann. Dann greift eine Lossless compression vermutlich nicht soo gut, egal was die peakdaten sagen..

Gast
2004-03-31, 10:14:18
Original geschrieben von robbitop
das sind theoriefälle, nicht mehr und nicht weniger.
75% Bandbreite wird im Normalfall sicher nicht eingespart, zumal sie ohne MSAA deutlich ineffektiver ist. Denn hier sind alle Subpixel des Bildes (bis auf die Polygonkanten und Stencilschattenkanten) gleichfarbig pro Pixel..

ohne MSAA gibts eben keine Subpixelfarbinfos die man komprimieren kann. Dann greift eine Lossless compression vermutlich nicht soo gut, egal was die peakdaten sagen..


Keine Theoriefälle. Die haben das mit einigen Apps durchgespielt. Die 4fach-Kompression ist ein Mittelwert. Die Minimale Kompression liegt natürlich bei etwas über 1,1 . Speicher kann man damit natürlich nicht einsparen, aber Bandbreite.

Da ich das PDF im Internet nicht mehr gefunden habe, habe ich es kurz mal hochgeladen :

http://www.8ung.at/mboeller/compression_FB_u_ZB.pdf

robbitop
2004-03-31, 11:24:39
selbst bei MSAA wo wirklich viel Redundanz durch die Subpixel im Bereich Farbe vorhanden ist, erreicht man den theoretischen Wer von 4 nicht annähernd in der Prais.
Ich glaube es erst wenn ich es in der Praxis sehe.
vieleicht kann Demi mal das Wort ertgreifen?

Blutgrätsche
2004-04-01, 17:45:17
Die guten Kompressionsraten für Color überraschen mich schon, obwohl die benutzten komprimierten Texturen dabei helfen könnten. Verwunderlich auch, das die Z-Buffer-Kompression im gleichen Grössenbereich liegt. Leider gibts zu den veralteteten, gebenchten Spielen keine Screenshots, damit man sich die Kompexität bzw. Variationen mal anschauen kann. Sollte für neuere Spiele (z.B. Bumpmapping, AF) nicht mehr ganz so gut funktionieren. Im übrigen würde sich Color Kompression bereits bei nur 25% Ersparnis lohnen.

robbitop
2004-04-01, 18:04:40
Z Werte lassen sich afair recht gut komprimieren, die Farbinfos hauen gut rein. Und aus Erfahrung lassen sich bilder lossless nicht allzugut komprimieren. Ich sage mal 25% sind sicher drin, je nach Situation, vieleicht auch mal 50%.

Demirug
2004-04-01, 18:55:25
Die Kompressionraten sind durchaus stimmig. Allerdings dürfte die Umsetzung dieser Verfahren in einen Grafikchip sehr problematisch werden. Mir ist kein Verfahren bekannt mit dem man Huffman parallel berechnen könnte. Da man aber eine Tile pro Takt packen und entpacken muss barucht man eine sehr lange Pipeline dafür. Sowas haut kräftig aufs Transistoren Konto. Da muss man sich dann sicher die Frage stellen ob es am Ende nicht besser ist die Transitoren für Zwischenspeicher zu nutzen.

Blutgrätsche
2004-04-02, 00:54:18
Original geschrieben von Demirug
Die Kompressionraten sind durchaus stimmig. Allerdings dürfte die Umsetzung dieser Verfahren in einen Grafikchip sehr problematisch werden. Mir ist kein Verfahren bekannt mit dem man Huffman parallel berechnen könnte. Da man aber eine Tile pro Takt packen und entpacken muss barucht man eine sehr lange Pipeline dafür. Sowas haut kräftig aufs Transistoren Konto. Da muss man sich dann sicher die Frage stellen ob es am Ende nicht besser ist die Transitoren für Zwischenspeicher zu nutzen.
Mich machen die Color-Kompressionsraten weiterhin stutzig, aber gut.

Wieso muss man ein Tile (angenommen 8x8) in einem Takt packen und entpacken? Bei 16 oder 32 Pixel Lese/Schreibzugriff darf es 4 resp. 2 Takte dauern. Das Ganze ist auch wenig rechenintensiv (bestenfalls Additionen), d.h. man kann ne Menge (sequentieller) Logik in einen Takt unterbringen. Wenn man dennoch mehr als 2 oder 4 "Loop"-Takte braucht, sollten wenige Pipeline-Stufen die zu erzielende Performance garantieren.

Warum kann man Huffman nicht (teilweise/abschnittsweise) parallel berechnen? Wegen dem "sequentiellen" Bit-Schreibe-Pointer oder Lese-Pointer? Glaube nicht an ein ernsthaftes Problem (jedenfalls sollten es nicht die von Demirug angesprochenen sein), man ist wohl nur etwas langsam mit der HW-Implementierung.

Mehr Zwischenspeicherung bzw. Cache bringt weniger Nutzen als Komprimierung. Die (Häufigkeit der) Wiederverwendbarkeit der Daten im Cache wird ohnehin überschätzt. Buffer braucht man sowieso, damit der Chip "rund" läuft (ansonsten Stottern und kaum Möglichkeiten zur Speicherzugriffs-Optimierung). Wenn man also schon den Speicher hat, dann kann man auch gleich einen Cache daraus machen.

Gast
2004-04-02, 12:58:43
Original geschrieben von Demirug
Die Kompressionraten sind durchaus stimmig. Allerdings dürfte die Umsetzung dieser Verfahren in einen Grafikchip sehr problematisch werden. Mir ist kein Verfahren bekannt mit dem man Huffman parallel berechnen könnte. Da man aber eine Tile pro Takt packen und entpacken muss barucht man eine sehr lange Pipeline dafür. Sowas haut kräftig aufs Transistoren Konto. Da muss man sich dann sicher die Frage stellen ob es am Ende nicht besser ist die Transitoren für Zwischenspeicher zu nutzen.


So schlimm kann das ganze gar nicht sein. Ich habe mir die alten Sachen zum Talisman noch einmal angesehen. MS hatte vor TREC in zwei Varianten einzusetzen, einmal als verlustbehaftete Kompression für Texturen und einmal als lossless-Kompression für den Framebuffer. Das war 1996! Das entsprechende DOC-file ist leider nicht mehr Online.

Hier ist allerdings zu sehen, wie aufwendig das damals war (siehe Die-area) :

http://web.media.mit.edu/~wad/vsp/node3.html

Heutzutage sollte der Aufwand aber vergleichsweise gering sein.

Demirug
2004-04-02, 17:21:16
Original geschrieben von Gast
So schlimm kann das ganze gar nicht sein. Ich habe mir die alten Sachen zum Talisman noch einmal angesehen. MS hatte vor TREC in zwei Varianten einzusetzen, einmal als verlustbehaftete Kompression für Texturen und einmal als lossless-Kompression für den Framebuffer. Das war 1996! Das entsprechende DOC-file ist leider nicht mehr Online.

Hier ist allerdings zu sehen, wie aufwendig das damals war (siehe Die-area) :

http://web.media.mit.edu/~wad/vsp/node3.html

Heutzutage sollte der Aufwand aber vergleichsweise gering sein.

AFAIR war TREC immer verlustbehaftet und aufgrund der DCT neigt es auch stark zu Blockfragmenten.

Was mich bei dem Verfahren in den verlinkten PDF von oben am meisten stört ist der Huffman.

Gast
2004-04-02, 17:48:11
Original geschrieben von Demirug
AFAIR war TREC immer verlustbehaftet...

Nicht immer :

http://www.8ung.at/mboeller/TREC.pdf

Ich habe mal kurz die alte HTML-Datei in ein PDF umgewandelt und hochgeladen. Die Formatierung passt allerdings nicht 100%ig.

Demirug
2004-04-02, 17:59:26
Original geschrieben von Gast
Nicht immer :

http://www.8ung.at/mboeller/TREC.pdf

Ich habe mal kurz die alte HTML-Datei in ein PDF umgewandelt und hochgeladen. Die Formatierung passt allerdings nicht 100%ig.

Es war mir nicht bekannt das das auch unter TREC aufgehängt war. Allerdings kann man das verlustfreie Verfahren für Spiele vergessen. Das komprimiert lediglich gleichfarbige Flächen bzw Linien (Horizontal, Vertical) gut.