Glide-API

[Matti]

Was bietet Glide, was OpenGL nicht kann? (mal abgesehen von den T-Buffer-Features der V5)

[stabilo_boss13]

Originally posted by Matti
Was bietet Glide, was OpenGL nicht kann? (mal abgesehen von den T-Buffer-Features der V5) Eigentlich nichts, denn Glide ist tot, OpenGL lebt noch!

Ich glaube nicht, dass Glide noch irgend etwas bieten wird. Außer dem von dir aufgezählten Feature fällt mir aber auch keines ein, das früher zugetroffen wäre. Da die Weiterentwicklung von Glide schon vor Jahren endgültig eingestellt wurde, würde ein eventuell fehlendes Feature bei OpenGL vielleicht noch eingebaut. Bei Glide habe ich da so meine Zweifel.

Zu Versuchszwecken habe ich mir für meine GF3 mal ein paar Glidewrapper zum Ausprobieren runtergeladen. Leider konnte ich aber keine aktuelle Anwendung finden, die das noch unterstützt.

[x-dragon]

Originally posted by stabilo_boss13
...
Zu Versuchszwecken habe ich mir für meine GF3 mal ein paar Glidewrapper zum Ausprobieren runtergeladen. Leider konnte ich aber keine aktuelle Anwendung finden, die das noch unterstützt. Ok, nicht mehr ganz aktuell, aber nach dem ja noch ein "fast" Addon demnächst dafür rauskommt: Diablo2 :)

[zeckensack]

Chroma-Keying. 'Ranged chroma' in Glide 3
Paletted textures (unter GL auf manchen Chips als Extension verfügbar)
table fog - unter GL wiederum nur als Extension
'YIQ'-quantisierte Texturen (eine Art Kompression)
echte Framebuffer-Locks, dh eine Applikation kann von Glide einen Zeiger bekommen, über den direkt in Graka-Speicher geschrieben, oder daraus gelesen werden kann
'AITRGB'. Soll heißen, der Combiner kann anhand des höchstwertigen Bits des interpolierten Vertex-Alpha einen seiner Inputs zwischen 'constant color' und 'texture' umschalten.
Per pixel-LOD als Combiner-Input.
explizite Unterscheidung zwischen Z- und W-Buffering
ein paar ganz besonders merkwürdige Z-Buffer-Modi ('compare to bias')

[Demirug]

Da spricht der Fachman :D

Wobei ein paar mehr Dinge noch über Extension machbar sein sollten. Da sie auch unter D3D zur Verfügung stehen.

[stabilo_boss13]

Originally posted by zeckensack
Chroma-Keying. 'Ranged chroma' in Glide 3
Paletted textures (unter GL auf manchen Chips als Extension verfügbar)
table fog - unter GL wiederum nur als Extension
'YIQ'-quantisierte Texturen (eine Art Kompression)
echte Framebuffer-Locks, dh eine Applikation kann von Glide einen Zeiger bekommen, über den direkt in Graka-Speicher geschrieben, oder daraus gelesen werden kann
'AITRGB'. Soll heißen, der Combiner kann anhand des höchstwertigen Bits des interpolierten Vertex-Alpha einen seiner Inputs zwischen 'constant color' und 'texture' umschalten.
Per pixel-LOD als Combiner-Input.
explizite Unterscheidung zwischen Z- und W-Buffering
ein paar ganz besonders merkwürdige Z-Buffer-Modi ('compare to bias')
Cool! Und welche davon sollte man denn noch nach OpenGL oder Direct3D übertragen? Sind denn da noch welche sinnvoll heutzutage (z.B. Paletted textures, table fog oder 'YIQ'-quantisierte Texturen braucht man doch gar nicht mehr, oder)?

[zeckensack]

Originally posted by stabilo_boss13
Cool! Und welche davon sollte man denn noch nach OpenGL oder Direct3D übertragen? Sind denn da noch welche sinnvoll heutzutage (z.B. Paletted textures, table fog oder 'YIQ'-quantisierte Texturen braucht man doch gar nicht mehr, oder)? Das meiste davon ist Schmand.
Die Texturformate machen nur einen Sinn, wenn der Texturspeicher extrem klein ist. Auf 'ne Voodoo 1 trifft das zu, auf aktuelle Chips wohl kaum. Paletten und sonstige Formatwandlungen sind 'pre filtering', und schränken immer ein Stück die erreichbare Taktrate des Chips ein. Deswegen haben diese Sachen eigentlich keine Existenzberechtigung mehr. S3TC ist die löbliche Ausnahme, weil man dafür keine LUTs braucht.

Table Fog braucht auch kein Mensch. Fog-Weights kann man pro Vertex vergeben, nur bei extrem niedrigem Polycount ist TF theoretisch besser. Praktisch schraubt man entweder den Polycount hoch, oder nimmt 'ne 1D-Textur.

AITRGB ist letztendlich auch nur eine Krücke, um Texturspeicher zu sparen.

Beliebige Framebuffer-Locks sind scheiße für tiefes Pipelining und beißen sich ganz böse mit den gängigen Entropie-Optimierungen wie Buffer-Swizzling und Hierarchical Z. Das sollte keine moderne API mehr erlauben.

W-Buffering ist tot, bringt keinerlei Vorteile wenn man HW-T&L und -Clipping hat.

LOD-Faktor in den Combiner braucht Vooodoo 2 als Krücke für's trilineare Filtern. Relevanz auf aktuellen Chips gleich null.

In der Summe ist es IMO überhaupt nicht schade um diese extra-Features ;)

[Matti]

Was ist überhaupt Chroma-Keying und W-Buffering??

[liquid]

Chroma-Keying hat IMHO was mit Transparenz oder so zu tun.
Zu dem Z-Buffer Ersatz namens W-Buffer gibt es hier (http://www.mvps.org/directx/articles/using_w-buffers.htm) einen schönen Artikel und wem das noch nicht genug ist, der kann ja nochmal im nv Developer Bereich nachschaun, die haben da auch noch ein Paper über den W-Buffer und seine Vorteile gegenüber dem linearen Depth Buffer.

cya
liquid

[Pitchfork]

Originally posted by zeckensack
LOD-Faktor in den Combiner braucht Vooodoo 2 als Krücke für's trilineare Filtern. Relevanz auf aktuellen Chips gleich null.


Mal ein wenig Erbsenzählen: bezieht sich dieser LOD Faktor auf die Auswahl des richtigen Miplevels pro Pixel? Weil gerade dieser Parameter, das Mipbias, wird bei ps_2_x oder ps_3_0 (vergessen, welches) wieder pro Pixel freigeschaltet, um so richtig nach Laune unscharf oder scharf werden zu können. Kann man ein paar schöne Effekte mit machen. Ist aber wahrscheinlich nicht wirklich mit dem Voodoo Faktor vergleichbar...

[liquid]

Originally posted by Matti
Was ist überhaupt Chroma-Keying und W-Buffering??
Das hat mich jetzt auch interessiert, was dieses dumme C-Keying genau ist.
Man kann es am ehesten mit dem Blue Screen Verfahren vergleichen, wo der Schauspieler seine Szene vor einem blauen Hintergrund spielt und dieser Hintergrund in der Nachbearbeitung durch den eigentlichen Szenenhintergrund ersetzt wird.

cya
liquid

[zeckensack]

Originally posted by Pitchfork


Mal ein wenig Erbsenzählen: bezieht sich dieser LOD Faktor auf die Auswahl des richtigen Miplevels pro Pixel? Weil gerade dieser Parameter, das Mipbias, wird bei ps_2_x oder ps_3_0 (vergessen, welches) wieder pro Pixel freigeschaltet, um so richtig nach Laune unscharf oder scharf werden zu können. Kann man ein paar schöne Effekte mit machen. Ist aber wahrscheinlich nicht wirklich mit dem Voodoo Faktor vergleichbar... Weder noch :)
Im Combiner ist das verfügbar, was 3dfx seinerzeit LOD_FRACTION nannte. Das ist der Blendfaktor zwischen zwei Miplevels. Dieser steigt bei Verkleinerung stetig an, und kippt zurück auf 0, wenn 1 erreicht wurde.

0.5 wäre halbe/halbe (Miplevel n) + (Miplevel n+1). Welche zwei Miplevel dort beteiligt sind, weiß der Combiner allerdings nicht.
Das echte xy/w, welches für Tiefeneffekte interessant wäre, ist nicht verfügbar. AFAIR gibt's das ab PS2.0.

[Xmas]

Originally posted by liquid
Das hat mich jetzt auch interessiert, was dieses dumme C-Keying genau ist.
Man kann es am ehesten mit dem Blue Screen Verfahren vergleichen, wo der Schauspieler seine Szene vor einem blauen Hintergrund spielt und dieser Hintergrund in der Nachbearbeitung durch den eigentlichen Szenenhintergrund ersetzt wird.
So ähnlich ist es. Chroma Keying bedeutet, dass ein Pixel nicht geschrieben wird, wenn ein der errechnete Farbwert mit einem vorher eingestellten Vergleichsfarbwert identisch ist.

Das gibt es zwar in OpenGL und D3D so nicht (mehr), ist aber mit Pixel Shader problemlos möglich. Die Verwendung ist aber recht unüblich.



Bei Glide konnte man den Nachkommateil des LOD als "Combiner-Input" nehmen, AFAIK aber nur als Blend-Faktor.

Bei PS2.0 und höher gibt es die texldb-Instruktion, die einen LOD-Bias ermöglicht (ps2.0: +3 bis -3, ps3.0: +16 bis -16), sozusagen als Output zum Textursampler. Den wirklichen LOD-Wert bekommt man aber nicht.

[Pitchfork]

Danke für die Aufklärung. Glide hatte mich irgendwie noch nie wirklich interessiert.