Treiber Bugs im Deto FX und mögliche Auswirkungen auf die Benchmarkergebnisse [Archiv] - Seite 3

Achill

2003-06-06, 08:53:26

Original geschrieben von seahawk
Braucht das einen neuen Thread ??

Ist aber langsam nur noch peinlich, wahrscheinlich sind die ATI KArten im 3DMark 50% schneller.

Wobei es immer noch keine Vergleich zum Quake Cheat von ATI ist, da dieser sich direkt in einem Spiel auswirkte.

Doch es ist der gleiche Umstand, aus folgendem Grund: Als die Sache mit ATI passiert war die Perf. unter Q3 sehr wichtig für viele Käufer, heut zu tage orientiert sicher der DAU an 3DMark01 und seit es den noch schöneren (Grafisch) 3DMark03 gibt sicher auch an diesem.

Wäre 3DMark nicht so wichtig, so würde NV diesen einfach links liegen lassen. Dies kann NV nicht (hat die Sache mit eingerührt) und fährt deswegen zweigleisig, einerseits macht die den 3Dmark03 madig, auf der anderen seite optimiert (evtl. mit teilweise unsauberen methoden) sie ihre Treiberreihe extrems auf den 3DMark03.

Dies machen sie nicht - wie viele hier so schön behauten - um zu zeigen, wie schlecht der 3DMark ist, sondern weil sie momentan dem gestetzen des Markes unterliegen, die, wie schon erwähnt, sie selber eingeführt hatten im 3DMark01 und ihrer älteren Reihe. Es hat sich nun leider nur verselbstständig, wobei auch der Shadercopieler (glaub Technikforum haben wir es durchgesprochen) von MS bzw. der Shadercode im 3DMark nicht optimal für die NV3x reihe ist. Man kann sich halt doch nicht so leicht von seiner haut trennen, wenn man sich erst einmal eine übergezogen hat.

Bzgl. AF geschwindihkeit, jeder der glaubt, das durch pure Treiber Verbesserungen 30% und mehr drin sind, der hat sicher nicht verstanden, dass zum Treiber auch HW gehört und diese eine bestimmt grenze besitz. Es ist sicher möglich 1 oder vielleicht auch 2 mal größere Sprünge in der Geschwindigkeit bzgl. der Treiber zu machen, aber nicht mehrmals.

Als das hier angesprochene sehe ich nätürlich genauso bei ATI Grafikkarten, würde dort der gleiche Umstand ein trehten, wäre ich genauso dagegen, weil ich als Endverbrachern darunter leide.

Zuletzt noch etwas zur Argumentation, dass ATI das ja schon in der Vergangenheit gemacht hat.
Ich kann nicht im realen Leben zu einem Kaufhaus gehen und einfach etwas klauen und dann, wenn ich erwischt werde, einfach sagen, letzte Woche hat doch auch einer geklaut...

Quasar

2003-06-06, 08:54:28

Ich frag' mich grade, in welchem Modus die Jungs wohl den 3DMark03 haben laufen lassen, was die Texturfiltering-Optionen angeht.

"optimal" oder "trilinear", da gibt's nämlich ähnliche lustige Unterschiede....
Wer da wohl definiert hat, was optimal ist...

Achill

2003-06-06, 08:56:00

Ich bin dafür sofort das mergen rückgänig zu machen, es ist afk ein neuer Umstand, es hätte ein freundlicher Threadtitel ausgereicht.

StefanV

2003-06-06, 09:27:08

Original geschrieben von seahawk
Wobei es immer noch keine Vergleich zum Quake Cheat von ATI ist, da dieser sich direkt in einem Spiel auswirkte.

Wobei der von vielen als Cheat abgestempelte BUG in einem frühen 70er Treiber eher ein Bug war, da die Performance im nachfolgenden Treiber NICHT geringer wurde, im Gegenteil, die Performance wurde noch geringfügig gesteigert...

Dürfte eher mit dem UT2003 Detailtexturenbug vergleichbar sein...

2003-06-06, 09:29:09

Original geschrieben von Stefan Payne
Wobei der von vielen als Cheat abgestempelte BUG in einem frühen 70er Treiber eher ein Bug war, da die Performance im nachfolgenden Treiber NICHT geringer wurde, im Gegenteil, die Performance wurde noch geringfügig gesteigert...

Naja, auch ATi ist lernfaehig und verfeinert sein Cheats fortlaufend oder haeltst du die vielleicht fuer zu daemlich dazu?

nagus

2003-06-06, 09:31:16

Original geschrieben von ow
Naja, auch ATi ist lernfaehig und verfeinert sein Cheats fortlaufend oder haeltst du die vielleicht fuer zu daemlich dazu?

NVIDIA =/ ATI, kappiert?

Salvee

2003-06-06, 09:32:54

Original geschrieben von Quasar
Ich frag' mich grade, in welchem Modus die Jungs wohl den 3DMark03 haben laufen lassen, was die Texturfiltering-Optionen angeht.

"optimal" oder "trilinear", da gibt's nämlich ähnliche lustige Unterschiede....
Wer da wohl definiert hat, was optimal ist...

:|

nVidia 'definiert' zumindest per Exe-Erkennung schonmal, was für ihre Chips das schnellste Setting ist.

Anscheinend werden sie durch die Anweisungsfolge beim Anfordern des Trilinearen AF von M$ und FM benachteiligt :stareup:

2003-06-06, 09:35:28

Original geschrieben von nagus
NVIDIA =/ ATI, kappiert?

Noe, bzgl. cheaten nehmen die sich garnix. ATi=NVidia!

2003-06-06, 09:36:30

Original geschrieben von Salvee
:|

nVidia 'definiert' zumindest per Exe-Erkennung schonmal, was für ihre Chips das schnellste Setting ist.

Gibt es einen Beleg dass ATi dies nicht tut?

Quasar

2003-06-06, 09:37:10

Original geschrieben von nagus
NVIDIA =/ ATI, kappiert?

Es heisst != und nicht =/ und "kapieren" wird nicht mit doppel-t geschrieben.... :eyes: :nono:

Und du hast recht, nVidia ist nicht ATi und bekommt von Futuremark "robust tools to detect such mechanisms" geliefert, weil sie ja nicht im sog. BETA-Programm sind.

In den Zwanzigern hat man das noch "Schutzgeld" genannt.

Du willst doch nicht, dass deine Produkte in unserem industry standard "Gaymer's Benchmark" schlecht aussehen, oder?
Nun, da habe ich ein Angebot für dich, das du nicht ablehnen kannst

Disclaimer:
Natürlich bezieht sich diese Geschichte weder implizit oder ausdrücklich auf reale Geschehnisse, Firmen oder Personen sondern ist frei erfunden.

Quasar

2003-06-06, 09:41:48

Original geschrieben von Salvee
:|

nVidia 'definiert' zumindest per Exe-Erkennung schonmal, was für ihre Chips das schnellste Setting ist.

Anscheinend werden sie durch die Anweisungsfolge beim Anfordern des Trilinearen AF von M$ und FM benachteiligt :stareup:

Mölicherweise werden sie durch die Applikationseinstellung auch zu vollem, winkelunabhängingen AF gezwungen, obwohl es eine viel schnellere Einstellung dafür gibt, die optisch dasselbe Resultat liefert.

Jaja, ich weiss, das Differenzbild. Aber leider sind die Aussagen von Tech-Report inkonsistent. Selbst wenn sie zur Probe zweimal dasselbe Bild mit dem "Murks03" gerendert haben: Dabei hatte der Chip einen anderen Workload, als wenn unterschiedliche Filtereinstellungen genutzt würden.
Auch im cheatbefreiten "330" ohne das nun kritisierte AF habe ich bei zwei Screenshots desselben Screens auf unterschiedlichen Karten pixelweise Unterschiede in den Bildern, die auf einem Differenzbild sicher ähnlich wie das von Tech-Report gepostete Bild aussähen.

Insofern....

Salvee

2003-06-06, 09:42:40

Original geschrieben von ow
Gibt es einen Beleg dass ATi dies nicht tut?

Nein, aber es gibt auch keinen, der dafür spräche.

Bei nV sieht die Sache im Moment leider anders aus.

Nur weil die einen gerade mit runtergelassenen Hosen erwischt werden, muss man dem anderen nicht auch spekulativ die Hosen runterziehen ;)

Salvee

2003-06-06, 09:45:36

Original geschrieben von Quasar
Mölicherweise werden sie durch die Applikationseinstellung auch zu vollem, winkelunabhängingen AF gezwungen, obwohl es eine viel schnellere Einstellung dafür gibt, die optisch dasselbe Resultat liefert.

Hört sich zumindest plausibel an, wenn es denn für eine Applikation möglich sein sollte, dieses AF-Verfahren zu erzwingen.

Tarkin

2003-06-06, 09:47:21

Original geschrieben von ow
Noe, bzgl. cheaten nehmen die sich garnix. ATi=NVidia!

Sicher ow

:tröst:

Also wenn ich mir die aktuelle Nachrichtenlage ansehe, dann ist wohl eher Nvidia aktueller Cheat-Meister.

Wennst allerdings ein aktuelles ATI Beispiel hast ... und bitte komm jetzt nicht mir 3dMark 2003 oder Quack!

Exxtreme

2003-06-06, 09:48:06

Original geschrieben von Salvee
Anscheinend werden sie durch die Anweisungsfolge beim Anfordern des Trilinearen AF von M$ und FM benachteiligt :stareup:
Good one! :lol:

Also bei mir hat NV in Sachen GraKas das Vertrauen vollkommen verspielt. :(

Quasar

2003-06-06, 09:49:47

Original geschrieben von Exxtreme
Good one! :lol:

Also bei mir hat NV in Sachen GraKas das Vertrauen vollkommen verspielt. :(

Keine große Überraschung, das aus deinem Mund zu hören.... =)
(nich böse sein...)

seahawk

2003-06-06, 09:50:48

Ich sag nur herzlichen Glückwunsch NV, ich hoffe es werden noch mehr Optimierungen/Cheats gefunden, damit dieser unsägliche 3DMark endlich verschwindet.

Momentan bewiest es für mich nur eins, dass der 3DMark stark cheatanfällig ist. (Besonders lame ist ja, dass diese Problem anscheinend durch ATI an die Website gemeldet wurde..)

Aber, sollte jemand NV so etwas in einem realen Spiel (UT,SS:SE oder was auch immer) nachweisen, dann wäre es für mich ein Grund niewieder NV-Produkte zu kaufen oder zu empfehlen

2003-06-06, 09:50:50

Original geschrieben von Salvee
Nein, aber es gibt auch keinen, der dafür spräche.

Bei nV sieht die Sache im Moment leider anders aus.

Nur weil die einen gerade mit runtergelassenen Hosen erwischt werden, muss man dem anderen nicht auch spekulativ die Hosen runterziehen ;)

Dass ATi beim 3DMark cheaten ertappt wurde trotz Teilnahme am Beta-Programm weisst du aber?

Und wieso ist in diesem techreport Artikel nicht zum Vergleich eine Radeon mitgebencht worden? Das macht mich nachdenklich.
Ebenso folgendes:

You probably won't be surprised to learn that my tip came from ATI. The ATI folks say they were studying the Detonator FX driver's new filtering routines, to see what they could learn, when they discovered this quirk.

:lol:, ati versucht also von Nv zu lernen, ist doch geil, oder??

Quasar

2003-06-06, 09:51:30

Original geschrieben von Salvee
Hört sich zumindest plausibel an, wenn es denn für eine Applikation möglich sein sollte, dieses AF-Verfahren zu erzwingen.

IIRC war das auch der Grund, dass die Doom3-Benches in HQ (wo ja 8xAF per Applikation erzwungen wird) zugunsten der Radeon ausgingen, da hier absolut unoptimiertes AF à la GF3/4 zum Einsatz kam.

Gästle

2003-06-06, 09:52:06

Original geschrieben von ow
Noe, bzgl. cheaten nehmen die sich garnix. ATi=NVidia!

Zwischen 2% und 24% vermag man noch zu unterscheiden.

PS: Ich glaub ich bin im Zoo, so wie sich hier mancher dreht und windet. Ist teilweise schon peinlich. :kratz2:

Exxtreme

2003-06-06, 09:53:05

Original geschrieben von seahawk

Momentan bewiest es für mich nur eins, dass der 3DMark stark cheatanfällig ist. (Besonders lame ist ja, dass diese Problem anscheinend durch ATI an die Website gemeldet wurde..)

Cheatanfällig ist wirklich alles. :)

FM kann dagegen nichts machen.

Salvee

2003-06-06, 09:54:39

Original geschrieben von seahawk
(Besonders lame ist ja, dass diese Problem anscheinend durch ATI an die Website gemeldet wurde..)

Ach ja...
Du weisst, wie die Quack-Geschichte an die Öffentlichkeit kam ? ;)

2003-06-06, 09:56:20

Original geschrieben von Gästle
Zwischen 2% und 24% vermag man noch zu unterscheiden.

PS: Ich glaub ich bin im Zoo, so wie sich hier mancher dreht und windet. Ist teilweise schon peinlich. :kratz2:

btw. so buggy, wie die Ati D3D Treiber sind duerfte man damit ueberhaupt nix benchen, auf der 8500 muss man immer noch in der Haelfte der Applikationen HWTL auschalten, damit's fehlerfrei laeuft.

Axel

2003-06-06, 09:57:06

Original geschrieben von ow
Dass ATi beim 3DMark cheaten ertappt wurde trotz Teilnahme am Beta-Programm weisst du aber?

Das ist mir neu, daß ATI gecheatet hat. Du willst doch nicht allen Ernstes die Optimierungen als Cheat bezeichnen?

2003-06-06, 09:58:23

Original geschrieben von Axel
Das ist mir neu, daß ATI gecheatet hat. Du willst doch nicht allen Ernstes die Optimierungen als Cheat bezeichnen?

Lt. Futuremark hat ATi gecheatet.

seahawk

2003-06-06, 09:58:54

Original geschrieben von Exxtreme
Cheatanfällig ist wirklich alles. :)

FM kann dagegen nichts machen.

Da bin ich nicht sicher. Solange die an dem Prinzip "ein Code für alle Karten" festhalten wird immer einer benachteiligt (das kann im 2001 ATI sein und im 2003er NV - habe ich schon beim 2001er gesagt).

Glaubwürdig wird es erst, wenn die für jede Karte in Absprache mit den Herstellern einen eigenen Pfad entwicklen, der auf die jeweilige Karte optimiert ist und optisch gleiche Ergebnisse liefert.

(Hätten die schon für den 2001er und Radeon 8500 genutzt, wäre die Karte deutlich vorne gewesen)

Danach wäre klär, dass jeder Eingriff durch den Treiber ein Cheat ist. Momentan ist die Grenze zwischen Optimierung und Cheat fliessend.

Salvee

2003-06-06, 09:59:22

Original geschrieben von ow
:lol:, ati versucht also von Nv zu lernen, ist doch geil, oder??

:D

Ich habe schon vor Monaten, als per Rivatuner die Möglichkeit geboten wurde, nur einzelne Texturstages anisotrop zu filtern, beispielsweise Zeckensack gefragt, ob das auch bei ATi möglich sei (er sagt, prinzipiell ja, btw).
Seit dem frage ich mich ständig, warum sie es nicht endlich machen!
Scheinbar ist ATi jetzt auf den Trichter gekommen :D

Demirug

2003-06-06, 09:59:50

Original geschrieben von Salvee
Hört sich zumindest plausibel an, wenn es denn für eine Applikation möglich sein sollte, dieses AF-Verfahren zu erzwingen.

Bei den nV Treiber ist es so das wenn eine Applikation unter D3D explizit AF-Angefordert hat dann werden die Qualitätsettings des Panels ingnoriert und man bekommt das "gute" AF. Der Grund dafür ist das nV davon ausgeht das wenn eine Applikation AF anfordert sie auch Textureabhängig die richtige Wahl bezüglich maxAF und bi/tri trift.

Exxtreme

2003-06-06, 10:00:38

Original geschrieben von seahawk
Glaubwürdig wird es erst, wenn die für jede Karte in Absprache mit den Herstellern einen eigenen Pfad entwicklen, der auf die jeweilige Karte optimiert ist und optisch gleiche Ergebnisse liefert.

Was hat das jetzt mit der Cheatanfälligkeit zu tun? :stareup:

Axel

2003-06-06, 10:02:30

Original geschrieben von ow
Lt. Futuremark hat ATi gecheatet.

Achja FM und deren sehr strenge Auslegung.
Ich hätte absolut nichts dagegen, wenn ATi oder auch NV ihre Treiber anpassen. Beide können die Bearbeitungsreihenfolge verändern, daß ist ok, aber einen vorgegebenen Teil nicht zu rendern, ist cheaten und das hat nur NV getan.

seahawk

2003-06-06, 10:02:38

Original geschrieben von Exxtreme
Was hat das jetzt mit der Cheatanfälligkeit zu tun? :stareup:

Bitte ganz lesen.

Demirug

2003-06-06, 10:02:41

Original geschrieben von ow
Lt. Futuremark hat ATi gecheatet.

Das Wort Cheat gibt es doch nicht mehr im Wortschatz von FM. Es gibt nur noch "Applikationsspezifische Optimierungen" die aber trotzdem nach Meinung von FM verboten sind.

Gast

2003-06-06, 10:02:59

Original geschrieben von ow
Dass ATi beim 3DMark cheaten ertappt wurde trotz Teilnahme am Beta-Programm weisst du aber?
....

Auch Nvidia nahm am Beta-Programm teil und verließ dieses 3 Monate vor dem Release. Daß in der Zeit nicht mehr die Shader geschrieben wurden, ist uns doch klar, oder?!

Exxtreme

2003-06-06, 10:05:47

Original geschrieben von seahawk
Bitte ganz lesen.
Und du glaubst tatsächlich, daß wenn FM anfängt für NV zu optimieren, die Cheats aufhören werden?

Ich habe langsam das Gefühl, daß einige hier die Cheaterei seitens NV als so eine Art Selbstverteidigung ansehen... :stareup:

Gästle

2003-06-06, 10:09:07

Eindeutiger als mit den Clipping Planes kann man gar nicht cheaten.

Deswegen: Nvidia cheatet. Natürlich nur zum Wohle der Allgemeinheit. :lol:

2003-06-06, 10:12:32

Original geschrieben von Axel
Achja FM und deren sehr strenge Auslegung.
Ich hätte absolut nichts dagegen, wenn ATi oder auch NV ihre Treiber anpassen. Beide können die Bearbeitungsreihenfolge verändern, daß ist ok, aber einen vorgegebenen Teil nicht zu rendern, ist cheaten und das hat nur NV getan.

Soll das ein Versuch sein, Atis Cheating zu legitimieren, weil Nv auch cheatet?
Die Vorstellung von FM bzgl. Optimierung duerfte ja mittlerweile klar sein, oder?

Quasar

2003-06-06, 10:12:51

Original geschrieben von Gast
Auch Nvidia nahm am Beta-Programm teil und verließ dieses 3 Monate vor dem Release. Daß in der Zeit nicht mehr die Shader geschrieben wurden, ist uns doch klar, oder?!

Geschrieben vielleicht nicht, aber du siehst ja selber, wie schnell durch einfache Umsortierung der Instruktionen massive Leistungsunterschiede sichtbar werden.

Und ein paar Zeilen c&p bekomme sogar ich in drei Monaten hin...

2003-06-06, 10:13:47

btw. kennt schon jemand das hier:

http://www.hardocp.com/article.html?art=NDgy

Quasar

2003-06-06, 10:15:37

Original geschrieben von Gästle
Eindeutiger als mit den Clipping Planes kann man gar nicht cheaten.

Deswegen: Nvidia cheatet. Natürlich nur zum Wohle der Allgemeinheit. :lol:

Hast du schon gewusst, dass Bezahler err Teilnehmer des BETA-Programmes "robust tools to detect such mechanisms" zur Verfügung gestellt bekommen?

Und wenn man die hat, was glaubst du, wie einfach es sein könnte, auch mal eben die Free-Fly Beta-Version zu detecten und dann den Himmel doch zu rendern, sobald eine Bewegungseingaben erfolgt?

Ich habe das Gefühl, manche hier sind reichlich naiv, wenn es um die Geldverdien-Maschinerie von Multi-Milliarden-Dollar-Konzernen geht.

Iceman346

2003-06-06, 10:16:21

Original geschrieben von ow
btw. so buggy, wie die Ati D3D Treiber sind duerfte man damit ueberhaupt nix benchen, auf der 8500 muss man immer noch in der Haelfte der Applikationen HWTL auschalten, damit's fehlerfrei laeuft.

Ist klar, darum spielt mein Bruder ja auch seit Monaten auf der 8500er mit teilweise völlig veralteten Treibern ohne jedwede Probleme.

seahawk

2003-06-06, 10:17:49

Original geschrieben von Exxtreme
Und du glaubst tatsächlich, daß wenn FM anfängt für NV zu optimieren, die Cheats aufhören werden?

Ich habe langsam das Gefühl, daß einige hier die Cheaterei seitens NV als so eine Art Selbstverteidigung ansehen... :stareup:

Ehrlich gesagt : JA - es ist eine Art "Selbstverteidigung"

Der Vorsprung der Radeons im 3DMark2003 steht in keinem Verhältnis zu irgendeinem realen Spiele Benchmark.

Außerdem weiß ich nicht ob die Cheats dann aufhören, aber dann ist es wenigstens klar, dass es ein Cheat ist. Ist ein Renderpfad für die Karte drinne, dem der Hersteller zu gestimmt hat, dann ist jede Änderung ein Cheat.

Salvee

2003-06-06, 10:20:58

Original geschrieben von ow
btw. kennt schon jemand das hier:

http://www.hardocp.com/article.html?art=NDgy

Kyle Bennet ist dank enger Freundschaft zu Brian Burke nichts weiter als ein Sprachrohr für nVidia-PR.

Solange nicht Brent seine Meinung kundtut, ist [H]-Speak=nV-Speak.

Gast

2003-06-06, 10:21:31

Original geschrieben von Quasar
Geschrieben vielleicht nicht, aber du siehst ja selber, wie schnell durch einfache Umsortierung der Instruktionen massive Leistungsunterschiede sichtbar werden.

"Einfache Umsortierung" klingt schonmal sehr .... . Demi hat was schönes zu dem Thema geschrieben, stellt sich aber sehr komplex dar.

Und ein paar Zeilen c&p bekomme sogar ich in drei Monaten hin...

Na da freu ich mich schon drauf. Vielleicht solltest du das wirklich mal versuchen, dann würdest du mitunter nicht so argumentieren.

Axel

2003-06-06, 10:23:41

Original geschrieben von ow
Soll das ein Versuch sein, Atis Cheating zu legitimieren, weil Nv auch cheatet?
Die Vorstellung von FM bzgl. Optimierung duerfte ja mittlerweile klar sein, oder?

Nicht doch.
Ich denke nicht einmal FM hätte etwas gesagt, wenn NV nur die Shaderinstruktionen für Ihre Karten angepasst hätten. Und es ist auch irrelevant für mich was FM als Cheat ansieht. Wie gesagt, die beschriebenen Optimierungen halte ich für legetim, aber NV geht mittlerweiler zu weit.

seahawk

2003-06-06, 10:24:07

Original geschrieben von ow
btw. kennt schon jemand das hier:

http://www.hardocp.com/article.html?art=NDgy

Da ist eigentlich alles gesagt. :up:

Exxtreme

2003-06-06, 10:26:19

Original geschrieben von seahawk
Der Vorsprung der Radeons im 3DMark2003 steht in keinem Verhältnis zu irgendeinem realen Spiele Benchmark.

Weil kein derzeitiges Spiel so shader-lastig ist wie der 3DMark03, so einfach ist das.

Mich würde tatsächlich interessieren wieviel NV durch den Einsatz von Clipping-Planes an Geschwindigkeit rausgeholt hat. Ich denke sehr viel mehr als durch den Austausch der Shader.
Original geschrieben von seahawk
Außerdem weiß ich nicht ob die Cheats dann aufhören, aber dann ist es wenigstens klar, dass es ein Cheat ist. Ist ein Renderpfad für die Karte drinne, dem der Hersteller zu gestimmt hat, dann ist jede Änderung ein Cheat.
Es ist auch jetzt schon klar, daß es ein Cheat ist. Die Clipping-Planes haben mit den Shadern gar nichts zu tun.

Quasar

2003-06-06, 10:27:53

Original geschrieben von Gast
"Einfache Umsortierung" klingt schonmal sehr .... . Demi hat was schönes zu dem Thema geschrieben, stellt sich aber sehr komplex dar.

Na da freu ich mich schon drauf. Vielleicht solltest du das wirklich mal versuchen, dann würdest du mitunter nicht so argumentieren.
Einfache Umsortierung der Reihenfolge derselben komlizierten Shaderinstruktionen.
Die Reihenfolge machts und die kann man so oder so wählen.

Deswegen bezog ich mich auch ausdrücklich nicht auf das Schreiben der Shader, sondern nur auf die Umsortierung der Anweisungen.

Ich bin sicher, wenn man sich mit der Materie auskennt und Einblick in die Interna des 3DMark03 hat, könnte man die am peformance-kritischsten Shader innerhalb weniger Tage (maximum!) entsprechend intern umsortieren.

Ich hoffe, das war jetzt klar und eindeutig.

seahawk

2003-06-06, 10:30:26

Axel

2003-06-06, 10:30:52

Original geschrieben von Exxtreme
Mich würde tatsächlich interessieren wieviel NV durch den Einsatz von Clipping-Planes an Geschwindigkeit rausgeholt hat. Ich denke sehr viel mehr als durch den Austausch der Shader.

Es ist auch jetzt schon klar, daß es ein Cheat ist. Die Clipping-Planes haben mit den Shadern gar nichts zu tun.

ganz meine Meinung

Gast

2003-06-06, 10:33:44

Original geschrieben von seahawk
Ehrlich gesagt : JA - es ist eine Art "Selbstverteidigung"

Der Vorsprung der Radeons im 3DMark2003 steht in keinem Verhältnis zu irgendeinem realen Spiele Benchmark.

Außerdem weiß ich nicht ob die Cheats dann aufhören, aber dann ist es wenigstens klar, dass es ein Cheat ist. Ist ein Renderpfad für die Karte drinne, dem der Hersteller zu gestimmt hat, dann ist jede Änderung ein Cheat.

Und schön zu sehen, daß plötzlich einige ihre jetzt ihren Moralischen entdecken; hat euch doch sonst nicht gestört. Da hieß es immer: Nvidia schreibt die dollsten Treiber... .

Im 3dMark, wo der Code einmal nicht direkt auf Nvidia optimiert ist, sehen die überhaupt kein Land. Krass, was müssen ATI und PVR über die Jahre geleistet haben, trotzdem noch konkurrenzfähig dazustehen.

2003-06-06, 10:34:06

Original geschrieben von Iceman346
Ist klar, darum spielt mein Bruder ja auch seit Monaten auf der 8500er mit teilweise völlig veralteten Treibern ohne jedwede Probleme.

Ist klar, deshalb koennte ich auf Anhieb mehr als eine halbes Dutzend Applikationen nennen, die nur mit SWTL unter D3D auf der 8500 fehlerfrei laufen.
Man schaue in die entsprechenden Threads hier im Forum. Ich hab keine Lust das immer wieder durchzukauen.

seahawk

2003-06-06, 10:36:31

Original geschrieben von Gast
Und schön zu sehen, daß plötzlich einige ihre jetzt ihren Moralischen entdecken; hat euch doch sonst nicht gestört. Da hieß es immer: Nvidia schreibt die dollsten Treiber... .

Im 3dMark, wo der Code einmal nicht direkt auf Nvidia optimiert ist, sehen die überhaupt kein Land. Krass, was müssen ATI und PVR über die Jahre geleistet haben, trotzdem noch konkurrenzfähig dazustehen.

Nur gab es damals keine komplexen Shaderoprationen ......

Quasar

2003-06-06, 10:36:34

Original geschrieben von Gast
Und schön zu sehen, daß plötzlich einige ihre jetzt ihren Moralischen entdecken; hat euch doch sonst nicht gestört. Da hieß es immer: Nvidia schreibt die dollsten Treiber... .

Im 3dMark, wo der Code einmal nicht direkt auf Nvidia optimiert ist, sehen die überhaupt kein Land. Krass, was müssen ATI und PVR über die Jahre geleistet haben, trotzdem noch konkurrenzfähig dazustehen.

Bis hin zu DX8 haben sich lt. Demirug die Optimierungsguides von ATi und nV kaum etwas getan. Was für den einen gut war, passte auch beim anderen.

Unter DX9 ist's eben anders.

Demirug

2003-06-06, 10:40:47

Original geschrieben von Exxtreme
Weil kein derzeitiges Spiel so shader-lastig ist wie der 3DMark03, so einfach ist das.

Mich würde tatsächlich interessieren wieviel NV durch den Einsatz von Clipping-Planes an Geschwindigkeit rausgeholt hat. Ich denke sehr viel mehr als durch den Austausch der Shader.

Es ist auch jetzt schon klar, daß es ein Cheat ist. Die Clipping-Planes haben mit den Shadern gar nichts zu tun.

Nachdem ich mich jetzt mal informiert habe wie der NV3X Clipplanes verarbeite bin ich zu 99,99% Sicher das es sich nicht um einen Clipplane Cheat handelt.

Der NV3X ist eigentlich so gar kein Freund von Clipplanes was daher kommt das er überhaupt nicht in der Lage ist auf Geometrieebene zu clippen. Auf dieser Ebene kann er nur Cullen.

Und mit den Shadern hat das schon was zu tun. Die pro Vertex Arbeit für die Clipplanes wird von den Vertexshadern mit erledigt.

Edit NV30 durch NV3X ersetzt weil es ja für alle Chips der FX-Rheie gilt.

Gast

2003-06-06, 10:42:20

Original geschrieben von Quasar
Bis hin zu DX8 haben sich lt. Demirug die Optimierungsguides von ATi und nV kaum etwas getan. Was für den einen gut war, passte auch beim anderen.

Unter DX9 ist's eben anders.

Da irrst du dich. Diese Problematik kam schon mit T&L bzw. den ersten VS-Shadern(DX 8) auf. Thomas auf Tommti-systems hat das mal plausibel dargelegt.

Exxtreme

2003-06-06, 10:42:27

Original geschrieben von seahawk
Ich rede nicht von den Clipping-Planes, aber von der AF und Shadersache. Das eine ist nur dumm, dass andere ??
Was hat das jetzt mit dem AF zu tun?

2003-06-06, 10:44:03

Original geschrieben von Quasar

Ich habe das Gefühl, manche hier sind reichlich naiv, wenn es um die Geldverdien-Maschinerie von Multi-Milliarden-Dollar-Konzernen geht.

Full ack.

Iceman346

2003-06-06, 10:46:33

Original geschrieben von ow
Ist klar, deshalb koennte ich auf Anhieb mehr als eine halbes Dutzend Applikationen nennen, die nur mit SWTL unter D3D auf der 8500 fehlerfrei laufen.
Man schaue in die entsprechenden Threads hier im Forum. Ich hab keine Lust das immer wieder durchzukauen.

Boah, ganze 6 Stück! Und das sind dann gleich 50% für dich? BTW, wenn unter diese Applikationen solche Sachen wie die PowerVR Demos fallen sehe ich das als nicht wichtig an. Wenns Spiele sind ist der Einwand berechtigt.

Demirug

2003-06-06, 10:47:31

Original geschrieben von Gast
Da irrst du dich. Diese Problematik kam schon mit T&L bzw. den ersten VS-Shadern(DX 8) auf. Thomas auf Tommti-systems hat das mal plausibel dargelegt.

Welche Problematik?

Das einzige was zu diesem Thema in den Guides steht ist folgendes:

NV: Benutze VS nur dann wenn T&L nicht ausreicht weil T&L auf mehr Chips läuft und auch auf Chips mit VS noch minimal schneller ist.

ATI: kürzere VS Programme sind besser weil davon mehr in den Programmcache passen. Bitte nicht ständig zwischen T&L und VS Programmen hin und her springen weil der R200 das nicht mag.

Das ist zwar jetzt nicht zu 100% kompatibel aber auch nicht so kritisch weil leicht zu umgehen.

seahawk

2003-06-06, 10:48:52

Original geschrieben von Exxtreme
Was hat das jetzt mit dem AF zu tun?

Um was geht es denn sonst bei dem Artikel von Nagus ?? Um einen AF-Cheat.

2003-06-06, 10:49:38

Original geschrieben von Salvee
Kyle Bennet ist dank enger Freundschaft zu Brian Burke nichts weiter als ein Sprachrohr für nVidia-PR.

Solange nicht Brent seine Meinung kundtut, ist [H]-Speak=nV-Speak.

Hast du's ueberhaupt gelesen?

Dann frage ich dich jetzt mal: wofuer werfen die Firmen FM hunderttausende von Dollars in den Rachen?? Welche Gegenleistung erfolgt dafuer??

Der 3DM03 ist tot, man sollte sich halt nicht von Firmen kaufen lassen, deren System-Performance man evaluieren will.

Salvee

2003-06-06, 10:51:00

Original geschrieben von Quasar
Ich habe das Gefühl, manche hier sind reichlich naiv, wenn es um die Geldverdien-Maschinerie von Multi-Milliarden-Dollar-Konzernen geht.

Willst du damit die 'Optimiererei' begründen oder legitimieren?

Andre

2003-06-06, 10:52:16

Original geschrieben von Demirug
Nachdem ich mich jetzt mal informiert habe wie der NV3X Clipplanes verarbeite bin ich zu 99,99% Sicher das es sich nicht um einen Clipplane Cheat handelt.

Der NV3X ist eigentlich so gar kein Freund von Clipplanes was daher kommt das er überhaupt nicht in der Lage ist auf Geometrieebene zu clippen. Auf dieser Ebene kann er nur Cullen.

Und mit den Shadern hat das schon was zu tun. Die pro Vertex Arbeit für die Clipplanes wird von den Vertexshadern mit erledigt.

Edit NV30 durch NV3X ersetzt weil es ja für alle Chips der FX-Rheie gilt.

Ich wette, dass dieses Posting mal wieder im Bashen untergeht.
Scheint ja keiner mehr an wirklich fundierten Meinungen interessiert zu sein, weil man dann ja NV oder ATI nicht mehr bashen könnte.
Wenn ich mir den Thread hiern so ansehe, verliert man echt die Lust.

2003-06-06, 10:52:48

Exxtreme

2003-06-06, 10:54:04

Original geschrieben von seahawk
Um was geht es denn sonst bei dem Artikel von Nagus ?? Um einen AF-Cheat.
Und wo siehst du hier die Legitimation zum äähm, "Optimieren"? Der AF hat mit einer Shader-Reihenfolge AFAIK nichts zu tun.

2003-06-06, 10:54:45

Original geschrieben von Iceman346
Boah, ganze 6 Stück! Und das sind dann gleich 50% für dich? BTW, wenn unter diese Applikationen solche Sachen wie die PowerVR Demos fallen sehe ich das als nicht wichtig an. Wenns Spiele sind ist der Einwand berechtigt.

Ich unterscheide nicht zwischen Spielen und nicht-Spielen, weil's ja auch voelliger Quascth waere.

Es gibt fuer mich nur 3D-Applikationen nach D3D oder OGL API und egal, was eine solche App. fuer einen Zweck hat: sie muss von Treiber fehlerfrei dargestellt werden.

Quasar

2003-06-06, 10:55:27

Original geschrieben von Salvee
Willst du damit die 'Optimiererei' begründen oder legitimieren?

Weder noch. =)
Nur die Reaktionen, die ich hier und anderswo erlebe erklärt es ziemlich gut.

Weder nVidia noch ATi sind die Heilsarmee und quetschen mit allen Mitteln jeden Cent aus den Kunden heraus, wenn sie können.

Exxtreme

2003-06-06, 10:59:34

Original geschrieben von Demirug
Nachdem ich mich jetzt mal informiert habe wie der NV3X Clipplanes verarbeite bin ich zu 99,99% Sicher das es sich nicht um einen Clipplane Cheat handelt.

Wie wird das dann gemacht? So wie es aussieht, wird ein grösserer Teil der 3D-Szene nicht berechnet. Ich habe mir mal die Screenshots angeschaut. Es sieht so ähnlich aus wie wenn man am Ende einer Map wäre. Manchmal gab es in Gothic1 so einen Effekt wenn man aus großer Entfernung durch Türen schaute.

DrumDub

2003-06-06, 11:00:00

und warum haben sich nv und ati nicht zusammengesetzt und gemeinsam den standard für directx 9 gesetzt? da wollte nvidia seine muskeln als marktführer spielen lassen und ist von ati und ms überrumpelt worden...

tja, pech gehabt. und jetzt wird halt mit allen mitteln versucht die sach wieder auszubügeln... bis jetzt sieht es so aus, dass der nv35 diese rolle ganz gut übernommen hat...

ein weiteres beispiel, dafür das nvidia reagieren musste ist die aufgebohrte 5600 ultra...

ich denke nvidia hat sich nach den erfolgen seit der tnt2 einfach zu sicher gefühlt und hat jetzt mit den konsequenzen zu kämpfen eben nicht mehr alleinherrscher (image-mäßig) im 3d-grafikkartenmarkt zu sein...

seahawk

2003-06-06, 11:00:36

Original geschrieben von Exxtreme
Und wo siehst du hier die Legitimation zum äähm, "Optimieren"? Der AF hat mit einer Shader-Reihenfolge AFAIK nichts zu tun.

Da gebe ich Dir Recht. Ich versuche das gar nicht zu legimitieren. Aber sowie ich Demi verstanden habe überläst der NV-Treiber bei Applikation der Anwendung wie der AF arbeitet. Da ja im 3DMark keine sichtbaren Unterschiede auftreten (das Übereinanderlegen von Bildern und irgendwelche Nachbearbeitung sund für micht in der Anwendung nicht sichtbar) ist es ja denkbar, dass der 3DMark der Karte unnötig viel Arbeit aufbrummt. Wenn NF da Optimiert, dann liegt das imo irgendwo zwischen Cheat und Optimierung.

Kann eigentlich mal jemand den selben Test mit UT2003, SS:SE, Quake, NFS6 machen. EXE umbenennen und dann mal mit AF benchen und vergleichen....

Quasar

2003-06-06, 11:00:43

Original geschrieben von Exxtreme
Und wo siehst du hier die Legitimation zum äähm, "Optimieren"? Der AF hat mit einer Shader-Reihenfolge AFAIK nichts zu tun.

Durch die Umbenennung von "mark" in "murks" wird die FX gezwungen, unoptimiertes AF zu verwenden. Dies macht sich natürlich in den Ergebnissen bemerkbar, wie es das schon zu Zeiten der GF4 tat.
Die Pixelunterschiede in den IQ-Shots erklären sich durch die leicht unterschiedlichen Lasten, die der Chip zu verarbeiten hat und die daraus folgend in leicht unterschiedlichen Bildern resultieren.
Dasselbe tritt auf, wenn du ein Differenzbild zwischen zwei verschiedenen Chips erstellen willst.

Quasar

2003-06-06, 11:01:57

Original geschrieben von DrumDub
[...]
ein weiteres beispiel, dafür das nvidia reagieren musste ist die aufgebohrte 5600 ultra...

ich denke nvidia hat sich nach den erfolgen seit der tnt2 einfach zu sicher gefühlt und hat jetzt mit den konsequenzen zu kämpfen eben nicht mehr alleinherrscher (image-mäßig) im 3d-grafikkartenmarkt zu sein...

Full Ack! Ein wahres Wort, gelassen ausgesprochen.

Exxtreme

2003-06-06, 11:05:22

Original geschrieben von Quasar
Durch die Umbenennung von "mark" in "murks" wird die FX gezwungen, unoptimiertes AF zu verwenden.
Genau. Und trotzdem haben sie einen Mechanismus eingebaut, der die Applikation erkennt und die BQ senkt um Geschwindigkeit zu erhöhen... vergleichbar mit Quack. ;)

seahawk

2003-06-06, 11:06:31

Wo ist die Bildqualität gesenkt ??

Quasar

2003-06-06, 11:08:55

Original geschrieben von Exxtreme
Genau. Und trotzdem haben sie einen Mechanismus eingebaut, der die Applikation erkennt und die BQ senkt um Geschwindigkeit zu erhöhen... vergleichbar mit Quack. ;)

Ach so. Optimiertes AF ist also ein Quack-Cheat?

Nagut, dann musst du dir auch die Aussage gefallen lassen, daß ATi hardwaremäßig schon einen Cheat eingebaut hat, der auf Kosten der Bildqualität die Performance erhöht und zwar bei allen Games.

Pfui!
.
.
.
.
.
.
.
.
.
.
. ;)
Deine Argumentation klingt schon etwas merkwürdig manchmal. Wie kommst du darauf, dass die Bildqualität gesenkt wurde? Das Differenzbild beweist, dass es Unterschiede gibt, die beiden Screenshots wurden von Tech-Extreme lediglich als "optisch kaum unterscheidbar" bewertet.
Vielleicht sieht das Bild ja sogar besser aus...

Exxtreme

2003-06-06, 11:12:08

Original geschrieben von seahawk
Wo ist die Bildqualität gesenkt ??
Guckst du hier:
http://www.tech-report.com/etc/2003q2/3dmurk03/index.x?pg=6

Einige Ränder sehen leicht unschärfer aus. :)
Wobei es ehrlich gesagt vernachlässigbar ist.

MadManniMan

2003-06-06, 11:12:21

Original geschrieben von seahawk
Wo ist die Bildqualität gesenkt ??

ich hab mir jetzt hier bis auf die bilder nicht viel angeguckt, aber zumindest hinten am fenster ist der untschied doch deutlich. da sollte gar ein dau erkennen, daß die eine fensterstrebe um ein mip-level beraubt wurde!

Exxtreme

2003-06-06, 11:13:54

Original geschrieben von Quasar
Aussage gefallen lassen, daß ATi hardwaremäßig schon einen Cheat eingebaut hat, der auf Kosten der Bildqualität die Performance erhöht und zwar bei allen Games.

Pfui!

Gebe ich dir recht. :)
Ich sehe sogar MSAA als so eine Art Cheat an. :)
Original geschrieben von Quasar
Deine Argumentation klingt schon etwas merkwürdig manchmal. Wie kommst du darauf, dass die Bildqualität gesenkt wurde? Das Differenzbild beweist, dass es Unterschiede gibt, die beiden Screenshots wurden von Tech-Extreme lediglich als "optisch kaum unterscheidbar" bewertet.
Vielleicht sieht das Bild ja sogar besser aus...
Siehe mein Posting oben. Man kann's grade noch so durchgehen lassen. ;)

2003-06-06, 11:20:40

Original geschrieben von DrumDub
und warum haben sich nv und ati nicht zusammengesetzt und gemeinsam den standard für directx 9 gesetzt? da wollte nvidia seine muskeln als marktführer spielen lassen und ist von ati und ms überrumpelt worden...

hae??

der dx9 Standard ist gemeinsam von MS, ATI und NV entwickelt worden.

nochmals fuer alle:

DX9 schreibt nur vor, WAS ein Chip koennen muss, aber nicht, WIE er das zu tun hat.

Dass sich die CPUs von Intel und AMD unterscheiden duerfte jedem klar sein, ist es denn dann so schwer, das auf Grafikchips zu projizieren??

Salvee

2003-06-06, 11:23:32

Original geschrieben von ow
Hast du's ueberhaupt gelesen?

Dann frage ich dich jetzt mal: wofuer werfen die Firmen FM hunderttausende von Dollars in den Rachen?? Welche Gegenleistung erfolgt dafuer??

Der 3DM03 ist tot, man sollte sich halt nicht von Firmen kaufen lassen, deren System-Performance man evaluieren will.

Ja, habe ich =)

Dennoch bleiben viele Fragen offen:

Der 3DMark03 ist ein synthetisches Testprogramm mit grossem Marketingeinfluss auf Millionen von Usern und Branchen-Giganten wie z.B. Dell.
-Wenn wirklich der Geldfluss von einer Firma zu FM das Benchmarkergebnis beeinflusst, warum gewinnt dann nicht nV?
-Hat ATi eine Bank überfallen, um FM mit mehr Kohle zu bestechen? Wenn ja, welche? :D
-Haben die anderen Beta-Member AMD, ATI, Intel, Microsoft, Creative Technologies, Matrox, S3Graphics, SiS, Ali, Beyond3D, Dell, CNET, ExtremeTech, Gateway, Imagination Technologies/PowerVR, InnoVISION Multimedia, Transmeta, and Trident Microsystems ein Interesse daran, dass nV schlecht abschneidet (die Konkurrenz-Graka-Hersteller stehen nur der Vollständigkeit halber in der Aufzählung ;) )
-Wieviel Geld ist wirklich geflossen?
- Seit wann ist Kyle der Herrgott über Benchmark-Rituale, und warum hat er weiterhin Q3A gebencht?
'I humbly ask that anyone evaluating computer hardware to stop publishing the game demo scores taken from 3DMark03. The media is greatly responsible for giving FutureMark its power in the industry and it is my thought that if we work collectively, we can shift that power to a more responsible set of real world utilities that I suggest will become a reality this year.'
-Wieviel Geld erhalten Spielehersteller für das 'WIMTBP'-Logo, und was sind ihre Gegenleistungen dafür? Lediglich die Werbefläche? Oder darf man Einfluss nehmen z.B. auf die integrierte Benchmarkfunktion?

Spekulationen über Spekulationen...

Ich wollte nur sagen, Kyles Blurb deckt sich immer mit der offiziellen Haltung von nV, unabhängig davon, ob man dieser zustimmen kann oder nicht (zumeist subjektive Entscheidung). Es reicht also der Besuch der nVidia-Homepage, [H] kann man sich danach oftmals sparen.

Quasar

2003-06-06, 11:26:02

Was mir bei genauerer Betrachtung der beiden Shots viel eher auffällt, ist die unterschiedliche Helligkeit in einigen Bereichen, so als ob der VS auch "anders" arbeiten würde.

nggalai

2003-06-06, 11:28:19

Hola,
Original geschrieben von DrumDub
und warum haben sich nv und ati nicht zusammengesetzt und gemeinsam den standard für directx 9 gesetzt? da wollte nvidia seine muskeln als marktführer spielen lassen und ist von ati und ms überrumpelt worden... Das hat ow ja schon erleutert--die Specs für DX9 wurden von allen gemeinsam bestimmt. Aber die Umsetzung und Programmierrichtlinien, da sieht's anders aus. ;) Weshalb die übliche Implementation nicht allen IHV gleich "gut" tut liest man hier (http://www.forum-3dcenter.org/vbulletin/showthread.php?s=&threadid=73365) nach. Die Technologieunterschiede sind doch zu beträchtlich, als dass man da mit "einer Lösung" allen gerecht werden könnte. Ist ja auch nicht mehr lange so.

93,
-Sascha.rb

Exxtreme

2003-06-06, 11:31:41

Original geschrieben von Quasar
Was mir bei genauerer Betrachtung der beiden Shots viel eher auffällt, ist die unterschiedliche Helligkeit in einigen Bereichen, so als ob der VS auch "anders" arbeiten würde.
Jepp, das haste recht. Die Säule im Hintergrund ist anders beleuchtet.

Hmm, mich interessiert jetzt ob es einen Zusammenhang mit dem Beleuchtungsproblem hier:
http://www.ixbt.com/video2/images/r9800pro-2/g2-840-330.gif

gibt. :)

Demirug

2003-06-06, 11:32:40

Original geschrieben von Exxtreme
Wie wird das dann gemacht? So wie es aussieht, wird ein grösserer Teil der 3D-Szene nicht berechnet. Ich habe mir mal die Screenshots angeschaut. Es sieht so ähnlich aus wie wenn man am Ende einer Map wäre. Manchmal gab es in Gothic1 so einen Effekt wenn man aus großer Entfernung durch Türen schaute.

Aufgrund der Screenshots die ich gesehen habe (Ich habe keine Freefly Version zum selberrumpropieren) tippe ich auf "Pre VS Culling"

Bei jedem Drawcall muss der Treiber ja sowieso prüfen was sich seit dem letzten Call alles relevante verändert hat. Erkennt er dabei das umschalten auf die VS/PS für den Skydome (leicht zu prüfen) kommt eine "Spezialrountine" zum Zug. Diese bestimmt dann aufgrund der für den VS benutzten Konstanten (wahrscheinlich eine Tranformationsmatrix) welcher Teil des Skydomes überhaupt zur Anzeige kommt. Diese Information wird dann genutzt den Drawcall so zu beschneiden das wirklich nur noch der sichtbare bereich angezeigt wird.

Anscheined hat man dabei aber nicht berücksichtigt das die Camera auch mal extrem noch oben geschwenkt werden kann (was beim normalen durchlauf ja nicht passiert) und so wird der Ausschnitt falsch bestimmt und man rendert nicht genügend vom Skydome um den gesamten Bildschirm abzudecken.

Ob es jetzt wirklich so gemacht wird kann ich nicht sagen aber ich würde es so machen.

Quasar

2003-06-06, 11:39:53

Original geschrieben von Exxtreme
Jepp, das haste recht. Die Säule im Hintergrund ist anders beleuchtet.

Hmm, mich interessiert jetzt ob es einen Zusammenhang mit dem Beleuchtungsproblem hier:
http://www.ixbt.com/video2/images/r9800pro-2/g2-840-330.gif

gibt. :)

Nicht nur die Säule im Hintergrund. Auch die Tischkanten sind in der "Murks" Version seltsam "prominent", also stärker beleuchtet.
Die Wand dagegen ist dunkler.

Ob die Fensterstreben überhaupt texturiert sind, MMM, vermag ich nicht zu sagen, jedenfalls sehen sie im "murks" schlechter, weil blurry aus.

Exxtreme

2003-06-06, 11:40:36

Demi,

könnte man sowas generell implementieren oder funktioniert das nur applikationsspezifisch?

Quasar

2003-06-06, 11:43:11

Original geschrieben von Demirug
Ob es jetzt wirklich so gemacht wird kann ich nicht sagen aber ich würde es so machen.

Das liesse sich IMO mittels der BETA Version recht leicht nachweisen. Wenn deine Annahme stimmt, müsste bzw. könnte der nicht gerenderte Bereich ja nur ungefähr mit dem im Bench-Modus sichtbaren Himmel korrelieren.
Bei einer Clip-Plane dagegen könnte man das Ganze doch wesentlich genauer festlegen, oder?

DrumDub

2003-06-06, 11:47:13

ow & ngglai

das habe ich auch nicht bestritten. nur warum hat es nvidia nicht geschafft seine architektur im bezug auf den umgang mit dx9 zu optimieren? hats nvidia mit den treibern verbockt oder warens designfehler im nv30? ist die hlsl von dx9 ati-freudnlicher?

Demirug

2003-06-06, 11:53:54

Original geschrieben von Quasar
Das liesse sich IMO mittels der BETA Version recht leicht nachweisen. Wenn deine Annahme stimmt, müsste bzw. könnte der nicht gerenderte Bereich ja nur ungefähr mit dem im Bench-Modus sichtbaren Himmel korrelieren.
Bei einer Clip-Plane dagegen könnte man das Ganze doch wesentlich genauer festlegen, oder?

Mit Clipplanes kann man genau auf einer bestimmten Ebene schneiden. Nur wüsste ich jetzt nicht wie man da Planes einziehen soll die zum einen wirklich was bringen und zum anderen das Fehlerbild erzeugen könnten.

Die Pre-VS-Cull Methode hat den Vorteil das sie die Last von der kompletten 3D-Pipeline nimmt. Ich könnte mir durchaus vorstellen das beim Render des Skydomes die Pixelpipelines leerlaufen weil der VS die ganzen nicht sichtbaren Verticen berechnet aus welchen dann die Dreiecke gebaut werden die dann sofort wieder entsorgt werden.

seahawk

2003-06-06, 11:56:20

Wieso es gibt ja die BETA Version des DX9 SDK die auch einen speziellen Pfad für die NV-Karten anbietet.

Wenn die nicht mehr BETA ist, dann ist das Problem erledigt.

Das ist im allgemeinen das Problem komplexer Systeme, wo nur das Ergebniss definiert wird. Es gibt viele Wege das Ergebniss zu erreichen.

Demirug

2003-06-06, 11:58:31

Original geschrieben von Exxtreme
Demi,

könnte man sowas generell implementieren oder funktioniert das nur applikationsspezifisch?

Können schon ist aber nicht ganz einfach da für eine gernerele Lösung eine Analyse des Vertexbuffers unter Berücksichtigung der benutzten Vertexshader settings gemacht werden müsste. Die die Verbindung Vertexbuffer zu Vertexsettings aber erst zur Laufzeit vorgenommen wird kompliziert das die ganze Sache.

Wenn man das ganze also generell hinbekommt ist man wirklich gut.

Normalerweise sollte es auch schon die Engine vermeiden eine Menge nicht sichtbarer Geometrie zu übergeben.

Demirug

2003-06-06, 12:03:36

Original geschrieben von DrumDub
ow & ngglai

das habe ich auch nicht bestritten. nur warum hat es nvidia nicht geschafft seine architektur im bezug auf den umgang mit dx9 zu optimieren? hats nvidia mit den treibern verbockt oder warens designfehler im nv30? ist die hlsl von dx9 ati-freudnlicher?

Der nv Chip ist schon für die Benutzung mit DX9 optimiert. Nur nicht für die Verwendung von 1.4 und 2.0 Shader.

HLSL ist Chip neutral. Das Problem liegt beim Chip-Compiler der erzeugt wenn man im sagt das man einen 2.0 Shader haben möchte einfach ATI freundlichen Code.

Baut man mit dem Beta Compiler einen 2.A Shader kommt ein NV3x freundlicher Shader raus.

nggalai

2003-06-06, 12:13:00

Hola DrumDub,
Original geschrieben von DrumDub
das habe ich auch nicht bestritten. nur warum hat es nvidia nicht geschafft seine architektur im bezug auf den umgang mit dx9 zu optimieren? hats nvidia mit den treibern verbockt oder warens designfehler im nv30? ist die hlsl von dx9 ati-freudnlicher? Eben--was heisst "Hardware optimieren?" Die Grundlagen des NV3x-Konzeptes reichen deutlich weiter zurück als die ersten verfügbaren DX9-Betas und die Diskussionen über HLSL und DX9-Implementationen. Die gegenwärtige Implementation von DX9 und der verfügbaren HLSL und des -Compilers orientieren sich aber an einem eher "traditionellen" Pipeline-Modell, mit welchem sich NVs Konzept einfach "etwas" beisst.

Man könnte NV höchstens vorwerfen, an den Marktbedürfnissen für die gegenwärtige DX9-Entwicklung vorbeientwickelt zu haben--aber das Konzept ist nicht "schlechter" oder "besser" für DX9 (die Features) geeignet als das von ATI. Der NV3x ist schon auf DX9 (die Features) optimiert. ;) Und Microsoft wird dem in Zukunft auch Rechnung tragen. Dafür hat NV bereits jetzt den ersten Schritt "in die Zukunft" getan. ATI darf da auch mal hin.

93,
-Sascha.rb

DrumDub

2003-06-06, 12:50:15

interessant ist ja in diesem zusammenhang, das der nv3x im workstation-bereich einen erheblichen vorsprung vor dem r3xx hat... hängt das jetzt mit der architektur zusammen oder mit der tatsache, das in dem bereich opengl stärker eingesetzt wird, was den nv-chips generell besser bekommt?

Demirug

2003-06-06, 13:05:20

Original geschrieben von DrumDub
interessant ist ja in diesem zusammenhang, das der nv3x im workstation-bereich einen erheblichen vorsprung vor dem r3xx hat... hängt das jetzt mit der architektur zusammen oder mit der tatsache, das in dem bereich opengl stärker eingesetzt wird, was den nv-chips generell besser bekommt?

Das hat weniger etwas mit der OpenGL und DirectX zu tun sondern mit den Anforderungen an die Karten. Die sind bei Workstation anwendungen ganzlich anders als bei Spielen.

mapel110

2003-06-06, 15:12:07

hm, schön, dass diese links hier im thread versteckt werden. was hat das bitteschön mit bugs zu tun, was nvidia hier mit AF optimierungen für den 3dmark gemacht hat ?!

naja, ich muss ja nicht alles verstehen. :|

gut, dass es wenigsten noch einen anderen thread heute gegeben hat, der diese links hatte, sonst wäre mir das entgangen.

btw wie wärs, wenn wir hier im grakachip forum generell nurnoch zwei threads machen.

"ATI bash0rn" und "nvidia bash0rn"

na wie wärs ?
*grml*

Razor@Work

2003-06-06, 15:22:41

Original geschrieben von mapel110
hm, schön, dass diese links hier im thread versteckt werden. was hat das bitteschön mit bugs zu tun, was nvidia hier mit AF optimierungen für den 3dmark gemacht hat ?!

naja, ich muss ja nicht alles verstehen. :|
Verstehen könntest Du aber schon, dass der Thread nicht verschwunden ist...
Rein vom Thema her, passt die Angelegenheit schon in diesen Thread. Ich selber habe es ja auch 'übersehen', deswegen ja...

So bleibt der 'closed' Thread als Hinweis, dass dies alles hier schon diskutiert wird und gut is', oder ?
:D

Freue mich schon darauf zuhause mal zu schaun', was es mit diesem 'Cheat' tatsächlich auf sich hat. Hoffentlich kommt mir nicht wieder was dazwischen (passiert in letzter Zeit permanent :().

Bis denne

Razor

P.S.: Seltsam finde ich nur den Moderatoren-Only-Plausch im 'closed' Tread... *eg*

Gast

2003-06-06, 15:29:19

Original geschrieben von Demirug
Der nv Chip ist schon für die Benutzung mit DX9 optimiert. Nur nicht für die Verwendung von ... 2.0 Shader.

Hi Demirug;

DER ist gut. Danke.

Demirug

2003-06-06, 15:35:29

Original geschrieben von Gast
Hi Demirug;

DER ist gut. Danke.

Gern geschen wenn ich auch den leisen Verdacht habe das du nicht verstanden hast auf was ich eigentlich hinaus wollte. Ist aber meine Schuld wenn ich mich missverständlich ausdrücke.

... 2.0 Shader. Sondern für 2.0+ bzw. die jetzt neuen 2.A Shader. Und ein anderer Chip wird dann für 2.B ausgelegt sein.

Razor@Work

2003-06-06, 15:52:11

Original geschrieben von Gast
Hi Demirug;

DER ist gut. Danke.
Um es deutlich zu machen...

HLSL also der Source-Code bleibt gleich, der Output des Compilers (C++ -> Assembler) muss aber zwingend auf die jeweilige Zielarchitektur ausgelegt sein (wie auch bei Intel und AMD), um obtimal auf eben dieser zu laufen.

Das hat M$ beim ersten HLSL-Compiler nicht berücksichtigt un nun korrigiert.
War das jetzt verständlich ?
???

Razor

Exxtreme

2003-06-06, 15:56:06

Original geschrieben von Razor@Work

Das hat M$ beim ersten HLSL-Compiler nicht berücksichtigt un nun korrigiert.
War das jetzt verständlich ?
???

Razor
Sie haben gar nichts korrigiert sondern das Problem nach hinten geschoben. :)

Wenn jetzt ein dritter Hersteller mit einer ganz anderen Architektur auf den Markt kommt, dann besteht das Problem weiterhin.

Die einzige Lösung ist den High-Level-Shader-Code den Treiber compilieren zu lassen.

DrumDub

2003-06-06, 16:46:19

Original geschrieben von Exxtreme
Die einzige Lösung ist den High-Level-Shader-Code den Treiber compilieren zu lassen.

jupp... das ist der einzig richtige ansatz. schließlich kennen die ihvs ihre eigene hardware nebst zugehöriger treiber noch am besten...

demi

ist FP32 im nv3x damit eigentlich ein zugeständnis an den workstation-bereich? wenn ich das richtig im kopf habe, ist da höhere genauigkeit zur vermeidung von renderingfehlern das wichtigste in dem marktsegment...

Demirug

2003-06-06, 17:07:30

Original geschrieben von Exxtreme
Sie haben gar nichts korrigiert sondern das Problem nach hinten geschoben. :)

Wenn jetzt ein dritter Hersteller mit einer ganz anderen Architektur auf den Markt kommt, dann besteht das Problem weiterhin.

Dritter Hersteller = 2.B usw.

Die einzige Lösung ist den High-Level-Shader-Code den Treiber compilieren zu lassen.

Ja und nein. Damit entfernt man zwar eine interpretations Ebene aber wie will man dann noch die kompatibilität (featuretechnisch) sichern?

Der Shaderbytecode sichert zu mindestens dieses ab.

Allerdings in einem gebe ich dir recht. Jeder IHV sollte die Möglichkeit erhalten für die unterschiedliche Shaderversionen einen Plugin Compiler mit dem Treiber auszuliefern. Dieser würde dann falls vorhanden automatisch benutzt wenn man zur Laufzeit des Programms den Compiler anwirft. Liefert der Hersteller keinen Compiler mit würde der Standard von MS benutzt.

Omnicron

2003-06-06, 17:11:04

Original geschrieben von MadManniMan
ich hab mir jetzt hier bis auf die bilder nicht viel angeguckt, aber zumindest hinten am fenster ist der untschied doch deutlich. da sollte gar ein dau erkennen, daß die eine fensterstrebe um ein mip-level beraubt wurde!

Aber bei 3D Mark sind die 3 Streben links viel schärfer / höher aufgelöst als bei 3D Murk. Wieso sollte ein besseres Miplevel die Geschwindigkeit steigern, das hätte ich mir eher andersrum gedacht ???

Demirug

2003-06-06, 17:15:03

Original geschrieben von DrumDub
demi

ist FP32 im nv3x damit eigentlich ein zugeständnis an den workstation-bereich? wenn ich das richtig im kopf habe, ist da höhere genauigkeit zur vermeidung von renderingfehlern das wichtigste in dem marktsegment...

Es gibt durchaus technische Anwendungen die eine durchgängie 32 Bit Pipeline erfordern. Aber das geht im Moment eher in Richtung Forschung. Im Workstationbereich übernehmen die Grafikkarten bisher ja primär die Aufgabe der schnellen Voransicht. Das genaue rendern übernimmt dann ja derzeit normalerweise noch die CPU.

Wenn ich mir aber bestimmte Dinge die nV in der letzen Zeit so angestellt hat (z.B. Die Plugins für Maya, oder der kauf von exluna) glaube ich fast man will dort genau diese Arbeiten von der CPU auf die GPU übertragen und wenn man bedenkt welche Unsummen für die Renderfarmen ausgegeben werden ist das sicherlich ein interesanter Markt. Vorallem wenn man die Synergieeffekte die dabei entstehen würden bedenkt.

Razor

2003-06-06, 19:04:52

Original geschrieben von Exxtreme
Sie haben gar nichts korrigiert sondern das Problem nach hinten geschoben. :)
Nö... die beiden einzigen DX9-Chips werden nun beide vom M$-Compiler voll unterstützt.
Original geschrieben von Exxtreme
Wenn jetzt ein dritter Hersteller mit einer ganz anderen Architektur auf den Markt kommt, dann besteht das Problem weiterhin.
Wei Demirug schon sagte... B...C...D...E...
Soviel unterschiedliche Chip-Hersteller gibt es ja nicht.
:D
Original geschrieben von Exxtreme
Die einzige Lösung ist den High-Level-Shader-Code den Treiber compilieren zu lassen.
Klasse Idee Exxtreme... und inwiefern wirkt sich das dann auf die Gesamt-Performance aus ?
Und auf den Arbeitsspeicher... die CPU-Last... den Spieleumfang... was auch immer.

Etwas unausgegoren, oder etwa nicht ?
Hmmm...

Razor

Exxtreme

2003-06-06, 19:09:18

Original geschrieben von Razor

Klasse Idee Exxtreme... und inwiefern wirkt sich das dann auf die Gesamt-Performance aus ?
Und auf den Arbeitsspeicher... die CPU-Last... den Spieleumfang... was auch immer.

Etwas unausgegoren, oder etwa nicht ?
Hmmm...

Razor
Err, ich hoffe, dir ist schon klar, was ein Compiler ist. :D

Deswegen wäre mein Vorschlag eben NICHT unausgegoren sondern würde jeden IHV absolut gleich behandeln.

P.S: Und das, was ich vorgeschlagen habe, wird AFAIR in OpenGL2.0 kommen.

Razor

2003-06-06, 19:19:26

Original geschrieben von Exxtreme
Err, ich hoffe, dir ist schon klar, was ein Compiler ist. :D

Durchaus...
So sollen also alle Shader-Operationen auf Interpreter-Basis arbeiten, bzw. verarbeitet werden ?
???

Razor

Exxtreme

2003-06-06, 19:24:24

Original geschrieben von Razor
Durchaus...
So sollen also alle Shader-Operationen auf Interpreter-Basis arbeiten ?
???

Razor
Compiler != Interpreter. ;)

Ein Intepreter arbeitet den Code Zeile für Zeile ab und übersetzt diese Zeilen während der Ausführung des Programmes -> QBasic. Hier kann man nicht optimieren.

Ich schlage einen Just-In-Time-Compiler vor. Der High-Level-Shader-Code wird vor der Ausführung erstmal in den Low-Level-Shader-Code compiliert. Und hier kann man jetzt optimieren. Der optimierte Shader-Code kann dann an die GraKa geschickt werden und ausgeführt werden.

Razor

2003-06-06, 19:28:42

Original geschrieben von Exxtreme
Ich schlage einen Just-In-Time-Compiler vor. Der High-Level-Shader-Code wird vor der Ausführung erstmal in den Low-Level-Shader-Code compiliert. Und hier kann man jetzt optimieren. Der optimierte Shader-Code kann dann an die GraKa geschickt werden und ausgeführt werden.
Wie schon gesagt, sind mir sowohl Compiler, als auch Interpreter durchaus in ihrer Funktionsweise bekannt.
(zudem ich beides oft genug benutze ;-)

Wie dem auch sei, der Compiler soll also zur Laufzeit des Games die Shader compilieren ?
Alle, die in der Engine benötigt werden, oder jeden einzeln, wenn er benötigt wird ?
Was für eine CPU willst Du als Unterbau eines solchen 'Treibers' empfehlen ?
Und wieviel Arbeitsspeicher ?
???

IMO würde das die CPU-Lastigkeit der Games nur noch weiter erhähen, ohne einen echten Vorteil zu erhalten...

Razor

Exxtreme

2003-06-06, 19:34:05

Original geschrieben von Razor
Wie dem auch sei, der Compiler soll also zur Laufzeit des Games die Shader compilieren ?

Genau. :)
Original geschrieben von Razor
Alle, die in der Engine benötigt werden, oder jeden einzeln, wenn er benötigt wird ?
Was für eine CPU willst Du als Unterbau eines solchen 'Treibers' empfehlen ?
Und wieviel Arbeitsspeicher ?
???

Razor
Also ich habe mir die Shader-Programme mal angeschaut. Ich denke, es wird Bruchteile einer Sekunde dauern, die HL-Shader zu kompilieren. Das ist garantiert nicht mit einem C-Compiler vergleichbar.

Demirug

2003-06-06, 19:34:53

Original geschrieben von Razor
Wie schon gesagt, sind mir sowohl Compiler, als auch Interpreter durchaus in ihrer Funktionsweise bekannt.
(zudem ich beides oft genug benutze ;-)

Wie dem auch sei, der Compiler soll also zur Laufzeit des Games die Shader compilieren ?
Alle, die in der Engine benötigt werden, oder jeden einzeln, wenn er benötigt wird ?
Was für eine CPU willst Du als Unterbau eines solchen 'Treibers' empfehlen ?
Und wieviel Arbeitsspeicher ?
???

IMO würde das die CPU-Lastigkeit der Games nur noch weiter erhähen, ohne einen echten Vorteil zu erhalten...

Razor

Razor, das sind nur Shader keine Programme mit tausenden Zeilen von Code.

Die jagt man einmal beim Erzeugen durch den Compiler und gut ist. Ich persönlich bevorzuge zwar die Precompiled Methode aber das Jiten wäre auch noch OK.

Demirug

2003-06-06, 19:37:32

Original geschrieben von Exxtreme
Also ich habe mir die Shader-Programme mal angeschaut. Ich denke, es wird Bruchteile einer Sekunde dauern, die HL-Shader zu kompilieren. Das ist garantiert nicht mit einem C-Compiler vergleichbar.

Etwas aufwendiger als ein C-Compiler sind die Shader compiler schon aber dafür ist ja auch die Programmgrösse viel kleiner.

Aber das mit den Sekundenbruchteilen pro Shader kommt in etwa hin.

Gast

2003-06-08, 13:23:20

Original geschrieben von seahawk
Wo ist die Bildqualität gesenkt ??

JA

Kennt ihr eigentlich schon folgende Screenshots :

http://www.beyond3d.com/misc/3dmrendering/3dmurk.zip

Dave Baumann von Beyond3D hat einmal die AF-Level zwischen 3DMark und 3DMurk miteinander verglichen. Also wenn Nvidia hier nicht cheated fresse ich einen Besen (oder so sagt man doch :) ).

Anscheinend wird beim 3DMark nur jeder 2. MipMap-Level auch wirklich mit AF gerendert und die dazwischenliegenden MipMaplevel gar nicht. Ich denke in einem Spiel könnte sowas auch funktionieren (und wäre nur schwer zu entdecken, oder?).

Sorry, aber ich habs einfach mal in beiden Threads geposted.

Aquaschaf

2003-06-08, 15:21:20

2 mal das selbe posting in 2 threads von dir .

edit : ups du schreibst es ja selber drunter

Leonidas

2003-06-08, 16:09:49

Original geschrieben von Exxtreme
Guckst du hier:
http://www.tech-report.com/etc/2003q2/3dmurk03/index.x?pg=6

Einige Ränder sehen leicht unschärfer aus. :)
Wobei es ehrlich gesagt vernachlässigbar ist.

Ja gut, aber der Effekt tritt doch nur unter AF auf! Ergo müßen Unterschiede in der Filterqualität zu sehen sein und nicht diese möglicherweise nur durch den Screenshot selber verursachen Kantenfehler. Oder?

Ok, ich hab das im Fenster jetzt auch gesehen. Nur: Ist das wirklich so dramatisch gegenüber Quake3.exe? Dessen Cheats hat selbst ein Blinder sofort sehen können, kein Vergleich zu 3DMurk.exe:
http://www.3dcenter.org/artikel/2001/10-24_a.php

Mr. Lolman

2003-06-08, 16:21:57

Original geschrieben von Leonidas
Ja gut, aber der Effekt tritt doch nur unter AF auf! Ergo müßen Unterschiede in der Filterqualität zu sehen sein und nicht diese möglicherweise nur durch den Screenshot selber verursachen Kantenfehler. Oder?

Ok, ich hab das im Fenster jetzt auch gesehen. Nur: Ist das wirklich so dramatisch gegenüber Quake3.exe? Dessen Cheats hat selbst ein Blinder sofort sehen können, kein Vergleich zu 3DMurk.exe:
http://www.3dcenter.org/artikel/2001/10-24_a.php

Na und, Cheats macht man ja nicht, damit man sie sofort entdeckt. Ausserdem war der nächste Treiber von ATi genauso schnell, und 'cheatete' nicht.

Xmas

2003-06-08, 16:54:16

Original geschrieben von Leonidas
Ja gut, aber der Effekt tritt doch nur unter AF auf! Ergo müßen Unterschiede in der Filterqualität zu sehen sein und nicht diese möglicherweise nur durch den Screenshot selber verursachen Kantenfehler. Oder?

Ok, ich hab das im Fenster jetzt auch gesehen. Nur: Ist das wirklich so dramatisch gegenüber Quake3.exe? Dessen Cheats hat selbst ein Blinder sofort sehen können, kein Vergleich zu 3DMurk.exe:
http://www.3dcenter.org/artikel/2001/10-24_a.php
Irgendwie ist das ganze nicht so recht nachzuvollziehen. Es tritt nur bei AF auf, und dann ist die Beleuchtung anders und es treten Kantenfehler auf?
Zudem sieht das Fenster im "3DMark" Shot sogar besser aus.

Omnicron

2003-06-08, 17:22:01

Also der Effekt tritt anscheined nur auf FXen auf, oder ?
Hab das gerade mal mit meiner Ti4200 (Deto 44.03, 3DMark mit Patch), nachgestellt, und da ist kein Unterschied zu sehen.
Könnten Leute die eine FX haben das nicht auch noch mal verifizieren ?

LovesuckZ

2003-06-08, 17:24:52

Original geschrieben von Omnicron
Also der Effekt tritt anscheined nur auf FXen auf, oder ?
Hab das gerade mal mit meiner Ti4200 (Deto 44.03, 3DMark mit Patch), nachgestellt, und da ist kein Unterschied zu sehen.
Könnten Leute die eine FX haben das nicht auch noch mal verifizieren ?

ja, tritt nur mit der FX auf.
Komisch ist auch, wenn ich 8AF mit "Murks" einstelle, bekomme ich 10% mehr Punkte als wenn ich 8AF per Treiber einstelle...

Leonidas

2003-06-08, 17:36:37

Original geschrieben von Leonidas
Ja gut, aber der Effekt tritt doch nur unter AF auf! Ergo müßen Unterschiede in der Filterqualität zu sehen sein und nicht diese möglicherweise nur durch den Screenshot selber verursachen Kantenfehler. Oder?

Ok, ich hab das im Fenster jetzt auch gesehen. Nur: Ist das wirklich so dramatisch gegenüber Quake3.exe? Dessen Cheats hat selbst ein Blinder sofort sehen können, kein Vergleich zu 3DMurk.exe:
http://www.3dcenter.org/artikel/2001/10-24_a.php

Update: Die Screenies von Beyond3D zeigen die Unterschiede wirklich:
http://www.beyond3d.com/misc/3dmrendering/3dmurk.zip

Exxtreme

2003-06-08, 17:48:57

Original geschrieben von Leonidas

Ok, ich hab das im Fenster jetzt auch gesehen. Nur: Ist das wirklich so dramatisch gegenüber Quake3.exe? Dessen Cheats hat selbst ein Blinder sofort sehen können, kein Vergleich zu 3DMurk.exe:
http://www.3dcenter.org/artikel/2001/10-24_a.php
Also so dramatisch wie Quack ist das bei Weitem nicht. Deswegen schrieb ich, daß es eigentlich vernachlässigbar ist... zumindest in diesem Test.

Andererseits ist die Szene ziemlich dunkel. Man sieht hier die Unterschiede nicht so gut wie auf den Screenshots von B3D.

P.S. Beim Quack wundert es mich wirklich, warum es erst Wochen später aufgefallen ist. Schauten die meisten Reviewer nicht auf das, was sie benchten? :|

Quasar

2003-06-08, 18:47:55

Original geschrieben von Exxtreme
P.S. Beim Quack wundert es mich wirklich, warum es erst Wochen später aufgefallen ist. Schauten die meisten Reviewer nicht auf das, was sie benchten? :|

Dank so praktischer und offenbar gern genutzter Tools wie dem Q3-Demoplayer (den es, Gott bewahre, bald auch in russisch und für eine Heerschar an Spielen geben soll), kann man ja 'ne Menge Zeit sparen. Aber man sieht leider wirklich nicht mehr, was man bencht.

Da der Q3-Demoplayer bei mir wohl aufgrund eines Anwenderfehlers immer recht andere Resultate als ein manueller Ablauf ausgespuckt hat, habe ich das Teil nie benutzt.

Und auch so: Bei 300fps+ sieht man nicht mehr wirklich viel von den dargestellten Szenen...

Gast

2003-06-08, 21:17:39

Original geschrieben von Leonidas
Update: Die Screenies von Beyond3D zeigen die Unterschiede wirklich:
http://www.beyond3d.com/misc/3dmrendering/3dmurk.zip

Hmm..

Deshalb habe ich den Link auch gepostet.

Was mich an dem ganzen aber wesentlich stärker interessiert ist, das man den Cheat mit dem AF-Tester unter 3DMark03 sofort sieht, im "Spiel" bzw. Benchmark aber (fast) nicht; und das obwohl 3DMark03 auf den meisten Rechner ziemlich langsam läuft.

Deshalb meine Frage : Würde man den Cheat in einem echten Spiel sehen, oder nicht?

Kann so ein Cheat die wesentlich bessere AF-Performance der NV3x-Karten mit den neuesten Treibern erklären?

Und wenn ja, wie kann man das überprüfen? Schließlich haben die Spiele keine Möglichkeit, ein bestimmtes Frame herauszupicken und einen genauen Vergleich zwischen den Treibern zu machen, oder?

Omnicron

2003-06-08, 22:31:49

Original geschrieben von Gast
Deshalb meine Frage : Würde man den Cheat in einem echten Spiel sehen, oder nicht?

Wenn man den Cheat in einem Spiel nicht sehen kann, würde ich es eine Optimierung nennen, und nicht Cheat.

Demirug

2003-06-08, 22:33:35

So ich habe mir jetzt eine halbe ewigkeit die Screenshots bei 400% angeschaut und bin jetzt total verwirt. ?-)

Von oben nach unten betrachtet:

Rot grün = Matsch sieht aus wie 1x AF
Blau Orange = OK 8xAF
Pink Geld = Matsch sieht aus wie 1x AF
Schwarz Weiss = OK 8xAF

und dann wiederholt sich das ganze wieder.

Ich habe mir Vergleichshots besorgt die tiefer (120) im Tunnel gemacht wurden. Der Effekt wandert mit den Farben mit ist also nicht von dem Z Wert abhängig.

Was zur Hölle treibt nVidia da? Sind das Intellisample Experimente?

nggalai

2003-06-08, 22:40:16

Hola,
Original geschrieben von Gast
Deshalb meine Frage : Würde man den Cheat in einem echten Spiel sehen, oder nicht?

Kann so ein Cheat die wesentlich bessere AF-Performance der NV3x-Karten mit den neuesten Treibern erklären?Die Frage ist, in wiefern das als "echter Cheat" durchgeht. Nach Futuremarks PDF-Definition ist's einer, weil NV im Treiber applikationsabhängig die Workload verändert zu haben scheint. In der Realität jedoch liegt's eh beim Entwickler/Designer, die Wahl zu treffen, welche Texturen einer Szene wie gefiltert werden sollen. z.B. müssen in Spielen Lightmaps nicht unbedingt anisotrop gefiltert werden, daher wird das in besseren Spielen auch gar nicht erst versucht, wenn man AF in der Applikation einstellt.

Deshalb heisst die Einstellung im Treiber-Panel auch "Application" (oder hiess mal so): das, was die Applikation gerne an AF hätte soll verwendet werden. Wenn ich im Treiber jetzt 8°AF einstelle, werden ALLE Texturen mit dieser Stufe gefiltert--auch die, welche der Programmierer wohl gar nicht gefiltert haben wollte (sofern er sich überhaupt die Mühe nahm, darauf zu achten). Sehr ineffizient, aber nicht jedes Spiel hat AF-Regler drin. Also könnte doch sein . . .

. . . dass NV da etwas entgegen kommt. ;) NV tweakt ihre Treiber ja eh schon auf Applikationen und Benchmarks, ist also naheliegend, dass sie da etwas sinnvollere (oder einfach nur schnellere) Einstellungen im Treiber vorgeben, applikationsabhängig. So kann man im Treiber immernoch 8°AF einstellen, das ist dann noch immer wie's sein soll der "maximale Grad", aber es werden nur die Texturen gefiltert, die das überhaupt nötig haben. Auch wenn da NV entscheidet, in Benchmarks also eher abzulehnen.

Haben die Leute bei Tech-Report und B3D AF im 3DMark oder im Treiber geändert?

Edit: Demiurg--in wiefern macht AF bei Bumpmaps Sinn? Ich kann mich noch düster an eine Diskussion in der DX-Mailinglist erinnern, wo gegen MIP-Mapping bei Bumpmaps gewettert wurde, aber zu AF hab' ich nichts mehr präsent. Wäre es möglich, dass Futuremark da auch die Bumpmaps und Specular Maps filtert, obwohl das technisch keinen Sinn macht? ???

93,
-Sascha.rb

Demirug

2003-06-08, 23:08:10

Original geschrieben von nggalai
Hola,
Die Frage ist, in wiefern das als "echter Cheat" durchgeht. Nach Futuremarks PDF-Definition ist's einer, weil NV im Treiber applikationsabhängig die Workload verändert zu haben scheint. In der Realität jedoch liegt's eh beim Programmierer, die Wahl zu treffen, welche Texturen einer Szene wie gefiltert werden sollen. z.B. müssen in Spielen Lightmaps nicht unbedingt anisotrop gefiltert werden, daher wird das in besseren Spielen auch gar nicht erst versucht, wenn man AF in der Applikation einstellt.

Nicht beim Programmierer sondern beim Designer. Der Programmier hat ja keine Kentniss über die später benutzten Texturen. Der Programmierer muss allerdings die möglichkeit zur Verfügung stellen den Filter pro Texture einstellbar zu machen. Das dumme ist nur das die meisten Engines beim AF wenn sie es überhaupt direkt unterstüzen oft einfach einen rundumschlag betrieben und einfach auf alles auf den gleiche filter ansetzen.

Edit: Demiurg--in wiefern macht AF bei Bumpmaps Sinn? Ich kann mich noch düster an eine Diskussion in der DX-Mailinglist erinnern, wo gegen MIP-Mapping bei Bumpmaps gewettert wurde, aber zu AF hab' ich nichts mehr präsent. Wäre es möglich, dass Futuremark da auch die Bumpmaps und Specular Maps filtert, obwohl das technisch keinen Sinn macht? ???

93,
-Sascha.rb

Zu dem Bumpmaps gibt es da keine genrelle Empfehlung. In der Regel kommt man aber ohne Erkennbare Qualitäteinbusen mit weniger AF als bei den Diffusemaps (die eigentliche Oberflächen farbe) aus.

Was Futermark da genau macht weiss ich nicht. Möglich wäre es aber das man alles maximal filtern lässt.

nggalai

2003-06-08, 23:15:03

Hola Demiurg,
Original geschrieben von Demirug
Nicht beim Programmierer sondern beim Designer. Der Programmier hat ja keine Kentniss über die später benutzten Texturen. Der Programmierer muss allerdings die möglichkeit zur Verfügung stellen den Filter pro Texture einstellbar zu machen.LOL War'st schneller als ich mit Editieren. Immer diese Videochats im Hintergrund. ;)

Danke für die Info!

Könnte also tatsächlich eine Intellisample-Spielerei sein. Eventuell macht NV da gleich Rundumschlag, so nachm Motto "Neee, Bumpmaps brauchen sowas nicht *ausschalt". Wobei, das würde die lustigen B3D-Screenshots noch nicht erklären. Die sehen echt eigenartig aus. Eventuell ein Bug?

93,
-Sascha.rb

Exxtreme

2003-06-08, 23:18:43

Original geschrieben von nggalai
Wobei, das würde die lustigen B3D-Screenshots noch nicht erklären. Die sehen echt eigenartig aus. Eventuell ein Bug?

93,
-Sascha.rb
Also an so einen "Bug" glaube ich nicht. Dieses Phänomen lässt sich nämlich deaktivieren wenn man die Exe umbenennt.

Demirug

2003-06-08, 23:24:06

Original geschrieben von nggalai
Hola Demiurg,
LOL War'st schneller als ich mit Editieren. Immer diese Videochats im Hintergrund. ;)

Danke für die Info!

Könnte also tatsächlich eine Intellisample-Spielerei sein. Eventuell macht NV da gleich Rundumschlag, so nachm Motto "Neee, Bumpmaps brauchen sowas nicht *ausschalt". Wobei, das würde die lustigen B3D-Screenshots noch nicht erklären. Die sehen echt eigenartig aus. Eventuell ein Bug?

93,
-Sascha.rb

Laut einer Analyse von digitlife spielt nvidia ja wirklich mit einer Textureanalyse rum. Bei OpenGL konnte man das dort auch nachweisen. Dort ging man aber davon aus das diese Analyse und Anpassung immer für die gesamte Texture gilt.

Die Screenshots von B3D lassen nun die Vermutung aufkommen das die Filteranpassung bei den NV3X Chips auch nur für Teile (Sektoren) der Texturen möglich sind. nVidia muss ja nun irgendwie berechnen welcher Filter wohl der richtige für einen Sektor ist und dabei läuft wohl was falsch wenn bestimmte Farbmuster auftretten.

Demirug

2003-06-08, 23:28:59

Original geschrieben von Exxtreme
Also an so einen "Bug" glaube ich nicht. Dieses Phänomen lässt sich nämlich deaktivieren wenn man die Exe umbenennt.

Wenn meine Intellisample vermutung richtig ist besteht ja durchaus die möglichkeit das man das ganze noch grundsätzlich deaktiviert hat. Es aber bei einzelnen Applikationen aktiviert hat bei denen man sich sicher war das es richtig funktioniert weil man der Sache noch nicht so ganz traut.

PS: Ich habe aus versehen auf ändern geklickt deswegen steht oben das ich was geändert hätte was ich aber nicht habe.

nggalai

2003-06-08, 23:37:23

Update:

mitm 44.61er scheinen die Probleme / Bildunterschiede weg zu sein:

http://www.beyond3d.com/forum/viewtopic.php?t=6311

Und der 320er-Speed ist auch wieder da, ohne Bildfehler. Entsprechend geht im Thread die Post ab. ;)

93,
-Sascha.rb

LovesuckZ

2003-06-08, 23:42:36

Original geschrieben von nggalai
Update:
mitm 44.61er scheinen die Probleme / Bildunterschiede weg zu sein:

Hm, hat wer enge Kontakte zu nvidia? :D

Exxtreme

2003-06-08, 23:43:14

Original geschrieben von nggalai
Update:

mitm 44.61er scheinen die Probleme / Bildunterschiede weg zu sein:

http://www.beyond3d.com/forum/viewtopic.php?t=6311

Und der 320er-Speed ist auch wieder da, ohne Bildfehler. Entsprechend geht im Thread die Post ab. ;)

93,
-Sascha.rb
Haha, wohl den SMDM* verbessert. :lol:
;)

*Special Murks Detection Mechanism.

nggalai

2003-06-08, 23:50:21

Hola,
Original geschrieben von Exxtreme
Haha, wohl den SMDM* verbessert. :lol:
;)

*Special Murks Detection Mechanism. ROFL ;D

Warscheinlich nicht--die Unterschiede sowie der Speed-up sind beide weg. i.e. der Treiber ist bei 8°AF gleich langsam wie mitm 44.03er im MM (Murks Mode(tm)).

Und LovesuckZ -- jup, Ante P. Daher auch der Link. ;)

93,
-Sascha.rb

LovesuckZ

2003-06-08, 23:53:26

Original geschrieben von nggalai
Und LovesuckZ -- jup, Ante P. Daher auch der Link. ;)

They've asked me not to share any drivers or demos though (beta versions that is).

Naja, sie/er wird wohl den treiber nicht ins netz stellen... :D
Hoffentlich dauerst net so lange, bis man ihn bekommt.

Demirug

2003-06-08, 23:58:11

Original geschrieben von LovesuckZ
They've asked me not to share any drivers or demos though (beta versions that is).

Naja, sie wird wohl den treiber nicht ins netz stellen... :D
Hoffentlich dauerst net so lange, bis man ihn bekommt.

Irgendjemand wir in schon leaken lassen aber es könnte sein das Ante P. noch einen auf den Deckel bekommt wenn der Devsupport heraus bekommt wer er wirklich ist. Die sehen das normalerweise nicht gerne wenn man über Beta-Treiber in öffentlichen Foren redet. Wobei Ante P in diesem Fall ja möglicherweise ja sogar dazu beauftragt wurde.

Razor

2003-06-09, 11:27:43

Original geschrieben von Demirug
Irgendjemand wir in schon leaken lassen aber es könnte sein das Ante P. noch einen auf den Deckel bekommt wenn der Devsupport heraus bekommt wer er wirklich ist. Die sehen das normalerweise nicht gerne wenn man über Beta-Treiber in öffentlichen Foren redet. Wobei Ante P in diesem Fall ja möglicherweise ja sogar dazu beauftragt wurde.
Wäre zu vermuten...
Schließlich musste nVidia ja nun auf die eine oder andere Weise auf den herben Verlust an Schnulerpunkten reagieren.

Erst einmal sorgt man dafür, dass das, was sie taten, nicht als Cheat angesehen wird (FM-Klarstellung) und im nächsten Schritt zeigen sie, dass zumindest das mit den Clipplanes wohl nicht beabsichtigt war (was Du ja schon vermutetest ;-).

Ob sie jetzt weiterhin eine Murks-Optimierung betreiben wird festzustellen sein... man sollte allerdings erwähnen, dass nVidia nicht sagte, dass sie solche Optimierungen zukünftig unterlassen werden...Patric Ojala hat sich dazu ja schon geäussert:
We don't have the 44.61 drivers, so I haven't got a chance to check if the drivers actually get more out of the hardware, or if it's just the same old optimizations with added benchmark detection functionality.

Until we can check these new drivers (which might be a lot of work), we recommend using the 330 build of 3DMark03 and the 44.03 or 43.51 drivers for benchmarking GFFX hardware. With this combination of 3DMark/drivers the default benchmark run should produce comparable results.
Insbesondere der von mir hervorgehobene Teil bekommt von mir ein Mega-LOL !
:lol:

Razor

Gast

2003-06-10, 06:23:40

Original geschrieben von Leonidas
Nur: Ist das wirklich so dramatisch gegenüber Quake3.exe? Dessen Cheats hat selbst ein Blinder sofort sehen können, kein Vergleich zu 3DMurk.exe:
http://www.3dcenter.org/artikel/2001/10-24_a.php

Ist es mal gut? Wie lange wollt ihr die alten Kamellen noch rauskramen? Hört mal auf, vom eigentlichen Thema ablenken zu wollen. Es geht hier um nVidia und nicht um eine alte ATi-Klamotte!

Gruß

Jörg

Demirug

2003-06-10, 11:45:06

Original geschrieben von Razor
Wäre zu vermuten...
Schließlich musste nVidia ja nun auf die eine oder andere Weise auf den herben Verlust an Schnulerpunkten reagieren.

Erst einmal sorgt man dafür, dass das, was sie taten, nicht als Cheat angesehen wird (FM-Klarstellung) und im nächsten Schritt zeigen sie, dass zumindest das mit den Clipplanes wohl nicht beabsichtigt war (was Du ja schon vermutetest ;-).

Es war nicht beabsichtigt das man es erkennt und wie gesagt ich glaube nicht wirklich an Clipplanes.

Ob sie jetzt weiterhin eine Murks-Optimierung betreiben wird festzustellen sein... man sollte allerdings erwähnen, dass nVidia nicht sagte, dass sie solche Optimierungen zukünftig unterlassen werden...

Die werden nicht aufhören zu "optimieren" so lange sie sich benachteiligt fühlen (Also niemals :D ). Mit der Zeit werden möglicherweise Murks spezifische optimierungen durch allgemeine ersetzt aber das steht noch in den Sternen. Vorallem da wir immer noch nicht bei dem ominösen Det50 angekommen sind.

Von Patric Ojala gibt es übrigens was neues:

think our Online Result Browser (ORB) already shows only 3DMark03 build 330 results by default, when you do search operations and such. If some new drivers appear that do questionable things also on build 330, we'll consider implementing futher restrictions in our ORB.

Ich würde mal sagen: "Ring frei zur nächsten runde".

Carlo28

2003-06-10, 16:33:10

Der neue Detonator 44.61 ist geleakt auf www.warp2search.net :)

LovesuckZ

2003-06-10, 16:51:32

Du bist nen Schatz! :D

Razor

2003-06-10, 20:11:41

Original geschrieben von LovesuckZ
Du bist nen Schatz! :D
Nix für unsereiner, Love...
:D

Razor

Razor

2003-06-10, 20:16:50

Original geschrieben von Demirug
Es war nicht beabsichtigt das man es erkennt und wie gesagt ich glaube nicht wirklich an Clipplanes.
Nun ja, bisher wurde doch immer behauptet, dass genau dies diesen 'Performance-Boost' bei der nVidia-'Optimierung' gebracht haben soll. So wie es jetzt ausschaut, hast Du recht, nur zeigt der neue Treiber ja wohl offensichtlich die gleiche Performance, ohne die bisherigen Symptome...

Schaun' wir mal, was daraus wird !
:D
Original geschrieben von Demirug
Die werden nicht aufhören zu "optimieren" so lange sie sich benachteiligt fühlen (Also niemals :D ). Mit der Zeit werden möglicherweise Murks spezifische optimierungen durch allgemeine ersetzt aber das steht noch in den Sternen. Vorallem da wir immer noch nicht bei dem ominösen Det50 angekommen sind.
Vermutlich wird nVidia erst dann damit aufhören, wenn FM einen 'Patch' bringt, der die Ungleichbehandlung aufhebt, oder aber ein neuer Murks heruas kommt, bei dem ebenfalls alle Karten 'gleich' gut oder schlecht unterstützt werden...
Original geschrieben von Demirug
Von Patric Ojala gibt es übrigens was neues:

Ich würde mal sagen: "Ring frei zur nächsten runde".
Der ORB können sich die Leutz getrost in die Haare schmieren...

Und was wollen die machen ?
Wenn ein neuer Treiber heraus kommt, der eine bessere Performance zeigt erst einmal gar nicht zulassen ?
Auch bei ATI ?
:D

Wir dürfen gespannt sein... *eg*

Razor

seahawk

2003-06-11, 08:44:40

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

Gibt es einen Link für mehr Informationen zu CG

Razor

2003-06-11, 09:15:37

Original geschrieben von seahawk
http://www.cs.utexas.edu/users/billmark/pubs/cgpaper.pdf

Ist ganz intressant was NV da über CG erzählt.
Kannst Du mal ein bissel genauer werden oder war des jetzt einfach OT ?
12 Seiten lesen, nur um heraus zu finden, was seahawk eigentlich will ?
Neee....
:D

Razor

seahawk

2003-06-11, 10:12:16

Ist nicht direkt on topic, ist aber interessant den Zusammenhang zwischen Shadersprache, Compiler und Hardware zu verstehen.

Demirug

2003-06-11, 10:22:32

Original geschrieben von seahawk
Ist nicht direkt on topic, ist aber interessant den Zusammenhang zwischen Shadersprache, Compiler und Hardware zu verstehen.

Tipp für sowas: Thread im Technologieforum aufmachen und hier dann einen Verweiss darauf plazieren.

seahawk

2003-06-11, 10:35:35

Tipp befolgt @ Danke Demi

nagus

2003-06-12, 08:32:30

quelle anandtech:
“Now, the (GeForce) FX 5900 (Ultra) is able to outpace the Radeon 9800 PRO in all relevant benchmarks and can reclaim the performance throne for NVIDIA,” said Lars Weinand, graphics card editor for Tom’s Hardware (www.tomshardware.com). “The card offers unrivaled FSAA (full scene antialiasing) speed combined with very good anisotropic filtering image quality and performance, thanks to the new Detonator FX driver, giving it a comfortable lead over its rival.”
"

soooo geil ... ich lach mich tot! :lolaway::lolaway::lolaway:

1. Now, the (GeForce) FX 5900 (Ultra) is able to outpace the Radeon 9800 PRO in all relevant benchmarks

>> thanks to drivercheating... hat er vergessen

2. The card offers unrivaled FSAA (full scene antialiasing) speed combined

>> shitty FSAA bildqualität hat er natürlich nicht erwähnt

3. thanks to the new Detonator FX driver, giving it a comfortable lead over its rival.”

>> und nochmal drivercheating...

marketing blah, blah kann so amüsant sein

Tarkin

2003-06-12, 08:32:53

hat das schon jemand geposted?

http://www.beyond3d.com/forum/viewtopic.php?t=6377

interessant ist auch folgendes:

"Actually it was posted on ixbt forum:
http://forum.ixbt.com/0010/044212-30.html

- Detonators have 73-element table of "recognized" applications
- ~50 "recognized" shaders
He simply wrote rivatuner-patch hich will "block" detection routines in the driver.
IMHO just a matter of time to see how 8500 fps in GT4 jumped ahead..."

:kratz2:

seahawk

2003-06-12, 09:15:36

Absolut, wenn der NV-Treiber 73 applicationen detected, dann ist wahrscheinlich kein Benchmark real.

In jeden Falle müßten all Reviews der FX5900 gegen die gesamte ATI Karten geändert werden und die ATI Karten zum deutlichen Sieger erklärt werden.

PS : Würde mich nicht wundern, wenn die 9700pro ohne Cheats schneller ist als ne 5900U.

Macht der ATI Treiber eigentlich auch so etwas ??

Tarkin

2003-06-12, 09:34:51

Original geschrieben von seahawk
Absolut, wenn der NV-Treiber 73 applicationen detected, dann ist wahrscheinlich kein Benchmark real.

In jeden Falle müßten all Reviews der FX5900 gegen die gesamte ATI Karten geändert werden und die ATI Karten zum deutlichen Sieger erklärt werden.

PS : Würde mich nicht wundern, wenn die 9700pro ohne Cheats schneller ist als ne 5900U.

Macht der ATI Treiber eigentlich auch so etwas ??

Naja, 9700er PRO schneller als 5900er ULTRA ... kann sein. Was ich auf jedenfall für realistisch halte ist, dass eine 8500er schneller als eine gleichgetaktete Geforce4 ist.

Zweiteres kann ich mir nicht vorstellen. Falls doch, dann in einem wesentlich geringeren Umfang. (nVidias Det. Treiber benötigen satte 20 MB ... ich kann mir gut vostellen warum :psst: )

IMO ist es nur noch eine Frage der Zeit, bis alle Cheats offengelegt werden.

nggalai

2003-06-12, 09:34:55

Original geschrieben von seahawk
Absolut, wenn der NV-Treiber 73 applicationen detected, dann ist wahrscheinlich kein Benchmark real. Oder es handelt sich um applikationsspezifische Bugfixes. Das machen Kyro-II und Radeon auch so--wenn für ein Spiel, damit's sauber läuft, im Treiber was gehackt werden muss, wird halt gehackt und eine Abfrage eingebaut. Von daher gesehen ist 73 ein recht kleiner Wert, ausser man behauptet, dass die Qualität der NV-Treiber so gut ist, dass solche Bugfixes unnötig und das ALLES Cheats sind. ;)

93,
-Sascha.rb

nagus

2003-06-12, 09:35:57

Winter[Raven]

2003-06-12, 09:36:08

Macht der ATI Treiber eigentlich auch so etwas ??

Natürlich, die hatten nur das Glück noch nicht aufzufliegen ... !

nggalai

2003-06-12, 09:38:01

Original geschrieben von Tarkin (nVidias Det. Treiber benötigen satte 20 MB ... ich kann mir gut vostellen warum :psst: )Die Detonator-Treiber benötigen zwischen 6 und 8MB. Die grossen, 18MB-Pakete sind die "internationalen" Versionen mit vollem Support für 29 Sprachen.

Wie gross war der Catalyst3.4 nochmal? Und der Parhelia-Treiber?

93,
-Sascha.rb

seahawk

2003-06-12, 09:46:16

Eine Reduzierung der Bildqualität ist ja bisher nur beim 3DMark festgestellt worden. Momentan sind es nur nicht sichtbare Optimierungen.

Kann mal einer UT2003 testen ??

(Ngglai : Ist natürlich denkbar - hatte ich nicht bedacht)

PS. Wäre wirklich intressant zu wissen, ob der ATI Treiber auch Applicationen detected.

Demirug

2003-06-12, 10:15:52

mhm Dragothic? Ich hatte da schon einen leisen Verdacht.

Da haben die Jungs wohl vergessen mit allen möglichen Memorylayouts zu testen. :D

seahawk

2003-06-12, 10:18:39

Original geschrieben von Demirug
mhm Dragothic? Ich hatte da schon einen leisen Verdacht.

Da haben die Jungs wohl vergessen mit allen möglichen Memorylayouts zu testen. :D

Kannst Du mehr sagen ??

Demirug

2003-06-12, 10:49:49

Original geschrieben von seahawk
Kannst Du mehr sagen ??

Können schon aber ob es stimmt weiss ich ja sowieso nicht. Die beobachteten Phenomäne in Verbindung mit Dragothic deuten ja darauf hin das der Chip nicht immer die richtigen Vertexdaten bekommt. Ich müsste allerdings noch ausprobieren ob dieses Dinge mit dem neuen script auch behoben sind. Falls ja hat man für Dragothic wohl eine Memorylayout optimierung vorgenommen. Dabei werden dann einfach die Daten (Vertex Texture framebuffer) auf eine andere Art als üblich im Speicher angeordnet um eine bessere Ausnutzung der Bandbreite zu erreichen. Da das Layout aber dabei relative fest hinterlegt wird kann es natürlich bei Karten die etwas anders als üblich sind (5200 mit 64 Bit ;) ) schon zu Problemen kommen. Diese Art der Optimierung ist schon uralt und dürfte inzwischen von wohl jedem IHV angewendet worden sein. Von 3DLabs weiss ich es zum Beispiel genau.

StefanV

2003-06-12, 11:01:37

Original geschrieben von nggalai
Wie gross war der Catalyst3.4 nochmal? Und der Parhelia-Treiber?

93,
-Sascha.rb

Beide zwischen 5 und 6MB (Cata: 'kleine' Sprachversion).

MadManniMan

2003-06-12, 11:03:29

die frage ist natürlich: wieviele der >70 optimierungen kommen ohne qualieinbuße daher

StefanV

2003-06-12, 11:03:42

Original geschrieben von seahawk
PS : Würde mich nicht wundern, wenn die 9700pro ohne Cheats schneller ist als ne 5900U.

Siehe aktuelle PCGH, da ist die 9700 PRO nicht soo weit von der 5900U entfernt...

StefanV

2003-06-12, 11:05:19

Original geschrieben von nggalai
Oder es handelt sich um applikationsspezifische Bugfixes. Das machen Kyro-II und Radeon auch so--wenn für ein Spiel, damit's sauber läuft, im Treiber was gehackt werden muss, wird halt gehackt und eine Abfrage eingebaut. Von daher gesehen ist 73 ein recht kleiner Wert, ausser man behauptet, dass die Qualität der NV-Treiber so gut ist, dass solche Bugfixes unnötig und das ALLES Cheats sind. ;)

93,
-Sascha.rb

Schon, nur warum laufen dann diverse Spiele, die mit einer bestimmten Treiberversion mal liefen, mit späteren Treiberversionen nicht mehr??

Konkretes Beispiel:

Final Fantasy 8, läuft mit Deto 6.31 recht gut, mit nachfolgenden nur mit Bildfehlern (zerstückelter Hintergrund).

nggalai

2003-06-12, 11:28:44

Hola Stefan,

danke für die Grössen-Infos. Also sind die meisten Graka-Treiber von der Grösse her vergleichbar.
Original geschrieben von Stefan Payne
Schon, nur warum laufen dann diverse Spiele, die mit einer bestimmten Treiberversion mal liefen, mit späteren Treiberversionen nicht mehr??

Konkretes Beispiel:

Final Fantasy 8, läuft mit Deto 6.31 recht gut, mit nachfolgenden nur mit Bildfehlern (zerstückelter Hintergrund). Naja, von 6.31 zu 44.03 sind schon ein paar Revisionen und Monate vergangen. Wenn tatsächlich nur 73 solche Applikationsspezifischen Infos im Treiber stecken, wäre es dann so unwarscheinlich, alte (aus Sicht von NV obsolete) Hacks wieder z.B. asu Platzgründen rauszunehmen? Vielleicht beissen sich die Hacks auch miteinander oder den neueren Treibern selbst--ist ja nicht so, als ob ein Treiberupdate ausschliesslich Bugfixes und Hacks beinhalten würde . . .

93,
-Sascha.rb

AlfredENeumann

2003-06-12, 12:53:19

Original geschrieben von nggalai
Oder es handelt sich um applikationsspezifische Bugfixes. Das machen Kyro-II und Radeon auch so--wenn für ein Spiel, damit's sauber läuft, im Treiber was gehackt werden muss, wird halt gehackt und eine Abfrage eingebaut. Von daher gesehen ist 73 ein recht kleiner Wert, ausser man behauptet, dass die Qualität der NV-Treiber so gut ist, dass solche Bugfixes unnötig und das ALLES Cheats sind. ;)

93,
-Sascha.rb

Ich denke die NV-Treiber sind so gut?
Und die Entwickler arbeiten so toll mit NV zusammen, dann dürften ja keine Bugfixes Notwendig sein, wenn sogar auf NV HArdware Entwickelt wird, oder?
Aber man sollte die ganzen Detections mal einzeln Prüfen bevor man von Cheats spricht.

nggalai

2003-06-12, 13:04:56

Hola Alfred,
Original geschrieben von AlfredENeumann
Aber man sollte die ganzen Detections mal einzeln Prüfen bevor man von Cheats spricht. Genau darauf wollte ich hinaus. :) Es gibt einfach noch andere mögliche Gründe, weshalb diese 73 Detections im Treiber sein könnten, um gleich pauschal davon auszugehen, dass das alles Cheats für Benchmarks sind.

93,
-Sascha.rb

StefanV

2003-06-12, 14:30:14

Original geschrieben von nggalai
Hola Stefan,

danke für die Grössen-Infos. Also sind die meisten Graka-Treiber von der Grösse her vergleichbar.
Naja, von 6.31 zu 44.03 sind schon ein paar Revisionen und Monate vergangen. Wenn tatsächlich nur 73 solche Applikationsspezifischen Infos im Treiber stecken, wäre es dann so unwarscheinlich, alte (aus Sicht von NV obsolete) Hacks wieder z.B. asu Platzgründen rauszunehmen? Vielleicht beissen sich die Hacks auch miteinander oder den neueren Treibern selbst--ist ja nicht so, als ob ein Treiberupdate ausschliesslich Bugfixes und Hacks beinhalten würde . . .

93,
-Sascha.rb

Damals hatte ich IIRC einen 30er Deto drauf, ist also nicht allzulange her, war glaub ich ein halbes - 3/4 Jahr, als ich mit meiner GF1 DDR Final Fantasy8 aufm PC spielen wollte (warum ich das aufm PC spielen wollte, obwohl auch an eine PSX Version rankomme?? Vielleicht weil ich nicht auf Point Sampling stehe??), weder mit 'nem 7er, noch mit 'nem 12er wollte FF8 laufen, 20er und 30er hab ich IIRC auch mit ausprobiert.

Der einzige Deto, der wirklich gefunzt hat, war der uralte 6.31er, was ich persönlich nicht so prickelnd fand...

Mit der GF3 hatte ich bisher noch nicht wirklich das Bedürfnis FF8 zu spielen.

EDIT by MOD:

spam&flamemode OFF

Exxtreme

2003-06-12, 14:33:57

Original geschrieben von nggalai
Oder es handelt sich um applikationsspezifische Bugfixes.
93,
-Sascha.rb
Also Hacks im Treiber um Bugs in Spielen auszugleichen ist das Falscheste, was die IHVs jemals machen können!

Endorphine

2003-06-12, 14:43:08

Original geschrieben von Exxtreme
Also Hacks im Treiber um Bugs in Spielen auszugleichen ist das Falscheste, was die IHVs jemals machen können! Was würdest du denn stattdessen vorschlagen, wenn der ISV (dolle Modewörter btw ;)) die Bugs nicht beheben will?

Exxtreme

2003-06-12, 14:48:38

Original geschrieben von Endorphine
Was würdest du denn stattdessen vorschlagen, wenn der ISV (dolle Modewörter btw ;)) die Bugs nicht beheben will?
Die Spiele-Hersteller sollen die Bugs beseitigen, schliesslich haben die die Bugs verbrochen.

Ich habe keine Lust irgendwannmal 120MB-Treiber zu saugen weil jedes Spiel eine Sonderbehandlung braucht. Ausserdem ist das ein falsches Signal an die Publisher. Diese werden erst recht keine Bugs beheben denn die IHVs gleichen es ja per Treiber aus. :bonk:

Endorphine

2003-06-12, 14:52:31

Original geschrieben von Exxtreme
Die Spiele-Hersteller sollen die Bugs beseitigen, schliesslich haben die die Bugs verbrochen.

Ich habe keine Lust irgendwannmal 120MB-Treiber zu saugen weil jedes Spiel eine Sonderbehandlung braucht. Ausserdem ist das ein falsches Signal an die Publisher. Diese werden erst recht keine Bugs beheben denn die IHVs gleichen es ja per Treiber aus. :bonk: Klar, es ist nicht so, wie es sein sollte. Aber für den Durchschnittskunden immer noch besser, als ihn einfach mit den Problemen allein zu lassen. Mit Idealismus allein ist da niemandem geholfen. Die IHVs und ISVs wissen sicher auch selbst, woran es liegt und welcher Weg zur Bugbekämpfung eigentlich effektiver wäre.

Demirug

2003-06-12, 15:10:06

Es müssen ja nicht unbedingt richtige Bugs in den Spielen sein. Folgende Situation:

Für ein bestimmtes Problem im Treiber gibt es zwei Lösungen:
1. Eine sehr schnelle Lösung die aber nicht zu 100% funktioniert sondern bei 1 oder 2 Applikationen nicht mitspielt
2. Eine eher langsame Lösung die aber immer funktioniert.

Ein echtes Dilema. Nimmt man nun immer die langsame Lösung und verschenkt Leistung bei mehr als 99% aller Applikationen oder nimmt man die schnelle Lösung und baut in den Treibern eine Erkennung der problematischen Anwendung ein um dann nur für diese die langsame Alternative zu benutzten?

MadManniMan

2003-06-12, 15:47:23

auch wenn ich selbst schon lange die begriffe nütze... was genau heißen IHV und ISV ausgeschrieben?

Exxtreme

2003-06-12, 15:59:28

Original geschrieben von Demirug
Es müssen ja nicht unbedingt richtige Bugs in den Spielen sein. Folgende Situation:

Für ein bestimmtes Problem im Treiber gibt es zwei Lösungen:
1. Eine sehr schnelle Lösung die aber nicht zu 100% funktioniert sondern bei 1 oder 2 Applikationen nicht mitspielt
2. Eine eher langsame Lösung die aber immer funktioniert.

Ein echtes Dilema. Nimmt man nun immer die langsame Lösung und verschenkt Leistung bei mehr als 99% aller Applikationen oder nimmt man die schnelle Lösung und baut in den Treibern eine Erkennung der problematischen Anwendung ein um dann nur für diese die langsame Alternative zu benutzten?
In dem Fall wäre eine programmspezifische Optimierung sehr vorteilhaft da man dann davon profitiert... wenn die BQ nicht drunter leidet.

Ich bin echt gespannt um welche Art der "Sonderbehandlungen" es sich handelt. ATi dürfte auch sowas in den Treibern haben.

Endorphine

2003-06-12, 16:14:17

Original geschrieben von MadManniMan
auch wenn ich selbst schon lange die begriffe nütze... was genau heißen IHV und ISV ausgeschrieben? independent hardware/software vendor http://www.forum-3dcenter.net/vbulletin/images/icons/icon7.gif

MadManniMan

2003-06-12, 16:23:14

Original geschrieben von Endorphine
independent hardware/software vendor http://www.forum-3dcenter.net/vbulletin/images/icons/icon7.gif

ah, jetz :) independent hieß es...

2003-06-12, 17:06:33

Original geschrieben von Exxtreme

Ich bin echt gespannt um welche Art der "Sonderbehandlungen" es sich handelt. ATi dürfte auch sowas in den Treibern haben.

Davon ist auszugehen.
Kurzer Blick mit einem editor in die ati3d2ag.dll erbrachte dies, welches Spiel das ist dürften ja viele wissen:

mapel110

2003-06-12, 17:13:09

Original geschrieben von ow
Davon ist auszugehen.
Kurzer Blick mit einem editor in die ati3d2ag.dll erbrachte dies, welches Spiel das ist dürften ja viele wissen:

bei dem game ists ja nicht nur aus performance-sicht von nöten.

MadManniMan

2003-06-12, 17:29:25

Original geschrieben von mapel110
bei dem game ists ja nicht nur aus performance-sicht von nöten.

im grunde ist alles imho kein großes problem

denn solange über exe-erkennung fehler ausgemerzt werden und performance ohne BQ-hit kommt, begrüße ich diese optimierungen sogar

Razor

2003-06-12, 21:10:21

Original geschrieben von Stefan Payne
Beide zwischen 5 und 6MB (Cata: 'kleine' Sprachversion).
Ohne Control-Panel ?
???

Sagen wir lieber Cat3.2 Winxp2k (6,7MB) + Panel (4,7MB) sind zusammen immerhin über 11MB (gepackt ;-).
Der Deto44.03 (WHQL) ist ungepackt 16,5MB und gepackt dann 5MB groß (ohne Setup !)...

Also wenn wir das Optimierungsverhalten an der Treibergröße messen wollen, ist ATI führend. Vermute allerdings eher, dass die ATI Treiber wesentlich mehr Bugfixes und Workarounds inne haben, wie natürlich auch 'ne Menge 'Optimierungen' (was bei nVidia sicher auch so ist, nur nicht ganz so massiv ;-).

Bis denne

Razor

Razor

2003-06-12, 21:14:04

Original geschrieben von Stefan Payne
...Final Fantasy 8...
Danke Stefan !!!
Vielen, vielen Dank, dass Du uns wieder mal - überflüssiger weise - mit FF8 beehrt hast...
(war ja zu erwarten)

Und ?
Wieso hast Du dieses unsägliche U< ich sach's net ;-) > noch nicht heruas gekramt ?
Naaaaaa ?
:D

Razor

Demirug

2003-06-12, 21:14:10

Razor, ATI braucht auch ein bischen mehr Platz weil sie nicht ganz so unified sind wie nVidia.

Razor

2003-06-12, 21:22:01

Original geschrieben von Demirug
Razor, ATI braucht auch ein bischen mehr Platz weil sie nicht ganz so unified sind wie nVidia.
Schon klar, Demirug, aber ich fand es nur wieder mal äusserst bezeichnend, dass SP da einfach das Panel weg läßt, ohne den der Treiber ja nun gar nichts bringt.

Der einzige Grund, warum ATI das Panel vom eigentlichen Treiber trennt, ist die Tatsache, dass das Panel Multi-OS ist, der Treiber aber für Win16 und Win32.

Bin mir allerdings immer noch nicht so sicher, warum ATI das eigentlich macht. Die wenigsten werden wohl beide Betriebssysteme auf dem Rechner haben und 'sparen' sich so knappe 5MB, oder ?

Bis dann

Razor

MadManniMan

2003-06-12, 21:22:48

Original geschrieben von Razor
Danke Stefan !!!
Vielen, vielen Dank, dass Du uns wieder mal - überflüssiger weise - mit FF8 beehrt hast...
(war ja zu erwarten)

Und ?
Wieso hast Du dieses unsägliche U< ich sach's net ;-) > noch nicht heruas gekramt ?
Naaaaaa ?
:D

Razor

hm, bash0rn macht spaß, wa? :naughty:

razorle, dieses beispiel paßt absolut zu dem, was stefan sagen wollte. dabei ist es wirklich unerheblich, ob es dir gefällt oder nicht...

StefanV

2003-06-12, 21:47:47

Original geschrieben von Razor
Schon klar, Demirug, aber ich fand es nur wieder mal äusserst bezeichnend, dass SP da einfach das Panel weg läßt, ohne den der Treiber ja nun gar nichts bringt.

Der einzige Grund, warum ATI das Panel vom eigentlichen Treiber trennt, ist die Tatsache, dass das Panel Multi-OS ist, der Treiber aber für Win16 und Win32.

Bin mir allerdings immer noch nicht so sicher, warum ATI das eigentlich macht. Die wenigsten werden wohl beide Betriebssysteme auf dem Rechner haben und 'sparen' sich so knappe 5MB, oder ?

Bis dann

Razor

1. ich kann den Treiber auch ohne Panel nutzen, aTuner und rTool sei dank.
Außerdem ist 2x ein Setup dabei, wer weiß, wieviel allein das Setup samt BG frisst...

2. :lol:
Mitnichten!!
Der Grund, warum ATI das Panel vom Treiber Trennt ist WHQL!!!

Mit Panel = nix WHQL, deswegen hat ATI das Panel ausgelagert, oder bietet NV die Optionen, die ATI bietet, ohne Reg hack??

3. siehe 2.
ATI lagert es wegen WHQL aus, früher wars ja mal im Treiber...

StefanV

2003-06-12, 21:50:23

Original geschrieben von MadManniMan
razorle, dieses beispiel paßt absolut zu dem, was stefan sagen wollte. dabei ist es wirklich unerheblich, ob es dir gefällt oder nicht...

Eben!

Wenn Razor ein besseres/aktuelleres Beispiel hat, dann möge er es bitteschön bringen, anstatt andere Leute anzuflamen, mir fiel kein passenderes Beispiel ein...

Razor

2003-06-12, 22:06:54

Original geschrieben von MadManniMan
hm, bash0rn macht spaß, wa? :naughty:

razorle, dieses beispiel paßt absolut zu dem, was stefan sagen wollte. dabei ist es wirklich unerheblich, ob es dir gefällt oder nicht...
Tut es nicht.
Vielleicht hätte er es mal mit späteren Treibern ausprobieren sollen. So lief dieses absolut buggy FF8 durchaus mit den 20'ern und 30'ern (mit den vorherigen hab' ich den Schrott schlicht nicht getestet !) . Auch habe ich ihm das damals so mitgeteilt, was er - wie immer - irgnorierte.

Und jetzt schon wieder.

Sorry, aber...

"hm, bash0rn macht spaß, wa? :naughty:"

Jaaaaaaa.....
:D

Razor

Razor

2003-06-12, 22:09:23

Original geschrieben von Stefan Payne
1. ich kann den Treiber auch ohne Panel nutzen, aTuner und rTool sei dank.
Außerdem ist 2x ein Setup dabei, wer weiß, wieviel allein das Setup samt BG frisst...

2. :lol:
Mitnichten!!
Der Grund, warum ATI das Panel vom Treiber Trennt ist WHQL!!!

Mit Panel = nix WHQL, deswegen hat ATI das Panel ausgelagert, oder bietet NV die Optionen, die ATI bietet, ohne Reg hack??

3. siehe 2.
ATI lagert es wegen WHQL aus, früher wars ja mal im Treiber...
Nur komisch, dass nVidia auch so WHQL bekommt und ATI damit ja wohl beim 3.3 auch Probleme bekommen hat... trotz Trennung.

Aber hoffentlich hast Du gerafft, worauf ich hinaus wollte...

Razor

Razor

2003-06-12, 22:09:55

Original geschrieben von Stefan Payne
Eben!

Wenn Razor ein besseres/aktuelleres Beispiel hat, dann möge er es bitteschön bringen, anstatt andere Leute anzuflamen, mir fiel kein passenderes Beispiel ein...
Es gibt kein aktuelles Beispiel !

Razor

StefanV

2003-06-12, 22:11:42

Original geschrieben von Razor
Es gibt kein aktuelles Beispiel !

Razor

Und wo ist dann bitteschön DEIN PROBLEM??

FF8 hab ich nur genannt, um ein BEISPIEL zu nennen, da mir kein besseres Beispiel einfiel, hab ich das mal genommen, da dir nichts besseres eingefallen ist, verstehe ich DEIN Problem nicht!!

StefanV

2003-06-12, 22:14:10

Original geschrieben von Razor
Nur komisch, dass nVidia auch so WHQL bekommt und ATI damit ja wohl beim 3.3 auch Probleme bekommen hat... trotz Trennung.

Aber hoffentlich hast Du gerafft, worauf ich hinaus wollte...

Razor

1. hat NV unter D3D Häckchen wie VSync??
Ohne Coolbits eher nicht, was??

1b. Vielleicht ligtes ja auch daran, daß M$ die WHQL Testsuite geändert hat??

2. hm, mal überlegen, vielleicht gegen ATI flamen??
Aber vielleicht bist du ja noch so freundlich und erklärst es nochma für die, die es nicht verstanden haben/verstehen wollten...

Razor

2003-06-12, 22:22:23

Original geschrieben von Stefan Payne
1. hat NV unter D3D Häckchen wie VSync??
Ohne Coolbits eher nicht, was??
Was ist besser ?
Ein komplettes Setup mit herunter laden, oder ein Doppelklick auf einen 2-Zeiler ?

Wird eigentlich der User aufgeklärt, dass er bei Installation des Panels die WHQL-Zulassung verliert ?
???
Original geschrieben von Stefan Payne
1b. Vielleicht ligtes ja auch daran, daß M$ die WHQL Testsuite geändert hat??
Woran auch immer... nVidia hat ja wohl offensichtlich kein Problem damit gehabt, oder ?
Original geschrieben von Stefan Payne
2. hm, mal überlegen, vielleicht gegen ATI flamen??
Aber vielleicht bist du ja noch so freundlich und erklärst es nochma für die, die es nicht verstanden haben/verstehen wollten...
Vielleicht solltest Du Dir leiber selber mal an die Nase fassen...
Nur so ein Gedanke.

Razor

Iceman346

2003-06-12, 22:47:33

Original geschrieben von Razor
Was ist besser ?
Ein komplettes Setup mit herunter laden, oder ein Doppelklick auf einen 2-Zeiler ?

:rofl:

Klar, jeder User weiss auch, wie man Coolbits schreibt/ausführt bzw. wo mans herkriegt. Da ist die Art wie ATi es durchführt imo deutlich intelligenter.

Und nur weils nicht von nvidia ist ists nicht unbedingt schlecht, nicht wahr Razor...

Quasar

2003-06-12, 22:51:13

Original geschrieben von Razor
Danke Stefan !!!
Vielen, vielen Dank, dass Du uns wieder mal - überflüssiger weise - mit FF8 beehrt hast...
(war ja zu erwarten)

Und ?
Wieso hast Du dieses unsägliche U< ich sach's net ;-) > noch nicht heruas gekramt ?
Naaaaaa ?
:D

Razor

Vielleicht weil das auf einigen ATi-Karten unerklärlicherweise seltsame Artefakte um die Bäume herum produziert, wenn AF aktiviert wird und dieser Bug bei nV mittlerweile gefixt scheint...?

MadManniMan

2003-06-12, 23:17:50

Original geschrieben von Razor
Und jetzt schon wieder.

soll das heißen, dass es mit einigen neueren treibern funktioniert :|

Exxtreme

2003-06-13, 07:57:24

Original geschrieben von Razor
Sagen wir lieber Cat3.2 Winxp2k (6,7MB) + Panel (4,7MB) sind zusammen immerhin über 11MB (gepackt ;-).
Der Deto44.03 (WHQL) ist ungepackt 16,5MB und gepackt dann 5MB groß (ohne Setup !)...

Bis denne

Razor

Naja, das Controlpanel muss man sich eigentlich nur einmal runterladen. Danach wird nur noch der Austausch der eigentlichen Treiber fällig, das CP kann man installiert lassen.

Gast

2003-06-13, 08:21:03

Original geschrieben von Exxtreme
Naja, das Controlpanel muss man sich eigentlich nur einmal runterladen. Danach wird nur noch der Austausch der eigentlichen Treiber fällig, das CP kann man installiert lassen.

Echt? Und wieso gibt's dann zu jedem Catalyst eine neue Version?

Nicht, daß ihr mich falsch versteht, ich finde sowohl die Trennung von CP und Treiber und auch das CP an sich ziemlich gelungen.

Razor

2003-06-13, 08:31:31

Original geschrieben von MadManniMan
soll das heißen, dass es mit einigen neueren treibern funktioniert :|
Nicht nur mit einigen, sondern schlicht mit allen...
Bestätigen kann ich dies mit diversen Treibern >=2x.xx

Razor

Exxtreme

2003-06-13, 08:33:06

Original geschrieben von Gast
Echt?

Ja, kannst mal beim nächsten Treiber mal austesten.
Original geschrieben von Gast
Und wieso gibt's dann zu jedem Catalyst eine neue Version?

Manchmal kommen doch neue Features rein. Da empfiehlt es sich das neueste CP zu haben.

Razor

2003-06-13, 08:34:41

Original geschrieben von Exxtreme
Manchmal kommen doch neue Features rein. Da empfiehlt es sich das neueste CP zu haben.
Also doch immer das Panel zum Treiber ?
:D

Razor

Exxtreme

2003-06-13, 08:37:08

Original geschrieben von Razor
Also doch immer das Panel zum Treiber ?
:D

Razor
Wie gesagt, du kannst dir immer das neuste Panel runterladen und installieren oder du lässt es sein. :)

Razor

2003-06-13, 09:04:06

Original geschrieben von Exxtreme
Wie gesagt, du kannst dir immer das neuste Panel runterladen und installieren oder du lässt es sein. :)
Und verzichte damit auf Features ?
???

Du würdest mir doch aber zustimmen, dass ein Treiber ohne Panel kaum Sinn macht, oder ?
Zumindest kann man also nVidia Treiber auch ohne 'Hack' nutzen...
(und damit auch ohne Verlust der WHQL-Zulassung ;-)

Bis denne

Razor

P.S.: Ich weiß, was Du zum Ausdruck bringen wolltest, nur finde ich diese Diskussionsgrundlage (Treiber-Größe vs. Qualität vs. Usability vs. Cheating/Optimierungsvielfalt) einfach nur lolig...
;D

StefanV

2003-06-13, 10:41:32

Original geschrieben von Gast
Echt? Und wieso gibt's dann zu jedem Catalyst eine neue Version?

Nicht, daß ihr mich falsch versteht, ich finde sowohl die Trennung von CP und Treiber und auch das CP an sich ziemlich gelungen.

1. hm, gute Frage, vielleicht, um die Versionsnummer anzupassen :naughty:
Nauja, ab und an werden mal ein paar Optionen geändert, siehe z.B. VSync und Truform, was ja (optisch) geändert wurde ;))

Exxtreme

2003-06-13, 10:49:24

Original geschrieben von Razor
Und verzichte damit auf Features ?
???

Nein, aber kannst sie nicht aktivieren. Wie gesagt, wenn neue Features hinzukommen, die man möglicherweise braucht, dann neues CP ziehen ansonsten das alte belassen.
Original geschrieben von Razor
Du würdest mir doch aber zustimmen, dass ein Treiber ohne Panel kaum Sinn macht, oder ?

Doch, du kannst immer noch deine Spiele starten, du kannst aber keinerlei Änderungen ohne das CP (und anderer Tools) vornehmen, sodaß ein grosser Teil der Features dir verwehrt bleibt.
Original geschrieben von Razor
Zumindest kann man also nVidia Treiber auch ohne 'Hack' nutzen...
(und damit auch ohne Verlust der WHQL-Zulassung ;-)

Bis denne

Razor

Du weisst wohl, welche Meinung ich über das WHQL-Programm habe. ;)
Original geschrieben von Razor
P.S.: Ich weiß, was Du zum Ausdruck bringen wolltest, nur finde ich diese Diskussionsgrundlage (Treiber-Größe vs. Qualität vs. Usability vs. Cheating/Optimierungsvielfalt) einfach nur lolig...
;D
Ich auch. ;)

ice cool69

2003-06-14, 17:57:42

reg dich nicht auf razur is 100%iger nvidia-fanboy, ich glaube nicht dass du das nötig hast den ernst zu nehmen oder?

Anárion

2003-06-14, 18:00:45

Original geschrieben von ice cool69
reg dich nicht auf razur is 100%iger nvidia-fanboy, ich glaube nicht dass du das nötig hast den ernst zu nehmen oder?

Der schafft's aber Postings wie deins zu unterlassen. Das nennt man Reife.

MadManniMan

2003-06-14, 18:30:44

Original geschrieben von Anárion
Der schafft's aber Postings wie deins zu unterlassen. Das nennt man Reife.

auch auf die gefahr hin, diesen post hier durch löschen zu verlieren, da zu OT:

razor hat es oft drauf, in seine durchaus manchmal irrtumsfreien posts dolle beleidigungen reinzupacken

Razor

2003-06-14, 22:42:49

Original geschrieben von ice cool69
reg dich nicht auf razur is 100%iger nvidia-fanboy, ich glaube nicht dass du das nötig hast den ernst zu nehmen oder?
Ich glaube nicht, dass sich Exxtreme aufgeregt hat.
Auch denke ich, dass wir ganz gut miteinander klar kommen...
;-)

Razor

Razor

2003-06-14, 22:44:09

Original geschrieben von MadManniMan
razor hat es oft drauf, in seine durchaus manchmal irrtumsfreien posts dolle beleidigungen reinzupacken
Tatsächlich ?
Würde mich eigentlich wundern...

Razor

nagus

2003-06-17, 13:10:38

sehr interessant... http://www.3dvelocity.com/reviews/5900u/5900u_16.htm

die radeons haben wirklich verdammt geile pixelshader-leistung

*UPDATE*

die FXn haben verdammt schlechte shader leistungen. handelt sich wohl um einen "bug" bzw. cheat warum dei der älteren shadermark-version die werte um ein vielfaches höher sind.

Frank

2003-06-17, 13:34:47

Original geschrieben von nagus
die radeons haben wirklich verdammt geile pixelshader-leistung
THREADTHEMA
Treiber Bugs im Deto FX und mögliche Auswirkungen auf die Benchmarkergebnisse]
aaaaahhhhhhja

:topic: :spam:

nagus

2003-06-17, 14:16:42

Original geschrieben von Frank
aaaaahhhhhhja

:topic: :spam:

entschuldigung, hab mein posting angepasst

Quasar

2003-06-17, 16:37:25

Was is'n das für ein komisches Review. Ich kann irgendwie keinerlei Bezug der von nagus verlinkten Seite und ihrem Inhalt zum Rest des etwas chaotischen Reviews erkennen.

Auch kann ich keine "anderen" Shadermark-Werte sehen... Man helfe mir auf die Sprünge plz!

Black-Scorpion

2003-06-17, 17:05:03

Original geschrieben von Quasar
Was is'n das für ein komisches Review. Ich kann irgendwie keinerlei Bezug der von nagus verlinkten Seite und ihrem Inhalt zum Rest des etwas chaotischen Reviews erkennen.

Auch kann ich keine "anderen" Shadermark-Werte sehen... Man helfe mir auf die Sprünge plz!

Nagus hat den 2. Link vergessen.

http://www.3dvelocity.com/reviews/5900u/5900u_4.htm

und nochmal

http://www.3dvelocity.com/reviews/5900u/5900u_16.htm

Quasar

2003-06-17, 18:15:06

Danke Anonym_001:

The 5800 Ultra's PS2.0 performance was never really questioned and was always considered (by us anyway) one of its strongest features, so we weren't expecting any massive improvements on the 5900 Ultra.

Was ham die denn geraucht????????

Also, was die beiden Versionen vom ShaderMark angeht:

ad1) ATis Treasure Chest Demo soll nicht auf ATi-Karten optimiert sein? Sorry, aber das kommt mir, gelinde gesagt, etwas spanisch vor.

ad2) Komisch, dass nur durch geshuffelte Instruktionen auch die ATi ziemlich verliert. Dass die nV-Chips hierfür "anfällig" sind, ist ja bekannt, da nunmal jedweder DX9-Code, der mit dem MS/ATi-Compiler erzeugt wurde, nicht mit den nV3x harmoniert.

Demirug

2003-06-17, 18:18:41

Original geschrieben von Quasar
Danke Anonym_001:

Was ham die denn geraucht????????

Also, was die beiden Versionen vom ShaderMark angeht:

ad1) ATis Treasure Chest Demo soll nicht auf ATi-Karten optimiert sein? Sorry, aber das kommt mir, gelinde gesagt, etwas spanisch vor.

ad2) Komisch, dass nur durch geshuffelte Instruktionen auch die ATi ziemlich verliert. Dass die nV-Chips hierfür "anfällig" sind, ist ja bekannt, da nunmal jedweder DX9-Code, der mit dem MS/ATi-Compiler erzeugt wurde, nicht mit den nV3x harmoniert.

Die Shadermark shader sind von Hand programmiert. Aber im Prinzip handelt es sich dabei um auf 2.0 umgeschrieben 1.x Shader. Aber Thomas kann das sicher genauer erklären.

Razor

2003-06-17, 19:49:28

Original geschrieben von Demirug
Die Shadermark shader sind von Hand programmiert. Aber im Prinzip handelt es sich dabei um auf 2.0 umgeschrieben 1.x Shader. Aber Thomas kann das sicher genauer erklären.
"Von Hand programmiert" unter Assembler ?
???

Und wenn unter Assembler... nach welchen Guidelines ?
Da der Source-Code der Shader aber dabei liegt und mir das doch sehr nach HLSL aussieht, vermute ich auch mal, dass diese mit dem (Standard-)M$-Compiler compiliert wurden. Also kommen hier (zumindest definitiv bei dem DX8-Test) ATI-Shader zum Einsatz, welche wohl mit dem M$-Compiler compiliert wurden.

Also irgendwie...
:D

Razor

P.S.: Wenn ich das richtig verstanden habe, dann nutzt Tommti definitiv die Geometrie und die Texturen aus dem Treasure-Chest-Demo. Ob er die Shader jetzt umgeschrieben hat, oder aber einfach nur auf eine andere DX/PS-Version portiert hat, kann ich nicht sagen... nur, dass die DX8-Shader des ShaderMark zu denen des orginalen Demo's absolut identisch sind.

Gil-galad

2003-06-17, 20:22:33

Original geschrieben von nagus
entschuldigung, hab mein posting angepasst

Nagus Du hast ne PM *eg*

Demirug

2003-06-17, 20:24:42

Original geschrieben von Razor
"Von Hand programmiert" unter Assembler ?
???

Und wenn unter Assembler... nach welchen Guidelines ?
Da der Source-Code der Shader aber dabei liegt und mir das doch sehr nach HLSL aussieht, vermute ich auch mal, dass diese mit dem (Standard-)M$-Compiler compiliert wurden. Also kommen hier (zumindest definitiv bei dem DX8-Test) ATI-Shader zum Einsatz, welche wohl mit dem M$-Compiler compiliert wurden.

Also irgendwie...
:D

Razor

P.S.: Wenn ich das richtig verstanden habe, dann nutzt Tommti definitiv die Geometrie und die Texturen aus dem Treasure-Chest-Demo. Ob er die Shader jetzt umgeschrieben hat, oder aber einfach nur auf eine andere DX/PS-Version portiert hat, kann ich nicht sagen... nur, dass die DX8-Shader des ShaderMark zu denen des orginalen Demo's absolut identisch sind.

Ja die DX8 sind die originalshader und die hat Thomas entsprechend portiert.

Ich weiss das relative genau: http://www.forum-3dcenter.org/vbulletin/showthread.php?s=&threadid=44943

AlfredENeumann

2003-06-19, 11:51:23

Original geschrieben von Tarkin
hat das schon jemand geposted?

http://www.beyond3d.com/forum/viewtopic.php?t=6377

interessant ist auch folgendes:

"Actually it was posted on ixbt forum:
http://forum.ixbt.com/0010/044212-30.html

- Detonators have 73-element table of "recognized" applications
- ~50 "recognized" shaders
He simply wrote rivatuner-patch hich will "block" detection routines in the driver.
IMHO just a matter of time to see how 8500 fps in GT4 jumped ahead..."

:kratz2:

Unwinder hat solche Detection jetzt auch im ATI-Treiber entdeckt. Auch für 3DMArk2001. Durch blocken dieser Detections fällt auch ATI im Naturetest auf das gleiche Niveau wie NV zurück.
Mann sollte jetzt wirklich mal untersuchen und auch nachfragen was diese Detections alles bewirken.

Richthofen

2003-06-19, 12:01:07

was wohl. Mehr Performance in synthethischen Benchmarks und Standardspielebenchmarks.
Manchmal zu lasten der Bildqualität, manchmal auch nicht.

AlfredENeumann

2003-06-19, 14:02:19

Original geschrieben von Richthofen
was wohl. Mehr Performance in synthethischen Benchmarks und Standardspielebenchmarks.
Manchmal zu lasten der Bildqualität, manchmal auch nicht.

Wenn du das so pauschal sagst, sage ich pauschal das Nvidia-Karten nie schneller waren als ATI.Karten. Eher im Gegenteil. Die Karten sind nur durch Cheats jedesmal Testsieger geworden.

Quasar

2003-06-19, 14:13:20

Original geschrieben von AlfredENeumann
Wenn du das so pauschal sagst, sage ich pauschal das Nvidia-Karten nie schneller waren als ATI.Karten. Eher im Gegenteil. Die Karten sind nur durch Cheats jedesmal Testsieger geworden.

Das ist dein gutes Recht, AEN. Jedoch scheinst du ein wenig die Situation zu verkennen.....

Beide cheaten.
Inkl. Cheats ist nV (meist) schneller.
Ohne Cheats: who knows?

Exxtreme

2003-06-19, 18:15:53

NVIDIA to 3DVelocity wrote:
NVIDIA works closely with games deveopers and 9 out of 10, and eventually nearer 10 out of 10 games will be either developed on their hardware, developed with Cg or developed with their direct input. How can they be accused of not conforming to industry standard shader routines when they ARE the driving force that sets the industry standards in shaders. Games developers are not likely to go shuffling instructions the way benchmark creators are and any games developer that wants to succeed will write their code so that it runs the way NVIDIA's shaders expect it to. the fact that their shader don't cut it on rarely heard of benchmarks and code that's been "tinkered" with is of little or no concern to them. They won't spend valuable time defending themselves against something they don't see as worth defending. Changing code doesn't expose cheating, it simply feeds code to their shaders in a way that they're not designed to handle it. Games developers will never do that, and if it's games performance that matters then NVIDIA is where the clever money is being spent.

Richard Huddy from ATI responded to Dave at B3D:

It's fair to say that NVIDIA hardware is used in the development of most games. That's true - but it's not as spectacular a domination as NVIDIA would have people believe. ATI is also used in the development of most games. In fact I suspect that you couldn't find a single example of a game which was developed without some use of both Vendor's hardware. [Even GunMetal which is intended for NVIDIA hardware only was clearly fixed up at some point on ATI hardware.] That's the way the process works. No game could be released with a respectable QA process which involves everyone's hardware.

But what NVIDIA are trying to claim is that developers produce code which is specifically tuned to work best on their hardware - and that claim is completely bogus. Sure they have an active DevRel team who try to intervene in the development process and steer things NVIDIA's way - but we all know that the two real dominating forces in games are (a) schedule and (b) the game. For that reason most shaders are written by the games developers in general kinds of ways - most of them are not tuned for NVIDIA hardware at all. NVIDIA don't control this industry nor will they ever.

They claim to be "the driving force that sets the industry standards in shaders". If that's the case then it's odd that they arrived late with their DX9 support (about 6 months behind ATI), that they have been shown to re-write several DX9 benchmark shaders to run on their DX8-style fixed point interfaces, that the OpenGL ARB declined to use Cg as the basis for OpenGL's high level shading language, that their own demo 'Dawn' runs faster on ATI hardware than on NVIDIA hardware even with the extra layers of software involved etc., etc.

NVIDIA are trailing for the moment. Now I don't think they're going to trail forever - but they still haven't come to terms with the fact that they're very much second best at the moment. And in that sense they're like alcoholics... The first step to recovery is to come to terms with the truth in the situation. Right now NVIDIA can't seem to do that, instead they're just saying that everyone else is wrong.

As for the claim that games developers don't shuffle shader ops around well that's an odd statement. Developers clearly do tweak shaders during the development process mostly to make experimental tweaks to the functionality - and often that means that reordering happens many times along the way. But sure, when a game is released it tends to remain unchanging. Then if NVIDIA become interested in the benchmarking built into the game then if they want to, they can go in and detect the shaders and consider substituting in other shaders that do 'similar' things (usually with some image quality reduction) but run faster. At that point NVIDIA would describe them as Application Specific Optimisations - but since they are authored solely with the purpose of getting higher benchmark scores then the so-called optimisations may be totally inactive during actual game play.

It's also clear that NVIDIA have been involved in this process in a very extensive way. The revelations regarding both ShaderMark and 3DMark03 make it abundantly clear that NVIDIA do re-write their shaders specifically to rise their scores in synthetic benchmarks. Clearly they're very interested in benchmark scores no matter how synthetic.

The statement that, "Changing code doesn't expose cheating, it simply feeds code to their shaders in a way that they're not designed to handle it" is also very obviously not true. If this were the case you might expect to see a small reduction in shader performance - but you cannot explain the massive performance drops that have been seen in recent cases. It would be remarkable indeed if NVIDIA had designed hardware that could only run the shaders from this "rarely heard of benchmark" at decent speed and any changes to that setup would many times slower. That would suggest that their hardware was perhaps the most badly designed you could imagine. Where's all this programmability they keep claiming to have? If you use it then you lose all your performance?

Actually on reflection I guess that you could argue that the above quote from NVIDIA _is_ true. Take it literally - and don't worry about the word 'cheating' in there - we'll let them use their "Get Out Of Jail Free" card for that. What the NVIDIA defence could be claiming is that their hardware is not designed to handle DX9 shaders. Something I guess I'd be happy to accept.

3DVelocity wrote:
"When I asked about the FX's relatively poor performance in our "real" game tests the reply wasn't entirely clear but they certainly claim to have doubts on the reliability of FRAPS and the reliability of those using it. In a nutshell they're saying that you can analyse all you want, future titles will be coded to run at their best on NVIDIA hardware and they suggested we ask the developers who they think is on top right now."

It's a fine sight isn't it? A company that used to lead by example with innovative technology and honest product positioning is reduced to saying that anyone who uses FRAPS to check on NVIDIA's story is unreliable. There's no reason I know of to doubt FRAPS - it's widely used and well respected.

It reminds me of the guy who was talking to his psychologist and his psychologist said, "You're in denial". To which the guy's simple response was, "No I'm not".

Developers genuinely like the fact that there's some intense competition in graphics these days. They see that as a good thing - and many of them like the spectacle of the struggle for technological supremacy. I don't think they're impressed by this kind of nonsense.

Demirug

2003-06-19, 18:26:58

Exxtreme, das habe ich auch gerade gelesen und es ist amüsant wie immer wenn sich zwei Grosse schlagen.

*popcorn holen*

Jeder stellt sich eben so gut dar wie es nur geht.

Gast

2003-06-19, 18:33:11

Original geschrieben von Quasar
Das ist dein gutes Recht, AEN. Jedoch scheinst du ein wenig die Situation zu verkennen.....

Beide cheaten.
Inkl. Cheats ist nV (meist) schneller.
Ohne Cheats: who knows?

Nvidia ist doch schon langsamer, wenn man nicht das Standarddemo (zB. Antalus) nimmt. Da mach dir mal keine Illusionen.

Quasar

2003-06-19, 18:56:24

Original geschrieben von Gast
Nvidia ist doch schon langsamer, wenn man nicht das Standarddemo (zB. Antalus) nimmt. Da mach dir mal keine Illusionen.

Jo? Ich mach mir schon keine Illusionen, danke. =)

AlfredENeumann

2003-06-19, 19:40:05

Original geschrieben von Quasar
Das ist dein gutes Recht, AEN. Jedoch scheinst du ein wenig die Situation zu verkennen.....

Beide cheaten.
Inkl. Cheats ist nV (meist) schneller.
Ohne Cheats: who knows?

Das war ja nicht meine richtige meinung, nur wenn Richthofen mit mit pauschalen aussagen kommt mach ich das auch.
Außerdem bezichtige ich keinen bei diesen Detections die Unwinder gefunden hat als cheater. Unwinder soll gefälligst erstmal hgenau nachweise wofür jede detection benutzt wird.
Das einzige was ich NV derzeit vorhalte ist das Shader beim Murks durch NV-eigene ersetzt wurden. Die umsortierung von Shader instruktionen sind mir wurscht, solange die Bildquali nicht drunter leidet. Bei einem Bench sollten aber auch solche Umsortierungen Unterlassen werden, weil das nicht der Sinn eines Benches ist.

Anárion

2003-06-19, 19:52:17

Original geschrieben von AlfredENeumann
nur wenn Richthofen mit mit pauschalen aussagen kommt mach ich das auch

Stehst du auf Schnullerentzug? Kommt mir so vor....

Exxtreme

2003-06-19, 19:58:51

Original geschrieben von Demirug
Exxtreme, das habe ich auch gerade gelesen und es ist amüsant wie immer wenn sich zwei Grosse schlagen.

*popcorn holen*

Jeder stellt sich eben so gut dar wie es nur geht.

Hrhrhr,

lustig wird das ganze erst, wenn man zwischen den Zeilen liest.

NV:

Alle Spiele werden auf NV-HW entwickelt und laufen dort am schnellsten -> alles was schneller auf Nicht-NV-HW läuft, ist nicht repräsentativ (incl. eigene Timedemos?? );

Alle synthetischen Benchmarks werden anders programmiert als 'echte' Spiele -> Reviewer sollen keine synthetischen Benchmarks mehr nutzen;

Wir haben Zweifel, daß FRAPS was taucht -> Die Reviewer sollen kein FRAPS mehr nutzen;

ATi:

NV hat zwar recht, daß die meisten Spiele auf NV-HW gecoded werden aber auf unserer auch -> NV redet Bullshit;

NV braucht spezielle Anpassungen, damit die Shader schnell laufen und das tun die Programmierer aber nicht. Und überhaupt ist die NV3x-Serie nicht richtig für DX9 designed -> die Radeon-Serie ist unter'm Strich trotzdem besser;

AlfredENeumann

2003-06-19, 19:59:58

Original geschrieben von Anárion
Stehst du auf Schnullerentzug? Kommt mir so vor....

Manchmal schon :...( :clown: :clown:

Demirug

2003-06-19, 20:25:45

Original geschrieben von Exxtreme
Hrhrhr,

lustig wird das ganze erst, wenn man zwischen den Zeilen liest.

NV:

Alle Spiele werden auf NV-HW entwickelt und laufen dort am schnellsten -> alles was schneller auf Nicht-NV-HW läuft, ist nicht repräsentativ (incl. eigene Timedemos?? );

Alle synthetischen Benchmarks werden anders programmiert als 'echte' Spiele -> Reviewer sollen keine synthetischen Benchmarks mehr nutzen;

Wir haben Zweifel, daß FRAPS was taucht -> Die Reviewer sollen kein FRAPS mehr nutzen;

ATi:

NV hat zwar recht, daß die meisten Spiele auf NV-HW gecoded werden aber auf unserer auch -> NV redet Bullshit;

NV braucht spezielle Anpassungen, damit die Shader schnell laufen und das tun die Programmierer aber nicht. Und überhaupt ist die NV3x-Serie nicht richtig für DX9 designed -> die Radeon-Serie ist unter'm Strich trotzdem besser;

Das zwischen den Zeilen lesen habe ich doch impliziert und da schreiben beide viel Müll weil sie ja gut aussehen wollen. Nicht vergessen Huddy war auch mal nv und hat dort sicherlich so einiges gelernt :D

ich warte jetzt auf den nächsten Schuss von nv. So in der Art:

ATIs hardware kann technisch mit unsere Hardware nicht mithalten das erkennt man ja schon daran das unsere DX9 Shader dort gar nicht laufen.

dann noch so etwas:

DX9 musste ja nur wegen ATI so weit begrennzt das unsere hochflexible Hardware nun ihere stärken unter dem DX9 minium gar nicht zeigen kann. Da die Entwickler aber immer das beste zeigen wollen definiert unsere Hardware die höchste Stufe für die entwickelt wird.

Und dann natürlich noch der opligatorische Verweiss auf Cg:

Wir sind der einzige IHV der einen eigenen Compiler für Hochsprachen Shader hat welcher optimalen Shadercode erzeugt. Alle anderen IHVs sind auf die Fähigkeiten und die Unterstüzung von Microsoft angewiesen.

Bitte nicht so ernst nehmen :D

Pathfinder

2003-06-19, 22:07:56

Original geschrieben von Demirug
Das zwischen den Zeilen lesen habe ich doch impliziert und da schreiben beide viel Müll weil sie ja gut aussehen wollen. Nicht vergessen Huddy war auch mal nv und hat dort sicherlich so einiges gelernt :D

ich warte jetzt auf den nächsten Schuss von nv. So in der Art:

ATIs hardware kann technisch mit unsere Hardware nicht mithalten das erkennt man ja schon daran das unsere DX9 Shader dort gar nicht laufen.

dann noch so etwas:

DX9 musste ja nur wegen ATI so weit begrennzt das unsere hochflexible Hardware nun ihere stärken unter dem DX9 minium gar nicht zeigen kann. Da die Entwickler aber immer das beste zeigen wollen definiert unsere Hardware die höchste Stufe für die entwickelt wird.

Und dann natürlich noch der opligatorische Verweiss auf Cg:

Wir sind der einzige IHV der einen eigenen Compiler für Hochsprachen Shader hat welcher optimalen Shadercode erzeugt. Alle anderen IHVs sind auf die Fähigkeiten und die Unterstüzung von Microsoft angewiesen.

Bitte nicht so ernst nehmen :D

Ich halte den nächsten "Schuß" für eher unwahrscheinlich. Warum sollten sie überhaupt auf die zweitklassige ATI-Konkurrenz mit der vorsintflutlichen Technik reagieren? Die Überlegenheit der eigenen Technologie ist unmittelbar ersichtlich, ganz besonders für alle Entwickler dieser Welt. Lediglich die Reviewer sind ein wenig zurückgelieben. Aber das macht doch nichts! - Kurz und prägnant wird die aktuelle Lage am Telefon vermittelt und danach sollen die Uhren auch bei denen wieder richtig ticken.

So einfach kann die Welt der Grafikhardware sein, wenn man nur ausreichend Halluzinogene geraucht hat! ;)

Bitte nicht so ernst nehmen!

Pathfinder