Anandtech GQ Artikel [Archiv]

Archiv verlassen und diese Seite im Standarddesign anzeigen : Anandtech GQ Artikel

Gast

2003-12-11, 23:25:11

schauts euch mal an: http://www.anandtech.com/video/showdoc.html?i=1931

vieles was 3dcenter schon belegt und besprochen hat wird teils vereinfacht mal zusammengefasst.

auf seite 6 wird der af tester genutzt und der letzte satz is typisch :" NVIDIA assures us that if we can point out a loss in image quality in any game, they will correct it. "

btw die jedi knight bilder finde ich gut gelungen, da sieht jeder, dass es unterschiede gibbet ^^

mapel110

2003-12-11, 23:58:27

irgendwie sieht man auf vielen shots garkeine unterschiede. zb ut2003. da sind wohl nen paar screenshots in die binsen gegangen.
ansonsten noch nen paar sinnlose vergleiche, weil unterschiedliche position, unterschiedlicher lichteinfall.... naja, mir gefällts irgendwie nicht. :(
hätte man wohl besser machen können.

Exxtreme

2003-12-12, 00:57:35

Also ich finde den Artikel eher lustig. Er könnte von Brian Burke stammen oder so. :D Das Teil ist IMHO biased hoch drei.

This has been dubbed “brilinear” filtering by some, as the method blends bilinear filtering more heavily than usual into higher order filtering techniques. We have yet to see any perceptible image quality issues arise from this, and as long as banding is not evident and the highest possible resolution textures are used, this filtering method serves its purpose. NVIDIA assures us that if we can point out a loss in image quality in any game, they will correct it.
Herr Wilson hat also keinen Unterschied bemerkt zw. "echtem" trilinear und "brilinear". Schön für ihn. Leider sehen das einige Leute anders. Und der letzte Satz ist auch nicht schlecht. Sowas Ähnliches hat Kyle Bennet auch schon zu hören bekommen. :D

Also, ATI has helped us track down the motion issue that we've been seeing on their cards. ATI supports using a separate filtering scheme for texture magnification (filtering when the screen pixels are smaller than texels) and minification (filtering when the screen pixels are larger than texels). NVIDIA hardware requires that magnification be done using the same filtering method as minification. Since TRAOD only requests anisotropic filtering be done on texture minification, NVIDIA does anisotropic filtering just fine while ATI doesn't do anisotropic filtering on magnification. The difference in filtering methods causes the flickering effect by which we have been bothered, and could be fixed via a patch from EIDOS; though, ATI reports that EIDOS is unwilling to do so. ATI could fix the problem themselves by doing application detection (determining that TRAOD is running and then adjusting settings specific to that game), but ATI is unwilling to take this step (even though it would be valid and helpful) in order to avoid the controversy.
Hier soll wohl der Berg zum Propheten kommen, was? Treiber sind nicht dazu da um Unstimmigkeiten von Applikationen auszugleichen. Und wenn ATi dieses Problem per Treiber fixt, dann könnte man in einem späteren Review behaupten, daß TR:AOD vom Treiber erkannt wird und die Ergebnisse ercheatet sein könnten. Ein Schelm, ein Schelm...

Weiter gayt's mit AM3:

Originally, we had noticed this issue in frame 4000, and NVIDIA pointed out an instance of the problem in frame 5100
Ist doch nett von Nvidia, daß sie auf "Unstimmigkeiten" von ATi-HW hinweisen.Da wollte wohl jemand sicherstellen, daß das von Herrn Wilson ja nicht übersehen wird. :D

NVIDIA hardware does more work than ATI
Kein Kommentar. :D

Lustig ist auch der BQ-Vergleich von Halo. Herr Wilson behauptet zwar, daß ATi falsch rendert, Beweise liefert er für diese Behauptung aber nicht. Wo sind Screenshots mit dem RefRast?

Und ob AA und AF benutzt wurde, darf man in den meisten Fällen auch raten. Bei Jedi Academy sagt er es, daß 4x AA + 8x AF benutzt wurde. Manchmal kann man es auch am Dateinamen der Bilddatei erkennen.

Gast

2003-12-12, 01:32:47

Original geschrieben von Exxtreme
Herr Wilson hat also keinen Unterschied bemerkt zw. "echtem" trilinear und "brilinear". Schön für ihn. Leider sehen das einige Leute anders.

Treiber sind nicht dazu da um Unstimmigkeiten von Applikationen auszugleichen. Und wenn ATi dieses Problem per Treiber fixt, dann könnte man in einem späteren Review behaupten, daß TR:AOD vom Treiber erkannt wird und die Ergebnisse ercheatet sein könnten. Ein Schelm, ein Schelm...

Ist doch nett von Nvidia, daß sie auf "Unstimmigkeiten" von ATi-HW hinweisen.Da wollte wohl jemand sicherstellen, daß das von Herrn Wilson ja nicht übersehen wird. :D

Angeblich sollen ja manche Leute auf einem Auge blind sein, je nachdem, welche Hardware sie favorisieren und sich deshalb eins zurechtlügen.... hüben wie drüben.

Treiber sind unter anderem dafür da, den Kunden zufrieden zu stellen. Wenn ein App-Dev sich weigert, etwas zu patchen, vermittle das mal deinem Kunden: no-go.
Was bleibt als Ausweg? Richtig, Applikationserkennung. Unter anderem deswegen war ich damals so vehement dagegen, als Unwinders Script dem "Markt" durchflutete, weil man nicht weiß, ob man eine gute oder eine böse Optimierung damit killt.

Daß dies nun öffentlich gesagt wird ist neu, nicht jedoch, daß ein IHV Reviewern Tips gibt, wo sie bei dem anderen IHV suchen sollen...

Q

Gast

2003-12-12, 01:40:05

Original geschrieben von Exxtreme
Lustig ist auch der BQ-Vergleich von Halo. Herr Wilson behauptet zwar, daß ATi falsch rendert, Beweise liefert er für diese Behauptung aber nicht. Wo sind Screenshots mit dem RefRast?

Falsch. Er sagt, Gearbox habe das behauptet, aber er wäre nicht sicher, worauf sie sich dabei bezögen.

Wie soll er dann für sowas Beweise liefern???

MadManniMan

2003-12-12, 02:57:34

BTW, wo ich grad die Halo-Screenis sehe...

...ich bin mit meiner R95P und meiner R90 mit der Taschenlampe rumgelaufen und muß sagen, daß der Effekt der Radeon (R95P) wesentlich besser kommt, als der der GeForce (R90) ...

Szilard

2003-12-12, 03:16:08

Halo wurde ja echt subba verglichen a) Nicht gleiche Stelle und b) Einmal mit Taschenlampe und einmal ohne :bonk:

'edit' Jedi Academy (8xAF): ATI mit 8xAF = Kantenglättung? Sieht nämlich so aus :???:

[dzp]Viper

2003-12-12, 08:21:55

Original geschrieben von MadManniMan
BTW, wo ich grad die Halo-Screenis sehe...

...ich bin mit meiner R95P und meiner R90 mit der Taschenlampe rumgelaufen und muß sagen, daß der Effekt der Radeon (R95P) wesentlich besser kommt, als der der GeForce (R90) ...

finde ich persönlich auch... jeder der mal eine taschenlampe in der Hand hatte, wird wissen, dass sie so einen leuchtkegel abstrahlt!

An die leute mit Xbox - wie sieht den da der Leuchtkegel aus?

Exxtreme

2003-12-12, 09:37:02

Original geschrieben von Gast
Angeblich sollen ja manche Leute auf einem Auge blind sein, je nachdem, welche Hardware sie favorisieren und sich deshalb eins zurechtlügen.... hüben wie drüben.

Ja, das Gerücht habe ich auch schon gehört. ;)
Original geschrieben von Gast
Treiber sind unter anderem dafür da, den Kunden zufrieden zu stellen. Wenn ein App-Dev sich weigert, etwas zu patchen, vermittle das mal deinem Kunden: no-go.
Was bleibt als Ausweg? Richtig, Applikationserkennung. Unter anderem deswegen war ich damals so vehement dagegen, als Unwinders Script dem "Markt" durchflutete, weil man nicht weiß, ob man eine gute oder eine böse Optimierung damit killt.

Die eigentliche Aufgabe eines Treibers ist die Hardware ansprechbar und verfügbar zu machen und nicht irgendwelche Bugs in Applikationen zu umgehen. Wäre ja noch schöner. Sobald IHV richtig damit anfängt, wirst du noch viel mehr verbuggte Spiele zu sehen bekommen denn die IHVs gleichen die Bugs per Treiber aus, gelle? Und wenn nicht, dann haben sie shice Treiber... wird es heissen. Und auf 150 MB Treiber habe ich jedenfalls keine Lust.

Und ich frage mich ernsthaft, warum Eidos diese Unstimmigkeit nicht korrigiert. Wollen sie nicht oder dürfen sie nicht?
Original geschrieben von Gast
Daß dies nun öffentlich gesagt wird ist neu, nicht jedoch, daß ein IHV Reviewern Tips gibt, wo sie bei dem anderen IHV suchen sollen...

Q
Ja, daß Herr Wilson das so offen zugibt, wundert mich ehrlich gesagt auch.

Exxtreme

2003-12-12, 09:40:39

Original geschrieben von Gast
Wie soll er dann für sowas Beweise liefern???
Microsoft liefert ein Tool namens Reference Rastersizer. Das liefert gute Indizien ob etwas korrekt gerendert wird oder nicht.

BlackBirdSR

2003-12-12, 11:49:44

Original geschrieben von Exxtreme
Also ich finde den Artikel eher lustig. Er könnte von Brian Burke stammen oder so. :D Das Teil ist IMHO biased hoch drei.

Herr Wilson hat also keinen Unterschied bemerkt zw. "echtem" trilinear und "brilinear". Schön für ihn. Leider sehen das einige Leute anders. Und der letzte Satz ist auch nicht schlecht. Sowas Ähnliches hat Kyle Bennet auch schon zu hören bekommen. :D

Hier soll wohl der Berg zum Propheten kommen, was? Treiber sind nicht dazu da um Unstimmigkeiten von Applikationen auszugleichen. Und wenn ATi dieses Problem per Treiber fixt, dann könnte man in einem späteren Review behaupten, daß TR:AOD vom Treiber erkannt wird und die Ergebnisse ercheatet sein könnten. Ein Schelm, ein Schelm...

Weiter gayt's mit AM3:

Ist doch nett von Nvidia, daß sie auf "Unstimmigkeiten" von ATi-HW hinweisen.Da wollte wohl jemand sicherstellen, daß das von Herrn Wilson ja nicht übersehen wird. :D

Kein Kommentar. :D

Lustig ist auch der BQ-Vergleich von Halo. Herr Wilson behauptet zwar, daß ATi falsch rendert, Beweise liefert er für diese Behauptung aber nicht. Wo sind Screenshots mit dem RefRast?

Und ob AA und AF benutzt wurde, darf man in den meisten Fällen auch raten. Bei Jedi Academy sagt er es, daß 4x AA + 8x AF benutzt wurde. Manchmal kann man es auch am Dateinamen der Bilddatei erkennen.

sag mal, wäre es nicht anständiger die Poster bei Beyond3d zu zitieren, als deren Antworten auf Deutsch zu deinen zu machen?
Falls dem so sein, denn Einiges von dir, habe ich in English wortwörtlich eben gerade auf Beyond3d gelesen...

Exxtreme

2003-12-12, 11:52:34

Original geschrieben von BlackBirdSR
sag mal, wäre es nicht anständiger die Poster bei Beyond3d zu zitieren, als deren Antworten auf Deutsch zu deinen zu machen?
Falls dem so sein, denn Einiges von dir, habe ich in English wortwörtlich eben gerade auf Beyond3d gelesen...
B3D? Ich war längere nicht mehr dort. Welcher Thread?

Edit: Gefunden. :)
http://www.beyond3d.com/forum/viewtopic.php?t=9414

Ja, ich kritisiere fast die gleichen Dinge aber es ist keine 1 zu 1-Übersetzung der Argumente dort. :)

Gast

2003-12-12, 11:55:11

Original geschrieben von Exxtreme
Die eigentliche Aufgabe eines Treibers ist die Hardware ansprechbar und verfügbar zu machen und nicht irgendwelche Bugs in Applikationen zu umgehen. Wäre ja noch schöner. Sobald IHV richtig damit anfängt, wirst du noch viel mehr verbuggte Spiele zu sehen bekommen denn die IHVs gleichen die Bugs per Treiber aus, gelle? Und wenn nicht, dann haben sie shice Treiber... wird es heissen. Und auf 150 MB Treiber habe ich jedenfalls keine Lust.

Halooo McFly! Aufwachen, McFly! ;)
Mal im Ernst, was meinst du, was die letzten Jahre alles so passiert ist?
AFAIK ist es gängige Praxis, zumindest die "kleineren" Bug von großen Titeln im Treiber zu umgehen, wo es denn geht.

Original geschrieben von Exxtreme
Microsoft liefert ein Tool namens Reference Rastersizer. Das liefert gute Indizien ob etwas korrekt gerendert wird oder nicht.

Das ja, nur:
Wie Wilson sagt, weiß er nicht, auf was sich die Heinis von Gearbox genau beziehen.... Soll er das komplette Game im RefRast laufen lassen und alle Frames vergleichen?

Gut, er hätte nachfragen können...

Q

Exxtreme

2003-12-12, 12:02:00

Original geschrieben von Gast
Halooo McFly! Aufwachen, McFly! ;)
Mal im Ernst, was meinst du, was die letzten Jahre alles so passiert ist?
AFAIK ist es gängige Praxis, zumindest die "kleineren" Bug von großen Titeln im Treiber zu umgehen, wo es denn geht.

Mag sein. Trotzdem ist eher Eidos in der Pflicht sowas auszubessern und nicht ATi.
Original geschrieben von Gast
Das ja, nur:
Wie Wilson sagt, weiß er nicht, auf was sich die Heinis von Gearbox genau beziehen.... Soll er das komplette Game im RefRast laufen lassen und alle Frames vergleichen?

Gut, er hätte nachfragen können...

Q
Eben. Das ist eine typische Nullaussage von Wilson. "Wir wissen zwar, daß es im ATi-Treiber einen Bug gibt, wir wissen aber nicht wo und wie er sich auswirkt". Diese Aussage trifft auf so ziemlich jede komplexere Software zu.

ShadowXX

2003-12-12, 12:21:35

Original geschrieben von Exxtreme
Eben. Das ist eine typische Nullaussage von Wilson. "Wir wissen zwar, daß es im ATi-Treiber einen Bug gibt, wir wissen aber nicht wo und wie er sich auswirkt". Diese Aussage trifft auf so ziemlich jede komplexere Software zu.

Man sollte noch dazu ergänzen: "und auch auch auf ziemlich jede komplexere Hardware ....".

Das wird nämlich gerne übersehen...

J.S.Shadow

Gast

2003-12-12, 12:23:02

Original geschrieben von Exxtreme
Mag sein. Trotzdem ist eher Eidos in der Pflicht sowas auszubessern und nicht ATi.

Aber sicher. Nur die wollen/können/dürfen (?) nicht. Wenn ich ATi wäre und bei mir Beschwerde-Mails eintrudelten, dann würde ich überlegen, nicht doch zu patchen, schließlich will man den mittlerweile guten Ruf, den sich die Treibercrew für aktuelle Spiele-Chip-Kombinationen hart erarbeitet hat, ja nicht gleich wieder verlieren und evtl. auch die eine oder andere Next-Gen-HW verkaufen.

Original geschrieben von Exxtreme
Eben. Das ist eine typische Nullaussage von Wilson. "Wir wissen zwar, daß es im ATi-Treiber einen Bug gibt, wir wissen aber nicht wo und wie er sich auswirkt". Diese Aussage trifft auf so ziemlich jede komplexere Software zu.

Typisch? Nu ja, wenn du meinst, ich kenn' ihn nicht so gut.
Aber wie gesagt, er hätte die Gearbox-Heinis schon fragen können...

Q

Exxtreme

2003-12-12, 12:37:27

Original geschrieben von Gast
Aber sicher. Nur die wollen/können/dürfen (?) nicht. Wenn ich ATi wäre und bei mir Beschwerde-Mails eintrudelten, dann würde ich überlegen, nicht doch zu patchen, schließlich will man den mittlerweile guten Ruf, den sich die Treibercrew für aktuelle Spiele-Chip-Kombinationen hart erarbeitet hat, ja nicht gleich wieder verlieren und evtl. auch die eine oder andere Next-Gen-HW verkaufen.

Ja, ATi ist in einem Dilemma. Die Frage ist jetzt, ob ein Spiel es wert ist, daß man einen Extra-Fix im Treiber implementiert. Und diese Unstimmigkeit, die Eidos da produziert hat, dürfte auch nur ein Texturflimmern zufolge haben. Den meisten Kunden fällt sowas eigentlich nicht auf.
Original geschrieben von Gast
Typisch? Nu ja, wenn du meinst, ich kenn' ihn nicht so gut.
Aber wie gesagt, er hätte die Gearbox-Heinis schon fragen können...

Q
Sorry, ich habe mich etwas missverständlich ausgedrückt. Gemeint war "typische Nullaussage" und nicht "typisch Wilson". :)

Demirug

2003-12-12, 13:09:01

Diese undefinierbaren und scheinbar völlig wahlloss auftretenden Renderprobleme bei R3XX Chips erinnern mich doch an etwas.

Da gab es doch dieses merkwürde "Partial Precision" Problem. Bei Shadern die Partial Precision Register benutzten kommt es dabei immer mal wieder zu Unstimmigkeiten. Das ganze ist völlig unverstandlich weil ATI ja nur FP24 hat und die PP Flags eigentlich ignorieren könnte. Bei den 3.7 Treibern wurde das auf jeden Fall öfter beobachtet ob man es inzwischen gefixt hat kann ich allerdings nicht sagen.

Halo hat jedenfalls massenhaft PP Flags in den Shadern.

MadManniMan

2003-12-12, 15:21:48

Original geschrieben von Demirug
Halo hat jedenfalls massenhaft PP Flags in den Shadern.

Bittebitte Beispiele! Dann kann ich gleich nachguck0rn...

Demirug

2003-12-12, 15:33:08

Original geschrieben von MadManniMan
Bittebitte Beispiele! Dann kann ich gleich nachguck0rn...

???

Was willst du nachschauen wenn ich dir jetzt den Shadercode geben? Ich weiss nur das es diese Shader gibt wo sie nun aber genau verwendet werden kann ich nicht sagen.

MadManniMan

2003-12-12, 15:57:13

Original geschrieben von Demirug
???

Was willst du nachschauen wenn ich dir jetzt den Shadercode geben? Ich weiss nur das es diese Shader gibt wo sie nun aber genau verwendet werden kann ich nicht sagen.

Da hab ich falsch gequotet... :bonk: ich wollte wissen, ob du mir Beispiele geben kannst, wo die Flags diese Problem machen.

BTW wird der :???:-Smiley jetzt so gemacht: :!!!: <- ! = ?

Demirug

2003-12-12, 16:52:13

Original geschrieben von MadManniMan
Da hab ich falsch gequotet... :bonk: ich wollte wissen, ob du mir Beispiele geben kannst, wo die Flags diese Problem machen.

BTW wird der :???:-Smiley jetzt so gemacht: :!!!: <- ! = ?

Beim Shadermark soll es mit pp zu Unregelmässigkeiten kommen. Steht sogar im pdf.

LovesuckZ

2003-12-12, 17:00:39

Original geschrieben von Demirug
Halo hat jedenfalls massenhaft PP Flags in den Shadern.

Steht "PP" für FP16?
Wenn ja, gibt es in Halo auch Shader, die volle Genauigkeit abbekommen?

DrumDub

2003-12-12, 17:10:05

Original geschrieben von LovesuckZ
Steht "PP" für FP16?

ich dachte "partial precision", also fp16+fp32?

Quasar

2003-12-12, 17:12:08

der _pp-hint steht dafür, daß der Treiber/Compiler bei Bedarf für diese so bezeichnete Instruktion auch FP16 benutzen darf.
Wenn er das nicht kann, muss er das aber nicht.

Demirug

2003-12-12, 17:12:55

Original geschrieben von LovesuckZ
Steht "PP" für FP16?
Wenn ja, gibt es in Halo auch Shader, die volle Genauigkeit abbekommen?

PP steht für "Partial Precision" was auf den FXen FP16 bedeutet.

Bei der Masse von Shadern die Halo verwendet kann ich es nicht ausschliessen das es irgendwo auch FP32 Register gibt aber ich habe bisher noch keine gesehen. Die Shader sind aber sowieso aberwitzig programmiert.

Quasar

2003-12-12, 17:21:52

Was genau meinst du mit "aberwitzig"? Angeblich kommen die doch direkt von nV...

Demirug

2003-12-12, 17:32:45

Original geschrieben von Quasar
Was genau meinst du mit "aberwitzig"? Angeblich kommen die doch direkt von nV...

Je öfter ich mir die Dinger anschaue desto weniger kann ich das glauben.

Typische Beispiel:

ps_2_0

def c3 , -1.000000, 0.000000, 0.000000, 0.000000
def c4 , 2.000000, 0.000000, 0.000000, 0.000000

dcl v0
dcl v1
dcl_pp t0.xy
dcl_pp t1.xy
dcl_pp t2.xy
dcl_pp t3.xyz
dcl_2d s0
dcl_2d s1
dcl_2d s2
dcl_cube s3
texld_pp r0 , t1 , s1
texld_pp r7 , t0 , s0
texld_pp r2 , t3 , s3
texld_pp r9 , t2 , s2
mad_pp r11.xyz , c4.xxxx , r0 , r7
add_pp r6.xyz , r11 , c3.xxxx
mul_pp r1.xyz , r6 , v0
mul_pp r8.xyz , r2 , v1
mul_pp r8.w , r9.zzzz , v1.wwww
mad_pp r10.xyz , r8 , r8.wwww , r1
mul_pp r5.xyz , r10 , c0.wwww
lrp_pp r4.xyz , v0.wwww , c0 , r5
mul_pp r11.xyz , v0.wwww , c1
add_sat_pp r10.xyz , -r11 , c2
add_pp r9.xyz , r4 , r10
mov_pp oC0 , r9

Das fängt schon damit an das die Texturkoordinaten als PP deklariert. Das bringt bei den FXen nichts da Koordinaten sowieso immer bei Bedarf mit FP32 berechnet werden. Bei einem Test musste ich sogar feststellen das eine PP Deklarition von Texturkoordinaten das ganze sogar langsamer macht.

Den Vogel schiesst das ganze aber damit ab das sie bei gerade mal 16 Anweisungen 11 Tempregister verbraten. So verschwenderisch ist nicht mal der MS-Compiler im 2.0 Modus.

Sumpfmolch

2003-12-12, 20:51:41

Original geschrieben von Demirug
Je öfter ich mir die Dinger anschaue desto weniger kann ich das glauben.

Typische Beispiel:

ps_2_0

def c3 , -1.000000, 0.000000, 0.000000, 0.000000
def c4 , 2.000000, 0.000000, 0.000000, 0.000000

dcl v0
dcl v1
dcl_pp t0.xy
dcl_pp t1.xy
dcl_pp t2.xy
dcl_pp t3.xyz
dcl_2d s0
dcl_2d s1
dcl_2d s2
dcl_cube s3
texld_pp r0 , t1 , s1
texld_pp r7 , t0 , s0
texld_pp r2 , t3 , s3
texld_pp r9 , t2 , s2
mad_pp r11.xyz , c4.xxxx , r0 , r7
add_pp r6.xyz , r11 , c3.xxxx
mul_pp r1.xyz , r6 , v0
mul_pp r8.xyz , r2 , v1
mul_pp r8.w , r9.zzzz , v1.wwww
mad_pp r10.xyz , r8 , r8.wwww , r1
mul_pp r5.xyz , r10 , c0.wwww
lrp_pp r4.xyz , v0.wwww , c0 , r5
mul_pp r11.xyz , v0.wwww , c1
add_sat_pp r10.xyz , -r11 , c2
add_pp r9.xyz , r4 , r10
mov_pp oC0 , r9

Das fängt schon damit an das die Texturkoordinaten als PP deklariert. Das bringt bei den FXen nichts da Koordinaten sowieso immer bei Bedarf mit FP32 berechnet werden. Bei einem Test musste ich sogar feststellen das eine PP Deklarition von Texturkoordinaten das ganze sogar langsamer macht.

Den Vogel schiesst das ganze aber damit ab das sie bei gerade mal 16 Anweisungen 11 Tempregister verbraten. So verschwenderisch ist nicht mal der MS-Compiler im 2.0 Modus.

heißt das halo bekommt doch noch einen deutlichen performanceboost wenn der angekündigte patch erscheint ?

(nachdem die shaderprogrammierer ihre derzeitige lektüre "pixelshader for dummies" fertig gelsen haben)

Demirug

2003-12-12, 21:08:01

Original geschrieben von Sumpfmolch
heißt das halo bekommt doch noch einen deutlichen performanceboost wenn der angekündigte patch erscheint ?

(nachdem die shaderprogrammierer ihre derzeitige lektüre "pixelshader for dummies" fertig gelsen haben)

Schwer zu sagen weil ich nicht weiss wie viele der Sünden durch die aktuellen Treiber schon korregiert werden.

mapel110

2003-12-12, 21:25:32

Original geschrieben von Sumpfmolch
heißt das halo bekommt doch noch einen deutlichen performanceboost wenn der angekündigte patch erscheint ?

(nachdem die shaderprogrammierer ihre derzeitige lektüre "pixelshader for dummies" fertig gelsen haben)

der patch ist erschienen, mit 0% performancezuwachs.

@demirug
korrigieren <-- :kicher:

zeckensack

2003-12-12, 22:06:48

"Optimierter" Code, hoffentlich legal ...
ps_2_0

def c3 , -1.000000, 2.000000, 0.000000, 0.000000

dcl v0
dcl v1
dcl_pp t0.xy
dcl_pp t1.xy
dcl_pp t2.xy
dcl_pp t3.xyz
dcl_2d s0
dcl_2d s1
dcl_2d s2
dcl_cube s3

texld_pp r0 , t1 , s1
texld_pp r1 , t0 , s0
mad_pp r0.xyz , c3.yyyy , r0 , r1
add_pp r0.xyz , r0 , c3.xxxx
mul_pp r0.xyz , r0 , v0

texld_pp r1 , t3 , s3
texld_pp r2 , t2 , s2
mov_pp r1.w,r2.zzzz
mov_pp r0.w,r2.wwww
mul_pp r1 , r1 , v1
mad_pp r0.xyz , r1 , r1.wwww , r0
mul_pp r0.xyz , r0 , c0.wwww
lrp_pp r1.xyz , v0.wwww , c0 , r0
mad_sat_pp r0.xyz , -v0.wwww , c1 , c2
add_pp r0.xyz , r1 , r0
mov_pp oC0 , r0
Drei Temps. Oi, ist das eine hässliche Syntax ...

StefanV

2003-12-12, 22:25:38

Demirug

2003-12-12, 23:04:02

Original geschrieben von zeckensack
"Optimierter" Code, hoffentlich legal ...
ps_2_0

def c3 , -1.000000, 2.000000, 0.000000, 0.000000

dcl v0
dcl v1
dcl_pp t0.xy
dcl_pp t1.xy
dcl_pp t2.xy
dcl_pp t3.xyz
dcl_2d s0
dcl_2d s1
dcl_2d s2
dcl_cube s3

texld_pp r0 , t1 , s1
texld_pp r1 , t0 , s0
mad_pp r0.xyz , c3.yyyy , r0 , r1
add_pp r0.xyz , r0 , c3.xxxx
mul_pp r0.xyz , r0 , v0

texld_pp r1 , t3 , s3
texld_pp r2 , t2 , s2
mov_pp r1.w,r2.zzzz
mov_pp r0.w,r2.wwww
mul_pp r1 , r1 , v1
mad_pp r0.xyz , r1 , r1.wwww , r0
mul_pp r0.xyz , r0 , c0.wwww
lrp_pp r1.xyz , v0.wwww , c0 , r0
mad_sat_pp r0.xyz , -v0.wwww , c1 , c2 <- Fehler
add_pp r0.xyz , r1 , r0
mov_pp oC0 , r0
Drei Temps. Oi, ist das eine hässliche Syntax ...

Die makierte Zeile funktioniert nicht. Konstanten haben ein Readport Limit von 1.

Der Compiler schlägt folgendes vor.

für R3XX:

ps_2_0
def c3, 2, -1, 0, 0
dcl v0
dcl v1
dcl t0.xy
dcl t1.xy
dcl t2.xy
dcl t3.xyz
dcl_2d s0
dcl_2d s1
dcl_2d s2
dcl_cube s3
texld r2, t1, s1
texld r3, t0, s0
texld r1, t3, s3
texld r0, t2, s2
mad r2.xyz, c3.x, r2, r3
add r2.xyz, r2, c3.y
mul r2.xyz, r2, v0
mul r1.xyz, r1, v1
mul r0.w, r0.z, v1.w
mad r0.xyz, r1, r0.w, r2
mul r1.xyz, r0, c0.w
lrp r0.xyz, r1, c0, v0.w
mov r1.xyz, c1
mad_sat r1.xyz, v0.w, -r1, c2
add r0.xyz, r0, r1
mov r0.w, c3.z
mov oC0, r0

Für NV3X:

ps_2_x
def c3, 2, -1, 0, 0
dcl v0
dcl v1
dcl t0.xy
dcl t1.xy
dcl t2.xy
dcl t3.xyz
dcl_2d s0
dcl_2d s1
dcl_2d s2
dcl_cube s3
texld r1, t0, s0
texld r0, t1, s1
mad r0.xyz, c3.x, r0, r1
add r0.xyz, r0, c3.y
mul r2.xyz, r0, v0
texld r0, t2, s2
texld r1, t3, s3
mul r1.xyz, r1, v1
mul r0.w, r0.z, v1.w
mad r0.xyz, r1, r0.w, r2
mul r1.xyz, r0, c0.w
lrp r0.xyz, r1, c0, v0.w
mov r1.xyz, c1
mad_sat r1.xyz, v0.w, -r1, c2
add r0.xyz, r0, r1
mov r0.w, c3.z
mov oC0, r0

Cpl. Dwayne Hicks

2003-12-13, 13:22:31

zeckensack ersetzte die pp texmov funktion mit einer floatingpoint gleichung das nächste mal bitte....

zeckensack

2003-12-13, 17:27:50

Original geschrieben von Odai Hussein
zeckensack ersetzte die pp texmov funktion mit einer floatingpoint gleichung das nächste mal bitte.... Das habe ich gemacht, weil IMO ein MOV billiger sein kann als ein MUL.
MUL r0.xyz,r0,v1
MUL r0.w,r1.zzzz,v1

=>
MOV r0.w,r1.zzzz
MUL r0,r0,v1
:)

Original geschrieben von Stefan Payne
Kannst du mal den obigen Code mal in eine Anwendung mit Benchfunktion pressen??

Mich würde mal der Performancevorteil deiner Variante interessieren, in der Praxis natürlich :)Da fehlen mir ein paar wichtige Teile.
Wie gross ist die Cubemap, und die anderen drei Texturen?
Was leitet der Vertex Shader an Vorarbeit (v0, v1)?
... ich habe keine DX9-App, in die ich das ganze mal eben reinstopfen könnte :(

AM kann mittlerweile Füllraten mit ARB_fragment_program messen, vielleicht geht's damit :)
!!ARBfp1.0
OPTION ARB_precision_hint_fastest; # "_pp" for everything

TEMP r0;
TEMP r1;
TEMP r2;
ATTRIB v0 = fragment.texcoord[4]; #?
ATTRIB v0 = fragment.texcoord[5]; #?

TEX r0,fragment.texcoord[1],texture[1],2D;
TEX r1,fragment.texcoord[0],texture[0],2D;
MAD r0.rgb,r0,2.0,r1;
ADD r0.rgb,r0,-1;
MUL r0.rgb,r0,v0;

TEX r1,fragment.texcoord[3],texture[3],CUBE;
TEX r2,fragment.texcoord[2],texture[2],2D;

MOV r1.a,r2.b;
MOV r0.a,r2.a;
MUL r1,r1,v1;
MAD r0.rgb,r1,r1.a,r0;
MUL r0.rgb,r0,program.env[0].a;
LRP r1.rgb,v0.a,program.env[0],r0;
MAD_SAT r0.rgb,-v0.a,program.env[1],program.env[2];
ADD r0.rgb,r1,r0;
MOV result.color,r0;
END

Demirug

2003-12-13, 17:42:17

Original geschrieben von zeckensack
Das habe ich gemacht, weil IMO ein MOV billiger sein kann als ein MUL.
MUL r0.xyz,r0,v1
MUL r0.w,r1.zzzz,v1

=>
MOV r0.w,r1.zzzz
MUL r0,r0,v1
:)

Womit du aber möglicherweise ATI keinen Gefallen getan hättest.

Die beiden MULs sehen stark nach paarweiser Ausführung aus.

zeckensack

2003-12-13, 17:56:56

Original geschrieben von Demirug
Womit du aber möglicherweise ATI keinen Gefallen getan hättest.

Die beiden MULs sehen stark nach paarweiser Ausführung aus. Das kann der Compiler wieder flicken. Im Grunde erwarte ich von einem guten Compiler auch, dass er die Anzahl der Temps alleine auf 3 (Segmentweise maximal 2) reduzieren kann.

Das ganze ist eine "DAC-Optimierung" (dümmster anzunehmender Compiler). Mehr kann man als Shader-Schreiber IMO kaum machen.