Woran liegts ? (schwache D3D Performance der Mainstream FX Karten)

[Radeonator]

Tja, woran liegt es denn, das die 5600Ultra und abwärts so dermassen schwach unter D3D sind ???

1. Treiber
2. HW
3. HW + Treiber ?

Sprich : Wird durch folgende Treiber Generationen ein Performance boost kommen oder lässt die Architektur der z.B. Mainstream Lösung 5600er einfach nicht mehr zu ???

[BlackBirdSR]

Die sind doch nicht schwach :abgel: ?!?!

Wenn man sich die Mainstream Karten vor der NV3x ansieht -> GF4 MX, und dann mit der 5200Ultra und 5600 vergleicht, sieht es doch ganz ok aus, oder nicht?

natürlich ist der Unterschied zur Gamer-Mainstream Karte aka Ti4200 nicht groß, wenn überhaupt. Aber dafür ist eh die 5600Ultra/5700 Ultra zuständig.

[Endorphine]

Die FX5600 Ultra wurde doch gerade erst in den Taktraten hochspezifiziert. Ich sehe da keine Lücke in nVidia's Portfolio. Oder habe ich was übersehen?

[Ailuros]

Original geschrieben von Endorphine
Die FX5600 Ultra wurde doch gerade erst in den Taktraten hochspezifiziert. Ich sehe da keine Lücke in nVidia's Portfolio. Oder habe ich was übersehen?

Mir persoenlich waere eigentlich eine NV25@13nm mit sehr hoher Taktrate + schnellerem Speicher lieber gewesen. Filter on scanout haette man ja wohl auf 4xMSAA erweitern koennen. Das Problem warum dann wohl doch nicht dafuer entschieden wurde, sind dann wohl vielleicht Shader/Transistoren Anzahl (da man ja auf dx9.0 von unten bis oben gezielt hat), und dass die Leistung wohl eine FX5800 nicht mehr so toll gewesen waere im Vergleich.

Ach was soll's, IHV's versuchen ihr Bestes zu tun fuer jede bestimmte Zeitspalte.

[mapel110]

tja, nvidia kleckert lieber bei der performance. sie saugen die kunden mit hier und da 10 fps mehr bei jeder neuen karte regelrecht aus.
statt mal nen richtigen performance boost zu bringen.

füllrate ist dann eben doch das entscheidende kaufkriterium, wenns um zocken geht.
und da bringt nvidia lieber produkte mit klaren abständen. bei ATI ists ja nicht so.

siehe 9500 pro (8 pipes) oder 9600 pro (mit hohem chiptakt 400 mhz).
von der rohperformance her bei 1024er ohne AF/AA nicht weit weg von der 9700/9800.

[Radeonator]

Also ich hab mir noch nen paar Reviews von der 5600Ultra reingezogen und überall war ein eindeutiges Fazit : Keine schlechte Karte aber zu schlechte D3D Leistung.
Die 5600Ultra bricht ihn hohen Auflösungen teilweise um 50% ein. Ich habe von keiner Lücke gesprochen, sondern von schlechten D3D Leistungm, also bitte nur darüber diskutieren.

Was mich stört ist der extrem kleine Abstand zwischen der 4200 und der 5600Ultra. 5200er sind imo keine Mainstream Karten, genauso wenig wie die GF4MX (die GF2MX war hingegen eine, zu deren Zeit waren die NV Karten allerdings anders eingeteilt als heutzutage, deshalb kann man hier absolut nicht vergleichen!).

Es stimmt meiner Meinung nicht ganz, das Nvidia mit mehr Leistung "kleckert". Die Sprünge zwischen gf1-gf2-gf3-gf4 Mainstream waren schon ziemlich groß.Die Mainstream Karten, bzw die Karten die ich so bezeichne, hatten sonst in etwa die Performance wie die Highend Karte der Vorgänger Reihe.Also hätte die Roh Performance der 5600Ultra in etwa auf GF4600er Niveau liegen müssen, so wie es ATi mit der 9500Pro vorgemacht hat (jaja, bitte nicht wieder das aba die 9600Pro ist doch eigentlich...geplärre, das tut in diesem Bsp nichts zur Sache und ich denke ihr versteht worauf ich hinaus will... ) Ich kann mir deshalb nicht vorstellen, das gerade in dieser Zeit, wo ATi in aller Munde ist, Nvidia mit absicht eine derart schwache D3D Vorstellung abliefert.

Also bitte zurück zum Topic (ohne die Fanatische bzw Nvidiotische brille ;) )

Architektur Fehler (unter OGL läuft die Karte zur Hochform auf, ist Sie evtl nur in diese Richtung Optimiert worden ? )
Treiber noch nicht i.O. (wieder das gleiche Bild unter OGL hui, unter D3D Pfui inkl falschdarstellungen etc. )

[Endorphine]

Original geschrieben von Ailuros
Mir persoenlich waere eigentlich eine NV25@13nm mit sehr hoher Taktrate + schnellerem Speicher lieber gewesen. Filter on scanout haette man ja wohl auf 4xMSAA erweitern koennen. Das Problem warum dann wohl doch nicht dafuer entschieden wurde, sind dann wohl vielleicht Shader/Transistoren Anzahl (da man ja auf dx9.0 von unten bis oben gezielt hat), und dass die Leistung wohl eine FX5800 nicht mehr so toll gewesen waere im Vergleich.

Ach was soll's, IHV's versuchen ihr Bestes zu tun fuer jede bestimmte Zeitspalte. Hätte wohl derzeit auch mehr Sinn gemacht. Nur eben vom Marketingaspekt schwieriger zu verkaufen (DX9 fehlt). Und dann auch schade wegen der DX9-Marktdurchdringung und für die Kunden wegen fehlender Longhorn-Beschleunigung.

Mir sagt die FX5600 auch überhaupt nicht zu. Wer soll diese Karte kaufen? Teuer und nicht sonderlich schnell. Teilweise sind sogar R9700 billiger.

@Thread: Ich seh grade Radeonator meinte wohl wirklich nur die D3D-Leistung. Wo fallen die kleineren fxen denn da aus dem Rahmen?

[Ailuros]

Radeonator,

Wenn sowas nur in einem der beiden API's zu bemerken ist, koennten weitere D3D spezifische Optimierungen vielleicht schon helfen.

Ich hatte eine 5600 schon selber am Durchrennen aber es gibt in der Zwischenzeit neuere Treiber und die Spezifikationen wurden auch leicht erhoeht. Auf der ersten 5600 hat mir OGL auch nicht besonders imponiert im Vergleich zu NV25 in SS:SE z.B.; natuerlich hab ich auch nur Quality Aniso gegen Quality Aniso verglichen um ehrlich zu sein.

[Radeonator]

Die Karten fallen ab Auflösungen jenseits der 1024x768 sehr stark in der Leistung ab.Da sind ohne extreme Quali Einstellungen mal gerade mit ach und krach GF4 Ti4200 Werte drin (zu wenig Roh Performance lässt auch keine großen Sprünge im Quali Bereich zu). Das obwohl die GF4 deutlich niedriger getaktet ist, finde ich schon erstaunlich! Handelt es sich hier um eine zu schnell an den Markt gekommene Karte und soll dieser "Fehler" evtl. mit der NV36 (soll ja eine Mainstream Karte werden) ausgebügelt werden??? Gibt es irgendeine Nvidia Site, wo vielleicht Aufklärung betrieben wird (sowie für ATi die Rage3D Seite, wo die Catalyst Crew sich im Forum tummelt... ) ???

[Sphinx]

planet3dnow.de - Themenabende

[robbitop]

man muss dazu sagen, dass der NV25 bei gleichem Takt 2x Texelfüllrate der NV31 besitzt.

[Radeonator]

Naja, nach den Reviews der Ultra Rev.2 liefert sie bei endsprechendem Takt ganz ordentliche Ergebnisse, nun muss Sie nur noch unter 200Euro fallen...:)

http://www.hardavenue.com/reviews/gffx5600u_ut2003fb.gif

[robbitop]

es gibt bald ein ausführliches Review bei www.seijin.de dazu :)

[Radeonator]

Original geschrieben von robbitop
es gibt bald ein ausführliches Review bei www.seijin.de dazu :)

Hast du ne Ahnung welche Hersteller sich die Rev.2 zu eigen machen werden ???

[Demirug]

Also meine bisherige Erfahrung zeigt das die FXen immer dann heftig unter D3D einbrechen wenn man sich auf "Neuland" begibt. Also Dinge benutzt welche die GF4 noch nicht unterstützt haben. Besonder krass ist zum Beispiel der Einbruch wenn man mit der DX7 Pipeline von 4 auf 5 Texturelayer geht. Bei OpenGL hat man das Problem in dem Sinn ja nicht so extreme weil die alten Extensions ja keinen Zugriff auf die neuen Funktionen erlauben und es bisher kaum eine Anwendung gibt welche die neuen Extensions schon nutzt.

[robbitop]

die Gainward und BFG..mehr sind mir momentan nicht bekannt

[LovesuckZ]

Original geschrieben von Endorphine
@Thread: Ich seh grade Radeonator meinte wohl wirklich nur die D3D-Leistung. Wo fallen die kleineren fxen denn da aus dem Rahmen?

Splinter Cell.
Eine 5800 liegt mit 500MHZ "nur" auf 9800pro, eine 5900 Ultra sogar "nur" auf 9700pro Niveau in der Beyond3d.com Demo.
Nvidia hat's diesmal einfach verbockt. Die Leistung unter D3D ist alles andere als akzeptabel, vorallen im Mainstreambereich (5600/Ultra) ist man der Konkurenz einfach icht gewachsen.
Ob Leistung mit dem so sehnlich herbeigewuenschten Deto 5x.xx besser werde, ist nicht abzusehen, eher egeh ich davon aus, dass die Geschwindigkeit langsamer wird, wolle doch nvidia, laut eines User's aus dem NVNews.com Forum, die "Cheatz" entfernen.

[robbitop]

ich gehe davon aus, dass die Geschwindigkeit stark mit Treibern steigen wird, denn die Architektur ist recht variabel und muss zT vergangene Sachen abbilden...ich denke mit dem 50ern wird ein nochmaliger Sprung vor allem im Bereich Pixelshader vorkommen

BTW wenn eine Applikation ohne erkennbares (oder sagen wir SIGNIFIKANNT erkennbares) Deizit an Bildqualitöt auftritt ist es eine Optimierung, die ich lobenswert finde...aber für Benches favorisiere ich immo CustomBenches..dort kann man optimierungen von cheats sehr schön trennen. Optimierung ist es wenn es überall gilt (man spielt ja mit so einer Karte und bencht nicht deshalb muss genau hier optoimiert werden)....in festen benches ist es fast zwangsläufig Cheat....wir von Seijin werden neben Refferenz Benches auch Customs machen. Weiterhin auch ein paar AA Modi neben 4xMSAA...denn das wird auf Dauer uninteressant und das kann man auch gerne bei Onkel Tom lesen ;)

[zeckensack]

Original geschrieben von robbitop
Weiterhin auch ein paar AA Modi neben 4xMSAA...Ausgezeichnet! =)

[LovesuckZ]

Original geschrieben von robbitop
ich gehe davon aus, dass die Geschwindigkeit stark mit Treibern steigen wird, denn die Architektur ist recht variabel und muss zT vergangene Sachen abbilden...ich denke mit dem 50ern wird ein nochmaliger Sprung vor allem im Bereich Pixelshader vorkommen


Ich glaube nicht dadran, lasse mich jedoch auch gerne überraschen.
Nochmal zu Splinter Cell: Firingsquad haben in ihrem neusten review eine eigene Timedemo genommen und ploetzlich ist die 5900 auf 9800pro niveau. Daher ist meine vorrige Aussage nur noch halb wahr.

Weiterhin auch ein paar AA Modi neben 4xMSAA...denn das wird auf Dauer uninteressant und das kann man auch gerne bei Onkel Tom lesen ;)

Und der Sinn? Eine r>=300 Karte kann nur 2/4/6 MSAA und Nvidia nur 2/4. Alle anderen Modien sind daher nicht vergleichbar vom Speed, von der Qualitaet jedoch. Die frage die ich mir stelle ist: Bei meiner 5800 "Ultra" ist 4xS in 1024*768 genauso schnell wie 4MS in 1280*1024 (das duerfte sich bei der 5900 oder hoeher noch deutlicher ausschlagen). Warum sollte ich also mit 4xS zocken, wenn ich eine hoehere Aufloesung nehmen kann?

[Radeonator]

@Demirug : Heisst das, das durch Treiber Optimierung was gemacht werden kann??? Es liest sich jedenfalls so.

[Demirug]

Original geschrieben von Radeonator
@Demirug : Heisst das, das durch Treiber Optimierung was gemacht werden kann??? Es liest sich jedenfalls so.

Ich habe da durchaus Hoffnung. Aber die stirbt ja bekanntermassen zuletzt. :)

Jemand von nv meinte das sie sich erst mal darum kümmern wollen das es keine Fehler gibt und dann die Performance steigern wollen. In wie weit das jetzt aber marketing blabla oder ehrlich gemeint war kann ich nicht sagen.

[zeckensack]

Original geschrieben von LovesuckZ
... warum sollte ich also mit 4xS zocken, wenn ich eine hoehere Aufloesung nehmen kann? Wenn du das gleiche Problem hast wie ich (Monitor geht nur bis 1280x1024), dann macht das schon Sinn :)

[StefanV]

Original geschrieben von LovesuckZ
Bei meiner 5800 "Ultra" ist 4xS in 1024*768 genauso schnell wie 4MS in 1280*1024 (das duerfte sich bei der 5900 oder hoeher noch deutlicher ausschlagen). Warum sollte ich also mit 4xS zocken, wenn ich eine hoehere Aufloesung nehmen kann?

Schonmal dran gedacht, daß es einige Leute mit 'nem 'Festfrequenz' Monitor mit 15" Bilderzeugerplatte haben und nicht jeder ein 24" Monitor mit 200kHz??

Denn ein schlauer Mensch überprüft ersteinmal, ob er überhaupt die Auflösung wirklich erhöhen kann, z.B. ob der Monitor noch mindestens 75Hz in der gewünschten Auflösung schafft bzw 85Hz...

Und selbst dann sollte der Monitor nicht 2 Pixel in ein Loch der Maske zu quetschen wollen, was z.B. bei 17ern ab 1280x960 vorkommen kann...

€dit:

Momentan hab ich alles andere als Finazprobleme, ich könnte mir in 2 Monaten z.B. ein Notebook oder 'nen 19" TFT anschaffen, so ich denn wollte...

Ich könnte das Geld allerdings auch zurücklegen und für ein neueres und größeres bzw ein eigenes Auto sparen, da mir das Fahrzeug, das ich jetzt fahre nicht wirklich gefällt...

Und aufgrund von 1):

Nicht jeder hat soviel Geld, wie ich bzw hat das Bedürfnis viel Geld auszugeben!!

Da du selbst Schüler bist, wars ein Schuss ins Knie, da man als Schüler nicht wirklich das Geld für 'nen tollen Schirm hat...
Eine GraKa ist da schon eher drin, das merkt man auch meist früher als 'nen shittigen Schirm...

[Razor]

Original geschrieben von Radeonator
Hast du ne Ahnung welche Hersteller sich die Rev.2 zu eigen machen werden ???
Creativ wird wohl gleich die Rev.2 heraus bringen...

Razor

[Razor]

Original geschrieben von Demirug
Ich habe da durchaus Hoffnung. Aber die stirbt ja bekanntermassen zuletzt. :)

Jemand von nv meinte das sie sich erst mal darum kümmern wollen das es keine Fehler gibt und dann die Performance steigern wollen. In wie weit das jetzt aber marketing blabla oder ehrlich gemeint war kann ich nicht sagen.
Das haben sie damals mit der gf3 genauso gemacht... erst einmal auf Kompatibilität getrimmt... erst dann auf Speed. Ist halt ein etwas anderer Ansatz als bei ATI und ich hoffe inständig, dass sie dass so beibehalten werden.

Razor

[Razor]

@Stefan

Halt einfach den Rand, wenn Du nichts zu Thema zu sagen hast...
Das, was Du da abgelassen hast, zeigt doch wirklich wie 'arm' Du tatsächlich bist.

In diesem Sinne

Razor

[StefanV]

Original geschrieben von Razor
Das haben sie damals mit der gf3 genauso gemacht... erst einmal auf Kompatibilität getrimmt... erst dann auf Speed. Ist halt ein etwas anderer Ansatz als bei ATI und ich hoffe inständig, dass sie dass so beibehalten werden.

Razor

Wenn man fies wäre, dann würde man an dieser Stelle behaupten, daß NV erstmal die Treiberteile der GF2 auf die GF3 umgeschrieben hätte, so das das Teil überhaupt läuft und später erst den 'echten' Treiber ausgeliefert habern, wofür sie natürlich von allerhand Leuten ein Lob eingesteckt haben :kotz:...

Wohingegen ATI ihre Karten gleich mit einem 'echten' Treiber ausliefert und nicht einen 'umgebastelten'...

[StefanV]

@Razor

Wenn du mich nicht magst bzw eines meiner Postings, dann antworte nicht dadrauf...

Desweiteren stehe ich nicht so sehr auf Beleidigungen, weswegen ich mich bemühe andere nicht zu beleidigen und auch von anderen erwarte, daß sie mich nicht beileidigen, da ich sie nicht beleidige...

Mehr hab ich zu den Zeilen, die du mir an den Kopf geschmissen hast, nicht zu sagen...

[robbitop]

das durfte man ja beim R300 und R200 sehen ...beim R100 auch...

[Razor]

Original geschrieben von Stefan Payne
@Razor

Wenn du mich nicht magst bzw eines meiner Postings, dann antworte nicht dadrauf...
Versuch Dir bitte nochmal den Inhalt meines Postings zu Gemüte zu führen.
Offensichtlich hast Du rein gar nichts verstanden. Schade eingentlich...

Razor

[StefanV]

@Razor

Durch solche Postings wie 'versuch dir den Inhalt meines Postings nochmal zu Gemüte zu führen', änderst du auch nichts!!

Ganz im Gegenteil, wie wäre es, wenn du dich bemühen würdest, das zu erklären, was du sagen wolltest anstatt gleich jemanden anzumachen??

[Razor]

Original geschrieben von robbitop
das durfte man ja beim R300 und R200 sehen ...beim R100 auch...
Das habe ich auch gerade gedacht...
Die Treiber für den R100 waren das Letzte... nach ca. einenm Jahr haben sich diese halbwegst stabilisiert. Bei R200 das Gleiche, nur das es hier ein bisel schneller ging. So hatte man 'schon' nach ca. 6 Monaten halbwegs brauchbare Treiber. Und zu guter letzt beim R300... Cat3.2 oder jetzt auch Cat3.4 sind OK, der Rest war murks...

Von wegen "richtige Treiber"...
:lol:

Mir ist es wichtig, dass ein Treiber erst einmal überall (!) läuft und erst dann kommt bei mir die Performance.
Und einen anderer Weg ist auch keinesfalls wünschenswert !

Razor

[Razor]

Original geschrieben von Stefan Payne
Ganz im Gegenteil, wie wäre es, wenn du dich bemühen würdest, das zu erklären, was du sagen wolltest anstatt gleich jemanden anzumachen??
Dann erkläre Du mir doch bitte erst einmal, was Dein 'nettes' Posting an Love mit dem Thread oder seinem Posting zu tun gehabt haben sollte. Wenn Du das in einen logischen Zusammenhang bringst, ohne dabei wieder vom Thema zu 'rutschen' werde ich mich offiziell bei Dir entschuldigen, wenn nicht, halt einfach den Rand, OK ?

Razor

[AlfredENeumann]

Original geschrieben von Razor
Das habe ich auch gerade gedacht...
Die Treiber für den R100 waren das Letzte... nach ca. einenm Jahr haben sich diese halbwegst stabilisiert. Bei R200 das Gleiche, nur das es hier ein bisel schneller ging. So hatte man 'schon' nach ca. 6 Monaten halbwegs brauchbare Treiber. Und zu guter letzt beim R300... Cat3.2 oder jetzt auch Cat3.4 sind OK, der Rest war murks...

Von wegen "richtige Treiber"...
:lol:

Mir ist es wichtig, dass ein Treiber erst einmal überall (!) läuft und erst dann kommt bei mir die Performance.
Und einen anderer Weg ist auch keinesfalls wünschenswert !

Razor



Und die treiber für die FX waren auf anhieb perfekt?

[robbitop]

imho ging es recht schnell. Ich glaube der 2. oder 3. Treiber war recht gut. Und das bevor sie breit verfügbar waren. Der aktuelle Treiber scheint extrem gut zu sein.

[LovesuckZ]

Original geschrieben von AlfredENeumann
Und die treiber für die FX waren auf anhieb perfekt?

So ungefaehr. Siehe nggalai. Für ihn ist der 43.45 der zur Zeit beste Treiber. Und dies ist der erste offizielle von nvidia für die FX. 44.03 und auch der beta 44.65 haben aus meiner Sicht kleine Schwaechen, die nicht weltbewegend sind (das koennen und duerfen andere anders sehen). Man kann schon fast sagen, die Treiber sind perfekt.

[Exxtreme]

Mädelz,

bitte das Topic beachten. =)

Wenn ihr über Treiber diskutieren wollt, dann macht bitte einen eigenen Thread auf.

[Razor]

Original geschrieben von AlfredENeumann
Und die treiber für die FX waren auf anhieb perfekt?
Perfekt nicht... aber der erste offizielle Treiber (43.45) ist noch immer der Beste, wenn auch nicht unbedingt der schnellste... das kommt jetzt !
:D

Razor

[Razor]

Original geschrieben von robbitop
imho ging es recht schnell. Ich glaube der 2. oder 3. Treiber war recht gut. Und das bevor sie breit verfügbar waren. Der aktuelle Treiber scheint extrem gut zu sein.
Auch wenn's noch immer leicht OT ist... der aktuellste (44.03) hat so einige Probleme mit dem Overlay (bei mir mit dem FullScreenDevice, bei nggalai im allgemeinen). Aber hinsichtlich der (D3D-Quality-) Performance ist er ein großer Schritt nach vorne.

Wenn dies jetzt noch intensiviert wird und mit den guten Feature-Eigenschaften des 43.45 kombiniert wird, dann dürfte sich das Thread-Thema ebenso erledigt haben.

Razor

[Razor]

Original geschrieben von Exxtreme
Mädelz,

bitte das Topic beachten. =)

Wenn ihr über Treiber diskutieren wollt, dann macht bitte einen eigenen Thread auf.
Meinst Du nicht, dass die Treiber einen wesentlichen Einfluss auf die Performance haben ?
???

Razor

[Exxtreme]

Original geschrieben von Razor
Meinst Du nicht, dass die Treiber einen wesentlichen Einfluss auf die Performance haben ?
???

Razor
Schon, aber die Tendenz der letzten Postings zeigt IMHO ganz klar, daß es wieder in einem Flamewar "AT-Treiber vs. NV-Treiber" ausgeartet wäre.

Ich hoffe, du verstehst. :)

P.S. Mein Posting war auch eigentlich eher an die ATi-Fraktion gerichtet.

[robbitop]

schon ma den 44.65 probiert?

[Razor]

Original geschrieben von Exxtreme
Schon, aber die Tendenz der letzten Postings zeigt IMHO ganz klar, daß es wieder in einem Flamewar "AT-Treiber vs. NV-Treiber" ausgeartet wäre.

Ich hoffe, du verstehst. :)
OK, akzeptiert...
Schade nur, dass SP hier wieder ATI ins Spiel gebracht hat.
Und eine solche Falschaussage 'muss' man einfach relativieren...
(was hiermit aber sein Ende findet, wenn nicht wieder jemand damit anfängt !)
:D

Razor

P.S.: Dein "P.S." zu spät gelesen... ;-)

[Razor]

Original geschrieben von robbitop
schon ma den 44.65 probiert?
Performance gut, Features gut, Taktsteuerung schlecht, Kompatibilität fast gut...
(vielleicht ein bissel kurz ?)
:D

Razor

[robbitop]

ich denk mal der 50er dürfte ne Offenbarung werden :D

[Quasar]

Original geschrieben von Demirug
Also meine bisherige Erfahrung zeigt das die FXen immer dann heftig unter D3D einbrechen wenn man sich auf "Neuland" begibt. Also Dinge benutzt welche die GF4 noch nicht unterstützt haben. Besonder krass ist zum Beispiel der Einbruch wenn man mit der DX7 Pipeline von 4 auf 5 Texturelayer geht. Bei OpenGL hat man das Problem in dem Sinn ja nicht so extreme weil die alten Extensions ja keinen Zugriff auf die neuen Funktionen erlauben und es bisher kaum eine Anwendung gibt welche die neuen Extensions schon nutzt.

Diese "neuen" Dinge benutzen, AFAIK, ja auch nicht mehr die "alte" Pipeline, sondern die neue "CineFX"-Engine, sprich, den einen (FX5200)/ die zwei (FX5600) / oder die vier (FX5800+) neuen Pipeline-Teile.

Ich denke nicht, dass man für die alten Einheiten extra noch einen weiteren Loopback eingebaut hat, um z.B. unter DX7 mehr als 4 Texturen zu nutzen, im Gegenteil exponiert bsw. der OpenGL ICD unter jener API auch nur vierfaches (single-pass) Multitexturing (...).

Da wird man bei nVidia wohl nachgerechnet haben und entschieden, dass ein Single-Pass mit neuer Pipe immer noch "billiger" ist, als ein Multipass im alten Stile.

Nur eine grobe Schätzung (Weiterhin glaube ich, dass man mit dem TriSetup, was wohl jetzt mit im VS-"Array" integriert ist, noch ein paar Probleme hat, aber das kann ich nicht oder kaum belegen).

[robbitop]

hallo Quasar, klingt wirklich interessant, aber auf welche Art von Problemen willst du herraus?

[Quasar]

Performance-Probleme, was sonst?

[robbitop]

ach ws du nicht sagst :D

ich meine woraus meinst du resultiert diese Einbusse? also was könnte dieses Problem hervorrufen deiner spekulation nach?

[LovesuckZ]

Original geschrieben von robbitop
ich denk mal der 50er dürfte ne Offenbarung werden :D

hm, glaube ich nicht. Was soll da noch kommen?
Wahrscheinlich wird das der erste treiber sein, um dem sich nen riesiger Hype aufbaut/aufgebauen wird :D

[robbitop]

Reife und PS Performance...gerüchten zufolge sollen irgendwie shader applikationsoptimiert sein. ein ShaderOptimizer...vieleicht auch etwas mehr D3D Performance

[Razor]

Original geschrieben von robbitop
Reife und PS Performance...gerüchten zufolge sollen irgendwie shader applikationsoptimiert sein. ein ShaderOptimizer...vieleicht auch etwas mehr D3D Performance
Vielleicht ja auch der von Demirug propagierte Shader-(Re-)Compiler...

Schaun' wir mal, aber da es ja nun derzeit um Kompatibilität und Feature-Stabilisierung geht, sollte in den folgenden Releases die grundlegende Performance angegangen werden... so wie es nVidia immer machte.

Und wenn man den jetzigen Status der Treiber in Betracht zieht, dürften sie wohl bald die 'Vorarbeiten' abgeschlossen haben.

Razor

[Demirug]

Original geschrieben von Quasar
Diese "neuen" Dinge benutzen, AFAIK, ja auch nicht mehr die "alte" Pipeline, sondern die neue "CineFX"-Engine, sprich, den einen (FX5200)/ die zwei (FX5600) / oder die vier (FX5800+) neuen Pipeline-Teile.

Ich denke nicht, dass man für die alten Einheiten extra noch einen weiteren Loopback eingebaut hat, um z.B. unter DX7 mehr als 4 Texturen zu nutzen, im Gegenteil exponiert bsw. der OpenGL ICD unter jener API auch nur vierfaches (single-pass) Multitexturing (...).

Da wird man bei nVidia wohl nachgerechnet haben und entschieden, dass ein Single-Pass mit neuer Pipe immer noch "billiger" ist, als ein Multipass im alten Stile.

Ja in dem Moment habe ich nicht daran gedacht das meine 5200 ja nur eine vollständige CineFX Pipe hat. Diese setzt übrigens etwa 400M Aritimetik Ops/s durch. Und ja wahrscheinlich müssen DX7 Setups mit mehr als 4 Texturen über die eine Pipeline laufen. Jetzt müsste man nur nochmal auspropieren ob man die 2 TMUs der anderen Pipe irgendwie noch nutzen kann.

Nur eine grobe Schätzung (Weiterhin glaube ich, dass man mit dem TriSetup, was wohl jetzt mit im VS-"Array" integriert ist, noch ein paar Probleme hat, aber das kann ich nicht oder kaum belegen).

Trisetup im VS-Array? Wie kommst du den darauf? Das macht eigentlich keine Sinn.

[Quasar]

Original geschrieben von Demirug
Ja in dem Moment habe ich nicht daran gedacht das meine 5200 ja nur eine vollständige CineFX Pipe hat. Diese setzt übrigens etwa 400M Aritimetik Ops/s durch. Und ja wahrscheinlich müssen DX7 Setups mit mehr als 4 Texturen über die eine Pipeline laufen. Jetzt müsste man nur nochmal auspropieren ob man die 2 TMUs der anderen Pipe irgendwie noch nutzen kann.

Bei der "ultra" wo wohl die Bandbreite auch nicht so knapp bemessen ist, scheint es irgendwie in Verbindung mit Stencil-Ops möglich zu sein, "brachliegende" Teile der bei multitexturing ungenutzten Pipes sehr sehr effizient zu nutzen
Ich kann reproduzierbar im Fablemark mit der FX5200u höhere Werte als mit der FX5600u erreichen, zwar nur ohne FSAA/AF, aber nichtsdestoweniger interessant, da die 5200u sogar noch mit 25MHz weniger taktet.

Original geschrieben von Demirug
Trisetup im VS-Array? Wie kommst du den darauf? Das macht eigentlich keine Sinn.
Eigentlich nicht, dessen bin ich mir bewusst.
edit: Aber wie sicher bist du dir, im Gegenzug gefragt, dass das TriSetup im nV3x noch eine komplett separierte Funktionseinheit ist?
Vielleicht wird es auch nicht komplett dort gemacht, aber angesichts der "Verlagerung" der Architektur beim nV3x denke ich, dass es durchaus möglich ist, dass das Tri-Setup in gewissem Maße in das VS-Array gewandert ist, bzw. sich vitale Ressourcen mit diesem teilt.

Aber wenn ich jetzt behaupten würde, dass ein VS-intensives Game wie Max Payne selbst in 640x480 bereits bei 2xAA einen reproduzierbaren Einbruch der Framerate von ~4fps (93xx vs. 89,xx) erzeugt, kann ich mir das nur so erklären. Denn für ein "verlustfreies" 2xAA (in 640x480) sollten 27GB/s eigentlich genug sein, oder?

[Quasar]

Original geschrieben von robbitop
ach ws du nicht sagst :D

ich meine woraus meinst du resultiert diese Einbusse? also was könnte dieses Problem hervorrufen deiner spekulation nach?
s.o. =)

[robbitop]

in der theorie ja, aber offenbar ist Multisamplich nicht nur Bandbreitenabhänigig. Ich habe die 9500nonPro damals mit 256bit DDR einmal bei 4xRGMSAA nur im Speicher übertaktet. Kein signifikanter Performancesprung. Als ich den Core anhob bekam ich diesen Performanceschub. Und dennoch hat 4xAA ca 35% Leistung gefressen obwohl die Bandbreite in diesem Fall offenbar nicht limitierende Komponente war.

[Demirug]

Original geschrieben von Quasar
Bei der "ultra" wo wohl die Bandbreite auch nicht so knapp bemessen ist, scheint es irgendwie in Verbindung mit Stencil-Ops möglich zu sein, "brachliegende" Teile der bei multitexturing ungenutzten Pipes sehr sehr effizient zu nutzen
Ich kann reproduzierbar im Fablemark mit der FX5200u höhere Werte als mit der FX5600u erreichen, zwar nur ohne FSAA/AF, aber nichtsdestoweniger interessant, da die 5200u sogar noch mit 25MHz weniger taktet.

Beim schreiben der Stencilschatten liegt ja normalerweise ein Grossteil der Pixelpipeline lahm. Möglicherweise hat man da eine möglichkeit gefunden da noch ein bischen was doch zu nutzten.

Eigentlich nicht, dessen bin ich mir bewusst.
edit: Aber wie sicher bist du dir, im Gegenzug gefragt, dass das TriSetup im nV3x noch eine komplett separierte Funktionseinheit ist?
Vielleicht wird es auch nicht komplett dort gemacht, aber angesichts der "Verlagerung" der Architektur beim nV3x denke ich, dass es durchaus möglich ist, dass das Tri-Setup in gewissem Maße in das VS-Array gewandert ist, bzw. sich vitale Ressourcen mit diesem teilt.

Aber wenn ich jetzt behaupten würde, dass ein VS-intensives Game wie Max Payne selbst in 640x480 bereits bei 2xAA einen reproduzierbaren Einbruch der Framerate von ~4fps (93xx vs. 89,xx) erzeugt, kann ich mir das nur so erklären. Denn für ein "verlustfreies" 2xAA (in 640x480) sollten 27GB/s eigentlich genug sein, oder?

Sicher kann man sich natürlich nie sein.

Bei der Funktionweise des Trisetups ist es erforderlich das zwischen VS und Trisetup ein Vertexcache liegt. Zudem ist die Funktionalität des Trisetups geradezu ideal um das alles Fest zu verdrahten.

Edit: Der Einbruch bei Max-Payne kann auch mit den beim Multisampling entstehenden Kantenpixel die ja mehrfach gerechnet werden müssen zusammen hängen.

[Keel]

Original geschrieben von robbitop
ich denk mal der 50er dürfte ne Offenbarung werden :D
Original geschrieben von robbitop
Reife und PS Performance...gerüchten zufolge sollen irgendwie shader applikationsoptimiert sein. ein ShaderOptimizer...vieleicht auch etwas mehr D3D Performance

Dein Wort in Gottes Ohr, auch wenn ich da eher etwas misstrauisch bin. Natürlich würde ich so etwas gern sehen, wenn NV tatsächlich bzgl. der im Augenblick schlechten (zumindest im Vergleich zu ATI) Shaderleistung noch etwas reißen könnte.
Gibt es denn ein schon halbwegs glaubwürdige Gerüchte, die ein Erscheinungsdatum nennen?

[Razor]

Original geschrieben von Keel
Dein Wort in Gottes Ohr, auch wenn ich da eher etwas misstrauisch bin. Natürlich würde ich so etwas gern sehen, wenn NV tatsächlich bzgl. der im Augenblick schlechten (zumindest im Vergleich zu ATI) Shaderleistung noch etwas reißen könnte.
Gibt es denn ein schon halbwegs glaubwürdige Gerüchte, die ein Erscheinungsdatum nennen?
Ohne hier jetzt wieder in heillosem Geflame unterzugehen...

Die NV3x-Architektur verarbeitet Shader anders, als es die R3x0-Architektur tut. Der M$-Compiler hat bisher nur ATI-freundlichen Code ausgespuckt, wird zuküftig aber auch einen nVidia-'freundlichen' Code generieren können.

Im Prinzip müsste man etwas in den Treiber bauen, der einen M$-erzeugten Standardcode disassembliert und daraus einen nVidia-freundlichen Code erzeugt, solange sich der neue M$-Compiler noch in er Beta-Phase befindet.

Die R3x0'er erscheinen nur deswegen derzeit so stark, weil der Code speziell auf dessen Architektur optimiert ist. Eine Vergleichbarkeit entsteht aber erst dann, wenn beide Chip-Architekturen optimal unterstützt werden und bis dahin würde ich von einer Quantifizierung der Shader-Leistung bei nVidia erst einmal abstand nehmen.

Bis denne

Razor

[Exxtreme]

Original geschrieben von Razor

Im Prinzip müsste man etwas in den Treiber bauen, der einen M$-erzeugten Standardcode disassembliert und daraus einen nVidia-freundlichen Code erzeugt, solange sich der neue M$-Compiler noch in er Beta-Phase befindet.

Eieiei, also so einen Re-Assembler möchte ich nicht schreiben wollen. :)

Und auch dieser Re-Assembler wäre IMHO nie effektiv genug um da was zu reissen da man sehr viele Möglichkeiten, etwas zu programmieren abdecken müsste.

Das Programm müsste erkennen können, was der Programmierer eigentlich will und dann entsprechend reagieren.

Ich denke, es ist besser wenn NV auf den Compiler von MS wartet.

[robbitop]

wo genau kommt der MS Compiler zum Einsatz

was eine Möglichkeit wäre, Applikationangepasste Shaderprofile. Sprich für alle Anwendungen und Games diese Profile die im Treiber sind und ab und zu per klick geupdatet werden. Absolut denkbar.

[Demirug]

Original geschrieben von Exxtreme
Eieiei, also so einen Re-Assembler möchte ich nicht schreiben wollen. :)

Und auch dieser Re-Assembler wäre IMHO nie effektiv genug um da was zu reissen da man sehr viele Möglichkeiten, etwas zu programmieren abdecken müsste.

Das Programm müsste erkennen können, was der Programmierer eigentlich will und dann entsprechend reagieren.

Ich denke, es ist besser wenn NV auf den Compiler von MS wartet.

Exxtreme beides macht Sinn. nv muss auch für den Fall gerüstet sein das sie 2.0 Shader vorgesetzt bekommen. In diesem Fall ist ein suboptimaler Cross-Assembler immer noch besser als gar keiner.

Zudem ist das Hauptproblem der derzeigten 2.0 Shader die Rheienfolge und die extensive Benutzung von Registern. Das liegt noch beides im Rahmen des machbaren. Zudem habe ich sehr gute Erfahrungen mit einem MSIL -> Cg/HLSL Crosscompiler gemacht bei dem die Problematik ähnlich ist.

[Demirug]

Original geschrieben von robbitop
wo genau kommt der MS Compiler zum Einsatz

was eine Möglichkeit wäre, Applikationangepasste Shaderprofile. Sprich für alle Anwendungen und Games diese Profile die im Treiber sind und ab und zu per klick geupdatet werden. Absolut denkbar.

Der MS Compiler ist ein Teil von D3DX und wir entweder bei den Entwicklern eingestzt um HLSL Shader in Assembler shader zu Compileren welche dann ausgelifert werden.

Die zweite Variante ist es den Compiler in das Spiel einzubauen und den HLSL Code beizulegen welcher dann erst beim Endanwender compiliert wird.


Von dieser Treiber ruft zuhause an und lädt sich optimierungsprofile vom Server Technik habe ich auch schon was gehört.

[Exxtreme]

Wenn der Shadercode in Form von einer HLSL vorliegt, dann ist das auch kein Problem. Den Low-Level-Shadercode wieder zurück in eine HLSL umzuwandeln und dann wieder in eine andere Form des Assembler-Codes ist ungleich schwieriger. Und wenn ein Programmierer noch manuell rumgefummelt hat, dann gute Nacht.

Deswegen bin ich, wie zecki auch, dafür, daß die Spiele-Programmierer die Shader als HLSL ausliefern und dieser erst zur Laufzeit kompiliert wird. Dann hat man auch kein Affentheater.

[Razor]

Original geschrieben von Exxtreme
Eieiei, also so einen Re-Assembler möchte ich nicht schreiben wollen. :)
Ich auch nicht !
:D
Original geschrieben von Exxtreme
Und auch dieser Re-Assembler wäre IMHO nie effektiv genug um da was zu reissen da man sehr viele Möglichkeiten, etwas zu programmieren abdecken müsste.
Nicht so ganz. Es geht ja nur um den Code, der vom alten M$-Compiler ausgespuckt wird. Das zu erkennen, dürfte relativ einfach sein und auch das disassembieren dürfte dabei recht einfach vonstatten gehen. Daraus dann den Sourcecode zu rekonstruieren und einen neuen code zu compilieren, der besser auf die eigene Architektur optimiert ist, dürfte dann nur noch Makulatur sein.

Schwieriger dürfte es mit den 'handgeschriebenen' Shadern sein, die direkt in Assembler geschrieben wurden. Da kommt dann der von Dir genannte Aspekt zum Tragen:
Original geschrieben von Exxtreme
Das Programm müsste erkennen können, was der Programmierer eigentlich will und dann entsprechend reagieren.
Exakt... hierfür muss es dann eine Art KI geben, die felxibel genug wäre, auf 'handgeschriebene' Shader zu reagieren. Aber ich denke, dass man mit dem einfach Schritt beginnen sollte, oder ?
;-)
Original geschrieben von Exxtreme
Ich denke, es ist besser wenn NV auf den Compiler von MS wartet.
Dann erldigen sich ja gewisse Problematiken von selbst, nicht aber das Problem mit den 'handgeschriebenen' Sachen... die ja zwangsweise entweder auf die eine oder andere Architektur ausgelegt wäre... da fällt mit übrigens auch ATI gut daran täte, so etwas für ihre Treiber anzudenken, denn was würde wohl passieren, wenn da jemand auf die nVidia-Architektur optimiert... (damit meine ich jetzt nicht den vom M$-Compiler erzeugten nVidia-Code, der auf einer ATI ja nicht einmal ausführbar wäre)

Razor

[Razor]

Original geschrieben von Exxtreme
Wenn der Shadercode in Form von einer HLSL vorliegt, dann ist das auch kein Problem.
Wie jetzt ?

Wenn der Shader in Form eines HLSL vorliegt, könnte ein im Game (meinetwaegen auch nachträglich) integrierter Cg-Compiler den einfach compilieren und schon ist's gut. Schließlich erzeugt der neue M$-Compiler ja aus dem gleichen Source unterschiedliche Compilate...

Nicht nur, dass es kein Problem wäre... nein... das Problem wäre gar keines !
Original geschrieben von Exxtreme
Den Low-Level-Shadercode wieder zurück in eine HLSL umzuwandeln und dann wieder in eine andere Form der LLSL ist ungleich schwieriger.
Nö ist es nicht...
Wenn der Compiler bekannt ist, dann ist dies ohne weiteres machbar.
Original geschrieben von Exxtreme
Und wenn ein Programmierer noch manuell rumgefummelt hat, dann gute Nacht.
Das ist allerdings etwas anderes.
Deswegen ja auch 2. (nachträgliche) Weg...
;-)
Original geschrieben von Exxtreme
Deswegen bin ich, wie zecki auch, dafür, daß die Spiele-Programmierer die Shader als HLSL ausliefern und dieser erst zur Laufzeit kompiliert wird. Dann hat man auch kein Affentheater.
Wäre natürlich der Idealfall... aber ich kann auch Demirug verstehen, der da gewisse Probleme bezüglich des Schutzes der eigenen Entwicklung hat. Schließlich wären solch 'offene' Shader ja quasi 'open Source', oder ?

Bis denne

Razor

[Demirug]

Original geschrieben von Razor
Wäre natürlich der Idealfall... aber ich kann auch Demirug verstehen, der da gewisse Probleme bezüglich des Schutzes der eigenen Entwicklung hat. Schließlich wären solch 'offene' Shader ja quasi 'open Source', oder ?

Bis denne

Razor

Wie? ich habe da gar kein Problem mit. Zudem kann man sich den Code von jedem Shader sowieso beschaffen (s. 3d Analyse). Und wenn man wirklich paranoid ist kann man den HLSL Code ja crypten.

[Exxtreme]

Original geschrieben von Razor
Wie jetzt ?

Wenn der Shader in Form eines HLSL vorliegt, könnte ein im Game (meinetwaegen auch nachträglich) integrierter Cg-Compiler den einfach compilieren und schon ist's gut. Schließlich erzeugt der neue M$-Compiler ja aus dem gleichen Source unterschiedliche Compilate...

Nicht nur, dass es kein Problem wäre... nein... das Problem wäre gar keines !

Eben. :)

Wobei ich den Compiler weniger im Game intergrieren würde. Ein Grafikkarten-Treiber bietet sich eher an.
Original geschrieben von Razor
Nö ist es nicht...
Wenn der Compiler bekannt ist, dann ist dies ohne weiteres machbar.

So einfach ist es nicht... glaub's mir. Das funktioniert NUR wenn der Shader-Compiler keinerlei Optimierungen vornimmt. Und dann ist die Gefahr groß, daß du nicht den Original-Code sondern einen "equivalenten" HLSL-Code bekommst da beim Programmieren viele Wege nach Rom führen.

Original geschrieben von Razor
Wäre natürlich der Idealfall... aber ich kann auch Demirug verstehen, der da gewisse Probleme bezüglich des Schutzes der eigenen Entwicklung hat. Schließlich wären solch 'offene' Shader ja quasi 'open Source', oder ?

Bis denne

Razor
Wenn man wirklich die Shader-Codes verbergen will, dann könnte man sie verschlüsseln und erst zur Laufzeit entschlüsseln.

[Razor]

Original geschrieben von Demirug
Wie? ich habe da gar kein Problem mit. Zudem kann man sich den Code von jedem Shader sowieso beschaffen (s. 3d Analyse). Und wenn man wirklich paranoid ist kann man den HLSL Code ja crypten.
Ups, da habe ich Dich dann wohl mißverstanden...
;-)

Razor

[Razor]

Original geschrieben von Exxtreme
Eben. :)

Wobei ich den Compiler weniger im Game intergrieren würde. Ein Grafikkarten-Treiber bietet sich eher an.
Wäre das rein technisch möglich ?
I.e. sieht die DX-API eine solche Verfahrensweise wor ?
???
Original geschrieben von Exxtreme
So einfach ist es nicht... glaub's mir. Das funktioniert NUR wenn der Shader-Compiler keinerlei Optimierungen vornimmt. Und dann ist die Gefahr groß, daß du nicht den Original-Code sondern einen "equivalenten" HLSL-Code bekommst da beim Programmieren viele Wege nach Rom führen.
Wie gesagt, wenn man den verwendeten Compiler kennt, dann ist das Ergebnis (also das Compilat) vorhersehbar. Auch dessen Struktur kann recht einfach 'erkannt' und damit dann auch disassembliert werden. 'Äquivalenter' Code ist nicht das Problem, da er ja wohl das gleiche machen dürfte, wie auch das Orginal (nur eben 'einfacher' ;-).
Original geschrieben von Exxtreme
Wenn man wirklich die Shader-Codes verbergen will, dann könnte man sie verschlüsseln und erst zur Laufzeit entschlüsseln.
Nö, auchdas würde nichts nützen, es sei denn die API sieht eine Kryptologie-Stufe vor und kann so verkrypteten Code entgegen nehmen. Allerdings dürfte diese Form von Verschlüsselung auch nicht lange ein Geheimnis bleiben...

Razor

[Demirug]

Original geschrieben von Exxtreme
Eben. :)

Wobei ich den Compiler weniger im Game intergrieren würde. Ein Grafikkarten-Treiber bietet sich eher an.

hehe über die Pros und contras der beiden Techniken hatte ich ja mit Zecki schon eine längeren Diskussion.

So einfach ist es nicht... glaub's mir. Das funktioniert NUR wenn der Shader-Compiler keinerlei Optimierungen vornimmt. Und dann ist die Gefahr groß, daß du nicht den Original-Code sondern einen "equivalenten" HLSL-Code bekommst da beim Programmieren viele Wege nach Rom führen.

So viele möglichkeiten zur optimierung gibt es aufgrund der länge von Shaderprogrammen derzeit kaum. Ausser Registerusage und Rheienfolge kann man da kaum was machen.


Wenn man wirklich die Shader-Codes verbergen will, dann könnte man sie verschlüsseln und erst zur Laufzeit entschlüsseln.

Und selbst dann kommt man ja wie gesagt noch an den Code ran.

[Exxtreme]

Original geschrieben von Razor
Wäre das rein technisch möglich ?
I.e. sieht die DX-API eine solche Verfahrensweise wor ?
???

AFAIK übernimmt DX nicht die Assemblierung des HLSL-Codes. Man könnte das dem Treiber überlassen. Wäre viel praktischer, da sich die Leistung mit einer neuen Treiberversion erhöhen könnte etc.
Original geschrieben von Razor
Wie gesagt, wenn man den verwendeten Compiler kennt, dann ist das Ergebnis (also das Compilat) vorhersehbar. Auch dessen Struktur kann recht einfach 'erkannt' und damit dann auch disassembliert werden. 'Äquivalenter' Code ist nicht das Problem, da er ja wohl das gleiche machen dürfte, wie auch das Orginal (nur eben 'einfacher' ;-).

Wenn der Compiler nicht Opensource ist, dann hat man wenig Chancen. Was meinste wie einfach es sonst wäre normale Anwendungen wieder in eine für Menschen lesbare Hochsprache zurückzukonvertieren?
Original geschrieben von Razor
Nö, auchdas würde nichts nützen, es sei denn die API sieht eine Kryptologie-Stufe vor und kann so verkrypteten Code entgegen nehmen. Allerdings dürfte diese Form von Verschlüsselung auch nicht lange ein Geheimnis bleiben...

Razor
Komplett wird man die Shader nicht verbergen können denn spätestens bei der übergabe an das API müssen diese im Klartext vorliegen.

[Demirug]

Original geschrieben von Exxtreme
AFAIK übernimmt DX nicht die Assemblierung des HLSL-Codes. Man könnte das dem Treiber überlassen. Wäre viel praktischer, da sich die Leistung mit einer neuen Treiberversion erhöhen könnte etc.

Jaein. Der Compiler ist ein Teil von D3DX. D3DX stellt eine Erweiterung da welche keinen direkten Einfluss auf die Treiber hat.

DirectX Treiber müssen nur den Assemblercode in einer Binären Form verstehen.

Wenn der Compiler nicht Opensource ist, dann hat man wenig Chancen. Was meinste wie einfach es sonst wäre normale Anwendungen wieder in eine für Menschen lesbare Hochsprache zurückzukonvertieren?

Wie gesagt Shader sind kurz genung das die meisten Probleme wie man sie beim recompile normaler Anwendungen hat nicht auftreten. Aber du hast Recht das man von einer Hochsprache aus bessere Ergebnisse erreichen kann.

Komplett wird man die Shader nicht verbergen können denn spätestens bei der übergabe an das API müssen diese im Klartext vorliegen.

Sie liegen in einer binären Form vor die aber zurück übersetzt werden kann. 3d analyse macht das zum Beispiel.

[Keel]

Original geschrieben von Razor
Ohne hier jetzt wieder in heillosem Geflame unterzugehen...

Die NV3x-Architektur verarbeitet Shader anders, als es die R3x0-Architektur tut. Der M$-Compiler hat bisher nur ATI-freundlichen Code ausgespuckt, wird zuküftig aber auch einen nVidia-'freundlichen' Code generieren können.

Im Prinzip müsste man etwas in den Treiber bauen, der einen M$-erzeugten Standardcode disassembliert und daraus einen nVidia-freundlichen Code erzeugt, solange sich der neue M$-Compiler noch in er Beta-Phase befindet.

Die R3x0'er erscheinen nur deswegen derzeit so stark, weil der Code speziell auf dessen Architektur optimiert ist. Eine Vergleichbarkeit entsteht aber erst dann, wenn beide Chip-Architekturen optimal unterstützt werden und bis dahin würde ich von einer Quantifizierung der Shader-Leistung bei nVidia erst einmal abstand nehmen.

Bis denne

Razor

==> "...wenn NV tatsächlich bzgl. der im Augenblick schlechten (zumindest im Vergleich zu ATI) Shaderleistung noch etwas reißen könnte."

Im Augenblick ist die Performance jedoch eher sehr mager. Und wie sie sein sollte, ist hier denke ich mal zu vernachlässigen, mich interessiert nur, wie sie letztendlich ist.

Dann formuliere ich meine Frage halt neu: Weiß man denn schon in etwa, wann MS einen solchen Compiler herausbringen wird? Das würde mich mal sehr interessieren... :)

[Demirug]

Original geschrieben von Keel
==> "...wenn NV tatsächlich bzgl. der im Augenblick schlechten (zumindest im Vergleich zu ATI) Shaderleistung noch etwas reißen könnte."

Im Augenblick ist die Performance jedoch eher sehr mager. Und wie sie sein sollte, ist hier denke ich mal zu vernachlässigen, mich interessiert nur, wie sie letztendlich ist.

Dann formuliere ich meine Frage halt neu: Weiß man denn schon in etwa, wann MS einen solchen Compiler herausbringen wird? Das würde mich mal sehr interessieren... :)

Den Compiler habe ich hier auf meinem Rechner als Beta-Version.