"Neuer" GF4-Bug: Z-Buffer Fehler?!?

[Höhnangst]

Ich weiß nicht, wer das schon kennt (nen Thread diesbezüglich hab ich hier noch nicht gesehen), aber im Grafikkarten-Bereich des Rivastation-Forums (http://www.rivastation.com/cgi-bin/dcforum99/dcboard.cgi?az=list&forum=grafik&conf=techzone) gibt's seit einigen Tagen mehrere Threads zu dem Thema (nach Aktualität geordnet):

@Borsti: GF4-Bug (http://www.rivastation.com/cgi-bin/dcforum99/dcboard.cgi?az=read_count&om=10023&forum=grafik)

Definitiv,GF4 Z-Buffer BUG auch in D3D ! (http://www.rivastation.com/cgi-bin/dcforum99/dcboard.cgi?az=read_count&om=10022&forum=grafik)

Bilder zum GF4 OGL-Z-Buffer Problem (http://www.rivastation.com/cgi-bin/dcforum99/dcboard.cgi?az=read_count&om=10013&forum=grafik)

GF4 & ZBuffer - Problem erkannt... (http://www.rivastation.com/cgi-bin/dcforum99/dcboard.cgi?az=read_count&om=10014&forum=grafik)

Ich glaube ich spinne... (http://www.rivastation.com/cgi-bin/dcforum99/dcboard.cgi?az=read_count&om=10010&forum=grafik)


PS: Die Links gehen bei mir komischerweise nur mit dem IE, Opera öffnet immer nur die Startseite?

[StefanV]

1. worum geht es bei diesem Bug eigentlich??

2. tja, soviel zum Thema NV und Bugs...

[Exxtreme]

Ich verfolge diese Diskussionen auch. Anscheinend benutzt die GF4Ti einen 16 Bit Z-Buffer wenn ein 32 Bit Z-Buffer angefordert wird. Die GF-Serie kann AFAIK keine 32 Bit Z-Buffer, nur 24 Bit und evtl. 8 Bit Stencil. Dieser Fehler tritt komischerweise auf einer GF3-Karte nicht auf. Soviel zu "Unified Driver Architecture". :lol:

Gruß
Alex

[Xmas]

Originally posted by Stefan Payne
1. worum geht es bei diesem Bug eigentlich??

2. tja, soviel zum Thema NV und Bugs...
:rofl:
Stefan, das ist echt ein Hammerkommentar... du hast zwar keine Ahnung um was es geht, aber erst einmal ablästern... köstlich. ;D

[Tarkin]

ich glaub diese Diskussion dürfte noch interessant werden ;D

[Simon Moon]

habs nur kurz den letzten link angelesen. Und da kam der Beweis mit ner Sniper. Vor einen abgelegten Gegenstand stehen und ganz nah heranzoomen. -> in nem spiel ist das doch eher unwahrscheinlich, oder?
Und wenn man ihn anders nicht findet, naja, dann kann er ja nicht gravierend sein...

[Exxtreme]

Originally posted by El-Diablo
habs nur kurz den letzten link angelesen. Und da kam der Beweis mit ner Sniper. Vor einen abgelegten Gegenstand stehen und ganz nah heranzoomen. -> in nem spiel ist das doch eher unwahrscheinlich, oder?
Und wenn man ihn anders nicht findet, naja, dann kann er ja nicht gravierend sein...
Jein. Es soll in SS:SE heftige Z-Fehler geben auch wenn man nicht snipert. Wobei es sich beim Snipern am heftigsten auswirkt. Schau dir mal die Threads in diesem Forum durch. Es gibt dort einige Screenshots.

Gruß
Alex

[daflow]

Heftig is relativ, aber unschön iss das schon, zumal das Problem ja bei den GF3 nicht auftaucht und die jetzigen GF4 Besitzer/Käufer numal wegen 'Klenigkeiten' (eye candy..) die Gf4 haben

[nagus]

kann es sein, dass dieser fehler nicht unbedingt ein fehler von Nvidia sonder eher ein fehler der SS-Engine ist?

[Exxtreme]

Originally posted by nagus
kann es sein, dass dieser fehler nicht unbedingt ein fehler von Nvidia sonder eher ein fehler der SS-Engine ist?
Nein, so wie es aussieht, liegt's tatsächlich an NV. Die Anwendung fordert einen 32 Bit Z-Buffer an, bekommt aber einen 16 Bit Z-Buffer vom Treiber. Da die GF-Serie keinen 32 Bit Z-Buffer unterstützt (die Radeon-Serie übrigns auch nicht), hätte der Treiber einen 24 Bit Z-Buffer zur Verfügung stellen können/sollen.

Gruß
Alex

[Xmas]

Falls die Engine ChoosePixelFormat nutzt um das richtige Format zu wählen, dann ist das ein Fehler von Microsoft, nicht von NVidia.

[HOT]

Meiner Meinung nach bringt es nix den Fehler, so er denn dann wirklich akut ist, schönzureden. Wenn der Z-Buffer tatsächlich nur mit 16Bit Präzision läuft, ist das unakzeptabel. Testen kann man die Präzision übrigens mit der 3D Winbench, vielleicht probiert das mal jemand, es gibt dort mehere Tests des Z-Buffers und seiner Genauigkeit. Mangels Geforce4 kann ich den leider net selber durchführen ;)

[apollo]

@Xmas
mag die DX is so sein, dass der Fehler bei Microsoft liegen könnte, aber das erklärt nicht den Fehler bei OGL!?

[Demirug]

Originally posted by apollo
@Xmas
mag die DX is so sein, dass der Fehler bei Microsoft liegen könnte, aber das erklärt nicht den Fehler bei OGL!?

Xmas hat schon recht "ChoosePixelFormat" ist eine MS Funktion die zur OpenGL unterstützung von Windows gehört.

[Exxtreme]

Originally posted by Demirug


Xmas hat schon recht "ChoosePixelFormat" ist eine MS Funktion die zur OpenGL unterstützung von Windows gehört.
Dann bleibt die Frage warum der Bug bei den Radeons und der GF3-Serie nicht auftritt.

Gruß
Alex

[Demirug]

Die erste Frage ist erst einmal ob z.B. SS überhaupt ChoosePixelFormat benutzt, oder diese Einstellungen auf andere Art und Weise durchführt.

Sobald man dieses bestimmt hat kann man den schuldigen suchen.

[tEd]

der fehler passiert nur bei gf4 karten, weder bei einer gf3 mit gleichen treibern noch auf radeon karten. Er tritt sowohl im ersten wie auch im 2ten teil von SS auf und zwar immer nur in opengl , unter d3d funktioniert alles.

Ich weiss nicht aber ich hab den eindruck das es relativ klar ist wo der fehler liegt.

[ice cool69]

dann isses ja wohl ein softwarebug und nvidia kann nichts dafür oder?

aber wie man sieht ist nvidia auch nicht vor solchen bugs gefeit obwohl sie als marktführer wohl momentan zuerst berücksichtigt werden bei der anpassung auf die grafikchips.

trotzdem: wieder ein kleines bsp dass nvidia auch nicht immer alles so perfekt läuft wie es hier einige gerne hätten.

und die radeontreiber holen auf, überholen vielleicht noch? ;)

[Quasar]

Ist das so neu? AFAIK war das schon vor Monaten bekannt....nur das ChoosePixelFormat daran schuld sein sollte, und nicht der nV-Treiber wusste ich nicht.

Jedi Knight II z.B. nutzt etwas namens ChoosePFD (=Pixel Format Description??) und funktioniert korrekt mit 24Bit Z- und 8Bit-Stencil-Buffer.

SeSam bietet aber eine Funktion, die JK2, also die Q3-Engine nicht hat: Es gibt vordefinierte Präferenzen für bekannte Chips, die die Engine selbständig einstellt. Vielleicht auch eine Möglichkeit...

(Die Fehler sind übrigens nicht nur beim Snipen zu sehen, auch in grossen Levels, wie sie z.B. im Valley-of-the-Jaguar- und Grand-Cathedral-Demo gezeigt werden)

[Piffan]

Originally posted by Quasar
Ist das so neu? AFAIK war das schon vor Monaten bekannt....nur das ChoosePixelFormat daran schuld sein sollte, und nicht der nV-Treiber wusste ich nicht.

Jedi Knight II z.B. nutzt etwas namens ChoosePFD (=Pixel Format Description??) und funktioniert korrekt mit 24Bit Z- und 8Bit-Stencil-Buffer.

SeSam bietet aber eine Funktion, die JK2, also die Q3-Engine nicht hat: Es gibt vordefinierte Präferenzen für bekannte Chips, die die Engine selbständig einstellt. Vielleicht auch eine Möglichkeit...

(Die Fehler sind übrigens nicht nur beim Snipen zu sehen, auch in grossen Levels, wie sie z.B. im Valley-of-the-Jaguar- und Grand-Cathedral-Demo gezeigt werden)

Auch bei Mafia tritt es auf..... Bei der Mission, wo Sam gerettet werden muß. Da sieht man es, wenn man sich von weitem dem erleuchteten Schuppen nähert, da flackern im Inneren Texturen auf den Balken....

Wenn es bei der G3 nicht auftritt, dann hat es NV mit der G4 versaut. Da kann man nichts schönreden....

[Kennung Eins]

Hmm nun würde ich gerne mal Testergebnisse von 3DCenter Usern sehen.

"screenshots"

[Radeonator]

Originally posted by Exxtreme

Nein, so wie es aussieht, liegt's tatsächlich an NV. Die Anwendung fordert einen 32 Bit Z-Buffer an, bekommt aber einen 16 Bit Z-Buffer vom Treiber. Da die GF-Serie keinen 32 Bit Z-Buffer unterstützt (die Radeon-Serie übrigns auch nicht), hätte der Treiber einen 24 Bit Z-Buffer zur Verfügung stellen können/sollen.

Gruß
Alex

AFAIK unterstützt die Radeon Serie 16,24,32bit Z-Buffer (siehe Registry) was eigentlich auch logisch ist, da Radeons auf 32Bit ausgelegt sind.

[Xmas]

Also eine R9700 (von den anderen weiß ich es nicht sicher) unterstützt keinen 32-bit Z-Buffer. Das hat mit der Auslegung auf 32-Bit Farbtiefe nichts zu tun. Die neueren Programme benötigen eh den Stencil-Buffer, so dass Z24S8 (24 bit Z, 8 bit Stencil) das populärste Format sein sollte.

[Quasar]

Originally posted by Kennung Eins
Hmm nun würde ich gerne mal Testergebnisse von 3DCenter Usern sehen.

"screenshots"

Sind zwar schon älter (so Mitte Juli, aber bitte sehr (http://www.computerbase.de/article.php?id=101&page=12#serious_sam_ii_ogl).

@Piffan:
Ich will auch gar nichts schönreden, nur fand ich es erstaunlich, dass SeSam SE bei der Chiperkennung einen Unterschied zwischen GF3 und GF4Ti macht, obwohl sich die Chips doch sehr ähneln.

[skampi]

Originally posted by Xmas
Also eine R9700 (von den anderen weiß ich es nicht sicher) unterstützt keinen 32-bit Z-Buffer. Das hat mit der Auslegung auf 32-Bit Farbtiefe nichts zu tun. Die neueren Programme benötigen eh den Stencil-Buffer, so dass Z24S8 (24 bit Z, 8 bit Stencil) das populärste Format sein sollte.

Auf der R8500 gab es meines Wissens unter D3D unterschiedliche Reg-Keys für 32Bit-Z oder 24/8, deshalb bin ich mir da nicht so sicher.

[zeckensack]

Originally posted by skampi


Auf der R8500 gab es meines Wissens unter D3D unterschiedliche Reg-Keys für 32Bit-Z oder 24/8, deshalb bin ich mir da nicht so sicher. Die Radeon8500 (und auch die Ur-Radeon) beherrscht einen 32bittigen Z-Buffer.

Unter D3D muß man das mittlerweile im Treiberpanel für D3D 'freischalten', Standardvorgabe sind hier 24Bit Z (+8 Stencil).

Unter OpenGL gibt's die Treiberoption gleich garnicht mehr (früher sehr wohl), aber auch hier kann ein Programm problemlos einen 32bittigen Z-Buffer kriegen.

Und für die ganz blöden Programme, die Schrott anfordern, dafür gibt's jetzt die Option 'Force 24bit Z'. Ergibt 24 Bit Z + 8 Bit Stencil.

[ow]

zecki

Also die Radeon1 bietet unter OGL (bei 32Bit Farbe)mit den letzten 8(?) Treibern nur 24+8 Bit Z/Stencil an. Deine Savage2k kann dazu noch 16 und 24+0 (GF2 auch).
Unter 16Bit FB in OGL kann die Radeon 16&24+8.

Unter D3D kann die Radeon auch 32+0 (und 16&24+8).

Mir ist etwas schleierhaft, wieso denn unter OGL und D3D Unterschiede gemacht werden.:|
Die Savage kann kein 24+0 unter D3D, daher laufen fast alle 3D Apps nur mit 16Bit Z (24+8 wollen die wohl nicht).

Wieso bieten nicht einfach alle dazu fähigen Chip die Z/Stencil, 16, 24+0, 24+8 unter 16 und 32Bit Farbtiefe an, in beiden APIs??

[Modulor]

Originally posted by ow
...
Wieso bieten nicht einfach alle dazu fähigen Chip die Z/Stencil, 16, 24+0, 24+8 unter 16 und 32Bit Farbtiefe an, in beiden APIs??

Die Wildcat VP760 kann alle o.g. Modi - und 32bit Z-buffer oben drauf unabhängig von der API.
Wie sieht es denn bei Parhelia aus?

[StefanV]

Originally posted by Modulor


Die Wildcat VP760 kann alle o.g. Modi - und 32bit Z-buffer oben drauf unabhängig von der API.
Wie sieht es denn bei Parhelia aus?

Keine Ahnung, hab sie noch nicht...

Wie könnte ich das testen??

[Mr. Lolman]

Seht das ganze mal so: Spiele sind mit 16 Bit Z-Buffer sicher etwas flotter, als mit 32 bit, und warum sollte nvidia unnötig Leistung verschenken, wenn der "vermeindliche" Z-Buffer Bug erst jetzt für grosse Diskussionen sorgt, nach dem es die Geforce4 schon über ein 1/2 Jahr gibbet.

Als meiner Meinung, ist da nvidia nicht ganz unschuldig, da bei eine Geforce3 dieses Prob. auch nicht auftrat.

[Quasar]

Wie gesagt, ich glaube, dass sowohl nV als auch die Prä-Selektion von SeSam schuld sind, denn wie ebenfalls gesagt, erkennt diese den GF4Ti beim Namen und wählt entsprechend ein passenden PFD aus...

[zeckensack]

Ich bin mittlerweile soweit, daß ich Matt Craighead in der Sache vertraue. Der schreibt idR keinen Bullshit.

Sieht dann so aus:
1)Die Auswahl des Pixelformats liegt nicht am Treiber, sondern an MS. Der Treiber hat lediglich die Pflicht, an die MS-Bibliothek zu melden welche Pixelformate er beherrscht. Man könnte da natürlich Einschränkungen machen und somit spezielle Formate erzwingen, dies ist im Moment nicht der Fall und schon garnicht eine Erklärung für dieses 'Problem'. Siehe 3

2)SSam fordert tatsächlich einen 16bittigen Z-Buffer (bzw fordert überhaupt nichts spezielles)

3)Das Argument "Auf der Gf3 passiert das nicht" ist null und nichtig. Diese kann nämlich überhaupt nicht die Kombination 32bit Color+16bit Z. Daran liegt es dann auch, daß sie automatisch mit höherer Z-Präzision läuft, egal was ein Spiel haben will. Die Gf2MX kann's, damit darf man vergleichen. Bin gespannt. :)
NV könnte auf der Gf4 die Fähigkeit zu diesen Mischformaten verstecken, aber wozu?

[ow]

Gf2MX nutzt 16Bit Z bei 32Bit Farbe (PFD 4).

Getestet mit
SeSam Test 2.1 (public Test 2.1a v0.18 build 109.2a).

[zeckensack]

Originally posted by ow
Gf2MX nutzt 16Bit Z bei 32Bit Farbe (PFD 4).

Getestet mit
SeSam Test 2.1 (public Test 2.1a v0.18 build 109.2a). Aha, danke :)
Damit wäre das ja schonmal bestätigt.

Also IMO können wir für die Gf4 Entwarnung geben, kein Bug ;)

[tEd]

das verhalten konnte von jemandem im rivastation forum bei seinen eigenen programmen reproduziert werden.

fordert man mit "choosepixelformat" einen 32bit z-buffer an , und wird dieser nicht unterstützt bekommt man statt den nächst kleineren einfach den noch kleineren ;)

vielleicht könnte jemand von den codern hier das mal testen

[VOODOO-KING]

Borsti hat nun auch ein paar SSam II + Q3A Tests durchgeführt

http://www.rivastation.com/dcforum99/gaga/grafik/10044.html

Gruss VOODOO-KING

[Diapolo]

Originally posted by zeckensack
3)Das Argument "Auf der Gf3 passiert das nicht" ist null und nichtig. Diese kann nämlich überhaupt nicht die Kombination 32bit Color+16bit Z. Daran liegt es dann auch, daß sie automatisch mit höherer Z-Präzision läuft, egal was ein Spiel haben will. Die Gf2MX kann's, damit darf man vergleichen. Bin gespannt. :)
NV könnte auf der Gf4 die Fähigkeit zu diesen Mischformaten verstecken, aber wozu?

Also GF3 KANN definitv 32 Bit Color mit 16 Bit Z-Buffer Tiefe!
Ist bei mir PixelFormat Nr. 17.
17 8 8 8 8 32 16 0

8 Red Bits
8 Green Bits
8 Blue Bits
8 Alpha Bits
32 Color Bits
16 Z Bits
0 Stencil Bits

Diapolo

[Haarmann]

Nun wird auch klarer, wieso ne GF4 soviel schneller ist, denn ne GF3 ;). Das ist wohl ein LMA2 Feature...

Soll mal wer mit GF4Ti Q3 testen aber mit
r_depthbits "32"
r_stencilbits "0"

[Exxtreme]

Originally posted by Haarmann
Nun wird auch klarer, wieso ne GF4 soviel schneller ist, denn ne GF3 ;). Das ist wohl ein LMA2 Feature...
Hehe, und da wird ATi das Cheaten bei Q3A vorgeworfen...
;)

Soviel bringt ein 16-Bit-Z-Buffer ggü. einem 32-Bit-Z-Buffer auch nicht. Ein paar Prozent dürften's sein, wenn's hochkommt. Eigentlich nicht der Rede wert.

[Haarmann]

Exxtreme... naja so ca 25% Bandbreite spart das wohl ;). Eben LMA2

Für mich isses eh ein absichtlicher Cheat

[Quasar]

Ein absichtlicher Cheat von SeSam SE? Oder tritt das "Phänomen" noch woanders auf?

[Exxtreme]

Originally posted by Quasar
Ein absichtlicher Cheat von SeSam SE? Oder tritt das "Phänomen" noch woanders auf?
Hmm, warum ist mir damals eine solche Frage, bezüglich ATis Treibercheat, nicht eingefallen...
;)

P.S. Bin grad im RS-Forum rumgesurft. So wie es aussieht, liegt das Problem doch bei Micros~1... was mich irgendwie gar nicht wundert. :D

[Haarmann]

Quasar...

GP4, wohl IL-2 meinte der mitm Flugsimi und einer hat sogar ne eigenen Anwendung, die das ned hinkriegt... Und ich denke bei r_depthbits "32"
r_stencilbits "0"

Wird auch Q3 16 Bit Z-Buffer setzen ;)

[Quasar]

Alle Q3-Derivate, die ich kenne, verwenden aber trotz deiner Mutmaßung einen 24bittigen Z-Buffer plus 8Bit Stencil.

Interessanterweise scheint auch die GeForce3 auf 16Bit Z zurückzufallen, sobald in SeSamSE FSAA zugeschaltet wird....komisch, was?

[Haarmann]

Quasar... nee eher noch ein weiterer Cheat ... Aber gut, dass es gesagt hast.

Und nun schalt einfach mal vorher auf

r_depthbits "32"
r_stencilbits "0"
Denn ich brauche keinen Stencil Scheiss für nen Schatten, den ich eh ausschalte, weil er mies aussieht.

[Diapolo]

Auf GF3 wird das zu einem 24 Bit Z-Buffer mit 0 Bit für den Stencil Buffer (Q3)!

Diapolo

[Exxtreme]

@ Diapolo

Leider funzt dein Progrämmchen nicht auf einer R9700. Einige Extensions werden nicht unterstützt. Das Programm beendet sich sofort nach dem Start. Ich poste trotzdem mal die Ergebnisse:

1 8 8 8 8 32 24 8 ICD
2 8 8 8 8 32 24 8 ICD
3 8 8 8 8 32 24 8 ICD
4 8 8 8 8 32 24 8 ICD
5 8 8 8 0 32 32 8 SW
6 8 8 8 0 32 16 8 SW
7 8 8 8 0 32 32 8 SW
8 8 8 8 0 32 16 8 SW
9 8 8 8 8 32 32 8 SW
10 8 8 8 8 32 16 8 SW
11 8 8 8 8 32 32 8 SW
12 8 8 8 8 32 16 8 SW
13 8 8 8 0 32 32 8 SW
14 8 8 8 0 32 16 8 SW
15 8 8 8 0 32 32 8 SW
16 8 8 8 0 32 16 8 SW
17 8 8 8 0 24 32 8 SW
18 8 8 8 0 24 16 8 SW
19 8 8 8 8 24 32 8 SW
20 8 8 8 8 24 16 8 SW
21 8 8 8 0 24 32 8 SW
22 8 8 8 0 24 16 8 SW
23 5 5 5 0 16 32 8 SW
24 5 5 5 0 16 16 8 SW
25 5 5 5 8 16 32 8 SW
26 5 5 5 8 16 16 8 SW
27 5 5 5 0 16 32 8 SW
28 5 5 5 0 16 16 8 SW
29 3 3 2 0 8 32 8 SW
30 3 3 2 0 8 16 8 SW
31 3 3 2 8 8 32 8 SW
32 3 3 2 8 8 16 8 SW
33 3 3 2 0 8 32 8 SW
34 3 3 2 0 8 16 8 SW
35 1 1 1 0 4 32 8 SW
36 1 1 1 0 4 16 8 SW
37 1 1 1 8 4 32 8 SW
38 1 1 1 8 4 16 8 SW
39 1 1 1 0 4 32 8 SW
40 1 1 1 0 4 16 8 SW


P.S. Was bedeutet "ICD" und "SW"?

[Diapolo]

SW (= Software) bedeutet dass es ein nicht beschleunigtes Format ist und ICD steht für Installable Client Driver (= volle Beschleunigung / HW-Beschleunigung).

Diapolo

PS.: Ich sagte glaube ich relativ deutlich, dass es im Moment nur auf GF3 / GF4 läuft (allerdings bei RS, interessant, dass Du es gesaugt hast *g*) ;).

[Exxtreme]

Originally posted by Diapolo
SW (= Software) bedeutet dass es ein nicht beschleunigtes Format ist und ICD steht für Installable Client Driver (= volle Beschleunigung / HW-Beschleunigung).

Diapolo
Axo, dann ist's klar.


Originally posted by Diapolo
PS.: Ich sagte glaube ich relativ deutlich, dass es im Moment nur auf GF3 / GF4 läuft (allerdings bei RS, interessant, dass Du es gesaugt hast *g*) ;).
Stimmt nicht ganz. Du hast geschrieben, es läuft auf einer GF3/GF4 oder höher. *eg* :naughty:

[Birdman]

Originally posted by Haarmann
Quasar... nee eher noch ein weiterer Cheat ... Aber gut, dass es gesagt hast.

Und nun schalt einfach mal vorher auf

r_depthbits "32"
r_stencilbits "0"
Denn ich brauche keinen Stencil Scheiss für nen Schatten, den ich eh ausschalte, weil er mies aussieht.
macht nix aus, die GF4 verwendet dabei einen 24bit depthbuffer, genau wie es sein muss.
(und ja, ich habs visuell, sowie inner console nachgeprüft)

[Diapolo]

Wenn ich sagte GF3 / GF4 oder höher, meinte ich eigentlich einen höherwertigen NV Chip und nix von ATI, Kyro oder Matrox :D.
Auch wenn du mir nun sicher sagen wirst, dass der R300 "höher" ist *g*.

Diapolo

[Birdman]

Originally posted by Exxtreme
Axo, dann ist's klar.

Stimmt nicht ganz. Du hast geschrieben, es läuft auf einer GF3/GF4 oder höher. *eg* :naughty:
jau, er meinte damit "besser" und ned einfach ne höhere zahl (8500/9700) *eg* :naughty:

[Haarmann]

Birdman

Das musst aber in die q3config eingeben... ned in Game... und dann ohne OSP starten ;).

[Exxtreme]

Originally posted by Diapolo
Wenn ich sagte GF3 / GF4 oder höher, meinte ich eigentlich einen höherwertigen NV Chip und nix von ATI, Kyro oder Matrox :D.
Auch wenn du mir nun sicher sagen wirst, dass der R300 "höher" ist *g*.

Diapolo
Weitere Kommentare verkneife ich mir... :naughty:
Als Mod muss ich mit gutem Beispiel vorangehen.
;)

[Diapolo]

Es is im Moment halt so, dass dieses "Progrämmchen" absolut auf NV Chips und deren GL Extensions zugeschnitten ist :).
Ich will net unbedingt einen NV vs. ATI Flamewar lostreten, deswegen also nix für ungut :D.

Diapolo

[Birdman]

Originally posted by Haarmann
Birdman
Das musst aber in die q3config eingeben... ned in Game... und dann ohne OSP starten ;).
örm, was soll das für nen Unterschied machen?
obs nun inner config steht, oder inner console reingehauen + anschliessendes /vid_restart gemacht wird, hat keinen Einfluss aufs endergebnis.
btw. diese Werte schreibs eh in die .cfg und habe nun etxra nochmals q3 gestartet, (mit depthbits auf 32 und stencil auf 0 inner .cfg) und das ganze verifiziert.
Alles i.O. die GF4 hat damit keine probleme --> 16bit Zbuffer Probleme sind eher bei MS und SeSam zu suchen als bei Nv.

und jo, ich starte nie OSP, immer nur baseQ3....

[Quasar]

Originally posted by Haarmann
Quasar... nee eher noch ein weiterer Cheat ... Aber gut, dass es gesagt hast.

Und nun schalt einfach mal vorher auf

r_depthbits "32"
r_stencilbits "0"
Denn ich brauche keinen Stencil Scheiss für nen Schatten, den ich eh ausschalte, weil er mies aussieht.

Warum soll ich etwas manuell einstellen, was automatisch korrekt ausgewählt wird? (Bei Q3-Engine...)

[Haarmann]

Quasar

Die Idee dahinter war eigentlich sehr einfach... Aber offenbar war zu einfach und ned alle haben bemerkt, dass ich nur wissen wollte, ob er auf 16 oder 24 schaltet als Ausweichsmassnahme, da 32 ja ned gehen.

[Quasar]

Ok, bin heut n bissel langsam :(

Also, bei Quake 3 weicht er auf 24+0 aus.

[tEd]

wie man den z-buffer in serious sam ändert:

in der konsole folgendes eingeben:

gap_iDepthBits = 24
ApplyVideoMode()

es funktioniert keine z-buffer fehler mehr :)

[Haarmann]

tEd

Aber welcher Review hat wohl so gebencht? ;) Da kann man nun wohl immer nen paar FPS abziehen... wobei diese paar noch recht viele sind.

[Quasar]

Ui....tatsächlich. Mit dem HQ-Script von 3DCenter in 1600x1200 kann man mit 24Bit Z-Buffer kaum noch spielen, so derbe wirken sich die verlorenen 1,3fps (55,9 vs. 54,6) aus. Ein Skandal....
:bonk: @Haarmann ;)

Aber nichtsdestotrotz danke für den Tip tEd!

[tEd]

1,3fps bessere bildqualität :D

[Quasar]

Ich hab nV mal angemailt....mal gucken, ob die sich dazu äußern oder das Problem auf SeSam abschieben, wozu ich momentan auch neige, weil, wie gesagt, dort die Pixelformate ausgesucht werden.

[Haarmann]

Quasar

Mit nem 500er CPU kommt man nie ans fps Limit ;) Ist mir schon klar...

[Quasar]

Setz ne 2 davor und du liegst etwa richtig ;)

[ow]

Originally posted by Quasar
Ich hab nV mal angemailt....mal gucken, ob die sich dazu äußern oder das Problem auf SeSam abschieben, wozu ich momentan auch neige, weil, wie gesagt, dort die Pixelformate ausgesucht werden.


Sehe ich auch so.

[tEd]

die frage ist schon geklärt. Sesam gibt beim "choosepixelformat" keinen spez. z-buffer wert an. Dadurch wird von der funktion selber dann der kleinste verfügbare genommen was bei einer gf4 im 32bit modus einen 16bit z-buffer ist.

[Quasar]

Nicht ganz. Oder zumindest nicht zufriedenstellend, imo.

Denn bei einer GF3 passiert das im Default-Modus nicht, es wird also als "kleinster Wert" ein 24bittiger Z-Bag...äh...Buffer genommen.
(Obwohl ich mich ein wenig wundere, warum die GF3 bei 32Bit keinen 16Bit Z-Buffer mag, aber egal).

Was mir nur komisch vorkommt, ist, dass sobald FSAA zugeschaltet wird, die GF3 exaktemento das Verhalten der GF4Ti ohne FSAA an den Tag legt, sprich, es wird auf 16Bit-Z zurückgegriffen...

[tEd]

ich denke auch das die "choosepixelformat" funktion nicht so funkrioniert wie sie sollte. Wenn man einen 32bit z-buffer anfordert bekommt man einen 16bittigen auf der gf4. Obwohl ein 24bittiger eigentlcih logischer gewesen wäre. Ich weiss nicht nach welche regeln die funktion die entsprechenden pixelformate wählt imo ein bisschen komisch.

[Unregistered]

Originally posted by Quasar

Was mir nur komisch vorkommt, ist, dass sobald FSAA zugeschaltet wird, die GF3 exaktemento das Verhalten der GF4Ti ohne FSAA an den Tag legt, sprich, es wird auf 16Bit-Z zurückgegriffen...

Da unterstell ich schon eher Absicht. Aber egal, für GayForce3-AA-Benchmarks interessiert sich eh keine Sau mehr.

[Quasar]

Mag sein, mag aber auch nicht sein. nV will sich's auf jeden Fall anschauen. Mal gucken, ob dabei was rauskommt.

[Haarmann]

Ich unterstelle NV immer Absicht, wenns um Frames "gewinnen" resp erschummeln geht...
So sehr, wie hier nur wenige bei ATIs Q3 an Bugs glaubten, so sehr glaube ich hier nicht an nen Zufall, sondern ne Absicht. Richtig, ich mag NV HW per se ned mehr riechen und ihre Treiber sind aus meiner Sicht auch samt der HW untauglich für meine Zwecke. Die Bugs in HW und SW seitens NV jedenfalls füllen inzwischen Bände. Sei es mangelhaftes 2D bei Riva oder untaugliches pseudo S3TC - es bringt immer Speed und kostet Qualität.
Was eigentlich viel erstaunlicher ist, jedem Reviewer fällt immer auf, was bei den anderen Grakas ned stimmt resp stimmen soll im Bild. Bei NV sind wohl alle Blind... DAS gibt einem eigentlich weit mehr zu denken. Hatten wir doch vor ned langer Zeit mal nen Z-Fehler Thread, der zu Lasten von ATI und Co ging ;).

[tEd]

In diesem Fall kann nv wohl wirklich nichts dafür und auch wenn es absicht wäre , würde es in sachen speed nicht mal was bringen.

Die s3tc,dxt1 sache haben sie dafür völlig verbockt , da hätte man viel mehr drüber hören müssen.

naja epic hat wohl auch erfahrungen damit gemacht :)

nv dxt1/s3tc (http://udn.epicgames.com/pub/Content/TextureComparison/)

[Quasar]

Originally posted by Haarmann
Ich unterstelle NV immer Absicht, wenns um Frames "gewinnen" resp erschummeln geht...
So sehr, wie hier nur wenige bei ATIs Q3 an Bugs glaubten, so sehr glaube ich hier nicht an nen Zufall, sondern ne Absicht. Richtig, ich mag NV HW per se ned mehr riechen und ihre Treiber sind aus meiner Sicht auch samt der HW untauglich für meine Zwecke. Die Bugs in HW und SW seitens NV jedenfalls füllen inzwischen Bände. Sei es mangelhaftes 2D bei Riva oder untaugliches pseudo S3TC - es bringt immer Speed und kostet Qualität.
Was eigentlich viel erstaunlicher ist, jedem Reviewer fällt immer auf, was bei den anderen Grakas ned stimmt resp stimmen soll im Bild. Bei NV sind wohl alle Blind... DAS gibt einem eigentlich weit mehr zu denken. Hatten wir doch vor ned langer Zeit mal nen Z-Fehler Thread, der zu Lasten von ATI und Co ging ;).

Jaja, Haarmann. Jetzt geht die allgemeine Hetze wieder los. Nimm dir mal ein Beispiel an tEd, der argumentiert wenigstens vernünftig und bringt Belege für seine Ansichten und Theorien, du dagegen flamst.

Wo ist der Z-Fehler Thread von ATi und Co. und was war dessen Ergebnis?

[Haarmann]

Quasar

Als ob einer der NV Fangemeinde je argumentiert hätte, als ATI bei Q3 ned richtig lief... :rofl:
Der Unterschied von 256 auf 512 ist immerhin ne Sache, die noch mit nem Byte und Wort als Var erklärt werden kann... Wie mann statt nem 32 Bit Z-Buffer nen 16 Bit ausliefern kann, bleibt mir allerdings schleierhaft. Wenn schon, müsste eigentlich sogar ein 24+8 Buffer geliefert werden - der hätte immerhin die richtige Breite. Auch ists saupeinlich, wenn alle immer von den Z-Fehlern einer Voodoo (oder G400 Max) flennten und selbst die Z-Fehler ihrer NV HW ned erkennen... Als NV nämlich noch keine 32 bpp + 16 Z-Buffer konnte, so wurden Matrox und ATI derb beschimpft, weil die das zum Teil per Default eingeschaltet haben, als man auf 32bpp geschaltet hat. Ist schon sicher ne ganze Weile her...
Alleine aber bei den endlosen Diskussionen um die V3 und ihren Post Filter wurde immer wieder gesagt, dass zwar das Banding ned so schlimm wär, aber die Z-Fehler ach sooo tragisch seien und man die sofort sähe. Wieso seht denn diese tragischen Fehler nun plötzlich keiner? Seit ihr etwa alle blind?
Und als ATI mal als Default in die Treiber die 16 Bit Z-Buffer reinwürgte... da kamen die Leute ausm Busch... etwa gleich, wie wenn ATI die 32 Bit Texturen zu 16 Bit Texturen machte... wie NV eben auch - nur dort passierte es durch ne absichtlich verbockte, dafür viel schnellere und Bandbreitenschonende reine 12 Bit (nix mit 16 Bit) S3TC Implementation...

P.S. Ich bin Mensch und keine Suchmaschine... und die Forums Engine geht ned für das. Alles was ich über sowas sehr direkt fand ist das...
http://www.tomshardware.com/graphic/99q2/990628/g400-01.html

[Quasar]

S3TC ist eine andere Geschichte, ebenso die Fehler, die "andere" machen. In diesem Thread geht's laut Überschrift um den Z-Buffer Fehler in SeSam. (Weswegen ich auch nicht auf die selben/ähnliche Fehler anderer Hersteller in diesem Thread einprügele, sonst komme ich mit der Argumentation nie weiter, und die Schuld und Gegenschuld und Urschuld wird solange hin- und hergeschoben, bis wir bei Kain und Abel angelangt sind.)

Da ist geklärt, wie er zustande kommt und wie man ihn umgeht, einzig die Frage, ob es nV's Absicht war, dass das so passiert oder nicht steht noch im Raum, auch wenn Leute, die Ahnung vom Programmieren haben, mittlerweile die Schuld eben NICHT mehr bei nV suchen (und Z-Bag wirst du wohl kaum als nV-Fanboy bezeichnen, oder?).

Für mich ist das Thema gegessen, bis sich weitere Fakten ergeben, die neues Licht ins Halbdunkel bringen.

[Haarmann]

Quasar

Wer lesen kann ist klar im Vorteil... es steht nirgends was von SS2 oder SS...
Und Z-Bufferfehler ist Fehler - egal in welchem Spiel und GF3 und GF4 User sind offensichtlich blind, sonst wär das schon lange aufgefallen... Alleine wenns wie bei Deiner GF3 bei No AA 24 Bit nimmt und bei 2xAA 16 Bit nimmt, siehts derb nach LMA aus... Oder einfach wien Cheat.

P.S. Wars ned grad in SS2 wo man alle möglichen und unmöglichen Positionen nach AF Fehlern der R8500 absuchte, aber offenbar zu blind war um nen offensichtlichen Z-Fehler zu sehen ???

[Exxtreme]

Originally posted by Haarmann

P.S. Wars ned grad in SS2 wo man alle möglichen und unmöglichen Positionen nach AF Fehlern der R8500 absuchte, aber offenbar zu blind war um nen offensichtlichen Z-Fehler zu sehen ???
Ja, das hat mich auch gewundert.

[ow]

@ Haarmann

Dein Geflame finde ich einfach nur peinlich hier. Am besten bist du still, wenn du nicht argumentieren kannst.

&FYI:
die ATis koennen gar kein 16Bit Z unter OGL bei 32Bit Farbtiefe ("Und als ATI mal als Default in die Treiber die 16 Bit Z-Buffer reinwürgte... "). Also informier dich erstmal, bevor du hier losblubberst.

[Haarmann]

ow

Jaja der OberNVistdasBeste Mann von hier... der keinen Schimmer von irgendwas hat (Wenns um NV fremde Treiber geht) aber immer alle runterputzt, die ihm und seiner Biased NVistdasGeilste Meinung ned passen...
Ich hab von Dir in jedem Post hier in dem Thread (wie auch sonst fast immer) noch nicht EIN Argument gesehen...

"die ATis koennen gar kein 16Bit Z unter OGL bei 32Bit Farbtiefe ("Und als ATI mal als Default in die Treiber die 16 Bit Z-Buffer reinwürgte... "). Also informier dich erstmal, bevor du hier losblubberst."

http://www.tomshardware.com/graphic/01q4/011123/index.html

Nein natürlich könnendie das ned... Dieses komische Schaltfeld im Treiber dient wohl als Dekoration :rofl:

Dein Geflame finde ich einfach nur peinlich hier. Am besten bist du still, wenn du nicht argumentieren kannst.

Genau, Dein Geflenne und Deinen Mist den Du hier wieder rausgelassen hast, den braucht gar niemand... Kauf Dir mal ne ATI und installier erst deren Treiber, dann urteile über Features der Treiber, denn offenbar hattest Du NIE auch nur einen Prä Catalyst Treiber installiert, sonst wär Dir dieser Button bestimmt aufgefallen.

[ow]

WO ist deine Argumentation Haarmann? Ausser Beleidigen hast du wohl nichts drauf?

Liste mal bitte alle PFDs des ATi ICD bei 32Bit Framebuffer auf.

Und btw. hab ich nicht von 16Bit FB geredet, da kann die ATi sehr wohl 16Bit Z.

[Haarmann]

ow

Also ich weiss ned... siehst Du das Bild oben wirklich nicht ???

Muss ichs noch anmalen, damit Du den Schaltknopf siehst?

Da steht deutlich Force 16-Bit Z-Buffer und wenn der Schalter drin is, dann hast in Q3 deutliche Z-Fehler sichtbar - auch bei 32 Bit... Ich wüsste das wohl ned so gut, wenn ich den Button nicht sehr oft selber benutzt hätte, wenn die Leistung eng wurde...

[Demirug]

ow & Haarmann,

die ATI kann wie Haarmann sagt auch bei 32bpp einen 16 Bit Z-Modus. Mit dem Schalter im Panel kann man den ICD zwingen auch nur noch 16 Bit modi als unterstützt zurückzugeben. Möglicherweise wird wenn diese Option nicht gewählt ist der 32/16 Modus vom ICD nicht gemeldet. Das müsste mal jemand testen.

Aber eigentlich tut das jetzt hier auch nicht unbedingt was zur Sache.

Was die unglückliche Z-Buffer wahl bei SS angeht so sind wohl alle 3 Partein (NV, MS, und SS) irgendwie beteiligt.

Wenn SS wie hier schon gesagt wurde beim Z-Buffer wirklich nichts angibt dann muss sich die Engine auch nicht wundern wenn sie irgendwas bekommt.

Die "ChoosePixelFormat" wählt aus der Modus-Liste die der Treiber liefert einfach die aus die seiner Meinung nach am besten passt. Sollte mehr als ein Modus passen darf ein beliebiger benutzt werden. Es ist lediglich definiert das "beschleunigte" Modi vorgezogen werden.

Damit "ChoosePixelFormat" arbeiten kann wird vom ICD eine Liste mit Modi angefordert. Die Liste muss laut Spezifikation nur nach beschleunnigt und nicht beschleunigt sortiert werden.

Wenn nun "ChoosePixelFormat" im falle von mehrern möglichkeiten einfach die erste nimmt und NVIDIA die Liste aufsteigend sortiert hat bekommt man einen 32/16 Modus wenn die Application 32/0 (egal) anfordert.

IMO liegt der Fehler (falls die aussage das SS beim Z-Buffer 0 angibt stimmt) ganz eindeutig bei SS denn NVIDIA hat nicht gegen die Spec verstossen und "ChoosePixelFormat" macht nichts was nicht so in der Dokumentation steht.

[Exxtreme]

Also doch eine Verkettung unglücklicher Zufälle?

[Xmas]

Originally posted by Haarmann
Quasar

Wer lesen kann ist klar im Vorteil... es steht nirgends was von SS2 oder SS...
Und Z-Bufferfehler ist Fehler - egal in welchem Spiel und GF3 und GF4 User sind offensichtlich blind, sonst wär das schon lange aufgefallen... Alleine wenns wie bei Deiner GF3 bei No AA 24 Bit nimmt und bei 2xAA 16 Bit nimmt, siehts derb nach LMA aus... Oder einfach wien Cheat.

P.S. Wars ned grad in SS2 wo man alle möglichen und unmöglichen Positionen nach AF Fehlern der R8500 absuchte, aber offenbar zu blind war um nen offensichtlichen Z-Fehler zu sehen ???
Haarmann, sowas nennt man wohl selektive Erinnerung...

http://www.forum-3dcenter.net/vbulletin/showthread.php?s=&threadid=13001

Der Thread ist schon über ein halbes Jahr alt, und geht noch um GF3 mit AA - es gibt auch andere Threads wo es um GF4 geht - interessanterweise wird dort schon genau aufgezeigt wo der Fehler liegt: SeSam2 fordert einfach gar keine bestimmte Z-Buffer-Tiefe an.

[Demirug]

Originally posted by Exxtreme
Also doch eine Verkettung unglücklicher Zufälle?

Ja könnte man so sagen. Im Prinzip hat keiner einen Fehler gemacht aber am ende lief es halt doch schief. Nur wenn ich gezwungen bin in diesem Fall jemandem den schwarzen Peter zuzuschieben ist mein Favorit die SS-Engine.

[Haarmann]

Mir ist eigentlich ziemlich Banane, was der Treiber wann rausgibt (da bin ich ehrlich). Wichtig isses für mich, was ich aufm Bildschirm sehe... Ich meine es gibt zig dieser Bildvergleiche vor allem mit SerSam2 und keinem soll das aufgefallen sein, dass es Z-Fehler hat? Das kann und will ich nicht glauben. Die stehen dort an Positionen und gucken in Richtungen, die im Gameplay nie vorkommen, aber merken ned, dass das Game selbst Z-Fehler hat die munter vor sich hin flimmern? Dafür erkennens dann allerdings jegliches Pixelflimmern...
Ich selbst hab ja keine GF3 oder GF4 Karte mehr und somit kann es mir kaum auffallen, aber ich erwarte eigentlich von jedem Reviewer, der sowas Bencht, dass er sich auch drauf achtet, dass beide Seiten mit gleich langen Spiessen kämpfen. Besonders bei Multisampling müsste dieser kleinere Z-Buffer grosse Vorteile bringen. Hätte ich SS2 noch installiert, würd ichs wohl auch austesten mit meiner R9700, aber ohne SS2 wirds schwer.

"Wenn SS wie hier schon gesagt wurde beim Z-Buffer wirklich nichts angibt dann muss sich die Engine auch nicht wundern wenn sie irgendwas bekommt."

Da bin ich eigentlich Deiner Meinung, sofern der gleiche Treiber bei jeder unterstützen HW auch gleich reagiert. Irgendwie verwundert es dann halt schon, wenn je nach Graka was anderes bei der gleichen Funktion rauskommt. Sowas wirft nicht gerade ein gutes Licht. Auch würds mich mal interessieren, wieviel Power es nun wirklich bringt, wenn man bei 4xFSAA den Z auf 16 stellt. Immerhin scheint das Problem auch bei GP4 aufzutauchen und ist somit weder auf OGL, noch auf SS2 beschränkt (Mangels TestHW kann ich das ja ned nachprüfen, denn GP4 hätte ich noch drauf).

Soweit ichs in den Links beim Init Post des Threads lesen konnte, passiert das auch, wenn man 32 Bit Z-Buffer anfordert... Da wiederum hört das Versehen auf und kommt aus meiner Sicht die Absicht ins Spiel.

Mal aber gucken, wann dies gefixt wird und ev wären mal nen paar Benches mit FSAA interessant. Natürlich bei hohen Auflösungen, denn wir wollen ja keine CPU Marks messen ;).

[Xmas]

Haarmann... es ist aufgefallen. Nur dir ist anscheinend nicht aufgefallen dass einigen aufgefallen ist. Und dass man es ganz einfach beheben kann.

[Exxtreme]

Originally posted by Xmas
Haarmann... es ist aufgefallen. Nur dir ist anscheinend nicht aufgefallen dass einigen aufgefallen ist. Und dass man es ganz einfach beheben kann.
Hmm, den Reviewern scheint es aber nicht aufgefallen zu sein. Ich habe nirgendwo gelesen, daß das in einem Review aufgefallen wäre.

[nggalai]

Originally posted by Exxtreme

Hmm, den Reviewern scheint es aber nicht aufgefallen zu sein. Ich habe nirgendwo gelesen, daß das in einem Review aufgefallen wäre. Zu dem Thema hatten wir doch schonmal einen Thread, oder? Wie kompetent Reviewer sind?

Echt. Die Sache ist Ur-alt (wie man schon XMas verlinktem Thread ansehen kann--März ahoi), und wurde von Croteam auch in den SS-Foren erklärt. Ich glaub' sogar sowas im ReadMe des letzten Patches gelesen zu haben, müsste ich aber nachschaun.

ta,
-Sascha.rb

[Demirug]

Originally posted by Haarmann
Da bin ich eigentlich Deiner Meinung, sofern der gleiche Treiber bei jeder unterstützen HW auch gleich reagiert. Irgendwie verwundert es dann halt schon, wenn je nach Graka was anderes bei der gleichen Funktion rauskommt. Sowas wirft nicht gerade ein gutes Licht.

Wie schon gesagt muss der Treiber die Modi melden. Wie genau das bei den NVIDIA treibern realisiert ist weis ich nicht. Eine Möglichkeit wäre das man einfach für jede Karte eine Liste hinterlegt hat. Eine ander Variante ist das man die Liste aufgrund der auf der geladenen Treibermodule dynamisch zusammenbaut. Wenn dem so ist könnte die Liste für jede Karte eine andere Rheienfolge aufweisen. Und da in der Spec ganz klar "sortieren nicht erforderlich" steht würde ich als Treiberentwickler auf keinen Fall anfangen die Liste zu sortieren.

Immerhin scheint das Problem auch bei GP4 aufzutauchen und ist somit weder auf OGL, noch auf SS2 beschränkt (Mangels TestHW kann ich das ja ned nachprüfen, denn GP4 hätte ich noch drauf).

Wenn sowas bei D3D Spielen passiert gibt es nur folgende möglichkeiten:

Es passiert bei allen Spielen im gleichen Modus -> Treiberbug
Es passiert bei nicht bei allen Spielen im gleichen Modus -> Engine Fehler. OK ein Cheat wäre auch möglich aber wenn man sich schon die mühe macht dann doch nicht beim Z-Buffer.

Soweit ichs in den Links beim Init Post des Threads lesen konnte, passiert das auch, wenn man 32 Bit Z-Buffer anfordert... Da wiederum hört das Versehen auf und kommt aus meiner Sicht die Absicht ins Spiel.

AFAIK hat das bis jetzt niemand wirklich nachgeprüft.

[Birdman]

Originally posted by Haarmann
Immerhin scheint das Problem auch bei GP4 aufzutauchen und ist somit weder auf OGL, noch auf SS2 beschränkt (Mangels TestHW kann ich das ja ned nachprüfen, denn GP4 hätte ich noch drauf).

Oh wunder, bei GP4 hat auch die Ati 9700 die selben Z-Fehler....eieiei, scheiss Ati treiber ;)

btw. am Sonntag habe ich versucht die R9k7 und Win 98 (nicht SE) zu installieren.
Hat knapp 1 h gedauert und zigs reboots gefordert bis es geklappt hat...soviel zu guten Treibern.

Ach ja, die Referenztreiber von der ATi seite liessen sich gar ned installen. Über die Exe kam ein Error, dass keine Graka gefunden wurde und ich zuert die Karte als Standard-VGA reinhauen soll (habe ich so gemacht, brachte aber auch keine Abhilfe) und wenn ich direkt aufs .inf File losgegangen bin brachte er mir nur Radeon 7500 und Radeon 8500 zur Auswahl...nicht jedoch die 9k7.
Super treiber sag ich da nur, vor allem weil, als das problem dann mal gelöst war, die Karte am laufmeter Abstürze produzierte unter UT2k3.
Ok, hätte die SBLive ausbauen können dann häts gefunzt, aber wieso eine Soundkarte ausbauen die seit 3 jahren ohne Fehl und Tadel läuft?

Was soll ich sagen...Ati hard+software füllen mit Ihren Bugs Akten en masse...schneller als selbst ein Christoph Meili diese vernichten könnte *eg*

[Exxtreme]

Originally posted by Birdman
btw. am Sonntag habe ich versucht die R9k7 und Win 98 (nicht SE) zu installieren.
Hat knapp 1 h gedauert und zigs reboots gefordert bis es geklappt hat...soviel zu guten Treibern.

Ich weiss echt nicht was ihr mit euren ATi-GraKas so alles macht. Weisst du wie ich meine unter Win98 (nicht SE) installiert habe?
R8500 raus, R9700 rein - fertig. Die GraKa wurde sofort erkannt und die Treiber waren schon auf der Platte. Es waren überhaupt keine Treiberinstallationsorgien nötig.

[Xmas]

Originally posted by Birdman
Oh wunder, bei GP4 hat auch die Ati 9700 die selben Z-Fehler...
Wenn dem so ist, dann ist das ein Engine-"Fehler", denn die R9700 unterstützt genausowenig wie die NV-Karten 32-Bit Z-Buffer.
Die Engine probiert also scheinbar 32-Bit Z aus, und wenn das nicht klappt wird 16-Bit genommen, ohne 24-Bit zu testen. Nicht gerade clever gelöst...

[Haarmann]

Birdman

Bisher nix von bemerkt bei GP4... aber ich achte mich mal besser auf die Landschaft, weil oft spiel ich das echt nicht und normalerweise achte ich mich mehr auf die Piste denn auf die Pampa.

"btw. am Sonntag habe ich versucht die R9k7 und Win 98 (nicht SE) zu installieren.
Hat knapp 1 h gedauert und zigs reboots gefordert bis es geklappt hat...soviel zu guten Treibern."

Tja... geh mal auf www.ati.com und guck nach, was ATI zum Thema 9700pro und Win98 meint... wer meint er müsse noch Win98 FE installieren, der soll halt leiden... Win98 FE lief sogar laut M$ nie richtig und somit ist auch ned der ATI ME Treiber schuld am Debakel. Vor allem dann nicht, wenn Du wohl keine orig ATI hast, aber mitem orig ATI Treiber versuchst - das muss ned klappen mein lieber Schwan... Mit 98 Beta3 und meiner 9700pro gehts übrigends bestens.
Und wenn 2 Karten ned zusammen laufen, so ist die Schuldige kaum die ATI alleine... vor allem ned, wenns ne SB Live is, die bei mir zumindest noch nie lief (Ich benutze kein Win9x mehr seit Beta2 von NT5 draussen war als HauptOS). Spätestens dann, wenn ich mir beim ICQ tippen nen IRQ LESS NOT EQUAL auf nem blauen Bildschirm ansehen muss, hört meine Geduld ganz schnell auf... Nicht dass ne Fortissimo 2 besser liefe im selben Gerät (die schmiert nur in jedem Game ab), aber immerhin macht ein CMedia Chip mit... Es liegt also weder am Slot, noch am Dual System, eher an fehlerhaften Treibern oder HW seitens der Hersteller und ich denke mal, dass jeder Hersteller Fehler macht, bei den einen werdens nur ab und an auch gefixt... bei CL jedoch wohl jedoch nie - Schade.

[Unregistered]

Originally posted by Haarmann
Quasar

Wer lesen kann ist klar im Vorteil... es steht nirgends was von SS2 oder SS...
Und Z-Bufferfehler ist Fehler - egal in welchem Spiel und GF3 und GF4 User sind offensichtlich blind, sonst wär das schon lange aufgefallen... Alleine wenns wie bei Deiner GF3 bei No AA 24 Bit nimmt und bei 2xAA 16 Bit nimmt, siehts derb nach LMA aus... Oder einfach wien Cheat.

P.S. Wars ned grad in SS2 wo man alle möglichen und unmöglichen Positionen nach AF Fehlern der R8500 absuchte, aber offenbar zu blind war um nen offensichtlichen Z-Fehler zu sehen ???

Haari,
Du hast recht, ich kann nicht lesen.

Da ich mich jetzt als offensichtlich unwürdig erwiesen habe, hier mitzureden, darf ich dieses Kompliment allerdings an dich zurückgeben.

Es sind ausser Tobias' selbstgemachter OpenGL-FluSim noch GP4 und SeSam SE betroffen. GP4 legt offenbar selbiges Verhalten auch mit der R300 an den Tag, entweder ATi und nV bauen hier dieselben Bugs ein, oder man sollte doch mal drüber nachdenken, bei einem solchen Zufall den Fehler woanders zu suchen.

SeSam ist etwas anders gelagert, und nicht nur ow und ich, sondern auch so Forumsbekannte nVidiots wie Z-Bag und Demirug, die zudem auch Null Ahnung von der Materie haben, suchen den Fehler eher bei SeSam SE.

Zu Tobias' FluSim kann ich mich nicht äußern, da ich das Programm nicht kenne (aber dass er für drei der vier Threads aus dem Ursprungsposting verantwortlich ist, die er ins gleiche Forum gesetzt hat, finde ich schon seltsam).

Weiterhin darf ich höflich auf zweierlei hinweisen:

a) Es wurde sehr wohl schon dieser Z-Fehler bemerkt und auch darauf hingewiesen (vor beinahe drei Monaten, AFAIR), und

b) Es ging mir eigentlich primär darum, innerhalb des Topic zu argmumentieren, und nicht noch zig uralte Geschichten auszugraben, wo der eine oder andere Dreck am Stecken hat. SeSam war nur das Beispiel, was ich leider nicht korrekt zu lesen im Stande war. Deine darauffolgende Argumentation zeigt mir jedoch, auf was es dir in Wirklichkeit ankommt.

@Exxtreme:
Auch dir sei gesagt, dass das Z-Buffer Problem bei SeSam SE schon vor nahezu drei Monaten (mind.) publik wurde. Wenn so etwas dann überlesen wird, darf die Schuld nicht bei den nVidiots gesucht werden.

[Quasar@Work]

Originally posted by Demirug
AFAIK hat das bis jetzt niemand wirklich nachgeprüft.

Mach ich mal, wenn ich um 19:00 zu Hause aufschlage.

[Exxtreme]

Ruhig Blut, ;)

leider verkehre ich als forumsbekannter FanATiker nicht sooo oft in irgendwelchen NV-Foren. ;)
Neee, offiziell habe ich leider nichts zum Thema gesehen. Und irgendwelche Schuldzuweisungen habe ich IIRC nie deswegen gemacht.
Originally posted by Unregistered
@Exxtreme:
Auch dir sei gesagt, dass das Z-Buffer Problem bei SeSam SE schon vor nahezu drei Monaten (mind.) publik wurde. Wenn so etwas dann überlesen wird, darf die Schuld nicht bei den nVidiots gesucht werden.

[ow]

Um diese Z-Anomalie noch etwas auszubauen:

Mein Gf2MX nutzt bei 32Bit Desktop meistens 16Bit Z, auch die OGL Benches 'Indy3D' und 'Viewperf' (alle Versionen ab 6.1.1) (->www.spec.org) laufen nur auf 16Bit Z bei 32Bit Farbtiefe.

Und auch diese beiden Apps fordern AFAIK kein spezielles Z-Format an.

Der 'OGL-Bench 1.6.1' nutzt auch nur 16Bit Z, der 1.6.2 nutzt 24Z+8Stencil. Ansonsten sind beide Versionen identisch. (http://www.din.or.jp/~ysd/oglbench/ogl_app.html)


Meine Radeon1 scheidet als Vergleichskarte aus, weil die nur 24+8 als Z/Stencil meldet bei 32Bit Farbe. Der RivaTNT kann kein 16Bit Z bei 32Farbe und nutzt deshalb immer 24+0 oder 24+8 (falls App. Stencil anfordert).

BTW. bezieht sich das alles auf OGL.


Alle Q3-Engine-Derivate nutzen immer 24Bit Z bei 32Bit Farbe.


SO, dann diskutiert's mal aus.

[HOT]

Ich glaube nicht, dass es haarmann um das technische Problem hierbei geht, er sieht vielmher eine art "doppelmoral" einiger NV Jünger. Kann ich durchaus nachvollziehen, da Nv auf jeden fall irgendwo in die trickkiste greifen wird um mehr speed zu bekommen als die anderen. Hat ati des öfteren auch so gemacht. und wenn der besagte angeforderte modus eben ganz oben in der liste steht bei SS und bei der geforce3 nicht, dann ist das mit Sicherheit so beabsichtigt und zwar net von den SS entwicklern.
Na ja wie auch immer, man sieht die meisten grafikfehler nur dann wenn man darauf hingewiesen wird oder durch zufall. solange das so bleibt solls mir schnurz sein.

[Quasar]

Originally posted by Exxtreme
Ruhig Blut, ;)
leider verkehre ich als forumsbekannter FanATiker nicht sooo oft in irgendwelchen NV-Foren. ;)
Neee, offiziell habe ich leider nichts zum Thema gesehen. Und irgendwelche Schuldzuweisungen habe ich IIRC nie deswegen gemacht.


Du brauchst auch nicht in nv-Foren zu verkehren, um sowas zu sehen. Sorry, wenn du nur das siehst, was du sehen willst und erst einmal das Gegenteil kategorisch abstreitest.

[Quasar]

Originally posted by HOT
Ich glaube nicht, dass es haarmann um das technische Problem hierbei geht, er sieht vielmher eine art "doppelmoral" einiger NV Jünger. Kann ich durchaus nachvollziehen, da Nv auf jeden fall irgendwo in die trickkiste greifen wird um mehr speed zu bekommen als die anderen. Hat ati des öfteren auch so gemacht. und wenn der besagte angeforderte modus eben ganz oben in der liste steht bei SS und bei der geforce3 nicht, dann ist das mit Sicherheit so beabsichtigt und zwar net von den SS entwicklern.
Na ja wie auch immer, man sieht die meisten grafikfehler nur dann wenn man darauf hingewiesen wird oder durch zufall. solange das so bleibt solls mir schnurz sein.

Wie gesagt, ich gehe darauf nur ein, um zu sagen, dass ich auf solcherart Argumentation eben nicht eingehe. Es geht nicht darum, wer vom Apfel zuerst abgebissen hat, es geht einzig und allein um folgendes: Ist der 16Bittige Z-Buffer ein Cheat oder nicht.

Bis auf Mutmaßungen und Unterstellungen ist bisher noch nichts gekommen, was man irgendwie argumentatorisch wertvoll oder gar überzeugend nennen könnte.

Bitte,
überzeugt mich, und zwar nicht mit billigem Geflame oder scheinbarer Doppelmoral, sondern mit Beweisen, handfesten Indizien, die nicht an den Haaren herbeigezogen bzw. teils schon widerlegt sind.

[Exxtreme]

Originally posted by Quasar


Du brauchst auch nicht in nv-Foren zu verkehren, um sowas zu sehen. Sorry, wenn du nur das siehst, was du sehen willst und erst einmal das Gegenteil kategorisch abstreitest.
Ich lasse es so unkommentiert stehen mit der kleinen Bemerkung, daß ich mich auf solche "Spielchen" nicht einlassen werde.

Nichts für ungut.

[Haarmann]

Quasar

Du erwartest von nem Nicht GF3 oder 4 Besitzer, dass er ohne HW was beweist? Wie soll denn das gehen? Ich fragte ja schon nach MSAA Werten einer GF3 resp 4... Dort müsste die Bandbreite drum kritischer werden. Allerdings müsste das z.B. bei ner GF3 Ti200 weniger arg sein als bei ner Ti500. Also bei Stock Takt.

[Quasar]

Tjo, Haari, wie hättest du's denn gern?

Ist 1024x768 genehm? Wir wollen ja schließlich nicht, dass die Füllrate ein Problem wird, oder?

[aths]

Originally posted by Quasar
Ist der 16Bittige Z-Buffer ein Cheat oder nicht.Ich würde sagen, dass es ein beabsichtigtes Verhalten ist, welches nunmal bei gewissen Benchmarks Vorteile auf Kosten der Bildqualität bringt. Dabei mussten keine Richtlinien verletzt werden, so dass im Gegensatz zu Tricks wie GDI-Bypassing der Quake-"Optimierung" kein "Voll-Cheat" vorliegt. BQ für ein paar % fps zu opfern hat bei NV ja Tradition. Die DXT1-Implementierung ist ja ebenfalls nicht vorschriftswidrig implementiert, man hätte aber genauso wie beim GF4-16Bit-Z-Buffer-"Bug" eine bessere Lösung finden können. Dass dieses Rumwurschteln bei NV einige Leute verärgert, kann ich völlig einsehen.

Der Treiber sollte so intelligent sein, bei unklarer Anforderung einer Z-Tiefe nach dem Farbmodus zu schauen und bei 32-Bit-Grafik dann zum 24-Bit-Z-Buffer griefen.

[tEd]

Das problem sehe ich hier ganz klar bei Sesam , da hier einfach zuwenig genau spez. wird was man will und überlässt die entschiedung der "choosepixelformat" funktion. Im übrigen benutzt ut auch diese funktion um das pixelformat zu wählen , nur wird dort der z-buffer genau spezifiziert , so kann es auch nicht zu fehlintepretationen kommen.

Ich würde es erst als cheat ansehen wenn man anstatt einem angeforderten 24bit z-buffer nur ein 16bittigen bekommt.

warum überhaupt ein 16bit z-buffer im 32bit modus? naja die nvidia demos laufen mit 16bitigem z-buffer :D.

[StefanV]

Hm, kann ich ja mal mit meiner Parhelia ausprobieren ;)

[Quasar]

Ja, das kann ich verstehen, nur sehe ich in diesem speziellen Fall (nochmal: Es geht hier nicht um S3TC oder DXTC, sondern um den Z-Buffer, offenbar sogar nur in OGL!!) absolut kein Schema hinter der Rumwurstelei. Ich traue den Leuten bei nV schon zu, dass sie Optimierungen etwas besser verstecken, als gerade beim Z-Buffer, der öffentlich bei beinahe jedem OpenGL-Game in der Konsole angezeigt wird und auch noch ein Flackern hervorruft (das menschliche Auge reagiert auf Bewegung/Veränderung am stärksten: was wäre also auffälliger, als ein Flackern?).

[Demirug]

Originally posted by aths
Der Treiber sollte so intelligent sein, bei unklarer Anforderung einer Z-Tiefe nach dem Farbmodus zu schauen und bei 32-Bit-Grafik dann zum 24-Bit-Z-Buffer griefen.

Die Wahl trift nicht der Treiber sondern "choosepixelformat".

[Quasar]

Originally posted by Stefan Payne
Hm, kann ich ja mal mit meiner Parhelia ausprobieren ;)

Ja, Stefan, du kannst das mit deiner Parhelia ausprobieren, Stefan.
Soll ich es dir zuliebe in meine Signatur schreiben:"Jubilieret und frohlocket, denn der Payne, der Stefan nennt eine Parhelia sein Eigen!" ???

[StefanV]

Originally posted by Quasar


Ja, Stefan, du kannst das mit deiner Parhelia ausprobieren, Stefan.
Soll ich es dir zuliebe in meine Signatur schreiben:"Jubilieret und frohlocket, denn der Payne, der Stefan nennt eine Parhelia sein Eigen!" ???

Kannst du auch machen ;)

Ich tue gerad SS:SE installieren...

[Piffan]

Originally posted by Quasar
Ja, das kann ich verstehen, nur sehe ich in diesem speziellen Fall (nochmal: Es geht hier nicht um S3TC oder DXTC, sondern um den Z-Buffer, offenbar sogar nur in OGL!!) absolut kein Schema hinter der Rumwurstelei. Ich traue den Leuten bei nV schon zu, dass sie Optimierungen etwas besser verstecken, als gerade beim Z-Buffer, der öffentlich bei beinahe jedem OpenGL-Game in der Konsole angezeigt wird und auch noch ein Flackern hervorruft (das menschliche Auge reagiert auf Bewegung/Veränderung am stärksten: was wäre also auffälliger, als ein Flackern?).

Vom gesunden Menschenverstand her kann man so viel Blödheit einfach nicht annehmen! Wer ein geübter Schummler ist, macht es nicht so offensichtlich.....

Ist schon seltsam, dass man vom Marktführer Fehlerfreiheit erwartet und hinter Ungereimtheiten immer Absicht sieht....

[Piffan]

Originally posted by Stefan Payne
Hm, kann ich ja mal mit meiner Parhelia ausprobieren ;)

Das ist ne gute Idee. Vielleicht ist ja doch das Imperium schuld und keiner der Kartenhersteller ;)

[Quasar]

...und unangebrachte Hilfsverben verwenden.

P.S.: Hab noch was feines für Haari (das, was default war, ist immer als erstes aufgeführt....):

NoFSAA
1024,16: 73,6
1024,24: 71,4

2xFSAA
1024,24: 68,4
1024,16: 67,8

4xFSAA
1024,16: 49,5
1024,24: 48,2

8xAF (performance opt.)
1024,24: 73,6
1024,16: 69,8

8xAF (quality opt.)
1024,16: 72,9
1024,24: 72,4

(bei den AF's wurde AF nur über den RT geforced, die eigentlich wichtige SeSam-Einstellung blieb bei "none", so dass nicht wirklich af-gefiltert wurde)

Interessanter Performance-Cheat, gerade bei 2xFSAA per default den 24Bit Z-Buffer zu aktivieren. Und nein, auch wenn's so aussieht, der Default Z-Buffer alterniert nicht einfach nur, mit der entsprechenden Reihenfolge kriegt man auch andere Muster hin....

Mein persönlicher Tip:
Da SeSam den GF3 kennt und möglicherweise dort auch die Reihenfolge der PFDs wählt es trotz Namensnennung des GF4Ti die PFDs analog zum GF3 aus (und dort könnte es wirklich eine Optimierung bei 2xFSAA mit 16Bit-Z sein). Leider scheint die Reihenfolge beim GF4 andersrum zu sein.

[Haarmann]

Quasar

Schon interessant... Bringt so gut wie nix - da hab ich bei 3dmark oder Q3 immer weit mehr mit erreicht ;).
Welche Karte hast denn eigentlich genau?

P.S. Das Witzigste ist schon die Alternierung ;). Is ja besser als Lotto.

[StefanV]

Hier das ergebnis der Parhelia:

(hm, irgendwie seltsam, aber schaut selbst)...

[Quasar]

Originally posted by Haarmann
Quasar

Schon interessant... Bringt so gut wie nix - da hab ich bei 3dmark oder Q3 immer weit mehr mit erreicht ;).
Welche Karte hast denn eigentlich genau?

P.S. Das Witzigste ist schon die Alternierung ;). Is ja besser als Lotto.

Das war jetzt ne Ti4600. Aber SeSam krankt IMO eh nicht mehr so sehr an der Speicherbandbreite, eher an der Füllrate.

[ow]

Originally posted by Stefan Payne
Hier das ergebnis der Parhelia:

(hm, irgendwie seltsam, aber schaut selbst)...


7Stencil Bits? Ich glaube das kann gar nicht sein.:|

Gib mir mal deine Mail-Addy, ich schick dir heute abend ein Prog, dass dir u.a alle PFDs des ICD ausliest.

[Diapolo]

7 Stencil Bits find ich auch irgendwie seltsam :D.

Was ist das für ein Tool, will mir auch mal ansehen, wie dieses Tool das macht ;).

Diapolo

[Diapolo]

7 Stencil Bits is schon seltsam :).

Was fürn Tool meinst du?

Diapolo

[ow]

Nennt sich "GLinfo" und liest einige Eigenschaften des OGL-ICD aus.

Die neueste Version gibt es hier:

http://www.delphi3d.net/hardware/glinfo2.zip

Die liest AFAIK aber leider keine Pixelformate aus dem Treiber mehr aus. Die alte Version tut dies noch.


Alternativ tut's auch 'wglinfo':

http://www.cg.tuwien.ac.at/~wimmer/wglinfo/

[quasar@work]

7 Stencil Bits....hm, warum nicht, dann hat man ein freies Bit für Overbright Lighting, als Vorzeichen-Bit ;) ;) ;)

[aths]

Originally posted by quasar@work
7 Stencil Bits....hm, warum nicht, dann hat man ein freies Bit für Overbright Lighting, als Vorzeichen-Bit ;) ;) ;) *Hüstel* Wie möchtest du mit Stencil Overbright Lighting machen?

[Quasar]

Originally posted by quasar@work
;) ;) ;)

Ich quote mal nur den relevanten Teil... :D

[Xmas]

Dann hat man ein freies Bit für FAA...

[Quasar]

Ein Bit in Reserve kann nie schaden....falls man mal unverhofft durstig wird

[Xmas]

lol
:bier:

[StefanV]

**************
* GLINFO LOG *
**************

DRIVER INFO
---------------
Vendor : Matrox Graphics Inc.
Renderer : Matrox ICD for Parhelia
Version : 1.3


OPENGL CAPABILITIES
-----------------------
Supported extensions:
GL_ARB_multisample
GL_ARB_multitexture
GL_ARB_point_parameters
GL_ARB_texture_border_clamp
GL_ARB_texture_compression
GL_ARB_texture_cube_map
GL_ARB_texture_env_add
GL_ARB_texture_env_combine
GL_ARB_texture_env_dot3
GL_ARB_transpose_matrix
GL_S3_s3tc
GL_ATI_element_array
GL_ATI_vertex_array_object
GL_Autodesk_valid_back_buffer_hint
GL_EXT_bgra
GL_EXT_blend_color
GL_EXT_blend_func_separate
GL_EXT_blend_logic_op
GL_EXT_blend_minmax
GL_EXT_blend_subtract
GL_EXT_clip_volume_hint
GL_EXT_compiled_vertex_array
GL_EXT_draw_range_elements
GL_EXT_element_array
GL_EXT_fog_coord
GL_EXT_multi_draw_arrays
GL_EXT_packed_pixels
GL_EXT_point_parameters
GL_EXT_rescale_normal
GL_EXT_secondary_color
GL_EXT_separate_specular_color
GL_EXT_stencil_wrap
GL_EXT_subtexture
GL_EXT_texture3D
GL_EXT_texture_compression_s3tc
GL_EXT_texture_cube_map
GL_EXT_texture_edge_clamp
GL_EXT_texture_env_add
GL_EXT_texture_filter_anisotropic
GL_EXT_texture_lod_bias
GL_EXT_texture_object
GL_EXT_vertex_array
GL_EXT_vertex_array_object
GL_EXT_vertex_shader
GL_EXT_texture_env_combine
GL_EXT_texture_env_dot3
GL_KTX_buffer_region
GL_MTX_fragment_shader
GL_NV_texgen_reflection
GL_SGIS_multitexture
GL_SGIS_texture_lod
WGL_EXT_swap_control

Max. viewport size : 4096x4096
Max. texture size : 2048x2048

Max. modelview stack depth : 32
Max. projection stack depth : 32
Max. texture stack depth : 32
Max. attribute stack depth : 16
Max. name stack depth : 64

Max. display list nesting : 64
Max. evaluator order : 8
Max. number of lights : 12
Max. clipping planes : 6
Max. pixel map size : 32

Point size range : 0.250 to 10.000
Point size granularity : 0.250
Line width range : 0.250 to 10.000
Line width granularity : 0.250

Number of auxiliary buffers : 0
Bits of sub-pixel precision : 4


ACCELERATED PIXEL FORMATS
-----------------------------

* Render to window; single buffered; RGBA color; color: 32 bpp (R: 8, G: 8, B: 8, A: 8); accumulation: 0 bpp (R: 0, G: 0, B: 0, A: 0); depth: 24 bits; stencil: 8 bits; auxiliary buffers: 0

* Render to window; double buffered; RGBA color; color: 32 bpp (R: 8, G: 8, B: 8, A: 8); accumulation: 0 bpp (R: 0, G: 0, B: 0, A: 0); depth: 24 bits; stencil: 8 bits; auxiliary buffers: 0

* Render to window; double buffered; RGBA color; color: 32 bpp (R: 8, G: 8, B: 8, A: 8); accumulation: 0 bpp (R: 0, G: 0, B: 0, A: 0); depth: 24 bits; stencil: 8 bits; auxiliary buffers: 0

[ow]

Respekt! 12 Lichtquellen.:D

Sind irgendwie wenig Formate.

Auf der GF2MX sieht das so aus:


* Render to window; single buffered; RGBA color; color: 32 bpp (R: 8, G: 8, B: 8, A: 8); accumulation: 64 bpp (R: 16, G: 16, B: 16, A: 16); depth: 16 bits; stencil: 0 bits; auxiliary buffers: 0

* Render to window; single buffered; RGBA color; color: 32 bpp (R: 8, G: 8, B: 8, A: 8); accumulation: 64 bpp (R: 16, G: 16, B: 16, A: 16); depth: 24 bits; stencil: 0 bits; auxiliary buffers: 0

* Render to window; single buffered; RGBA color; color: 32 bpp (R: 8, G: 8, B: 8, A: 8); accumulation: 64 bpp (R: 16, G: 16, B: 16, A: 16); depth: 24 bits; stencil: 8 bits; auxiliary buffers: 0

* Render to window; single buffered; RGBA color; color: 32 bpp (R: 8, G: 8, B: 8, A: 8); accumulation: 64 bpp (R: 16, G: 16, B: 16, A: 16); depth: 0 bits; stencil: 0 bits; auxiliary buffers: 0

* Render to window; double buffered; RGBA color; color: 32 bpp (R: 8, G: 8, B: 8, A: 0); accumulation: 64 bpp (R: 16, G: 16, B: 16, A: 16); depth: 16 bits; stencil: 0 bits; auxiliary buffers: 0

* Render to window; double buffered; RGBA color; color: 32 bpp (R: 8, G: 8, B: 8, A: 8); accumulation: 64 bpp (R: 16, G: 16, B: 16, A: 16); depth: 16 bits; stencil: 0 bits; auxiliary buffers: 0

* Render to window; double buffered; RGBA color; color: 32 bpp (R: 8, G: 8, B: 8, A: 0); accumulation: 64 bpp (R: 16, G: 16, B: 16, A: 16); depth: 24 bits; stencil: 0 bits; auxiliary buffers: 0

* Render to window; double buffered; RGBA color; color: 32 bpp (R: 8, G: 8, B: 8, A: 8); accumulation: 64 bpp (R: 16, G: 16, B: 16, A: 16); depth: 24 bits; stencil: 0 bits; auxiliary buffers: 0

* Render to window; double buffered; RGBA color; color: 32 bpp (R: 8, G: 8, B: 8, A: 0); accumulation: 64 bpp (R: 16, G: 16, B: 16, A: 16); depth: 24 bits; stencil: 8 bits; auxiliary buffers: 0

* Render to window; double buffered; RGBA color; color: 32 bpp (R: 8, G: 8, B: 8, A: 8); accumulation: 64 bpp (R: 16, G: 16, B: 16, A: 16); depth: 24 bits; stencil: 8 bits; auxiliary buffers: 0

* Render to window; double buffered; RGBA color; color: 32 bpp (R: 8, G: 8, B: 8, A: 0); accumulation: 64 bpp (R: 16, G: 16, B: 16, A: 16); depth: 0 bits; stencil: 0 bits; auxiliary buffers: 0

* Render to window; double buffered; RGBA color; color: 32 bpp (R: 8, G: 8, B: 8, A: 8); accumulation: 64 bpp (R: 16, G: 16, B: 16, A: 16); depth: 0 bits; stencil: 0 bits; auxiliary buffers: 0

* Render to window; double buffered; RGBA color; color: 32 bpp (R: 8, G: 8, B: 8, A: 0); accumulation: 64 bpp (R: 16, G: 16, B: 16, A: 16); depth: 16 bits; stencil: 0 bits; auxiliary buffers: 0

* Render to window; double buffered; RGBA color; color: 32 bpp (R: 8, G: 8, B: 8, A: 8); accumulation: 64 bpp (R: 16, G: 16, B: 16, A: 16); depth: 16 bits; stencil: 0 bits; auxiliary buffers: 0

* Render to window; double buffered; RGBA color; color: 32 bpp (R: 8, G: 8, B: 8, A: 0); accumulation: 64 bpp (R: 16, G: 16, B: 16, A: 16); depth: 24 bits; stencil: 0 bits; auxiliary buffers: 0

* Render to window; double buffered; RGBA color; color: 32 bpp (R: 8, G: 8, B: 8, A: 8); accumulation: 64 bpp (R: 16, G: 16, B: 16, A: 16); depth: 24 bits; stencil: 0 bits; auxiliary buffers: 0

* Render to window; double buffered; RGBA color; color: 32 bpp (R: 8, G: 8, B: 8, A: 0); accumulation: 64 bpp (R: 16, G: 16, B: 16, A: 16); depth: 24 bits; stencil: 8 bits; auxiliary buffers: 0

* Render to window; double buffered; RGBA color; color: 32 bpp (R: 8, G: 8, B: 8, A: 8); accumulation: 64 bpp (R: 16, G: 16, B: 16, A: 16); depth: 24 bits; stencil: 8 bits; auxiliary buffers: 0

* Render to window; double buffered; RGBA color; color: 32 bpp (R: 8, G: 8, B: 8, A: 0); accumulation: 64 bpp (R: 16, G: 16, B: 16, A: 16); depth: 0 bits; stencil: 0 bits; auxiliary buffers: 0

* Render to window; double buffered; RGBA color; color: 32 bpp (R: 8, G: 8, B: 8, A: 8); accumulation: 64 bpp (R: 16, G: 16, B: 16, A: 16); depth: 0 bits; stencil: 0 bits; auxiliary buffers: 0

[Quasar]

Hier dann mal eine R300



**************
* GLINFO LOG *
**************

DRIVER INFO
---------------
Vendor : ATI Technologies Inc.
Renderer : Radeon 9700 x86/SSE
Version : 1.3.3379 Win2000 Release


OPENGL CAPABILITIES
-----------------------
Supported extensions:
GL_ARB_multitexture
GL_EXT_texture_env_add
GL_EXT_compiled_vertex_array
GL_S3_s3tc
GL_ARB_depth_texture
GL_ARB_point_parameters
GL_ARB_shadow
GL_ARB_shadow_ambient
GL_ARB_texture_border_clamp
GL_ARB_texture_compression
GL_ARB_texture_cube_map
GL_ARB_texture_env_add
GL_ARB_texture_env_combine
GL_ARB_texture_env_crossbar
GL_ARB_texture_env_dot3
GL_ARB_texture_mirrored_repeat
GL_ARB_transpose_matrix
GL_ARB_vertex_blend
GL_ARB_vertex_program
GL_ARB_window_pos
GL_ATI_element_array
GL_ATI_envmap_bumpmap
GL_ATI_fragment_shader
GL_ATI_map_object_buffer
GL_ATI_separate_stencil
GL_ATI_texture_float
GL_ATI_texture_mirror_once
GL_ATI_vertex_array_object
GL_ATI_vertex_attrib_array_object
GL_ATI_vertex_streams
GL_ATIX_texture_env_combine3
GL_ATIX_texture_env_route
GL_ATIX_vertex_shader_output_point_size
GL_EXT_abgr
GL_EXT_bgra
GL_EXT_blend_color
GL_EXT_blend_func_separate
GL_EXT_blend_minmax
GL_EXT_blend_subtract
GL_EXT_clip_volume_hint
GL_EXT_draw_range_elements
GL_EXT_fog_coord
GL_EXT_packed_pixels
GL_EXT_point_parameters
GL_EXT_rescale_normal
GL_EXT_secondary_color
GL_EXT_separate_specular_color
GL_EXT_stencil_wrap
GL_EXT_texgen_reflection
GL_EXT_texture3D
GL_EXT_texture_compression_s3tc
GL_EXT_texture_cube_map
GL_EXT_texture_edge_clamp
GL_EXT_texture_env_combine
GL_EXT_texture_env_dot3
GL_EXT_texture_filter_anisotropic
GL_EXT_texture_lod_bias
GL_EXT_texture_object
GL_EXT_texture_rectangle
GL_EXT_vertex_array
GL_EXT_vertex_shader
GL_HP_occlusion_test
GL_KTX_buffer_region
GL_NV_texgen_reflection
GL_NV_blend_square
GL_SGI_texture_edge_clamp
GL_SGIS_texture_border_clamp
GL_SGIS_texture_lod
GL_SGIS_generate_mipmap
GL_SGIS_multitexture
GL_WIN_swap_hint
WGL_EXT_extensions_string
WGL_EXT_swap_control
GL_ARB_multisample
GL_ATI_texture_env_combine3

Max. viewport size : 2048x2048
Max. texture size : 2048x2048

Max. modelview stack depth : 32
Max. projection stack depth : 10
Max. texture stack depth : 10
Max. attribute stack depth : 16
Max. name stack depth : 128

Max. display list nesting : 64
Max. evaluator order : 30
Max. number of lights : 8
Max. clipping planes : 6
Max. pixel map size : 65536

Point size range : 1,000 to 64,000
Point size granularity : 0,125
Line width range : 1,000 to 64,000
Line width granularity : 0,125

Number of auxiliary buffers : 0
Bits of sub-pixel precision : 4


ACCELERATED PIXEL FORMATS
-----------------------------

* Render to window; single buffered; RGBA color; color: 32 bpp (R: 8, G: 8, B: 8, A: 8); accumulation: 0 bpp (R: 0, G: 0, B: 0, A: 0); depth: 24 bits; stencil: 8 bits; auxiliary buffers: 0

* Render to window; single buffered; RGBA color; color: 32 bpp (R: 8, G: 8, B: 8, A: 8); accumulation: 64 bpp (R: 16, G: 16, B: 16, A: 16); depth: 24 bits; stencil: 8 bits; auxiliary buffers: 0

* Render to window; double buffered; RGBA color; color: 32 bpp (R: 8, G: 8, B: 8, A: 8); accumulation: 0 bpp (R: 0, G: 0, B: 0, A: 0); depth: 24 bits; stencil: 8 bits; auxiliary buffers: 0

* Render to window; double buffered; RGBA color; color: 32 bpp (R: 8, G: 8, B: 8, A: 8); accumulation: 64 bpp (R: 16, G: 16, B: 16, A: 16); depth: 24 bits; stencil: 8 bits; auxiliary buffers: 0

[StefanV]

Originally posted by ow
Respekt! 12 Lichtquellen.:D

Sind irgendwie wenig Formate.


Ja, wundert mich auch, daß so wenig im File sind.

Das Programm sagt, ich hab 39 verschiedene Formate...

[StefanV]

hier mal das Andere Programm:


OpenGL renderer string: Matrox ICD for Parhelia
OpenGL version string: 1.3
OpenGL extensions (GL_):
GL_ARB_multisample, GL_ARB_multitexture, GL_ARB_point_parameters,
GL_ARB_texture_border_clamp, GL_ARB_texture_compression,
GL_ARB_texture_cube_map, GL_ARB_texture_env_add, GL_ARB_texture_env_combine,
GL_ARB_texture_env_dot3, GL_ARB_transpose_matrix, GL_S3_s3tc,
GL_ATI_element_array, GL_ATI_vertex_array_object,
GL_Autodesk_valid_back_buffer_hint, GL_EXT_bgra, GL_EXT_blend_color,
GL_EXT_blend_func_separate, GL_EXT_blend_logic_op, GL_EXT_blend_minmax,
GL_EXT_blend_subtract, GL_EXT_clip_volume_hint,
GL_EXT_compiled_vertex_array, GL_EXT_draw_range_elements,
GL_EXT_element_array, GL_EXT_fog_coord, GL_EXT_multi_draw_arrays,
GL_EXT_packed_pixels, GL_EXT_point_parameters, GL_EXT_rescale_normal,
GL_EXT_secondary_color, GL_EXT_separate_specular_color, GL_EXT_stencil_wrap,
GL_EXT_subtexture, GL_EXT_texture3D, GL_EXT_texture_compression_s3tc,
GL_EXT_texture_cube_map, GL_EXT_texture_edge_clamp, GL_EXT_texture_env_add,
GL_EXT_texture_filter_anisotropic, GL_EXT_texture_lod_bias,
GL_EXT_texture_object, GL_EXT_vertex_array, GL_EXT_vertex_array_object,
GL_EXT_vertex_shader, GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3,
GL_KTX_buffer_region, GL_MTX_fragment_shader, GL_NV_texgen_reflection,
GL_SGIS_multitexture, GL_SGIS_texture_lod, WGL_EXT_swap_control.

visual x bf lv rg d st ge ge r g b a ax dp st accum buffs ms
id dep cl sp sz l ci b ro ne ac sz sz sz sz bf th cl r g b a ns b
-----------------------------------------------------------------------
0x01 32 wn . 32 . r . . . . 8 8 8 8 . 24 8 . . . . . .
0x02 32 wn . 32 . r y . . . 8 8 8 8 . 24 8 . . . . . .
0x03 32 wn . 32 . r y . . . 8 8 8 8 . 24 8 . . . . . .
0x04 32 wn . 32 . r . . y . 8 8 8 . . 32 8 16 16 16 . . .
0x05 32 wn . 32 . r . . y . 8 8 8 . . 16 8 16 16 16 . . .
0x06 32 wn . 32 . r y . y . 8 8 8 . . 32 8 16 16 16 . . .
0x07 32 wn . 32 . r y . y . 8 8 8 . . 16 8 16 16 16 . . .
0x08 32 wn . 32 . r . . y . 8 8 8 8 . 32 8 16 16 16 16 . .
0x09 32 wn . 32 . r . . y . 8 8 8 8 . 16 8 16 16 16 16 . .
0x0a 32 wn . 32 . r y . y . 8 8 8 8 . 32 8 16 16 16 16 . .
0x0b 32 wn . 32 . r y . y . 8 8 8 8 . 16 8 16 16 16 16 . .
0x0c 32 wn . 32 . c . . y . . . . . . 32 8 . . . . . .
0x0d 32 wn . 32 . c . . y . . . . . . 16 8 . . . . . .
0x0e 32 wn . 32 . c y . y . . . . . . 32 8 . . . . . .
0x0f 32 wn . 32 . c y . y . . . . . . 16 8 . . . . . .
0x10 24 bm . 24 . r . . y . 8 8 8 . . 32 8 16 16 16 . . .
0x11 24 bm . 24 . r . . y . 8 8 8 . . 16 8 16 16 16 . . .
0x12 24 bm . 24 . r . . y . 8 8 8 8 . 32 8 16 16 16 16 . .
0x13 24 bm . 24 . r . . y . 8 8 8 8 . 16 8 16 16 16 16 . .
0x14 24 bm . 24 . c . . y . . . . . . 32 8 . . . . . .
0x15 24 bm . 24 . c . . y . . . . . . 16 8 . . . . . .
0x16 16 bm . 16 . r . . y . 5 5 5 . . 32 8 11 11 10 . . .
0x17 16 bm . 16 . r . . y . 5 5 5 . . 16 8 11 11 10 . . .
0x18 16 bm . 16 . r . . y . 5 5 5 8 . 32 8 8 8 8 8 . .
0x19 16 bm . 16 . r . . y . 5 5 5 8 . 16 8 8 8 8 8 . .
0x1a 16 bm . 16 . c . . y . . . . . . 32 8 . . . . . .
0x1b 16 bm . 16 . c . . y . . . . . . 16 8 . . . . . .
0x1c 8 bm . 8 . r . . y . 3 3 2 . . 32 8 11 11 10 . . .
0x1d 8 bm . 8 . r . . y . 3 3 2 . . 16 8 11 11 10 . . .
0x1e 8 bm . 8 . r . . y . 3 3 2 8 . 32 8 8 8 8 8 . .
0x1f 8 bm . 8 . r . . y . 3 3 2 8 . 16 8 8 8 8 8 . .
0x20 8 bm . 8 . c . . y . . . . . . 32 8 . . . . . .
0x21 8 bm . 8 . c . . y . . . . . . 16 8 . . . . . .
0x22 4 bm . 4 . r . . y . 1 1 1 . . 32 8 5 6 5 . . .
0x23 4 bm . 4 . r . . y . 1 1 1 . . 16 8 5 6 5 . . .
0x24 4 bm . 4 . r . . y . 1 1 1 8 . 32 8 4 4 4 4 . .
0x25 4 bm . 4 . r . . y . 1 1 1 8 . 16 8 4 4 4 4 . .
0x26 4 bm . 4 . c . . y . . . . . . 32 8 . . . . . .
0x27 4 bm . 4 . c . . y . . . . . . 16 8 . . . . . .
-----------------------------------------------------------------------
visual x bf lv rg d st ge ge r g b a ax dp st accum buffs ms
id dep cl sp sz l ci b ro ne ac sz sz sz sz bf th cl r g b a ns b
-----------------------------------------------------------------------

[Xmas]

Ist das mit FAA an oder aus?

[ow]

SP:

Das andere Prog liefert genau dieselben PFDs.

Nur die, die unter der Spalte "gene" kein "y" haben, sind HW-beschleunigt (die ersten 3 Stueck bei dir). Der Rest ist SW-Rendering durch die opengl32.dll.
Der Parhelia nutzt (wie auch der R300, s. Quasar) immer 24Z+8 Stencil bei 32Bit Framebuffer.

Es erstaunt mich etwas, dass der Parhelia keine Accumulation Buffers unterstuetzt.
Das tun sonst alle mir bekannten ICDs, die fuer den Einsatz unter professioneller OGL-SW gedacht sind.



AFAIK melden beide Progs nur die Formate fuer sie jeweileils aktuelle Desktop-Farbtiefe. Also Desktop mal auf 16Bit und Progs nochmal laufenlassen.

[StefanV]

Originally posted by Xmas
Ist das mit FAA an oder aus?

FAA war glaub ich an.

Macht aber auch keinen Unterschied.

[StefanV]

Hm, interessant...

andere Auflösung, andere Formate, siehe hier:



* Render to window; single buffered; RGBA color; color: 32 bpp (R: 8, G: 8, B: 8, A: 8); accumulation: 0 bpp (R: 0, G: 0, B: 0, A: 0); depth: 24 bits; stencil: 8 bits; auxiliary buffers: 0

* Render to window; single buffered; RGBA color; color: 32 bpp (R: 8, G: 8, B: 8, A: 8); accumulation: 32 bpp (R: 8, G: 8, B: 8, A: 8); depth: 24 bits; stencil: 8 bits; auxiliary buffers: 0

* Render to window; double buffered; RGBA color; color: 32 bpp (R: 8, G: 8, B: 8, A: 8); accumulation: 0 bpp (R: 0, G: 0, B: 0, A: 0); depth: 24 bits; stencil: 8 bits; auxiliary buffers: 0

* Render to window; double buffered; RGBA color; color: 32 bpp (R: 8, G: 8, B: 8, A: 8); accumulation: 32 bpp (R: 8, G: 8, B: 8, A: 8); depth: 24 bits; stencil: 8 bits; auxiliary buffers: 0

* Render to window; double buffered; RGBA color; color: 32 bpp (R: 8, G: 8, B: 8, A: 8); accumulation: 0 bpp (R: 0, G: 0, B: 0, A: 0); depth: 24 bits; stencil: 8 bits; auxiliary buffers: 0

* Render to window; double buffered; RGBA color; color: 32 bpp (R: 8, G: 8, B: 8, A: 8); accumulation: 32 bpp (R: 8, G: 8, B: 8, A: 8); depth: 24 bits; stencil: 8 bits; auxiliary buffers: 0

[StefanV]

und nochmal, 16bit Desktop:


ACCELERATED PIXEL FORMATS
-----------------------------

* Render to window; single buffered; RGBA color; color: 16 bpp (R: 5, G: 6, B: 5, A: 0); accumulation: 0 bpp (R: 0, G: 0, B: 0, A: 0); depth: 24 bits; stencil: 8 bits; auxiliary buffers: 0

* Render to window; single buffered; RGBA color; color: 16 bpp (R: 5, G: 6, B: 5, A: 0); accumulation: 32 bpp (R: 8, G: 8, B: 8, A: 8); depth: 24 bits; stencil: 8 bits; auxiliary buffers: 0

* Render to window; double buffered; RGBA color; color: 16 bpp (R: 5, G: 6, B: 5, A: 0); accumulation: 0 bpp (R: 0, G: 0, B: 0, A: 0); depth: 24 bits; stencil: 8 bits; auxiliary buffers: 0

* Render to window; double buffered; RGBA color; color: 16 bpp (R: 5, G: 6, B: 5, A: 0); accumulation: 32 bpp (R: 8, G: 8, B: 8, A: 8); depth: 24 bits; stencil: 8 bits; auxiliary buffers: 0

* Render to window; double buffered; RGBA color; color: 16 bpp (R: 5, G: 6, B: 5, A: 0); accumulation: 0 bpp (R: 0, G: 0, B: 0, A: 0); depth: 24 bits; stencil: 8 bits; auxiliary buffers: 0

* Render to window; double buffered; RGBA color; color: 16 bpp (R: 5, G: 6, B: 5, A: 0); accumulation: 32 bpp (R: 8, G: 8, B: 8, A: 8); depth: 24 bits; stencil: 8 bits; auxiliary buffers: 0

[StefanV]

achso:

Beidesmal Treiber 1.02, das da oben müsste 1.01 gewesen sein.

[ow]

Scheint als würde der Parhelia immer 24Z/8Stencil nutzen, 16Z und 24Z ohne Stencil Formate fehlen.

[StefanV]

Originally posted by ow
Scheint als würde der Parhelia immer 24Z/8Stencil nutzen, 16Z und 24Z ohne Stencil Formate fehlen.

Was IMHO auch sinn macht...

Wozu braucht man noch 16bit Z-Buffer??

[Quasar]

...besonders auf einer Karte, die nicht bandbreitenlimitiert ist.

[zeckensack]

Das paßt irgendwie auch zur Aussage von Matrox beim Parhelia-Start, so in etwa "Wir halten nichts von Optimierungen, wir bieten immer und überall höchstmögliche Präzision". War AFAIK in Bezug auf Subpixel-Präzision.

[Richthofen]

wenn das derren Haltung ist, dann ist diese doch sehr leichtsinnig. Der Markt bestraft sowas gnadenlos :)
Am Besten ist man bietet beides.
Optimierungen und Präzision.

[StefanV]

Originally posted by Richthofen
wenn das derren Haltung ist, dann ist diese doch sehr leichtsinnig. Der Markt bestraft sowas gnadenlos :)
Am Besten ist man bietet beides.
Optimierungen und Präzision.

Richthofen, erstens sind wir hier nicht in einem Finanz Thread, Demurigs Aussage in einem anderen Thread mußt du wohl überlesen haben, oder??

Zweitens:

Wofür unnötig Transistoren verschwenden für etwas, das so gut wie keine Vorteile bringt??

[Demirug]

ja ohne CrossBar machen 16 Bit-Modi nicht viel Sinn.

[StefanV]

hö??

Watt is datt denn??

7012-> 32bit
6979-> 16bit

(3DM 2001)

Interessant ;)
Vermutlich ist die Parhelia auf 32bit Optimiert und beherrscht die 16bit Modi nicht wirklich gut.

[Quasar]

Hm, wenn ich jetzt sowas in Bezug auf den R300 (13580 vs. 13590) geschrieben hätte, wäre wieder ein Flamewar losgegangen....

[aths]

Originally posted by Quasar
Hm, wenn ich jetzt sowas in Bezug auf den R300 (13580 vs. 13590) geschrieben hätte, wäre wieder ein Flamewar losgegangen.... Wieso das denn?

[Quasar]

Weil ich ein böser nVidiot bin. :D

[StefanV]

Originally posted by Quasar
Weil ich ein böser nVidiot bin. :D

Schick mir die Karte und lass mich das sagen, dann gibts keine Flames *eg*

Bin ja schließlich bekannt dafür ATI zu lieben und NV zu hassen :naughty:

[Quasar]

nee, mit der Bemerkung zur Parhelia und meinem anschliessenden Konjunktiv hast du mir ja eine sichere Vorlage gegeben. Danke übrigens ;)

[Haarmann]

Quasar

Also Du bist NVidianer, NVidioten sind andere... zwischen biased sein und zwischen Brett mit nem NV Logo vor dem Kopf haben liegen noch Welten.
Und es ist eigentlich ja nich soo schlimm, wenn die 16 Bit langsam aber sicher unsere Bildschirme verlassen. Bei ner R8500 bringt aber das "Zuschalten" von 16 Bit Z-Buffer noch nen paar Prozente - mindestens bei den Zwiebeln und Q3.

Ich jedenfalls brauch kein 16Bit zum Leben - die alten Games müssen ja nur laufen, besonders fordernd sind se für die heutigen 3D Karten wohl nicht.

[tEd]

Diapolo vom rivastation forum hat jetzt eine offizielle antwort von croteam per email erhatlen.

Hi.

oh, this one is easy ...

You see, every driver on this planet adjust z-depth bits to match color depth bits if app requested 0 bits for depth. This is a good thing!
SeriousSam, by default, requires 0-bits z-depth, therefore leaving the driver to decide what z-depth is the most appropriate for current color-depth. There are two main reasons that makes this approch logical:

1) some hardware have performance penalty when color depth and z-depth are not equal. 32-bit color matches 24-bit depth with 8 bit stencil (or 8-bit alignment, whatever). That's why driver has to choose 24 (or 32) bit z-buffer when color-depth is 32-bit, and 16-bit depth when color is 16-bit.

2) if player (user) chooses to use 16-bit color, that means he/she is willing to trade quality for speed. So we can assume that z-fighting artefacts produced by 16-bit z-buffer is not an issue for him/her. And vice-versa: if 32-bit color is choosed, this would assume that no z-fighting should be present, because player opted for quality.

Needless to say, that SeriousEngine is very configurable, so anyone can force z-depth to theirs preference (cvar: '/gap_iDepthBits=n').
Hope this helps.

bye
DEN

P.S. Yes, it's definately a driver issue, not ours!

man darf weiter streiten wer schuld hat.

[aths]

Originally posted by tEd
Diapolo vom rivastation forum hat jetzt eine offizielle antwort von croteam per email erhatlen.

And vice-versa: if 32-bit color is choosed, this would assume that no z-fighting should be present, because player opted for quality.
Genau so sehe ich das auch: Bei 32-Bit-Grafik möchte ich bei unklarer Z-Buffer-Anforderung natürlich einen 24-Bit-Z-Buffer haben. Wenn der Treiber bei GF4 hier 16 Bit nimmt und bei GF3 noch sinnvollerweise 24 Bit, so halte ich das für nVidias Absicht, um hier oder da ein paar lächerliche % herauszuholen.

[zeckensack]

Was der gute DEN da schreibt ist aber leider kompletter Nonsens.

0 heißt einfach garnichts, respektive total egal was kommt.

Insofern verhält sich der NV-Treiber absolut korrekt.
Anders als andere Karten? Ja, warum auch nicht.
Geschummelt? Nein.

Wen DEN der Meinung ist, daß ein Benutzer der 32bit Farbe wählt auch 32bit Z haben will, dann ist das seine Sache. Dann hat er das aber auch so zu implementieren, ergo 32 bit anfordern, und nicht 'mir doch egal'.

[aths]

zeckensack,

ich stimme mit dem SeSam-Menschen nicht darin überein, dass es eine reine Treibersache wäre. Der Fehler liegt letztlich bei ihnen, da nVidia nicht außerhalb der Spezifikationen liegt, hingegen CroTeam geschlampt (resp. sich auf eine gewisse Treiberintelligenz verlassen) hat.

Die Frage bleibt, warum der gleiche Deto, der für GF3 noch 24 Bit wählt, auf GF4 Ti nun 16 Bit einstellt.

[Exxtreme]

Originally posted by aths

Die Frage bleibt, warum der gleiche Deto, der für GF3 noch 24 Bit wählt, auf GF4 Ti nun 16 Bit einstellt.
AFAIK kann eine GF3 keine 32 Bit-Farbtiefe UND einen 16 Bit Z-Buffer. Deswegen wählt ChoosePixelFormat(?) wohl dann zufällig die "richtige" Kombi.

[zeckensack]

Originally posted by aths
Die Frage bleibt, warum der gleiche Deto, der für GF3 noch 24 Bit wählt, auf GF4 Ti nun 16 Bit einstellt. Da verweise ich auf Matt 'NV-OGL-Treiber-Guru' Craighead, der sinngemäß sagte die Geforce3 beherrscht garkeinen 32/16-Mischmodus (jedenfalls nicht ohne aktiviertes AA).

Quellenangabe folgt sogleich, sobald OpenGL.org aus den Füßen kommt.

[Diapolo]

Stimme Dir zu, die einzigen Formate auf GF3 mit 16 Bit Z-Buffer, sind alle ein FSAA fähiges Format (mit jeweils 2 oder 4 Samples).
Das würde "erklären", warum GF3 einen 24 Bit Z-Buffer bekommt und die GF4 bei 32 Bit Farbtiefe eben den erwähnten 16 Bit Z-Buffer.

Dann wäre aber noch zu klären, wieso auf ATI karten anscheinend ein 32 Bit bzw. 24 Bit Z-Buffer gewählt wird und auf GF4 eben nicht :D.

Wie dem auch sei, ich habe nochmal ne Mail an DEN geschrieben und angefragt, ob Croteam nicht evtl. die PF-Auswahl Funktion abändern kann :).

EDIT: Alles natürlich auf 32 Bit Farbtiefe bezogen und überprüft hab ich es mit dem Log File meiner OGL App!

EDIT2: Hier mal ein Link zu der Log-File auf meiner GF3: http://home.t-online.de/home/Phil.Kaufmann/Diapolo.html

Diapolo

[zeckensack]

Originally posted by zeckensack
Quellenangabe folgt sogleich, sobald OpenGL.org aus den Füßen kommt. Ich bleib die Quelle jetzt schuldig, habe lange genug gewartet.

Das OpenGL.org-Forum ist heute ultralahm.
Nach 25 Minuten möge man mir ein Aufgeben bitte verzeihen.

[aths]

Könntest du mir mit eigenen Worten erklären, warum GF3 MSAA machen muss um eine 32/16-Bit Kombi zu erlauben, und wieso das beim GF4 jetzt anders ist?

[Demirug]

aths,

ich gehe davon aus das es etwas mit der effektivität zu tun. Aufgrund der Crossbar müssen ja immer 64 bit am Stück geschrieben werden. Wenn die GF3 nun in eimem 2*2 Pixel Raster rendert können die 2 nebeneinader liegende Pixel bei 32 bit immer zusammen gelesen und geschrieben werden. Bei 16 bit ist aber eine 4*1 Anordnung besser. Aus diesem Grund also erst mal keinen 32/16 Modus.

1x Modus
32 Bit = 1*2*32 = 64 Bit information = 1 speicher zugriffe.
16 Bit = 1*2*16 = 32 Bit information = 0.5 speicher zugriffe (sehr schlecht).

2x Modus
32 Bit = 2*2*32 = 128 Bit information = 2 speicher zugriffe.
16 Bit = 2*2*16 = 64 Bit information = 1 speicher zugriff.

4x Modus
32 Bit = 4*2*32 = 256 Bit information = 4 speicher zugriffe.
16 Bit = 4*2*16 = 128 Bit information = 2 speicher zugriffe.

Das ganze funktioniert natürlich nur wenn die Multisamplebuffer interleaved gespeichert werden.

[kalle]

Originally posted by Diapolo
Stimme Dir zu, die einzigen Formate auf GF3 mit 16 Bit Z-Buffer, sind alle ein FSAA fähiges Format (mit jeweils 2 oder 4 Samples).
Das würde "erklären", warum GF3 einen 24 Bit Z-Buffer bekommt und die GF4 bei 32 Bit Farbtiefe eben den erwähnten 16 Bit Z-Buffer.

Dann wäre aber noch zu klären, wieso auf ATI karten anscheinend ein 32 Bit bzw. 24 Bit Z-Buffer gewählt wird und auf GF4 eben nicht :D.

Wie dem auch sei, ich habe nochmal ne Mail an DEN geschrieben und angefragt, ob Croteam nicht evtl. die PF-Auswahl Funktion abändern kann :).

EDIT: Alles natürlich auf 32 Bit Farbtiefe bezogen und überprüft hab ich es mit dem Log File meiner OGL App!

Diapolo

SS2 scheint aber nicht die einzige Anwendung zu sein

http://www.forum-3dcenter.org/vbulletin/showthread.php?threadid=37945

[Diapolo]

Also das könnte auch so ein "falsche Z-Buffer Ziefe"-Fall sein, aber irgendwie sieht es auch nach OC-Fehlern aus?
Wenn ich meine Graka fies hoch übertakte haben auch einige Primitives keine Texturen mehr, wie auf dem Screenshot.
Wobei das dann eher über das ganze Bild geht und nicht nur auf Teilbereiche beschränkt ist.

Diapolo

[Xmas]

Dann hat sich das mit dem angeblichen GF4-"Bug" ja geklärt...

[Kalle]

Originally posted by Xmas
Dann hat sich das mit dem angeblichen GF4-"Bug" ja geklärt...

It's not a bug, it's a feature.:biggrin:

[Quasar]

Originally posted by kalle


SS2 scheint aber nicht die einzige Anwendung zu sein

http://www.forum-3dcenter.org/vbulletin/showthread.php?threadid=37945

Häh? Du meinst, CS verhalte sich ähnlich, weil es die Dreistigkeit besitzt mit einer Farbtiefe von 16Bit einen ebensotiefen Z-Buffer zu nutzen?

Oder willst du nur auf ein paar Artefakte aufmerksam machen?

[zeckensack]

Originally posted by aths
Könntest du mir mit eigenen Worten erklären, warum GF3 MSAA machen muss um eine 32/16-Bit Kombi zu erlauben, und wieso das beim GF4 jetzt anders ist? Demirug hat's schon recht gut getroffen denke ich :)

Bliebe natürlich die Frage, warum GF4 es trotzdem kann ...

Der Problemfall ist ja folgender:
32bit Farbe <- das geht wohl immer irgendwie durch die Crossbar.
16bit Z <- man braucht vier Werte, um einen Crossbarzugriff 'vollzukriegen'

:D
Farbzugriffe müssen sowieso als Read-Modify-Write ausgelegt werden (für Blendingoperationen), also ließe sich ein 32bit-Wert im Colorbuffer schreiben, indem man zwei holt, einen ändert und beide zurückschreibt. Hört sich höllisch ineffizient an, aber lassen wir's mal dabei. Ehrlich gesagt kann ich es mir nämlich garnicht anders vorstellen, sonst wäre es ja praktisch eine 16*16bit Crossbar. Sollte sich in der Praxis auch nicht bemerkbar machen, da die meisten Pixel deutlich innerhalb eines Dreiecks liegen und von solch einem teilweisem Zugriff garnicht betroffen sind.

Ist aber alles nur Vorgeplänkel, denn 16/16 kann die Gf3 ja auch.

IMO fehlt es einfach am nötigen Bitshift, um die Addressierung ausführen zu können. Stellen wir uns mal vor, der Chip hat zwei Zeiger gespeichert, einen auf den aktuell zu bearbeitenden Colorbuffer, den anderen auf den Z-Buffer.
Die Addressierung der Pixel ist dann in 32/32 und 16/16 jeweils gleichförmig, also man rechnet für den aktuellen Pixel einen Offset aus und addressiert
Color = BasepointerColorbuffer+offset
Depth = BasepointerDepthbuffer+offset

'offset' ist in beiden Fällen gleich. Beim Mischformat 32/16 jedoch muß Offset für den Z-Buffer um ein Bit nach rechts geschoben (also halbiert) werden, weil der Z-Buffer nur halb so groß ist.

GF3 kann's nicht, GF4 kann's.

[Demirug]

das es die GF4 kann hängt wohl irgendwie mit der Z-Buffer Kompression zusammen. Dadurch ändert sich ja einiges.

[Haarmann]

Quasar

CS läuft auch in 32 Bit... es fehlen dann zwar die Farben der Texturen, aber der Rest müsste ja wohl funzen mit 32 Bit...

Interessanter is ja nun, dass die GF4 anders reagiert als ne GF3. Während ne GF3 bei 0xFSAA auf 32Bit Z geht, macht ne GF4 16 Bit Z, bei 2x FSAA dreht sich der Spiess wohl um. Das tragisce daran wäre nun, dass ne GF3 ja nur bei 0 und 4xFSAA gut aussieht und ne GF4 nur bei 2x FSAA - Dumm gelaufen, denn mit ner GF3 lässt sich wohl ned jedes Game in 4x FSAA spielen.

[Quasar]

Originally posted by Haarmann
Quasar
CS läuft auch in 32 Bit... es fehlen dann zwar die Farben der Texturen, aber der Rest müsste ja wohl funzen mit 32 Bit...

So, erstmal den kurzen Teil.

Im verlinkten Thread beklagt sich der Ersteller allerdings, dass dieses Problem bei seiner config (1024x768x16) auftritt....

Das Half-Life (also auch CS) gut mit 32Bit funzen ist mir wohlbekannt...

[zeckensack]

Originally posted by Haarmann
Quasar

CS läuft auch in 32 Bit... es fehlen dann zwar die Farben der Texturen, aber der Rest müsste ja wohl funzen mit 32 Bit...

Interessanter is ja nun, dass die GF4 anders reagiert als ne GF3. Während ne GF3 bei 0xFSAA auf 32Bit Z geht, macht ne GF4 16 Bit Z, bei 2x FSAA dreht sich der Spiess wohl um. Das tragisce daran wäre nun, dass ne GF3 ja nur bei 0 und 4xFSAA gut aussieht und ne GF4 nur bei 2x FSAA - Dumm gelaufen, denn mit ner GF3 lässt sich wohl ned jedes Game in 4x FSAA spielen. Na und?
Dann muß CS eben nochmal gepatcht werden, wäre ja nicht das erste Mal.

Ist ehrlich gesagt unfassbar, wie treudoof einige 'große' Spiele ihre Formate auswählen.

[Quasar]

Um mal wieder auf's mittlerweile eigentliche Problem zurückzukommen, es gab damals doch diese nette Geschichte, dass die GF3 kein Early-Z in 16Bit konnte.(Suchfunktion ist leider deaktiviert...:()

Kann das damit auch zusammenhängen, bzw. ist das eigentlich in neueren Treibern schon gefixt worden? (Meine GF3 macht z.Zt. ein paar Hardwareprobleme, sprich 905-Sicherheit, dass sie kaputt ist).

@Zecki:
Ich glaube, der zweite Abschnitt von Haarmann war nicht mehr auf CS bezogen...

[Diapolo]

Originally posted by Haarmann
Interessanter is ja nun, dass die GF4 anders reagiert als ne GF3. Während ne GF3 bei 0xFSAA auf 32Bit Z geht, macht ne GF4 16 Bit Z, bei 2x FSAA dreht sich der Spiess wohl um. Das tragisce daran wäre nun, dass ne GF3 ja nur bei 0 und 4xFSAA gut aussieht und ne GF4 nur bei 2x FSAA - Dumm gelaufen, denn mit ner GF3 lässt sich wohl ned jedes Game in 4x FSAA spielen.

Moment, du wirfst da einiges durcheinander :).

GF3 macht keinen 32 Bit Z-Buffer, genausowenig, wie eine GF4.

Um 16 Bit Z bei 32 Bit Color auf einer GF3 zu bekommen ist immer ein Multisample-Buffer im PF mit vorhanden (mit 2 oder 4 Samples).
Das ist jedenfalls so, wenn man WGL_ARB_multisample nutzt, wie das nun der Treiber intern macht, wenn man FSAA im Control Panel einstellt weiss ich nicht, aber sicher auf eine ähnliche Art und Weise.

Was mich nun wundert, wieso sollte unter 4x FSAA der Fehler bei CS weg sein?

Wenn CS nicht´s spezielles anfordert, wie die SeriousEngine, dann wird bei zuschalten von FSAA wohl ein 16 bittiger Z-Buffer gewählt, anstelle eines 24 bittigen ohne FSAA (eben wegen der HW Limitierung der GF3).

Wie sieht es eigentlich bei SS2 aus, wenn man da FSAA forciert?
Auch wieder Z-Buffer Fehler auf GF3 Karten?
Das würde meine Vermutung dann ja bestätigen!

Diapolo

[aths]

Originally posted by Demirug
das es die GF4 kann hängt wohl irgendwie mit der Z-Buffer Kompression zusammen. Dadurch ändert sich ja einiges. Z-Buffer-Komprimierung beherrscht schon GF3, nur nicht so "gut" wie GeForce4.

[aths]

Originally posted by zeckensack
'offset' ist in beiden Fällen gleich. Beim Mischformat 32/16 jedoch muß Offset für den Z-Buffer um ein Bit nach rechts geschoben (also halbiert) werden, weil der Z-Buffer nur halb so groß ist.

GF3 kann's nicht, GF4 kann's.
[/Speku] Das könnte so sein. Ich hab nur noch nicht begriffen, wieso die GF3 dann aber mit MSAA 32/16 kann :sulkoff:

[Quasar]

Originally posted by Diapolo
Wie sieht es eigentlich bei SS2 aus, wenn man da FSAA forciert?
Auch wieder Z-Buffer Fehler auf GF3 Karten?
Das würde meine Vermutung dann ja bestätigen!

Diapolo

Hab' ich weiter oben schon beschrieben, bei 2xFSAA 16Bit-Z, bei 4x wieder 24Bit...usw.

[Demirug]

Originally posted by aths
Z-Buffer-Komprimierung beherrscht schon GF3, nur nicht so "gut" wie GeForce4.

Das meinte ich ja. Da wurde irgendwas verändert was wohl dazu führte das man jetzt auch ohne MSAA 32/16 benutzten kann.

[Diapolo]

Originally posted by Quasar


Hab' ich weiter oben schon beschrieben, bei 2xFSAA 16Bit-Z, bei 4x wieder 24Bit...usw.

Wärst du so nett mir die Stelle zu quoten, hab dazu noch nix gesehen ???

EDIT:
Bei CS mit -32bpp Switch habe ich mit 2x, Qunincunx und 4x FSAA diese Bildfehler und in meinen Augen sind es ganz klar Z-Fehler.
Ohne forciertes FSAA treten keine Fehler auf.

Diapolo

[Quasar]

Originally posted by Quasar
Alle Q3-Derivate, die ich kenne, verwenden aber trotz deiner Mutmaßung einen 24bittigen Z-Buffer plus 8Bit Stencil.

Interessanterweise scheint auch die GeForce3 auf 16Bit Z zurückzufallen, sobald in SeSamSE FSAA zugeschaltet wird....komisch, was?

So, bitte sehr :)

[Diapolo]

Besten Dank :).

Dann würde ich es mal als gesichert ansehen, dass sich GF3 und GF4 im Prinzip "gleich" oder ähnlich verhalten, aber da die GF3 eben kein 32 / 16 Format ohne FSAA beherrscht, hat diese das Glück ohne FSAA in den Genuss eines 24 bittigen Z-Buffers zu kommen.

Wirklich erstaunlich wieviele Spiele von der PF-Auswahl her gesehen absolut schlampig programmiert wurden *Kopf schüttel*!

Da sei es NV doch wirklich mal Nahe gelegt einen Switch in ihr CP zu integrieren, welcher einen 24 Bit Z-Buffer forciert.

Diapolo

PS.: Wie sind eigentlich nun die ATI Erfahrungen so? Mit FSAA, ohne FSAA bei SS2, CS und Quake-Engine Games?

[ow]

Originally posted by Diapolo

PS.: Wie sind eigentlich nun die ATI Erfahrungen so? Mit FSAA, ohne FSAA bei SS2, CS und Quake-Engine Games?



Die neuen ATi OGL Treiber kennen kein 16Bit Z unter 32Bit Farbtiefe mehr, nur 24Z + 8Stencil.