NVIDIA und Futuremark [Archiv] - Seite 2

Salvee

2003-05-30, 12:30:05

Original geschrieben von Gästle
Hast du dich mal gefragt, was man zB mit dem Codecreatures Benchmark misst? Ein hochoptimierter Bench für eine "bestimmte" Architktur, nur als der rauskam gab/gibt es keinen Aufschrei der Entrüstung, damit wird fröhlich in vielen Reviews gebencht.

Es ist einfach verlogen, sich jetzt so zu entrüsten, während man über lange Zeit diese Situation ignoriert bis gefördert hat.

Demirug hat den Codecraetures bench bereits kritisiert und als 'seltsam' abgetan. Das kann man ihm also nicht vorwerfen imho.
Es gibt aber noch extremere Beispiele für Benchmarks, die fröhlich von allen möglichen 'Dau-Reviewern' benutzt wurden (allerdings OGL), als da wären
1. Dronez
2. Vulpine GL Mark

Hat nV sich damals beschwert oder gejammert? -> Nope
Haben sie diese Benches verloren ? -> Nope
Den Rest kann man sich denken ...

seahawk

2003-05-30, 12:43:10

Original geschrieben von Mr. Lolman
Stimmt, denn als damals eine Voodoo5 mit 2500 Punkten gegen eine 'doppelt so schnelle' GF2GTS abstinkte interessierte es auch keinnem.

IMO lag die Voodoo5 soagr auf GF3 Niveau. Ich spielte MoHAA in 1024x768x22, 2xAA. Bei einer GF2 hätte man 4xAA und 32bit verwenden müssen, damit die BQ ähnlich aussieht. Da hätte eine GF2 kein Licht gesehen, und trotzdem wars legitim alle Karten mit dem 3dmark 2000/2001 zu benchen. Deswegen ahb ich jetzt kein Verständnis mit den Leuten die nach 4 Jahren (zum ersten Mal wenn die NV Karten ggü. den direkten Konkurrenten nicht so toll dastehen) anfangen über den Mark zu meckern.

Der 3dmark ist da, wird verwendet und pasta. NV braucht keine Sonderbehandlung. 3dfx bekam sie ja auch nicht. Hoffen wir, dass die nächste Version auf NV Karten wieder ein zufriedenstellenderes Ergebnis abliefert ;).

Ja der 3DMark und die 3Dfx KArten. Irgendwie immer eine unglücklicher Mischung. Aber da die 3dfx Karten ja was DX-Features angeht irgendwie unkonvetionell waren ist das nicht so klar.

Aber das Beispiel beweist auch wie realitätsfern der 3DMark schon immer war. (Ich habe nie was anders gesagt)

seahawk

2003-05-30, 12:44:50

Original geschrieben von Salvee
Demirug hat den Codecraetures bench bereits kritisiert und als 'seltsam' abgetan. Das kann man ihm also nicht vorwerfen imho.
Es gibt aber noch extremere Beispiele für Benchmarks, die fröhlich von allen möglichen 'Dau-Reviewern' benutzt wurden (allerdings OGL), als da wären
1. Dronez
2. Vulpine GL Mark

Hat nV sich damals beschwert oder gejammert? -> Nope
Haben sie diese Benches verloren ? -> Nope
Den Rest kann man sich denken ...

ATI hätte ja JAmern können - bzw. wenn ihre Hardware unfair benachteiligt wird jammern müssen imo.

Demirug

2003-05-30, 13:00:26

Original geschrieben von Salvee
Wenn man sich die Spekulationen hier so durchliest, stellen sich mir doch ein paar Fragen:

- der Konsens, der hier im Forum vor ein paar Monaten gefunden wurde, ist für die Tonne: damals ging es um die Befürchtungen, ob beispielsweise per
Cg programmierte Games ATi benachteiligen werden. Das Ergebnis war: man kann im Grossen und Ganzen nicht auf einen IHV optimieren, die
Optimierungsguides sein sich sehr ähnlich, sobald man auf den einen optimiert, ist's auch für den anderen optimiert etc.
Das kann man im Zeitalter von DX9 wohl erstmal komplett vergessen.

Solange wir mal die Shader aussen vorlassen also nur den reinen Codepfad (der ja shaderunabhängig ist) betrachten stimmen die Guidelines noch fast zu 100% überein.

Auch was die grundsätzlichen Dinge angeht (Anzahl der Instruktionen, Verhältniss Texturanweisungungen/Rechenanweisungen) ist man sich bei nv und ATI noch recht einig. Wenn es dann aber ins Detail (Instruktionsreihenfolge, Registerbenutzung) geht fangen die Unterschiede an.

- DX9 scheint ja nicht besonders 'einheitlich' zu sein, liegt das nur an der relativ hohen Programmierbarkeit der DX9-Chips? Oder ist DX9 Schrott (salopp formuliert)?

DX9 normiert nur Verfahren. Unter anderem eben auch wie ein Shader angelegt und benutzt wird. Desweiteren wird auch noch festgelegt wie das binäre Format eines Shaders aufgebaut ist. Man darf sich diese Format aber jetzt nicht wie das Binärformat für "normalen" x86 Programmcode vorstellen. Das Binärformat entspricht eher dem Bytecode von Java oder MSIL von .Net. Eine GPU kann also nicht direkt etwas damit anfangen. Der Treiber muss als Umsetzer einspringen und je stärker das Ausgangsmaterial (Shaderbytecode) von der eigentlichen Chipstruktur abweicht desto aufwendiger wird das ganze für den Treiber. Aufgrund der geringen Komplexität der 1.1-1.3 Shader war das bisher kein grosses Problem da man die Hardware dafür gar nicht so unterschiedlich bauen konnte. Mit der zunehmenden Komplexität steigen aber auch die Möglichkeiten andere Wege bei der Implementierung einzuschlagen.

Seinen ureigenen Zweg (vereinheitlichung unterschiedlicher Hardware) erfüllt DX9 nach wie vor allerdings wird es komplizierter werden jeden Chip ideal zu nutzen wenn man darauf besteht Shader per Hand in der Shaderassemblersprache zu schreiben.

Salvee

2003-05-30, 13:02:05

Original geschrieben von seahawk
ATI hätte ja JAmern können - bzw. wenn ihre Hardware unfair benachteiligt wird jammern müssen imo.

Da kann ich dir nur zustimmen, auch wenn das Ganze dann in einen Jammer-Contest ausartet.
Bliebe festzuhalten: benachteiligende Benches sind ein alter Hut, die Messlatte an schmierigen Tricks, diese auszuhebeln, setzt ganz klar nV.

Black-Scorpion

2003-05-30, 13:11:07

Wenn es um den 03 geht, kommt mir NV wie ein kleines Kind vor.
Die reagieren auch trotzig wenn man ihnen ihr Lieblingsspielzeug wegnimmt. ;)

Gästle

2003-05-30, 13:26:00

Original geschrieben von Salvee
Demirug hat den Codecraetures bench bereits kritisiert und als 'seltsam' abgetan. Das kann man ihm also nicht vorwerfen imho.
Es gibt aber noch extremere Beispiele für Benchmarks, die fröhlich von allen möglichen 'Dau-Reviewern' benutzt wurden (allerdings OGL), als da wären
1. Dronez
2. Vulpine GL Mark

Hat nV sich damals beschwert oder gejammert? -> Nope
Haben sie diese Benches verloren ? -> Nope
Den Rest kann man sich denken ...

Ich wollte eigentlich auch nicht direkt demirug ansprechen, das war mehr so in die Richtung Razor etc. gerichtet, die die Auseinandersetzung immer gern sehr einseitig sehen.

AlfredENeumann

2003-05-30, 14:51:36

Original geschrieben von Razor
Eine Wischi-Waschi-Aussage die aber auch rein gar keinen Gehalt hat. Der Source-Code muss offen gelegt werden, um zu belegen, dass dem tatsächlich nicht so ist. Wenn für ATI günstig und für nVidia ungünstig gecodet wurde ist dieser Bench unbrauchbar. Und nicht nur das... solte sich heraus stellen, dass dem tatsächlich so ist, dann dürften sogar einige Schadensersatzklagen auf FM zukommen...

Klar, dass sie sich gegen solche Vorwürfe wehren müssen.
IMO läuft das Ganze auf einen Rechtsstreit hinaus...
(wenn der Murks nicht von alleine verschwindet ;-)

Na Klar. Sonst geht´s noch oder was ?
Dann sollten wir estmal alle Benchproggis überprüfen, ob die nicht nach NV-Performance-Guides Programmiert sind um nicht ATI zu benachteiligen, oder ?

Klar, ein verschwindener Drache ein Cheat.

Ne, aber ein Merkmal für fähige Treiberprogrammierer.

AlfredENeumann

2003-05-30, 14:53:43

Original geschrieben von Razor
Näturlich können sie was dafür...

Schließlich schreiben Sie sich auf die Fahne unabhängig zu sein. Und wenn sie dieses verfehlt haben ist dieser Murks unbrauchbar (wer auch immer daran 'schuld' sein mag ;-).

Das ist doch alles Mist was du da verzapfst.
FM hat sich an Standard M$ Code gehalten. Neutraler gehts doch gar nicht mehr.

AlfredENeumann

2003-05-30, 14:56:28

Original geschrieben von Razor
Wenn ich Dich richtig verstanden habe, dann wusste FM aber zumindest auf Besis der Guidelines von nVidia, dass die PS1.4 'schlecht' waren. Und warum sollte nVidia aus dem Beta-Programm ausgestiegen sein, wenn dort nicht etwas vorgefallen wäre, weilches eine Entscheidung solch einer Tragweite rechtfertigte...

Guidelinies irgendwelcher Hersteller sind unwichtig Razor!!! Es soll doch neutral sein!!! Selbst du plädierst doch dafür!!! Also interessiert es keine Sau was irgendwelche Guidelines sagen.

AlfredENeumann

2003-05-30, 15:03:41

Original geschrieben von LovesuckZ
kannst du das auch beweisen?

http://www.computerbase.de/article.php?id=52&page=4#3dmark2000
http://www.computerbase.de/article.php?id=52&page=6#3dmark2001

http://www.computerbase.de/article.php?id=49&page=9#3dmark_2000
http://www.computerbase.de/article.php?id=49&page=12#3dmark_2001

ich sehe nicht, wo Nvidia hier so deutlich ueberlegen ist...

Hmmm. 01er erschien rein zufällig mit den GF3 Karten und rein zufällig war es die einzige Karte damals nach DX8. Auf welcher Karte wurde das ding wohl entwickelt?
Das ist natürlich kein Beweis aber höchst verdächtig, oder ?

Demirug

2003-05-30, 15:34:20

Original geschrieben von AlfredENeumann
Das ist doch alles Mist was du da verzapfst.
FM hat sich an Standard M$ Code gehalten. Neutraler gehts doch gar nicht mehr.

Ich fürchte ich habe mich da nicht klar ausgedrückt. Meine Schuld.

MS selbst macht bezüglich der optimalen Programmierung eines Pixelshaders aus der Sicht der Performance keine Angaben. Die Dokumentaion enthält lediglich eine Beschreibung der Instruktionen und Register und der Einschränkungen die es gibt.

Die einzigen Dokumente welche etwas über das Programmieren von PS >=2.0 unter Berüksichtigung der Performance aussagen kommen von ATI und nv. ATI erzählt dort eine ganze Menge was man berücksichtigen soll und sagt dann in einem Nebensatz das der MS-HLSL Compiler aber zum grössten Teil das alles genau so machen würde. nv erzählt nun ganz andere Dinge und endet bei jeder Folie zu dem Thema mit "oder benutzten sie Cg".

betasilie

2003-05-30, 15:50:12

Original geschrieben von Demirug
nv erzählt nun ganz andere Dinge und endet bei jeder Folie zu dem Thema mit "oder benutzten sie Cg".
Und wenn FM Cg benutzt hätte, wäre die Sache noch ungrechter.

Black-Scorpion

2003-05-30, 15:55:57

Original geschrieben von betareverse
Und wenn FM Cg benutzt hätte, wäre die Sache noch ungrechter.

Aber NV hätte keinen Grund gehabt sich zu beschweren.
Nicht auszudenken wenn der NV30 dann auch so schlecht abgeschnitten hätte.

StefanV

2003-05-30, 15:57:57

Original geschrieben von betareverse
Und wenn FM Cg benutzt hätte, wäre die Sache noch ungrechter.

...nur hätte dann keine Sau rumgeheult, das wäre der Unterschied...

Einige sind doch erst mit 'ach, der 3Dmark ist doch scheiße' gekommen, als abzusehen war, daß 'ihre' Firma dabei richtig abkackt, das das vorher andersrum genauso war, das scheinen sie zu vergessen (3DFX, PowerVR)...

Um ehrlich zu sein, finde ich nVs Verhalten einfach nur erbärmlich!!

Exxtreme

2003-05-30, 15:59:06

Original geschrieben von Stefan Payne

Um ehrlich zu sein, finde ich nVs Verhalten einfach nur erbärmlich!!
Dito. :)

AlfredENeumann

2003-05-30, 16:09:24

*anschließ*

seahawk

2003-05-30, 18:36:21

Original geschrieben von AlfredENeumann
Hmmm. 01er erschien rein zufällig mit den GF3 Karten und rein zufällig war es die einzige Karte damals nach DX8. Auf welcher Karte wurde das ding wohl entwickelt?
Das ist natürlich kein Beweis aber höchst verdächtig, oder ?

Hm der 2003 erschein zeitnah mit dem R300. Auf welcher KArte wurde er wohl entwickelt ?? Das ist natürlich kein Beweis aber höchst verdächtig, oder ??

AlfredENeumann

2003-05-30, 19:32:46

Original geschrieben von seahawk
Hm der 2003 erschein zeitnah mit dem R300. Auf welcher KArte wurde er wohl entwickelt ?? Das ist natürlich kein Beweis aber höchst verdächtig, oder ??

der 03er kam später. er konnte ja erst releast werden als DX9 aus der Betaphase raus war und der NV-Chip hätte fertig sein müssen.

seahawk

2003-05-30, 19:39:26

der 2001 kam auch erst als DX 8 aus der Betaphase raus war und der ATI Chip hätte fertig sein müssen.

-> Ist ne unsinnige Idee daraus irgendetwas abzuleiten.

Razor

2003-05-30, 19:52:18

Original geschrieben von Gästle
Ich wollte eigentlich auch nicht direkt demirug ansprechen, das war mehr so in die Richtung Razor etc. gerichtet, die die Auseinandersetzung immer gern sehr einseitig sehen.
Könntest Du das mal näher ausführen ?
???

Razor

Razor

2003-05-30, 19:53:57

Original geschrieben von AlfredENeumann
Na Klar. Sonst geht´s noch oder was ?
Aber klaro !
:D
Original geschrieben von AlfredENeumann
Dann sollten wir estmal alle Benchproggis überprüfen, ob die nicht nach NV-Performance-Guides Programmiert sind um nicht ATI zu benachteiligen, oder ?
Du scheinst Dich hier im Thema 'etwas' verheddert zu haben, oder ?
;-)
Original geschrieben von AlfredENeumann
Ne, aber ein Merkmal für fähige Treiberprogrammierer.
Wenn Du meinst.

Razor

Razor

2003-05-30, 19:55:12

Original geschrieben von AlfredENeumann
Das ist doch alles Mist was du da verzapfst.
FM hat sich an Standard M$ Code gehalten. Neutraler gehts doch gar nicht mehr.
Sie haben den Murks offenbar zu früh released und das, was dabei heraus gekommen ist, hat offensichtlich das Ziel verfehlt. M$ hat dies eingesehen, FM noch nicht.

Aber sonst geht's Dir noch gut ?
:D

Razor

Razor

2003-05-30, 19:59:46

Original geschrieben von AlfredENeumann
Guidelinies irgendwelcher Hersteller sind unwichtig Razor!!! Es soll doch neutral sein!!! Selbst du plädierst doch dafür!!! Also interessiert es keine Sau was irgendwelche Guidelines sagen.
Nochmal: Zieh Dir den jetzigen Diskussionsfaden rein !
Wenn Du des Lesens mächtig bist, dann solltest auch Du gemerkt haben, dass das, was da von FM gekommen ist, KEINESWEGS neutral ist, wenn sie den M$-Compiler benutzt haben. M$ hat dies/wird dies korrigieren. Und wenn FM nachzieht und diesen Fehler ebenfalls korrigiert und damit wieder eine gleiche Aufgangslage für beide Chiparchtitekturen schafft, ist ja auch alles OK. Derzeit wird vermutlich die eine bevorzugt...

Offenbar gibt es derzeit KEINE Möglichkeit, DX9 (i.e. dessen Shader-Leistung) 'neutral' zu beurteilen.
Ich bitte Dich wirklich ernsthaft darum, mal dem derzeitigen Diskussionsfaden zu folgen...
(Deine Kommentare sind... gelinde ausgedrückt... OT)

Razor

Razor

2003-05-30, 20:01:12

Original geschrieben von betareverse
Und wenn FM Cg benutzt hätte, wäre die Sache noch ungrechter.
Nicht, wenn sie beides benutzt hätten...
Oder auf einen M$-Compiler gewartet hätten, der mehrere Zielpfade unterstützt.
(wie ja jetzt geschehen ;-)

Razor

Razor

2003-05-30, 20:02:40

Original geschrieben von Anonym_001
Aber NV hätte keinen Grund gehabt sich zu beschweren.
Nicht auszudenken wenn der NV30 dann auch so schlecht abgeschnitten hätte.
Möglicherweise hat nVidia dann keinen Grund mehr, zu cheaten...
Aber das werden wir erst wissen, wenn es soweit ist und der Murks tatsächlich unter gelichen Voraussetzungen bencht.

Schaun' wir mal.

Razor

Razor

2003-05-30, 20:08:16

Original geschrieben von Stefan Payne
...nur hätte dann keine Sau rumgeheult, das wäre der Unterschied...

Einige sind doch erst mit 'ach, der 3Dmark ist doch scheiße' gekommen, als abzusehen war, daß 'ihre' Firma dabei richtig abkackt, das das vorher andersrum genauso war, das scheinen sie zu vergessen (3DFX, PowerVR)...

Um ehrlich zu sein, finde ich nVs Verhalten einfach nur erbärmlich!!
'Erbärmlich' ?
Du jast offenbar nicht die geringste Ahnung, welche Stellenwert der Murks derzeit hat(te).
Früher war das zeimlich wurscht, heute wird das Ding als Industrie-Bench vermarktet...

Und wenn Du diesen Schrott auch weiterhin wiederholst.

Viele haben auch vorher schon versucht die Leuts davon zu überzeugen, dass so etwas wie der Murks wenn überhaupt nur für Vergleiche im eigenen System bei Grafikkarten des gleichen Herstellers zu gebruachen ist (so wie meine Wenigkeit !), aber für nichts anderes.

Du hast selber damals lauthals rumgeschrieen und Dich ebenfalls über den Murks beklagt (die 'Musik' war schlecht, aber inhaltlich war's korrekt ;-). Und jetzt erzählst Du uns, dass man den Murks akzeprieren solle, wie er ist, obwohll die Ursache der Ungleichbehandlung gefunden zu sein scheint ?

Nochmal Payne: Ist der Murks nun schrott, oder nicht ?
Zählt Deine damalige Meinung oder hast Du Dich nun um 180° gedreht ?
???

Razor

Razor

2003-05-30, 20:09:07

Original geschrieben von AlfredENeumann
der 03er kam später. er konnte ja erst releast werden als DX9 aus der Betaphase raus war und der NV-Chip hätte fertig sein müssen.
Ahhhh... stimmt ja...
Der R300 war ja ein DX9-Chip ohne DX9 !
:D

Razor

Exxtreme

2003-05-30, 20:35:55

Razor,

Original geschrieben von Razor

Wenn Du des Lesens mächtig bist, dann solltest auch Du gemerkt haben, dass das, was da von FM gekommen ist, KEINESWEGS neutral ist, wenn sie den M$-Compiler benutzt haben. M$ hat dies/wird dies korrigieren. Und wenn FM nachzieht und diesen Fehler ebenfalls korrigiert und damit wieder eine gleiche Aufgangslage für beide Chiparchtitekturen schafft, ist ja auch alles OK. Derzeit wird vermutlich die eine bevorzugt...

Razor

dir ist wohl gar nicht bewusst, warum M$ überhaupt ein NV3x-freundliches Profil integriert, oder? ;)
Es ist wohl eine politische Entscheidung. M$ macht sowas nicht um NV einen Gefallen zu tun.

Damals als der 3DMark rauskam, war das, was FM veröffentlichte, neutral. :)

Die bei FM konnten ja auch nicht wissen, daß der NV30 so schlecht abschneidet. Und was anderes als den M$-Shader-Compiler hatten sie ja auch nicht. Hätten sie CG verwendet, würde es erst recht heissen, daß sie auf einen GraKa-Hersteller optimieren und nicht neutral sind.

FM steckte in einer Zwickmühle. Sie haben sich wohl für das geringere Übel entschieden.

Exxtreme

2003-05-30, 20:46:56

Original geschrieben von Razor
Nicht, wenn sie beides benutzt hätten...
Oder auf einen M$-Compiler gewartet hätten, der mehrere Zielpfade unterstützt.
(wie ja jetzt geschehen ;-)

Razor
Wie gesagt, sie hätten nicht wissen können, daß der M$-Shader-Compiler einen ATi-freundlichen Shader-Code erzeugt und sie hätten auch nicht wissen können, daß M$ einen Compiler mit mehreren Zielpfaden anbietet. Glaskugeln funktionieren leider immer noch nicht. ;)

Beim DX9-Beta-Test ist einiges nicht so gelaufen, wie es normalerweise ablaufen sollte.

Razor

2003-05-30, 20:57:24

Original geschrieben von Exxtreme
dir ist wohl gar nicht bewusst, warum M$ überhaupt ein NV3x-freundliches Profil integriert, oder?
Es ist wohl eine politische Entscheidung. M$ macht sowas nicht um NV einen Gefallen zu tun.
Sondern ?
Original geschrieben von Exxtreme
Damals als der 3DMark rauskam, war das, was FM veröffentlichte, neutral.
Klar, gab ja auch nur eine einzige DX9-Archtitektur...
:D
Original geschrieben von Exxtreme
Die bei FM konnten ja auch nicht wissen, daß der NV30 so schlecht abschneidet. Und was anderes als den M$-Shader-Compiler hatten sie ja auch nicht. Hätten sie CG verwendet, würde es erst recht heissen, daß sie auf einen GraKa-Hersteller optimieren und nicht neutral sind.
Ich denke schon dass sie sogar genau wussten, wie schlecht nVidia abschneiden würde...
Warum sollte sonst nVidia ausgetreten sein ?

Und klar, lieber den M$-Compiler only benutzen, als für beide Architekturen eine gemeinsame Ausgangsbasis zu schaffen.

Und noch einmal, sie müssen sich JETZT die einseitige Bevorzugung vorwerfen lassen, weil sie es NICHT getan hatten ! Bitte nicht die Tatsachen verdrehen...
Original geschrieben von Exxtreme
FM steckte in einer Zwickmühle. Sie haben sich wohl für das geringere Übel entschieden.
Sie haben sich schilcht so oder so falsch entschieden. Und JETZT stecken sie in einer Zwickmühle, die durchaus dazu führen könnte, dass sie jegliche Reputation verlieren...

Und immer noch unter der Voraussetzung, dass die wirklich den M$-Complier nutzten...
;-)

Razor

Exxtreme

2003-05-30, 21:02:13

Original geschrieben von Razor
Sondern ?

CG soll angeblich 3D-API-unabhängig sein. Und jetzt zähl mal eins und eins zusammen. :)

Was fürchtet M$ z.Zt. am meisten?

Original geschrieben von Razor
Und noch einmal, sie müssen sich JETZT die einseitige Bevorzugung vorwerfen lassen, weil sie es NICHT getan hatten ! Bitte nicht die Tatsachen verdrehen...

Und:
Original geschrieben von Razor
Sie haben sich schilcht so oder so falsch entschieden. Und JETZT stecken sie in einer Zwickmühle, die durchaus dazu führen könnte, dass sie jegliche Reputation verlieren...

Und immer noch unter der Voraussetzung, dass die wirklich den M$-Complier nutzten...
;-)

Razor
Überleg mal was passieren würde, wenn FM Cg verwenden würde?

Demirug

2003-05-30, 21:02:35

Razor

2003-05-30, 21:04:43

Original geschrieben von Exxtreme
Wie gesagt, sie hätten nicht wissen können, daß der M$-Shader-Compiler einen ATi-freundlichen Shader-Code erzeugt und sie hätten auch nicht wissen können, daß M$ einen Compiler mit mehreren Zielpfaden anbietet. Glaskugeln funktionieren leider immer noch nicht. ;)
Ich denke, dass nVidia sie darauf 'aufmerksam' gemacht hat, FM darauf aber nicht reagierte...
M$ hat sich mittlerer Weile überzeugen lassen, FM (noch) nicht.

DAS müssen sie dringend nachholen, denn noch können sie reagieren (das neue SDK ist ja noch nicht offiziell ;-). Wenn also bei Verfügbarkeit des neuen SDK's eine neue Murks-version erscheint, die die unterschiedlichen Architekturen berücksichtigt, dann hat FM IMO noch eine Chance. Und bis dahin sollte der Bench auch keinesfalls genutzt werden (wie ja bereits von diversen Sites angekündigt).
Original geschrieben von Exxtreme
Beim DX9-Beta-Test ist einiges nicht so gelaufen, wie es normalerweise ablaufen sollte.
Was aber nicht heißt, dass man sich auf die alten Kamellen stützen sollte.
Ganz im Gegenteil, sollte man auf Veränderungen flexibel reagieren, wenn es dafür einen Grund gibt.

Aber klar, für FM dürfte es schwierig sein, zuzugeben, dass alle bisherigen Ergebnisse schlicht unbrauchbar sind, da Vergleiche mit einseitiger, wenn auch unbeabsichtigter, Optimierung einer bestimmten Architektur einher gingen.

Wie gesagt, im Prinzip müssten sie nVidia's Vorwüfen entsprechen.
Nur ob das jetzt noch möglich ist ?
Hmmm...

Razor

Razor

2003-05-30, 21:06:03

Original geschrieben von Exxtreme
CG soll angeblich 3D-API-unabhängig sein. Und jetzt zähl mal eins und eins zusammen. :)

Was fürchtet M$ z.Zt. am meisten?
Nüscht... sie integrierten den cg-compiler einfach ins SDK !
:D
Original geschrieben von Exxtreme
Und:

Überleg mal was passieren würde, wenn FM Cg verwenden würde?
Vermutlich wird es egal sein, ob sie cg oder den neuen M$-Compiler benutzen...

Razor

Demirug

2003-05-30, 21:09:56

Original geschrieben von Exxtreme
CG soll angeblich 3D-API-unabhängig sein. Und jetzt zähl mal eins und eins zusammen. :)

Was fürchtet M$ z.Zt. am meisten?

Ja Cg ist im Prinzip API unabhängig allerdings kümmert sich Cg wirklich nur um die Shader den ganzen rest drumherum muss man immer noch selber machen. Zudem gibt es für DX 8, DX 9 und OpenGL jeweils speziale ergänzungs APIs. Unter OpenGL ist Cg derzeit aber nur wirklich sinnvoll bei NV oder DX9-Level Karten zu benutzten.

Exxtreme

2003-05-30, 21:16:52

Original geschrieben von Razor
Nüscht... sie integrierten den cg-compiler einfach ins SDK !
:D

Nicht wirklich. ;)

Stell dir mal vor, was passiert wäre wenn M$ dieses NV3x-Profil nicht eingebaut hätte.

Richtig, NV hätte durch vieeel Marketing und kleinen Zuwendungen wie Geldspritzen die Entwickler dazu gebracht, nur noch mit CG zu entwickeln und den M$-Shader-Compiler nicht mehr zu verwenden. Wenn sie gaaaanz fies wären, dann hätten sie auch noch gesagt: Vergesst DX und nehmt lieber OpenGL.

Und jetzt die Preisfrage:
Welche extrem grosse Einschränkung hat DX ggü. OpenGL?

Und dann nochmal die Frage: Was fürchtet M$ z.Zt. am meisten? Kleiner Tipp am Rande: München. :)
Original geschrieben von Razor
Vermutlich wird es egal sein, ob sie cg oder den neuen M$-Compiler benutzen...

Razor
Jetzt vermutlich ja.

Eigentlich trägt M$ die Schuld an der jetzigen Situation... IMHO.

Mr. Lolman

2003-05-30, 21:18:14

Original geschrieben von Razor

Sie haben sich schilcht so oder so falsch entschieden. Und JETZT stecken sie in einer Zwickmühle, die durchaus dazu führen könnte, dass sie jegliche Reputation verlieren...

Und immer noch unter der Voraussetzung, dass die wirklich den M$-Complier nutzten...
;-)

Razor

Ich glaube nicht, das diese Sache grosse Auswirkungen auf FMs Reputation haben wird. Wenn überhaupt, dann eher auf die von NVidia.

FM war im Zeitdruck. Der 3dmark2001 war durch die neuen schnellen GraKas fast ausschliesslich CPU limitiert. Nicht gut, für einen Grafikkartenbenchmark. 2002 wurde sowieso ausgelassen, da es in dem Jahr keine Basis für einen DX9 Benchmark gab.
Die Radeon 9700pro erschien. DX9 gab es noch nicht. die NV30 auch noch nicht. Der 3dmark2001 wurde immer weniger repräsentativ. Dann kam DX9 und FM arbeitete mit Hochdruck am 3dmark2003.
Kein NV30, keine Betaversionen an NV, nur ATi Karten gabs.

Zudem nutzte man anscheinend den M$ Kombiler (der ATi freundlichen Code auspuckt, warum auch immer :stareup: ) und als der NV30 endlich erschien, musste jeder merken, dass dessen PS2.0 Shader nicht das Gelbe vom Ei waren.

Ein Treiber von NV wurde nachgeschoben, und plötzlich konnte der NV30 mit dem R300 konkurrieren. Die Bildqualität wurde zwar etwas schwächer, aber das war sowieso ein Fehler von Futuremark, da der verwendete PS 1.4 anscheinend genügend Raum für legale BQ verringerende, geschwindigkeitsverbessernde Optimierungsmassnahmen liess. So wurde dann auch eine Zeitlang gebencht. Mal NV schneller, mal ATi aber NV hatte immer die schlechtere BQ.

Manche Forenuser schrien 'CHEAT', aber kein Cheat wars. ATi Fanboy war man. Dann als FM selbst den Finger erhebt und sagt: Ja es stimmt -> 'CHEAT' ist plötzlich FM Scheisse und dem Untergang geweiht. Nicht der Cheater ist der Arsch, sondern der Programmierer der das 'Cheaten' in seinem Programm nicht im Vorhinein schon wirksam unterbinden konnte.

-> John Carmack du Penner. Du gehst jetzt hoffentlich Pleite, wegen dir nämlich, konnte man in Q3a cheaten !!! *scnr* ;)

Razor

2003-05-30, 21:29:41

Original geschrieben von Exxtreme
Jetzt vermutlich ja.

Eigentlich trägt M$ die Schuld an der jetzigen Situation... IMHO.
M$ wird auch eine Teilschuld mittragen.
Wenn aber FM diesen Sachverhalt trotz nVidia's Einwendungen ignorierte , sind sie ebenso schuldig.

Aber klar, ich würde nicht soweit gehen, FM die alleinige Schuld zuzuschreiben, wenn (ja wenn ;-) sie den M$-Compiler nutzten.

Razor

P.S.: Zu dem Rest Deines Posts solltest Du genauer werden, denn so verschließt sich mir der Sinn dessen...
:D

Demirug

2003-05-30, 21:34:41

Original geschrieben von Exxtreme
Nicht wirklich. ;)

Stell dir mal vor, was passiert wäre wenn M$ dieses NV3x-Profil nicht eingebaut hätte.

Richtig, NV hätte durch vieeel Marketing und kleinen Zuwendungen wie Geldspritzen die Entwickler dazu gebracht, nur noch mit CG zu entwickeln und den M$-Shader-Compiler nicht mehr zu verwenden. Wenn sie gaaaanz fies wären, dann hätten sie auch noch gesagt: Vergesst DX und nehmt lieber OpenGL.

Und jetzt die Preisfrage:
Welche extrem grosse Einschränkung hat DX ggü. OpenGL?

Wenn du jetzt auf die fehlende portierbarkeit anspielst so muss ich dich etwas enttäuschen. Auf dem Mac laufen DirectX-Programme und wenn ein paar Linux Jungs wirklich wollten könnte es auch dort laufen.

Jetzt vermutlich ja.

Eigentlich trägt M$ die Schuld an der jetzigen Situation... IMHO.

Selbst wenn MS damals schon den entsprechenden Compiler zur verfügung gestellt hätte muss ich mich aber fragen ob FM wirklich Chipabhängig zur Laufzeit compiliert hätte.

PS: Einer von den MS D3D Leuten machte Andeutungen bezüglich weiteren "target profiles" wie vs/ps_2_b.

Exxtreme

2003-05-30, 21:38:42

Original geschrieben von Razor
M$ wird auch eine Teilschuld mittragen.
Wenn aber FM diesen Sachverhalt trotz nVidia's Einwendungen ignorierte , sind sie ebenso schuldig.

Aber klar, ich würde nicht soweit gehen, FM die alleinige Schuld zuzuschreiben, wenn (ja wenn ;-) sie den M$-Compiler nutzten.

Razor

Ich denke, daß M$ am meisten Schuld trägt. Sie haben eine, im Nachhinein unfertige Beta-Version als Final deklariert. FM konnte deswegen davon ausgehen, daß sich kaum noch was ändert.
Original geschrieben von Razor
P.S.: Zu dem Rest Deines Posts solltest Du genauer werden, denn so verschließt sich mir der Sinn dessen...
:D
München. (http://www.heise.de/newsticker/data/anw-28.05.03-004/) :)

Tja, das ist ein Gegner, den M$ nicht so ohne Weiteres wegkaufen, wegklagen oder vom Markt fegen kann. :)
Und deshalb ist es so gefürchtet bei M$.

Und jetzt stell dir vor, NV hilft nach, daß die Entwickler sich OpenGL zuwenden. :)

AlfredENeumann

2003-05-30, 21:42:01

Original geschrieben von Razor
Nochmal: Zieh Dir den jetzigen Diskussionsfaden rein !
Wenn Du des Lesens mächtig bist, dann solltest auch Du gemerkt haben, dass das, was da von FM gekommen ist, KEINESWEGS neutral ist, wenn sie den M$-Compiler benutzt haben.

Fakt ist als der Murks rauskam war das damalige Dx9 mit Compiler aktueller Stand. Daher neutral. Basta.

Exxtreme

2003-05-30, 21:42:24

Original geschrieben von Demirug
Wenn du jetzt auf die fehlende portierbarkeit anspielst so muss ich dich etwas enttäuschen. Auf dem Mac laufen DirectX-Programme und wenn ein paar Linux Jungs wirklich wollten könnte es auch dort laufen.

Tja, und diese Einschränkung hat openGL eben nicht. :)

Damit würde ein richtiges Killerargument für Windows wegfallen.

Deswegen denke ich, daß es eine strategische Entscheidung war, solche Profile einzubauen.
Original geschrieben von Demirug
Selbst wenn MS damals schon den entsprechenden Compiler zur verfügung gestellt hätte muss ich mich aber fragen ob FM wirklich Chipabhängig zur Laufzeit compiliert hätte.

Tja, das weiss wohl niemand. Aus deinem Posting schliesse ich, daß sie damals kaum die Möglichkeit dazu hatten.

AlfredENeumann

2003-05-30, 21:43:43

Original geschrieben von Razor
M$ hat dies/wird dies korrigieren. Und wenn FM nachzieht und diesen Fehler ebenfalls korrigiert und damit wieder eine gleiche Aufgangslage für beide Chiparchtitekturen schafft, ist ja auch alles OK. Derzeit wird vermutlich die eine bevorzugt...

Aha. Dann laß die bescheuerten Kommentare. Warte ab ob FM den Murks neu Compiliert. Dann darfst du mekern, vorher nicht.

AlfredENeumann

2003-05-30, 21:44:50

Original geschrieben von Razor
Nicht, wenn sie beides benutzt hätten...
Oder auf einen M$-Compiler gewartet hätten, der mehrere Zielpfade unterstützt.
(wie ja jetzt geschehen ;-)

Razor

NEIN !!!!

CG optimiert def. auf NV, der M$ Complier paßt nur besser zu ATI, ist aber nicht auf die ATI-Chips optimiert.

Kleiner Unterschied !!!

AlfredENeumann

2003-05-30, 21:45:51

Original geschrieben von Razor
Ahhhh... stimmt ja...
Der R300 war ja ein DX9-Chip ohne DX9 !
:D

Razor

?

Razor

2003-05-30, 21:48:34

Original geschrieben von Exxtreme
Ich denke, daß M$ am meisten Schuld trägt. Sie haben eine, im Nachhinein unfertige Beta-Version als Final deklariert. FM konnte deswegen davon ausgehen, daß sich kaum noch was ändert.
Trotz nVidia's Einwendungen ?
???
Original geschrieben von Exxtreme
München. (http://www.heise.de/newsticker/data/anw-28.05.03-004/) :)

Tja, das ist ein Gegner, den M$ nicht so ohne Weiteres wegkaufen, wegklagen oder vom Markt fegen kann. :)
Und deshalb ist es so gefürchtet bei M$.

Und jetzt stell dir vor, NV hilft nach, daß die Entwickler sich OpenGL zuwenden. :)
Thx for the Link...
Aber wie Demirug schon schrieb, wenn man wollte, dann könnte DirectX auch unter Liunx...

nVidia kann es herzlich egal sein, was die Entwickler verwenden, wenn der M$-Compiler das gleiche Ergebnis liefert, wie es auch cg tut. Wenn sich aber jetzt die Entwickler zunehmend cg zuwenden, welches ja wohl code für jede Chip-Architektur liefert, dann ist das natürlich umso besser für nVidia.

Nur frage ich mich ernsthaft, was das jetzt mit dem FM-Prob' zu tun hat...
:D

Razor

Razor

2003-05-30, 21:50:04

Original geschrieben von AlfredENeumann
Fakt ist als der Murks rauskam war das damalige Dx9 mit Compiler aktueller Stand. Daher neutral. Basta.
Deine Meinung, nicht meine...
Offensichtlich gab es schon damals Einwendungen, die von FM ignoriert wurden.
M$ hat bereits reagiert und wird einen diesbezüglichen Fehler korrigieren.

Und das sollte FM nun auch tun, oder etwa nicht ?
???

Razor

StefanV

2003-05-30, 21:50:06

Original geschrieben von Razor
nVidia kann es herzlich egal sein, was die Entwickler verwenden, wenn der M$-Compiler das gleiche Ergebnis liefert, wie es auch cg tut. Wenn sich aber jetzt die Entwickler zunehmend cg zuwenden, welches ja wohl code für jede Chip-Architektur liefert, dann ist das natürlich umso besser für nVidia.

Ahso, und was machen wir mit den ganzen ATI Usern??

Erschießen??

Demirug

2003-05-30, 21:50:07

Original geschrieben von Exxtreme
Tja, und diese Einschränkung hat openGL eben nicht. :)

Dafür gibt es andere aber das ist jetzt hier wirklich offtopic.

Damit würde ein richtiges Killerargument für Windows wegfallen.

Noch ist die Gefahr von Cg und OpenGL für MS nicht so gross. Ich schätze OpenGL 2.0 gefährlicher ein.

Deswegen denke ich, daß es eine strategische Entscheidung war, solche Profile einzubauen.

Strategisch war diese Entscheidung sicherlich für mich kam sie allerdings zu spät. Aber ist nicht jede Entscheidung irgendwie strategisch?

Tja, das weiss wohl niemand. Aus deinem Posting schliesse ich, daß sie damals kaum die Möglichkeit dazu hatten.

Es hätte einen weg gegeben. ;)

Razor

2003-05-30, 21:51:26

Original geschrieben von AlfredENeumann
NEIN !!!!

CG optimiert def. auf NV, der M$ Complier paßt nur besser zu ATI, ist aber nicht auf die ATI-Chips optimiert.

Kleiner Unterschied !!!
Was wo nachzulesen ist ?
Auf welche Chips soll der erste Versuch vom M$ denn sonst optimiert sein ?
Auf Chips, die noch gar nicht existieren ?
???

Also ehrlich...

Razor

Razor

2003-05-30, 21:52:44

Original geschrieben von Stefan Payne
Ahso, und was machen wir mit den ganzen ATI Usern??

Erschießen??
Wenn Du meinst...
Was willst Du uns jetzt mit diesem Post sagen ?
???

Razor

AlfredENeumann

2003-05-30, 21:53:41

StefanV

2003-05-30, 21:54:20

Original geschrieben von Razor
Was wo nachzulesen ist ?
Auf welche Chips soll der erste Versuch vom M$ denn sonst optimiert sein ?
Auf Chips, die noch gar nicht existieren ?
???

Also ehrlich...

Razor

Sag mal, meinst du nicht, daß es NVs Problem ist, wenn sie die ganze Zeit pennen und nicht in der Lage sind, eine einigermaßen funzende Testplattform in Richtung Redmond zu schicken??

Zumal der NV30 ja laut einigen ja angeblich schon fast ein Jahr fertig gewesen sein soll...

2003-05-30, 21:56:56

Original geschrieben von AlfredENeumann
Auf keine. Stell dir mal vor wer alles an den DX9 Specs beteiligt war.

Das kann nicht sein.
Jeder Compiler optimiert auf die Hardware, auf der der Zielcode laufen soll.
Und hier hat wohl die ATI-Architektur bei MS Compiler-Entwicklung Pate gestanden.

AlfredENeumann

2003-05-30, 21:57:39

So. FMs Statement nochmal. Ich habe mal so ein paar stellen markiert.

Futuremark replies Posted Tuesday, May 27 by nzaweird
We had a chance to get the follow up remarks of Tero Sarkkinen's, Executive Vice President of Sales and Marketing at Futuremark, regarding the recent claims of Nvidia.

HardAve: In light of the recent struggles between your 3DMark2003 and Nvidia's driver set, we would like to hear your remarks regarding Nvidia's claims your software intentionally put the GeforceFX product in bad light after Nvidia passed on the opportunity in becoming a beta program partner of Futuremark's. On top of this, with the new 330 patch, it appears 3DMark2003 is the only benchmark showing the GeforceFX 5900Ultra well behind the competition, where other apps like UT2003 and Doom3 showcase the exact opposite. Why is this?

Tero Sarkkinen: Any suggestion that Futuremark would intentionally penalize or favor any specific hardware in our products is absurd and NOT TRUE. And please note that we are not attacking here, we are just defending our product.

We are in the business of making objective benchmarks and we intend to keep it that way. We respect deeply our BETA members, which include the biggest in the industry, and they all have participated in the development of 3DMark03. NVIDIA themselves was an active member of the BETA program until December 2002.

NVIDIA's claim that "since they are not a beta partner, they do not get a chance to write shaders like they would with real applications developer" is irrelevant and to us it seems like an attempt to shift discussion to a different topic. The topic here is that the drivers special cased 3DMark03 and resulted in an incorrect score which made false representation of their products' performance in 3DMark03.

3DMark03 was developed strictly according to DirectX9 standard in very close cooperation with Microsoft and other BETA members. If hardware performs well 3DMark03, it performs well in all applications that use DirectX 9. Note that since 3DMark is designed to be an objective evaluation tool, it does _not_ include manufacturer-specific optimizations. This is why it is exceptionally well suitable for objective performance measurement.

Since we all now see how tempting it is to try to cheat in a benchmark, we have started to work with our partners in order to develop new structures and processes to weed out cheating and unfair play in all benchmarks. This is a business opportunity for us, since due to our role and position we are better suited to act in this role than e.g. game benchmark providers. We welcome all interested parties to work with us in this important initiative.

NVIDIA is an extremely capable company with great products. We welcome them to continue the competition in the hardware development with fair means.

In reply to your more specific question, 3DMark03 is a forward looking DirectX 9 benchmark. It stresses the hardware with workloads that will be typical of DirectX 9 games. Thus, hardware's performance in Unreal Tournament 2003 does not necessarily bear relation to that how that hardware will perform in DirectX 9 workloads, which make an extensive use of pixel and vertex shading. Doom 3 is not a published product yet but we have seen few reviews. Based on those reviews, it seems that in Doom 3 there are performance differences depending on which codepath is used for different hardware. Not much more can be said at this time, as the application is not ready and not available for public testing (although we very much would like to see it :)

Quelle: http://www.hardavenue.com/#newsitem1054020435,86380,

AlfredENeumann

2003-05-30, 21:58:38

Original geschrieben von ow
Das kann nicht sein.
Jeder Compiler optimiert auf die Hardware, auf der der Zielcode laufen soll.
Und hier hat wohl die ATI-Architektur bei MS Compiler-Entwicklung Pate gestanden.

Komisch ich habe immer gedacht das NV bei der Entwicklung der DX9-Specs ebenfalls beteiligt war. Was haben den die Typen dort gemacht? Etwa gepennt?

StefanV

2003-05-30, 21:59:31

Original geschrieben von ow
Das kann nicht sein.
Jeder Compiler optimiert auf die Hardware, auf der der Zielcode laufen soll.
Und hier hat wohl die ATI-Architektur bei MS Compiler-Entwicklung Pate gestanden.

...was aber wieder NVs Problem ist, war sowie deren Schuld, da sie mit dem NV30 einfach nicht fertig wurden...

Wenn M$ 'nen Lauffähigen NV30 gehabt hätte, dann sähe das ganze ev. ganz anders aus...

Razor

2003-05-30, 22:01:29

Original geschrieben von Mr. Lolman
Ich glaube nicht, das diese Sache grosse Auswirkungen auf FMs Reputation haben wird. Wenn überhaupt, dann eher auf die von NVidia.
Es hat bereits Auswirkungen auf den Murks...
Original geschrieben von Mr. Lolman
FM war im Zeitdruck. Der 3dmark2001 war durch die neuen schnellen GraKas fast ausschliesslich CPU limitiert. Nicht gut, für einen Grafikkartenbenchmark. 2002 wurde sowieso ausgelassen, da es in dem Jahr keine Basis für einen DX9 Benchmark gab.
Die Radeon 9700pro erschien. DX9 gab es noch nicht. die NV30 auch noch nicht. Der 3dmark2001 wurde immer weniger repräsentativ. Dann kam DX9 und FM arbeitete mit Hochdruck am 3dmark2003.
Kein NV30, keine Betaversionen an NV, nur ATi Karten gabs.
Also hat FM 'überhastet' reagiert...
Oder was willst Du uns damit sagen ?
Original geschrieben von Mr. Lolman
Zudem nutzte man anscheinend den M$ Kombiler (der ATi freundlichen Code auspuckt, warum auch immer) und als der NV30 endlich erschien, musste jeder merken, dass dessen PS2.0 Shader nicht das Gelbe vom Ei waren.
Komisch nur, dass nVidia schon vor Erscheinen aus dem Beta-Programm ausgestiegen ist.
Somit dürfte sehr wohl bekannt gewesen sein, wie sich das Ganze darstellen würde...
Original geschrieben von Mr. Lolman
Ein Treiber von NV wurde nachgeschoben, und plötzlich konnte der NV30 mit dem R300 konkurrieren. Die Bildqualität wurde zwar etwas schwächer, aber das war sowieso ein Fehler von Futuremark, da der verwendete PS 1.4 anscheinend genügend Raum für legale BQ verringerende, geschwindigkeitsverbessernde Optimierungsmassnahmen liess. So wurde dann auch eine Zeitlang gebencht. Mal NV schneller, mal ATi aber NV hatte immer die schlechtere BQ.
Soweit so gut.
Und die letzten Treiber haben noch einen druaf gesetzt und damit diese Diskussion ins rollen gebracht.
M$ hat einen neuen (noch inoffiziellen) Compiler nachgeschoben, der den Grund des Cheatings den Boden entzieht.

Nun ist FM an der Reihe...
(wenn, ja wenn... ;-)
Original geschrieben von Mr. Lolman
Manche Forenuser schrien 'CHEAT', aber kein Cheat wars. ATi Fanboy war man. Dann als FM selbst den Finger erhebt und sagt: Ja es stimmt -> 'CHEAT' ist plötzlich FM Scheisse und dem Untergang geweiht. Nicht der Cheater ist der Arsch, sondern der Programmierer der das 'Cheaten' in seinem Programm nicht im Vorhinein schon wirksam unterbinden konnte.
Wo wurde gesagt, dass es keine Cheaterei war ?
Wurde doch sehr schnell von allen Seiten belegt, dass dem so war.
???

IMO sollte man sich jetzt der Realität widmen und mal schaun', wie FM jetzt reagiert.
M$ hat vorgelegt und einen vermeintlichen Fehler korrigiert.

Auch wenn FM an der ursprünglichen Situation kaum Schuld tragen sollte (was ich nicht so ganz glaube ;-), müssen sie sich doch der jetzt vorherrschenden Situation stellen und reagieren. Tun sie dieses nicht, hat der Murks seine 'Unabhängigkeit' definitiv verloren und ist wohl nur noch dazu zu gebrauchen ATI-Karten untereinander zu vergleichen...

Bis denne

Razor

2003-05-30, 22:03:20

Original geschrieben von AlfredENeumann
Komisch ich habe immer gedacht das NV bei der Entwicklung der DX9-Specs ebenfalls beteiligt war. Was haben den die Typen dort gemacht? Etwa gepennt?

Ähm.....zwisdchen den Specs, was ein Chip können muss und der technischen Umsetzung dessen liegen WELTEN.
DX hat NIE vorgeschrieben, wie die Chips-Architektur auszusehen hat.

Razor

2003-05-30, 22:03:46

Original geschrieben von AlfredENeumann
Auf keine. Stell dir mal vor wer alles an den DX9 Specs beteiligt war.
Interessant nur, dass ATI selbst auf den M$-Compiler verweist, der ja alles für ATI-Chips 'optimal' umsetzen würde...
;-)

Razor

Exxtreme

2003-05-30, 22:04:15

Original geschrieben von AlfredENeumann
Komisch ich habe immer gedacht das NV bei der Entwicklung der DX9-Specs ebenfalls beteiligt war. Was haben den die Typen dort gemacht? Etwa gepennt? Glaube ich nicht. ;)
Ich denke, M$ hat DX9 verfrüht und unfertig veröffentlicht. Und da ATi früher die nötige HW hatte, wurden sie halt erstmal bevorzugt von M$. FM ihrerseits konnte nur das nehmen, was auf den Markt war, ohne die Tools eines GraKa-Herstellers zu berücksichtigen. Sonst müssten sie sich immer den Vorwurf gefallen lassen, daß sie für einzelne Hersteller optimieren und nicht neutral sind.

Razor

2003-05-30, 22:05:20

Original geschrieben von Stefan Payne
Sag mal, meinst du nicht, daß es NVs Problem ist, wenn sie die ganze Zeit pennen und nicht in der Lage sind, eine einigermaßen funzende Testplattform in Richtung Redmond zu schicken??

Zumal der NV30 ja laut einigen ja angeblich schon fast ein Jahr fertig gewesen sein soll...
Wie dem auch sei...
M$ hat die NV3x-Architektur nun in seinen Compilern berücksichtigt.
(warum auch immer dies vorher nicht geschah ;-)

Meinst Du nicht, das FM jetzt reagieren sollte ?
???

Und wie war noch gleich Deine Meinung zu den Murksen ?
Schrott oder nicht ?
:D

Razor

Demirug

2003-05-30, 22:05:59

Original geschrieben von AlfredENeumann
Auf keine. Stell dir mal vor wer alles an den DX9 Specs beteiligt war.

In den Specs steht wie gesagt nichts zu dem Thema Performance. Für einen Compiler spielt aber gerade dieser Punkt eine wichtige Rolle.

Technisch gesehen machte es auch keinen Sinn bei den 2.0 Shadern auf etwas anderes als ATI zu optimieren. Bei ATI hat man keine möglichkeit auf ein höheres Profil auszuweichen ergo muss man bei den R3xx Chips immer auf 2.0 zurückgreifen. Die anderen DX9 Chips die wahrscheinlich noch kommen werden haben alle einen 2.0+ Shadereinheit. Dort kann also auf etwas anderes als 2.0 ausgewichen werden.

MS hat alles dafür getan das man chipspezifische Shader ohne grossen Aufwand einsetzten kann ergo sollte man es auch tun.

Razor

2003-05-30, 22:06:14

StefanV

2003-05-30, 22:07:31

Original geschrieben von Razor
Interessant nur, dass ATI selbst auf den M$-Compiler verweist, der ja alles für ATI-Chips 'optimal' umsetzen würde...
;-)

Razor

Auf was sollen sie denn sonst verweisen??

cg geht ja wohl kaum und wenn sie schreiben würden 'Use ASsembler', dann würde ATI von diversen Entwicklern gekillt werden.

Razor, nenne mir bitte eine Alternative zum M$ Compiler, aus Sicht von ATI!!

Razor

2003-05-30, 22:08:45

StefanV

2003-05-30, 22:11:45

Original geschrieben von Razor
Wie dem auch sei...
M$ hat die NV3x-Architektur nun in seinen Compilern berücksichtigt.
(warum auch immer dies vorher nicht geschah ;-)

Meinst Du nicht, das FM jetzt reagieren sollte ?
???

Und wie war noch gleich Deine Meinung zu den Murksen ?
Schrott oder nicht ?
:D

Razor

1. wie soll ich bitteschön eine nicht existente HW unterstützen??
Soll man raten, wie sie funktioniert oder was??

2. warum sollte FM reagieren?
Meinst du, FM sollte sich jetzt noch den Arsch aufreißen, nur damit der 3Dmark auf der NV3x Serie besser läuft??

Ich frage dich an dieser Stelle:

Was ist mit den anderen Herstellern, die DX9 HW planen??

Soll FM für jeden dieser Hersteller einen eigenen Codepfad schreiben??

3. Razor, es ist schon interessant, daß DU den 3Dmark plötzlich so niedermachst, vorher hats dich überhauptnicht gejuckt, im Gegenteil...
Aber jetzt, da NV mal scheiße dasteht, scheint der 3Dmark scheiße zu sein...

Quasar

2003-05-30, 22:11:47

Original geschrieben von Stefan Payne
Auf was sollen sie denn sonst verweisen??

cg geht ja wohl kaum und wenn sie schreiben würden 'Use ASsembler', dann würde ATI von diversen Entwicklern gekillt werden.

Razor, nenne mir bitte eine Alternative zum M$ Compiler, aus Sicht von ATI!!

Es ging beim Verweisen um die Optimierungs-/Performance-Guidelines der IHVs. Normalerweise stehen dort jeweils eine Menge "do" und "don't", wenn ich da richtig informiert bin.

nV hat cg entwickelt, und verweist darauf.

ATi hat Rendermonkey als Plug-In für einige Modeller und verweist ansonsten auf den MS-Compiler, ohne es jedoch für nötig zu halten, spezifisch etwas zur Performance und der performancekritischen Programmierung "ihrer" Shader sagen zu müssen.

In meinen Augen ist das angesichts der Vergangenheit und der damals veröffentlichten Guidelines schon etwas merkwürdig, meinst du nicht auch?

StefanV

2003-05-30, 22:13:54

Original geschrieben von Razor
Die Frage stellt sich doch nun gar nicht mehr...
Auch nVidia kann jetzt sagen:
"Für D3D cg oder M$ verwenden... für den Rest halt nur cg !"
:D

Razor

War das 'ne Antwort auf meine Frage??

Ich denke eher nicht.

Also nochmal:

Was ist die Alternative zum M$ Compiler aus ATI Sicht, bitte beantworte mir diese Frage und weiche nicht aus.

Demirug

2003-05-30, 22:17:31

Original geschrieben von Quasar
Es ging beim Verweisen um die Optimierungs-/Performance-Guidelines der IHVs. Normalerweise stehen dort jeweils eine Menge "do" und "don't", wenn ich da richtig informiert bin.

nV hat cg entwickelt, und verweist darauf.

ATi hat Rendermonkey als Plug-In für einige Modeller und verweist ansonsten auf den MS-Compiler, ohne es jedoch für nötig zu halten, spezifisch etwas zur Performance und der performancekritischen Programmierung "ihrer" Shader sagen zu müssen.

In meinen Augen ist das angesichts der Vergangenheit und der damals veröffentlichten Guidelines schon etwas merkwürdig, meinst du nicht auch?

Kleine Korrekturen: ;)

Rendermonkey ist kein Plugin für Modeller sondern ein eigenständiges Programm. ATI möchte (irgendwann) noch Plug Ins bringen welche mit Rendermonky erstellte Effektfiles benutzten können.

Es gibt auch von ATI inzwischen ein paar Guidelines zur Performance der Pixelshadereinheit. Aber wie schon erwähnt verweist ATI gerne auf den HLSL Compiler von MS.

LovesuckZ

2003-05-30, 22:22:57

@Demirug
kann ein Entwickler Cg und den M$ Compiler gleichzeitig benutzen?

Demirug

2003-05-30, 22:33:35

Original geschrieben von LovesuckZ
@Demirug
kann ein Entwickler Cg und den M$ Compiler gleichzeitig benutzen?

Aus eigener Erfahrung kann ich das bestätigen. Unser Effektset Generator ist so aufgebaut das er jeden Compiler unterstützen kann welcher HLSL compatiblen Code versteht (die unterstützung von Compiler mit einem anderen Syntax ist auch möglich aber aufwendiger weil man dem Generator dann erst noch die Syntax beibringen muss). Bei Erzeugen der Effekte geben wir dann einfach an was der bevorzugte Compiler sein soll und das wars.Im Moment habe ich diese Auswahl des Compilers automatisch mit der Vendor ID verknüpft. Effektsets für Nvidia Karten werden mit Cg erstellt alle anderen bekommen den Code vom MS Compiler.

Razor

2003-05-30, 22:36:52

Original geschrieben von Stefan Payne
Soll FM für jeden dieser Hersteller einen eigenen Codepfad schreiben??
Wenn sie den Anspruch 'Unabhängigkeit' behalten wollen: Ja !
Original geschrieben von Stefan Payne
3. Razor, es ist schon interessant, daß DU den 3Dmark plötzlich so niedermachst, vorher hats dich überhauptnicht gejuckt, im Gegenteil...
Aber jetzt, da NV mal scheiße dasteht, scheint der 3Dmark scheiße zu sein...
Du verdrehst Dir die Tatsachen, wie Du es willst, oder ?
Was meinst Du eigentlich, warum ich schon IMMER Murks geschrieben habe ?
Weil ich den Schrott von den Zwiebel- oder jetzt FM-Jungens so toll fand ?

Du aber drehst Dich, wie ein Fähnchen im Winde: Damals hast Du den Murks verurteilt und jetzt verteidigst Du ihn.

Ja was denn nun ?

Dewegen nochmal meine Frage:
"Ist der Murks nun schrott oder nicht ?"
(und damit mein ich alle, von 99 zu 2003 !)

Razor

AlfredENeumann

2003-05-30, 23:32:38

Original geschrieben von ow
Ähm.....zwisdchen den Specs, was ein Chip können muss und der technischen Umsetzung dessen liegen WELTEN.
DX hat NIE vorgeschrieben, wie die Chips-Architektur auszusehen hat.

Nein das nicht. War ja prakisch immer umgekert (oder so ähnlich), aber wie konnte es dazu kommen das zwei so verschiedene Chipdesigns "erarbeitet" wurden, aber M$ sich nur für eine Variante entschieden hat, und DX9 so starkt nach diesem Desing beendet hat.

AlfredENeumann

2003-05-30, 23:34:39

Original geschrieben von Razor
Interessant nur, dass ATI selbst auf den M$-Compiler verweist, der ja alles für ATI-Chips 'optimal' umsetzen würde...
;-)

Razor

Auf welchen den sonst? Etwa cg? :lol:

AlfredENeumann

2003-05-30, 23:35:27

Original geschrieben von Exxtreme
Glaube ich nicht. ;)
Ich denke, M$ hat DX9 verfrüht und unfertig veröffentlicht. Und da ATi früher die nötige HW hatte, wurden sie halt erstmal bevorzugt von M$. FM ihrerseits konnte nur das nehmen, was auf den Markt war, ohne die Tools eines GraKa-Herstellers zu berücksichtigen. Sonst müssten sie sich immer den Vorwurf gefallen lassen, daß sie für einzelne Hersteller optimieren und nicht neutral sind.

Mein ich ja. Es wurde genommen was "neutral" da war. Mehr nicht.

AlfredENeumann

2003-05-30, 23:38:16

Original geschrieben von Razor
Wenn sie den Anspruch 'Unabhängigkeit' behalten wollen: Ja !

Wer entscheidet dann wie weit auf einen Chip optimiert wird ?

Demirug

2003-05-30, 23:47:24

So dann wollen wir mal etwas produktives tun. Ich habe mal den gleichen Shader mit dem ps_2_0 profil und den ps_2_a profil durchlaufen lassn.

ps_2_0
def c1, 0, 0.2, 0.4, 0
def c2, 0.5, 0.125, 0.06125, 0.25
def c3, 0.244, 0.223, 0, 75
def c4, 0.122, 0.1115, 0.2, 0.03
def c5, 1.12108, 0.892, 0.147493, 0.678
def c6, 0.488, 0.446, 1.3089, 0.764
def c7, 0, 0.973249, 0.229753, 0
def c8, 2, -1, 0.409836, 0.976
def c9, 0.339, 0.382, 0.15, 0
def c10, 0.1695, 0.191, 0, 0
def c11, 0.08475, 0.0955, 0, 0
def c12, 5, 1, 0, 0
def c13, 1, 0.2, 0, 0
dcl t0.xy
dcl_2d s0
mul r0.w, t0.x, c5.z
frc r0.x, r0.w
mul r10.x, r0.x, c5.w
mul r0.w, t0.y, c6.z
frc r0.y, r0.w
mul r10.y, r0.y, c6.w
mul r8.xy, r0, c9
mul r7.xy, r0, c10
mul r5.xy, r0, c11
mul r0.w, t0.x, c8.z
frc r0.x, r0.w
mul r6.x, r0.x, c8.w
mul r0.w, t0.y, c5.x
frc r0.y, r0.w
mul r6.y, r0.y, c5.y
mul r4.xy, r0, c6
mul r3.xy, r0, c3
mul r2.xy, r0, c4
mul r1.xy, t0, c2.x
mul r0.xy, t0, c2.w
texld r9, r10, s0
texld r10, r8, s0
texld r8, r7, s0
texld r7, r5, s0
texld r5, r6, s0
texld r6, r4, s0
texld r4, r3, s0
texld r3, r2, s0
texld r2, r1, s0
texld r1, t0, s0
texld r0, r0, s0
mul r0.w, r10.x, c2.y
mad r0.w, r9.x, c2.z, r0.w
mad r0.w, r8.x, c2.w, r0.w
mad r0.w, r7.x, c2.x, r0.w
mad r1.z, c8.x, r0.w, c8.y
mul r0.w, r6.x, c2.y
mad r0.w, r5.x, c2.y, r0.w
mad r0.w, r4.x, c2.w, r0.w
mad r1.y, r3.x, c2.x, r0.w
mul r0.w, r2.x, c2.y
mad r0.w, r1.x, c2.z, r0.w
mad r2.w, r0.x, c2.w, r0.w
mul r0.xy, t0, c2.y
texld r0, r0, s0
mad r0.w, r0.x, c2.x, r2.w
mad r1.x, c8.x, r0.w, c8.y
dp3 r0.w, r1, r1
rsq r0.w, r0.w
mul r0.xyz, r1, r0.w
dp3 r0.w, c0, c0
rsq r0.w, r0.w
mul r1.xyz, r0.w, c0
dp3 r2.w, r1, r0
dp3 r0.w, r0, c7
cmp r2.w, r2.w, r2.w, c3.z
cmp r2.w, r2.w, r2.w, c3.z
mul r1.w, r2.w, c4.z
cmp r2.w, r0.w, r0.w, c3.z
pow r0.w, r2.w, c3.w
mad r0.xyz, r0.w, c13, r1.w
add r0.xyz, r0, c1
mul r0.w, t0.y, t0.y
mul r0.w, r0.w, t0.y
mul r0.w, r0.w, c4.w
mad r0.w, t0.y, c9.z, r0.w
mad r0.xyz, r0.w, c12, r0
mov r0.w, c3.z
mov oC0, r0

ps_2_a
def c1, 1, 0.2, 0, 0.4
def c2, 0.5, 0.125, 0.06125, 0.25
def c3, 0.08475, 0.0955, 0, 75
def c4, 0.973249, 0.229753, 0, 0.2
def c5, 0.03, 0.15, 0, 0
def c6, 0.409836, 1.12108, 0.147493, 1.3089
def c7, 0.488, 0.446, 0.244, 0.223
def c8, 0.122, 0.1115, 0.678, 0.764
def c9, 0.339, 0.382, 0.1695, 0.191
def c10, 5, 1, 0, 0
def c11, 2, -1, 0.976, 0.892
dcl t0.xy
dcl_2d s0
mul r1.xy, t0, c2.x
texld r0, t0, s0
texld r1, r1, s0
mul r0.w, r1.x, c2.y
mad r2.w, r0.x, c2.z, r0.w
mul r1.xy, t0, c2.w
mul r0.xy, t0, c2.y
texld r1, r1, s0
texld r0, r0, s0
mad r0.w, r1.x, c2.w, r2.w
mad r0.w, r0.x, c2.x, r0.w
mad r3.x, c11.x, r0.w, c11.y
mul r0, t0.xyxy, c6
frc r0, r0
mul r2.xy, r0.zwzw, c9
mul r1.xy, r0.zwzw, c8.zwzw
texld r2, r2, s0
texld r1, r1, s0
mul r1.w, r2.x, c2.y
mad r3.w, r1.x, c2.z, r1.w
mul r2.xy, r0.zwzw, c9.zwzw
mul r1.xy, r0.zwzw, c3
texld r2, r2, s0
texld r1, r1, s0
mad r0.w, r2.x, c2.w, r3.w
mad r0.w, r1.x, c2.x, r0.w
mad r3.z, c11.x, r0.w, c11.y
mul r2.xy, r0, c7
mul r1.xy, r0, c11.zwzw
texld r2, r2, s0
texld r1, r1, s0
mul r0.w, r2.x, c2.y
mad r2.w, r1.x, c2.y, r0.w
mul r1.xy, r0, c7.zwzw
mul r0.xy, r0, c8
texld r0, r0, s0
texld r1, r1, s0
mad r0.w, r1.x, c2.w, r2.w
mad r3.y, r0.x, c2.x, r0.w
dp3 r0.w, r3, r3
rsq r0.w, r0.w
mul r0.xyz, r3, r0.w
dp3 r0.w, c0, c0
rsq r0.w, r0.w
mul r1.xyz, r0.w, c0
dp3 r0.x, r1, r0
dp2add r0.w, r0.yzzw, c4, c4.z
cmp r0.z, r0.x, r0.x, c3.z
cmp r0.z, r0.z, r0.z, c3.z
mul r0.z, r0.z, c4.w
cmp r1.w, r0.w, r0.w, c3.z
pow r0.w, r1.w, c3.w
mad r0.xyz, r0.w, c1, r0.z
add r0.xyz, r0, c1.zyww
mul r0.w, t0.y, t0.y
mul r0.w, r0.w, t0.y
mul r0.w, r0.w, c5.x
mad r0.w, t0.y, c5.y, r0.w
mad r0.xyz, r0.w, c10, r0
mov r0.w, c3.z
mov oC0, r0

Die unterschiede dürften schnell erkenntlich sein.

Quasar

2003-05-30, 23:54:11

Die einzelnen Op-Typen sind "homogener" verteilt, wenn ich das richtig sehe, oder?

Demirug

2003-05-30, 23:58:38

Original geschrieben von AlfredENeumann
Nein das nicht. War ja prakisch immer umgekert (oder so ähnlich), aber wie konnte es dazu kommen das zwei so verschiedene Chipdesigns "erarbeitet" wurden, aber M$ sich nur für eine Variante entschieden hat, und DX9 so starkt nach diesem Desing beendet hat.

MS hat sich für die Variante als Basis entschieden welche der kleinsten gemeinsamen Nenner aller IHVs ist. So wie bei DX8 auch. Das was also PS 2.0 ist gibt es genau so von niemanden als Hardware. Aber von allen DX9 Chips desen Spezifikation ich kenne kommt ATI am dichtesten an die PS 2_0 heran.

Der eigentliche D3D Teil von DX9 ist fertig und stabil (wichtig für die Treiber). Der D3DX Teil unterliegt aber noch veränderungen das war aber auch schon in der Vergangenheit so das an D3DX nachträglich noch etwas geändert wurde.

Der Compiler gehört zu D3DX.

Demirug

2003-05-31, 00:09:45

Original geschrieben von Quasar
Die einzelnen Op-Typen sind "homogener" verteilt, wenn ich das richtig sehe, oder?

Ja.

Den Def und Dcl Teil kann man mal vergessen. dort werden nur Konstanten und speziele Variablen (Texturekoordinaten und Texturesampler) definiert. Das muss logischerweise immer am Anfang sein.

Bei den Operationen muss man zwischen denen die mit tex anfangen (Texture reads) und dem Rest trennen.

Beim 2_0 Profil versucht der Compiler so viele tex anweisungen wie nur möglich am stück anzuordnen. Danach wiederum so viele Rechenoperatione wie möglich und das ganze immer im wechsel. Genau was ATI gerne möchte.

Beim 2_a Profil werden dagegen nach möglichkeit immer 2 tex Anweisungen zusammengelegt und dann so viele Rechenoperationen wie nur möglich ausgeführt bevor wieder 2 tex Anweisungen kommen. Steht genau so in den Guides von nVidia.

Ein weitere Unterschied ist in der Verwendung der Temporären Register zu erkennen. Der ps_2_0 Shader benötigt 11 (r0-r10) die ps_2_a Variante dagegen nur 4 (r0-r3). ATI macht bezüglich der TempRegs keine Aussagen nVidia sagt das man für die optimale Performance so wenige wie möglich benutzten soll.

Salvee

2003-05-31, 01:32:08

Weiss zufällig jemand, ob ATi den Chip nach dem M$-Compiler gebaut hat oder ob der M$-Compiler in seiner ursprünglichen Form sich
am ATi-Chip orientiert (was war zuerst da sozusagen) ?

Edit: Leicht OT

Edit2: So besonders optimiert auf ATi kann der Murks auch nicht sein, denn allein das Austauschen des PS2.0 Shaders im GT4 bringt schon ~8% Performance ;)

Salvee

2003-05-31, 01:42:12

Original geschrieben von Demirug
Ein weitere Unterschied ist in der Verwendung der Temporären Register zu erkennen. Der ps_2_0 Shader benötigt 11 (r0-r10) die ps_2_a Variante dagegen nur 4 (r0-r3). ATI macht bezüglich der TempRegs keine Aussagen nVidia sagt das man für die optimale Performance so wenige wie möglich benutzten soll.

Das hört sich für einen 'Shader-Dau' wie mich so an, als wäre nV mit der relativ hohen Programmierbarkeit irgendwie über das Ziel hinausgeschossen, sprich die höhere Flexibilität verbraucht eine Menge Transistoren, die dann für TempRegs u.ä., ein besseres Trisetup oder zusätzliche AA-Sampler gefehlt haben.

Razor

2003-05-31, 09:03:52

Original geschrieben von Salvee
Edit2: So besonders optimiert auf ATi kann der Murks auch nicht sein, denn allein das Austauschen des PS2.0 Shaders im GT4 bringt schon ~8% Performance ;)
Nun ja lediglich die 'Optimierungen', die ATI noch zusätzlich zur vermutlich sowieso schon vorhandenen Nähe zu ihrem Treiber vornahm, sind damit weggefallen. Trotz des deutlichen Vorteils der Hardwarenähe, hat es sich ATI also wohl nicht nehmen lassen, noch zusätzliche Optimierungen vorzunehmen...

Aber das werden sie ja 'korrigieren' !
:D

Razor

Razor

2003-05-31, 09:06:10

Demirug

2003-05-31, 09:11:23

Original geschrieben von Salvee
Das hört sich für einen 'Shader-Dau' wie mich so an, als wäre nV mit der relativ hohen Programmierbarkeit irgendwie über das Ziel hinausgeschossen, sprich die höhere Flexibilität verbraucht eine Menge Transistoren, die dann für TempRegs u.ä., ein besseres Trisetup oder zusätzliche AA-Sampler gefehlt haben.

Die TempRegs sind schon da sogar ehr als bei ATI. Zu mindestens kann man sie benutzten. Es scheint nur irgendwie so zu sein das eine Anzahl von x Registern in einer effektiveren Art in der Pipeline gehalten werden können. Meine Vermutung dazu ist das die Pipelines wie eine CPU eine Menge von X Registern zur verfügung haben. Wenn diese nicht mehr ausreichen muss auf den Speicher (Cache) des Chips zurückgeriffen werden. Dadurch wird aber die Speicher-Pipeline Bandbreite zusätzlich belastet und genau davon scheint es nicht genügend zu geben. Wenn es so ist hast du in gewisser weise recht da die Tempregister in diesem Fall ja nicht wirklich als Physikalische einheit vorliegen sondern sein einen kleinen Teil des Caches abzweigen.

Demirug

2003-05-31, 09:24:50

Original geschrieben von Razor
Nein, das was ich meine, heraus gelesen zu haben, ist schlicht die Tatsache, dass die Chips sehr unterschiedlich arbeiten und damit mit unterschiedlichen Wegen ans gleiche Ziel kommen.

Offensichtlich trägt der neue Compiler mit den unterschiedlichen Zielpfaden dem Rechnung, oder ?

Razor

Ja die unterschiedlichen Ziel-Profile sind sicherlich eine gute Idee und das man immer zwei tex Anweisungen Paarweise vorfindet zeigt eindeutig das hier für NV3x optimiert wurde. MS will diesen Weg ja weiter gehen und für jede Chip Familie eigene Zielprofile integrieren. Möglicherweise wie schon vermutet wurde um zu verhindern das noch mehr IHVs auf die Idee kommen eigene Compiler zu schreiben.

Trotzdem habe ich inzwischen das ungute Geühl das FM diese Profile nicht nutzen wird. Da sie ja so sehr darauf bestehen das jeder Chip die gleiche Arbeit verrichten soll. Wer sich mal die Mühe macht un bei meinem Beispiel oben die Anweisungen nachzählt wird etwas feststellen.

Beide brauchen 12 Textureanweisungen soweit so gut. Bei den Rechenanweisungen benötigt man beim 2_0 Profil 59 Slots beim 2_a aber nur 51 Slots. Das sind 8 Anweisungen weniger was schon eine ganze Menge ist. Ein NV3X Chip kann diesen Effekt also mit viel weniger Anweisungen berrechen. Aber erledigt er dann wenn man nach FM geht immer noch die gleiche Menge Arbeit?

Razor

2003-05-31, 09:36:35

Wie Du schon gesagt hast, Demirug...
"Was genau will FM eigentlich mit dem Murks messen ?"
(so, oder ähnlich ;-)

Für mich scheint es immer sinnfreier, den Murks überhaupt als Bench einzusetzen.
Vielleicht wäre es für eine objektive Beurteilung der Leistungsfähigkeit von GraKa's wirklich besser, wenn der Murks ganz von der Bildfläche verschwindet...
Nur meine Meinung.

Razor

Mr. Lolman

2003-05-31, 10:18:51

Mr. Lolman

2003-05-31, 10:19:41

Original geschrieben von Demirug
Ja die unterschiedlichen Ziel-Profile sind sicherlich eine gute Idee und das man immer zwei tex Anweisungen Paarweise vorfindet zeigt eindeutig das hier für NV3x optimiert wurde. MS will diesen Weg ja weiter gehen und für jede Chip Familie eigene Zielprofile integrieren. Möglicherweise wie schon vermutet wurde um zu verhindern das noch mehr IHVs auf die Idee kommen eigene Compiler zu schreiben.

Trotzdem habe ich inzwischen das ungute Geühl das FM diese Profile nicht nutzen wird. Da sie ja so sehr darauf bestehen das jeder Chip die gleiche Arbeit verrichten soll. Wer sich mal die Mühe macht un bei meinem Beispiel oben die Anweisungen nachzählt wird etwas feststellen.

Beide brauchen 12 Textureanweisungen soweit so gut. Bei den Rechenanweisungen benötigt man beim 2_0 Profil 59 Slots beim 2_a aber nur 51 Slots. Das sind 8 Anweisungen weniger was schon eine ganze Menge ist. Ein NV3X Chip kann diesen Effekt also mit viel weniger Anweisungen berrechen. Aber erledigt er dann wenn man nach FM geht immer noch die gleiche Menge Arbeit?

Wieviel Slots braucht man bei einer ATi Karte? Lassen sich die eingesparten Anweisungen 1:1 in Perfomancegewinn umrechnen? (14%)

IMO ging es ursprünglich FM primär darum, mit dem neuem Patch, das Cheaten seitens NVidia zu unterbinden. (Damit meine ich das Treiber HSR im GT4 und die geringere Rendergenauigkeit) Gegen eine PS Optimierung haben die sich AFAIK nie ausgesprochen. FM verwendete den M$ HLSL-Combiler (welcher sich, aufgrund NVs eigenbrötlerischem Renderingansatz, als unerwartet ATi freundlich erwies) anstelle von cg.

ATis Optimierungen betrafen die Shader, und diese waren ja seitens FM legitim. Nur ATi fühlt sich bemüssigt die Optimierungen herauszunehmen, wahrscheinlich im Wissen, das NV ohne ähnlichen Optimierungen noch schlechter dastehen würde. Der optimaler Weg dürfte jetzt sowieso mit den neuen Profilen im M$-Combiler beschritten werden, und seitens FM wäre es wohl der entscheidende Schritt in den Untergang, diese Möglichkeit nicht wahrzunehmen.

Original geschrieben von Razor
Wie Du schon gesagt hast, Demirug...
"Was genau will FM eigentlich mit dem Murks messen ?"
(so, oder ähnlich ;-)

Für mich scheint es immer sinnfreier, den Murks überhaupt als Bench einzusetzen.
Vielleicht wäre es für eine objektive Beurteilung der Leistungsfähigkeit von GraKa's wirklich besser, wenn der Murks ganz von der Bildfläche verschwindet...
Nur meine Meinung.

Razor

http://forum.gamevision.de/images/smilies/motz.gif http://forum.gamevision.de/images/smilies/motz.gif http://forum.gamevision.de/images/smilies/motz.gif http://forum.gamevision.de/images/smilies/motz.gif http://forum.gamevision.de/images/smilies/motz.gif

Razor

2003-05-31, 10:34:06

Original geschrieben von Mr. Lolman
IMO ging es ursprünglich FM primär darum, mit dem neuem Patch, das Cheaten seitens NVidia zu unterbinden. (Damit meine ich das Treiber HSR im GT4 und die geringere Rendergenauigkeit) Gegen eine PS Optimierung haben die sich AFAIK nie ausgesprochen. FM verwendete den M$ HLSL-Combiler (welcher sich, aufgrund NVs eigenbrötlerischem Renderingansatz, als unerwartet ATi freundlich erwies) anstelle von cg.
Jegliche Änderung des Workloads für die Chips wird von FM als Cheat bezeichnet.
Also auch die 'Optimierungen' von ATI.
(nicht meine Meinung ;-)
Original geschrieben von Mr. Lolman
ATis Optimierungen betrafen die Shader, und diese waren ja seitens FM legitim. Nur ATi fühlt sich bemüssigt die Optimierungen herauszunehmen, wahrscheinlich im Wissen, das NV ohne ähnlichen Optimierungen noch schlechter dastehen würde. Der optimaler Weg dürfte jetzt sowieso mit den neuen Profilen im M$-Combiler beschritten werden, und seitens FM wäre es wohl der entscheidende Schritt in den Untergang, diese Möglichkeit nicht wahrzunehmen.
Nein, ATI betreibt genauso Schadensbegrenzung, weil sie nach FM gecheatet haben.
Und da ja ihre eigene Architektur eine Begünstigung findet, reicht es ja, einen Vorsprung zu nVidia (wohl unverdienter maßen) zu halten. Aber klar, ist in etwa das, was Du auch sagtest.

Im übrigen bezog sich mein Kommentar auf das von Demirug, in welchem er meinte, dass FM wohl nicht die zusätzlichen Zielpfade des neuen M$-Compilers nutzen wird.

Deswegen mein "weg mit dem Murks von der Bildfläche" !
Und wenn ich Dich richtig verstanden habe, siehst Du das wohl genauso, oder ?

Ich denke, dass der Murks einfach von der Bildfläche verschwindet, sollte FM nicht auf die neue Situation reagieren.

Besser ausgedrückt ?
:D

Razor

Quasar

2003-05-31, 10:42:22

Original geschrieben von Mr. Lolman
IMO ging es ursprünglich FM primär darum, mit dem neuem Patch, das Cheaten seitens NVidia zu unterbinden. (Damit meine ich das Treiber HSR im GT4 und die geringere Rendergenauigkeit)

Bis hierhin Ack.

Original geschrieben von Mr. Lolman
Gegen eine PS Optimierung haben die sich AFAIK nie ausgesprochen.
Doch haben sie. Warum auch immer, jedenfalls haben sie bei ATis Vorgehen nicht offen von Betrug oder Cheating gesprochen. Der Ansatz ist klar:
Futuremark im 3DMark03_audit_report
[...]has verified that certain NVIDIA Drivers indeed seem to have detection mechanisms, which are triggered by components of the 3DMark03 program.[...]In our testing, all identified detection mechanism stopped working when we altered the benchmark code just trivially.[...] According to industry's terminology, this type of driver design ist defined as "driver cheats".[...]Our investigations reveal that some drivers from ATi also produce al slightly lower total score[...]This drop in performance is almost entirely due to 8.2% difference in the game test 4 result, which means that the test was also detected and somehow altered by the ATi drivers.
Aus dem letzten Teil in Verbindung mit dem ersten Teil, auch wenn Futuremark sich viel Mühe gegeben hat, die Verbindung nicht so offensichtlich herauszustellen, folgt sehr wohl, daß ATi ebenso cheatet.

Original geschrieben von Mr. Lolman
FM verwendete den M$ HLSL-Combiler (welcher sich, aufgrund NVs eigenbrötlerischem Renderingansatz, als unerwartet ATi freundlich erwies) anstelle von cg.

IIRC hat Demirug sich mal dahingehend geäußert, dass er meine, die meisten Shader seien von Hand geschrieben. Das finale DX9 und das entsprechende SDK sind wohl massiv zu spät released worden, um überhaupt noch im 3DMark03 Anwendung gefunden zu haben.

Original geschrieben von Mr. Lolman
ATis Optimierungen betrafen die Shader, und diese waren ja seitens FM legitim.
Nein, s.o.

Original geschrieben von Mr. Lolman
Nur ATi fühlt sich bemüssigt die Optimierungen herauszunehmen, wahrscheinlich im Wissen, das NV ohne ähnlichen Optimierungen noch schlechter dastehen würde. Der optimaler Weg dürfte jetzt sowieso mit den neuen Profilen im M$-Combiler beschritten werden, und seitens FM wäre es wohl der entscheidende Schritt in den Untergang, diese Möglichkeit nicht wahrzunehmen.

ATi fühlt sich bemüssigt, weil sie nur ~3% verlieren und hinterher mit einer "weissen Weste" prahlen können. IMO nur zu verständlich, jeder hier würde es genauso machen (und nV natürlich auch!).

BTW, ein Nachsatz im Audit-Report macht mich, beim zehnten lesen, doch _sehr_ stutzig:
[...]It is possible that new drivers that cheat also in the new 3DMark03 build may be released in the future. We sincerely hope this will not happen. We strive to provide all BETA program members with robust tools to detect such situations[...]

WTF??? BETA-Mitglieder bekommen Tools, um im Vorfeld zu untersuchen, ob ihre Cheats aufgedeckt werden können oder nicht??? ??? ???

Mr. Lolman

2003-05-31, 10:45:41

Original geschrieben von Razor
Jegliche Änderung des Workloads für die Chips wird von FM als Cheat bezeichnet.
Also auch die 'Optimierungen' von ATI.
(nicht meine Meinung ;-)

Nein, ATI betreibt genauso Schadensbegrenzung, weil sie nach FM gecheatet haben.

Ui, wusste ich nicht. Ich las von einer Meldung seitens FM - sinnmäss, das NV cheatet (24%), das die Shader, durch den Patch, minimalst geändert wurden und das aber auf bei ATi ein Vorsprung von 2% festgestellt werden konnte. Deswegen: Link bidde :)

Und da ja ihre eigene Architektur eine Begünstigung findet, reicht es ja, einen Vorsprung zu nVidia (wohl unverdienter maßen) zu halten. Aber klar, ist in etwa das, was Du auch sagtest.

Im übrigen bezog sich mein Kommentar auf das von Demirug, in welchem er meinte, dass FM wohl nicht die zusätzlichen Zielpfade des neuen M$-Compilers nutzen wird.

Deswegen mein "weg mit dem Murks von der Bildfläche" !
Und wenn ich Dich richtig verstanden habe, siehst Du das wohl genauso, oder ?

Ich denke, dass der Murks einfach von der Bildfläche verschwindet, sollte FM nicht auf die neue Situation reagieren.

Besser ausgedrückt ?
:D

Razor

Ich sehe, wir verstehen uns :D :ficken:

Demirug

2003-05-31, 10:47:52

Original geschrieben von Mr. Lolman
Wieviel Slots braucht man bei einer ATi Karte? Lassen sich die eingesparten Anweisungen 1:1 in Perfomancegewinn umrechnen? (14%)

Das PS 2_0 Profil braucht bei diesem Shadern 12 Texture + 59 Rechen Slots. Im besten fall können die Eingesparten Anweisungen voll in einem Performancegewinn umgewnadelt werden. Zu messen ist das Allerdings nicht ganz einfach weil ja auch noch der Gewinn durch die andere Sortierreheienfolge hinzukommt.

IMO ging es ursprünglich FM primär darum, mit dem neuem Patch, das Cheaten seitens NVidia zu unterbinden. (Damit meine ich das Treiber HSR im GT4 und die geringere Rendergenauigkeit) Gegen eine PS Optimierung haben die sich AFAIK nie ausgesprochen. FM verwendete den M$ HLSL-Combiler (welcher sich, aufgrund NVs eigenbrötlerischem Renderingansatz, als unerwartet ATi freundlich erwies) anstelle von cg.

Ja man wollte das erkennen des 3dmarks unterbinden. Die PS Optimierung (da ja Spezial für den 3dmark eingebaut) haben sie aber auch kritisiert. On FM wirklich den HLSL Compiler benutzt hat ist AFAIK bisher noch nicht bestätigt es könnte auch sein das sie die Shader von Hand geschrieben haben.

ATis Optimierungen betrafen die Shader, und diese waren ja seitens FM legitim. Nur ATi fühlt sich bemüssigt die Optimierungen herauszunehmen, wahrscheinlich im Wissen, das NV ohne ähnlichen Optimierungen noch schlechter dastehen würde. Der optimaler Weg dürfte jetzt sowieso mit den neuen Profilen im M$-Combiler beschritten werden, und seitens FM wäre es wohl der entscheidende Schritt in den Untergang, diese Möglichkeit nicht wahrzunehmen.

In wie fern legitim? FM hat doch klar gemacht das sie jede form von Spezieller 3dmark optimierung verurteilen.

Der Ideale Weg wäre die Nutzung der Profile sicherlich aber ich habe da wie schon gesagt Zweifel das FM da mitspielt weil ja dann plötzlich nicht mehr beide Chips sich mit genau dem selben Shader-Code herumschlagen müssen und nv teilweise von den mächtigeren ALUs profitieren könnte.

Demirug

2003-05-31, 10:52:14

Original geschrieben von Quasar
WTF??? BETA-Mitglieder bekommen Tools, um im Vorfeld zu untersuchen, ob ihre Cheats aufgedeckt werden können oder nicht??? ??? ???

mhm so habe ich das bisher noch gar nicht gesehen. Aber du hast recht als Beta Mitglied bekommt ATI von FM die gleichen Tools wie die Reviewer. Damit können sie Testen was diese Tools feststellen können. Was man damit wohl alles machen kann? ...

Razor

2003-05-31, 11:32:41

Original geschrieben von Mr. Lolman

Ui, wusste ich nicht. Ich las von einer Meldung seitens FM - sinnmäss, das NV cheatet (24%), das die Shader, durch den Patch, minimalst geändert wurden und das aber auf bei ATi ein Vorsprung von 2% festgestellt werden konnte. Deswegen: Link bidde :)
Erst einmal liegt der Vorsprung bei ATI im GT4 bei 'satten' 8%... in den anderen Tests (GT1-3) konnte keine Veränderung in der Performance festgestellt werden. So hat also ATI nur bei GT4-MotherNature 'gecheatet' (nicht meine Meinung !) und damit dann in Total 2% (GT1-4) Schnullerpunkte bekommen...

Desweiteren hat Quasar ja schon die entsprechenden Passagen aus dem Audit Report (http://www.futuremark.com/companyinfo/3dmark03_audit_report.pdf) zitiert, nach denen ja auch die 'Optimierung' von ATI als Cheat deklariert wurde (ohne sie namentlich zu nennen ;-).

Hier also mal ein Zitat (http://www.futuremark.com/products/3dmark03/?03patch330) zu dem Murks Patch 3.20:
3DMark03 (build 330) Info

Futuremark is pleased to announce the release of a new version of 3DMark®03 - Patch (330)!

3DMark03 v3.3.0 is an updated version of 3DMark03. Hardware review sites discovered deliberate cheats in some drivers. These drivers identify 3DMark03 build 3.2.0, and render the tests differently than 3DMark03 instructs, in order to gain additional performance. Build 3.3.0 has been changed so that the test results remain the same, but the questionable drivers do not identify 3DMark03 anymore. The drivers now think 3DMark is a 3D application among others, and render the tests like 3DMark instructs. This produces a result that is genuinely comparable to other hardware.

Futuremark encourages everyone to download the latest patch (330) to ensure comparable results.

Please read the Audit Report (http://www.futuremark.com/companyinfo/3dmark03_audit_report.pdf) (pdf) for more information.

NOTE: 3DMark03 results from the original version (313) are identical with the results of this new build (330), and those of the first patch (320), except when using certain drivers with built in cheats.

Bis denne

Razor

AlfredENeumann

2003-05-31, 14:41:37

Original geschrieben von Razor
Nun ja lediglich die 'Optimierungen', die ATI noch zusätzlich zur vermutlich sowieso schon vorhandenen Nähe zu ihrem Treiber vornahm, sind damit weggefallen. Trotz des deutlichen Vorteils der Hardwarenähe, hat es sich ATI also wohl nicht nehmen lassen, noch zusätzliche Optimierungen vorzunehmen...

Aber das werden sie ja 'korrigieren' !
:D

Razor

Aha. Wenn ATI also Optimieren muß um mehr Leistung zu bekommen ist der Murks also nicht auf ATI optimiert.

Lethal Master

2003-05-31, 15:40:35

Lolman w. LMs Cookies:

Original geschrieben von Razor
Erst einmal liegt der Vorsprung bei ATI im GT4 bei 'satten' 8%... in den anderen Tests (GT1-3) konnte keine Veränderung in der Performance festgestellt werden. So hat also ATI nur bei GT4-MotherNature 'gecheatet' (nicht meine Meinung !) und damit dann in Total 2% (GT1-4) Schnullerpunkte bekommen...
Razor

Stimmt, aber die 'satten 8%' stehen in keiner Relation zu den 'satten 50%' die dann insgesamt (inkl. den aderen gecheateten GTs) 24% Mehrperfomance ausmachen :) ansonsten ACK und danke für die Links...

Quasar

2003-05-31, 15:47:44

Salvee

2003-05-31, 15:50:00

Original geschrieben von Quasar
Damit beantwortest du AENs Frage ja ziemlich eindeutig. =)

Nö, denn während bei ATi einzig der Austausch des Wassers-Shaders 8% Performancezuwachs bringt, hat nV da noch einige 'Optimierungen' mehr am Start, von denen nicht bekannt ist, welche denn nun wieviel bringt.

Pussycat

2003-05-31, 17:21:37

Doch, das hardgecoddete clipping. Das ist ganz einfach falsch und hat nichts damit zu tun dass FM so gemein ist die Shader unfreundlich zu machen.

seahawk

2003-05-31, 17:34:27

Also für mich läßt sich bisher folgendes feststellen :

- wir wissen nicht ob FM den MS Compiler benutzt hat, oder nicht
- DX 9 wurde "unreif" released und die erste Version des SDKs liegt ATI Karten besser
- Das kommende SDK wird Pfade haben, die ATI und NV berücksichtigen.
- Es ist denkbar, dass die Probleme der NV Karten mit dem "normalen" Pfad aus der erhöhten Programmierbarkeit herrühren. Für optimale Performance brauchen die Karten eine andere Reihenfolge der Befehle.

DX 9 sagt imo, aber nichts über die Reihenfolge der Befehle, es definiert ja nur was die KArte können muss. Die Reihenfolge der BEfehle um dies zu errecihen wird nicht festgelegt.

Wenn also FM ein Ändern an den Shadercodes ihres 2003 Marks als cheaten ansieht, dann werden aktuell die Karten von ATI bevorzugt. Ich denke dies war von FM nicht beabsichtigt, wahrscheinlich lagen zum Zeitpunkt der Programmierung noch keine Erkenntnisse über die Bedürfnisse der NV Karten vor.

Durch das kommende SDK von M$ werden beide Karten in kommenden, realen 3D Anwendungen optimal unterstützt. Demi hat ja gesagt, dass sein Projekt dies enthalten wird. Ich denke die meisten Publisher / Entwckler werden gleich verfahren. (siehe z.B. auch Doom 3 das zwar OGL ist, aber auch unterschiedliche Pfade enthält)

FM sagt, dass Ihr Produkt eine reale Einschätzung der Leistung von Grafikkarten in DX9 Anwendungen gibt. Und dies ist imo nicht mehr gegeben. Dadurch hat der Murks in seiner gegenwärtigen Form seine Berechtigungverloren. FM nutzt nur einen ATI freundlichen (nicht optimierten, da gibt es bestimmt noch Möglichkeiten) Code. DX 9 hingegen bietet in Kürze einen ATI freundlichen und einen NV freundlichen Code.
Sollte FM nicht bereit sein auch einen NV freundlichen Code einzubauen, dann verhält sich der Murks anders, als die eigentlichen DX 9 Anwendungen. Daher ist er als Bench nicht zu gebrauchen.

(Es wäre anders, wenn M$ nicht den NV freundlichen Code einführen würde)

Quasar

2003-05-31, 22:56:03

Original geschrieben von Salvee
Nö, denn während bei ATi einzig der Austausch des Wassers-Shaders 8% Performancezuwachs bringt, hat nV da noch einige 'Optimierungen' mehr am Start, von denen nicht bekannt ist, welche denn nun wieviel bringt.

Doch. AEN fragte, ob Razor den Austausch Wassershaders und die damit verbundenen ~3% Leistungsgewinn nicht als Gegenbeweis ansähe, dass der 3DMark03 für ATi optimiert sei.

Wenn nun selbst ATi, die ihre Hardware schon recht gut kennen sollten, nicht mehr finden, als diesen einen Shader, der für 3% gut ist, wie optimal muss dann der Rest des Programmes auf ihrer Hardware laufen?

(Dies unterstellt natürlich, dass ATi auch die Absicht hatte, ihre Treiber, um es mal neutral zu sagen, möglichst gut auf den 3DMark03 abzustimmen.)

Salvee

2003-05-31, 23:03:41

Original geschrieben von Quasar
Doch. AEN fragte, ob Razor den Austausch Wassershaders und die damit verbundenen ~3% Leistungsgewinn nicht als Gegenbeweis ansähe, dass der 3DMark03 für ATi optimiert sei.

Wenn nun selbst ATi, die ihre Hardware schon recht gut kennen sollten, nicht mehr finden, als diesen einen Shader, der für 3% gut ist, wie optimal muss dann der Rest des Programmes auf ihrer Hardware laufen?

(Dies unterstellt natürlich, dass ATi auch die Absicht hatte, ihre Treiber, um es mal neutral zu sagen, möglichst gut auf den 3DMark03 abzustimmen.)

Und genau bei dieser letzten 'Unterstellung' scheiden sich halt unsere Geister ;)

Schade, seahawk hatte so ein schönes Schlussplädoyer gehalten, dem ich mich erstmal *anschliesse*

Edit :up: :)

Razor

2003-06-01, 11:36:09

Original geschrieben von AlfredENeumann
Aha. Wenn ATI also Optimieren muß um mehr Leistung zu bekommen ist der Murks also nicht auf ATI optimiert.
???

Ich glaube Du bist ein wenig "verwirrt", oder ?
:D

Razor

Achill

2003-06-01, 11:38:52

Original geschrieben von Demirug
Solange wir mal die Shader aussen vorlassen also nur den reinen Codepfad (der ja shaderunabhängig ist) betrachten stimmen die Guidelines noch fast zu 100% überein.

Auch was die grundsätzlichen Dinge angeht (Anzahl der Instruktionen, Verhältniss Texturanweisungungen/Rechenanweisungen) ist man sich bei nv und ATI noch recht einig. Wenn es dann aber ins Detail (Instruktionsreihenfolge, Registerbenutzung) geht fangen die Unterschiede an.

DX9 normiert nur Verfahren. Unter anderem eben auch wie ein Shader angelegt und benutzt wird. Desweiteren wird auch noch festgelegt wie das binäre Format eines Shaders aufgebaut ist. Man darf sich diese Format aber jetzt nicht wie das Binärformat für "normalen" x86 Programmcode vorstellen. Das Binärformat entspricht eher dem Bytecode von Java oder MSIL von .Net. Eine GPU kann also nicht direkt etwas damit anfangen. Der Treiber muss als Umsetzer einspringen und je stärker das Ausgangsmaterial (Shaderbytecode) von der eigentlichen Chipstruktur abweicht desto aufwendiger wird das ganze für den Treiber. Aufgrund der geringen Komplexität der 1.1-1.3 Shader war das bisher kein grosses Problem da man die Hardware dafür gar nicht so unterschiedlich bauen konnte. Mit der zunehmenden Komplexität steigen aber auch die Möglichkeiten andere Wege bei der Implementierung einzuschlagen.

Seinen ureigenen Zweg (vereinheitlichung unterschiedlicher Hardware) erfüllt DX9 nach wie vor allerdings wird es komplizierter werden jeden Chip ideal zu nutzen wenn man darauf besteht Shader per Hand in der Shaderassemblersprache zu schreiben.

*nochmal hoch holt*
Es wäre also doch besser, wenn es eine Highlevelsprache gäbe, MS die Umsetzung der Befehle vor/beschreibt und alle Firmen ihren eigenen Compiler mitbringen, um diese Sprache um zu setzen.
Der erzeugt Zwischencode sollte schon schlechter zu optimieren sein als der anfängliche Quellcode...

Bzgl. FM
Ich denke die einzig fähre Möglichekit wäre also eine HLSprache, wobei jede firme die selber umsetzt, oder Ein Compiler von MS, der identische Shader erzeugt, jedoch für jeden GPU-Typ optimiert, damit zur Laufzeit eine Auswahl getroffen werden kann.

Im Endeffekt sieht man hier schon, wie mächtig MS ist, je nachdem wie sie ihren Compiler gestallten, werden bestimmt Hersteller bevorzugt.
MS kann also schon druck ausüben...

Noch eine kleine Bemerkung, für mich ist es klar, das MS NV zuwendet, man darf die amerikanische Politik nicht vergessen... man sollte sich auch dahin gehende mal gedanken machen als sich "naiv" in die Lämmerherde ein zu reihen.

Razor

2003-06-01, 11:40:36

Original geschrieben von Lethal Master
Lolman w. LMs Cookies:

Stimmt, aber die 'satten 8%' stehen in keiner Relation zu den 'satten 50%' die dann insgesamt (inkl. den aderen gecheateten GTs) 24% Mehrperfomance ausmachen :) ansonsten ACK und danke für die Links...
Cheat ist Cheat... (nach FM's Definition !)

Das was nVidia da gemacht hat, würde ich bei einem RealWorld-Bench nicht dulden (was sie ja auch nicht taten !), das was ATI da machte sind IMO 'normale' Optimierungen, die in dieser Form sicher auch von nVidia vorgenommen wurden... nur ist nVidia halt sehr viel weiter gegangen...

Und wenn das mit dem M$-Compiler stimmt, dann hat FM wissentlich oder unwissentlich auf ATI 'optimiert' und sollte dieses Problem schleunigst korrigieren.

Ansonsten: No Prob' !
:D

Razor

Razor

2003-06-01, 11:51:11

Original geschrieben von Achill
Bzgl. FM
Ich denke die einzig fähre Möglichekit wäre also eine HLSprache, wobei jede firme die selber umsetzt, oder Ein Compiler von MS, der identische Shader erzeugt, jedoch für jeden GPU-Typ optimiert, damit zur Laufzeit eine Auswahl getroffen werden kann.
So wird es ja in dem neuesten SDK realisiert und auch als empfohlene Vorgehensweise dargestellt. Gleicher HLSL-Code resultiert in 2 unterschiedlichen Shader-Sets, einem für ATI (oder classic PS2) und einem für nVidia (PS2a). Zur Laufzeit wird dann nach Hardwareidentifikation (über DX-Caps) das jeweilige Shader-Set ausgewählt und das war's dann auch schon...

Und wenn ich recht entsinne hat M$ damit angekündigt auch weitere Architekturen anderer Chip-Hersteller in dieser Weise zu unterstützen, wenn diese erscheinen. So können Developer z.Bsp. Patches nachschieben, die dann eine optimale Unterstützung neuer Hardware gewährleisten (was somit auch mit FM möglich wäre).

Schaun' wir mal, wie FM jetzt auf diese Situation reagiert...

Razor

Demirug

2003-06-01, 12:01:10

Original geschrieben von Achill
*nochmal hoch holt*
Es wäre also doch besser, wenn es eine Highlevelsprache gäbe, MS die Umsetzung der Befehle vor/beschreibt und alle Firmen ihren eigenen Compiler mitbringen, um diese Sprache um zu setzen.
Der erzeugt Zwischencode sollte schon schlechter zu optimieren sein als der anfängliche Quellcode...

Im Prinzip gebe ich dir recht. Allerdings gibt es mit dieser Lösung des Shaderproblems (welche übrigens OpenGL 2.0 benutzt) leider auch Probleme.

1. Das kleine Problem. Bei den kleinen IHVs dürfte kaum Fachwissen über das schreiben von Compiler vorhanden sein was es diesen dann noch schwerer macht mit den grossen mitzuhalten welche sich die notwendigen Spezialisten mal schnell einkaufen können.

2. Es ist bei dem direkten Hochsprachenkonzept nicht möglich im Vorfeld mitdestvoraussetzungen festzulegen das ein Chip den support melden darf. Bei der einfach strukturierten Assemblersprache kann man noch einfach regeln (maximale Länge, welche Befehle und Register, ...)aufstellen was gehen muss. Bei einer Hochsprache geht das nicht mehr und das zerstört die Planungssicherheit bei den Entwicklern.

Bzgl. FM
Ich denke die einzig fähre Möglichekit wäre also eine HLSprache, wobei jede firme die selber umsetzt, oder Ein Compiler von MS, der identische Shader erzeugt, jedoch für jeden GPU-Typ optimiert, damit zur Laufzeit eine Auswahl getroffen werden kann.

Ja genau das passiert ja jetzt. Der Cg Compiler benutzt die gleiche Syntax wie der MS-Compiler und der MS-Compiler bekommt noch ein zusätzliche Profil für die NV3x Chip. Die R3xx Chips bekommen wohl kein zusätzliches Profil das das standard 2.0 Profil schon den Bedürfnissen von ATI entspricht.

Im Endeffekt sieht man hier schon, wie mächtig MS ist, je nachdem wie sie ihren Compiler gestallten, werden bestimmt Hersteller bevorzugt.
MS kann also schon druck ausüben...

Ja aber wenn das einem IHV nicht passt können sie immer noch einen eigenen Compiler schreiben und diesen die ISVs Schmakhaft machen.

Noch eine kleine Bemerkung, für mich ist es klar, das MS NV zuwendet, man darf die amerikanische Politik nicht vergessen... man sollte sich auch dahin gehende mal gedanken machen als sich "naiv" in die Lämmerherde ein zu reihen.

MS will Geld verdienen viel Geld ich denke denen sind solche Sache egal vorallem da sie mit den amerikanischen Behörden doch nur ständig Ärger haben.

IMHO war das Zielprofil für die NV3x Chips von Anfang an vorgesehen hat es aber einfach nicht mehr in das erste DX9-SDK geschaft.