nVidia und Futuremark ab Montag wieder dicke Freunde? [Archiv]

tEd

2003-08-09, 22:15:37

Original geschrieben von Razor
Und welche wären das ?
???

Razor

so ziemlich jedes humus demo.

http://esprit.campus.luth.se/~humus

sind zwar meistens opengl demos welche die arb_fragment_program extrension nutzen was aber ziemlich das euqivalent zu d3d ps2.0 sind IMO

das hier hat nette ps2.0 features

http://www.daionet.gr.jp/~masa/rthdribl/index.html

welches auf ati hardware um einiges besser läuft

der ganzen dx9 shadermark tests.

du wirst zwar sicher nvidia treiber finden welche vielleicht in diesen demos /benchmarks sehr gut auf nv3x abschneiden(im vergleich zur ati hardware) nur kann ich dir sagen das dann nicht der code ausgeführt wurde welcher vom demjenigen developer welcher den benchmark/die demo geschrieben hat ausgeführt wurde.

Ich denke da gibts nichts zu diskutieren , es wurde bewiesen wie nvidia in den verschiedensten ps2.0 immer wieder den original code umgangen hat , das gilt sowohl für z.b 3dmark03 wie auch shadermark , welche gerne mal als benchmarks für grafikkarten reviews
benutzt werden.

Ich glaube daran das man ps2.0 shader auf der nv3x architektur sehr schnell sein kann wenn der derjenige entwickler sehr viel zeit und mühe darin investiert .

Doom3 ist sicher ein gutes beispiel. John carmack hat sich die mühe gemacht für die einzelnen karten verschiedene codepaths zu schreiben und auf die einzelnen karten zu optimieren, nur ist das eher die ausnahme.

LovesuckZ

2003-08-09, 22:19:25

Original geschrieben von mapel110
nvidias dawn zb

Ohne Wrapper?

mapel110

2003-08-09, 22:24:00

Original geschrieben von LovesuckZ
Ohne Wrapper?

geht ja nit ohne :|

mapel110

2003-08-09, 22:26:20

Original geschrieben von tEd
Doom3 ist sicher ein gutes beispiel. John carmack hat sich die mühe gemacht für die einzelnen karten verschiedene codepaths zu schreiben und auf die einzelnen karten zu optimieren, nur ist das eher die ausnahme.

die mühe muss man sich wohl oder übel unter opengl machen. andere hersteller=andere extensions

LovesuckZ

2003-08-09, 22:26:33

Original geschrieben von tEd
du wirst zwar sicher nvidia treiber finden welche vielleicht in diesen demos /benchmarks sehr gut auf nv3x abschneiden(im vergleich zur ati hardware) nur kann ich dir sagen das dann nicht der code ausgeführt wurde welcher vom demjenigen developer welcher den benchmark/die demo geschrieben hat ausgeführt wurde.

Dadran muss der Entwickler aber denken. Entwickler, die vor einem halben Jahr (oder früher= angefangen haben ihre Engine zu schreiben, seien ja eine Ausnahme, da es das erweitere SDK von MS noch nicht gab. Doch alle, die nur Stur einen Pfad in ihre Engine einbauen, sollten sich eine andere Arbeit besorgen...

Ich denke da gibts nichts zu diskutieren , es wurde bewiesen wie nvidia in den verschiedensten ps2.0 immer wieder den original code umgangen hat , das gilt sowohl für z.b 3dmark03 wie auch shadermark , welche gerne mal als benchmarks für grafikkarten reviews
benutzt werden.

Das sind auch genau die Benches, die einseitig programmiert wurden (wobei es beim Shadermark ja nicht schlimm ist, da es ein ATi bench ist).
Ich koennte auch sagen, dass die r3x0 karten eine schlechte VS2.0 und PS1.1 Leistung haetten, nur weil sie im GunMetal Benchmark schlechter als die Nvidia Konkurenz abschneiden.

Ich glaube daran das man ps2.0 shader auf der nv3x architektur sehr schnell sein kann wenn der derjenige entwickler sehr viel zeit und mühe darin investiert.

Nein, man muss einfach nur den Anweisungen von Nvidia folgen. Und schon sieht die Sache ganz anders aus.

Doom3 ist sicher ein gutes beispiel. John carmack hat sich die mühe gemacht für die einzelnen karten verschiedene codepaths zu schreiben und auf die einzelnen karten zu optimieren, nur ist das eher die ausnahme.

Was aber unter OpenGL so üblich ist (siehe auch Q3).

tEd

2003-08-09, 22:51:32

Original geschrieben von LovesuckZ

Dadran muss der Entwickler aber denken. Entwickler, die vor einem halben Jahr (oder früher= angefangen haben ihre Engine zu schreiben, seien ja eine Ausnahme, da es das erweitere SDK von MS noch nicht gab. Doch alle, die nur Stur einen Pfad in ihre Engine einbauen, sollten sich eine andere Arbeit besorgen...[quote]

was heisst hier stur einen pfad? die d3d spez. ist ja schliesslich da um es den entwicklern einfacher zu machen so das es nicht nötig wäre für jede grafikkarte einen eigenen pfad zu schreiben. Was kann ein entwickler dafür das standard ps2.0 code auf nv3x 2-3x schlechter läuft als auf ati hardware.

[quote]
Das sind auch genau die Benches, die einseitig programmiert wurden (wobei es beim Shadermark ja nicht schlimm ist, da es ein ATi bench ist).
Ich koennte auch sagen, dass die r3x0 karten eine schlechte VS2.0 und PS1.1 Leistung haetten, nur weil sie im GunMetal Benchmark schlechter als die Nvidia Konkurenz abschneiden.

die benches die ich erwähnt habe sind haben standart ps2.0 code , welche nach der dx9 spez. programmiert wurden.

zu gunmetal:
Nun da gibts nichts wrklich überraschendes , die nv3x architektur wird in den meisten fällen ps1.1 schneller ausführen als entsprechende ati hardware , das hat weniger mit gunmetal selber zu tun. Die nv3x architektur ist besser für ps1.1 geeignet als für ps2.0 darum würde es mich nicht übberraschen wenn gunmetal auf einer nv35 schneller läuft als auf einer r350. Obwohl ich das jetzt nicht genau weiss ob das stimmt

Nein, man muss einfach nur den Anweisungen von Nvidia folgen. Und schon sieht die Sache ganz anders aus.

die entwicklern sollen in erster linie der dx9 spez. folgen. Sicher sind optimierungsmöglichkeiten für verschieden hardware architekturen nicht zu verachten. Wenn man nur den nvidia anweisungen folgt dann kommt so etwas wie nwn und mgs2 heraus. Das ist nicht erwünscht.

Was aber unter OpenGL so üblich ist (siehe auch Q3).

Ja sicher , darum gibt es wahrscheinlich nur noch wenige entwickler welche spiele auf dieser api programmieren.

LovesuckZ

2003-08-09, 23:00:25

Original geschrieben von tEd
was heisst hier stur einen pfad? die d3d spez. ist ja schliesslich da um es den entwicklern einfacher zu machen so das es nicht nötig wäre für jede grafikkarte einen eigenen pfad zu schreiben. Was kann ein entwickler dafür das standard ps2.0 code auf nv3x 2-3x schlechter läuft als auf ati hardware.

Es gibt aber keinen einzigen "Standard ps2.0 Code". Mit dem neusten SDK's sind es genau 3. Einen für die ATi Hardware, einen für Nvidia und den dritten für eine andere Firma. Und welchen sollte man nun nehmen?

die benches die ich erwähnt habe sind haben standart ps2.0 code , welche nach der dx9 spez. programmiert wurden.

Sie haben in unserer Zeit keinen Standard Code sondern einen optimierten für die ATi hardware.

die entwicklern sollen in erster linie der dx9 spez. folgen. Sicher sind optimierungsmöglichkeiten für verschieden hardware architekturen nicht zu verachten. Wenn man nur den nvidia anweisungen folgt dann kommt so etwas wie nwn und mgs2 heraus. Das ist nicht erwünscht.

Nvidia und sowie ATi haben mit ihren Karten die Spez. für DX9 erfüllt. Da beide aber andere Wege der Realisierung gegangen sind, kann man sie auch nicht mit dem selben Code ansprechen.
Und MGS und NWN angeht, liegt hier eher das Problem bei den Entwicklern und nicht bei Nvidia. Und sowas kommt eben heraus, wenn man nur auf eine Hardware optimiert. Und das wollen wir doch nicht?

Demirug

2003-08-09, 23:00:49

Da ich mich als Threadstarter für diese jetzt wieder mal aufkommende Endlosdiskussion Mitverantwortlich fühle möchte ich doch noch ein paar Worte zu dem Thema "PS 2.0 nach DX9 Spezifikation" sagen. In der Dokumentation welche ja sogar noch mehr vorgaben macht als die reine Spezifikation sind für die Pixelshader 2.0 nur definiert welche Befehle, Register und Programmelängen unterstützt werden müssen. Desweiteren gibt es Restriktionen was man nicht darf. Zu dem Thema Reihenfolge der Anweisungen sowies die Anzahl der eingesetzten Register gibt es nirgends in der Dokumentation oder Spezifikation eine Angabe. Dafür gibt es von nVidia und ATI empfehlungen zu genau diesem Themenkomplex und diese laufen genau in gegensätzliche Richtungen.

Demirug

2003-08-09, 23:03:12

Original geschrieben von LovesuckZ
Es gibt aber keinen einzigen "Standard ps2.0 Code". Mit dem neusten SDK's sind es genau 3. Einen für die ATi Hardware, einen für Nvidia und den dritten für eine andere Firma. Und welchen sollte man nun nehmen?

Es gibt Codecompilerprofile welche für eine Hardware optimierten Shadercode erzeugen. Davon derzeit nur 2 ein drittes ist in Vorbereitung.

tEd

2003-08-09, 23:30:31

[SIZE=1]Original geschrieben von LovesuckZ
Es gibt aber keinen einzigen "Standard ps2.0 Code". Mit dem neusten SDK's sind es genau 3. Einen für die ATi Hardware, einen für Nvidia und den dritten für eine andere Firma. Und welchen sollte man nun nehmen?

OK ich hab nicht die neuste SDK. Ich werd mir das mal anschauen.

Sie haben in unserer Zeit keinen Standard Code sondern einen optimierten für die ATi hardware.

siehe antwort oben , aber wie gesagt was macht den d3d überhaupt einen sinn wenn jeder entwickler trotzdem eine seperaten codepath für jede karte von den verschiedenen herstellern machen muss , nur das ihr spiel auch überall einigermassen gleich gut läuft? Keinen sinn macht es IMO.

Nvidia und sowie ATi haben mit ihren Karten die Spez. für DX9 erfüllt. Da beide aber andere Wege der Realisierung gegangen sind, kann man sie auch nicht mit dem selben Code ansprechen.

ich habe eher das gefühl das nvidia ihren eigenen weg gehen wollten. Vielleicht hätten sie besser mit MS zusammenarbeiten sollen als versuchen die ganze sache auf ihre sache zu regeln (siehe CG). Wenn sie doch dx9 erfüllt warum umgehen sie dann andauernd in dx9 demos und benchmarks diese erfüllung indem sie shadercode auswechseln welche nicht dx9 conform sind?

Und MGS und NWN angeht, liegt hier eher das Problem bei den Entwicklern und nicht bei Nvidia. Und sowas kommt eben heraus, wenn man nur auf eine Hardware optimiert. Und das wollen wir doch nicht?

Woher willst du das wissen das es rein nur an den Entwicklern liegt? Vorallem wenn ich aussagen von nwn entwicklern höere wie: "Das pixelshader wasser wäre auf ati hardware gar nicht möglich" Was eine lächerlich aussage ist vorallem wenn man bedenkt das ati seiner zeit im vergleich die flexiblere pixelshader hardware hatte als nvidia(r8500zuGF3,GF4).

Warum unterstützt Nvidia ps1.4 nicht mit CG , welches in dx8.1 spez. ist. Das sind alles Anzeichen das Nvidia nicht für standards sind sondern sich nur darum kümmern sich ihre vorteile für ihre hardware zu schaffen als an die ganze insdustrie zu denken

Demirug

2003-08-09, 23:56:19

Original geschrieben von tEd
OK ich hab nicht die neuste SDK. Ich werd mir das mal anschauen.

Das entsprechende SDK ist noch eine closed BETA. Also nicht das vom normalen MS Server benutzten.

siehe antwort oben , aber wie gesagt was macht den d3d überhaupt einen sinn wenn jeder entwickler trotzdem eine seperaten codepath für jede karte von den verschiedenen herstellern machen muss , nur das ihr spiel auch überall einigermassen gleich gut läuft? Keinen sinn macht es IMO.

Codepath ist in diesem Zusammenhang ein unglücklicher Begriff. Richtige Codepfade gibt es mit DX für das Pixelprocesing sowieso nur 2. Den Für Shader (alle Versionen werden da gleich behandelt) und den alten DX7 Weg. Benutzt man D3DX gibt es aber die Option mit Effekten zu arbeiten und man braucht nur noch einen Codepfad für alle Karten weil die unterschide nicht mehr im Code sondern in den Effektdateien liegen.

Was aber nun bei NV3X und R3XX erforderlich ist sind unterschiedliche Assemblercodeshader. Das nächste SDK wird aber in der Lage sein entsprechende Shader für NV3X und R300 aus HLSL erzeugen zu können. Das aktuelle erzeugt immer für R3XX optimierten Code.

ich habe eher das gefühl das nvidia ihren eigenen weg gehen wollten. Vielleicht hätten sie besser mit MS zusammenarbeiten sollen als versuchen die ganze sache auf ihre sache zu regeln (siehe CG). Wenn sie doch dx9 erfüllt warum umgehen sie dann andauernd in dx9 demos und benchmarks diese erfüllung indem sie shadercode auswechseln welche nicht dx9 conform sind?

Ja nv hatte eine eigene Vorstellung was die nächste Generation vn Shaderhardware anging konnte sich aber wohl nicht mit MS einig werden. Wie die Vorstellung aussihet kann man sich in den entsprechende OpenGL erweiterungen anschauen.

Sie benutzen eigenen Shadercode weil die für ATI Chips programmierten Shaderprogramme eben nicht zu ihrer Arichitktektur passen. In den neusten Treiber erzeugen die ausgetauschten Shader alle das richtige ergebniss.

Woher willst du das wissen das es rein nur an den Entwicklern liegt? Vorallem wenn ich aussagen von nwn entwicklern höere wie: "Das pixelshader wasser wäre auf ati hardware gar nicht möglich" Was eine lächerlich aussage ist vorallem wenn man bedenkt das ati seiner zeit im vergleich die flexiblere pixelshader hardware hatte als nvidia(r8500zuGF3,GF4).

Was auch immer dazu geführt hat das es für ATI Karten zuerst keine Shaderwasser gab solange es von den Entwickler keine vernüpftige Erklräung dazu gibt sind sie für mich ganz eindeutig schuld.

Warum unterstützt Nvidia ps1.4 nicht mit CG , welches in dx8.1 spez. ist. Das sind alles Anzeichen das Nvidia nicht für standards sind sondern sich nur darum kümmern sich ihre vorteile für ihre hardware zu schaffen als an die ganze insdustrie zu denken

Weil es schon bei 1.4 Shadern eine Rheie von optimierungsregeln zu beachten gibt welche aber nur ATI (und wahrscheinlich MS) komplett hat. Aus diesem Grund ist nVidia gar nicht in der Lage ein guten PS1.4 Profil anzubieten. Und da HLSL und CG Syntaxkonform sind macht es auch keinen grossen Sinn für 1.4 Pixelshader den Cg combíler nutzen zu wollen wo nVidia den Compiler von MS sowieso nicht schlagen könnte.

tEd

2003-08-10, 02:40:30

Original geschrieben von Demirug
Das entsprechende SDK ist noch eine closed BETA. Also nicht das vom normalen MS Server benutzten.

ich glaub nicht das ich da zugang zu hab

Codepath ist in diesem Zusammenhang ein unglücklicher Begriff. Richtige Codepfade gibt es mit DX für das Pixelprocesing sowieso nur 2. Den Für Shader (alle Versionen werden da gleich behandelt) und den alten DX7 Weg. Benutzt man D3DX gibt es aber die Option mit Effekten zu arbeiten und man braucht nur noch einen Codepfad für alle Karten weil die unterschide nicht mehr im Code sondern in den Effektdateien liegen.

Was aber nun bei NV3X und R3XX erforderlich ist sind unterschiedliche Assemblercodeshader. Das nächste SDK wird aber in der Lage sein entsprechende Shader für NV3X und R300 aus HLSL erzeugen zu können. Das aktuelle erzeugt immer für R3XX optimierten Code.

das ist sicher der richtige weg.

Ja nv hatte eine eigene Vorstellung was die nächste Generation vn Shaderhardware anging konnte sich aber wohl nicht mit MS einig werden. Wie die Vorstellung aussihet kann man sich in den entsprechende OpenGL erweiterungen anschauen.

Nvidia sollte sich einfach mal bewusst werden das sie nicht allein die herrschaft im 3d grafkarten markt haben , ihr verhalten ist manchmal einfach zu arrogant. ich habe einfach das gefühl das sie der meinung sind das alle sich alleine nach ihnen richten müssten und wenn das mal nicht der Fall ist dann schmollen sie wie ein kleines kind.

Sie benutzen eigenen Shadercode weil die für ATI Chips programmierten Shaderprogramme eben nicht zu ihrer Arichitktektur passen. In den neusten Treiber erzeugen die ausgetauschten Shader alle das richtige ergebniss.

Das mag wohl so sein nur ist das für mich kein Ausrede was sie in den letzten Monaten abgezogen habe. Sie haben mehrmals beschissen,gelogen,ergebnisse verfälscht und somit versucht kunden zu verarschen. Keine Firma ist in dieser Branche ein heiliges schäflein auch ati nicht aber irgenwo sollte es eine grenze geben welche nicht überschritten werden darf und nvidia hat diese grenze meiner meinung nach mehr als nur ein bisschen überschritten. Vorallem kann ich ich es nicht haben wenn bei direkter berfragung auf gewisse Erreignisse einfach auf dumm geschaltet wird , als wäre nichts passiert.

Was auch immer dazu geführt hat das es für ATI Karten zuerst keine Shaderwasser gab solange es von den Entwickler keine vernüpftige Erklräung dazu gibt sind sie für mich ganz eindeutig schuld.

Naja was soll ich sagen als Kunde(gamer) ist man dann sowieso letztendendes immer der arsch der in die röhre kuckt.

Weil es schon bei 1.4 Shadern eine Rheie von optimierungsregeln zu beachten gibt welche aber nur ATI (und wahrscheinlich MS) komplett hat. Aus diesem Grund ist nVidia gar nicht in der Lage ein guten PS1.4 Profil anzubieten. Und da HLSL und CG Syntaxkonform sind macht es auch keinen grossen Sinn für 1.4 Pixelshader den Cg combíler nutzen zu wollen wo nVidia den Compiler von MS sowieso nicht schlagen könnte.

Wenigstens unterstützen hätte man es können. ps1.4 ist ja nicht irgend ein geheimniss welches nur ati oder MS kennt , schliesslich müssen ja auch alle IHV welche ps2.0 hardware anbieten fähig sein ps1.4 code ausführen zu können.

Ich hätte hier eigentlich noch ein kommentar von einem nvida angestellten reinschreiben wollen , welcher die ganze geschichte mit ps1.4 und ati von nvidias seite aus betrachtet. Dieser wurde von dave baumann im beyond3d forum gepostet , das ist aber schon ein weilchen her und sehr wahrscheinlich werde ich diesen thread niemals wieder finden aber dieser kommentar war doch sehr shockierend und reflektiert recht gut das momentane unprofessionelle verhalten von nvidia gegenüber der öffentlichkeit.

Ailuros

2003-08-10, 03:36:11

...reflektiert recht gut das momentane unprofessionelle verhalten von nvidia gegenüber der öffentlichkeit.

Nur die PR/marketing Abteilung.

***edit:

Vielleicht hilft dieser Ausschnitt von Wavey:

NVIDIA have got a real bee in their bonnet about PS1.4. I was talking to a few guys at Dusk-till-dawn about it and they are unhappy that Futuremark have supported a technique that 'only a bunch of Canadians' have. I pointed out that "well, it is a part of DirectX afterall" to which the responce was "well, it shouldn't have been".

The fact is, it is in DX, its a viable rendering option, and games are supporting it (I have a big list...).

tEd

2003-08-10, 04:05:09

Original geschrieben von Ailuros
Nur die PR/marketing Abteilung.

wenn ich mir den letzten chat mit den softwarejungs von nvidia anschaue dann nicht unbedingt

tEd

2003-08-10, 04:07:30

Original geschrieben von Ailuros

NVIDIA have got a real bee in their bonnet about PS1.4. I was talking to a few guys at Dusk-till-dawn about it and they are unhappy that Futuremark have supported a technique that 'only a bunch of Canadians' have. I pointed out that "well, it is a part of DirectX afterall" to which the responce was "well, it shouldn't have been".

The fact is, it is in DX, its a viable rendering option, and games are supporting it (I have a big list...).

Vielleicht hilft dieser Ausschnitt von Wavey:

ja danke das hab ich gesucht...

Ailuros

2003-08-10, 04:43:15

Original geschrieben von tEd
wenn ich mir den letzten chat mit den softwarejungs von nvidia anschaue dann nicht unbedingt

Privat oder in aller Oeffentlichkeit? Falls (b) dann ist die Reaktion verstaendlich.

ja danke das hab ich gesucht...

Eine einfache Suche mit "DaveBaumann" "posts" und "PS1.4" hat geholfen (nur als Tipp fuer zukuenftige Versuche).

Peinliche Geschichten gibt es bei jedem IHV. Das oben ist eher harmlos ;)

Demirug

2003-08-10, 10:14:00

Original geschrieben von tEd
ich glaub nicht das ich da zugang zu hab

MS will es ja noch im Sommer Final machen. Viel ändert sich aber nicht. ES geht darum den Entwicklern das Leben leichter zu machen.

Nvidia sollte sich einfach mal bewusst werden das sie nicht allein die herrschaft im 3d grafkarten markt haben , ihr verhalten ist manchmal einfach zu arrogant. ich habe einfach das gefühl das sie der meinung sind das alle sich alleine nach ihnen richten müssten und wenn das mal nicht der Fall ist dann schmollen sie wie ein kleines kind.

Wenn man mal versucht das ganze einingermassen opjektiv zu betrachten so hat in der Vergangenheit jeder IHV (ausser die ganz kleinen) schon mal ein Feature in die DX Spec gedrückt das nur ihm etwas nutzt und dieses dann so gut wie möglich ausgeschlachtet.

Das mag wohl so sein nur ist das für mich kein Ausrede was sie in den letzten Monaten abgezogen habe. Sie haben mehrmals beschissen,gelogen,ergebnisse verfälscht und somit versucht kunden zu verarschen. Keine Firma ist in dieser Branche ein heiliges schäflein auch ati nicht aber irgenwo sollte es eine grenze geben welche nicht überschritten werden darf und nvidia hat diese grenze meiner meinung nach mehr als nur ein bisschen überschritten. Vorallem kann ich ich es nicht haben wenn bei direkter berfragung auf gewisse Erreignisse einfach auf dumm geschaltet wird , als wäre nichts passiert.

In den letzten Monaten? Dieses Spiel wird doch schon seit Jahren gespielt von allen. Und es gibt Brachen da ist das noch viel schlimmer. Ich kann da leider aus Erfahrung sprechen. Bei diesen Spielen gibt es keine Grenzen nur Risiko Nutzen abwägungen. Bis vor kurzem was das Risiko beim Benchmark beschiess gering aber der Nutzen enorm. Geradezu eine Einladung. Das man sich dumm stellt ist doch verständlich den wenn man etwas verleugnet könnte man am ende fällig sein wenn man aber angeblich von nichts etwas wusste ist man schön raus und kann im Zweifel noch einen Bauern opfern.

Das Geschäftsleben ist nun mal Krieg und ich habe auf zu vielen Positionen in solchen kriegen Schlachten geschlagen als das mich jemand davon überzeugen könnte das es jemals anders war oder anders sein wird.

Naja was soll ich sagen als Kunde(gamer) ist man dann sowieso letztendendes immer der arsch der in die röhre kuckt.

Natürlich das letze Glied in der Kette zahlt immer die Rechnung.

Wenigstens unterstützen hätte man es können. ps1.4 ist ja nicht irgend ein geheimniss welches nur ati oder MS kennt , schliesslich müssen ja auch alle IHV welche ps2.0 hardware anbieten fähig sein ps1.4 code ausführen zu können.

Ich sehe schon wieder einen PS 1.4 Flame auf uns zu kommen. Die Politik von nv ist hier eindeutig und aus iherer Sicht auch verständlich. nv hat keine Hardware welche von PS 1.4 Shadercode gegenüber 2.0 Shadercode profitieren könnte. Dazu kommt noch das Cg ein Lückenfüller ist der sich irgendwann verabschieden wird also wird nur das investiert was einen nutzwert (vorallem für nv) bringt. Aufgrund einer ARB entscheidung müssen wir aber nun wohl doch noch etwas länger mit Cg leben als ich ursprünglich gedacht haben. Cg war und ist derzeit aber noch wichtig aufgrund bestimmter Signalwirkungen auf den Markt.

Ich hätte hier eigentlich noch ein kommentar von einem nvida angestellten reinschreiben wollen , welcher die ganze geschichte mit ps1.4 und ati von nvidias seite aus betrachtet. Dieser wurde von dave baumann im beyond3d forum gepostet , das ist aber schon ein weilchen her und sehr wahrscheinlich werde ich diesen thread niemals wieder finden aber dieser kommentar war doch sehr shockierend und reflektiert recht gut das momentane unprofessionelle verhalten von nvidia gegenüber der öffentlichkeit.

Was soll man dazu jetzt grossartig sagen? Ich könnte jetzt Sun-Tzu zitieren aber lassen wir das. Nv betreibt den Versuch der Schadensbegrenzung und da es sehr viel Schaden zu begrenzen gibt wird die Stimmung da schnell gereitzt. Aber durch sowas muss jede Firma mal durch das stärkt den Charakter.

Razor

2003-08-10, 10:18:52

Original geschrieben von tEd
so ziemlich jedes humus demo.
http://esprit.campus.luth.se/~humus
sind zwar meistens opengl demos welche die arb_fragment_program extrension nutzen was aber ziemlich das euqivalent zu d3d ps2.0 sind IMO

das hier hat nette ps2.0 features
http://www.daionet.gr.jp/~masa/rthdribl/index.html

welches auf ati hardware um einiges besser läuft
Humus proggt auf ATI-Karten...
Mehr ist dazu eigentlich nicht zu sagen.

Original geschrieben von tEd
der ganzen dx9 shadermark tests.
Der Shadermark basiert auf ATI's Tresure-Chest-Demo...
Auch dazu sollte man eigentlich kein Wort verlieren.
Original geschrieben von tEd
du wirst zwar sicher nvidia treiber finden welche vielleicht in diesen demos /benchmarks sehr gut auf nv3x abschneiden(im vergleich zur ati hardware) nur kann ich dir sagen das dann nicht der code ausgeführt wurde welcher vom demjenigen developer welcher den benchmark/die demo geschrieben hat ausgeführt wurde.

Ich denke da gibts nichts zu diskutieren , es wurde bewiesen wie nvidia in den verschiedensten ps2.0 immer wieder den original code umgangen hat , das gilt sowohl für z.b 3dmark03 wie auch shadermark , welche gerne mal als benchmarks für grafikkarten reviews
benutzt werden.
Wie gesagt... die von Dir genannten Beispiele dürften ATI-optimiert sein.
Das einzige, was diese aussagen, ist, wie sich nVidia-Hardware in ATI-optimierten Situationen verhält.
nVidia dürfte das in einigen Bereichen einfach 'korrigiert' haben...
Original geschrieben von tEd
Ich glaube daran das man ps2.0 shader auf der nv3x architektur sehr schnell sein kann wenn der derjenige entwickler sehr viel zeit und mühe darin investiert .
Er muss einfach nur alle verfügbaren PS2-Zielpfade unterstützen und sich an die Devolper-Guidelines aller IHV's halten und schon läuft's auf jeder Hardware gut. Das einzige, was er dafür braucht, ist eine Hardware-Erkennungsfunktion (die er nicht einmal selber proggen muss), um das jeweilige Shader-Set auszuwählen. Und das compilieren der Shader muss er dann (derzeit) 2x machen (dauert dann je nach Umfang max. 5 min ?). Spezielle Codepfade braucht er dafür nicht, die sind immer gleich, nur das Compilat sollte auf die jeweilige Architektur ausgelegt sein...

Wo ist also das Problem ?
Original geschrieben von tEd
Doom3 ist sicher ein gutes beispiel. John carmack hat sich die mühe gemacht für die einzelnen karten verschiedene codepaths zu schreiben und auf die einzelnen karten zu optimieren, nur ist das eher die ausnahme.
Doom3 ist ein OpenGL-Game und hat mit PS2.0 aber auch rein gar nichts zu tun.
Darin gibt's Pfade für alle möglchen GraKa-Chips...

Razor

Demirug

2003-08-10, 10:59:42

Original geschrieben von Razor
Er muss einfach nur alle verfügbaren PS2-Zielpfade unterstützen und sich an die Devolper-Guidelines aller IHV's halten und schon läuft's auf jeder Hardware gut. Das einzige, was er dafür braucht, ist eine Hardware-Erkennungsfunktion (die er nicht einmal selber proggen muss), um das jeweilige Shader-Set auszuwählen. Und das compilieren der Shader muss er dann (derzeit) 2x machen (dauert dann je nach Umfang max. 5 min ?). Spezielle Codepfade braucht er dafür nicht, die sind immer gleich, nur das Compilat sollte auf die jeweilige Architektur ausgelegt sein...

Pro Shader in der Regel weniger als 1 Sekunde. Bei kurzen sogar < 100 ms. Das ganze ist eigentlich sogar schnell genug um es zur Laufzeit zu machen.

Pitchfork

2003-08-10, 12:44:53

Original geschrieben von Demirug
Dazu kommt noch das Cg ein Lückenfüller ist der sich irgendwann verabschieden wird also wird nur das investiert was einen nutzwert (vorallem für nv) bringt. Aufgrund einer ARB entscheidung müssen wir aber nun wohl doch noch etwas länger mit Cg leben als ich ursprünglich gedacht haben. Cg war und ist derzeit aber noch wichtig aufgrund bestimmter Signalwirkungen auf den Markt.

Original geschrieben von Richard Huddy
Guys,

>Of course you're right.
>Ok, no more Cg questions.

And also please note that NVIDIA's line seems to now be that Cg is 'almost
legacy' (my words, not theirs). They were asked at SIGGRAPH which language
to prefer and in open conference stated that HLSL is the preferred language
to use on DirectX and OpenGL's High Level shading language is to be
preferred when using OpenGL.

Assuming that this is the company line, I guess this whole issue will
therefore go away soon and we can return to a more pure technical
discussion.

I agree that tools with Cg integrated will remain as an issue since it will
clearly take some little time before they are all upgraded to use HLSL etc,
but realistically I believe that the language war is pretty much over.

[I'm sure someone from NVIDIA will be quick to correct me if I have wrongly
represented their position.]

Thanks,

Richard "7 of 5" Huddy
European Developer Relations Manager, ATI

Razor

2003-08-10, 13:02:47

Original geschrieben von Demirug
Pro Shader in der Regel weniger als 1 Sekunde. Bei kurzen sogar < 100 ms. Das ganze ist eigentlich sogar schnell genug um es zur Laufzeit zu machen.
Gut, dass ich ein Fragezeichen setzte, gell ?
;-)

Wollte nur verdeutlichen, dass es (so gut wie) KEINEN Aufwand bedeutet, hier verschiedene Zielsysteme anzusprechen. Offenbar hat tEd hier was durcheinander bekommen und verwechselte Codepaths mit Goalpaths (meine Übersetzung ;-).

Egal, vielleicht wäre es tatsächlich sinnvoller, wenn die Shader in Form des Source-Codes übergeben werden. So wäre dann eine Benachteiligung eines bestimmten IHV's nur den eigenen Treiber-Programmierern anzulaseten.

Razor

Demirug

2003-08-10, 13:08:12

Pitchfork, meine email addresse ist auch in dem Listserver eingetragen.

Ich sehe da aber keinen grossen Wiederspruch zwischen dem was Huddy schreibt und dem was ich schreibe. Nur über den Zeitraum gibt es wohl unterschiedliche Meinungen.

Auf der DX Ebene sind nachdem MS nun Chip spezifische Profile anbieten wird compiler direkt von den IHVs relative überflüssig geworden. DX & Cg da ist der Vorhang gefallen ausser nV baut da noch ein DX7 Profile ein womit aber nicht zu rechnen ist.

Auf dem OpenGL Level sehe ich das nicht so optimistisch wie Huddy es darstellt. Gerade veranstalltungen wie die Siggraph werden doch immer "misbraucht" um neue Technologien zu puschen. Aber was nützt glslang dem armen Entwickler der auch noch die ganzen pre DX9 Level Chips unterstüzen soll? Cg stellt da derzeit noch die beste möglichkeit dar mit einem einzigen Codepfad die meisten Chips zu unterstüzen.

Und dan bleibt da noch die wunderbare Welt der Multi-API Engine die aber ständig kleiner wird und daher wohl keine Betrachtung mehr bedarf.

Pitchfork

2003-08-10, 13:32:18

Ich habe mit dem Zitat eher einen indirekten Beleg deiner These bringen wollen, keinen Widerspruch. Auch wenn nV natürlich diese Aussage unkommentiert gelassen hat.
Wegen MultiAPI Engine: da muß man sich glaube ich nix vormachen. Es dürfte kaum Gründe geben, die wertvollen nv Entwicklungsresourcen in diesen Bereich zu investieren.

Demirug

2003-08-10, 13:40:46

Original geschrieben von Pitchfork
Ich habe mit dem Zitat eher einen indirekten Beleg deiner These bringen wollen, keinen Widerspruch. Auch wenn nV natürlich diese Aussage unkommentiert gelassen hat.

Hatte ich mir schon fast gedacht. Ich vermute auch das der Teil von nvidias Cg Team welcher für die DX Profile zuständig ist/war gerade in Redmond ist. Langfristig ist das für nv sicher auch die günstigere Lösung. Die gewonnen Erfahrung wird aber sicherlich dem OpenGL 1.5 (FKA OpenGL 2.0) Treiber zu gute kommen.

Wegen MultiAPI Engine: da muß man sich glaube ich nix vormachen. Es dürfte kaum Gründe geben, die wertvollen nv Entwicklungsresourcen in diesen Bereich zu investieren.

Ja sehe ich auch so.

reunion

2003-08-10, 13:53:47

Original geschrieben von Razor
Humus proggt auf ATI-Karten...
Mehr ist dazu eigentlich nicht zu sagen.

Der Shadermark basiert auf ATI's Tresure-Chest-Demo...
Auch dazu sollte man eigentlich kein Wort verlieren.

Razor

Und was ist z.b.: mit Aquanox 2, Unreal 2 oder Splinter Cell, wo die nv Karten allesamt total versagen?? Und die fx5900ultra mit mühe die hälfte fps der 9800pro erreicht. Siehs ein razor Nv hat eine schlechte PS bzw. VS Shader Leistung. Du glaubst doch nicht ernsthalft das alle bis jetzt erschienenen PS bzw. VS Tests auf ATI optimiert sind.

Gast

2003-08-10, 16:48:00

wenn sie mit dem MS compiler gemacht wurden dann ja.

Demirug

2003-08-10, 16:51:17

Original geschrieben von reunion
Und was ist z.b.: mit Aquanox 2, Unreal 2 oder Splinter Cell, wo die nv Karten allesamt total versagen?? Und die fx5900ultra mit mühe die hälfte fps der 9800pro erreicht. Siehs ein razor Nv hat eine schlechte PS bzw. VS Shader Leistung. Du glaubst doch nicht ernsthalft das alle bis jetzt erschienenen PS bzw. VS Tests auf ATI optimiert sind.

reunion, du hast ein bischen recht und razor hat ein bischen recht.

Der 2.0 Pixelshadercode den ich bisher gesehen habe (Shadermark, Humus Demos, 3dMark, Aquanox 2) war immer mehr oder weniger stark nach den ATI regeln programmiert. 1.4 Shader sind ja schon aufgrund der von ATI durch MS vorgschrieben Struktur immer nach ATI Regeln programmiert. Aber neutral (was leider gar nicht geht) oder gar nach nv Regeln war da keiner. Das ist verständlich wenn man sich anschaut wie oder wann die ganzen Programmen entstanden sind.

Nun würde Pixelshader welche nach den NV-Regeln geschrieben wurden den FXen erst mal helfen aber mit den aktuellen Treibern auch nicht direkt auf den R300 Level heben. Da fehlt einfach die direkt und einfach zu nutzende Power. Es ist allerdings noch Rechenpower in der Pixelpipeline vorhanden die ein entsprechender Treiber freisetzten könnte aber bei der pro Takt Leistung wird bestenfalls der NV35 an den R350 herankommen.

Das beseitigen von Begrenzungen bei den Pixelshadern hatte leider einen recht hohen Preis für nVidia. Hätte ATI mit dem R300 nicht so hervoragende Arbeit geleistet und gnadenloss das R200 Design ausgeschlachtet und auf Leistung getrimmt wäre das nicht so heftig aufgefallen. So muss jetzt nVidia durch das grosse Tal der Tränen. Es bleibt noch abzuwarten wie viel ATI und die anderen IHVs für den Technologiewechsel zahlen müssen.

LovesuckZ

2003-08-10, 16:57:15

Demirug,

also werden auch weitere Detos keine großartigen Performancesprünge
im Sachen Pixelshader nach DX8 bringen?
Denn ich meine, dass eine 5900 Ultra 20-30% hinter einer 9800pro in Unreal2 oder Splinter Cell zurueck liegt, sollte eigentlich nicht sein...

zeckensack

2003-08-10, 17:00:46

Original geschrieben von mapel110
die mühe muss man sich wohl oder übel unter opengl machen. andere hersteller=andere extensions ARB_fragment_program ist für den DX9-Techlevel herstellerneutral.

NV kann von niemandem erwarten, zusätzlich einen NV_fragment_program-Pfad einzubauen. Wenn sie mit dem Shader-Code nicht klar kommen, steht ihnen völlig frei im Treiber die Instruktionssequenzen umzusortieren. ATI macht das schon seit dem R300-Launch für PS1.x (und entsprechend unter OpenGL für ATI_fragment_shader).
Aber eben nicht als dümmstmögliche App-spezifische Holzhammer-Anpassung, sondern als allgemeingültige Optimierung, die über jeden Shadercode drüberläuft.

Das gleiche wäre auch ein gangbarer Weg für DX9/PS2.0 gewesen. Aber Rumjammern und das Erzwingen eines neuen SDKs liegen wohl eher auf NV's Linie.

Demirug

2003-08-10, 17:09:35

Original geschrieben von LovesuckZ
Demirug,

also werden auch weitere Detos keine großartigen Performancesprünge
im Sachen Pixelshader nach DX8 bringen?
Denn ich meine, dass eine 5900 Ultra 20-30% hinter einer 9800pro in Unreal2 oder Splinter Cell zurueck liegt, sollte eigentlich nicht sein...

Woran es bei Unreal2 und Splinter Cell liegt kann ich nicht sagen. Ein Performancesprung bei PS ist aber durchaus noch zu erwarten. Allerdings sind 1.1-1.3 Shader zu kurz als das es sich da wirklich auswirken könnte. Je Länger der Shader desto mehr wird sich herausholen lassen.

Demirug

2003-08-10, 17:20:17

Original geschrieben von zeckensack
ARB_fragment_program ist für den DX9-Techlevel herstellerneutral.

NV kann von niemandem erwarten, zusätzlich einen NV_fragment_program-Pfad einzubauen. Wenn sie mit dem Shader-Code nicht klar kommen, steht ihnen völlig frei im Treiber die Instruktionssequenzen umzusortieren. ATI macht das schon seit dem R300-Launch für PS1.x (und entsprechend unter OpenGL für ATI_fragment_shader). Aber eben nicht als dümmstmögliche App-spezifische Holzhammer-Anpassung, sondern als allgemeingültige Optimierung, die über jeden Shadercode drüberläuft.

Was muss ATI bei den 1.x Shader gross umsortieren? 1.4 entspricht der Hardware. Bei 1.1-1.3 kann der ALU-Teil 1:1 übernommen werden. Nur die maximal 4 Befehle des Textureteils müssen unter umständen etwas angepasst werden aber das ist eher ein Makroreplacement als eine aufwendige Optimierung.

Das gleiche wäre auch ein gangbarer Weg für DX9/PS2.0 gewesen. Aber Rumjammern und das Erzwingen eines neuen SDKs liegen wohl eher auf NV's Linie.

Klar können sie umsortieren aber an der Reihenfolge der Anweisungen kranken die NV3X Chips gar nicht mal so sehr wie ich inzwischen lernen musste. Das Hauptproblem liegt in der Anzahl der benutzten Tempregister. Und das lässt sich mit ein bischen umsortieren leider nicht lösen da muss neu compiliert werden.

Öhm du weist aber schon warum es ein neues SDK gibt? Es mag ja sein das nv jetzt jammert das MS sich mal beeilen soll aber ATI hat damals ja auch gejammert und eine public BETA-Version bekommen.

zeckensack

2003-08-10, 17:34:47

Original geschrieben von Demirug
Was muss ATI bei den 1.x Shader gross umsortieren? 1.4 entspricht der Hardware. Bei 1.1-1.3 kann der ALU-Teil 1:1 übernommen werden. Nur die maximal 4 Befehle des Textureteils müssen unter umständen etwas angepasst werden aber das ist eher ein Makroreplacement als eine aufwendige Optimierung.ATI betreibt vollständige Flow-Anaylse und Rekompilierung (inklusiver neuer Register-Zuweisung) aller Shader. Auch PS1.4 auf R200 wird rekompiliert, wie ich erst kürzlich auf Umwegen erfahren habe.

Klar können sie umsortieren aber an der Reihenfolge der Anweisungen kranken die NV3X Chips gar nicht mal so sehr wie ich inzwischen lernen musste. Das Hauptproblem liegt in der Anzahl der benutzten Tempregister. Und das lässt sich mit ein bischen umsortieren leider nicht lösen da muss neu compiliert werden.Korrekt. Das ist immer so, wenn eine neue HW-Generation kommt, das wissen auch die IHVs. Zu ATI liegt ein Anekdotenbeweis vor, bei NV leider nicht. Vielleicht tut NV das auch, behält das aber für sich, weil sie sonst den Foren-Bewohnern dieser Welt die letzten Argumente nehmen würden, keine Ahnung :|

Das Assembler-Modell von DX9 ist hier der eigentliche Griff ins Klo, weil explizite Register-Zuweisung in einer herstellerübergreifenden Sprache einfach nichts zu suchen hat. Ich wette bei MS lachen sich die Leute kaputt über Typen wie uns, die hier die Schuld zwischen den IHVs hin- und herschieben, und die eigentliche Ursache des 'Problems' darüber vergessen.
Öhm du weist aber schon warum es ein neues SDK gibt? Es mag ja sein das nv jetzt jammert das MS sich mal beeilen soll aber ATI hat damals ja auch gejammert und eine public BETA-Version bekommen. Das ist irrelevant. Wenn MS ihre Software nicht auf die Reihe bekommen, ist das nun wirklich nicht mein Problem.

ATI hatte fertige Hardware auf dem Markt und brauchte irgendein DX9. MS mal ein bisschen in den Hintern zu treten, war exakt die richtige Strategie.

Wenn NV jetzt ein 'anderes' DX9 braucht, dann ist das aus technischer Sicht überflüssig, nichts weiter als eine nette Hinhaltetaktik.

Den Recompiler müssen sie sowieso schreiben, spätestens wenn sie mal wieder neue Hardware bringen (NV40 ahoi!?).

Mr. Lolman

2003-08-10, 17:36:05

Warum läuft eigentlich GTA Vice City auf ATi Hardware soviel besser, als auf NV Hw? Werden in dem Spiel Pixelshader ueberhaupt benutzt??

Oder bei NOLF2 in 1024x768, 4xAA ist eine 256MB FX5900 Ultra auch mehr als 10% hinter einer 9700pro zu finden, also etwas ueber 9700 Niveau. (in 1600x1200, 4xAA ist sie rechnerisch sogar etwas langsamer als die 9700 (!!!)

(Quelle (http://www.gamepc.com/labs/view_content.asp?id=3x5900u&page=9))

Werden denn in den genannten Spielen auch ATi optimierte Pixelshader >1,3 eingesetzt?

AFAIK nicht...

Demirug

2003-08-10, 17:53:01

Original geschrieben von zeckensack
ATI betreibt vollständige Flow-Anaylse und Rekompilierung (inklusiver neuer Register-Zuweisung) aller Shader. Auch PS1.4 auf R200 wird rekompiliert, wie ich erst kürzlich auf Umwegen erfahren habe.

Wenn du es sagst wird es wohl stimmen. nv macht es ja AFAIK auch für PS 1.1-1.3 um die Regcombiner besser zu nutzen. Bei den kurzen 1.X Shader wird man da aber in der Regel kaum was rausholen können. Wobei 1 Takt weniger da ja schon viel ist.

Das ATI bei den 2.0 Shader Skalaranweisungen verschiebt ist ja bekannt.

Korrekt. Das ist immer so, wenn eine neue HW-Generation kommt, das wissen auch die IHVs. Zu ATI liegt ein Anekdotenbeweis vor, bei NV leider nicht. Vielleicht tut NV das auch, behält das aber für sich, weil sie sonst den Foren-Bewohnern dieser Welt die letzten Argumente nehmen würden, keine Ahnung :|

Das Assembler-Modell von DX9 ist hier der eigentliche Griff ins Klo, weil explizite Register-Zuweisung in einer herstellerübergreifenden Sprache einfach nichts zu suchen hat. Ich wette bei MS lachen sich die Leute kaputt über Typen wie uns, die hier die Schuld zwischen den IHVs hin- und herschieben, und die eigentliche Ursache des 'Problems' darüber vergessen.

Fliesspunktshader werden nach meinem Kenntnissstand derzeit im Savemode auf die Hardware umgesetzt. Das heist alles 1:1. Dabei verschenkt man aber leider fleisig Leistung.

Register in DX9 Assembler sind eigentlich nur Variablenname. Wenn der Treiber aber so faul ist die 1:1 einfach zu übernehmen ist das natürlich eine andere sache.

Das ist irrelevant. Wenn MS ihre Software nicht auf die Reihe bekommen, ist das nun wirklich nicht mein Problem.

ATI hatte fertige Hardware auf dem Markt und brauchte irgendein DX9. MS mal ein bisschen in den Hintern zu treten, war exakt die richtige Strategie.

Wenn NV jetzt ein 'anderes' DX9 braucht, dann ist das aus technischer Sicht überflüssig, nichts weiter als eine nette Hinhaltetaktik.

Den Recompiler müssen sie sowieso schreiben, spätestens wenn sie mal wieder neue Hardware bringen (NV40 ahoi!?).

An DX9 wird doch gar nichts geändert mit dem neuen SDK. Das neue SDK erweitert D3DX auf 2.X Shader. Das wurde damals leider nicht mehr ganz fertig weil ja plötzlich gerusht wurde.

Ich glaube nicht das NV40 einen anderen Recompiler als NV30 braucht. Aber schreiben müssen sie ihn auf jeden Fall. Dumm nur das ihr absoluter Fachman für genau diesen den Job ja jetzt einen auf Prof macht.

Exxtreme

2003-08-10, 19:32:23

Original geschrieben von Razor

Egal, vielleicht wäre es tatsächlich sinnvoller, wenn die Shader in Form des Source-Codes übergeben werden. So wäre dann eine Benachteiligung eines bestimmten IHV's nur den eigenen Treiber-Programmierern anzulaseten.

Razor
Mega-Full-Ack!

Leider sind viele Programmierer "erzkonservative Kontrollfreaks". ;)

Sobald man nämlich die HLSL-Shader an den Compiler im Treiber übergibt, gibt man Kontrolle ab.

Und von den Programmierern hat sich Micro$~1 wohl einlullen lassen. Die Lösung mit den verschiedenen Shader-Profilen ist IMHO keineswegs als "gut" zu bewerten. Da haben nämlich die Endanwender und vor allem die IHVs nur Nachteile davon. Der Endanwender mit exotischerer HW hat keinen optimierten Shader zur Verfügung wenn der Publisher abwinkt und die IHVs müssen nämlich neben dem HLSL-Compiler noch versuchen eine LLSL-Optimierung in die Treiber einzubauen um "konkurrenzfähig" zu sein. Auch eine Shadererkennungs- und Austauschroutine, um in Benchmarks und Benchmark-Spielen gut auszusehen, bindet Resourcen, welche man in den HLSL-Compiler besser reingesteckt hätte.

Aber ich noch niemals etwas gesehen, was Micro$~1 richtig gut hingekriegt hätte. ;)

zeckensack

2003-08-10, 19:49:08

Original geschrieben von Exxtreme
Aber ich noch niemals etwas gesehen, was Micro$~1 richtig gut hingekriegt hätte. ;) Ich auch nicht. Ich denke da gerne auch an Trivial-Funktionen wie zB ShowCursor. Da läuft's mir eiskalt den Rücken runter.

Das ganze läuft IMO darauf hinaus, daß DX9 zwar nicht "gut", aber "reparabel" ist, im Sinne von "durch den Treiber nachkorrigierbar". Genauso wie ShowCursor reparabel ist.
Neue Shader-Profile für jeden Fliegenschiss wirken dem leider direkt entgegen ... was passiert zB, wenn ATI den F-Buffer fertigbekommt, und damit auch PS2_a-fähig ist? Noch mehr sinnlos verballerte Energie.

Ailuros

2003-08-10, 20:08:10

...was passiert zB, wenn ATI den F-Buffer fertigbekommt, und damit auch PS2_a-fähig ist? Noch mehr sinnlos verballerte Energie.

Noch nicht fertig ist auch nur eine Theorie. Bei ATI (nicht dass es bei anderen anders ist heh) wenn mal was nicht von Anhieb an laeuft, dann ist meistens ein Hardware-bug da. F-buffer koennte man zwar zum laufen bringen in dem Fall, aber Gott weiss was es dann noch brechen koennte ;)

Demirug

2003-08-10, 20:18:06

Nur F-Buffer reicht nicht für 2_A.

2_A ist eigentlich nur ein 2_X profil mit vordefiniertem Variabeln.

Das mit dem Shaderassembler ist sicherlich nicht Ideal aber direkt Hochsprachen Sourcecode dem Treiber vorzusetzen hat genauso seine Gefahren. Deswegen bin ich ja für eine zwischenlösung mit Bytecode.

Aber wenn man sich die Diskussionen auf den D3D Boards oder Listen anschaut so würde man noch nicht mal Bytecode bei den meisten durchbekommen. Da glauben wirklich noch viele das die Grafikchips wirklich den Shaderassemblercode 1:1 direkt so ausführen und sie die volle Kontrolle hätten.

MS hat zwar durchaus viel Macht aber wenn sich die Mehrheit der Entwickler in Sachen Shaderhochsprache querstellt haben sie auch ein Problem es durchzudrücken.

Exxtreme

2003-08-10, 20:24:21

Original geschrieben von Demirug

Das mit dem Shaderassembler ist sicherlich nicht Ideal aber direkt Hochsprachen Sourcecode dem Treiber vorzusetzen hat genauso seine Gefahren.

Naja, die einzige Gefahr, die ich sehe, ist daß der Compiler im Treiber fehlerhaft und das Ergebnis dadurch von Treiber abhängig sein könnte. Diese Gefahr besteht aber in einer LLSL-Optimierung auch.
Original geschrieben von Demirug
MS hat zwar durchaus viel Macht aber wenn sich die Mehrheit der Entwickler in Sachen Shaderhochsprache querstellt haben sie auch ein Problem es durchzudrücken.
Naja, da gibt's schon Mittelchen und Wege. M$ hätte die Verwendung von LLSL so kompiziert machen können, daß die Entwickler freiwillig davon abgesprungen wären. ;)

Demirug

2003-08-10, 20:34:47

Original geschrieben von Exxtreme
Naja, die einzige Gefahr, die ich sehe, ist daß der Compiler im Treiber fehlerhaft und das Ergebnis dadurch von Treiber abhängig sein könnte. Diese Gefahr besteht aber in einer LLSL-Optimierung auch.

Das ist mein kleinstes Problem. Das kann man ja im Notfall nit einem Treiberupdate fixen. Ich sehe da eher die Gefahr das die Hardware featuretechnisch auseinader streben könnte. Weil man ja jeden Mist über eine reine Textsource zugänglich machen kann. Da fehlt dann irgendwo ein minimallevel auf den man mindestens aufsetzten kann.

Naja, da gibt's schon Mittelchen und Wege. M$ hätte die Verwendung von LLSL so kompiziert machen können, daß die Entwickler freiwillig davon abgesprungen wären. ;)

Etwas nachträglich komplizierter zu machen ist eine sehr unpopläre Massnahme. Was glaubst du wie viele Entwickler dann einfach erst mal bei DX8 geblieben wären?

Und was noch wichtiger ist wie willst du es kompliziert machen eine LLSL zu benutzen? Egal welche Schweinerei sich MS da hätte einfallen lassen es hätte nicht lange gedauert bis jemand etwas programmiert hätte was die Sache wieder auf den alten Level gebracht hätte.

zeckensack

2003-08-10, 20:35:08

Original geschrieben von Demirug
Nur F-Buffer reicht nicht für 2_A.

2_A ist eigentlich nur ein 2_X profil mit vordefiniertem Variabeln.

Das mit dem Shaderassembler ist sicherlich nicht Ideal aber direkt Hochsprachen Sourcecode dem Treiber vorzusetzen hat genauso seine Gefahren. Deswegen bin ich ja für eine zwischenlösung mit Bytecode.Bytecode wäre sehr gut, es gibt auch durchaus gute Argumente, eine offene Bytecode-Schnittstelle alternativ zu Treiber-integrierten Hochsprachen zu bringen.
Es läuft darauf hinaus, daß
1)Bytecode schneller zu parsen ist (IMO nicht besonders wichtig)
2)Man je nach Geschmack auch andere Hochsprachen nutzen kann, wenn jemand ein Front-End dafür schreibt.

Unter'm Strich würde ich Hochsprachen-Code favorisieren. Wenn man es richtig macht ist der Unterschied allerdings derart klein, daß es sich nicht großartig lohnt darüber zu streiten.
Aber wenn man sich die Diskussionen auf den D3D Boards oder Listen anschaut so würde man noch nicht mal Bytecode bei den meisten durchbekommen. Da glauben wirklich noch viele das die Grafikchips wirklich den Shaderassemblercode 1:1 direkt so ausführen und sie die volle Kontrolle hätten.Wenn ich ausgehend vom OGL.org-Forum generalisieren darf, dann weiß die große Mehrzahl der Leute, die sich auf Dev-Boards herumtreiben, überhaupt nicht wovon sie reden :|
Wirkliches Verständnis für Zusammenhänge kann man höchstens von 10~15% der Leute erwarten.
MS hat zwar durchaus viel Macht aber wenn sich die Mehrheit der Entwickler in Sachen Shaderhochsprache querstellt haben sie auch ein Problem es durchzudrücken.Haben Software-Entwickler wirklich signifikanten Einfluß auf MS' API-Design?
Will MS es sich wirklich leisten, nur aufgrund von ISVs einen Weg zu gehen, der sie im Nachhinein noch sehr viel Arbeit kosten wird?
Ich befürchte viel eher, daß MS selbst nicht so genau weiß, wie man eine saubere API entwirft.

Exxtreme

2003-08-10, 20:43:23

Original geschrieben von Demirug
Das ist mein kleinstes Problem. Das kann man ja im Notfall nit einem Treiberupdate fixen. Ich sehe da eher die Gefahr das die Hardware featuretechnisch auseinader streben könnte. Weil man ja jeden Mist über eine reine Textsource zugänglich machen kann. Da fehlt dann irgendwo ein minimallevel auf den man mindestens aufsetzten kann.

Also das verstehe ich jetzt nicht. ?-)

Das API würde Microsoft definieren. Und es wäre halt verboten, eigene Funktionen einzufügen. :)

zeckensack

2003-08-10, 20:51:49

Original geschrieben von zeckensack
Wenn ich ausgehend vom OGL.org-Forum generalisieren darf, dann weiß die große Mehrzahl der Leute, die sich auf Dev-Boards herumtreiben, überhaupt nicht wovon sie reden :|
Gnarf! (http://www.opengl.org/discussion_boards/ubb/Forum7/HTML/000400.html)

Demirug

2003-08-10, 20:52:00

Original geschrieben von zeckensack
Bytecode wäre sehr gut, es gibt auch durchaus gute Argumente, eine offene Bytecode-Schnittstelle alternativ zu Treiber-integrierten Hochsprachen zu bringen.
Es läuft darauf hinaus, daß
1)Bytecode schneller zu parsen ist (IMO nicht besonders wichtig)
2)Man je nach Geschmack auch andere Hochsprachen nutzen kann, wenn jemand ein Front-End dafür schreibt.
Unter'm Strich würde ich Hochsprachen-Code favorisieren. Wenn man es richtig macht ist der Unterschied allerdings derart klein, daß es sich nicht großartig lohnt darüber zu streiten.

Bytecode hat noch einen weiteren Vorteil. Das festlegen und validiren von bestimmten mindestanforderungen an die Shaderhardware ist damit einfacher.

Wenn ich ausgehend vom OGL.org-Forum generalisieren darf, dann weiß die große Mehrzahl der Leute, die sich auf Dev-Boards herumtreiben, überhaupt nicht wovon sie reden :|
Wirkliches Verständnis für Zusammenhänge kann man höchstens von 10~15% der Leute erwarten.

Ja das geht bei den DX jungs genauso zu. Eher noch Schlimmer seit DX den Mytos das ja alles so Kompliziertsei verliert

Haben Software-Entwickler wirklich signifikanten Einfluß auf MS' API-Design?

Ja wobei der Einfluss davon abhängt für wie kompetent man von MS gehalten wird. Aber Vorschläge darf man jederzeit machen. Das letzte Wort hat aber MS und die IHVs.

Will MS es sich wirklich leisten, nur aufgrund von ISVs einen Weg zu gehen, der sie im Nachhinein noch sehr viel Arbeit kosten wird?
Ich befürchte viel eher, daß MS selbst nicht so genau weiß, wie man eine saubere API entwirft.

MS muss zwei Parteien zufrieden stellen. Die IHVs und die ISVs und das jeweils schnell.

Bei den Shadern steht MS aber nun vor einem wirklich grossen Problem. Sie müssen eine zu 100% validirbare Schnittstelle haben. Das heist das es möglich sein muss nur aufgrund einer Liste von Daten (welche vom IHV kommt) prüfen zu können ob ein Shader auf dieser Hardware läuft oder nicht. Wenn du einen Vorschlag hast wie man das auf andere weise lösen kannst als es jetzt gemacht wird würde mich das interesieren. Selbst mit Bytecode dürfte das noch recht problematisch werden.

Demirug

2003-08-10, 20:56:10

Original geschrieben von Exxtreme
Also das verstehe ich jetzt nicht. ?-)

Das API würde Microsoft definieren. Und es wäre halt verboten, eigene Funktionen einzufügen. :)

- Codelänge
- Anzahl der gleichzeitig aktiven lokalen Variablen
- Anzahl und Art der dependet Aktionen

Dafür bedarf es keinen Syntax Änderungen oder neuer Funktionen.

Razor

2003-08-10, 22:04:37

Razor

2003-08-10, 22:06:25

Original geschrieben von Mr. Lolman
Warum läuft eigentlich GTA Vice City auf ATi Hardware soviel besser, als auf NV Hw?
(Quelle (http://www.gamepc.com/labs/view_content.asp?id=3x5900u&page=9))
Siehe vorherigen Post... AF-'Optimierung' (oder Cheat) bei ATI.

Razor

nagus

2003-08-10, 22:25:07

Original geschrieben von Razor
Siehe vorherigen Post... AF-'Optimierung' (oder Cheat) bei ATI.

Razor

*MEGALOL*

du bezichtigst ATI des cheatings?? *MUAAHAHAHAHAHAHA*

du bringst mich immer wieder zum lachen, genau wie LovesuckZ ;)

2003-08-10, 22:29:22

Original geschrieben von zeckensack
Gnarf! (http://www.opengl.org/discussion_boards/ubb/Forum7/HTML/000400.html)

;D lol, sag ich da nur ;D

Razor

2003-08-10, 23:08:55

Original geschrieben von nagus
du bringst mich immer wieder zum lachen, genau wie LovesuckZ ;)
Schön... wo Lachen doch sooooo gesund ist !
:D

Razor

P.S.: Du weißt aber schon, was der Unterschied zwischen 'Optimierung' und 'Cheat' ist ? Richtig, 'Cheat' ist eine 'Optimierung' zulasten der Bildqualität (= BQ ;-). Dass ATI dies bei allen Applikationen macht, macht die Sache nicht besser... auch wenn es nur bei wenigen davon eine visuelle Beeinträchtigung bedeutet... nur ist es bei denen dann keine Optimierung mehr, sondern eben ein Cheat.

Exxtreme

2003-08-10, 23:33:46

Original geschrieben von Razor

P.S.: Du weißt aber schon, was der Unterschied zwischen 'Optimierung' und 'Cheat' ist ? Richtig, 'Cheat' ist eine 'Optimierung' zulasten der Bildqualität (= BQ ;-).

Soweit Ack!
Original geschrieben von Razor
Dass ATI dies bei allen Applikationen macht, macht die Sache nicht besser... auch wenn es nur bei wenigen davon eine visuelle Beeinträchtigung bedeutet... nur ist es bei denen dann keine Optimierung mehr, sondern eben ein Cheat.
Wo senkt ATi die Bildqualität?

Ailuros

2003-08-11, 03:04:17

Falls Du die Quality-Leistung meinst... ATI-AF-Optimierung !
Wenn Du diesen 'Vorteil' abziehst, dann dürfte die Leistung ungefähr vergleichbar sein...
(bringt ca. 20-30% ;-)

GeForceFX:

Qualität/Quality Filtermodus
Die trilineare Filterung auf der Stage 0 wird nur für ca. der Hälfte aller Pixel angewandt.
Die trilineare Filterung auf den Stages 1-7 ist nur noch ein ganz schmales Band zwischen den MipMaps.
Texturen auf der Stage 0 bekommen den maximalen Level an anisotroper Filterung.
Texturen auf den Stages 1-7 bekommen maximal einen Level an anisotroper Filterung von 2.

http://www.3dcenter.de/artikel/ati_nvidia_treiberoptimierungen/index9.php

Im genauen wird unter dem anisotropen Filter bei ATi nur die Basis-Textur ("Texture Stage 0") trilinear gefiltert, alle weiteren Texturen ("Texture Stage 2-7") dagegen dann nur bilinear. Dieser Verhalten des ATi-Treibers gilt dabei für alle Anwendungen, sofern diese im anisotropen Modus betrieben werden.

http://www.3dcenter.de/artikel/ati_nvidia_treiberoptimierungen/index6.php

Und ja die Winkelabhaengigkeit sollte erwaehnt werden, nur faellt die Filterung auf Level2x bei 22 und 67 Grad Winkeln zurueck auf allen texturing stages, wobei aber im ersten Fall texturing stages 1-7 von 0 bis 360Grad auf Level2x zurueckfallen.

Die Leistungs-Unterschiede werden im Review (den Du sicher schon gelesen hast) mit Anti-Cheat Scripten illustriert. Ich sehe dass die Radeon weniger an Leistung verliert mit den Scripten.

Wenn es schon zur Bildqualitaet kommen sollte, dann sollte man nicht nur die Vor- sondern auch die Nachteile erwaehnen. Um einen 4*4 EER zu erreichen ist eine FX um ungefaehr 60-70% langsamer, in der gleichen Aufloesung.

PS: adaptive anisotropische Filterung basiert nun mal meistens auf Optimierungen. Wenn heutige Karten voll trilineares 8x oder 16x sample Anisotropic von 0 bis 360 Grad fuer alle texturing stages anwenden wuerden, waere die Leistung fuer alle umso einiges schlechter. Der FX - High performance modus sieht uebrigens aeusserst uebel aus in real-time.

mapel110

2003-08-11, 03:12:30

Original geschrieben von Razor
Siehe vorherigen Post... AF-'Optimierung' (oder Cheat) bei ATI.

Razor

lass dir mal gesagt sein, dass nicht alle spiele von der AF optimierung gleich viel profitieren bzw es überhaupt tun
http://www.3dcenter.org/artikel/ati_nvidia_treiberoptimierungen/index8_e.php

LovesuckZ

2003-08-11, 08:52:42

Original geschrieben von Ailuros
Und ja die Winkelabhaengigkeit sollte erwaehnt werden, nur faellt die Filterung auf Level2x bei 22 und 67 Grad Winkeln zurueck auf allen texturing stages, wobei aber im ersten Fall texturing stages 1-7 von 0 bis 360Grad auf Level2x zurueckfallen.

Dies gilt nur für ut2003.

Die Leistungs-Unterschiede werden im Review (den Du sicher schon gelesen hast) mit Anti-Cheat Scripten illustriert. Ich sehe dass die Radeon weniger an Leistung verliert mit den Scripten.

Was hat das mit dem AF beider Karten zu tun?
Wenn du auf UT2003 ansprichst: Hier wird alle geblockt, von legalen Optimeirungen bis zu Cheats. Daher ist ein vergleich mit ASE gegen ATI nicht besonders fair.

PS: adaptive anisotropische Filterung basiert nun mal meistens auf Optimierungen. Wenn heutige Karten voll trilineares 8x oder 16x sample Anisotropic von 0 bis 360 Grad fuer alle texturing stages anwenden wuerden, waere die Leistung fuer alle umso einiges schlechter.

Also ist es legitim für Leistung Bildqualitaet zu opfern, nur weil "heutige Karten" nicht die noetige Power haben?
Nvidia's Qualitaet AF reicht für sehr viele Spiele heutzutage noch sehr gut aus.

Razor@Work

2003-08-11, 10:12:50

Original geschrieben von Exxtreme
Wo senkt ATi die Bildqualität?
Ist bilineare Filterung besser als trilineare ?
(und bitte nicht übersehen, dass ich dies nicht auf alle Apps/Games bezog !)
???

Razor

Exxtreme

2003-08-11, 10:19:16

Original geschrieben von Razor@Work
Ist bilineare Filterung besser als trilineare ?
(und bitte nicht übersehen, dass ich dies nicht auf alle Apps/Games bezog !)
???

Razor
Klar ist bilinear schlechter als trilinear. Mir aber nicht bekannt, daß der ATi-Treiber bilinear einstellt obwohl trilinear gewünscht wird.

Razor@Work

2003-08-11, 10:22:52

Original geschrieben von Ailuros
GeForceFX:

http://www.3dcenter.de/artikel/ati_nvidia_treiberoptimierungen/index9.php

http://www.3dcenter.de/artikel/ati_nvidia_treiberoptimierungen/index6.php
Du redest hier von UT2003, ja ?
Ich habe nichts anderes behauptet...
Bei U2 ist dies aber nicht der Fall und hier cheatet nur ATI !
:D
Original geschrieben von Ailuros
Und ja die Winkelabhaengigkeit sollte erwaehnt werden, nur faellt die Filterung auf Level2x bei 22 und 67 Grad Winkeln zurueck auf allen texturing stages, wobei aber im ersten Fall texturing stages 1-7 von 0 bis 360Grad auf Level2x zurueckfallen.

Die Leistungs-Unterschiede werden im Review (den Du sicher schon gelesen hast) mit Anti-Cheat Scripten illustriert. Ich sehe dass die Radeon weniger an Leistung verliert mit den Scripten.
Du redest noch immer von UT2003 ?
???

Und diese Skripte sind insofern kein 'Beweis', da bei nVidia rigeros alle 'Eingriffe' (also nich nur Optimierungen) abgewürgt wurden, während sich Unwinder bei ATI überhaupt nicht sicher war, alles deaktiviert zu haben...
Original geschrieben von Ailuros
Wenn es schon zur Bildqualitaet kommen sollte, dann sollte man nicht nur die Vor- sondern auch die Nachteile erwaehnen. Um einen 4*4 EER zu erreichen ist eine FX um ungefaehr 60-70% langsamer, in der gleichen Aufloesung.
Da eine FX kein EER kann, ist das doch wohl nur eine rein hypothetische Annahme, oder ?
Original geschrieben von Ailuros
PS: adaptive anisotropische Filterung basiert nun mal meistens auf Optimierungen. Wenn heutige Karten voll trilineares 8x oder 16x sample Anisotropic von 0 bis 360 Grad fuer alle texturing stages anwenden wuerden, waere die Leistung fuer alle umso einiges schlechter. Der FX - High performance modus sieht uebrigens aeusserst uebel aus in real-time.
Gerade bei dem letzten Satz geben ich Dir zu 100% recht.

Nichts desto trotz sollte es dem User überlassen werden, welche Qualität er bevorzugt. Bei ATI wird derzeit 'quality' eingestellt und bekommt diese bei UT2003, U2 und auch BF1492 (um nur einige zu nennen) nicht. Dass diese 'Optimierung' bei vielen anderen Games ohne visuelle Nachteile bleibt, liegt in der Natur der Engines... insofern könnte man sagen, dass ATI bei UT2003, U2 und BF1492 (natürlich auch noch bei einigen anderen) definiv cheatet (also zu lasten der BQ 'optimiert'), bei den anderen lediglich 'optimiert'. nVidia hingegen cheatet bei UT2003, nicht aber bei U2 und BF1492 (und noch keinem anderen mir bekannten Game).

Insofern sind die Ergebnisse bei UT2003 vergleichbar (da identisch schlechte BQ), bei den anderen aber nicht... eigentlich doch gar nicht so schwer, oder ?

Razor

Razor@Work

2003-08-11, 10:25:59

Original geschrieben von mapel110
lass dir mal gesagt sein, dass nicht alle spiele von der AF optimierung gleich viel profitieren bzw es überhaupt tun
http://www.3dcenter.org/artikel/ati_nvidia_treiberoptimierungen/index8_e.php
Klar... deswegen ich ja auch explizit Beispiele nannte, die nicht nur 'profitieren', sondern bei denen es auch gleich zu visuellen Nachteilen kommt. Insofern ich hier auch nicht 'Optimierung' sagen, sondern cheat.

Razor

P.S.: Dass der Murks01 gleich 1000 Punkte zulegt, wenn man das rTool nutzt sollte einem schon zu denken geben... na ja... nicht wirklich... ;)

Razor@Work

2003-08-11, 10:30:31

Original geschrieben von Exxtreme
Klar ist bilinear schlechter als trilinear. Mir aber nicht bekannt, daß der ATi-Treiber bilinear einstellt obwohl trilinear gewünscht wird.
Das Thema hatten wir schon, Exxtreme... und ich bin eben nicht Deiner Meinung, dass ATI keine 'quality' liefern muss, wenn 'quality' gefordert ist (ich beziehe mich hier jetzt mal explizit auf die Stages > 0 bei UT2003, U2 und BF1942 neben ein paar anderen Games ;-).

Solange solche Optimierungen nicht zulasten der BQ gehen, ist dies OK (wie bei gf4ti und ähnlichen Optimierungen ja auch). Aber es hatte einen Grund, warum selbst aths, mit der Default-Optimierung bei UT2003 nicht zufreiden war und von der generellen Optimierung auf eine langsamere Variante gegangen ist, um eben keine BQ zu 'opfern'. ATI tut dies nicht und cheatet somit (wie im speziellen Falle von UT2003 nVidia auch).

Razor

Exxtreme

2003-08-11, 10:43:13

Original geschrieben von Razor@Work
Das Thema hatten wir schon, Exxtreme... und ich bin eben nicht Deiner Meinung, dass ATI keine 'quality' liefern muss, wenn 'quality' gefordert ist (ich beziehe mich hier jetzt mal explizit auf die Stages > 0 bei UT2003, U2 und BF1942 neben ein paar anderen Games ;-).

ATi liefert "Quality" wenn das Spiel "Quality" fordert. :)

Nur wenn das Spiel nix fordert, dann liefern sie halt diese "Sparversion" von Tri-AF per Controlpanel. Aber wie schon gesagt, in dem Fall kann ATi "Quality" so definieren, wie sie lustig sind. Ein Cheat ist das keinesfalls. Ein Cheat wäre es, wenn der Treiber eigenständig die Texturen anders filtern würde, wie vom Spiel gefordert.

Wobei man sagen muss, daß das, was NV in UT2003 eigentlich auch kein richtiger Cheat ist. Es gibt nämlich AFAIK keine Norm wie Tri-AF auszusehen hat.

Exxtreme

2003-08-11, 10:44:12

Original geschrieben von Razor@Work
P.S.: Dass der Murks01 gleich 1000 Punkte zulegt, wenn man das rTool nutzt sollte einem schon zu denken geben... na ja... nicht wirklich... ;)
Liegt daran, daß 3DMurks standardmässig Bi-AF vom Treiber fordert.

Gast

2003-08-11, 10:53:31

Hi Exxtreme,

also erstens: "...und ich bin eben nicht Deiner Meinung"
und zweitens: "...na ja... nicht wirklich... ;)"

Siehe auch ersten und zweiten Post von Dir.
:D

Razor

P.S.: Und ich empfinde die 'Optimierungen' bei UT2003 von beiden IHV's als cheat !

Demirug

2003-08-11, 11:25:35

Original geschrieben von Exxtreme
Wobei man sagen muss, daß das, was NV in UT2003 eigentlich auch kein richtiger Cheat ist. Es gibt nämlich AFAIK keine Norm wie Tri-AF auszusehen hat.

Ich weiss nicht da muss man die Regeln aber schon böse biegen.

Bei D3D kann man die Filter kann getrennt einstellen. Also was getan werden soll wenn:

-ein Texel grösser als Pixel ist
-ein Texel kleiner als Pixel ist
-der Pixel zwischen zwei Mipmaps liegt.

tri wäre nun linear auf der Mipmap und linear zwischen den Mipmaps.

linear auf der Mipmap ist definiert als:

A weighted average of a 2x2 area of texels surrounding the desired pixel is used

linear zwischen den Mipmaps ist definiert als:

The texture filter to use between mipmap levels is trilinear mipmap interpolation. The rasterizer linearly interpolates pixel color, using the texels of the two nearest mipmap textures.

also aus dem linearen interpolieren zwischen den beiden Mipmaps kommen sie da IMHO nicht raus. Allerdings könnte man bei dem Sample aus der zweiten Mipmap wohl etwas tricksen indem man sagt man produziert dieses Sample eigentlich mit den werten der anderen Mipmap und gewichtet entsprechend.

Pitchfork

2003-08-11, 11:56:21

Zum Umgang Microsofts mit Shadern:

DX9 ist imho die bisher eindeutig beste Version von DX. Die Schwachstellen sind wieder deutlich minimiert worden und die Anwendung erleichtert. Eine Aussage, daß MS bis auf die Cursor APIs noch nie was gescheites hinbekommen hat, ist def. Unsinn.

Zu den Shaderschnittstellen: Microsoft ist genau den gleichen Weg gegangen wie Java, C# oder sonstwas. Es gibt eine abstrakte virtuelle Machine mit exakt festgelegten Specs. Diese Machine hat eine Bytecodesprache und eine lesbare Form der Bytecodesprache (Assembler Version der Shader). Diese Bytecode Shader (und Core DX kennt nix anderes als assemblierte Bytecode Shader, nix da Ascii oder so) werden von der Runtime validiert und vom Treiber beim Anlegen in lauffähige Maschinenabhängige Shader übersetzt.

Zusätzlich hat Microsoft eine High Level Sprache geschaffen, die aus C ähnlichem Code voroptimierten Bytecode für die virtuelle Machine erzeugt. Die Qualität des High Level Optimierers ist sehr gut und wird von Update zu update besser (und ist btw. besser als der von Cg).

Diese Trennung der Compilierung eines Shaders in zwei Schichten ist seit ungefähr 1960 Standard und wird bei jedem Compiliervorgang sei es C, Java, C++, Cobol, Fortran oder was weiß ich angewendet.
Zuerst wird eine Zwischenrepräsentation für eine virtuelle Machine erzeugt, diese global optimiert (loop unrolling, dead code removal, vectorisation,...) und dann der finale Code generiert (register zuweisung, instruktionsgenerierung, instruction reordering,...).

Microsoft ist jetzt hingegangen und hat aus zwei Gründen die Kontrolle über den ersten Pass der Compilierung sich vorbehalten:

1. Definitionsmacht über die Sprache und ihre Fähigkeiten. Nix wäre tödlicher für DX, wenn derselbe Shader nicht immer identische Ergebnisse liefern würde. Oder gar herstellerabhängige Erweiterungen auftauchen würden, wie es unvermeidbar wäre, wenn die Treiber die Kontrolle hätten (mal hier ein #pragma, mal dort ein __machesschneller).

2. Vermeiden von Mehraufwand und Vertrauen in die eigenen Fähigkeiten. Microsoft kann Compilier bauen, sie machen das schließlich seit 1980 (oder so). Sie wissen wie man optimiert. Sie haben die erfahrenen Leute. Und von diesen Optimierungen profitieren die kleinen wie die großen IHVs gleichermaßen. Ich möche ehrlich gesagt gar nicht wissen, wie gut ein S3 Shadercompiler sein könnte zB.

Die IHVs müssen nun ihre Hausaufgaben machen und den zweiten Teil des Compilers verbessern, indem sie den Bytecode der virtuellen Machine loophole optimieren und nicht einfach 1:1 umsetzen. Das ist im Vergleich zu einem vollen HLSL System eine relativ überschaubare Arbeit und die Übergabe des Zwischencodes als Bytecode macht die Sache weder leichter noch schwerer.

Wegen der neuen Shaderprofile von Microsoft: Der HLSL Compiler beschränkt sich auf ein Target Profile um verläßlichen Code zu generieren, der auf dem Target läuft. Nun gibt es in der DX9 Spec halt drei Shadermodelle (2.0, 2.x, 3.0) wobei 2.x auch noch ein wachsweiches Zwischending ist. Was jetzt passiert ist einfach, daß aus dem 2.x Modell die Features ausgewählt wurden, die die einzige verfügbare 2.x Hardware am Markt besitzt (nv3x) und daß als Target ausgewählt wurde. Dadurch kann HLSL zB. auf einmal Predication, längere Shader oder Shader mit beliebig vielen Dependant Reads. Also echter Mehrwert. Nebenbei wurde (da dieser Shader ja zur Zeit nur auf nv Hardware läuft) nv der Gefallen getan, die Instruktionen für nv Hardware voroptimiert (also im wesentlichen andere Registernutzung und andere Reihenfolge) im Bytecode abzulegen. Dieses 2_a Shadermodell mußte kommen, sonst wären keine über 2.0 hinausgehenden Features der nv3x Reihe von HLSL zugänglich. Der EINZIGE Gefallen von MS an NV ist eine andere Registerbenutzung und Assemblerreihenfolge! Und genau diesen Punkt kann und wird nv in seinen Treiber durch den zweiten Compilepass in den Griff bekommen.

Das gleiche Prozedere wird passieren, sobald echte 3.0 Hardware auf den Markt kommt: es wird ein neues DXSDK Update kommen mit anderen Targets für HLSL.

Zusammenfassend: ich kann keinen Fehler seitens Microsofts in Sachen Shaderstrategie erkennen und sehe ansonsten nur viele Vorteile und gut gewählte Lösungen.

Pitchfork

PS: Die Richtung, in der sich PC 3D Hardware entwickelt und in die sich PC Gaming entwickelt wird sehr stark von Microsoft beeinflußt und profitiert von deren Visionen und Forschungsarbeiten. Die Zeiten, in denen MS einfach nur ein gemeinsames API für die Hardware verschiedener Hersteller baut sind lange vorbei, Microsoft ist bei der Erforschung und Entscheidung, was überhaupt in Hardware Sinn macht, immer stärker beteiligt.

Gast

2003-08-11, 11:56:59

Original geschrieben von Demirug
Ich weiss nicht da muss man die Regeln aber schon böse biegen.

Bei D3D kann man die Filter kann getrennt einstellen. Also was getan werden soll wenn:

-ein Texel grösser als Pixel ist
-ein Texel kleiner als Pixel ist
-der Pixel zwischen zwei Mipmaps liegt.

tri wäre nun linear auf der Mipmap und linear zwischen den Mipmaps.

linear auf der Mipmap ist definiert als:

linear zwischen den Mipmaps ist definiert als:

also aus dem linearen interpolieren zwischen den beiden Mipmaps kommen sie da IMHO nicht raus. Allerdings könnte man bei dem Sample aus der zweiten Mipmap wohl etwas tricksen indem man sagt man produziert dieses Sample eigentlich mit den werten der anderen Mipmap und gewichtet entsprechend. in irgendteinem ini file von splinter sthet eindeutig drine das ati den höchsten qualitäts anforderungen der engine mit keiner karte grecht werden kann :)
so und nun bitte back@topic

Demirug

2003-08-11, 12:08:31

Schöne Zusammenfassung Pitchfork.

Ergänzen möchte ich noch folgendes.

1. Den kleinen Nachteil den ich an dem derzeitigen Bytecode Model von DX9 sehe sind die zu wenigen Makros um höhere Funktionen zu übermitteln und das der Bytecode für jede neue Shaderversion noch erweitert werden muss. Und MS sollte den Punkt das die Pixelshader so wie sie im SDK erklärt sind nur eine Virtuele Maschine sind etwas klarer Herausstellen.

2. Das 2_0 Traget ist dafür aber im Gegenzug an die einzige Hardware die nicht mehr kann angepasst.

Mr. Lolman

2003-08-11, 12:16:40

Original geschrieben von Gast
in irgendteinem ini file von splinter sthet eindeutig drine das ati den höchsten qualitäts anforderungen der engine mit keiner karte grecht werden kann :)
so und nun bitte back@topic

Mann, weil das Spiel auf der XBOx entwickelt wurde. Theroetisch könnte ATi auf jeden Fall schon die Schattentechnik darstellen.
Ausserdem läuft das Spiel mit HQ Einstellungen unter aller Sau.

(erninnere mich gerade an LS Screenshot seiner FX5800 "Ultra" wo er mit 4xS AA 9fps erreichte...)

Mr. Lolman

2003-08-11, 12:23:14

Original geschrieben von Gast
P.S.: Und ich empfinde die 'Optimierungen' bei UT2003 von beiden IHV's als cheat !

ATi senkt nicht gezielt für gew. Spiele die BQ. Jeder der Sich eine ATi Karte kauft, weiss dass das Quality-AF bei allen Spielen immer gleich gut aussieht.

Bei NV kauft man sich ne FX im Glauben, immer das bessere Q-AF serviert zu bekommen, doch in UT2003 ists nur Performance AF. Wenn man die exe umbennent startet das Spiel nicht mehr, und wenn man in der Applikation den AF Level wählt, bekommt man im ggs. zu ATi immernoch das qualitativ schlechtere AF. Die einzige Möglichkeit ist es einen alten Detonator zu verwenden (IIRC <43.45) oder mit dem Unwinderscript zu spielen. Mit beiden Lösungen steht man dann qualitativ etwas besser als ATi da, bei weit schlechterer Leistung.

(kann mich noch erinnern wo Lovesuckz mit einem neuen optimierten Cheat Treiber in 400/400 plötzlich mehr fps hatte als mit dem alten in ~500/500 (IIRC 492MHz Chiptakt))

Razor@Work

2003-08-11, 12:31:22

Dreh' und wende es, wie Du willst...

Bei Games und Apps, deren Stages >0 ebenfalls sichtbar sind, 'versagt' die Optimierung von ATI's 'quality' schlicht. Insofern würde es ATI gut zu Gesicht stehen, es so zu machen, wie es auch damals der aTuner angeboten hat. So denn eine Option im Treiber (meinetwegen auch hardcodiert) exisitiert, die diese Optimierung unterdrückt, um es auch Games wie UT2003 (die keine Einstellmöglichkeiten dafür in der Oberfläche bieten, also ca. 99% aller Games !) zu ermöglichen, in voller Qualität zu laufen.

Auch ATI's Leistung ist bei 'reinem' tri-AF wesentlich schlechter, insofern auch hier kein Unterschied bei den IHV's zu sehen ist.

Razor

LovesuckZ

2003-08-11, 12:31:58

Original geschrieben von Mr. Lolman
ATi senkt nicht gezielt für gew. Spiele die BQ. Jeder der Sich eine ATi Karte kauft, weiss dass das Quality-AF bei allen Spielen immer gleich gut aussieht.

OpenGL Spiele sehen besser aus, da hier noch das alte Quality AF zum Einsatz kommt. ATi hat also die Quality in DX Applicationen gesenkt. Man koennte von einen DX Cheat reden...

Exxtreme

2003-08-11, 12:49:17

Original geschrieben von LovesuckZ

OpenGL Spiele sehen besser aus, da hier noch das alte Quality AF zum Einsatz kommt. ATi hat also die Quality in DX Applicationen gesenkt. Man koennte von einen DX Cheat reden...
Nochmal für alle, ATi senkt die BQ nicht. Die BQ wird besser wenn man AF hinzuschaltet.

LovesuckZ

2003-08-11, 12:57:49

Original geschrieben von Exxtreme
Nochmal für alle, ATi senkt die BQ nicht. Die BQ wird besser wenn man AF hinzuschaltet.

ATi hat aber die BQ nach einem Treiberupdate gesenkt und zwar nur für DX Spiele.
Nvidia tats nur in UT2003, ATi für eine ganze API (?)...

Exxtreme

2003-08-11, 13:05:00

Original geschrieben von Razor@Work
Dreh' und wende es, wie Du willst...

Bei Games und Apps, deren Stages >0 ebenfalls sichtbar sind, 'versagt' die Optimierung von ATI's 'quality' schlicht.

Da gebe ich dir recht. Wobei man sagen muss, daß diese Games, in denen man diese "Optimierung" sieht, eher die Ausnahme darstellen. Mir sind UT2003, BF1942 und Aquanox bekannt.
Original geschrieben von Razor@Work
Insofern würde es ATI gut zu Gesicht stehen, es so zu machen, wie es auch damals der aTuner angeboten hat. So denn eine Option im Treiber (meinetwegen auch hardcodiert) exisitiert, die diese Optimierung unterdrückt, um es auch Games wie UT2003 (die keine Einstellmöglichkeiten dafür in der Oberfläche bieten, also ca. 99% aller Games !) zu ermöglichen, in voller Qualität zu laufen.

Es fehlt einfach eine zusätzliche Option im Controlpanel. Diese bietet das rTool und AFAIK der aTuner. Ich weiss, das sind Third-Party-Tools und somit nicht wirklich relevant.

Was mir persönlich fehlt, ist auch eine zusätzliche Treiberoption um Tri-AF zu forcen.
Original geschrieben von Razor@Work
Auch ATI's Leistung ist bei 'reinem' tri-AF wesentlich schlechter, insofern auch hier kein Unterschied bei den IHV's zu sehen ist.

Razor
Ich glaube, die Spiele-Designer tragen hier die Hauptschuld. Solange diese zu blöd sind um die Filterung für die Texturstages zu bestimmen, solange werden diese "Optimierungen" im Treiber drin bleiben. In den meisten Fällen wird halt 10-30% an Leistung verschleudert. :)

Exxtreme

2003-08-11, 13:07:06

Original geschrieben von LovesuckZ
ATi hat aber die BQ nach einem Treiberupdate gesenkt und zwar nur für DX Spiele.

Nochmal, ATi hat nicht die BQ gesenkt. Sie erhöhen sie nur nicht so hoch wie es möglich wäre.

Das ist ein Unterschied. :)

LovesuckZ

2003-08-11, 13:11:53

Original geschrieben von Exxtreme
Nochmal, ATi hat nicht die BQ gesenkt. Sie erhöhen sie nur nicht so hoch wie es möglich wäre.

Nein. Wenn man mit einem Treiber, der nicht die Stageoptimierung hatte, Quality AF eingesetzt hat, bekam man die bestmoeglichste Qualitaet. Nach einem "Wunder" Treiber wurde die Quality Qualitaet gesenkt, um Benchmarks gewinnen und Treiber besser "verkaufen" zu koennen.
Kurz: ATi hat ihre AF Qualitaet von einem Moment auf den anderen zum schlechten hin veraendert.
Ich denke, du wirst mir zustimmen, dass dies nicht ganz lobenswert war (egal, wie legal sowas ist).

Crushinator

2003-08-12, 00:29:17

Original geschrieben von LovesuckZ
(...)
Kurz: ATi hat ihre AF Qualitaet von einem Moment auf den anderen zum schlechten hin veraendert. Ich denke, du wirst mir zustimmen, dass dies nicht ganz lobenswert war (egal, wie legal sowas ist). Dem letzten Satz kann ich voll und ganz zustimmen, würde aber trotzdem nicht vom Cheat sprechen. "Unnötige Bevormundung" würde eher dazu passen.

Gast

2003-08-12, 00:31:31

Original geschrieben von Mr. Lolman
Mann, weil das Spiel auf der XBOx entwickelt wurde. Theroetisch könnte ATi auf jeden Fall schon die Schattentechnik darstellen.
Ausserdem läuft das Spiel mit HQ Einstellungen unter aller Sau.

(erninnere mich gerade an LS Screenshot seiner FX5800 "Ultra" wo er mit 4xS AA 9fps erreichte...) Ist das meine schuld :)

Ailuros

2003-08-12, 04:30:38

Du redest hier von UT2003, ja ?
Ich habe nichts anderes behauptet...
Bei U2 ist dies aber nicht der Fall und hier cheatet nur ATI !

Der Artikel behandelt nicht nur UT2k3.

Gibt es einen Link der Unreal2 Optimierungen beweisst? (muss ich verpasst haben).

Und diese Skripte sind insofern kein 'Beweis', da bei nVidia rigeros alle 'Eingriffe' (also nich nur Optimierungen) abgewürgt wurden, während sich Unwinder bei ATI überhaupt nicht sicher war, alles deaktiviert zu haben...

Du hast sicher ein effektives Gegenbeispiel die Deine Theorie unterstuetzen kann, dass ATI tatsaechlich mehr optimiert oder cheated? (Begriffe sind mir eigentlich egal)

Da eine FX kein EER kann, ist das doch wohl nur eine rein hypothetische Annahme, oder ?

War das ein Witz oder ein peinlicher Ausrutscher? :D

EER = Edge Equivalent Resolution

2xRGMS = 2*2 EER
4xOGMS = 2*2 EER
.....
8xS (2xRGMS + 4xOGSS) = 4*4 EER

4x sparse MSAA = 4*4 EER
6x sparse MSAA = 6*6 EER

Um die edge-AA Qualitaet von 4xAA einer Radeon zu erreichen, braucht eine FX zumindest 8xS. :P

Und die 60-70% Leistungs-Unterschied ist nicht unrealistisch.

Gerade bei dem letzten Satz geben ich Dir zu 100% recht.

Schon Level2x trotz Winkelabhaengigkeit gibt bei der Radeon bessere Resultate.

Nichts desto trotz sollte es dem User überlassen werden, welche Qualität er bevorzugt. Bei ATI wird derzeit 'quality' eingestellt und bekommt diese bei UT2003, U2 und auch BF1492 (um nur einige zu nennen) nicht. Dass diese 'Optimierung' bei vielen anderen Games ohne visuelle Nachteile bleibt, liegt in der Natur der Engines... insofern könnte man sagen, dass ATI bei UT2003, U2 und BF1492 (natürlich auch noch bei einigen anderen) definiv cheatet (also zu lasten der BQ 'optimiert'), bei den anderen lediglich 'optimiert'. nVidia hingegen cheatet bei UT2003, nicht aber bei U2 und BF1492 (und noch keinem anderen mir bekannten Game).

Ich ueberrenn mal den Kauderwelsch ueber die cheaterei fuer den Moment.

Auf der Radeon kann man trilinear auf alle texturing stages einstellen. Ein paar Seiten zuvor steht Demi´s Zitat, wie NV im Quality Mode optimiert. Hast Du ne Loesung fuer neueste Treiber diesen davon abzuhalten z.B. auf level2x bei texturing stages 1-7 herunterzudruecken (auch wenn es sich nur um ein Spiel handelt?).

Der Leistungs-einbruch einer R3xx mit trilinearer unoptimierter Anisotropy ist trotzdem kleiner wie bei NV3x.

SS:SE 1600*1200*32 (custom non-public demo)

NV35/8xAF(tri) = -24%

R350/16xAF(tri) = -8%

(**edit: Verlust-Prozentuale bei 1xAF und 8x/16xAF im Vergleich)

Wobei die Frage aufkommt, wer hier mehr Grund zu wahrem cheaten hat.

Ailuros

2003-08-12, 04:52:01

Original geschrieben von LovesuckZ

Nein. Wenn man mit einem Treiber, der nicht die Stageoptimierung hatte, Quality AF eingesetzt hat, bekam man die bestmoeglichste Qualitaet. Nach einem "Wunder" Treiber wurde die Quality Qualitaet gesenkt, um Benchmarks gewinnen und Treiber besser "verkaufen" zu koennen.
Kurz: ATi hat ihre AF Qualitaet von einem Moment auf den anderen zum schlechten hin veraendert.
Ich denke, du wirst mir zustimmen, dass dies nicht ganz lobenswert war (egal, wie legal sowas ist). [/SIZE]

Wenn die Applikation keine AF-spezifische settings hat, dann 3rd party Tweak-utilities, wo man voll trilinear auf alle texturing stages einstellen kann.

Nochmal wo auch immer NV Optimierungen in Applikationen auftauchen, sind sie in neuesten Treibern festgenagelt.

Wie dem auch sei ich hab auf der NV25 in neuen Spielen (wo immer moeglich) nur auf texturing stage "0" volles AF angelegt, und ich konnte keinen Unterschied sehen; dabei sind die performance modes gar nicht moeglich auf NV25 (nur Kompression und dazu grausam schlecht setzt sich ein bei high performance).

Obwohl bilineare Anisotropy nicht der Idealfall ist, sondern trilineares AF, ist der Unterschied in Qualitaet zwischen biAF auf FX und biAF auf R3xx, so gut wie Tag und Nacht.

Razor@Work

2003-08-12, 11:02:33

Original geschrieben von Ailuros
Der Artikel behandelt nicht nur UT2k3.

Gibt es einen Link der Unreal2 Optimierungen beweisst? (muss ich verpasst haben).
Es gibt genasu genommen nicht einmal einen Artikel über UT2003.
Hier ist es nur auffällig geworden, weil man den Cheat bei nVidia nachweisen wollte, dann aber verblüfft feststellte, dass die BQ bei ATI ja nicht einmal besser ist. Ergo bei nVidia die Ausnahme, bei ATI aber die Regel darstellte (auf das AF bezogen, selbstverständlich ;-).

Man sollte sich IMO mal generell mit der 'Optimierung' auf Seiten ATI beim AF auseinander setzen, aber offensichtlich ist das für viele wohl irgendwie anders zu bewerten, als wenn man was bei nVidia findet. Sind ja schließlich doch schon so einige Games, die das mit der Reduzierung der BQ bei ATI betrifft (leider nur aus Forenbeiträgen gesammelt...).
Original geschrieben von Ailuros
Du hast sicher ein effektives Gegenbeispiel die Deine Theorie unterstuetzen kann, dass ATI tatsaechlich mehr optimiert oder cheated? (Begriffe sind mir eigentlich egal)
Nein, lediglich die Aussage von Unwinder selbst, der zugegeben hat, dass die 'Optimierungen' bei ATI sehr viel 'versteckter' und schwerer zu ermitteln sind. Bei nVidia war's einfach ein kompletter Codeteil, der recht 'einfach' deaktiviert werden konnte. Bei ATI sind die betreffenden Teile im ganzen Code 'verstreut'.

Absicht und Methode ?
Vermutlich ja...
Original geschrieben von Ailuros
War das ein Witz oder ein peinlicher Ausrutscher? :D
Weder noch... schlicht ein Mißverständnis.
Original geschrieben von Ailuros
Um die edge-AA Qualitaet von 4xAA einer Radeon zu erreichen, braucht eine FX zumindest 8xS. :P
Und die 60-70% Leistungs-Unterschied ist nicht unrealistisch.
Und das ist genau der Grund, warum ich Vergleiche unterschiedlicher Thechniken grundweg ablehne...
Die AA-quali ab 4x bei ATI (R3x0) kann von der nVidia-Methode nicht erreicht werden. Da hilft es auch nicht, jetzt irgendwelche abstrusen Modi anzuführen, die da vielleicht ran kommen würden... OGMS und RGMS sind unterschiedliche Techniken. So kann man vielleicht die Leistung vergleichen (4 zu 4 sample), nicht aber die daraus resultierende Qualität.

Das AA-quali ist ab 4xRGMS bei ATI klar besser.
Die Leistungsfähigkeit beider Kontrahenten bei 4xMS dagegen vergleichbar.
Original geschrieben von Ailuros
Schon Level2x trotz Winkelabhaengigkeit gibt bei der Radeon bessere Resultate.
Redest Du jetzt vom AF ?
Dann gibt's ein klares: NEIN !
Original geschrieben von Ailuros
Ich ueberrenn mal den Kauderwelsch ueber die cheaterei fuer den Moment.
Schade... aber wenn Du meinst...
;-)
Original geschrieben von Ailuros
Auf der Radeon kann man trilinear auf alle texturing stages einstellen. Ein paar Seiten zuvor steht Demi´s Zitat, wie NV im Quality Mode optimiert. Hast Du ne Loesung fuer neueste Treiber diesen davon abzuhalten z.B. auf level2x bei texturing stages 1-7 herunterzudruecken (auch wenn es sich nur um ein Spiel handelt?).
Nein, das kann offensichtlich nur die Appliaktion... aber der User kann dies nicht bei allen Applikationen erzwingen und das ist der eigentliche Kritikpunkt. Im Treiber wird 'quality' eingestellt und man bekommt es nicht überall...

Bei UT2003 bekommt man die 'quality' auch von nVidia nicht. Aber zeig mir bitte nur ein einziges weiteres Beipsiel...
Original geschrieben von Ailuros
Der Leistungs-einbruch einer R3xx mit trilinearer unoptimierter Anisotropy ist trotzdem kleiner wie bei NV3x.
Aufgrund der zusätzlichen Winkelabhängigkeit... ja.
(und auch nicht immer ;-)
Original geschrieben von Ailuros
Wobei die Frage aufkommt, wer hier mehr Grund zu wahrem cheaten hat.
Nö, die Frage ist, warum ATI hier so massiv und mit der Holzhammer-Methode absichtlich die BQ bei einigen Games (mit visuellen Stages > 0) seit Cat3.1 herab gesetzt hat.

Razor

Razor@Work

2003-08-12, 13:12:02

Original geschrieben von Ailuros
Wenn die Applikation keine AF-spezifische settings hat, dann 3rd party Tweak-utilities, wo man voll trilinear auf alle texturing stages einstellen kann.
Das ist leider sogar völlig falsch.

Man kann lediglich dem Treiber sagen, dass er keinesfalls die Einstellungen der Treibers denen der Appliaktion vorziehen soll. Dies hat dann ja auch zur Folge, dass der Murks01 dann gleich bilinear filtert, obwohl im Panel eigentlich 'quality' (=trilinear) eingestellt ist.

Ganz oder gar nicht.

Aber klar, wenn man das rTool benutzt, die INI der Anwendung so anpaßt, dass trilineare Filterung über die Anwendung eingestellt wird (ist nur bei den wenigsten Anwendungen/Games möglich) dann bekommt man auch das, was haben möchte...

... aber ist das nicht ein wenig zu umständlich ?
Und funktionieren tut das auch nicht überall...

Original geschrieben von Ailuros
Nochmal wo auch immer NV Optimierungen in Applikationen auftauchen, sind sie in neuesten Treibern festgenagelt.
Wenn Du das jetzt auf die AF-'Optimierung' von UT2003 beziehst: ja !
Und auch dass ist intolerabel...
Original geschrieben von Ailuros
Wie dem auch sei ich hab auf der NV25 in neuen Spielen (wo immer moeglich) nur auf texturing stage "0" volles AF angelegt, und ich konnte keinen Unterschied sehen; dabei sind die performance modes gar nicht moeglich auf NV25 (nur Kompression und dazu grausam schlecht setzt sich ein bei high performance).
Auch diese Methode habe ich schon aus zuvor beschriebenen Gründen abgelehnt.
Und selbst hier hat z.Bsp. der aTuner für UT2003 ein eigenes Profil gehabt, weil eben das Ergebnis nicht das ist, was gewünscht war und eben eine qualitativ höherwertige, wenn auch performance-seitig ungünstigere Variante gewählt.

Aber klar, bei der überwiegenden Anzahl der Games fällt diese Form der Optimierung ja auch nicht (negativ) auf. Trotzdem bleibt ein Bodensatz an Games (zumal sehr aktuelle) bei denen diese Form der 'Optimierung' eine schlechtere BQ liefert, per se also ein Cheat darstellt...
Original geschrieben von Ailuros
Obwohl bilineare Anisotropy nicht der Idealfall ist, sondern trilineares AF, ist der Unterschied in Qualitaet zwischen biAF auf FX und biAF auf R3xx, so gut wie Tag und Nacht.
Es gibt Unterschiede, aber ein Unterscheid wie "Tag und Nacht" ist es nicht (vom 'high performance'-Mode mal abgesehen ;-). Auch fällt mir gerade das mipmap-banding sehr unangenehm auf, weswegen ich ja auch so ein Verfechter der maximal möglichen Qualität bin. Auch denke ich, dass Leute, die nichts anderes kennen, eher Schwierigkeiten haben, dort Unterschiede (die dann ja gar nicht vorhanden sind) auszumachen.

Ich selber habe schon die gf4-Optimierung der Stages abgelehnt (die ja auch für meine gf3 möglich war, wenn die nv4_disp gehackt wurde), weil mir diese Veränderung in einigen Games eben als untragbar erschien. Genauso wahr genommen habe ich das dann, als ich die R9500 in den Fingern hatte...

Allerdings denke ich, dass man hier wohl 'eh nie auf einen Konsens kommen kann. Schade ist eigentlich nur, dass ATI keine Möglichkeit bietet, die wirkliche AF-Qualität, die mit dem R300 ja ohne weiteres machbar ist, auch über die Panels anzubieten... was im übrigen auch für die supersampling Methoden beim AA gilt... aber das steht auf einem anderen Blatt...

Razor

Razor@Work

2003-08-12, 13:13:02

Was war das ?
???

Razor

zeckensack

2003-08-12, 14:32:33

Razor,
wenn ich Exxtreme richtig verstanden habe, dann erzwingt die AF-Einstellung im Panel auf'm R300 weiterhin einwandfrei die Anisotropie. Was sie nicht erzwingt ist ein trilinearer Basisfilter.

Den kann eine App aber trotzdem bekommen (auch in Kombination mit dem über's Panel aktiviertem AF), so wie sie ihn sowieso schon seit etlichen Jahren kriegen kann. Die App muß ihn nur wollen. Wenn sich die Leutz da wissentlich für "für diese Textur reicht bilinear" entschieden haben ... ist die durchschnittlich erreichte AF-Qualität auf R300 zwar tatsächlich mit dem neuen Treiber gesunken, aber so richtig illegal ist's nicht.

zeckensack

2003-08-12, 15:42:21

Original geschrieben von Pitchfork
<...>
Zu den Shaderschnittstellen: Microsoft ist genau den gleichen Weg gegangen wie Java, C# oder sonstwas. Es gibt eine abstrakte virtuelle Machine mit exakt festgelegten Specs. Diese Machine hat eine Bytecodesprache und eine lesbare Form der Bytecodesprache (Assembler Version der Shader). Diese Bytecode Shader (und Core DX kennt nix anderes als assemblierte Bytecode Shader, nix da Ascii oder so) werden von der Runtime validiert und vom Treiber beim Anlegen in lauffähige Maschinenabhängige Shader übersetzt.
Nein, nicht wie Java, und sicher auch nicht wie C#. Der Bytecode ist viel zu beschränkt in seiner Ausdruckskraft, eben weil man doch maschinenspezifischen Assembler durchschleust, nur in einer etwas gefälligeren Representation.

Wenn der Bytecode auch nur ansatzweise so maschinenunabhängig wäre wie Java, dann bräuchte man keine Profil-Updates, man müßte nichtmal zwischen NV30 und R300 unterscheiden.
Diese Trennung der Compilierung eines Shaders in zwei Schichten ist seit ungefähr 1960 Standard und wird bei jedem Compiliervorgang sei es C, Java, C++, Cobol, Fortran oder was weiß ich angewendet.
<...>Der Zwischencode der Compiler wird in vernünftigen Sprachen aber nicht offengelegt, und damit auch nicht als "Quellcode" für Kompilierung akzeptiert.
Oder programmiert hier irgendjemand direkt auf GCC-Interna?
Das Problem ist, sobald man diese Schicht offenlegt, muß man die Spezifikation in dieser Form halten, zumindest als Option für Abwärtskompatibilität. Denn es gibt Code für diese Zwischenstufe, der auch in Zukunft laufen muß.
Dafür ist DX9 einfach nicht reif genug (im Gegensatz zu Java).
Microsoft ist jetzt hingegangen und hat aus zwei Gründen die Kontrolle über den ersten Pass der Compilierung sich vorbehalten:

1. Definitionsmacht über die Sprache und ihre Fähigkeiten. Nix wäre tödlicher für DX, wenn derselbe Shader nicht immer identische Ergebnisse liefern würde. Oder gar herstellerabhängige Erweiterungen auftauchen würden, wie es unvermeidbar wäre, wenn die Treiber die Kontrolle hätten (mal hier ein #pragma, mal dort ein __machesschneller).???
Ein Hochsprachencompiler muß als Basisvoraussetzung erstmal eine ausreichende Syntax haben, bei einem geschichteten Modell zudem soviel wie möglich davon an die maschinenspezifische Schicht weitergeben können.
Herstellerspezifische Erweiterungen braucht man dann erst garnicht zu definieren.

2. Vermeiden von Mehraufwand und Vertrauen in die eigenen Fähigkeiten. Microsoft kann Compilier bauen, sie machen das schließlich seit 1980 (oder so). Sie wissen wie man optimiert. Sie haben die erfahrenen Leute. Und von diesen Optimierungen profitieren die kleinen wie die großen IHVs gleichermaßen.Garnichts wissen sie. Sie wissen nur das, was ihnen die IHVs an Information zuspielen. Optimieren für die Architektur können nur die IHVs. Daß MS das jetzt auch kann, hat nichts mit DX zu tun. Ohne IHV-Infos liefe da überhaupt nichts.
Ich möche ehrlich gesagt gar nicht wissen, wie gut ein S3 Shadercompiler sein könnte zB.Es gibt mehrere Möglichkeiten, an einen funktionsfähigen (wenn auch nicht Optimalen) Backend-Compiler zu kommen. Wenn S3 soetwas will, dann sollen sie sich halt darum kümmern. Die Zuständigkeit (und die Motivation) ist doch sonnenklar.

Die IHVs müssen nun ihre Hausaufgaben machen und den zweiten Teil des Compilers verbessern, indem sie den Bytecode der virtuellen Machine loophole optimieren und nicht einfach 1:1 umsetzen. Das ist im Vergleich zu einem vollen HLSL System eine relativ überschaubare Arbeit und die Übergabe des Zwischencodes als Bytecode macht die Sache weder leichter noch schwerer.Korrekt. Der bislang definierte Bytecode ist nur offensichtlich nicht dafür geeignet.
Wegen der neuen Shaderprofile von Microsoft: Der HLSL Compiler beschränkt sich auf ein Target Profile um verläßlichen Code zu generieren, der auf dem Target läuft. Nun gibt es in der DX9 Spec halt drei Shadermodelle (2.0, 2.x, 3.0) wobei 2.x auch noch ein wachsweiches Zwischending ist. Was jetzt passiert ist einfach, daß aus dem 2.x Modell die Features ausgewählt wurden, die die einzige verfügbare 2.x Hardware am Markt besitzt (nv3x) und daß als Target ausgewählt wurde. Dadurch kann HLSL zB. auf einmal Predication, längere Shader oder Shader mit beliebig vielen Dependant Reads. Also echter Mehrwert. Nebenbei wurde (da dieser Shader ja zur Zeit nur auf nv Hardware läuft) nv der Gefallen getan, die Instruktionen für nv Hardware voroptimiert (also im wesentlichen andere Registernutzung und andere Reihenfolge) im Bytecode abzulegen. Dieses 2_a Shadermodell mußte kommen, sonst wären keine über 2.0 hinausgehenden Features der nv3x Reihe von HLSL zugänglich. Der EINZIGE Gefallen von MS an NV ist eine andere Registerbenutzung und Assemblerreihenfolge! Und genau diesen Punkt kann und wird nv in seinen Treiber durch den zweiten Compilepass in den Griff bekommen.Großartig. Wofür braucht's dann noch MS' "Erfahrung" im Front End, wenn - wie du richtig feststellst - die korrekte Optimierung sowieso Sache des IHVs, des Treibers ist?

Es bringt keinen Nutzen, wenn MS bereits im Front-End 'validiert', nur zusätzliche Restriktionen.
Daß Shader-Programm A auf Zielhardware XY voraussichtlich nicht laufen wird, ist eine nette Information, wenn sie von einem SDK und einer Debug-Version kommt. Hat aber in einer Mechanismusdefinition überhaupt nichts verloren.
Wieder die Frage: Wen interessiert's, wer ist zuständig?
Antwort in diesem Fall: Der ISV muß wissen, auf welchen Targets sein Shader läuft. Der IHV muß dafür sorgen, daß möglichst viele Shader auf seinen Chips laufen.
MS geht's schlicht nichts an, ebensowenig geht's den Front End-Compiler was an. Hier besteht weder Zuständigkeit, noch technische Motivation.

Zusammenfassend: ich kann keinen Fehler seitens Microsofts in Sachen Shaderstrategie erkennen und sehe ansonsten nur viele Vorteile und gut gewählte Lösungen.Und ich sehe daß MS wieder den Kontroll-Freak spielt. Die für gute Optimierung erforderliche 'Extraktion' von HW-Informationen aus den IHVs liegt bestimmt auch nicht in deren Interesse.

PS: Die Richtung, in der sich PC 3D Hardware entwickelt und in die sich PC Gaming entwickelt wird sehr stark von Microsoft beeinflußt und profitiert von deren Visionen und Forschungsarbeiten. Die Zeiten, in denen MS einfach nur ein gemeinsames API für die Hardware verschiedener Hersteller baut sind lange vorbei, Microsoft ist bei der Erforschung und Entscheidung, was überhaupt in Hardware Sinn macht, immer stärker beteiligt. Dann ist "UltraShadow" wohl auch noch eine Erfindung von MS?

Razor@Work

2003-08-12, 16:11:48

Original geschrieben von zeckensack
Razor,
wenn ich Exxtreme richtig verstanden habe, dann erzwingt die AF-Einstellung im Panel auf'm R300 weiterhin einwandfrei die Anisotropie. Was sie nicht erzwingt ist ein trilinearer Basisfilter.

Den kann eine App aber trotzdem bekommen (auch in Kombination mit dem über's Panel aktiviertem AF), so wie sie ihn sowieso schon seit etlichen Jahren kriegen kann. Die App muß ihn nur wollen. Wenn sich die Leutz da wissentlich für "für diese Textur reicht bilinear" entschieden haben ... ist die durchschnittlich erreichte AF-Qualität auf R300 zwar tatsächlich mit dem neuen Treiber gesunken, aber so richtig illegal ist's nicht.
Ich weiß, zeckensack, ich weiß...

Scenario 1:
- man stellt im Panel 'quality' ein (=trilinearer Basisfilter)
- man erzwingt via rTool die applikationsgesteuerte Filterung
- man bencht Murks01, welcher per Default einen bilinearen Filter benutzt
Man erhält damit ein bilinearen Filter (=höheres Ergebnis).

Scenario 2:
- man stellt im Panel 'quality' ein (=trilinearer Basisfilter)
- man bencht Murks01, welcher per Default einen bilinearen Filter benutzt
Man erhält damit einen Mischmasch aus trilinearem und bilinearem Filter (=niedrigeres Ergenis).

-

Verstehst Du nun, wie ich das meinte ?
Da ist eine Inkonsistenz zwischen den Einstellungen und ist durchaus dazu in der Lage zu verwirren...
Oder meinst Du, dass jeder in der Lage ist, die Auswirkungen dieser Einstellungen abschätzen zu können ?

Insofern braucht man schon gehörig Hintergrund, um hier zu einem 'richtigen' Resultat zu gelangen...

Razor

zeckensack

2003-08-12, 16:27:28

Original geschrieben von Razor@Work
- man stellt im Panel 'quality' ein (=trilinearer Basisfilter)Jein :)
Wenn man 'Performance AF' einstellt, dann wird man auf bilineares AF beschränkt, dh jede Anforderung der Applikation nach trilinearem Filter werden auf bilinear zurückgestuft. Das ist so gewesen, und so geblieben.

Quality AF ist nun nicht mehr per se auch "force trilinear". Es hat sich so eingebürgert, NV hat es AFAIK (abgesehen von ...) immer so gehandhabt, ATI hat sich nun dafür entschieden, AF von "force trilinear" zu trennen. Und hier liegt das eigentliche Problem: die Vergleichbarkeit zwischen den IHVs geht völlig aus dem Fenster :(

Rein technisch betrachtet hat man es IMO wirklich mit zwei paar Schuhen zu tun, die nur aus Tradition verknüpft sind.
Verstehst Du nun, wie ich das meinte ?
Da ist eine Inkonsistenz zwischen den Einstellungen und ist durchaus dazu in der Lage zu verwirren...
Oder meinst Du, dass jeder in der Lage ist, die Auswirkungen dieser Einstellungen abschätzen zu können ?

Insofern braucht man schon gehörig Hintergrund, um hier zu einem 'richtigen' Resultat zu gelangen...

Razor Ack.
Ich würde mir wünschen, daß ATI das ganze wieder geraderückt, indem sie zusätzlich zu den aktuell vorhandenen Kontrollen einen "force trilinear"-Schalter ins Panel hängen. Dann wäre, was mich angeht, wieder alles im Lot.

Pitchfork

2003-08-12, 16:57:26

Original geschrieben von zeckensack
Nein, nicht wie Java, und sicher auch nicht wie C#. Der Bytecode ist viel zu beschränkt in seiner Ausdruckskraft, eben weil man doch maschinenspezifischen Assembler durchschleust, nur in einer etwas gefälligeren Representation.

Wenn der Bytecode auch nur ansatzweise so maschinenunabhängig wäre wie Java, dann bräuchte man keine Profil-Updates, man müßte nichtmal zwischen NV30 und R300 unterscheiden.
Der Zwischencode der Compiler wird in vernünftigen Sprachen aber nicht offengelegt, und damit auch nicht als "Quellcode" für Kompilierung akzeptiert.
Oder programmiert hier irgendjemand direkt auf GCC-Interna?
Das Problem ist, sobald man diese Schicht offenlegt, muß man die Spezifikation in dieser Form halten, zumindest als Option für Abwärtskompatibilität. Denn es gibt Code für diese Zwischenstufe, der auch in Zukunft laufen muß.
Dafür ist DX9 einfach nicht reif genug (im Gegensatz zu Java).
???
Ein Hochsprachencompiler muß als Basisvoraussetzung erstmal eine ausreichende Syntax haben, bei einem geschichteten Modell zudem soviel wie möglich davon an die maschinenspezifische Schicht weitergeben können.
Herstellerspezifische Erweiterungen braucht man dann erst garnicht zu definieren.

Garnichts wissen sie. Sie wissen nur das, was ihnen die IHVs an Information zuspielen. Optimieren für die Architektur können nur die IHVs. Daß MS das jetzt auch kann, hat nichts mit DX zu tun. Ohne IHV-Infos liefe da überhaupt nichts.
Es gibt mehrere Möglichkeiten, an einen funktionsfähigen (wenn auch nicht Optimalen) Backend-Compiler zu kommen. Wenn S3 soetwas will, dann sollen sie sich halt darum kümmern. Die Zuständigkeit (und die Motivation) ist doch sonnenklar.

Korrekt. Der bislang definierte Bytecode ist nur offensichtlich nicht dafür geeignet.
Großartig. Wofür braucht's dann noch MS' "Erfahrung" im Front End, wenn - wie du richtig feststellst - die korrekte Optimierung sowieso Sache des IHVs, des Treibers ist?

Es bringt keinen Nutzen, wenn MS bereits im Front-End 'validiert', nur zusätzliche Restriktionen.
Daß Shader-Programm A auf Zielhardware XY voraussichtlich nicht laufen wird, ist eine nette Information, wenn sie von einem SDK und einer Debug-Version kommt. Hat aber in einer Mechanismusdefinition überhaupt nichts verloren.
Wieder die Frage: Wen interessiert's, wer ist zuständig?
Antwort in diesem Fall: Der ISV muß wissen, auf welchen Targets sein Shader läuft. Der IHV muß dafür sorgen, daß möglichst viele Shader auf seinen Chips laufen.
MS geht's schlicht nichts an, ebensowenig geht's den Front End-Compiler was an. Hier besteht weder Zuständigkeit, noch technische Motivation.

Und ich sehe daß MS wieder den Kontroll-Freak spielt. Die für gute Optimierung erforderliche 'Extraktion' von HW-Informationen aus den IHVs liegt bestimmt auch nicht in deren Interesse.

Dann ist "UltraShadow" wohl auch noch eine Erfindung von MS?

Hui, wer wird denn gleich, hum hom, emotional.

Wobei ich das Gefühl habe, daß das jetzt auch zu schnell ausufert, ich denke ich habe meine Meinung deutlich geäußert.

Beispiele für die Forschungs Microsofts im Bereich Spielegrafik gibt es genug, siehe Progressive Meshes und Precomputed Radiance Transfer mittels Spherical Harmonics.

Razor

2003-08-12, 19:11:00

Original geschrieben von zeckensack
Jein :)
Wenn man 'Performance AF' einstellt, dann wird man auf bilineares AF beschränkt, dh jede Anforderung der Applikation nach trilinearem Filter werden auf bilinear zurückgestuft. Das ist so gewesen, und so geblieben.
Das würde ich voll unterschreiben !
Original geschrieben von zeckensack
Quality AF ist nun nicht mehr per se auch "force trilinear". Es hat sich so eingebürgert, NV hat es AFAIK (abgesehen von ...) immer so gehandhabt, ATI hat sich nun dafür entschieden, AF von "force trilinear" zu trennen. Und hier liegt das eigentliche Problem: die Vergleichbarkeit zwischen den IHVs geht völlig aus dem Fenster :(
Jain...
:D

Oder warum sollte es so sein, dass das Murks-Ergebnis im panel mit 'quality, mit rTool und Murks-'InGame' Einstellung 'bilinear' schneller ist, als ohne rTool ? Eben weil zumindest auf Stage 0 trilinear gefiltert wird.

Insofern ist die Panel-Einstellung 'quality' ein "force tri-AF on stage 0", welches durch das rTool ausser Kraft gesetzt wird/werden kann. Fordert die Applikation nun einen bilinearen Filter an, bekommt sie dies auch für alle Stages . Fordert sie einen trilinearen Filter, bekommt sie diesen (ebenfalls für alle Stages - da glaube ich den Bezeugungen der Leute hier). Aber eben nur durch den Eingriff des rTools...
Original geschrieben von zeckensack
Rein technisch betrachtet hat man es IMO wirklich mit zwei paar Schuhen zu tun, die nur aus Tradition verknüpft sind.
Hmmm...

Das rTool sorgt zumindest dafür, dass die Applikation das bekommt, was sie will. Das Panel hingegen scheint sich da sehr ungewöhnlich zu verhalten. So bekommt die Applikation anscheinend auch dann einen trilinearen Filter (zumindest auf Stage 0 ;-), wenn sie gar keinen anfordert (Einstellung 'quality'). Auf der anderen Seite wird der trilinieare Filter auf Stage 0 verweigert, auch wenn die Applikation dies gern hätte (Einstellung 'performance').

Wenn das rTool also nicht benutzt wird, interessiert den Treiber die Applikation überhaupt nicht. Bei 'quality' gibt's trilinearen Filter, bei 'performance' bilinearen... selbstverständlich nur auf Stage 0, da alle anderen Stages ja 'eh nur bilinear gefiltert werden.

Und ich denke mal, dass dies auch in Situationen ohne AF gilt...
Original geschrieben von zeckensack
Ack.
Ich würde mir wünschen, daß ATI das ganze wieder geraderückt, indem sie zusätzlich zu den aktuell vorhandenen Kontrollen einen "force trilinear"-Schalter ins Panel hängen. Dann wäre, was mich angeht, wieder alles im Lot.
Na ja, zumindest ein wenig mehr Klarheit und auf der anderen Seite ein wenig mehr 'Entwirrung' wäre schon nicht schlecht. Auch sollte man den rTool-Switch in den Treiber einbauen, damit dem User nicht einfach mögliche Funktionalitäten vorenthalten werden.

Razor

LovesuckZ

2003-08-12, 19:11:48

Der Vater hat seinen verloren geglaubten Sohn zurueck:

Saratoga, California USA – August 12, 2003 – Futuremark Corporation, the leading provider of PC performance analysis software and services, today announced that NVIDIA Corporation has re-joined its worldwide benchmark development program. Futuremark’s flagship product, 3DMark®03, sets the standard for easily and objectively measuring and comparing PCs’ 3D graphics performance and is part of Futuremark’s suite of benchmark solutions originally launched in 1998.

http://www.futuremark.com/pressroom/pressreleases/?081203

Naja, wem's gefaellt...

Gast

2003-08-12, 22:02:52

hehe.
FM will halt überleben. Ohne Nvidia geht des halt nicht.

Auf in den Coding Kampf. Ein neuer Benchmark muss her am besten mit CG!

Demirug

2003-08-12, 22:05:33

Original geschrieben von Gast
hehe.
FM will halt überleben. Ohne Nvidia geht des halt nicht.

Auf in den Coding Kampf. Ein neuer Benchmark muss her am besten mit CG!

Cg ist tot und ich kann 3 Tage arbeit wegwerfen.

LovesuckZ

2003-08-12, 22:14:57

Original geschrieben von Demirug
Cg ist tot und ich kann 3 Tage arbeit wegwerfen.

Ging ja schnell.
Vor ein paar Tagen hast du noch gesagt, du müsstest laenger mit Cg leben als du dachtest.

Demirug

2003-08-12, 22:18:57

Original geschrieben von LovesuckZ
Ging ja schnell.
Vor ein paar Tagen hast du noch gesagt, du müsstest laenger mit Cg leben als du dachtest.

Ich sagte das sich Cg als solches noch etwas länger halten wird das bezog sich aber vorallem auf OpenGL.

Für DX lohnt es nicht mehr weil MS ja jetzt die NV3X-Optimierungen in den DX-SDK Compiler übernimmt.

Ailuros

2003-08-13, 02:27:42

Nein, lediglich die Aussage von Unwinder selbst, der zugegeben hat, dass die 'Optimierungen' bei ATI sehr viel 'versteckter' und schwerer zu ermitteln sind. Bei nVidia war's einfach ein kompletter Codeteil, der recht 'einfach' deaktiviert werden konnte. Bei ATI sind die betreffenden Teile im ganzen Code 'verstreut'.

Absicht und Methode ?
Vermutlich ja...

ATI hat Unwinder nie Treiber-Kleinigkeiten zugeschickt, deshalb kann er auch nicht mehr im Rivatuner fuer Radeons einsetzen. Wenn´s zu Methoden kommt, es wird sich schon zeigen ob NVIDIA selber ihm weiterhin kleinere Details ueber Treiber zuschickt oder nicht. Falls nicht ist er wohl durch die Anti-Cheat Scripte in "Ungnade" gefallen ;)

Und das ist genau der Grund, warum ich Vergleiche unterschiedlicher Thechniken grundweg ablehne...
Die AA-quali ab 4x bei ATI (R3x0) kann von der nVidia-Methode nicht erreicht werden. Da hilft es auch nicht, jetzt irgendwelche abstrusen Modi anzuführen, die da vielleicht ran kommen würden... OGMS und RGMS sind unterschiedliche Techniken. So kann man vielleicht die Leistung vergleichen (4 zu 4 sample), nicht aber die daraus resultierende Qualität.

Normalerweise ist ein Vergleich zwischen verschiedenen Implementationen eine zwielichtige Sache. Das gilt aber genauso was AA oder AF betrifft, da Implementation bei beiden verschieden sind.

In dem Sinn lies bitte Deinen obrigen Paragraph nochmal durch.

Die Qualitaet von 4xOGMS liegt zwischen 2xRGMS und 4xOGMS, also so etwa:

2xRGMS < 4xOGMS < 4xRGMS

Redest Du jetzt vom AF ?
Dann gibt's ein klares: NEIN !

High Performance ist ein bilinear Wischi-waschi mode mit Texturen Kompression zugefuegt, und ja der finale output im ATI-performance mode mit Level 2x ist besser, denn beim letzteren gibt es erst mal kein TC.

Aber klar, bei der überwiegenden Anzahl der Games fällt diese Form der Optimierung ja auch nicht (negativ) auf. Trotzdem bleibt ein Bodensatz an Games (zumal sehr aktuelle) bei denen diese Form der 'Optimierung' eine schlechtere BQ liefert, per se also ein Cheat darstellt...

Dazu moechte ich erst mal eine Liste der besagten Spiele. Spiele die anisotropy auf alle ihre texturing stages gleich verteilen sind eher selten.

Das ist leider sogar völlig falsch.

Man kann lediglich dem Treiber sagen, dass er keinesfalls die Einstellungen der Treibers denen der Appliaktion vorziehen soll. Dies hat dann ja auch zur Folge, dass der Murks01 dann gleich bilinear filtert, obwohl im Panel eigentlich 'quality' (=trilinear) eingestellt ist.

Wieso? Jegliches Spiel dass ich bis jetzt beruehrt habe wo man aniso durch game-settings einstellen kann und mipmaps eingefaerbt werden koennen, bekommt volle trilineare Anisotropy wenn ich Aniso im Treiber abschalte und es im Spiel aktiviere.

Es gibt Unterschiede, aber ein Unterscheid wie "Tag und Nacht" ist es nicht (vom 'high performance'-Mode mal abgesehen ;-). Auch fällt mir gerade das mipmap-banding sehr unangenehm auf, weswegen ich ja auch so ein Verfechter der maximal möglichen Qualität bin. Auch denke ich, dass Leute, die nichts anderes kennen, eher Schwierigkeiten haben, dort Unterschiede (die dann ja gar nicht vorhanden sind) auszumachen.

Du hast Dich ja geweigert ein Gegenbeispiel von CTF-December mit bi-AF zu liefern (und nochmal ja die map ist schlecht gecodet). Bei bi-AF bekommst Du in dem Fall auf NV Hardware ein mipmap banding Fest, wobei selbst bei trilinear nur eine feine -fast nicht bemerkbare- Transition uebrigbleibt.

Gib mir zwei screenshots, einmal mit bi-AF und einmal mit tri-AF, vom Schiffdeck in December und ich markier Dir sofort wo die mipmap boundries liegen ohne mipmap Faerbung und ja auf einem stillen Screenshot. Selbst texture aliasing kann man auf einem Screenshot sehen, wenn man ein trainiertes Auge hat.

Aber macht Dir keine Sorgen ich werde nicht zum ignorantem Idioten als erstes Mal hingestellt.

Ailuros

2003-08-13, 04:38:34

Der Kontext ist relevant:

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

Mir ging diese Kyle Persona schon seit laengerer Zeit auf die Nerven; dabei hab ich keine Ahnung ob und wann er ehrlich mit sicher selber ist.

Wenn er in diesem Artikel FutureMark´s Kredibilitaet bezweifelt, uebersieht er hoechstwahrscheinlich seine eigene Meinungs-Schwankungen.

Wie dem auch sei, ich hab den Artikel erst jetzt durchgelesen und ich weiss ehrlich nicht mehr warum ich die Seite immer noch besuche.

Ausschnitt:

The issue with this “quasi-Trilinear Filtering” optimization is that you cannot turn it off should you wish to. If you go into the UT2K3 video setup GUI, there is a checkbox there for “Trilinear Filtering”, so it seems obvious to me that the game developer seemed to think that Trilinear Filtering would be something that would enhance the game. Some folks are upset that they do not get to enable this feature using NVIDIA GFFX cards as it is commonly understood to work.

As of last night, using NVIDIA’s new driver set, we were not able to turn on true Trilinear Filtering in UT2K3. We went to NVIDIA and asked about this. They explained that we had never been told what we thought we had been told. It seemed to turn into a semantics game; one I did not feel like playing. Why NVIDIA is refusing to give this option to the enthusiasts is simply beyond me.

Der Rest ueber Futuremark ist nur nutzloser Kauderwelsch eines sehr verwirrten Juenglings, der es anscheinend schwer hat eine konstante Meinung ueber ein Thema zu haben:

On the topic of 3DMark03, everyone but NVIDIA, Futuremark, and their lawyers will tell you that NVIDIA cheated in that benchmark to get a better score. No matter what the press releases say about optimizations, I think many of us know very well that it was cheating.

Wie sich der Wind wenden kann hm? ;)

LovesuckZ

2003-08-13, 12:46:34

Original geschrieben von Demirug
Woran es bei Unreal2 und Splinter Cell liegt kann ich nicht sagen.

Liegt es vielleicht dadran, dass die NV30/35 Karten nur über 4 Pixel Pipelines verfügen?
Die Idee kommt eigentlich von den Ergebnisse, welche Beyond3d.com im Splinter cell Oil - benchmark mit ihrer 9600pro gemacht haben.

9600pro 420/680

1024x768 30.28199 Avarage 19.29549 Min. 66.15853 Max.

5800 420/680

1024*768 30,96254 Avarage 20,80223 Min. 71,858214 Max.

http://www.beyond3d.com/reviews/triplex/redair9600pro/index.php?p=7

Ailuros

2003-08-13, 16:38:46

Mal abgesehen von dem ganzen Wirrwarr, gibt es eigentlich jemand hier der Unreal2 wirklich toll fand? Ich konnte mich nicht dazu bringen das verdammte Ding voll durchzuspielen und es hatte keineswegs etwas mit Leistung zu tun.

mapel110

2003-08-13, 16:41:47

Original geschrieben von Ailuros
Mal abgesehen von dem ganzen Wirrwarr, gibt es eigentlich jemand hier der Unreal2 wirklich toll fand? Ich konnte mich nicht dazu bringen das verdammte Ding voll durchzuspielen und es hatte keineswegs etwas mit Leistung zu tun.

is zwar gewaltig offtopic ;) und es gab schon etliche threads dazu. aber JA, ich hab mich durchgewürgt, weil ich mitreden wollte :D
auch der einzige grund.

Aquaschaf

2003-08-13, 17:22:12

Also Spass gemacht hats mir eigentlich schon, die Misionen, Musik, Sprachausgabe und Grafik haben mir gefallen. Aber die Story ist ja wohl ein wenig einfallslos, und das Spiel ist sehr, sehr kurz - weswegen ich nicht verstehe wie man es -einmal begonnen- nicht durchspielen konnte ;)
Die durch den Hype geweckten Erwartungen hats aber natürlich nicht erfüllt.

LovesuckZ

2003-08-14, 12:28:41

45.23 empfohlender 3dMark2003 Treiber?

Nun ist laut NVIDIA der Detonator 45.23 der "von Futuremark empfohlene Treiber um akkurate 3DMark03-Ergebnisse zu erhalten".

http://www.tecchannel.de/news/20030814/thema20030814-11535.html

Razor@Work

2003-08-14, 13:37:45

Original geschrieben von Ailuros
Normalerweise ist ein Vergleich zwischen verschiedenen Implementationen eine zwielichtige Sache. Das gilt aber genauso was AA oder AF betrifft, da Implementation bei beiden verschieden sind.

In dem Sinn lies bitte Deinen obrigen Paragraph nochmal durch.

Die Qualitaet von 4xOGMS liegt zwischen 2xRGMS und 4xOGMS, also so etwa:

2xRGMS < 4xOGMS < 4xRGMS
Da brauche ich gar nichts durchzulesen... ging es doch darum, dass hier jemand meinte, dass erst 8xS an die Quali von 4xMS(ATI) heran kommen würde. Und dieser Vergleich ist einfach unsinnig... auch ist es absolut unstrittig, dass die AA-Quali ab 4xRG definitv besser ist...

Jetzt aber Leistungsvergleiche mit irgendwelchen AA-Modi nVidia's zu machen, die auch noch Supersampling-Anteile enthalten, ist einfach... naja...
;-)
Original geschrieben von Ailuros
High Performance ist ein bilinear Wischi-waschi mode mit Texturen Kompression zugefuegt, und ja der finale output im ATI-performance mode mit Level 2x ist besser, denn beim letzteren gibt es erst mal kein TC.
Warum sollte man die 'high perf'-Mode von nVidia mit dem 'perf'-Mode von ATI vergleichen ?
???

Dann doch wohl eher 'perf' gegen 'perf', oder ?
Original geschrieben von Ailuros
Dazu moechte ich erst mal eine Liste der besagten Spiele. Spiele die anisotropy auf alle ihre texturing stages gleich verteilen sind eher selten.
Da komm ich jetzt nicht mit...
Soweit ich weiß, gibt es KEIN Spiel, welches selbsttätig die Stages einzeln handhabt.

Er geht hier lediglich um Apps, bei denen auch die Stages > 0 visuell zum Tragen kommen und davon gibt es derzeit so einige...
- U2/UT2003
- BF1492
- Aquanox 1/2
und noch ein paar andere...
Original geschrieben von Ailuros
Wieso? Jegliches Spiel dass ich bis jetzt beruehrt habe wo man aniso durch game-settings einstellen kann und mipmaps eingefaerbt werden koennen, bekommt volle trilineare Anisotropy wenn ich Aniso im Treiber abschalte und es im Spiel aktiviere.
Und wieviele wären das ?
U2/UT2003 und SeriousSam D3D ?
???
Original geschrieben von Ailuros
Du hast Dich ja geweigert ein Gegenbeispiel von CTF-December mit bi-AF zu liefern (und nochmal ja die map ist schlecht gecodet). Bei bi-AF bekommst Du in dem Fall auf NV Hardware ein mipmap banding Fest, wobei selbst bei trilinear nur eine feine -fast nicht bemerkbare- Transition uebrigbleibt.

Gib mir zwei screenshots, einmal mit bi-AF und einmal mit tri-AF, vom Schiffdeck in December und ich markier Dir sofort wo die mipmap boundries liegen ohne mipmap Faerbung und ja auf einem stillen Screenshot. Selbst texture aliasing kann man auf einem Screenshot sehen, wenn man ein trainiertes Auge hat.
Ich sehe keinen Sinn darin, hier ScreenShots anzufertigen, wenn das eigentlich Resultat erst in Bewegung sörend zum Tragen kommt.
Original geschrieben von Ailuros
Aber macht Dir keine Sorgen ich werde nicht zum ignorantem Idioten als erstes Mal hingestellt.
Das will und sollte ich keinesfalls tun !
Sorry, wenn das so rüber gekommen sein sollte...
:-(

Razor

Razor@Work

2003-08-14, 13:41:15

Original geschrieben von LovesuckZ
45.23 empfohlender 3dMark2003 Treiber?

Nun ist laut NVIDIA der Detonator 45.23 der "von Futuremark empfohlene Treiber um akkurate 3DMark03-Ergebnisse zu erhalten".

http://www.tecchannel.de/news/20030814/thema20030814-11535.html
:bounce::lol::rofl::lol::bounce:

Hmmm...
Gibt es so etwas wie "akkurate 3DMark03-Ergebnisse" ünerhaupt ?
;-)

Razor

Exxtreme

2003-08-14, 13:42:43

Original geschrieben von LovesuckZ
45.23 empfohlender 3dMark2003 Treiber?

Nun ist laut NVIDIA der Detonator 45.23 der "von Futuremark empfohlene Treiber um akkurate 3DMark03-Ergebnisse zu erhalten".

http://www.tecchannel.de/news/20030814/thema20030814-11535.html
Nimm das! (http://www.beyond3d.com/forum/viewtopic.php?p=153882#153882)

StefanV

2003-08-14, 14:01:00

Original geschrieben von Razor@Work
Da brauche ich gar nichts durchzulesen... ging es doch darum, dass hier jemand meinte, dass erst 8xS an die Quali von 4xMS(ATI) heran kommen würde. Und dieser Vergleich ist einfach unsinnig... auch ist es absolut unstrittig, dass die AA-Quali ab 4xRG definitv besser ist...

Jetzt aber Leistungsvergleiche mit irgendwelchen AA-Modi nVidia's zu machen, die auch noch Supersampling-Anteile enthalten, ist einfach... naja...
;-)

Razor

Tja, dafür sehe ich bei ATIs 4xMS weniger Kanten als bei meiner GF3 TI200, bei welcher ich immer Kanten sehe...

Razor@Work

2003-08-14, 14:20:10

Original geschrieben von Stefan Payne
Tja, dafür sehe ich bei ATIs 4xMS weniger Kanten als bei meiner GF3 TI200, bei welcher ich immer Kanten sehe...
Ich hoffe inständig, dass Du 'Treppchen' und nicht 'Kanten' meinst...
Als Kantenvernichtungs-'Feature' war mir bisher AA nicht bekannt.

Razor

Exxtreme

2003-08-14, 14:24:51

Original geschrieben von Razor@Work
Ich hoffe inständig, dass Du 'Treppchen' und nicht 'Kanten' meinst...
Als Kantenvernichtungs-'Feature' war mir bisher AA nicht bekannt.

Razor
:rofl:

Good one!

Ailuros

2003-08-15, 07:22:26

Da brauche ich gar nichts durchzulesen... ging es doch darum, dass hier jemand meinte, dass erst 8xS an die Quali von 4xMS(ATI) heran kommen würde. Und dieser Vergleich ist einfach unsinnig... auch ist es absolut unstrittig, dass die AA-Quali ab 4xRG definitv besser ist...

Jetzt aber Leistungsvergleiche mit irgendwelchen AA-Modi nVidia's zu machen, die auch noch Supersampling-Anteile enthalten, ist einfach... naja...
;-)

Im Bereich EER hat leider 8xS nur einen 4*4 grid, da kann man nichts daran aendern. Wenn man auf einer NV2/3x x=4,y=4 haben will, dann ist nur 8xS dafuer verfuegbar.

Wie gesagt man redet im Kreis herum wenn man sowieso unvergleichbare Implementationen vergleicht, und dass gilt genauso fuer AA als auch fuer AF fuer die beiden IHVs.

Warum sollte man die 'high perf'-Mode von nVidia mit dem 'perf'-Mode von ATI vergleichen ?

Dann doch wohl eher 'perf' gegen 'perf', oder ?

Ich sagte nur dass high performance mode auf FX nicht zu ertragen ist. Wenn man aber zu vergleichen trotz der Implementations-Unterschiede kommen wuerde, dann natuerlich Performance vs Performance und Quality vs Quality.

Da komm ich jetzt nicht mit...
Soweit ich weiß, gibt es KEIN Spiel, welches selbsttätig die Stages einzeln handhabt.

Bei UT2k3 kommt man mit texturing stage "0" noch damit weg ohne Qualitaets-Unterschiede, weil die Texturen die Aniso benoetigen sowieso in den Basis-Texturen zu finden sind. Angenommen aber ein Spiel unterstuetzt 4-layer MT und hat die Texturen in den stages anders verteilt, heisst es dann dass alle texture layers genauso viel Aniso brauchen wuerden. Bei manchen Spielen bringt es was die texturing stages ausser "0" zu optimieren, bei manchen gar nichts.

Ein Spiel dass 4 layer MT hat, und in "0" lightmaps, in "1" detail textures usw usw anwendet braucht genauso viel aniso fuer alle stages. Ich weiss es klingt verwirrend, aber vielleicht kann Demi den Knoten den ich hier zustande gebracht habe, besser loesen.

Das einzige Spiel an dass ich mich erinnern kann dass sich seltsam verhielt mit Aniso (auf der NV25) ist LOTR-The Fellowship of the Rings. Bei default aniso gabs merkwuerdige Boxen in den Himmel-Texturen. Die Artifakte gingen wieder weg, als ich aniso fuer texturing stage "0" wieder abschaltete. Nur auf texturing stage "2" Aniso Level8x, der Rest auf Level1x.

- U2/UT2003
- BF1492
- Aquanox 1/2
und noch ein paar andere...

Ja aber wo genau kommen die obrigen Spiele zum "tragen" wenn man nur auf "0" optimiert. Wer spielt denn Aquanox oder U2? Irgendjemand muss ja wohl Beweise oder zumindest einen Screenshot dafuer haben, der wirklich dieses absolut beweisst. Beim oben erwaehnten Artikel muss man ja wirklich die Nase auf die Roehre kleben um zumindest einen Unterschied zu sehen (ausser natuerlich die colorized mipmap screenshots, aber keiner spielt in Disco-Quake mode).

Gegen UT2k3 und BF1942 hab ich nichts einzuwenden. Wenn man komplett von 1-7 auf bilinear setzt und das mipmapping ist schlecht, dann bekommt man stellenweise texture aliasing, ueberhaupt auf Bodentexturen was mehr als nur stoerend ist. Versuch mal auf der GF3 mit aTuner in UT2k3 8x Aniso fuer texturing stage "0" einzuschalten und schalte "1,2,3" auf 1x Aniso und begrenze die letzten drei auf bilinear, waehrend nur "0" trilineares 8x bekommt. Und nein so sieht es auf den R3xx NICHT aus. Auf der R2xx hoechstwahrscheinlich schon. Was gibts fuer BF1942 viel zu sagen, das Spiel basiert auf der q3a engine und duerfte also auf 2-layer multitexturing begrenzt sein.

Und wieviele wären das ?
U2/UT2003 und SeriousSam D3D ?

SS:SE in openGL bitte schoen, wer spielt das Ding in D3D? Also wollen wir mal:

Flight Simulator 2002
LOTR
Startopia
SS:SE
UT2003
Unreal2
Quake3
UT1
Soul Reaver 2
Indiana Jones: The Emperor's Tomb
DroneZ
RtCW
Max Payne

etc etc.

reicht das voruebergehend? Natuerlich kommt noch eine Vielfalt von etwas aelteren Spielen dazu wobei nicht optimiert wurde. Allein dass 16bpp AA nicht geht bei denen ist aussagend.

Ich sehe keinen Sinn darin, hier ScreenShots anzufertigen, wenn das eigentlich Resultat erst in Bewegung sörend zum Tragen kommt.

Haette ich ja auch nicht anders erwartet. :D

Mipmap boundries sind genauso sichtbar wie texture aliasing auf Screenshots.

Zumindest einen trilinearen AF shot von der vorerwaehnten Szene? Auch nicht hm? ;) Wovon hast Du Angst; dass ich Dir gleich sagen wo es hapert oder was?

Iceman346

2003-08-15, 10:33:35

Original geschrieben von Razor@Work
Da brauche ich gar nichts durchzulesen... ging es doch darum, dass hier jemand meinte, dass erst 8xS an die Quali von 4xMS(ATI) heran kommen würde. Und dieser Vergleich ist einfach unsinnig... auch ist es absolut unstrittig, dass die AA-Quali ab 4xRG definitv besser ist...

Stimmt. Das was man bekommt wenn man im Treiber 8x AA einstellt ist von der Qualität an horizontalen Linien nämlich auf dem Niveau von 2xAA. NUR 4xS glättet an horizontalen Linien besser als 2x AA. Alle andern AA Modi die Nvidia anbietet glätten zwar vertikale Linien immer besser, versagen bei horizontalen Linien aber total.

Razor@Work

2003-08-15, 13:08:55

Gib's zu, Du hast Langeweile !
;-)
Original geschrieben von Ailuros
Im Bereich EER hat leider 8xS nur einen 4*4 grid, da kann man nichts daran aendern. Wenn man auf einer NV2/3x x=4,y=4 haben will, dann ist nur 8xS dafuer verfuegbar.

Wie gesagt man redet im Kreis herum wenn man sowieso unvergleichbare Implementationen vergleicht, und dass gilt genauso fuer AA als auch fuer AF fuer die beiden IHVs.
Was ist an dem AF von ATI anders, ausser, dass es winkelabhängiger ist und in derzeitigen Treibern, keine wirkliche 'quality' zuläßt (was bei nVidia auch für UT2003 zutrifft ;-) ?

Ansonsten ACK.
Original geschrieben von Ailuros
Ich sagte nur dass high performance mode auf FX nicht zu ertragen ist. Wenn man aber zu vergleichen trotz der Implementations-Unterschiede kommen wuerde, dann natuerlich Performance vs Performance und Quality vs Quality.
Das geht aus den schon zuvor mehrfach beschriebenen Gründen nicht.
Es sei denn, Du meinst Cat3.0 und vorher...
Original geschrieben von Ailuros
Bei UT2k3 kommt man mit texturing stage "0" noch damit weg ohne Qualitaets-Unterschiede, weil die Texturen die Aniso benoetigen sowieso in den Basis-Texturen zu finden sind. Angenommen aber ein Spiel unterstuetzt 4-layer MT und hat die Texturen in den stages anders verteilt, heisst es dann dass alle texture layers genauso viel Aniso brauchen wuerden. Bei manchen Spielen bringt es was die texturing stages ausser "0" zu optimieren, bei manchen gar nichts.

Ein Spiel dass 4 layer MT hat, und in "0" lightmaps, in "1" detail textures usw usw anwendet braucht genauso viel aniso fuer alle stages. Ich weiss es klingt verwirrend, aber vielleicht kann Demi den Knoten den ich hier zustande gebracht habe, besser loesen.

Das einzige Spiel an dass ich mich erinnern kann dass sich seltsam verhielt mit Aniso (auf der NV25) ist LOTR-The Fellowship of the Rings. Bei default aniso gabs merkwuerdige Boxen in den Himmel-Texturen. Die Artifakte gingen wieder weg, als ich aniso fuer texturing stage "0" wieder abschaltete. Nur auf texturing stage "2" Aniso Level8x, der Rest auf Level1x.
Danke für die Erklärungen...
Allerdings befinden sich die Detail-Texturen von UT2003 wohl auf Level 1. Insofern kann man da schon sehr gut beobachten, wie sich das fehlende aniso, samt bilinearer Filterung dort auswirkt...
Original geschrieben von Ailuros
Ja aber wo genau kommen die obrigen Spiele zum "tragen" wenn man nur auf "0" optimiert. Wer spielt denn Aquanox oder U2? Irgendjemand muss ja wohl Beweise oder zumindest einen Screenshot dafuer haben, der wirklich dieses absolut beweisst. Beim oben erwaehnten Artikel muss man ja wirklich die Nase auf die Roehre kleben um zumindest einen Unterschied zu sehen (ausser natuerlich die colorized mipmap screenshots, aber keiner spielt in Disco-Quake mode).

Gegen UT2k3 und BF1942 hab ich nichts einzuwenden. Wenn man komplett von 1-7 auf bilinear setzt und das mipmapping ist schlecht, dann bekommt man stellenweise texture aliasing, ueberhaupt auf Bodentexturen was mehr als nur stoerend ist. Versuch mal auf der GF3 mit aTuner in UT2k3 8x Aniso fuer texturing stage "0" einzuschalten und schalte "1,2,3" auf 1x Aniso und begrenze die letzten drei auf bilinear, waehrend nur "0" trilineares 8x bekommt. Und nein so sieht es auf den R3xx NICHT aus. Auf der R2xx hoechstwahrscheinlich schon. Was gibts fuer BF1942 viel zu sagen, das Spiel basiert auf der q3a engine und duerfte also auf 2-layer multitexturing begrenzt sein.
So 'schlimm' siehts, wie mit der von Dir beschriebenen gf3/4-Methode sieht's tatsächlich nicht beim R300 aus. Allerdings ist auch die Optimierung, die nVidia nun für UT2003 gewählt hat, lange nicht so krass.

Der Unterschied ist aber deutlich erkennbar (wenn man es denn erkennen will). Und für mich als Quali-Fetischist, ist das Inakzeptabel...
Original geschrieben von Ailuros
SS:SE in openGL bitte schoen, wer spielt das Ding in D3D? Also wollen wir mal:

Flight Simulator 2002
LOTR
Startopia
SS:SE
UT2003
Unreal2
Quake3
UT1
Soul Reaver 2
Indiana Jones: The Emperor's Tomb
DroneZ
RtCW
Max Payne

etc etc.

reicht das voruebergehend? Natuerlich kommt noch eine Vielfalt von etwas aelteren Spielen dazu wobei nicht optimiert wurde. Allein dass 16bpp AA nicht geht bei denen ist aussagend.
In all diesen Games läßt sich aniso im Game-Menü konfigurieren ?
Sorry, aber sollte ich da tatsächlich sooo viel verpaßt haben ?
???

Kann natürlich sein, da ich bis dato ja nie darauf angewiesen war, es über das Game einzustellen.
Trotzdem hoffe ich wirklich inständig, dass Du nicht die Konfiguration über irgendwelche Registery-Settings oder INI-Files meinst.
Original geschrieben von Ailuros
Haette ich ja auch nicht anders erwartet. :D

Mipmap boundries sind genauso sichtbar wie texture aliasing auf Screenshots.
Na dann mal her damit.
Wenn Du anfängst, mach ich mit !
;-)
Original geschrieben von Ailuros
Zumindest einen trilinearen AF shot von der vorerwaehnten Szene? Auch nicht hm? ;) Wovon hast Du Angst; dass ich Dir gleich sagen wo es hapert oder was?
Glaube mir, 'angst' verspüre ich schon sehr lange nicht mehr... ;)

Aber wie schon gesagt, zeige mir einen ScreenShot, welcher mipmap boundries und texture aliasing zeigt und ich werde Deinem Wunsch entsprechen.

Razor

Iceman346

2003-08-15, 13:36:56

Original geschrieben von Ailuros
Was gibts fuer BF1942 viel zu sagen, das Spiel basiert auf der q3a engine und duerfte also auf 2-layer multitexturing begrenzt sein.

Battlefield basiert NICHT auf der Quake 3 Engine! Auch wenn das schon mehrere hier gepostet haben. Ich habe keine Ahnung woher diese Fehlinformation stammt.

BTW, Nvidia reduziert bei ihrem UT2k3 Cheat auch die Aniso Stufe für alle Texturestages > 0 auf 2x AF und geht hier auf Performance Filterung zurück (die 0. Stage kriegt ja noch ein Zwischending von Performance und Quality, alle danach nur noch Performance)

Ailuros

2003-08-16, 03:08:37

Original geschrieben von Iceman346
Battlefield basiert NICHT auf der Quake 3 Engine! Auch wenn das schon mehrere hier gepostet haben. Ich habe keine Ahnung woher diese Fehlinformation stammt.

BTW, Nvidia reduziert bei ihrem UT2k3 Cheat auch die Aniso Stufe für alle Texturestages > 0 auf 2x AF und geht hier auf Performance Filterung zurück (die 0. Stage kriegt ja noch ein Zwischending von Performance und Quality, alle danach nur noch Performance)

:ups:

Auf welcher Engine basiert es denn eigentlich?

betasilie

2003-08-16, 03:10:22

Original geschrieben von Ailuros
:ups:

Auf welcher Engine basiert es denn eigentlich?
Eine eigene Engine, keine Lizenz-Engine. ;)

Ich dachte anfangs auch, dass es sich um die Q3-Engine handelt. Erstens OGL und irgendwie sieht es auch ein bischen danach aus.

Ailuros

2003-08-16, 03:37:21

Gib's zu, Du hast Langeweile !
;-)

Ja mein Job ist aeusserst langweilig ;)

So 'schlimm' siehts, wie mit der von Dir beschriebenen gf3/4-Methode sieht's tatsächlich nicht beim R300 aus. Allerdings ist auch die Optimierung, die nVidia nun für UT2003 gewählt hat, lange nicht so krass.

Der Unterschied ist aber deutlich erkennbar (wenn man es denn erkennen will). Und für mich als Quali-Fetischist, ist das Inakzeptabel...

Qualitaets-Fetischist nur wohl bei Texturen-Filterung ja? ;)

Na dann mal her damit.
Wenn Du anfängst, mach ich mit !
;-)

Ich hab momentan nur den hier der auf meinem FTP hockt. Mehr ist nur moeglich wenn ich nach Hause komme:

http://users.otenet.gr/~ailuros/CTFdecember.jpg

Ob Du jetzt nen bi oder tri AF shot postest von der gleichen Stelle ist mir eigentlich egal. Wie gesagt CTF-December; genau in der Mitte zwischen den beiden Basen.

apollo

2003-08-16, 05:50:05

Original geschrieben von betareverse
Eine eigene Engine, keine Lizenz-Engine. ;)

Ich dachte anfangs auch, dass es sich um die Q3-Engine handelt. Erstens OGL und irgendwie sieht es auch ein bischen danach aus.

Refractor II heisst das Teil, eine "radikale Weiterentwicklung" von Refractor I (u.a. "Codename Eagle").
Ist aber afair D3D.

Razor

2003-08-16, 13:20:43

Original geschrieben von Ailuros
Ja mein Job ist aeusserst langweilig ;)
Meiner eigentlich nicht... nur dezeit it's einfach zum gääääähnen.
;-)

Wird demnächst zwar nicht spannender, aber zumindest anstrengender...
... weniger Langeweile also !
Original geschrieben von Ailuros
Qualitaets-Fetischist nur wohl bei Texturen-Filterung ja? ;)
Nein, Quali-Fetischt, wenn's um Gesamteindrücke geht. AF ist mir halt sehr viel wichtiger, als AA. Nich dass ich auf Letzteres verzichten würde, aber ich nutze 'eh meist nur 2xRG und wenn's 'chööön' sein soll, kommt 4xS zum Tragen... eigentlich aber auch nur, um die Jaggies los zu werden und nicht um besonders feine Übergänge bei Kanten zu beäugen...
;-)
Original geschrieben von Ailuros
Ich hab momentan nur den hier der auf meinem FTP hockt. Mehr ist nur moeglich wenn ich nach Hause komme:

http://users.otenet.gr/~ailuros/CTFdecember.jpg

Ob Du jetzt nen bi oder tri AF shot postest von der gleichen Stelle ist mir eigentlich egal. Wie gesagt CTF-December; genau in der Mitte zwischen den beiden Basen.
Dem werde ich, wie gesagt, gerne nachkomen, wenn Du auf Deinem Shot zeigst, wo dort "Mipmap boundries" oder gar "texture aliasing" zu bewundern ist.

Und by the way... kann es sein, dass Du bei Dir die Detail-Texturen deaktiviert hast ?
???

Razor

Iceman346

2003-08-16, 14:46:27

Original geschrieben von betareverse
Eine eigene Engine, keine Lizenz-Engine. ;)

Ich dachte anfangs auch, dass es sich um die Q3-Engine handelt. Erstens OGL und irgendwie sieht es auch ein bischen danach aus.

Wie apollo schon sagte. Battlefield ist Direct 3D nicht Open GL ;)

Ailuros

2003-08-17, 02:17:21

Dem werde ich, wie gesagt, gerne nachkomen, wenn Du auf Deinem Shot zeigst, wo dort "Mipmap boundries" oder gar "texture aliasing" zu bewundern ist.

Und by the way... kann es sein, dass Du bei Dir die Detail-Texturen deaktiviert hast ?

Detail textures ist das letzte was ich in einem Spiel abstellen wuerde; ich schau noch mal nach wenn ich nach Hause komme um ganz sicher zu sein.

Im oberen shot ist nur eine einzige mipmap boundry da, man muss nur sehen koennen wo sie liegt. Wenn Du noch weiter darueber verhandeln willst lass es gut sein. Sooo wichtig ist es nun auch wieder nicht. ;)

betasilie

2003-08-17, 04:21:50

Original geschrieben von Iceman346
Battlefield ist Direct 3D nicht Open GL ;)
Achso. Das hatte ich wohl falsch in Erinnerung. ;)

Razor

2003-08-17, 10:57:23

Original geschrieben von Ailuros
Detail textures ist das letzte was ich in einem Spiel abstellen wuerde; ich schau noch mal nach wenn ich nach Hause komme um ganz sicher zu sein.
Sie sind bei Dir definitv abgeschaltet... glaube mir.
;-)
Original geschrieben von Ailuros
Im oberen shot ist nur eine einzige mipmap boundry da, man muss nur sehen koennen wo sie liegt. Wenn Du noch weiter darueber verhandeln willst lass es gut sein. Sooo wichtig ist es nun auch wieder nicht. ;)
In dem CTFdecember-Shot ist nichts dergleichen zu erkennen...
Sag doch bitte einfach, wo auf diesem irgendetwas in dieser Richtung zu entdecken ist.

Und: Ich verhandele nicht !
:D

Razor

Hier also mal zumindest ein Ausschnittsvergleich eines Shot's vom mir (links) und dem von Dir (rechts).
Und sorry, aber Dir muss da einiges daneben gegangen sein... ;)

(auf 256Farben reduziert und auf 60% der ursprünglichen Größe verkleinert, i.e. 147kb -> 18kb ;-)

Ailuros

2003-08-17, 20:52:24

Sie sind bei Dir definitv abgeschaltet... glaube mir.
;-)

Abgeschaltet nicht von mir auf jeden Fall. War der verdammte LOD bug nicht weg mit 3.2? Das ganze ist eine saubere Ghost Installation vom anderen HDD ohne jeglichen VGA Treiber wo ich einfach 3.6 installierte.

Ich musste Texmipbias auf 0.00000 im ini stellen um wahre detail textures zu bekommen.

In dem CTFdecember-Shot ist nichts dergleichen zu erkennen...
Sag doch bitte einfach, wo auf diesem irgendetwas in dieser Richtung zu entdecken ist.

Shot kopieren und ueber 200% zoom in. Schau genau hin (rechts am Kamin z.B). Mit detail textures ist auch nicht sehr viel offensichtlicher. Hier ist ein korrekter shot in einem besseren Winkel:

http://users.otenet.gr/~ailuros/Dec2.jpg

Zoom bei beiden shots rein; ich kanns meistens auch ohne zoom sehen, bei Zweifel zoome ich noch extra rein. Und das ist der einzige Spot in der ganzen Map wo man die mipmap boundry sehen kann. In anderen maps ist es nicht mehr zu erkennen und auch nicht 3rd party maps die ich bis jetzt gespielt habe. "Ouch jetzt kann ich's sehen ja"? :D

Hier also mal zumindest ein Ausschnittsvergleich eines Shot's vom mir (links) und dem von Dir (rechts).
Und sorry, aber Dir muss da einiges daneben gegangen sein...

Ja ich bin total ueberarbeitet und brauche dringend Ferien. Nur ist eben mein Job so dass ich Hochsaison habe wenn alle anderen Ferien machen *aechz*

Ich weiss nicht was zum Teufel schief ging vor ein paar Tagen aber MSN Messenger hat ploetzlich verrueckt gespielt. Da ich keine Lust hatte mit dem ganzen rumzufuchteln, hab ich die Partition schnell formatiert und ein Ghost Image vom zweiten HDD kopiert.