PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : DXT1 bei GeForce-Karten (Split aus Radeon 9000 Pro...)


aths
2002-08-05, 19:05:42
"- yes, we sacrificed image quality to gain better framerates." trifft auch auf nVs Implementierung von DXT1 zu.

ow
2002-08-05, 19:48:49
Originally posted by aths
"- yes, we sacrificed image quality to gain better framerates." trifft auch auf nVs Implementierung von DXT1 zu.

hehe, ausser dass es mit den besseren fps nix wurde.:D

davon abgesehen kann mich die TC des Radeon auch nicht so begeistern (s. Q3 Himmel).

hab jetzt wieder die Kyro drinne. der kann zwar nur DXT1, dafür aber IMO recht gut.:D

Quasar
2002-08-06, 22:42:53
Originally posted by aths
"- yes, we sacrificed image quality to gain better framerates." trifft auch auf nVs Implementierung von DXT1 zu.

Ist das deine persönliche Meinung oder ist das ein Quote eines nV-Offiziellen?

aths
2002-08-13, 18:52:12
Originally posted by Quasar
Ist das deine persönliche Meinung oder ist das ein Quote eines nV-Offiziellen? Das ist eine logische Schlussfolgerung.

Quasar
2002-08-14, 07:23:58
Originally posted by aths
Das ist eine logische Schlussfolgerung.

"Schlussfolgerung" glaube ich dir, aber das "logisch" erschließt sich mir nicht.

aths
2002-08-14, 11:28:38
Originally posted by Quasar
"Schlussfolgerung" glaube ich dir, aber das "logisch" erschließt sich mir nicht. Dann für dich:

- DXT1 dekomprimiert bei GF nur im 16-Bit-Farbraum
- DXT1-5 im 32-Bit-Farbraum

Warum?

- Die NV-Leute gingen wohl davon aus, dass vor allem DXT1 benutzt würde und überlegten, wie sie hier besonders schnell sein könnten. Sie opferten also Bildqualität für ein klein wenig mehr Geschwindigkeit.

Ist das unlogisch? Gibt es für dich logischere Erklärungen, warum sie DXT1 so kastriert haben?

ow
2002-08-14, 12:01:26
aths

deine Folgerung setzt voraus, dass NV das mit Absicht getan hat.
Das ist afaik weder bewiesen noch widerlegt.

Im uebrigen gefaellt mir das DXT1 meiner Radeon auch nicht besser.

Nur mein Kyro kriegt das akzeptabel hin, also ohne wirklich stark auffallenden Qualitaetsverlust gegenueber unkomprimierten Texturen.

aths
2002-08-14, 23:15:31
Originally posted by ow
aths

deine Folgerung setzt voraus, dass NV das mit Absicht getan hat.
Das ist afaik weder bewiesen noch widerlegt. Dass sie DXT1 im Gegensatz zu 2-5 aus Versehen beschnitten haben, kann ich mir schwer vorstellen. Da arbeiten doch keine Deppen.

Quasar
2002-08-14, 23:33:39
Ist für dich keine Limitierung der HW vorstellbar?

Oder ist es für dich logisch, daß für solcherart marginale Performancegewinne, selbst bei zwischenzeitlicher Doppelführung, was pure Leistung angeht, seit Ewigkeiten mit herumgeschleppt wird?

Xmas
2002-08-15, 04:45:25
Originally posted by Quasar
Ist für dich keine Limitierung der HW vorstellbar?
Was meinst du mit "Limitierung der HW"? Dass ein besseres DXT1 nicht auf den Chip passen würde?

Quasar
2002-08-16, 18:03:44
Originally posted by Xmas

Was meinst du mit "Limitierung der HW"? Dass ein besseres DXT1 nicht auf den Chip passen würde?

Einen HW-Bug.

Xmas
2002-08-16, 18:40:48
Originally posted by Quasar
Einen HW-Bug.
Na der hätte mittlerweile aber schon behoben werden können, oder? ;)

aths
2002-08-16, 23:52:38
Originally posted by Quasar
Ist für dich keine Limitierung der HW vorstellbar?

Oder ist es für dich logisch, daß für solcherart marginale Performancegewinne, selbst bei zwischenzeitlicher Doppelführung, was pure Leistung angeht, seit Ewigkeiten mit herumgeschleppt wird? Limitierung? Welcher Art denn? DXT2-5 sind doch auch vernünftig installiert. Der DXT1-"Bug" (der streng genommen keiner ist) ist auch bei GeForce4 noch da. Ein Chip mit 2 programmierbaren VertexShadern und PixelShader1.3 soll irgendwie "limitiert" sein, DXT1 in eine 32-Bit-Textur zu entpacken?

Die These dass sie es wegen der Geschwindigkeit machten ist in meinen Augen noch großzügig - ich hätte da auch eine "Verschwörungstheorie" anzubieten: S3TC ist nicht von NV, und was nicht von NV ist, ist nicht gut für NV, weshalb sie es mit Absicht nur kastriert übernommen haben. Die Sache mit dem minimalen Leistungsvorteil halte ich allerdings für wahrscheinlicher.

nocturne
2002-08-17, 02:10:36
aths,

warum versuchst Du eigentlich immer krampfhaft, in Threads, bei denen es um Kritik an ATI geht, mit Gewalt das Thema zu wechseln und offtopic gegen nVidia zu stänkern?

:nono:

aths
2002-08-17, 02:56:51
Originally posted by nocturne
aths,

warum versuchst Du eigentlich immer krampfhaft, in Threads, bei denen es um Kritik an ATI geht, mit Gewalt das Thema zu wechseln und offtopic gegen nVidia zu stänkern? Bitte genau den Thread verfolgen: Ich warf ein, dass der Vorwurf, Bildqualität für Geschwindigkeit zu opfern nicht einseitig an ATI gerichtet werden kann.

Thowe
2002-08-17, 09:01:25
Originally posted by nocturne
aths,

warum versuchst Du eigentlich immer krampfhaft, in Threads, bei denen es um Kritik an ATI geht, mit Gewalt das Thema zu wechseln und offtopic gegen nVidia zu stänkern?

:nono:

:lol:

Entschuldigung, aber das sagt gerade der Richtige.

Quasar
2002-08-17, 10:58:03
Originally posted by Xmas

Na der hätte mittlerweile aber schon behoben werden können, oder? ;)

Ja, natürlich. :)

Quasar
2002-08-17, 11:08:28
Originally posted by aths
Limitierung? Welcher Art denn? DXT2-5 sind doch auch vernünftig installiert. Der DXT1-"Bug" (der streng genommen keiner ist) ist auch bei GeForce4 noch da. Ein Chip mit 2 programmierbaren VertexShadern und PixelShader1.3 soll irgendwie "limitiert" sein, DXT1 in eine 32-Bit-Textur zu entpacken?

Die These dass sie es wegen der Geschwindigkeit machten ist in meinen Augen noch großzügig - ich hätte da auch eine "Verschwörungstheorie" anzubieten: S3TC ist nicht von NV, und was nicht von NV ist, ist nicht gut für NV, weshalb sie es mit Absicht nur kastriert übernommen haben. Die Sache mit dem minimalen Leistungsvorteil halte ich allerdings für wahrscheinlicher.

Eine Limitierung in Form eines Bugs, wie ich schon schrieb.

Deine Argumentation, daß der Chip 2 programmierbare Vertexshader und einen 1.3-Poxelshader besitzt, zieht nicht. Oder wie würden sonst dieser, der AF- und die diversen anderen Bugs in diesem und vergleichbaren Produkten zu erklären sein, obwohl sie geradezu lächerlich simpel anmuten?
(AF-Bug, Tri+Bi-only, derselbe Bug beim Radeon-I, etc.)

Großzügig finde ich es von euerer Majestät natürlich auch, einen Geschwindigkeitscheat zu vermuten, seid meines untertänigsten Dankes versichert. *trief*

Wieso sollte man, nachdem S3 schon lange keine größere Rolle im Desktop-Retailmarkt spielt, so etwas tun?? Ach, das wird wohl auch der Grund sein, warum sie noch kein RGSSAA von 3dfx übernommen haben. Stammt ja nicht von ihnen...

Wundert mich aber, daß z.B. die Texturfilter so gut funktionieren, oder sind die etwa von nVidia?

Ich wiederhole mich gerne noch einmal:

Wozu sollte dieser "minimale Geschwindigkeitsvorteil" denn zu Zeiten einer Doppelführung in der Geschwindigkeitsdisziplin von Nutzen sein? (Damals GF2u & GF3, jetzt GF4Ti4400 & Ti4600)
Diese Argumentation klingt in meinen virtuellen Ohren nicht gerade zwingend logisch, noch dazu ein wenig deplaziert in diesem Thread. Auch wenn "der Vorwurf, Bildqualität für Geschwindigkeit zu opfern nicht einseitig an ATI gerichtet werden kann", wieso ist es dein fortwährendes Bestreben, die Fehler des einen mit den Fehlern des anderen entschuldigen zu wollen? Wozu das? Daß kein Produkt perfekt ist, ist sicherlich auch so allen klar.

aths
2002-08-17, 12:23:10
Originally posted by Quasar
Wozu sollte dieser "minimale Geschwindigkeitsvorteil" denn zu Zeiten einer Doppelführung in der Geschwindigkeitsdisziplin von Nutzen sein? (Damals GF2u & GF3, jetzt GF4Ti4400 & Ti4600)
Diese Argumentation klingt in meinen virtuellen Ohren nicht gerade zwingend logisch, noch dazu ein wenig deplaziert in diesem Thread. Auch wenn "der Vorwurf, Bildqualität für Geschwindigkeit zu opfern nicht einseitig an ATI gerichtet werden kann", wieso ist es dein fortwährendes Bestreben, die Fehler des einen mit den Fehlern des anderen entschuldigen zu wollen? Wozu das? Daß kein Produkt perfekt ist, ist sicherlich auch so allen klar. Ich beantworte die Punkte mal in der umgekehrten Reihenfolge. Die letzte Frage verwundert mich, da ich dich als jemanden kenne*, der, solange es dem Ansehen von nV nützt, für "ausgleichende Gerechtigkeit" ist.

* Was also nur mein persönlicher, subjektiver Eindruck ist.

Die GF4 leidet in meinen Augen generell daran, dass sie bei der Entwicklung zuwenig Ressourcen bekam. Hier wurde meines Erachtens gespart. Der DXT1-"Bug" wurde durch eine Verschlimmbesserung immerhin in Angriff genommen, ohne sich dabei die Mühe eines wirklichen Bugfixings zu machen.

Ich glaube nicht an einen zufällig hereingerutschten Bug bei GF256. Der wäre spätestens mit NV15 beseitigt. Deshalb sehe ich Absicht darin. GeForce3, nunja, wurde vielleicht als so schnell eingestuft dass man S3TC gar nicht "braucht". Und bei GF4 wurde eh gespart. Vielleicht spielte ja doch ein wenig mit rein, dass nV bei den Features, die sie nicht selbst entwickelt haben, nicht so genau hinsehen.

nggalai
2002-08-17, 13:01:21
Hi there,Originally posted by ow
deine Folgerung setzt voraus, dass NV das mit Absicht getan hat.
Das ist afaik weder bewiesen noch widerlegt.
Doch, das geschah in voller Absicht:

Link: http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0104A&L=DIRECTXDEV&P=R17076&I=-3

Auszug:DXT1 is still very good for some images, but not so good for others, especially images with gradients. The 16 bit interpolation was designed to get the best performance and with DXT1, but it might have be worth the speed hit not to clamp.

For images that do not render well, you can use the DXT3 or DXT5 formats.

DXT3 and DXT5 (which also supports interpolated or explicit alpha) are not clamped.

[...]


-Doug


Douglas H. Rogers
Manager of Direct3D Technical Developer Relations
(meine Hervorhebung.)

Wäre das ein Bug, hätte Doug das anders formuliert. Hier impliziert er ganz klar Absicht, wie von aths hier "angeprangert". ;)

ta,
-Sascha.rb

Quasar
2002-08-17, 13:08:44
Eigentlich versuche ich (gerade in letzter Zeit verstärkt), möglichst jedes Produkt in seinen Fehlern isoliert zu betrachten, weil es, wie gesagt, eigentlich keine Entschuldigung für Firma X sein kann, wenn Firma Y denselben Mist baut. Im Gegenteil, für das neuere Produkt muss das eine Gelegenheit sein, sich hier positiv abzuheben. (Versuch' nicht Gegenbeispiele zu finden, es gibt mit Sicherheit noch genügend!)

Schwierig wird diese Position nur immer dann, wenn in einer Diskussion mit der Argumentation in dem Stil angefangen wird, Firma Y mache es ja auch nicht besser. Das führt unweigerlich zu Versuchen einer Gegendarstellung und ehe man sich's versieht, ist man wieder beim Adam&Eva der Grafikkarten angelangt.


Was nun den DXTC-1-Bug (in deinen Augen: Cheat?) angeht, so habe ich den Eindruck, daß die durch ihre Register Combiners ziemlich flexiblen TMUs von nVidia schon seit längerem im Einsatz sind und jeweils an die Erfordernisse der neuen Marktlage angepasst wurden.
Vom 1-TMU Design der GeForce256, welche ja schon per se recht flexibel sein musste, damit der Chip nicht zu oft zu Pipeline-Combining gezwungen wurde, über die zweite, wohl gleichartige TMU beim GeForce2 GTS bis hin zur Pixelshader-Erweiterung des GeForce3 (die nahezu unverändert im GF4 übernommen wurde).


Wenn ich diverse Postings hier im Forum, insbesondere von Demirug richtig verstanden habe, war es für nVidia (die ja auch die DX8-Shader-Specs maßgeblich mitbestimmt haben) wohl mit am einfachsten, aus ihren TMUs eine PS-kompatible Rendereinheit zu gestalten mit ein paar Änderungen um das feststehenden Grundgerüst herum.
Ich bin nun kein Chipdesigner, aber ich könnte mir sehr gut vorstellen, daß der S3TC-Bug relativ tief im Design der TMU steckt (und daß er damals wirklich zu Geschwindigkeitszwecken implementiert worden ist!). Wenn das nun so sein sollte und eine Eliminierung dieses Bugs ein tiefgreifendes Re-Design der TMU nötig machen würde und so evtl. viele Funktionen der Register-Combiners (die lt. Demirug teilw. deutlich über die Spec und die eigentlich verfügbaren Möglichkeiten hinausgingen) nicht mehr auf die ursprüngliche Weise ausführbar wären, müsste imo auch die Pixelshader-Erweiterung komplett umgestrickt werden.
-> Mein Tip: Im nV30 wird der Bug behoben sein, da komplett neues Design.


Insofern kann ich deinem letzten Absatz, ein wenig umformuliert und erweitert zustimmen, nicht aber des Aussage, daß der Bug beim GF3 und höher aus Geschwindigkeitsgründen noch vorhanden sei. Im GF4 wurde das, was mit der bestehenden TMU möglich war, getan, um den Bug möglichst wenig auffällig zu gestalten (in deinen Worten eine Verschlimmbesserung), mehr war ohne tiefgreifendes Re-Design imo nicht drin.

edit:
Sascha's Posting war eben noch nicht da, würde aber in meine obige Argumentation passen: Erst Absicht (als die Speeddifferenz wirklich noch etwas ausmacht) und später kaum aus dem Design herauszubekommen).

vogel
2002-08-17, 19:52:59
Originally posted by ow
hehe, ausser dass es mit den besseren fps nix wurde.:D

Du weist nicht wie langsam es gewesen waere es richtig zu implementieren ;)


davon abgesehen kann mich die TC des Radeon auch nicht so begeistern (s. Q3 Himmel).

hab jetzt wieder die Kyro drinne. der kann zwar nur DXT1, dafür aber IMO recht gut.:D
DXT1 Radeon == DXT1 Kyro. Quake 3 laesst den Treiber komprimieren was nicht optimal ist da gute Kompressoren sehr lange dauert. Damals musste man aber noch RGBA unterstuetzen was heute nicht mehr der Fall ist also hat es Sinn gemacht. Heutzutage wird alles in DXT gespeichert so das der Treiber garnicht komprimieren muss und es auf allen Karten die es RICHTIG implementieren gleich aussieht.

-- Daniel, Epic Games Inc.

ow
2002-08-17, 20:16:39
Originally posted by vogel

Du weist nicht wie langsam es gewesen waere es richtig zu implementieren ;)



Das ist richtig.:D


DXT1 Radeon == DXT1 Kyro. Quake 3 laesst den Treiber komprimieren was nicht optimal ist da gute Kompressoren sehr lange dauert. Damals musste man aber noch RGBA unterstuetzen was heute nicht mehr der Fall ist also hat es Sinn gemacht. Heutzutage wird alles in DXT gespeichert so das der Treiber garnicht komprimieren muss und es auf allen Karten die es RICHTIG implementieren gleich aussieht.

-- Daniel, Epic Games Inc.

Was die Ladezeiten eines Q3-level angeht, dauert´s auf der Radeon wesentlich länger bei eingeschalteter TC. Schöner ist´s dadurch aber nicht.;)
Bei GF und Kyro sind die Ladezeiten nicht merklich länger als ohne TC, die GF zeigt das bekannte Problem (welches Topic dieses Thread ist).
Auf dem Kyro sieht´s sehr gut aus. Da sieht man noch, dass die Texturen mal 32Bit waren.;)

aths
2002-08-19, 14:12:46
Quasar,

ich werfe nVidia bei DTX1 keinen Cheat vor. Ebensowenig halte ich ATIs AF oder nVidias HRAA für einen Cheat, sondern lediglich für eine "performanceoptimierte Implementierung". Weil es den "DXT3 für DXT1" Fix gibt, ist der DTX1 "Bug" (der ja kein wirklicher Bug ist) auch nicht so schlimm. Ich halte nVs Vorgehen dennoch für blöde, aus meiner ganz persönlichen Sicht beurteilt. Nur schwer kann ich mir vorstellen, dass eine echte Verbesserung von DXT1 ein aufwändiges Redesign der Pipeline erfordert hätte. Meine Theorie ist einfach, dass nV zu wenig auf solche "Feinheiten" achtet.

Meiner persönliche Erfahrung mit 3dfx-Chips ist: Was sie können, das können sie auch, und was sie nicht können, können sie gar nicht. Voodoos wurden nach meinem Empfinden irgendwie mit mehr Liebe designt. Bei nV finde ich etliche Feinheiten, die nicht zuende gedacht wurden, was mich dann stört. Dass ich keinen Gamma-Regler für das Overlay habe, 4xS-AA nicht für OpenGL angeboten wird, ich per Tweak DXT3 statt DXT1 nehmen muss, erträgliche AF-Performance ebenfalls nur via Tweaks erreichbar ist, Gamma nicht für Desktop/OpenGL/D3D getrennt geregelt werden kann usw, sind eben Dinge, die mich auf Dauer völlig abnerven.

Nun zum eigentlichen Punkt :) Da es sich hier um den Marktführer handelt, haben sich die meisten an die Macken dieser Produkte gewöhnt und empfinden sie als nicht weiter schlimm. Meiner Meinung nach ist es der falsche Weg, dem Marktführer nur wegen der Verbreitung seiner Produkte alle Nachteile nachzusehen. Im Gegenteil, sie gehören nach meinem Dafürhalten besonders angesprochen. Nur so wird sichtbar, dass es "da draußen" noch mehr gibt.

Unregistered
2002-08-19, 22:13:25
Mann, das ist doch alter Hut mit Sahne (ist mir so eingefallen).
Bei der GF1 war das noch´ne Schummelei, in die GF2 hat man das mitübernommen und seit der GF3 angeblich bereinigt..von wegen.
Ich habe mich auch gewundert warum einige Texturen in SoF2 ein wenig grünlich oder lila schimmern. Vielleicht könnte das der Glanz der Kacheln sein, aber wenn ich von DTX1 auf echte 32Bit-Texturen umstelle, da sehen diese feinsäuberlich ohne komische Farbverläufe aus.
Mann, dabei dachte ich, ich hätte mit einer GF4 endlich einen ausgereiften Chip, denkste!

vogel
2002-08-20, 01:46:26
Originally posted by Unregistered
Mann, das ist doch alter Hut mit Sahne (ist mir so eingefallen).
Bei der GF1 war das noch´ne Schummelei, in die GF2 hat man das mitübernommen und seit der GF3 angeblich bereinigt..von wegen.
Ich habe mich auch gewundert warum einige Texturen in SoF2 ein wenig grünlich oder lila schimmern. Vielleicht könnte das der Glanz der Kacheln sein, aber wenn ich von DTX1 auf echte 32Bit-Texturen umstelle, da sehen diese feinsäuberlich ohne komische Farbverläufe aus.
Mann, dabei dachte ich, ich hätte mit einer GF4 endlich einen ausgereiften Chip, denkste!
GF1-4 interpolieren DXT1 in 16 bit jedoch dithered GF4 (und XBox) in texture space => lila/ gruen.

-- Daniel, Epic Games Inc.

aths
2002-08-20, 09:58:22
Originally posted by vogel
jedoch dithered GF4Das lässt sich übrigens deaktivieren. Der Quake Himmel sieht jedenfalls sowohl mit, als auch ohne Dithering lächerlich aus.

ow
2002-08-20, 10:09:08
naja, aber immerhin nicht ganz so schlimm wie auf einer Radeon. Sieh's doch mal so.:D

aths
2002-08-20, 12:13:46
Originally posted by ow
naja, aber immerhin nicht ganz so schlimm wie auf einer Radeon. Sieh's doch mal so.:D Der Quake Himmel soll auf einer Radeon noch schlimmer aussehen?!

ow
2002-08-20, 12:35:06
Ja aths, das tut er IMO.

Nicht wegen Colorbandings sondern wegen Blockbildung.
Der Himmel sieht etwa aus, als waere er nicht bilinear gefiltert.
Man sieht dort recht grosse quadratische abgegrenzte Bereiche.

Doomtrain
2002-08-20, 12:44:02
Originally posted by aths

Meiner persönliche Erfahrung mit 3dfx-Chips ist: Was sie können, das können sie auch, und was sie nicht können, können sie gar nicht. Voodoos wurden nach meinem Empfinden irgendwie mit mehr Liebe designt. Bei nV finde ich etliche Feinheiten, die nicht zuende gedacht wurden, was mich dann stört.

Genau meine Meinung...schauen wir mal, vielleicht gibt sich das bei NV ja irgendwann.

Blackhand
2002-08-22, 18:59:14
@ow
Da du doch wohl die Treiber immer hattest um sie nach Bugs zu durchsuchen, müsste dir doch aufgefallen sein, dass der Himmel erst seit der Treiberversion 6071 si schlimm aussieht, oder?
Bei ATi ists kein Hardwarebug, bei der GeForce schon.

(Es sei denn ich hab damals die ganze Zeit net gemerkt, dass die TC deaktiviert war, was ich eher nicht glaube. Ich könnte auch grad nochmal den 58er Plutonium Treiber draufmachen)

Blackhand
2002-08-22, 22:18:40
Beim 58er sieht der Himmel doch genauso schlecht aus. Da muss ich mich wohl doch getäuscht haben. Allerdings ist der Himmel das einzige was schlechter aussieht und das bisher auch nur in Quake3, sonst in keinem anderen SPiel was ich kenne. Bei allen nicht-Himmel Texturen sehe ich keinen Unterschied zu keiner TC. Bei der GeForce betraf das schlechte TC doch alle Texturen, oder?

Für eine R100 ist der schlechte Quake3-Himmel vielleicht etwas schmerzlich, aber bei einer R8500 hat man keine Performance Probleme, wenn man die TC in Quake3 ganz weglässt.