Maßstab für die Shaderleistung

[Demirug]

Bei allen die ich hiermit nerve entschuldige ich mich schon mal im vorraus.

Ich haben diese Sache ja schon öfter angesprochen. Allerdings bin ich nach wie vor der Ansicht das wir noch keine befriedigende Lösung gefunden haben. Also setzte ich den Punkt "Quantifizieren der Pixel processing Leistung" mal wieder auf die Tagesordnug.

Bei den primär bisher in Verbindung mit Computer-Spielen eingesetzten Techniken war die Leistung des Pixelprocessing stark von der Fähigkeit schnell Texturwerte zu berechnen geprägt. Diese Fähigkeit eines Chips lässt sich in MTexel/s gut messen und vergleichen. Für die indirekt damit verbundene Bandbreite gibt es mit MB/s ebenfalls eine Einheit.

Nun muss man aber leider erkennen das diese beiden Angaben heute nicht mehr ausreichen um das Leistungsvolumen eines Chips ausreichend zu beschreiben. Gerade beim Einsatz von Pixelshadern der neusten Generation (PS 2.0/2.X) erkennt man klar die Tendenz mehr zu rechnen und weniger aus Texturen zu gewinnen. Damit rückt die Füllrate und Bandbreite in diesem Zusammenhang in den Hintergrund und macht einem neuen Flaschenhals Platz. Leider haben wir für diesen Flaschenhals bisher keinen guten Namen und wir können auch nicht seine Grösse in Vergleichbarer Form angeben. Es ist durchaus möglich die Rechenleistung eines Chips mit einer Formel auszudrücken. Allerdings enthalten solche Formeln bei jedem Chip anderer Variablen womit eine Vergleichbarkeit für den weniger tief in der Materie bewanderten Nutzer nahezu unmöglich ist. Aber selbst für kundige ist die Formel nur von begrenzter Aussagekraft weil von der theoretisch sehr grossen Anzahl von möglichen Shadern nur ein Bruchteil wirklich jemals genutzt werden wird. Was man braucht ist eine Zahl welche Auskunft über die unter praxsis Bedingungen erreichbare Shaderleistung gibt. Mit verschiedenen Shaderbenchmarks wurde der versuch gemacht einen solchen Wert zu finden. Diese Tests kranken IMHO jedoch alle an einem grossen Problem. Es mit einer verhältnissmässig kleinen Anzahl von Shadern gearbeitet. Dies lädt natürlich dazu ein stark auf diese Shader zu optimieren (legal oder nicht so legal). Desweiteren ist eine Übertragung der gewonnen Ergebnisse auf möglicherweise ganz anderer Shader welche in echten Spielen zum Einsatz kommen eine gefährliche Sache.

Solange nur 2 Hersteller um die Gunst der Kunden buhlen ist das ja alles noch recht unproblematisch. Einem der beiden erkennt man die Krone zu und dem anderen bescheinigt meine eine Schwäche. Kommen jedoch mehr Hersteller ins Boot wird das ermitteln der Verhältnisse zueinader ein fast unausweichlicher Wunsch eines mündigen Kundes. Aber auch bei nur zwei Herstellern ist eine Leistungsreihenfolge wünschenswert wenn das Lieferprogramm mehr als nur eine Chipvariante enthält. Als Einheit für einen solchen Vergleich würden sicherlich MOps/s (für Operationen pro Sekunden) gut geeignet sein. Die Frage ist aber nun wie man eine Operation im Pixelprocessingumfeld definieren soll.

Der einfachste Weg wäre es sicherlich einfach die Anzahl der berechneten Pixel/s mit der Anzahl der Shaderanweisungen des verwendeten Shaders zu multiplizieren. Dabei würde man aber in keiner Art und Weise die unterschiedliche Komplexität der einzelnen Anweisungen berücksichtigen.

Alternativ könnte man die benötigten Anweisungsslots als Faktor nutzten. Die DX-Spec gibt für jeden Anweisung eine Anzahl von Slots an die durch sie belegt werden. Dieses Liste ist allerdings eher technischer Natur als unter dem reinen Leistunggesichtspunkt ausfgebaut.

Eine eher aufwendige Alternative wäre das zerlegen eines Shaders in seine mathematischen Grundfunktionen deren Summe dann der Faktor bildet. Allerdings ist auch das nicht ganz unproblematisch. Gerade bei den 1.X Shadern lassen sich in einer einzigen Anweisungszeile viele Berechnungen unterbringen. Ein Shader der davon rege Gebrauch macht würde als auf einen sehr hohen faktor kommen.

Egal was man also als Massstab heranzieht können einzelne Shader das Ergebniss in die eine oder andere Richtung verfälschen. Dagegen könnte man aber mit einer Datenbasis an Shader die möglichst gross ist vorgehen. Einzelne Ausreiser könnte kompensiert werden.

Es bleibt aber nach wie vor die Frage wie man einzelne Anweisungen innerhalb eines Shaders gewichten sollte. Sind eine Skalar oder Vektor3 Operation genauso viel Wert wie eine Vektor4 Operation? Sollte man Modifiziere (damit lassen sich zusätzliche einfache berechnungen als Teil der eigentlich Anweisung vor dieser ausführen) extra berücksichtigen oder nicht? Bei PS 1.X sind diese so zahlreich vorhanden das man beim umwandeln eines 1.X Shaders zu einem 2.0 Shader durchaus plötzlich viel mehr Anweisungen hat weil es bei 2.0 kaum noch Modifizierer gibt und diese durch "normale" Anweisungen ersetzt werden müssen.

Fragen über Fragen die einer Antwort harren.

[MadManniMan]

Anfänglich wollte ich jubelnd aufschreien, würdest du doch meiner Bitte nachkommen, mir einen relativ eindeutigen Indikator für Shaderleistung aufzuzeigen.
Doch nun stehe ich vor der Frage: "Ömm, wenn nicht du das beantworten kannst, wer dann?"

OK, wird sicherlich eine schöene Diskussion zwischen dir, zecki und Xmas - vielleicht auch noch anderen - , aber im Endeffekt wirds wohl leider unspaßig für ordinäres Forengetier wie Meinereiner...

Wie dem auch sei... Guten morgen! Ich geh jetzt ins Bett.

Manni

[Quasar]

Mit einer Gewichtung im Hinblick auf richtige DX9-Games (in dem Sinne, daß UT2003 eines der ersten richtigen DX7-Games ist), muss man IMO ziemlich aufpassen.

Die Funktionen, die, AFAIK, momentan genutzt werden, sind eher einfache, aber umso aufwendigere Full-Screen Effekte, wie Hitzeflimmern, Unschärfe etc.. Die wirklich aufwendigen Shader aber habe ich, so wie die meisten von uns, wohl noch kaum zu Gesicht bekommen.

Außerdem denke ich für den Anfang, daß man die Shaderleistung teilen sollte - und zwar in DX8-Shader und DX9-Shader (auch wenn jetzt gleich wieder einige kommen und sagen, auch PS1.1 ist in DX9 spezifiziert). Ansonsten würde man IMO zu stark eine Gleichmacherei betreiben, wo keine ist, d.h. die recht starken INT-Shader der FX würden die recht schwachen FP-Shader evtl. auf ein unverdient hohes Level hieven.

Außerdem wäre es gut zu schauen (falls das machbar ist), was die jeweiligen Treiber aus den einzelnen Anweisungen machen - IIRC gab es da das Gerücht, die "sincos"-Funktion würde auf nV in Hardware (Daher evtl. auch die niedrigeren Werte der GeForce4 im 3DMark2001SE Nature. FX kanns nun in HW und macht es auch, GeForce3/4 müssen nun lange lange rechnen...?) bis zu 7x schneller laufen, als auf R300, weswegen letztere dies über eine LookUp-Approximation anstellt. Auch wenn sich dieses Beispiel als nichtig herausstellt, das Prinzip sollte dasselbe sein.
Solche Funktionen sollten dann eher in der real umgesetzten Art und Weise implementiert werden.

Edit:
Direkt noch vergessen: Wie wäre ein "Effizienzfaktor", der die auf noch zu bestimmende Art und Weise gewonnene Shaderleistung in Relation zur Texelfüllrate setzt?

[Demirug]

Original geschrieben von MadManniMan
Anfänglich wollte ich jubelnd aufschreien, würdest du doch meiner Bitte nachkommen, mir einen relativ eindeutigen Indikator für Shaderleistung aufzuzeigen.
Doch nun stehe ich vor der Frage: "Ömm, wenn nicht du das beantworten kannst, wer dann?"

OK, wird sicherlich eine schöene Diskussion zwischen dir, zecki und Xmas - vielleicht auch noch anderen - , aber im Endeffekt wirds wohl leider unspaßig für ordinäres Forengetier wie Meinereiner...

Wie dem auch sei... Guten morgen! Ich geh jetzt ins Bett.

Manni

Das Ziel dieses Threads soll es ja es ja sein einen solchen Indikator zu definieren. Es macht eben nur wenig Sinn wenn ich das jetzt im Alleingang tun würde.

[Demirug]

Original geschrieben von Quasar
Außerdem denke ich für den Anfang, daß man die Shaderleistung teilen sollte - und zwar in DX8-Shader und DX9-Shader (auch wenn jetzt gleich wieder einige kommen und sagen, auch PS1.1 ist in DX9 spezifiziert). Ansonsten würde man IMO zu stark eine Gleichmacherei betreiben, wo keine ist, d.h. die recht starken INT-Shader der FX würden die recht schwachen FP-Shader evtl. auf ein unverdient hohes Level hieven.

Ja, eine Trennung macht sicherlich Sinn. Ich würde sogar dazu tendieren die 1.4 Shader in eine eigene Gruppe zu stecken. Genauso dann die 3.0 Shader.

Außerdem wäre es gut zu schauen (falls das machbar ist), was die jeweiligen Treiber aus den einzelnen Anweisungen machen - IIRC gab es da das Gerücht, die "sincos"-Funktion würde auf nV in Hardware (Daher evtl. auch die niedrigeren Werte der GeForce4 im 3DMark2001SE Nature. FX kanns nun in HW und macht es auch, GeForce3/4 müssen nun lange lange rechnen...?) bis zu 7x schneller laufen, als auf R300, weswegen letztere dies über eine LookUp-Approximation anstellt. Auch wenn sich dieses Beispiel als nichtig herausstellt, das Prinzip sollte dasselbe sein.
Solche Funktionen sollten dann eher in der real umgesetzten Art und Weise implementiert werden.

Es ist keine LookUp-Approximation sondern eine Taylor-Reihe. Die DX-Spec schreibt hier eine mit 8 Stufen vor. Deswegen braucht der R3XX auch 8 Takte hat dann aber Sinus und Cosinus errechnet. Die FXen schaffen den Sinus oder Cosinus in einem Takt. Braucht man beide Werte benötigt man eben zwei Takte. Zudem kann nur der Shadercore Sinus/Cosinus berechnungen durchführen. Genau diese Komplexität macht es ja so schwer einen einzigen Wert für die Shaderleistung festzulegen. Denn wie stark soll man zum Beispiel die Sinus/Cosinus Leistung gewichten?

Edit:
Direkt noch vergessen: Wie wäre ein "Effizienzfaktor", der die auf noch zu bestimmende Art und Weise gewonnene Shaderleistung in Relation zur Texelfüllrate setzt?

Man könnte natürlich anstatt Ops/s auch Ops/sample angeben. Ob nun ein absoluter oder relativer Wert besser ist hängt wohl von der jeweiligen Situation ab. Da sich aber der einen unter zuhilfenahme der Fillrate aus dem anderen berechnen lässt stellt das ja kein wirkliches Problem dar.

Die Frage ist aber wie du schon sagsts wie soll man eine Op definieren?

[Ailuros]

Soll das ein Massstab fuer Profis oder Amateure bzw. Laien werden?

Falls es der zweite Fall sein sollte, sind ja fortschrittliche Berechnungen und theoretische Resultate sehr hilfsreich, aber wenn sich dann in Spiel X oder Y durch Shaderoptimierung die gleiche Leistung mit gleicher Bildqualitaet ergibt, dann verliert bei mir persoenlich die Theorie irgendwo ihren Zweck.

Im Grunde wiederhole mit anderen Worten was Demi sagen wollte.

Demi,

Wie waere es mit einem synthetischen demo dass bei den einem oder anderem Fall unter besten und schlechtesten Vorraussetzungen laufen kann? Beispiel R3xx best/worst case und NV3x best/worst case. Es muesste ein ziemlich kompliziertes Projekt sein, aber wenn jemand Zeit genug dafuer hat, koennte es sich sogar zu einem Industrie-Standard entwickeln ;)

[Gast]

OT;

was soll der Thread hier? Der passt doch wesentlich besser ins Techno-Forum.

[Demirug]

Original geschrieben von Ailuros
Soll das ein Massstab fuer Profis oder Amateure bzw. Laien werden?

Natürlich eher für Laien. Die Profis können sich ja ruhig mit iheren für die Massen unverständlichen Pipeline beschreibungen rumärgner. :)

Falls es der zweite Fall sein sollte, sind ja fortschrittliche Berechnungen und theoretische Resultate sehr hilfsreich, aber wenn sich dann in Spiel X oder Y durch Shaderoptimierung die gleiche Leistung mit gleicher Bildqualitaet ergibt, dann verliert bei mir persoenlich die Theorie irgendwo ihren Zweck.

Wenn man auf die Praxis pfeift kann man ja einfach die Angaben über Ops/Takt welche es von den IHV gibt nehmen und man hat einen Indikator. Da dieser Max Wert allerdings in der Regel kaum auch nur annähernd erreicht wird wäre das wohl eine schlechte Wahl.

Demi,

Wie waere es mit einem synthetischen demo dass bei den einem oder anderem Fall unter besten und schlechtesten Vorraussetzungen laufen kann? Beispiel R3xx best/worst case und NV3x best/worst case. Es muesste ein ziemlich kompliziertes Projekt sein, aber wenn jemand Zeit genug dafuer hat, koennte es sich sogar zu einem Industrie-Standard entwickeln ;)

Es gibt ja noch andere Chips ausser von ATI und nV und von denen ist im Bezug auf Worst/Best Case ja noch weniger bekannt. Zudem lädt ein synthetischer Test mit wenigen Shadern mal wieder zu undurchsichtigen Optimierungen ein. Im Hinblick auf die Dinge mit denen Futuremark in letzter Zeit konfrontiert wurde erscheint mir das nicht der richtige Weg.

Letzten Endes interesiert die Leistung im täglichen Gebrauch. Dieser Gebrauch besteht nun mal weitgehend für die meisten in Spiele. Es macht daher eigentlich wenig Sinn irgendwelche Shaderkonstruktionen zu bewerten die wohl niemals in einem Spiel zum Einsatz kommen.

Natürlich kann man zur Bewertung der Spieleleistung irgendwelche Timedemos oder FRAPS Benchmarks durchführen. Aber wir haben ja inzwischen sehen müssen das die Wahl der Timedemo oder des Weges durchaus Einfluss auf den Gewinner haben kann. Über die Shaderleistung sagen uns solche Tests zudem auch nicht sehr viel weil neben der Shaderleistung auch noch andere Dinge eine Rolle spielen.

Aus Bewertungssicht sind die in einem Spiel verwendeten Shader aber denoch hochinteresant. Genau mit diesen muss sich eine Karte in der Praxis herumschlagen. Aus diesem Grund hat es IMHO den grössten Praxisbezug wenn man die Leistung an diesen Shadern festmacht. Misst man für jeden Shader der in einem Spiel benutzt wird die erreichbare Leistung in Pixel/s so ergibt sich eine schöne lange Tabelle die man als Kurve darstellen kann. Das Problem ist nur noch wie man die ganzen Messergebnisse auf einen Zahlenwert pro Shadergruppe reduziert. Dafür ist ehen eine Gewichtung der Shader erforderlich. Genau nach diesem Gewichtungsfaktor suche ich.

[Demirug]

Original geschrieben von Gast
OT;

was soll der Thread hier? Der passt doch wesentlich besser ins Techno-Forum.

Da es um Leistungsmessung geht hätte er auch im Benchmarkforum gepasst. Deswegen habe ich mich für das allgemeine Forum entschieden.

[Quasar]

Nun, du selbst weißt sicher besser, welche Instruktionen in welcher Häufigkeit in Shadern anzutreffen sind.

Im Besten Falle sollte man die Gewichtung dem User überlassen.
Ein Black-Box-Shader-Modul und man stellt vorher die prozentuale Verteilung von ArOps und TexOps ein, i.e. bestimmt selbst, ob man rechen- oder texturlastige Shader haben will. Dazu bestimmt man noch, ob man strikt am 2.0-Profil bleiben will oder 2.x-Shader nimmt, ob PP erlaubt oder gewünscht ist, und ob es erlaubt sein soll, daß der Treiber selbst, wo möglich, auf z.B. 1.4 reduziert. =)

Dazu bräuchte man dann natürlich ein Referenzergebnis, anhanddessen man kontrollieren kann, ob wirklich die angeforderte Genauigkeit verwandt wurde, und wenn nicht, wie hoch der prozentuale Fehler war.

(Ich glaub', das wird ganz schön kompliziert)

[Demirug]

Original geschrieben von Quasar
Nun, du selbst weißt sicher besser, welche Instruktionen in welcher Häufigkeit in Shadern anzutreffen sind.

Weiss ich das wirklich? Ich könnte sicherlich für meine Shader eine Statistik aufstellen. Aber die wirkliche Liestung ergibt sich ja leider nicht aus der Häufigkeit mit der Instruktionen auftreten. Die Verteilung innerhalb eines Shaders ist stark ausschlaggeben für die Leistung.


Im Besten Falle sollte man die Gewichtung dem User überlassen.
Ein Black-Box-Shader-Modul und man stellt vorher die prozentuale Verteilung von ArOps und TexOps ein, i.e. bestimmt selbst, ob man rechen- oder texturlastige Shader haben will. Dazu bestimmt man noch, ob man strikt am 2.0-Profil bleiben will oder 2.x-Shader nimmt, ob PP erlaubt oder gewünscht ist, und ob es erlaubt sein soll, daß der Treiber selbst, wo möglich, auf z.B. 1.4 reduziert. =)

Glaubst du nicht das diese Einstellungsvielfallt den Laien überfordert. Zum Experimentieren wäre ein solcher Schadergenerator sicherlich eine schöne Sache aber in erster Annäherung suche ich ja eigentlich erst mal nach einem Zahlenwert der ausdrückt wie gut eine Karte beim Pixelshadereinsatz performt.

[haifisch1896]

Wie wäre es wenn man eben diesen Generator anwendet, und dabei eine Zeitmessung macht? Also im Endeffekt eine feste Zahl an Frames, die gerechnet werden müssen.

[Demirug]

Original geschrieben von hendrikhey
Wie wäre es wenn man eben diesen Generator anwendet, und dabei eine Zeitmessung macht? Also im Endeffekt eine feste Zahl an Frames, die gerechnet werden müssen.

Dann haben wir aber wieder eine rein akademische Shaderleistung. Genau das will ich ja vermeiden. Das herstellen des Praxisbezugs ist auch nicht so schwer wenn man Shader nimmt die auch in bekannten und/oder in weniger bekannten Spielen benutzt werden. Das ist soweit ja alles kein Problem. Das einzige was noch fehlt ist eine Referenzleistung für jeden Shader zu der man dann die Leistung aller Chips in Bezug setzten kann.

[aths]

Original geschrieben von Demirug
Zum Experimentieren wäre ein solcher Schadergenerator sicherlich eine schöne Sache aber in erster Annäherung suche ich ja eigentlich erst mal nach einem Zahlenwert der ausdrückt wie gut eine Karte beim Pixelshadereinsatz performt. Gewichtete Benchmarks mit einigen Beispiel-Shadern. Anders geht es ja nicht.

[Demirug]

Original geschrieben von aths
Gewichtete Benchmarks mit einigen Beispiel-Shadern. Anders geht es ja nicht.

Soweit bin ich ja auch schon. Ich habe sogar schon viele viele Shader zusammen gesammelt. Die Gewichtung ist aber eben noch das Problem.

[Quasar]

Wie wäre es mit einer Einteilung nach der Wahrscheinlichkeit, mit der mit einen gegebenem Shader eine große Anzahl Pixel berechnet werden müssen?

Bsw. der Overbright-Lighting Sky im Mother Nature Test. Dank Back-to-Front wird der komplett erstmal leistungsbremsend eingesetzt.

Es gibt sicher auch Shader, die zwar häufig genutzt werden, aber nur für örtliche begrenzte Spezialfälle.

[Demirug]

Original geschrieben von Quasar
Wie wäre es mit einer Einteilung nach der Wahrscheinlichkeit, mit der mit einen gegebenem Shader eine große Anzahl Pixel berechnet werden müssen?

Bsw. der Overbright-Lighting Sky im Mother Nature Test. Dank Back-to-Front wird der komplett erstmal leistungsbremsend eingesetzt.

Es gibt sicher auch Shader, die zwar häufig genutzt werden, aber nur für örtliche begrenzte Spezialfälle.

Das wäre dann ja wiederum schon ein weiterer Schritt. Zu ermitteln wie häufig ein Shader zum Einsatz kommt. Das hatt aber primär ja erstmal nichts mit der Performance mit der eine Karte einen Shader abarbeiten kann zu tun. Es ist ja durchaus denkbar das der gleiche Shader in unterschiedlichen Spielen unterschiedlich häufig benutzt wird.

Im Moment tendiere ich stark zu dem Verfahren das Spec benutzt. Für jeden Shader einen Referenzwert festlegen und dann zwischen diesem und der tatsächlichen Leistung das Verhältniss bestimmen. Der Mittelwert aus allen Verhältnissen ergibt die Gesamtpunktzahl. Was noch fehlt ist das Verfahren zum Festlegen der Referenzwerte.

[Riptor]

Original geschrieben von Demirug
Aus Bewertungssicht sind die in einem Spiel verwendeten Shader aber denoch hochinteresant. Genau mit diesen muss sich eine Karte in der Praxis herumschlagen. Aus diesem Grund hat es IMHO den grössten Praxisbezug wenn man die Leistung an diesen Shadern festmacht. Misst man für jeden Shader der in einem Spiel benutzt wird die erreichbare Leistung in Pixel/s so ergibt sich eine schöne lange Tabelle die man als Kurve darstellen kann. Das Problem ist nur noch wie man die ganzen Messergebnisse auf einen Zahlenwert pro Shadergruppe reduziert. Dafür ist ehen eine Gewichtung der Shader erforderlich. Genau nach diesem Gewichtungsfaktor suche ich.

Heißt das, das wir demnächst einen 3DCentermark erwarten dürfen? :)
Wird sowas denn eigentlich nicht schon so in der Art von den Kollegen von Tommti-Systems mit deren Shadermark gemacht? Oder ist dieser eindeutig zu praxisuntauglich?
Was die Gewichtung angeht: Schwer, ich kenne mich zu wenig aus, um da wirklich mitreden zu können, aber interessant wäre es, diese Gewcihtung so zu verteilen, dass praxisrelevante Shader wichtiger sind, als praxisunrelevante. Dies kann sich dann natürlich auf die Dauer hin ändern, aber würde für die Zeit, wo ein Benchmark gemacht wird, sinnvoll sein. Ich habe leider keine Ahnung, inwieweit so was zu realisieren ist...

[aths]

Riptor,

der Nachteil eines solchen Benchmarks wäre, dass Demis Programm einmal mehr in den "Genuss" von treiberseitiger Applikationserkennung kommen würde.

[Riptor]

Original geschrieben von aths
der Nachteil eines solchen Benchmarks wäre, dass Demis Programm einmal mehr in den "Genuss" von treiberseitiger Applikationserkennung kommen würde.

Hmmmm... Das hast du recht, hatten wir ja schon in der Vergangenheit gesehen.

[Demirug]

Original geschrieben von aths
Riptor,

der Nachteil eines solchen Benchmarks wäre, dass Demis Programm einmal mehr in den "Genuss" von treiberseitiger Applikationserkennung kommen würde.

Das sehe ich in diesem Fall inzwischen als weniger problematisch an. Die Shader aus bekannten Spiele sind eh schon optimiert. Ein allgeimens erkennen wäre sicherlich möglich aber man ja die Fensternamen notfalls mit einem Zufallsgenerator ändern. Kritisch wird es nur wenn rein genrische Shader zum Einsatz kommen die eigentlich nichts sinnvolles machen.

[aths]

Original geschrieben von Demirug
Das sehe ich in diesem Fall inzwischen als weniger problematisch an. Die Shader aus bekannten Spiele sind eh schon optimiert. Dann könnte man ja gleich diese Spiele benchen.

Imo sollte ein Shader-Bench natürlich Recomiler erlauben (kann er sich eh nicht gegen wehren) aber bitte keine Hand-Optimierung zulassen.

Besser wäre, der Programmierer selbst beachtet einmal ATI- und einmal NV-Optimierungsregeln, und nach Möglichkeit (sofern 2_0) werden beide Shader auf beiden Karten gebencht.

[Demirug]

Original geschrieben von aths
Dann könnte man ja gleich diese Spiele benchen.

Da gibt es schon einen Unterschied. Bei einem Spiel hast du in den FPS immer noch eine ganze Mange anderer Sachen als nur die Shaderleistung. Die Verwendung von im echten Einsatz befindelichen Shader stelt zumindestens einen Praxisbezug da.

Imo sollte ein Shader-Bench natürlich Recomiler erlauben (kann er sich eh nicht gegen wehren) aber bitte keine Hand-Optimierung zulassen.

Man könnte natürlich noch einen würfelmodus einbauen der die Shader ein bischen umstrikt so das sie zwar nach wie vor das gleiche Rechnen aber in der binärform anders aussehen.

Besser wäre, der Programmierer selbst beachtet einmal ATI- und einmal NV-Optimierungsregeln, und nach Möglichkeit (sofern 2_0) werden beide Shader auf beiden Karten gebencht.

Können wir aber sicher sein das sich die Spieleentwickler immer diese Mühe machen? Theoretische Shaderbenchmarks haben wir ja schon.