X800 und SM2.0b in FarCry 1.2! erster Test! [Archiv]

Demirug

2004-07-22, 21:51:56

Also die R420 kann wohl auch eine Form von Object Instancing. Damit es mit DX funktioniert hat ATI aber schwer die DX-Spec gedehnt. Wie schwer muss ich erst noch rausfinden genauso was R420 Object Instancing wirklich ist.

Auf jeden Fall braucht man einen spezial Treiber damit es funktioniert und den hatten ixbt noch nicht.

OT:

In der Zwischenzeit habe ich mich mit wichtigeren Dingen beschäftigt. Der SM30 Pfad läuft jetzt auf den FXen und SM2B sollte ich R3XX tauglich haben. SM2B läuft im Prinzip auch auf den FXen aber SM30 ist da derzeit noch schneller. Könnte aber daran liegen das SM2B keine PP in den Shadern hat. Muss ich also noch ausprobieren wie schnell die FXen mit 2B und PP sind.

Wer einen NV3X oder einen R3XX sein eigenen nennt und Beta-Tester spielen möchte bitte PM an mich.

LovesuckZ

2004-07-22, 21:55:29

Original geschrieben von Demirug
Also die R420 kann wohl auch eine Form von Object Instancing. Damit es mit DX funktioniert hat ATI aber schwer die DX-Spec gedehnt. Wie schwer muss ich erst noch rausfinden genauso was R420 Object Instancing wirklich ist.
Auf jeden Fall braucht man einen spezial Treiber damit es funktioniert und den hatten ixbt noch nicht.

Was bringt "Object Instancing" in farcry wirklich? Konntest du da etwas herausfinden?
Liegt es an nvidias version oder wird es auch bei ATi auftreten, dass der Performancegewinn = 0 ist?
Und ganz wichtig: Sind beide Versionen a) kompartibel zueinander, b)muessten die r3xx Karten dies nicht auch unterstuetzen und c) hat der NV3x auch die besseren VS, kann er also auch eine Art von "Object Instancing"?

mapel110,
so wie ich das mitbekommen habe bei Demirug's Erlaeuterungen, benutzt Crytek fuer jedes Lichtchen ein Shaderlein.

Demirug

2004-07-22, 21:55:50

Original geschrieben von mapel110
tja, aber die FXse waren ja zu lahm für ihren ps2.a. ;(

Falsch. Hätte Crytek im Patch 1.1 diese Lichtpassoptimierung eingebaut hätte sie die FXen ohne Qaulitätsverlust schneller machen können.

Das aufwendigere SM3 Licht läuft auf einer FX schneller als das SM2 Licht.

Demirug

2004-07-22, 21:58:54

Original geschrieben von LovesuckZ
Was bringt "Object Instancing" in farcry wirklich? Konntest du da etwas herausfinden?
Liegt es an nvidias version oder wird es auch bei ATi auftreten, dass der Performancegewinn = 0 ist?

Object Instancing bringt immer nur dann was wenn man CPU-limitiert ist. Ist also was für Leute micht schwachen CPUs. Allerdings verbrät Farcry gerade im Outdoor bereich so kräftig CPU Leistung fürs rendern das die Einsprung eher ein Tropfen auf den heisen Stein ist.

Benedikt

2004-07-22, 22:04:53

Original geschrieben von Demirug
Falsch. Hätte Crytek im Patch 1.1 diese Lichtpassoptimierung eingebaut hätte sie die FXen ohne Qaulitätsverlust schneller machen können.

Das aufwendigere SM3 Licht läuft auf einer FX schneller als das SM2 Licht.

Gibt's dafür auch einen "r_irgendwas"-Parameter, dass man den SM3-Pfad auf einer FX laufen lassen kann?

MFG,
B. W.

Tjell

2004-07-22, 23:01:19

Auch wenn es ein weeeenig abseits des Themas ist:

Zumindest performancemäßig (und von der Verfügbarkeit + Preis :) ) bewegen sich ATI und nVidia in ähnlichen Gefilden, also kann man getrost zu der einen oder anderen Karte greifen.

Die eine ist ein wenig stromsparender, die andere bietet mehr Features - während der Unterschied im Stromverbrauch eher einen Tropfen auf den heißen Stein darstellt, sind die Features währenddessen (nach meinem langsam aufkommenden Vorab-Fazit) einfach nur ein "Goodie", das zu Lebzeiten des NV40 keinen Unterschied wird machen können, dafür sind die Softwareschmieden einfach zu langsam.

Eigentlich beste Voraussetzungen, um dem Fanboyismus Lebewohl zu sagen und unvoreingenommen sachlich den Kauf einer neuen Grafikkarte zu überdenken. Es sei denn, man mag einen der Hersteller nicht (Ey, sehe ich da einen Spiegel?).

Und die Geschichte mit FarCry? Ganz einfach, bei so einem Simpel-Shooter, der sich auch als Engine verkaufen soll, muß man einfach für ständigen Gesprächsstoff sorgen. :D

VooDoo7mx

2004-07-22, 23:13:18

Ist fast schon erbärmlich wie grottig Far Cry programmiert wird oder programmiert wurden ist.

Jetzt, nachdem der 1.2 Patch da ist, gibts zig Beta RFenderpfade dir vielleicht mal irgendwann in 1.3 oder 1.4 welche in 6 bzw 12 Monaten erscheinen eingebracht.

Also ich hab selten so einen grottigen Support bei einen solch erfolgreichen Spiel miterlebt!

Schande über Crytek!

Asaraki

2004-07-23, 00:20:30

tokugawa

2004-07-23, 01:04:25

Original geschrieben von VooDoo7mx
Ist fast schon erbärmlich wie grottig Far Cry programmiert wird oder programmiert wurden ist.

Jetzt, nachdem der 1.2 Patch da ist, gibts zig Beta RFenderpfade dir vielleicht mal irgendwann in 1.3 oder 1.4 welche in 6 bzw 12 Monaten erscheinen eingebracht.

Also ich hab selten so einen grottigen Support bei einen solch erfolgreichen Spiel miterlebt!

Schande über Crytek!

Erstens: Nachträgliche Code-Wartung ist eher GUTER Support, und nicht schlechter Support. Die hätten das Spiel einfach rausbringen können und so lassen können und nix mehr daran feilen brauchen. Stattdessen basteln sie noch daran rum. Das ist etwas, was postiv bewertet werden sollte.

Zweitens: Woher willst du wissen, wie "grottig" es programmiert worden ist? Daran, dass noch immer daran rumgefeilt wird (und daran, dass es bisher von den neuen Patches nur Beta-Versionen gibt, und wie man weiß, sollte man Beta-Versionen noch nicht beurteilen wie Finals), kann man jedenfalls nicht beurteilen, ob Far Cry jetzt "grottig" programmiert worden ist.

Drittens: Willst du uns vielleicht zeigen wie's besser geht? Nur zu, programmier uns eine ähnliche Engine. Und dann schau mal, wie weit du kommst ohne Code-Wartung (ein nicht wegzudenkender Teil des Software-Engineering, wirst in jeder Software-Engineering-Lehrveranstaltung auf den Unis hören, sowie in jeder Software-Firma).

tombman

2004-07-23, 03:39:03

jo, sogar total ohne patches sind sie derzeit allem überlegen was am Markt ist. Sie hätten sich ja jetzt gar ned so reinsteigern müssen.. aber sie wollen es eben auch als engine verkaufen.
NV40 und R420 sind hochkomplexe Viecher (zu komplex um hohe Stückzahlen auf den Markt zu werfen? :rofl: ) die man erst zu programmieren verstehen muß.
Des wird in Zukunft sicher noch schwerer sein, weils dann sicher noch komplexer wird. Oder die compiler/tools werden besser *eg*.

tombman

2004-07-23, 04:21:44

UPDATE!

Erste 2 Runs = 2.b
==============================================================
TimeDemo Play Started , (Total Frames: 1512, Recorded Time: 46.65s)
!TimeDemo Run 0 Finished.
Play Time: 25.82s, Average FPS: 58.57
Min FPS: 45.70 at frame 92, Max FPS: 70.73 at frame 720
Average Tri/Sec: 1547661, Tri/Frame: 26423
Recorded/Played Tris ratio: 1.61
!TimeDemo Run 1 Finished.
Play Time: 25.47s, Average FPS: 59.37
Min FPS: 43.97 at frame 1395, Max FPS: 71.12 at frame 254
Average Tri/Sec: 1557066, Tri/Frame: 26225
Recorded/Played Tris ratio: 1.62
==============================================================

Zeiten 2 Runs = sm 2.0 default

TimeDemo Play Started , (Total Frames: 1512, Recorded Time: 46.65s)
!TimeDemo Run 0 Finished.
Play Time: 30.52s, Average FPS: 49.54
Min FPS: 37.99 at frame 1397, Max FPS: 61.86 at frame 711
Average Tri/Sec: 2286870, Tri/Frame: 46165
Recorded/Played Tris ratio: 0.92
!TimeDemo Run 1 Finished.
Play Time: 30.21s, Average FPS: 50.05
Min FPS: 37.70 at frame 1393, Max FPS: 62.42 at frame 701
Average Tri/Sec: 2309755, Tri/Frame: 46152
Recorded/Played Tris ratio: 0.92
_____________

harhar - 20% mehr speed auf ATi X800XTPE (535/565) durch SM2.b

M@g

2004-07-23, 06:16:25

Hmm wie soll man denn jetzt wieder vergleichen ^^
NV40 auch mal mit 2.b laufen lassen, wer weis was sie mit dem neuen Pfad noch so eingebaut haben, vieleicht hilfts den FXen sogar auf die Sprünge :) (wär schon lachhaft wenn R9xxx Karten auch besser laufen würden)

BlackBirdSR

2004-07-23, 06:53:27

Erste 2 Runs = 2.b
==============================================================
TimeDemo Play Started , (Total Frames: 1512, Recorded Time:
Min FPS: 45.70 at frame 92, Max FPS: 70.73 at frame 720
Average Tri/Sec: 1547661, Tri/Frame: 26423

!TimeDemo Run 1 Finished.

Min FPS: 43.97 at frame 1395, Max FPS: 71.12 at frame 254
Average Tri/Sec: 1557066, Tri/Frame: 26225
==============================================================

Zeiten 2 Runs = sm 2.0 default

!TimeDemo Run 0 Finished.
Min FPS: 37.99 at frame 1397, Max FPS: 61.86 at frame 711
Average Tri/Sec: 2286870, Tri/Frame: 46165

!TimeDemo Run 1 Finished.

Min FPS: 37.70 at frame 1393, Max FPS: 62.42 at frame 701
Average Tri/Sec: 2309755, Tri/Frame: 46152
[/SIZE][/QUOTE]

Das finde ich viel interessanter als die avg. FPS

Demirug

2004-07-23, 07:02:44

Original geschrieben von Benedikt
Gibt's dafür auch einen "r_irgendwas"-Parameter, dass man den SM3-Pfad auf einer FX laufen lassen kann?

MFG,
B. W.

Nein, dafür braucht man ein kleines Zusatzprogramm.

Demirug

2004-07-23, 07:05:51

Demirug

2004-07-23, 07:09:32

Original geschrieben von tombman
jo, sogar total ohne patches sind sie derzeit allem überlegen was am Markt ist. Sie hätten sich ja jetzt gar ned so reinsteigern müssen.. aber sie wollen es eben auch als engine verkaufen.
NV40 und R420 sind hochkomplexe Viecher (zu komplex um hohe Stückzahlen auf den Markt zu werfen? :rofl: ) die man erst zu programmieren verstehen muß.
Des wird in Zukunft sicher noch schwerer sein, weils dann sicher noch komplexer wird. Oder die compiler/tools werden besser *eg*.

Komplex in der Produktion. Für die Entwickler ist es dank HLSL wesentlich einfacher geworden. Wenn ich da an DX7 Hardware zurückdenke war das schon wesentlich umständlicher weil man zwar eine API hatte aber jeder Chip/Treiber bei jedem einzelnen Effekt ja oder nein sagen durfte.

Das einzige wo man noch Erfahrungen sammeln muss ist das Performance verhalten von neuen Funktionen.

Demirug

2004-07-23, 07:14:49

Original geschrieben von M@g
Hmm wie soll man denn jetzt wieder vergleichen ^^
NV40 auch mal mit 2.b laufen lassen, wer weis was sie mit dem neuen Pfad noch so eingebaut haben, vieleicht hilfts den FXen sogar auf die Sprünge :) (wär schon lachhaft wenn R9xxx Karten auch besser laufen würden)

2B fehlen die PP Flags daher laufen die FXen besser mit konvertieren SM3 Shadern. 2B mit PP Flags könnte vielliecht noch interesant sein. Da die Berechnungen aber sehr identisch sind erwarte ich da eigentlich keine grossesn Unterschied zwischen 3.0 und 2.B

Auch die R9XXX Karten wären mit an sicherheit grenzender Wahrscheinlichkeit schneller nur können die den 2B Pfad in der grundform nicht ausführen. Da sind zu lange shader drin. Die kann man aber in Multipass Shader zerlegen. Funktioniert im Prinzip auch schon nur bei dem einen oder anderen Shader gibt es noch ein kleines Problem dabei.

Demirug

2004-07-23, 07:16:32

Original geschrieben von BlackBirdSR
Erste 2 Runs = 2.b
==============================================================
TimeDemo Play Started , (Total Frames: 1512, Recorded Time:
Min FPS: 45.70 at frame 92, Max FPS: 70.73 at frame 720
Average Tri/Sec: 1547661, Tri/Frame: 26423

!TimeDemo Run 1 Finished.

Min FPS: 43.97 at frame 1395, Max FPS: 71.12 at frame 254
Average Tri/Sec: 1557066, Tri/Frame: 26225
==============================================================

Zeiten 2 Runs = sm 2.0 default

!TimeDemo Run 0 Finished.
Min FPS: 37.99 at frame 1397, Max FPS: 61.86 at frame 711
Average Tri/Sec: 2286870, Tri/Frame: 46165

!TimeDemo Run 1 Finished.

Min FPS: 37.70 at frame 1393, Max FPS: 62.42 at frame 701
Average Tri/Sec: 2309755, Tri/Frame: 46152

Das finde ich viel interessanter als die avg. FPS

Warum? Ist doch logisch. Wenn man für ein Object nur noch einen Pass und nicht mehr zwei braucht halbiert sich auch die Anzahl der Tris die man für diese Object zu rendern hat. Farcry zählt nun mal eben alle Polys die gerendert werden.

boxleitnerb

2004-07-23, 10:34:32

Gibt es durch Benutzung von SM 2.0b dann auch HDR für ATI Karten? In diesem Thread auf rage3d
http://www.rage3d.com/board/showthread.php?t=33770996 auf Seite 2 wird ein Bild gepostet, das IMO HDR auf einer X800XT PE darstellt. Was meint ihr dazu?

seahawk

2004-07-23, 11:13:22

Also muss man feststellen, dass beide neue Renderpfade weniger der hauptgrund für den Speedgewinn sind und nicht irgendwelche Hardwareunterschiede. CryTek nutzt also nur vorhandene Hardware besseraus.

SM3.0 optimiert auf GeForce-Karten und 2.0b auf die neuen ATI.

SM3.0 scheint ein minimaler Faktor zu sein.

Jesus

2004-07-23, 11:14:04

Original geschrieben von boxleitnerb
Gibt es durch Benutzung von SM 2.0b dann auch HDR für ATI Karten? In diesem Thread auf rage3d
http://www.rage3d.com/board/showthread.php?t=33770996 auf Seite 2 wird ein Bild gepostet, das IMO HDR auf einer X800XT PE darstellt. Was meint ihr dazu?

hm möglich, da DynLights = Dynamic, Dynamic... hab ich zumindest bei mir noch nie gesehen ;)

TheCounter

2004-07-23, 11:25:52

Original geschrieben von boxleitnerb
Gibt es durch Benutzung von SM 2.0b dann auch HDR für ATI Karten? In diesem Thread auf rage3d
http://www.rage3d.com/board/showthread.php?t=33770996 auf Seite 2 wird ein Bild gepostet, das IMO HDR auf einer X800XT PE darstellt. Was meint ihr dazu?

Das ist kein HDR. Aber HDR (Wohl eher MDR?) wird wohl auch auf ATI Karten laufen, es gibt sogar extra schon definationen dafür im Patch 1.2, genauso wie für 3dc.

Das auf dem Bild ist ein ganz normales dynamic (?) light mit nem großen flare...

Jesus

2004-07-23, 11:27:24

Original geschrieben von TheCounter
ganz normales dynamic (?) light ...

eben ;)

deekey777

2004-07-23, 11:31:41

Bei mir sehen alle "Löcher" in den Decken (Katakomben) aus: DynLights=Dynamic Dynamic (2/2/2).

Grafikkarte ist 9800 Pro (was sonst!).
Screenshot?

http://www.3dfusion.net/galerie/data/media/2/licht.JPG
(Nicht alle haben DSL.)

Demirug

2004-07-23, 11:36:01

Original geschrieben von TheCounter
Das ist kein HDR. Aber HDR (Wohl eher MDR?) wird wohl auch auf ATI Karten laufen, es gibt sogar extra schon definationen dafür im Patch 1.2, genauso wie für 3dc.

Da wäre ich mir nicht so sicher. Farcry braucht für einige Effekte zwingend Alpha-Blending im Framebuffer. Die einzigen die derzeit Alpha-Blending mit FP-Buffer beherschen sind die NV4X Chips sowie wahrscheinlich die neuen von 3dlabs.

Marodeur

2004-07-23, 11:44:38

Original geschrieben von Demirug
Auch die R9XXX Karten wären mit an sicherheit grenzender Wahrscheinlichkeit schneller nur können die den 2B Pfad in der grundform nicht ausführen. Da sind zu lange shader drin. Die kann man aber in Multipass Shader zerlegen. Funktioniert im Prinzip auch schon nur bei dem einen oder anderen Shader gibt es noch ein kleines Problem dabei.

Hmm... ist das in Arbeit das da was für die 9XXX gemacht wird oder ist das jetzt reine Theorie? Freuen würds mich ja schon wenn da noch was ginge... Im Prinzip machens bei mir oft nur 3-5 fps aus die von etwas zäh und ruckelig zu halbwegs flüssig fehlen mit der 9700... :/

Demirug

2004-07-23, 11:52:47

Original geschrieben von Marodeur
Hmm... ist das in Arbeit das da was für die 9XXX gemacht wird oder ist das jetzt reine Theorie? Freuen würds mich ja schon wenn da noch was ginge... Im Prinzip machens bei mir oft nur 3-5 fps aus die von etwas zäh und ruckelig zu halbwegs flüssig fehlen mit der 9700... :/

Schau mal dort (http://www.forum-3dcenter.org/vbulletin/showthread.php?s=&postid=2047513#post2047513). ;)

Jesus

2004-07-23, 11:52:53

Original geschrieben von deekey777
Bei mir sehen alle "Löcher" in den Decken (Katakomben) aus: DynLights=Dynamic Dynamic (2/2/2).

Grafikkarte ist 9800 Pro (was sonst!).
Screenshot?

http://www.3dfusion.net/galerie/data/media/2/licht.JPG
(Nicht alle haben DSL.)

oh, da hab ich mich wohl geirrt :D

deekey777

2004-07-23, 12:03:04

Original geschrieben von Jesus
oh, da hab ich mich wohl geirrt :D

Ist egal, es sei, dass auch Katakomben in FC 1.0/FC 1.1 genauso aussehen wie in FC 1.2.

Hätte jemand Lust, das zu prüfen? :D

Marodeur

2004-07-23, 13:50:01

Original geschrieben von Demirug
Schau mal dort (http://www.forum-3dcenter.org/vbulletin/showthread.php?s=&postid=2047513#post2047513). ;)

ARKS... ich hatte das sogar gelesen, aufgenommen ... aber dann ein paar Postings später wieder vergessen...
:(

Ich glaub ich werd alt... :cryl:

Melbourne, FL

2004-07-23, 14:56:00

Jetzt muss ich mal dumm fragen...im Rage3D Forum wird behauptet man braucht DX9c...stimmt das (kann ich mir eigentlich gar nicht richtig vorstellen)? Und wenn ja wo kriege ich das?

Danke!

Alexander

Demirug

2004-07-23, 15:03:25

Original geschrieben von Melbourne, FL
Jetzt muss ich mal dumm fragen...im Rage3D Forum wird behauptet man braucht DX9c...stimmt das (kann ich mir eigentlich gar nicht richtig vorstellen)? Und wenn ja wo kriege ich das?

Danke!

Alexander

Die Lichtoptimierung funktioniert AFAIK auch mit 9.0b. Für das Object Instancing braucht man aber 9.0c weil sich dort noch was geändert hat. Die die öffentlich zugänglichen Treiber aber das OI sowieso nicht unterstützen nützt auch 9.0c nichts.

LovesuckZ

2004-07-23, 15:05:32

Original geschrieben von Demirug
Für das Object Instancing braucht man aber 9.0c weil sich dort noch was geändert hat.

Unterstuetzen dann auch r3xx karten OI?

Demirug

2004-07-23, 15:10:03

Original geschrieben von LovesuckZ
Unterstuetzen dann auch r3xx karten OI?

Laut den neusten Informationen ja. Allerdings kann ich noch nicht sagen in welchem Umfang. Zudem stellt es auf jeden Fall eine Verletzung der DX-Spec dar.

LovesuckZ

2004-07-23, 15:12:50

Original geschrieben von Demirug
Laut den neusten Informationen ja. Allerdings kann ich noch nicht sagen in welchem Umfang.

Hat sich irgendwas an der Funktionalitaet der VS vom r3xx zum r420 geaendert?

Zudem stellt es auf jeden Fall eine Verletzung der DX-Spec dar.

democoder hat sich im beyond3d.com Forum ziemlich aufgeregt, weil ATi dies mit FOURCC (Format) realisieren solle.
Nun, was ist solch ein "FOURCC"?
Vorallen wird es interessant, wie Nvidia darauf reagiert, immerhin haben sie sich auch nicht getraut eine DX9 Verletzung vorzunehmen, indem sie einfach beim SM2.0 Integergenauigkeit verwendetetn. Aber das kann sich ja noch aendern.

Gast

2004-07-23, 15:19:05

Original geschrieben von LovesuckZ
Hat sich irgendwas an der Funktionalitaet der VS vom r3xx zum r420 geaendert?

natürlich ;)

Gast

2004-07-23, 15:22:07

Original geschrieben von Gast
natürlich ;)

Desweiteren wurde die Anzahl der Vertex Shader von 4 auf 6 erhöht, was dem R420 zusammen mit der Takterhöhung und den internen Verbesserungen eine Steigerung der Vertex Leistung um bis zu 100 Prozent bescheren könnte. Im übrigen reicht nach unseren Rechnungen diese Erhöhung der Anzahl der Vertex Shader (im übrigen ist die Anzahl nicht direkt mit den nVidia-Chips vergleichbar, welche ein Vertex Shader Array benutzen) nicht aus, um die 50 Millionen mehr Transistoren zu erklären - hier dürfte im R420 also noch Platz für die eine oder andere Überraschung sein, seien es die schon erwähnten mehr Textureneinheiten oder aber verbessertes Anti-Aliasing oder/und anisotrope Filterung.

2004-07-23, 15:24:04

Original geschrieben von Demirug
Laut den neusten Informationen ja. Allerdings kann ich noch nicht sagen in welchem Umfang. Zudem stellt es auf jeden Fall eine Verletzung der DX-Spec dar.

Was sagt denn da MS dazu??

Demirug

2004-07-23, 15:43:19

Original geschrieben von LovesuckZ
Hat sich irgendwas an der Funktionalitaet der VS vom r3xx zum r420 geaendert?

Object Instancing ist eher eine Sache des Vertex-DMA der noch vor den Vertexshader sitzt.

democoder hat sich im beyond3d.com Forum ziemlich aufgeregt, weil ATi dies mit FOURCC (Format) realisieren solle.
Nun, was ist solch ein "FOURCC"?
Vorallen wird es interessant, wie Nvidia darauf reagiert, immerhin haben sie sich auch nicht getraut eine DX9 Verletzung vorzunehmen, indem sie einfach beim SM2.0 Integergenauigkeit verwendetetn. Aber das kann sich ja noch aendern.

FOURCC steht für "Four Character Code". Man kann bei DX damit zusätzliche Texturformate nutzen indem man den FOURCC dieses Formats angibt. Natürlich gibt es auch eine Funktion um festzustellen ob ein bestimmtes FOURCC Format unterstützt wird. Die Kompressionformate sind zum Beispiel auch als FOURCC festgelegt.

Wenn ich das ganze nun soweit richtig verstanden habe behauptet dieser Treiber nun ein bestimmtes FOURCC Texturformat zu unterstützen. Diese Meldung kann dann so interpretiert werden das die karte Object Instancing unterstützt. In wie weit das mit dem normalen SM3 Object Instancing identisch ist weiss ich aber noch nicht.

Exxtreme

2004-07-23, 15:44:44

Original geschrieben von ow
Was sagt denn da MS dazu??
Hmmm, bei sowas müsste sich aber die Runtime querstellen... oder nicht? Und da sieht man wieder wie einengend DirectX doch ist. Der Chip kann es, darf aber nicht. :bonk:

Demirug

2004-07-23, 15:45:10

Original geschrieben von ow
Was sagt denn da MS dazu??

Gar nichts denn es verletzt ja keine der WHQL Regeln. Mehr können als melden darf ein Treiber immer nur anders herum gibt es Ärger.

Jesus

2004-07-23, 16:29:50

also verstehe ich das richtig, ATI benutzt eine Art workaround um über ein bestimmtes in DX9 enthaltenes TExturformat eine Art Object instancing zu machen , um es ohne SM3 machen zu können , da sie dass ja bekanntlich nicht unterstützen ? Supi :)

aths

2004-07-23, 16:35:34

Original geschrieben von seahawk
SM3.0 scheint ein minimaler Faktor zu sein. Man wird es nicht offiziell von NV hören, aber wenn man sich die HW ansieht, gelangt man zu dem Schluss, dass das dynamische Branchen beim SM 3.0 vor allem dazu da ist, damit Entwickler die Möglichkeiten haben, bedingte Sprünge in Shader-Programmen überhaupt zu nutzen. Manchmal gewinnt NV40 dadurch sogar ein wenig Performance. Inzwischen bin ich nicht mehr überzeugt, dass dynamisches Branchen von NV für den NV40 von Anfang an vorgesehen war: CineFX wirkt im NV40 integriert, dynamisches Branching wirkt angeflanscht.

Für die Performane sind andere 3.0-Features da: Mehr Interpolatoren, Object Instancing. Der NV40 bietet abseits von SM 3.0 eine Verschnellerung bestimmter Textur-Operationen (gegenüber GF FX), Verschnellerung vieler anderer arithmetischer Instruktionen, und inbezug auf FP16-Rendering die bekannten Vorteile.

Jesus

2004-07-23, 16:42:36

Original geschrieben von aths
Man wird es nicht offiziell von NV hören, aber wenn man sich die HW ansieht, gelangt man zu dem Schluss, dass das dynamische Branchen beim SM 3.0 vor allem dazu da ist, damit Entwickler die Möglichkeiten haben, bedingte Sprünge in Shader-Programmen überhaupt zu nutzen. Manchmal gewinnt NV40 dadurch sogar ein wenig Performance.

lt. Crytek verliert man aber auch manchmal Performance, deswegen haben sie es auch nicht benutzt.

Gast

2004-07-23, 17:09:34

Original geschrieben von Jesus
also verstehe ich das richtig, ATI benutzt eine Art workaround um über ein bestimmtes in DX9 enthaltenes TExturformat eine Art Object instancing zu machen , um es ohne SM3 machen zu können , da sie dass ja bekanntlich nicht unterstützen ? Supi :)

Eher wohl nicht. Sie benutzen anscheinend FOURCC um dem Spiel zu sagen, "hey hier ist eine Karte die Object Instancing kann" obwohl der Chip, hier der R420 kein VS3.0 kann.

Stimmt das so Demirug?

aths

2004-07-23, 17:10:58

Original geschrieben von Jesus
lt. Crytek verliert man aber auch manchmal Performance, deswegen haben sie es auch nicht benutzt. Man kann dieses Feature auch an ungünstiger Stelle einsetzen und Performance verlieren, ja.

Aber: Ohne dynamisches Branchen und "Abfrage" per CMP müssen ja ohnehin beide Zweige berechnet werden. Mit dynamischem if-else-endif kann der NV40 aufgrund seiner Arbeitsweise ebenfalls gezwungen sein, beide Branches abzuarbeiten, auch wenn nur einer wirklich genutzt wird. Zusätzlich kostet die if-else-endif-Struktur ca. 6 - 8 Takte. Da muss man dann gucken, ob sich das noch lohnt. So lange die CPU effizient (also schnell) Shadercombining machen kann, kann man ohne Branchen leben. Ansonsten wäre statisches Branchen abzuwägen, ist ebenfalls CPU-lastig (aber nicht ganz so sehr.)

LovesuckZ

2004-07-23, 17:14:23

Original geschrieben von Gast
Eher wohl nicht. Sie benutzen anscheinend FOURCC um dem Spiel zu sagen, "hey hier ist eine Karte die Object Instancing kann" obwohl der Chip, hier der R420 kein VS3.0 kann.

OI ist nicht an einen VS3.0 gebunden.
Unter DX9 kann es aber nur verwendet werden, wenn die Karte/Treiber SM3.0 bereitstellt.
ATi will dies umgehen und verstoeßt damit wohl gegen DX.

Xmas

2004-07-23, 17:17:04

Original geschrieben von aths
Man kann dieses Feature auch an ungünstiger Stelle einsetzen und Performance verlieren, ja.

Aber: Ohne dynamisches Branchen und "Abfrage" per CMP müssen ja ohnehin beide Zweige berechnet werden. Mit dynamischem if-else-endif kann der NV40 aufgrund seiner Arbeitsweise ebenfalls gezwungen sein, beide Branches abzuarbeiten, auch wenn nur einer wirklich genutzt wird. Zusätzlich kostet die if-else-endif-Struktur ca. 6 - 8 Takte. Da muss man dann gucken, ob sich das noch lohnt. So lange die CPU effizient (also schnell) Shadercombining machen kann, kann man ohne Branchen leben. Ansonsten wäre statisches Branchen abzuwägen, ist ebenfalls CPU-lastig (aber nicht ganz so sehr.)
Neben dynamischem Branching hat NVidia ja (seit NV30) noch einen weiteren Vorteil, der genau da ansetzt wo DB nicht lohnt: Predication. Bei ATI muss man für den gleichen Zweck dann z.B. LERPs einbauen, was langsamer ist.

aths

2004-07-23, 17:20:18

Original geschrieben von LovesuckZ
OI ist nicht an einen VS3.0 gebunden.
Unter DX9 kann es aber nur verwendet werden, wenn die Karte/Treiber SM3.0 bereitstellt.
ATi will dies umgehen und verstoeßt damit wohl gegen DX. Nah.

Ich weiß nur, dass SM3.0 auch Object Instanzing erfordert. Centroid Mapping z. B. ist auch Zwang für PS 3.0., aber das Feature hat schon Radeon 9700. DX9.0c erlaubt das jetzt auch für SM 2.0.

LovesuckZ

2004-07-23, 17:25:26

Original geschrieben von aths
Nah.
Ich weiß nur, dass SM3.0 auch Object Instanzing erfordert.

Object Instancing" ist ja nicht direkt ein Shader 3 Feature. Es ist nur definiert das jede Karte mit VS3 auch "Object Instancing" beherschen muss. Da es aber kein Capsbit dafür gibt ist es fest mit den Shader Model 3 verbunden.

demirug (15.07.'04) (http://www.forum-3dcenter.org/vbulletin/showthread.php?s=&postid=2022306#post2022306)

Nun bleibt die Frage, ob DX9.c eben solch ein "Capsbit" fuer OI bereitstellen wird.

deekey777

2004-07-23, 17:29:05

One Returned SM 2.0_b for Radeon X800 in Far Cry 1.2 (M.A.J) (http://translate.google.com/translate?u=http%3A%2F%2Fwww.3dchips-fr.com%2FNews%2Factualites%2F200407223.html&langpair=fr%7Cen&hl=en&ie=UTF-8&ie=UTF-8&oe=UTF-8&prev=%2Flanguage_tools)

"The developers also called upon "Geometry Instancing" supported by SM 2.0_b for returned vegetation. Geometry Instancing proposed by NVIDIA is not reserved for Shader Model 3.0."

Laut DH.net (http://www.driverheaven.net/showthread.php?threadid=51384&) soll nicht alles korrekt sein, was die Franzosen geschrieben haben. Auch DH wird einen Artikel zu diesem Thema veröffentlichen.

Demirug

2004-07-23, 18:15:30

Original geschrieben von deekey777
One Returned SM 2.0_b for Radeon X800 in Far Cry 1.2 (M.A.J) (http://translate.google.com/translate?u=http%3A%2F%2Fwww.3dchips-fr.com%2FNews%2Factualites%2F200407223.html&langpair=fr%7Cen&hl=en&ie=UTF-8&ie=UTF-8&oe=UTF-8&prev=%2Flanguage_tools)

"The developers also called upon "Geometry Instancing" supported by SM 2.0_b for returned vegetation. Geometry Instancing proposed by NVIDIA is not reserved for Shader Model 3.0."

Laut DH.net (http://www.driverheaven.net/showthread.php?threadid=51384&) soll nicht alles korrekt sein, was die Franzosen geschrieben haben. Auch DH wird einen Artikel zu diesem Thema veröffentlichen.

Das stimmt schon das "Geometry Instancing" nicht nur mit VS 3.0 benutzt werden kann. Wenn es eine Karte unterstützt kann man es mit Shadern jeder Version benutzten. Es ist aber (auch bei DX 9.0c) so definiert das die Meldung das VS 3.0 unterstützt werden auch bedeut das die Karte GI beherscht. Laut Spec ist das auch die einzige Methode zum feststellen ob GI unterstützt wird.

Entweder hat ATI geschlafen und sich kein Capsbit dafür machen lassen oder MS wollte nicht.

Jesus

2004-07-23, 18:24:24

Original geschrieben von Demirug
Entweder hat ATI geschlafen und sich kein Capsbit dafür machen lassen oder MS wollte nicht.

was aber im Endeffekt auch egal ist, falls es funktioniert ;)

Demirug

2004-07-23, 18:28:18

Original geschrieben von Jesus
was aber im Endeffekt auch egal ist, falls es funktioniert ;)

Es ist nicht egal. Bei sowas besteht immer die Gefahr das Features nicht genutzt werden weil sie eben nicht auf eine genormte Art erkannt werden können.

Jesus

2004-07-23, 18:29:37

naja aber wenn es Crytek weiss bevor du oder sonstwer es gewusst haben, dann seh ich diese Gefahr nicht so gross ;)

seahawk

2004-07-23, 18:29:40

Original geschrieben von Demirug
Es ist nicht egal. Bei sowas besteht immer die Gefahr das Features nicht genutzt werden weil sie eben nicht auf eine genormte Art erkannt werden können.

Oder, dass so etwas zunimmt und die Normung praktisch sinnlos wird.

Blutgrätsche

2004-07-23, 18:32:07

Auf B3D steht irgendwo, dass ATI vermutlich ein FOURCC Schlupfloch (Hack) verwenden wird.

Demirug

2004-07-23, 18:38:37

Original geschrieben von Jesus
naja aber wenn es Crytek weiss bevor du oder sonstwer es gewusst haben, dann seh ich diese Gefahr nicht so gross ;)

Doch genau sowas erhöht die Gefahr. ATI hat die Erkennung bis jetzt immer noch nicht öffentlich gemacht. Wenn man den Entwicklern nicht sagt was die Karten können braucht man sich nicht zu wundern wenn es dann keiner benutzt. Scheinbar musste Crytek ja auch noch schnell darauf aufmerksam gemacht werden das die R420 Chips auch Object Instancing können.

tombman

2004-07-23, 18:51:48

Original geschrieben von Jesus
naja aber wenn es Crytek weiss bevor du oder sonstwer es gewusst haben, dann seh ich diese Gefahr nicht so gross ;)

eben, die "skilligen" developer von crytek, id und epic werden schon rauskriegen was ein chip kann und was ned. außerdem werden ati und nvidia denen sicher auch brühwarm erzählen was geht und was nimma geht.

klar wärs schöner wenn alles schön offiziell wäre, aber ein bischen hack geht immer noch :D

*sing* "ein hack geht noch, einer geht noch rein..." :D

Jesus

2004-07-23, 18:52:24

ich denke ATI wirds wirklich verpennt haben, deswegen konnten sie das feature auch nicht bewerben, da es sonst als "betrug" gewertet werden könnte weils keiner richtig (offiziell ) benutzen kann.

Ich als Entwickler würde mich jedenfalls freuen wenn in meiner HW noch versteckte Resourcen enthalten wären ;) ( das erinnert mich irgendwie an seelige C64 zeiten ;) )

ob ich jetzt irgendne offizelle funktion mit extra cap benutze oder eine andere die dasselbe Ergebnis erzeugt bleibt im endeffekt dann gleich, falls mans weiss.

seahawk

2004-07-23, 19:10:19

Mal OT :

Aber mir fällt auf, dass hier Leute eine solche Verletzung der Norm begrüssen, die vorher oftmals wegen der PP_Lösung der GeForce gejammert haben und ihr nicht volle DX9 Kompatibilität vorwarfen.

Winter[Raven]

2004-07-23, 19:12:31

M@g

2004-07-23, 19:22:27

Lasst das gebashe bitte...

Finde es nicht gut das Features "hintenrum" aktivierbar sind. Für was gibts denn die Schnittstellenstandarts? Mehr anbieten als ein Standart ist immer gut, aber an gewisse Regeln sollte man sich doch halten, für was brauchen wir sonst Standarts/Vereinbarungen die den kleinsten gemeinsamen Nenner definieren?

OpenGL bietet ja die möglichkeit über den "Standart" (1.5, 2.0) hinaus per Extensions weitere Features einzubinden, sowas sollte es bei DX auch geben, oder man kann es sich sparen, über "Standarts" zu reden, dann macht jeder seine eigene Suppe.

Benedikt

2004-07-23, 19:28:22

Original geschrieben von Demirug
<schnipp>

In der Zwischenzeit habe ich mich mit wichtigeren Dingen beschäftigt. Der SM30 Pfad läuft jetzt auf den FXen und SM2B sollte ich R3XX tauglich haben. SM2B läuft im Prinzip auch auf den FXen aber SM30 ist da derzeit noch schneller. Könnte aber daran liegen das SM2B keine PP in den Shadern hat. Muss ich also noch ausprobieren wie schnell die FXen mit 2B und PP sind.

Wer einen NV3X oder einen R3XX sein eigenen nennt und Beta-Tester spielen möchte bitte PM an mich.
bzw.
Original geschrieben von Demirug
Falsch. Hätte Crytek im Patch 1.1 diese Lichtpassoptimierung eingebaut hätte sie die FXen ohne Qaulitätsverlust schneller machen können.

Das aufwendigere SM3 Licht läuft auf einer FX schneller als das SM2 Licht.

Damit wiederhole ich einfach einige aufgetretene Fragen:
1. Unterstützen die FXen auch "eine Art von" Object Instancing?
2. Und verrätst du uns FX-Usern auch, wieviel's ca. an Performance bringt, wenn man den SM3.0-Pfad auf einer FX laufen lässt?

MFG,
B. W.

Jesus

2004-07-23, 19:51:04

Original geschrieben von seahawk
Mal OT :

Aber mir fällt auf, dass hier Leute eine solche Verletzung der Norm begrüssen, die vorher oftmals wegen der PP_Lösung der GeForce gejammert haben und ihr nicht volle DX9 Kompatibilität vorwarfen.

re OT ;)

ich denk PP war wurde eher wegen des namens ( Partial Precision , weniger Rechnen , weniger Qualität ;) ) abgelehnt ;)

und es entspricht ja eigenltich immer noch nicht der DX norm was NV da implementiert hat ( FP16 bzw 32. statt FP24 wie´s DX vorschreibt :) )

CMIIAW=)

Demirug

2004-07-23, 19:57:23

Original geschrieben von Benedikt
Damit wiederhole ich einfach einige aufgetretene Fragen:
1. Unterstützen die FXen auch "eine Art von" Object Instancing?
2. Und verrätst du uns FX-Usern auch, wieviel's ca. an Performance bringt, wenn man den SM3.0-Pfad auf einer FX laufen lässt?

MFG,
B. W.

1. AFAIK nicht. nVidia hat zumindestens niemals etwas derartiges behauptet und es gibt auch keine OpenGL Extension dafür.

2. http://www.forum-3dcenter.org/vbulletin/showthread.php?s=&postid=2044361#post2044361

M@g

2004-07-23, 19:59:12

Original geschrieben von Jesus

und es entspricht ja eigenltich immer noch nicht der DX norm was NV da implementiert hat ( FP16 bzw 32. statt FP24 wie´s DX vorschreibt :) )

Stimmt doch so gar nicht, FP24 wird benötigt, aber gegen mehr (und das dürfte wohl FP32 sein) hat man nix einzuwenden...

Jesus

2004-07-23, 19:59:56

Original geschrieben von M@g
Stimmt doch so gar nicht, FP24 wird benötigt, aber gegen mehr (und das dürfte wohl FP32 sein) hat man nix einzuwenden...

aber gegen weniger :)

mrdigital

2004-07-23, 20:00:03

Jesus, ist dieses nV macht kein "richtiges DX" oder ATI hat MS bestochen oder was weiss ich nicht alles noch nicht hinreichend diskutiert worden?
DX schreibt mindestens 24bit vor, wenn nV da 32bit Präzision liefert wirds doch nicht schlechter und auch nicht unrichtiger. Es gibt nun die Möglichkeit auf 16bit (pp - Partial Precission) zurückzuschalten, aber auch das sieht DX vor. In sofern hat nV wunderbar DX9 implementiert bzw sogar übererfüllt.

M@g

2004-07-23, 20:02:26

Original geschrieben von Jesus
aber gegen weniger :)

Wenn mans nicht braucht, warum dann "mehr" verwenden ;)
Würde doch nur mehr Rechenaufwand in dem Fall bedeuten.
Der Käs ist eh schon vor einiger Zeit gegessen worden, aufwärmen lohnt da nicht.

Jesus

2004-07-23, 20:04:41

ich hab ja nicht damit angefangen ;)

Demirug

2004-07-23, 20:04:43

Original geschrieben von Jesus
re OT ;)

ich denk PP war wurde eher wegen des namens ( Partial Precision , weniger Rechnen , weniger Qualität ;) ) abgelehnt ;)

und es entspricht ja eigenltich immer noch nicht der DX norm was NV da implementiert hat ( FP16 bzw 32. statt FP24 wie´s DX vorschreibt :) )

CMIIAW=)

Doch es entspricht der Norm.

[from ps_2_0 section]
---Begin Paste---
Internal Precision
- All hardware that support PS2.0 needs to set D3DPTEXTURECAPS_TEXREPEATNOTSCALEDBYSIZE.
- MaxTextureRepeat is required to be at least (-128, +128).
- Implementations vary precision automatically based on precision of inputs to a given op for optimal performance.
- For ps_2_0 compliance, the minimum level of internal precision for temporary registers (r#) is s16e7** (this was incorrectly s10e5 in spec)
- The minimum internal precision level for constants (c#) is s10e5.
- The minimum internal precision level for input texture coordinates (t#) is s16e7.
- Diffuse and specular (v#) are only required to support [0-1] range, and high-precision is not required.
---End Paste ---

DX schreibt nur minimale Genauigkeiten vor. Mehr ist immer erlaubt. Und dann gibt es da noch den Satz "Implementations vary precision automatically based on precision of inputs to a given op for optimal performance" der ein Freibrief für so einige spielerien mit der Genauigkeit ist.

Jesus

2004-07-23, 20:09:46

Original geschrieben von Demirug
- The minimum internal precision level for input texture coordinates (t#) is s16e7.

aber ist das nicht der Grund dafür dass sich schon einige über die BQ in D3 auf NV ( auf B3D ) mit PP aufgeregt haben ( bei grossen texturen ).

again CMIIAW ( correct me if i am wrong ;) )

Demirug

2004-07-23, 20:20:06

Original geschrieben von Jesus
aber ist das nicht der Grund dafür dass sich schon einige über die BQ in D3 auf NV ( auf B3D ) mit PP aufgeregt haben ( bei grossen texturen ).

again CMIIAW ( correct me if i am wrong ;) )

Nein, weil nVidia bei den texture coordinaten das pp sogar ignoriert und immer FP32 nimmt.

Es kann nur probleme geben wenn man im Shader Texturkoordinaten berechnet und das mit PP Register tut. Der Shadercompiler kann solche fälle aber leicht erkennen.

q@e

2004-07-23, 20:21:07

Original geschrieben von Jesus
aber ist das nicht der Grund dafür dass sich schon einige über die BQ in D3 auf NV ( auf B3D ) mit PP aufgeregt haben ( bei grossen texturen ).

Kaum, da die DX-Spec bei der Entwicklung der Codepfade für Doom3 keine Rolle gespielt haben dürfte... :eyes:

(oder was meinst du mit "D3"?)

Benedikt

2004-07-23, 20:22:46

Original geschrieben von Demirug
1. AFAIK nicht. nVidia hat zumindestens niemals etwas derartiges behauptet und es gibt auch keine OpenGL Extension dafür.

2. http://www.forum-3dcenter.org/vbulletin/showthread.php?s=&postid=2044361#post2044361

*ähem* Ich meinte eigentlich weniger NV40, sondern NV3x in Kombination mit dem SM3.0-Renderpfad.

MFG,
B. W.

/edit: du hast geschrieben, du hättest eine Methode gefunden, den 3.0-Pfad auf den FXen lauffähig zu machen, deshalb meine Frage ...

q@e

2004-07-23, 20:23:57

axo, hier ist's ja schön on-topic:
http://home.arcor.de/quasat/3DC-Pics/FC/FarCry0000a.JPG

Cat4.7, X800Pro - was ist denn das?

Jesus

2004-07-23, 20:26:27

grafikfehler ;) old news ;) ( ca. 2 wochen )

Benedikt

2004-07-23, 20:27:02

Dieselben Probleme wie die hier (http://www.forum-3dcenter.org/vbulletin/showthread.php?s=&threadid=154356&highlight=x800+far+cry), nehme ich mal an (Cat 4.7, X800, Probleme mit Far Cry).

MFG,
B. W.

deekey777

2004-07-23, 20:28:16

Original geschrieben von q@e
axo, hier ist's ja schön on-topic:
http://home.arcor.de/quasat/3DC-Pics/FC/FarCry0000a.JPG

Cat4.7, X800Pro - was ist denn das?

Schaue doch mal in den FC Patch 1.2 Problemthread rein, da siehtst du das schöne Blau auch mit SM 3.0beta.

Nachtrag: Beta ist Beta...

Gast

2004-07-23, 20:28:19

Original geschrieben von Jesus
grafikfehler ;) old news ;) ( ca. 2 wochen )

Nein, ich glaube kaum. Vor zwei Wochen gab es weder den Patch v1.2 öffentlich, noch ein 2.B-Shaderprofil.... :eyes:

q@e

2004-07-23, 20:29:19

^^ /me

Jesus

2004-07-23, 20:30:07

Original geschrieben von Gast
Nein, ich glaube kaum. Vor zwei Wochen gab es weder den Patch v1.2 öffentlich, noch ein 2.B-Shaderprofil.... :eyes:

die fehler traten mit patch 1.2 ohne SM2.0b auf X800 karten auf, in dem test von [H] zum beispiel ;) als das unveröffentlichte Patch1.2 zum ersten mal getestet wurde.

Demirug

2004-07-23, 20:33:44

Original geschrieben von Benedikt
*ähem* Ich meinte eigentlich weniger NV40, sondern NV3x in Kombination mit dem SM3.0-Renderpfad.

MFG,
B. W.

/edit: du hast geschrieben, du hättest eine Methode gefunden, den 3.0-Pfad auf den FXen lauffähig zu machen, deshalb meine Frage ...

Die Werte sind von meiner FX 5900 auf der ja ein NV35 seinen Dients tut. Das NV40 bedeutet dort das Farcry laut Log die NV4X Shader benutzt hat.

deekey777

2004-07-23, 20:37:28

Original geschrieben von q@e
^^ /me

OT: Irgendwo hab ich gelesen, dass ATi wegen des SM 2.0b Profils richtig Feuer unterm Cryteks Arsch gemacht haben soll, damit es schon mit Patch 1.2 released wird.

Benedikt

2004-07-23, 20:38:27

Original geschrieben von Demirug
Die Werte sind von meiner FX 5900 auf der ja ein NV35 seinen Dients tut. Das NV40 bedeutet dort das Farcry laut Log die NV4X Shader benutzt hat.

Sorry, ging nicht so deutlich hervor IMO ... :)

Und du bist dir sicher, dass CineFX trotz seines bedeutend umfassenderen Featuresets gegenüber ATIs R3xx/R420 keinerlei Obj.-Instancing beherrscht? Schade irgendwie ...
Naja, ~3FPS mehr durch Verwendung des SM3.0-Pfades wären ja auch schon was.

MFG,
B. W.

q@e

2004-07-23, 20:47:12

Original geschrieben von Jesus
die fehler traten mit patch 1.2 ohne SM2.0b auf X800 karten auf, in dem test von [H] zum beispiel ;) als das unveröffentlichte Patch1.2 zum ersten mal getestet wurde.

Ja, das war ja auch unveröffentlicht.... nun ist es veröffentlicht und die Fehler sind immer noch da.

Da nimmt es mich wunder, wie man sich über 20% Performancezugewinn freuen kann, wenn gleichzeitig die BQ.... moment.... *sich_erinner* .... das hatten wir doch mit Patch 1.1 schonmal....

Nur komisch, daß da alle Resultate mit nV-Karten irrelevant und ungültig gewesen sein sollen (worin ich i.Ü. mit 'euch' übereinstimme), nun aber auf einmal werden die Bildfehler fein säuberlich ignoriert, obwohl sie teilweise wirklich extreme Ausmaße annehmen...

Far Cry mit Patch 1.2 ist definitiv nix für die X800-Serie - zumindest nicht mit dem Cat4.7.

Jesus

2004-07-23, 20:50:04

Original geschrieben von q@e
Ja, das war ja auch unveröffentlicht.... nun ist es veröffentlicht und die Fehler sind immer noch da.

Da nimmt es mich wunder, wie man sich über 20% Performancezugewinn freuen kann, wenn gleichzeitig die BQ.... moment.... *sich_erinner* .... das hatten wir doch mit Patch 1.1 schonmal....

Nur komisch, daß da alle Resultate mit nV-Karten irrelevant und ungültig gewesen sein sollen (worin ich i.Ü. mit 'euch' übereinstimme), nun aber auf einmal werden die Bildfehler fein säuberlich ignoriert, obwohl sie teilweise wirklich extreme Ausmaße annehmen...

Far Cry mit Patch 1.2 ist definitiv nix für die X800-Serie - zumindest nicht mit dem Cat4.7.

sorry aber das ist ziemlicher Käse den du da erzählst. Das PAtch 1.1 hat die BQ ( beabsichtigt ) runtergeschraubt um Performance zu gewinnen, das ist was anderes als solche Fehler wie sie jetzt auftreten ( im übrigen auch auf nv40...

Original geschrieben von deekey777
Schaue doch mal in den FC Patch 1.2 Problemthread rein, da siehtst du das schöne Blau auch mit SM 3.0beta.

Nachtrag: Beta ist Beta...

Edit.: patch 1.2 wurde übrigens offizell zurückgezogen aufgrund diverser Fehler ;)

Blaire

2004-07-23, 20:55:25

@jesus atius:
Solche Fehler konnte ich bisher bei der NV40 nicht erkennen. Wie kommst du darauf?

Jesus

2004-07-23, 20:57:00

Original geschrieben von Blaire
@jesus atius:
Solche Fehler konnte ich bisher bei der NV40 nicht erkennen. Wie kommst du darauf?

http://img26.exs.cx/img26/2944/FarCry6.jpg

:D

nene das ist definitiv nix für die 6800 ;D

Blaire

2004-07-23, 20:58:15

Nvnews.net? Sieht so aus als würde jemand seine GT zu stark übertaktet haben. Solche Fehler hab ich nicht gehabt.

http://www.nvnews.net/vbulletin/showthread.php?t=32712
Hier der Thread Problem lag nicht am Patch 1.2 bzw. 6800 Ultra ;)

deekey777

2004-07-23, 20:58:35

Original geschrieben von Jesus

Edit.: patch 1.2 wurde übrigens offizell zurückgezogen aufgrund diverser Fehler ;)

OMG!!! :weg:

Original geschrieben von Blaire
@jesus atius:
Solche Fehler konnte ich bisher bei der NV40 nicht erkennen. Wie kommst du darauf?

Schaue doch auch Mal in den FC Patch 1.2 Problemthread rein, da wirst du etwas finden.

q@e

2004-07-23, 21:03:18

Original geschrieben von Jesus
http://img26.exs.cx/img26/2944/FarCry6.jpg

:D
nene das ist definitiv nix für die 6800 ;D

Tjo, leider liegt's wohl nicht am 2.B-Pfad (der ja offiziell noch BETA ist) und auch nicht am fehlenden DX9.0c...
http://home.arcor.de/quasat/3DC-Pics/FC/FarCry0006a.JPG

Dumm das...

Jesus

2004-07-23, 21:06:26

Original geschrieben von q@e
Tjo, leider liegt's wohl nicht am 2.B-Pfad (der ja offiziell noch BETA ist) und auch nicht am fehlenden DX9.0c...
http://home.arcor.de/quasat/3DC-Pics/FC/FarCry0006a.JPG

Dumm das...

ihr seit im falschen thread

http://www.forum-3dcenter.org/vbulletin/showthread.php?s=&threadid=156740&perpage=20&pagenumber=1

es gibt auch noch gelbe buggy bugs( auf GF FX glaub ich wars ) und was weiss ich was ;)

q@e

2004-07-23, 21:08:18

Eigentlich bin ich im richtigen Thread - "X800 und Far Cry 1.2" ist doch hier, oder?

Der einzige, der OT ist, bist du:
Zitat: "nene das ist definitiv nix für die 6800"

Aber ich denke, das wird die Moderation schon geregelt kriegen.

Blaire

2004-07-23, 21:10:02

Original geschrieben von Jesus
ihr seit im falschen thread

http://www.forum-3dcenter.org/vbulletin/showthread.php?s=&threadid=156740&perpage=20&pagenumber=1

es gibt auch noch gelbe buggy bugs( auf GF FX glaub ich wars ) und was weiss ich was ;)

Dort steht das selbe wie im NVNews.net Thread. Er hat es gelöst bekommen. Hat damit wohl wenig mit einem 6800 Problem zu tun.

MfG

Jesus

2004-07-23, 21:20:14

Original geschrieben von q@e
Far Cry mit Patch 1.2 ist definitiv nix für die X800-Serie - zumindest nicht mit dem Cat4.7.

Da es kein 1.2 patch mehr gibt ist diese aussage ( wie auch vorher schon ) nun überflüssig... fragt sich nur wieso Crytek diesen Patch zurückzieht wenn es doch an den schlechten ATI treibern liegen muss...

q@e

2004-07-23, 21:22:02

Original geschrieben von Jesus
[...]wenn es doch an den schlechten ATI treibern liegen muss...

Wer sagt denn sowas? :gruebel: Oder willst du mir Dinge in den Mund legen, die ich weder gesagt noch impliziert habe?

Meine Erwähnung der Cat4.7 war lediglch zur Vervollständidung der nötigen Information um diese Fehler einordnen zu können.

deekey777

2004-07-23, 21:23:15

Original geschrieben von Jesus
Da es kein 1.2 patch mehr gibt ist diese aussage ( wie auch vorher schon ) nun überflüssig... fragt sich nur wieso Crytek diesen Patch zurückzieht wenn es doch an den schlechten ATI treibern liegen muss...

... und es Gerüchte gibt, dass heute der cat. 4.8 (eher 4.7 1/2) kommt.

Jesus

2004-07-23, 21:32:30

Original geschrieben von q@e
Wer sagt denn sowas? :gruebel: Oder willst du mir Dinge in den Mund legen, die ich weder gesagt noch impliziert habe?

Meine Erwähnung der Cat4.7 war lediglch zur Vervollständidung der nötigen Information um diese Fehler einordnen zu können.

nein eigentlich wollte ich damit sagen dass es nicht an den treibern liegt ( höchstwahrscheinlich, da diverse Grafikfehler auch auf FX, X800 und 9800er karten auftreten ), wie von dir angedeutet, sondern an Crytek. Aber die Tatsache dass sie den Patch zurückgezogen haben scheint dich ja nicht sonderlich zu stören :)

q@e

2004-07-23, 21:36:51

Wieso sollte es mich stören? Was möchtest du damit sagen?

q@e

2004-07-23, 21:38:29

Eher im Gegenteil:

Original geschrieben von q@e
Liegt eher am Patch, gut daß CryTek den zurückgenommen hat.
(http://www.forum-3dcenter.org/vbulletin/showthread.php?&postid=2050918#post2050918)... ;)

Gast

2004-07-23, 22:32:42

Original geschrieben von LovesuckZ
ATi's GI.
Nur stell ich mir die Frage, warum dies nicht beworben wurde...

Tombman,
Farcry ist ein DX8 Game mit ein paar DX9 Shadern.
Laut demirug stecke selbst im normalen SM2.0 Pfad einiges an Potential, was nicht ausgeschoepft wurde. So wie ich ihn verstanden habe, stelle der NV40 Pfad eigentlich nur einen SM2.a Pfad dar.

Lovesucks,

warum bitteschön macht nv dann mit farcry den sm3.0 marketing ketchup überrall auf ???

reunion

2004-07-23, 22:39:15

Original geschrieben von Gast
Lovesucks,

warum bitteschön macht nv dann mit farcry den sm3.0 marketing ketchup überrall auf ???

Weil das zurzeit das einzige Spiel ist was zumindest offiziell PS3.0 unterstützt?

Gast

2004-07-23, 22:41:33

Original geschrieben von reunion
Weil das zurzeit das einzige Spiel ist was zumindest offiziell PS3.0 unterstützt?

Tja, laut Lovesuchs ist doch ein DX8.0 Game.

Das verstehe wer will! :)

Ich sag nur, für einen Blockbuster (Dumm3) ein paar Frames schneller sein reicht bei weitem nicht aus um nen Blumentopf hier zu gewinnen.

TheCounter

2004-07-23, 23:50:00

Hier mal ein paar Konsolen-Befehle für Leute mit NV40 bzw. X800 Karten, vielleicht lässt sich ja das ein oder andere schon jetzt aktivieren.

\r_GeomInstancing
\r_HDRBrightOffset
\r_HDRBrightThreshold
\r_HDRLevel

Da ist noch soviel drin im Patch, man weis garnicht was man zuerst untersuchen soll ;)

deekey777

2004-07-23, 23:59:28

Original geschrieben von TheCounter
Hier mal ein paar Konsolen-Befehle für Leute mit NV40 bzw. X800 Karten, vielleicht lässt sich ja das ein oder andere schon jetzt aktivieren.

\r_GeomInstancing
\r_HDRBrightOffset
\r_HDRBrightThreshold
\r_HDRLevel

Da ist noch soviel drin im Patch, man weis garnicht was man zuerst untersuchen soll ;)

Was für ein Patch? ;D

@Gast: Far Cry 1.1 ist ein DX8.0 Spiel mit ein Paar PS 2.0 eye candies.

cl55amg

2004-07-24, 00:19:46

farcry ist zwar irgendwie interessant, weil doom 3 nicht released ist...;-)

aber ich würde sagen das doom nicht "schlecht" programiert ist. und wir dann viel besser vergleichen können...

aber ich denke das ATI und Nvidia sowieso mittlerweile gleichgute karten produzieren...

LovesuckZ

2004-07-24, 09:23:47

Original geschrieben von Gast
Lovesucks,
warum bitteschön macht nv dann mit farcry den sm3.0 marketing ketchup überrall auf ???

Weil es das erste Spiel ist, dass SM3.0 unterstuetzt?

LovesuckZ

2004-07-24, 09:32:17

Original geschrieben von Jesus
was aber im Endeffekt auch egal ist, falls es funktioniert ;)

nein, ist es nicht.
Sollte MS das durchgehen lassen, dass koennen sie gleich alles "frei" machen.
ATi muss sich daran halten, dass GI nur mit einem SM3.0 (bzw. VS3.0) funktioniert.

Gast

2004-07-24, 09:45:31

ATI muss sich an GAR NICHTS halten. Sie werden nur das Problem haben, dass sich diverse Entwickler an die offiziellen Specs orientieren und somit einiges auf den ATI-Karten nicht zu sehen sein wird -> obwohl eigentlich möglich.

LovesuckZ

2004-07-24, 09:48:18

Original geschrieben von Gast
ATI muss sich an GAR NICHTS halten.

Natuerlich nicht, aber Nvidia wird dann doch das selbe Recht zu ehren.
MS machte eine Entscheidung und fertig. Dann haben sie nun in dieser Runde das Pech gehabt, letzten war es Nvidia.

Gibt es eine Moeglichkeit ATi's OI auch unter OpenGL zu verwenden?

Tarkin

2004-07-24, 10:29:10

weiß nicht, ob das schon jemand gepostet hat...

http://www.driverheaven.net/showthread.php?s=&threadid=51427

So to recap:

The major performance increase is due to improvements in the lighting shader. The new patch enables the effect of three lights to be calculated in one pass (previously, each light required its own pass). It is possible, with a bit of extra work, for four lights to be calculated in a single pass on ATI hardware, but Crytek has not made the changes that would enable this. This is the major performance increase on both ATI and Nvidia hardware.

The second performance increase is through the use of instancing. Instancing is a technique by which large numbers of identical objects can be grouped together and processed as a batch, greatly reducing the load on the CPU. Uses in FarCry include trees and grass. In the original version of the game, only trees and clumps of grass close to the player were rendered as geometry (that is, as a collection of triangles with textures painted across them). Further from the viewer they were replaced by "billboards" - a flat image of a tree that always faces the viewer. This increases frame rates, but at some cost to realism. Instancing allows the distance at which geometry must be replaced by billboards to be increased significantly (to the extent that essentially nothing the viewer sees is a billboard) with only a very small hit to performance.

SM3.0 includes instancing, a feature nvidia have promoted heavily, saying that it proves the superiority of their hardware - while this is certainly a major talking and selling point, all X800 cards (and even 9500,9600,9700,9800) are capable of instancing. We have a beta driver in our possession which reflects this and associated performance gains, and it will be in the publicly posted CATALYST 4.8. We dont feel until a final patch is available from Crytek we should post our detailed findings as there is every possibility between now and the next release this could change.

We can give you rough indications of percentage increases - on the research map with Far Cry v1.2 \r_sm2bpath 1 and HLSL compiler profile 2.0b we saw increases of 13% at 1024x768, 21% at 1280x1024 and 25% at 1600x1200. Nothing to be sniffed at.

So what about the juicy gossip? Well to say today has been a dramatic day is an understatement, during our testing period for the last 12 hours or so we have spent alot of time on the phone and in email to many people in the industry, one such person in the industry even stated this:

"Nvidia encouraged Crytek to use partial precision in the shaders wherever possible. This means that many of the shaders will run in 16-bit precision, not the 32-bit precision (a requirement of SM3.0) that they are touting to the press. Ironically, while promoting the 32-bit precision of SM3.0 as a "must have", Nvidia is asking developers to use less precision than was available in SM1.0 - that is, all the way back in DirectX8! Even more ironically, ATI hardware will run most of the FarCry shaders more accurately (ATI hardware runs all shaders in 24-bit precision). Microsoft, the owner of DirectX, defines 24-bit and greater as "full precision" and 16-bit as "partial precision", Nvidia has claimed that ATI paid Crytek to delay the patch and include ATI features (the figure mentioned was $500k!)."

So there you have it, some of the facts, and some rumours.... nonetheless Crytek has committed to delivering 3Dc support in patch v1.3, which will provide higher detail images, or free up memory with better compression than traditional normal map compression options. FarCry is a great example of a next generation title that uses normal maps extensively. When the "final" patch arrives, we will be giving it a good going over and posting indepth results.

I guess its in the hands now of Crytek, lets hope we still arent waiting two months from now, and with Doom3 just around the corner, more importantly will anyone care?

M@g

2004-07-24, 10:48:07

Was für eine herrliche Schlammschlacht...
Hoffentlich denken die Entwickler noch an die Spieler und bringen "funktionierende" Patches raus, bisher war ja einiges nur crap.

Demirug

2004-07-24, 10:53:51

Original geschrieben von M@g
Was für eine herrliche Schlammschlacht...
Hoffentlich denken die Entwickler noch an die Spieler und bringen "funktionierende" Patches raus, bisher war ja einiges nur crap.

Wenn Crytek an die Spieler denken würde hätten wir auch SM20A und einen neuen SM20 Pfad bekommen. Bzw man hätte das ganze einfach ein neues Verfahren für das rendern beleuchteter Objekte genannt.

Crytek ist aber ein Wirtschaftsunternehmen und muss primär ans Geld denken.

TheCounter

2004-07-24, 11:01:40

Interessant, also bräuchte ich den Cat mit v8.041 und ich könnte auch GI auf meinem R350 laufen lassen...

Die Frage ist nur, wieviel das bringen würde.

tombman

2004-07-24, 11:20:14

Original geschrieben von Tarkin

"Nvidia encouraged Crytek to use partial precision in the shaders wherever possible. This means that many of the shaders will run in 16-bit precision, not the 32-bit precision (a requirement of SM3.0) that they are touting to the press. Ironically, while promoting the 32-bit precision of SM3.0 as a "must have", Nvidia is asking developers to use less precision than was available in SM1.0 - that is, all the way back in DirectX8! Even more ironically, ATI hardware will run most of the FarCry shaders more accurately (ATI hardware runs all shaders in 24-bit precision).

O W N E D !!!

Immer wieder geil, wie ATI mit ihrer 24bit-für-alles Strategie so gut zurechtkommt ;)

Nvidia hat zwar 32bit, aber irgendwie wissen sie auch, daß sie eigentlich nicht die nötige power dafür haben, des beinhart in jedem high-end game durchzuziehen- deshalb bitten sie jeden so viel wie möglich 16bit zu nehmen - köstlich :D

M@g

2004-07-24, 11:40:20

Original geschrieben von Tarkin
weiß nicht, ob das schon jemand gepostet hat...

http://www.driverheaven.net/showthread.php?s=&threadid=51427
...Microsoft, the owner of DirectX, defines 24-bit and greater as "full precision" and 16-bit as "partial precision"...

Auf SM3 bezogen stimmt das aber AFAIK nicht...

Und an die ATifanboys...
Wenn weniger Präzision der Shader ausreicht um einen Effekt darzustellen, warum soll man es dann nicht verwenden ^^
Ati macht doch das selbe bei der Anisotropischen Filterung, weglassen was nicht auffällt (auffallen soll, der Vergleich hinkt etwas aber es wird ja dem entprechend Argumentiert).

Winter[Raven]

2004-07-24, 11:44:39

Original geschrieben von M@g
Auf SM3 bezogen stimmt das aber AFAIK nicht...

Berehcnung von 3.0 Shadern setzt FP32 voraus, und nicht FP24. Und wieder News von der Webseite die man am liebsten vergessen sollte.

@ Tombman

Wirds dir nicht langsamm langweillig? jedes mal immer nur heiße Luft und nichts dahinter ... *gähn*

LovesuckZ

2004-07-24, 12:10:02

Original geschrieben von tombman
O W N E D !!!
Immer wieder geil, wie ATI mit ihrer 24bit-für-alles Strategie so gut zurechtkommt ;)

Nicht Fisch und kein Fleisch.
Nv4x ist mit FP16 schneller und beim Einsatz von FP32 schoener und gleichschnell.

Nvidia hat zwar 32bit, aber irgendwie wissen sie auch, daß sie eigentlich nicht die nötige power dafür haben, des beinhart in jedem high-end game durchzuziehen- deshalb bitten sie jeden so viel wie möglich 16bit zu nehmen - köstlich :D

Beweise, dass Nvidia beim Nv4x immernoch eine FP32 "schwaeche" haette.

Original geschrieben von M@g
Wenn weniger Präzision der Shader ausreicht um einen Effekt darzustellen, warum soll man es dann nicht verwenden ^^

Richtig. Reicht ein Shader unter PS2.x aus, dann sollte man diesen nehmen. Erzeugt _pp keine Artefakte, dann sollte reduzierte Genauigkeit verwendet werden.

Original geschrieben von Winter[Raven]
Berehcnung von 3.0 Shadern setzt FP32 voraus, und nicht FP24. Und wieder News von der Webseite die man am liebsten vergessen sollte.

PS3.0 setzen als "volle Genauigkeit" FP32 vorraus. Berechnungen muessen jedoch nicht mit FP32 vorgenommen werden.

Mr. Lolman

2004-07-24, 12:13:46

Original geschrieben von LovesuckZ
Nicht Fisch und kein Fleisch.
Nv4x ist mit FP16 schneller und beim Einsatz von FP32 schoener und gleichschnell.

Du verlangst Beweise, und stellst selbst haltlose Aussagen in den Raum?

Beweise, dass Nvidia beim Nv4x immernoch eine FP32 "schwaeche" haette.

Sagen wir, eine Partielle gibts immernoch. Denn selbst dem NV40 schmecken einige Full Precision Shader überhauptnicht (siehe Shadermark und rthdribl)

Auf endgültige Farcry 1.2 Ergebnisse bin ich schon ganz schön gespannt. (wenns dann Crytek irgendwann gebacken bekommt)

LovesuckZ

2004-07-24, 12:19:24

Original geschrieben von Mr. Lolman
Du verlangst Beweise, und stellst selbst haltlose Aussagen in den Raum?

Es sollte bekannt sein, dass der Leistungszuwachs der NV40 Karten mit FP16 bis zu 50% und mehr betragen kann.

Sagen wir, eine Partielle gibts immernoch. Denn selbst dem NV40 schmecken einige Full Precision Shader überhauptnicht (siehe Shadermark und rthdribl)

Das gelte dann wohl auch fuer ATi und FP24, wenn du den Shadermark2.0 heranziehst.
Und rthdribl: liegt es an den Shadern oder an der Art wie HDR Lightning erzeugt wird?

q@e

2004-07-24, 12:26:40

Original geschrieben von Mr. Lolman
Sagen wir, eine Partielle gibts immernoch. Denn selbst dem NV40 schmecken einige Full Precision Shader überhauptnicht (siehe Shadermark und rthdribl)

Von RTHDRIBL mal abgesehen - welche Shader im ShaderMark2.0 wären das, die "unverhältnismäßig" langsamer sind?
Ich habe da leider keine Zahlen zu im Kopf.

Jesus

2004-07-24, 12:36:28

hallo again ;)

also das soll jetzt kein Fanboy gelaber sein, aber irgendwie scheinen immer mehr Kaufargumente der 6800 dahinzuschwinden ( SM3.0, GI... ) zumindest von der DX seite aus betrachtet ;), da sie die X800 entweder auch hat, oder gleich schnell ( oder sogar schneller ) auf anderem Weg bewältigt ;)

Wenn da nicht D3 und OGL und die miserable Linux Performance wäre ( und wenn ich kohle hätte :D ) wär ich fast schon so weit mir eine zu kaufen ;)
Aber mal abwarten was noch so alles kommt ;)

TheCounter

2004-07-24, 12:37:44

@Demi

Also dein Tool funktioniert wunderbar. :)

EDIT:

Ich erstell dann mal ne Tabelle mit dem Vergleich sm2b vs. sm20 auf meiner R9800.

LovesuckZ

2004-07-24, 12:41:09

Original geschrieben von Jesus
also das soll jetzt kein Fanboy gelaber sein, aber irgendwie scheinen immer mehr Kaufargumente der 6800 dahinzuschwinden ( SM3.0, GI... ) zumindest von der DX seite aus betrachtet ;), da sie die X800 entweder auch hat, oder gleich schnell ( oder sogar schneller ) auf anderem Weg bewältigt ;)

Wie?
Ich dachte SM3.0 waere kein Kaufargument, weil es heutzutage nichts bringen wuerde...
Ob ATi's Hack in zukuenftige Spiele eingesetzt werde, bleibt abzuwarten. Bis dahin ist man einen NV40 besser beraten, da man weiß: SM3.0 = GI.
Wie sagte Nv40 im NvNews.net Forum: Wenn ATi etwas bringt, ist es gleich "genial", "ein kaufargument" und "sehr wertvoll". Macht es Nvidia dagegen kommen Sprueche wie "nutzlos", "brauch'ma nicht", "Verschwendung"...

M@g

2004-07-24, 12:41:55

Nix genaues weis man nicht, und solange nicht mehrere Spiele/Anwendungen SM2.0b und SM3.0 "richtig" einsetzen is das ganze hinfällig und gehört ins Speku Forum ^^
Imoment gibts keinen Patch 1.2 (da der veröffentliche gebugt war und Grafikfehler verursachte, die ggf. auch zu mehr FPS führen können) für FarCry und somit ist die Diskussion hinfällig und gerät so langsam OffTopic.

Schließen und Wiedereröffnen wenns was neues zu Thema gibt, von offizieller Seite.

Jesus

2004-07-24, 12:49:09

naja man kanns schon offenlassen, zumindest um zu sehen was noch alles in dem ehem. Patch1.2 dringewesen wäre ;)

@ls:
ich dachte SM 3 brächte nicht so viel bevor ich diesen patch sah, allerdings tut es das ja anscheinend auch doch, daher kann ich meine Meinung ja auch mal revidieren ;)

Gast

2004-07-24, 13:07:42

Hallo,

hier sind ein paar Ergebnisse mit dem Renderingpfad 2b,

Volcano:1280x1024 2aa+8AF max Details
==============================================================
TimeDemo Play Started , (Total Frames: 5471, Recorded Time: 83.74s)
!TimeDemo Run 0 Finished.
Play Time: 84.54s, Average FPS: 64.71
Min FPS: 31.36 at frame 5376, Max FPS: 142.88 at frame 1771
Average Tri/Sec: 2832436, Tri/Frame: 43769
Recorded/Played Tris ratio: 0.99
==============================================================
TimeDemo Play Started , (Total Frames: 5471, Recorded Time: 83.74s)
!TimeDemo Run 0 Finished.
Play Time: 73.61s, Average FPS: 74.32
Min FPS: 39.73 at frame 5391, Max FPS: 152.07 at frame 1830
Average Tri/Sec: 2479333, Tri/Frame: 33360
Recorded/Played Tris ratio: 1.30

total cool die Erhöhung,werden nachher nochm mehr posten!!

mfg

M@g

2004-07-24, 13:17:55

1. Ab ins Benchmark Forum
2. Da fehlen ein paar Systemangaben ;)

@Jesus
ich finde den 2.0b Renderpfad ist ne gute idee, nur der Hype darum nervt einfach, das teil ist beta stadium und verursacht Bildfehler, und trotzdem freuen sich die Leute...
Paradox da alle der GF68 Serie mit Patch 1.1 vorgeworfen haben, sie würde sich mit Bildfehlern (das berüchtigte Blaue-Kacheln Bild) einen Speedvorteil verschaffen.
Da stinkt einfach, ich will doch nur das das Game gescheit funst und nicht Betatester spielen ^^
(Habe es auf meiner R97 schon durchgespielt mit der GT Benche ich nur noch)

Jesus

2004-07-24, 13:36:12

Original geschrieben von M@g
1. Ab ins Benchmark Forum
2. Da fehlen ein paar Systemangaben ;)

@Jesus
ich finde den 2.0b Renderpfad ist ne gute idee, nur der Hype darum nervt einfach, das teil ist beta stadium und verursacht Bildfehler, und trotzdem freuen sich die Leute...
Paradox da alle der GF68 Serie mit Patch 1.1 vorgeworfen haben, sie würde sich mit Bildfehlern (das berüchtigte Blaue-Kacheln Bild) einen Speedvorteil verschaffen.
Da stinkt einfach, ich will doch nur das das Game gescheit funst und nicht Betatester spielen ^^
(Habe es auf meiner R97 schon durchgespielt mit der GT Benche ich nur noch)

das lag daran das die 6800 mit Patch 1.1 den FX renderpfad benutzte. Und dort waren eben diese "blauen kacheln" ( folge von fp 16 ? ) dazu da die Geschwindigkeit für die FXen zu erhöhen. Daher lag es wohl nahe das auch für die 6800 so zu sehen ( und das Gegenteil hat ja keiner Bewiesen, mit Patch 1.2 ist es nicht mehr vergleichbar da der pfad ja jetzt völlig verändert wurde )

Btw jetzt von einem Hype des 2.0b zu reden find ich nicht angebracht, wo gerade mal 1 oder 2 Seiten überhaupt rausgefunden haben was es bringt;) nicht im Vergleich zum SM3 Hype der davor stattfand ;)

Gast

2004-07-24, 13:42:07

@Jesus
ich finde den 2.0b Renderpfad ist ne gute idee, nur der Hype darum nervt einfach, das teil ist beta stadium und verursacht Bildfehler, und trotzdem freuen sich die Leute...

Also Bildfehler kann ich nicht feststellen????????????????????????

mfg

Benedikt

2004-07-24, 13:49:36

Original geschrieben von LovesuckZ
Wie?
Ich dachte SM3.0 waere kein Kaufargument, weil es heutzutage nichts bringen wuerde...
Ob ATi's Hack in zukuenftige Spiele eingesetzt werde, bleibt abzuwarten. Bis dahin ist man einen NV40 besser beraten, da man weiß: SM3.0 = GI.
Wie sagte Nv40 im NvNews.net Forum: Wenn ATi etwas bringt, ist es gleich "genial", "ein kaufargument" und "sehr wertvoll". Macht es Nvidia dagegen kommen Sprueche wie "nutzlos", "brauch'ma nicht", "Verschwendung"...

Das is' aber anders rum genauso: Du glaubst doch nicht, dass NV viele gute Worte über ATIs 3DC (z. B.) verschwenden wird ... :)
Und ob ATIs Methode, das Object Instancing über FOURCC bekannt zu geben als ein "Hack" zu bezeichnen ist, bin ich mir auch noch nicht ganz sicher. Scheint eine legitime Methode zu sein ...

MFG;
B. W.

M@g

2004-07-24, 13:50:27

Original geschrieben von q@e
axo, hier ist's ja schön on-topic:
http://home.arcor.de/quasat/3DC-Pics/FC/FarCry0000a.JPG

Cat4.7, X800Pro - was ist denn das?

@ Gast
Sowas meinte ich, und im Far Cry Forum (findest du hier http://www.forum-3dcenter.org/vbulletin/forumdisplay.php?s=&forumid=83) findest du noch einige andere die Probleme mit 1.2 haben.

Benedikt

2004-07-24, 13:52:33

Original geschrieben von Jesus
das lag daran das die 6800 mit Patch 1.1 den FX renderpfad benutzte. Und dort waren eben diese "blauen kacheln" ( folge von fp 16 ? ) dazu da die Geschwindigkeit für die FXen zu erhöhen. Daher lag es wohl nahe das auch für die 6800 so zu sehen ( und das Gegenteil hat ja keiner Bewiesen, mit Patch 1.2 ist es nicht mehr vergleichbar da der pfad ja jetzt völlig verändert wurde )

Btw jetzt von einem Hype des 2.0b zu reden find ich nicht angebracht, wo gerade mal 1 oder 2 Seiten überhaupt rausgefunden haben was es bringt;) nicht im Vergleich zum SM3 Hype der davor stattfand ;)

Ist das Kachel-Problem eigentlich mit dem (ich sag jetz mal "inoffiziellen") Patch 1.2 behoben worden, auch für die FXen?

MFG,
B. W.

Jesus

2004-07-24, 13:57:05

Original geschrieben von M@g
@ Gast
Sowas meinte ich, und im Far Cry Forum (findest du hier http://www.forum-3dcenter.org/vbulletin/forumdisplay.php?s=&forumid=83) findest du noch einige andere die Probleme mit 1.2 haben.

wo steht eigentlich dass das mit allen X800 KArten / Konfigurationen auftritt ?

Jesus

2004-07-24, 14:00:02

Original geschrieben von Benedikt
Ist das Kachel-Problem eigentlich mit dem (ich sag jetz mal "inoffiziellen") Patch 1.2 behoben worden, auch für die FXen?

MFG,
B. W.

ja ( zumindest teilweise, besser als vorher ) auf kosten der performance

LovesuckZ

2004-07-24, 14:02:02

Original geschrieben von Benedikt
Das is' aber anders rum genauso: Du glaubst doch nicht, dass NV viele gute Worte über ATIs 3DC (z. B.) verschwenden wird ... :)

Ich rede nicht von den Herstellern, sondern von den usern:
Hier wirst du niemanden finden, der 3Dc den nutzen absprechen wird, weil es DX5T gibt.

Und ob ATIs Methode, das Object Instancing über FOURCC bekannt zu geben als ein "Hack" zu bezeichnen ist, bin ich mir auch noch nicht ganz sicher. Scheint eine legitime Methode zu sein ...

Nun, fuer OI gibt es zur zeit kein capsbit, dass man es unter SM2.x verwenden kann.
MS entschied sich so und ATi soll sich gefaelligst daran halten und nicht mit Hacks anfangen Features in DX "zu pressen".
Immerhin kann man auch kein Ultrashadow und nvidia's FP texturen unter DX verwenden, sowie Integergenauigkeit bei einen PS2.x Shader.

Benedikt

2004-07-24, 14:07:31

Original geschrieben von LovesuckZ
<schnipp>
Nun, fuer OI gibt es zur zeit kein capsbit, dass man es unter SM2.x verwenden kann.
MS entschied sich so und ATi soll sich gefaelligst daran halten und nicht mit Hacks anfangen Feature in DX "zu pressen".
Immerhin kann man auch kein Ultrashadow und nvidia's FP texturen unter DX verwenden, sowie Integergenauigkeit bei einen PS2.x Shader.

Warum so negativ eingestellt? Wenns Performance bringt, wirst du sicher keinen ATI user auf der Welt finden, der ATIs Methode nicht gut findet.
Und NV user betriffts nicht, also eine win-win-Situation, oder?
Ich meine, solange die DX spec nicht verletzt wird ...
Und btw, ich als NV-Benutzer würde mich sehr drüber freuen, wenn Nvidia einen Weg finden würde, z. B. UltraShadow unter DX bereitzustellen!

MFG,
B. W.

Jesus

2004-07-24, 14:07:48

Original geschrieben von LovesuckZ
MS entschied sich so und ATi soll sich gefaelligst daran halten und nicht mit Hacks anfangen Feature in DX "zu pressen".
Immerhin kann man auch kein Ultrashadow und nvidia's FP texturen unter DX verwenden, sowie Integergenauigkeit bei einen PS2.x Shader.

zumindest sollte man nicht darüber urteilen solange wir nicht wissen was es genau ist / macht.

Im übrigen finde ich es nicht schlimm, es ist ja nicht das erstemal dass es features gibt die nicht in der DX Spec vorhanden sind. ATI hätte das ganze ja auch ausserhalb von DX machen können, da is es doch besser das es zumindest über DX verfügbar ist.

Benedikt

2004-07-24, 14:11:16

Nur: Das einzige, was ich an ATIs Methode "verdächtig" finde: Warum hat ATI das jetzt erst bekanntgegeben, haben die ein wenig "Panik" bekommen? Und nach ein wenig "macht einfach irgendwas, egal was, um NV Paroli bieten zu können" schauts mir auch aus.
Ich meine, wenn ich ein Feature anzupreisen habe, mache ich das doch nicht halb-offiziell so von hinten rum, sondern gebe zumindest Infos raus.

MFG,
B. W.

LovesuckZ

2004-07-24, 14:15:43

Original geschrieben von Benedikt
Warum so negativ eingestellt? Wenns Performance bringt, wirst du sicher keinen ATI user auf der Welt finden, der ATIs Methode nicht gut findet.

Es geht nicht um die User, sondern um DX.
Letztes Jahr hat fast jeder ATi user geheuelt, weil Nvidia reduzierte Genauigkeit erzwungen hat. Eigentlich unsinnig, sehen wir doch jetzt, dass FP16 in 90% aller Situationen ausreicht (Shadermark2.0, Rightmark3d, Farcry, Halo, Aquanox2, wahrscheinlich TR:6).

Ich meine, solange die DX spec nicht verletzt wird ...

Es ist eine Verletzung von DX: Es gebe keine Capsbits, so Demirug, um OI unter SM2.x zu verwenden.
Und so handelt es sich wie erwzunges FP16 um ein "regelverstoß".

Gast

2004-07-24, 14:22:37

Original geschrieben von Benedikt
Ist das Kachel-Problem eigentlich mit dem (ich sag jetz mal "inoffiziellen") Patch 1.2 behoben worden, auch für die FXen?

MFG,
B. W.

Ja, das ist nicht mehr existent und auch in erster Instanz durch fehlerhaft kombinierte Shader ausgelöst worden - der fp16-Patch von tb zeigt, daß es kein PP-Problem war.

Mr. Lolman

2004-07-24, 14:33:28

Original geschrieben von LovesuckZ
...

Du hast PN.

Mr. Lolman

2004-07-24, 14:40:03

Original geschrieben von Gast
Ja, das ist nicht mehr existent und auch in erster Instanz durch fehlerhaft kombinierte Shader ausgelöst worden - der fp16-Patch von tb zeigt, daß es kein PP-Problem war.

Also wars ein generelles Shaderproblem. Vielleich ist Crytek, unter dem Aspekt der höheren Geschwindigkeit mit FC 1.1, vgl. mit tbs fp16 Patch, doch garnicht so unfähig, wie es immerweider postuliert wird, sondern hat den Patch unter dem Gesichtspunkt der maximalen Performance für FX Karten veröffentlicht. (was ihnen wohl auch nicht 100% gelungen ist, wie man u.a. von Demirug erfahren konnte)

q@e

2004-07-24, 14:58:23

Oh - höhere Geschwindigkeit?

Benedikt

2004-07-24, 15:09:55

Original geschrieben von LovesuckZ
Es ist eine Verletzung von DX: Es gebe keine Capsbits, so Demirug, um OI unter SM2.x zu verwenden.
Und so handelt es sich wie erwzunges FP16 um ein "regelverstoß".

Sicher, dass da nicht mit DX9.0c etwas kommt?

MFG,
B. W.

Mr. Lolman

2004-07-24, 15:11:11

Original geschrieben von q@e
Oh - höhere Geschwindigkeit?

Geschwindigkeit:

FC1.0 < tb fp16 < FC1.1

Demirug

2004-07-24, 15:12:08

Original geschrieben von Benedikt
Sicher, dass da nicht mit DX9.0c etwas kommt?

MFG,
B. W.

Ich bin sicher das es kein Bit gibt. ;)

LovesuckZ

2004-07-24, 15:13:11

Original geschrieben von Benedikt
Sicher, dass da nicht mit DX9.0c etwas kommt?
MFG,
B. W.

Wenn dies so waere, wuerde ATi diesen ganzen hickhack mit FOURCC nicht anstellen.
Hoffen wir es aber, denn so kann man sich auf die breite Unterstuetzung von OI wohl schneller einstellen als man dachte.

LovesuckZ

2004-07-24, 15:15:19

Original geschrieben von Mr. Lolman
Geschwindigkeit:
FC1.0 < tb fp16 < FC1.1

Ich moechte Quasar den Spass nicht nehmen aber:

FC.10 << FC1.1 <<<< tb FP16

Quelle:
Quasar selbst (http://www.computerbase.de/artikel/hardware/grafikkarten/x800_pro_xt_pe_geforce_6800_gt_ultra/10/#far_cry_v1_1)

q@e

2004-07-24, 15:18:59

Sry, aber daraus geht das nun nicht hervor ;)

Mr. Lolman

2004-07-24, 16:33:43

Original geschrieben von LovesuckZ
Ich moechte Quasar den Spass nicht nehmen aber:

FC.10 << FC1.1 <<<< tb FP16

Quelle:
Quasar selbst (http://www.computerbase.de/artikel/hardware/grafikkarten/x800_pro_xt_pe_geforce_6800_gt_ultra/10/#far_cry_v1_1)

Hab die Quelle garnicht erstmal angeklickt, da Quasar dies ja selbst gleich 'revidiert' hat. Aber deine Pfeilausführungen stehen im Gegensatz zu diversen Userberichten, die z.T. auf Tommtis Patch verzichteten, da zwar die Shader schöner gerechnet werden, aber das ganz nicht mehr so schnell ist, wies noch mit Patch 1.1 der Fall war. Andere finden den Patch von tb performancemässig in 1024 + max Details gerade noch ok, was sich benchmarkmässig ca. mit den Ergebnissen deckt, die ich mit 1024x768 /4xAA 4xbiAF max Details, und aktivierten BQ Tweaks bekomme (oder 1152 4xAA 4xbiAF max Details ohne Tweaks)

(Quellen such ich dir jetzt nicht raus, aber als fleissiger NV/Benchmark Forum Leser sollte man das auch so mitbekommen haben)

aths

2004-07-24, 16:55:17

Original geschrieben von Mr. Lolman
Also wars ein generelles Shaderproblem. Vielleich ist Crytek, unter dem Aspekt der höheren Geschwindigkeit mit FC 1.1, vgl. mit tbs fp16 Patch, doch garnicht so unfähig, wie es immerweider postuliert wird, sondern hat den Patch unter dem Gesichtspunkt der maximalen Performance für FX Karten veröffentlicht. (was ihnen wohl auch nicht 100% gelungen ist, wie man u.a. von Demirug erfahren konnte) Natürlich ist Crytek nicht so unfähig, wie einige rumposaunen. Demirug weist Optimierungspotenzial nach, das nicht genutzt wurde. Leider werden seine Postings manchmal von Leuten interpretiert, die ihn gar nicht verstehen. Immerhin hat Crytek FC gemacht, und etwas ähnliches gibts afaik derzeit nicht. Dass die Jungs nicht jede Optimierungsmöglichkeit gesehen und genutzt haben, tritt angesichts der Leistung dieses Spiel überhaupt fertiggebracht zu haben, imo in den Hintergrund.

Gil-galad

2004-07-24, 17:01:03

Original geschrieben von LovesuckZ
Es geht nicht um die User, sondern um DX.
Letztes Jahr hat fast jeder ATi user geheuelt, weil Nvidia reduzierte Genauigkeit erzwungen hat. Eigentlich unsinnig, sehen wir doch jetzt, dass FP16 in 90% aller Situationen ausreicht (Shadermark2.0, Rightmark3d, Farcry, Halo, Aquanox2, wahrscheinlich TR:6).

Es ist eine Verletzung von DX: Es gebe keine Capsbits, so Demirug, um OI unter SM2.x zu verwenden.
Und so handelt es sich wie erwzunges FP16 um ein "regelverstoß".

Es mag sich ja um einen Regelverstoß handeln aber:

Während FP16 qualitative Nachteile bringt (wie man ja sehen konnte), bringt OI Geschwindigkeit und keinen (!) bildlichen Nachteil.

q@e

2004-07-24, 17:07:42

Original geschrieben von AiS|Gil-galad
Während FP16 qualitative Nachteile bringt [...]

Diese Aussage ist so, wie sie dasteht, genauso falsch, wie die Pauschalisierungen, alle Soldaten wären Mörder, alle Polen klauen Autos und alle Deutschen wären Nazis.

FP16 kann qualitative Nachteile mit sich bringen, weswegen ein zwangsweises verwenden von pp_hints, was es ja in der Vergangenheit gegeben hat, der falsche Weg ist. Es sollte dem Entwickler überlassen werden, wo er meint, sein Content würde durch FP16-Präzision nicht oder nicht sichtbar beeinflusst.

Gil-galad

2004-07-24, 17:12:10

Original geschrieben von q@e
Diese Aussage ist so, wie sie dasteht, genauso falsch, wie die Pauschalisierungen, alle Soldaten wären Mörder, alle Polen klauen Autos und alle Deutschen wären Nazis.

FP16 kann qualitative Nachteile mit sich bringen, weswegen ein zwangsweises verwenden von pp_hints, was es ja in der Vergangenheit gegeben hat, der falsche Weg ist. Es sollte dem Entwickler überlassen werden, wo er meint, sein Content würde durch FP16-Präzision nicht oder nicht sichtbar beeinflusst.

Ja ich hätte es vielleicht eingrenzen sollen.

Unter Umständen kann FP16 die Bildqualität senken, während man durch OI keine Nachteile zu verzeichnen hat.

Demirug

2004-07-24, 17:14:46

Original geschrieben von AiS|Gil-galad
Ja ich hätte es vielleicht eingrenzen sollen.

Unter Umständen kann FP16 die Bildqualität senken, während man durch OI keine Nachteile zu verzeichnen hat.

Man kann auch OI falsch benutzten so das es zu einem Performancen Verlust führt.

Gil-galad

2004-07-24, 17:16:43

Original geschrieben von Demirug
Man kann auch OI falsch benutzten so das es zu einem Performancen Verlust führt.

Sowas wird doch aber von den Entwicklern geprüft oder nicht? Ich kann mir nur schwer vorstellen, dass Entwickler OI einfach einbauen, ohne die Performance zu vergleichen.

Und was ich bei CryTek nicht verstehe: Wieso reduzieren die bei vielen Shadern die Genauigkeit auf 16 Bit und prüfen dann nicht, ob die Bildqualität leidet? Bei den meisten Shadern scheint man ja keine Verschlechterung zu sehen. Aber grad bei den Kacheln ist es ja sehr auffällig. Wieso wird da nicht genauer geprüft?

Winter[Raven]

2004-07-24, 17:19:41

Original geschrieben von AiS|Gil-galad
Sowas wird doch aber von den Entwicklern geprüft oder nicht? Ich kann mir nur schwer vorstellen, dass Entwickler OI einfach einbauen, ohne die Performance zu vergleichen.

Wir haben gesehn wie "gut" Crytek die FP16 Shader verglichen hat, gelle?

Gil-galad

2004-07-24, 17:21:34

Original geschrieben von Winter[Raven]
Wir haben gesehn wie "gut" Crytek die FP16 Shader verglichen hat, gelle?

Bei den Shadern hat CryTek anscheinend nicht richtig hingeschaut oder die Verschlechterung billigend in Kauf genommen.

Bei OI sieht man aber, dass CryTek da anscheinend Ihre Aufgaben erledigt haben ;)

Demirug

2004-07-24, 17:21:53

Original geschrieben von AiS|Gil-galad
Sowas wird doch aber von den Entwicklern geprüft oder nicht?

So sicher bin ich mir da nicht.

Ich habe gesehen das Far Cry ein einzelnes Object per OI gerendert hat. Aus der Sicht der Faulheit ist das natürlich verständlich. Wollte man für den Fall das nur ein gleiches Object vorkommt das Standardverfahren benutzten müsste man ja den Shader entsprechend schreiben das er in eine OI und eine Standard Variante compiliert werden kann. Anders nimmt man halt in Kauf das man bei einem einzelnen Object durch OI einen höheren Overhead hat als wenn man es ohne OI macht.

Gil-galad

2004-07-24, 17:25:55

Original geschrieben von Demirug
So sicher bin ich mir da nicht.

Ich habe gesehen das Far Cry ein einzelnes Object per OI gerendert hat. Aus der Sicht der Faulheit ist das natürlich verständlich. Wollte man für den Fall das nur ein gleiches Object vorkommt das Standardverfahren benutzten müsste man ja den Shader entsprechend schreiben das er in eine OI und eine Standard Variante compiliert werden kann. Anders nimmt man halt in Kauf das man bei einem einzelnen Object durch OI einen höheren Overhead hat als wenn man es ohne OI macht.

Ist der Aufwand so groß, dass man nicht 2 Varianten in den Shader packen kann?

Demirug

2004-07-24, 17:39:47

Original geschrieben von AiS|Gil-galad
Ist der Aufwand so groß, dass man nicht 2 Varianten in den Shader packen kann?

Eigentlich nicht. Zudem müsste die zweite Varainte ja sowieso für Karten die kein OI können vorhanden sein. Es fehlt also nur ein wenig mehr Logig die zwischen OI und nicht OI wählt.

Gil-galad

2004-07-24, 17:42:28

Original geschrieben von Demirug
Eigentlich nicht. Zudem müsste die zweite Varainte ja sowieso für Karten die kein OI können vorhanden sein. Es fehlt also nur ein wenig mehr Logig die zwischen OI und nicht OI wählt.

Dann sollte es ja eigentlich keine Anwendungen geben, wo OI negativ "auffällt". Denn jeder der Programmieren kann (in dem Umfang von Far Cry etc.) sollte eigentlich ensprechend fit sein.

Gast

2004-07-24, 19:35:45

Original geschrieben von Demirug
Das stimmt schon das "Geometry Instancing" nicht nur mit VS 3.0 benutzt werden kann. Wenn es eine Karte unterstützt kann man es mit Shadern jeder Version benutzten. Es ist aber (auch bei DX 9.0c) so definiert das die Meldung das VS 3.0 unterstützt werden auch bedeut das die Karte GI beherscht. Laut Spec ist das auch die einzige Methode zum feststellen ob GI unterstützt wird.

Entweder hat ATI geschlafen und sich kein Capsbit dafür machen lassen oder MS wollte nicht.

Wenn es bei ATI Performance bringt, dann werden doch irgendwelche Recheneinheiten benutzt, die nicht ausgelastet sind. Könnte es sein, dass dafür die RE bemüht werden, welche normalerweise für das(nicht DX konforme) Displacement Mapping zur Verfügung stehen?
Ist schon erstaunlich, dass ATI OI mit ihrer GPU realisieren kann. :kratz:

Ja, meine auch dass ATI da bisschen geschlafen hat. Es ist immer sinnvoll die maximalen Möglichkeiten einer GPU den Entwicklern mitzuteilen, auch wenn sie ausserhalb der Specifikation liegen. Das kann eigentlich nur von Vorteil sein.
ATI muss den Entwicklersupport noch bisschen verbessern. :)

Demirug

2004-07-24, 19:41:11

Original geschrieben von Gast
Wenn es bei ATI Performance bringt, dann werden doch irgendwelche Recheneinheiten benutzt, die nicht ausgelastet sind. Könnte es sein, dass dafür die RE bemüht werden, welche normalerweise für das(nicht DX konforme) Displacement Mapping zur Verfügung stehen?
Ist schon erstaunlich, dass ATI OI mit ihrer GPU realisieren kann. :kratz:

Das DM von ATI ist DX konform aber völlig unbrauchbar weil es von der CPU gemacht wird.

OI kann man im Prinzip auch über den Treiber und die CPU machen. Damit möchte ich ATI aber jetzt nichts unterstellen.

Gast

2004-07-24, 19:50:36

Original geschrieben von Demirug
OI kann man im Prinzip auch über den Treiber und die CPU machen. Damit möchte ich ATI aber jetzt nichts unterstellen.

Bei FC, welches sehr CPU-lastig ist, würde es doch nichts bringen, oder?

Benedikt

2004-07-24, 19:56:31

Original geschrieben von Demirug
Das DM von ATI ist DX konform aber völlig unbrauchbar weil es von der CPU gemacht wird.

OI kann man im Prinzip auch über den Treiber und die CPU machen. Damit möchte ich ATI aber jetzt nichts unterstellen.

Aber welche Einheiten werden denn dann dazu verwendet? Dass da noch etwas in den R3xx Chips brach gelegen hat, ist IMO irgendwie unwahrscheinlich... Realisiert man da intern irgendeine Lastverteilung auf Einheiten, die bis jetzt noch nicht verwendet wurden?
Ich meine der R3xx sollte doch schon irgendwie ausgereizt sein, so lange der schon am Markt ist...

MFG,
B. W.

/edit: wenn's wirklich über die CPU gemacht wird, und unterm Strich höhere Frameraten ergibt, dann ist doch entweder FarCry ineffizient oder der Treiber... oder täusche ich mich da?

Demirug

2004-07-24, 20:03:13

Original geschrieben von Gast
Bei FC, welches sehr CPU-lastig ist, würde es doch nichts bringen, oder?

Es könnte auch dann noch einen leichten Vorteil bringen weil das aufrollen des OIs vom Treiber gemacht. Dadurch entfällt der DX-Overhead der mit jedem Drawcall verbunden ist.

Demirug

2004-07-24, 20:07:34

Original geschrieben von Benedikt
Aber welche Einheiten werden denn dann dazu verwendet? Dass da noch etwas in den R3xx Chips brach gelegen hat, ist IMO irgendwie unwahrscheinlich... Realisiert man da intern irgendeine Lastverteilung auf Einheiten, die bis jetzt noch nicht verwendet wurden?
Ich meine der R3xx sollte doch schon irgendwie ausgereizt sein, so lange der schon am Markt ist...

MFG,
B. W.

OI muss wenn es der Chip macht im Vertex-DMA erledigt werden. Diese Einheit lädt die Vertex informationen vom Speicher in den Chip und versorgt die Shader damit.

Das es auch der R300 können soll macht mich irgendwie aber auch stuzig. Warum hat ATI dann nicht versucht schon damals ein Capsbit dafür zu bekommen?

/edit: wenn's wirklich über die CPU gemacht wird, und unterm Strich höhere Frameraten ergibt, dann ist doch entweder FarCry ineffizient oder der Treiber... oder täusche ich mich da?

s. meinen letzten Post.

Gast

2004-07-24, 20:14:53

Original geschrieben von Demirug
Es könnte auch dann noch einen leichten Vorteil bringen weil das aufrollen des OIs vom Treiber gemacht. Dadurch entfällt der DX-Overhead der mit jedem Drawcall verbunden ist.
Ach so, danke. :)

Über die Treiber zu Programmieren geht also schneller. So eine Art Assembler im Vergleich zu C++. *g*
Wäre es in diesem Fall nicht sinnvoller, wenn die IHVs ihre DX-Schnittstellen proggen und es an MS weitergeben oder bremst DX die Grakas künstlich ein?

Demirug

2004-07-24, 20:19:06

Original geschrieben von Gast
Ach so, danke. :)

Über die Treiber zu Programmieren geht also schneller. So eine Art Assembler im Vergleich zu C++. *g*
Wäre es in diesem Fall nicht sinnvoller, wenn die IHVs ihre DX-Schnittstellen proggen und es an MS weitergeben oder bremst DX die Grakas künstlich ein?

Das mit DX der Runtime und den Treibern ist etwas kompliziert und ändert sich bei Longhorn sowieso. Kurz gesagt erkauft man sich bei DX den Vorteil das es einfacher ist gute Treiber zu schreben mit einem grösseren Overhead bei den aufrufen. Bei Longhorn wird dieser Overhead aber kleiner.

Um da noch mehr ins Detail zu gehen fehlt mir hier der Platz und es wäre entgültig total OT.

Stebs

2004-07-24, 20:59:14

Dann noch schnell eine kurze Frage dazu:
Währe ein kleinerer Overhead auch bei einem (hypothetischen?) DirectX"Next" für WindowsXP machbar oder ist aus technischer Sicht Longhorn notwendig dafür?

mapel110

2004-07-24, 21:39:07

Original geschrieben von Stebs
Dann noch schnell eine kurze Frage dazu:
Währe ein kleinerer Overhead auch bei einem (hypothetischen?) DirectX"Next" für WindowsXP machbar oder ist aus technischer Sicht Longhorn notwendig dafür?

http://www.forum-3dcenter.org/vbulletin/showthread.php?s=&threadid=157320
antwort und weitere Diskussion dort.

Benedikt

2004-07-24, 21:51:23

Original geschrieben von Demirug

s. meinen letzten Post.

Ja, also wenn ich das richtig verstanden habe, "faked" ATI quasi OI und fasst einfach Drawcalls im Treiber intern zusammen, um einen ähnlichen Effekt wie OI zu erzielen bzw. die Effizienz zu erhöhen und die DX-Calls zu verringern. Korrekt?
Oder hat dieser Vertex-DMA den du ansprichst Funktionen die erst jetzt richtig genutzt werden?

MFG,
B. W.

/edit: kannst du das irgendwie überprüfen/messen ob das wirklich eine HW-Geschichte ist, oder nicht?

Demirug

2004-07-24, 22:00:17

Original geschrieben von Benedikt
Ja, also wenn ich das richtig verstanden habe, "faked" ATI quasi OI und fasst einfach Drawcalls im Treiber intern zusammen, um einen ähnlichen Effekt wie OI zu erzielen bzw. die Effizienz zu erhöhen und die DX-Calls zu verringern. Korrekt?
Oder hat dieser Vertex-DMA den du ansprichst Funktionen die erst jetzt richtig genutzt werden?

MFG,
B. W.

/edit: kannst du das irgendwie überprüfen/messen ob das wirklich eine HW-Geschichte ist, oder nicht?

Was ATI macht weiss ich nicht. Ich wollte lediglich aufzeigen das man OI im Treiber emulieren kann auch wenn die Karte eigentlich kein OI kann.

Messen kann man das ganze eher schlecht. Solange ATI die Details zu iherem OI nicht rausrückt wird das sogra noch komplizierter weil man sich die Informationen aus farcry herausholen müsste.

Stebs

2004-07-24, 22:03:44

Edit: Hier was rausgeschnitten und nach http://www.forum-3dcenter.org/vbulletin/showthread.php?s=&threadid=157320 geschmissen, hab mir mit der Antwort bisschen zu viel Zeit gelassen ;)

Um jetzt verschiedene Neuigkeiten mal zusammenzufassen und zu schaun ob ichs verstanden habe:

OI (Object Instancing) ist (laut Gerüchten?) auch auf ATI's R300-R420 möglich. Laut DirectX-Specs muss OI erst ab SM3 vorhanden sein, leider existiert keine (DirectX-konforme) Möglichkeit das Vorhandensein diese Fähigkeit auf prä-SM3 Karten zu testen. Da ATI's Karten aber natürlich keine SM3-Karten sind, "basteln" sie jetzt (ausserhalb der DX-Specs) sozusagen ein eigenes Capsbit mit Hilfe der FourCC-Funktion. (Z.b. gaukeln sie per Treiber die Fähigkeit vor ein bisher (und zukünftig) nie benütztes Texturformat zu unterstützen, was in Wirklichkeit dann Unterstützung für OI heisst)- das war natürlich wilde Spekulation meinerseits.
Ich sehe in diesem Fall keine so grosse Gefahr für die generelle Unterstützung von OI, da ab SM3 ja eh immernoch alles klar ist. Höchstens die Unterstützung von OI auf < SM3-Karten ist fragwürdig, da sämtliche Entwickler da mitspielen müssten.
Wie genau OI auf ATI-Karten funktionniert ist unklar, schlimmstenfalls per Treiber+CPU, wobei im Endeffekt trotzdem ein (kleiner) Performancevorteil rauskommen könnte.

Hab ich soweit alles richtig verstanden?

Benedikt

2004-07-24, 22:04:29

Original geschrieben von Demirug
Was ATI macht weiss ich nicht. Ich wollte lediglich aufzeigen das man OI im Treiber emulieren kann auch wenn die Karte eigentlich kein OI kann.

Messen kann man das ganze eher schlecht. Solange ATI die Details zu iherem OI nicht rausrückt wird das sogra noch komplizierter weil man sich die Informationen aus farcry herausholen müsste.

Naja wahrscheinlich rücken sie in Kürze sowieso damit groß raus ("NV's killer features aren't killer anymore...") :)

MFG,
B. W.

LovesuckZ

2004-07-24, 22:09:11

Original geschrieben von Benedikt
Naja wahrscheinlich rücken sie in Kürze sowieso damit groß raus ("NV's killer features aren't killer anymore...") :)
MFG,
B. W.

Die erste frage lautet dann:
Warum man dieses Feature den ATi user vorenthalten hat und wahrscheinlich auch weiter haette. Sozusagen die selbe Situation wie mit "trilinear", nur umgedreht.
Wir reden dauernd von DX:
Wie sieht es mit OpenGL aus? Ich meine, gibt es eine Moeglichkeit ATi's OI hier zu verwenden? Bis jetzt habe ich nirgends gelesen, dass es von ATi eine Moeglichkeit gibt...

Benedikt

2004-07-24, 22:13:54

Original geschrieben von LovesuckZ
Die erste frage lautet dann:
Warum man dieses Feature den ATi user vorenthalten hat und wahrscheinlich auch weiter haette. Sozusagen die selbe Situation wie mit "trilinear", nur umgedreht.
Wir reden dauernd von DX:
Wie sieht es mit OpenGL aus? Ich meine, gibt es eine Moeglichkeit ATi's OI hier zu verwenden? Bis jetzt habe ich nirgends gelesen, dass es von ATi eine Moeglichkeit gibt...

Hmm, anzunehmen dass das im Zuge der neuen OGL-Treiber dazu kommt. Andererseits scheint OGL keine so hohe Priorität für ATI zu haben im Moment. Mal sehen.

MFG,
B. W.

StefanV

2004-07-25, 08:42:28

Original geschrieben von Benedikt
Hmm, anzunehmen dass das im Zuge der neuen OGL-Treiber dazu kommt. Andererseits scheint OGL keine so hohe Priorität für ATI zu haben im Moment. Mal sehen.

MFG,
B. W.

Naja, das Problem ist doch, daß es kaum noch (NEUE!!) OGL SPiele gibt...
Das einzige, was mir so aus dem Stehgreif einfällt, wäre Doom3 als OGL Only, andere (eigentlich Multi API) Games setzen mehr auf D3D, z.B. UT2003, bei FarCry wurde der OGL Support AFAIK sogar gestrichen.

Wenn man sich die Situation bei OGL auch anschaut, dann ists auch verständlich...

Wobei das größte Problem die Trägheit des OGL Komitees sein dürfte...

BlackBirdSR

2004-07-25, 09:25:53

Original geschrieben von Stefan Payne
Naja, das Problem ist doch, daß es kaum noch (NEUE!!) OGL SPiele gibt...
Das einzige, was mir so aus dem Stehgreif einfällt, wäre Doom3 als OGL Only, andere (eigentlich Multi API) Games setzen mehr auf D3D, z.B. UT2003, bei FarCry wurde der OGL Support AFAIK sogar gestrichen.

Wenn man sich die Situation bei OGL auch anschaut, dann ists auch verständlich...

Wobei das größte Problem die Trägheit des OGL Komitees sein dürfte...

MOHAA:2
Kotor:2
ähm ja das wars soweit ich mich erinnern kann ;)

Gast

2004-07-25, 12:30:39

Seltsam, über das Instancing-Demo wird noch gar nicht geredet :

DH Editorial: ATI and Instancing, further investigation (http://www.driverheaven.net/showthread.php?threadid=51500&s=)

Die X800XT-PE ist in diesem Nvidia-Demo(!) um 20% schneller als eine 6800GT, der Zugewinn durch Instancing ist allerdings geringer als bei den 6800er'n.

LovesuckZ

2004-07-25, 12:33:27

Nur 20%?
Da verbufft ja irgendwo Leistung, aber was will man von 'nen Hack auch mehr erwarten...

q@e

2004-07-25, 12:33:55

..als eine GT mit Ultra-Taktraten!
Sollten doch aber mehr als 30% sein. ;)

Jesus

2004-07-25, 13:48:27

X800XT: 4.5fps ( OI off ) - 48fps ( OI on, SM2.0b )
6800U : 3.0fps ( OI off ) - 40fps ( OI on, SM3.0 )

wo ist dass da weniger effizient ? oder bin ich da auf dem falschen dampfer ;) kommt mir jetzt blos nicht mit den taktraten ;)

btw seh ich das richtig die haben nur den SM3 check des benchamrks entfernt und es hat gefunzt ? wozu dann dieses FourCC zeugs ? oder wird das vom treiber dann automatisch emuliert wenn eine SM3 OI anweisung kommt über dieses FourCC. Dann wäre der aufwand für die entwickler ja gleich null ;)

LovesuckZ

2004-07-25, 13:51:33

Original geschrieben von Jesus
wo ist dass da weniger effizient ? oder bin ich da auf dem falschen dampfer ;) kommt mir jetzt blos nicht mit den taktraten ;)

20% Vorsprung bei effektiveren VS und 30% hoeheren Coretakt -> gleiche effizienz?
Wohl nicht...

/edit: jesus, lese doch den Thread nochmal :)
ATi sendet mit diesen FOURCC Hack, dass sie OI unterstuetzen und koennen es dann ausfuehren.
Ohne diesen Umweg kann man es nicht verwenden.

Jesus

2004-07-25, 13:56:14

gut und wenn du mir jetzt noch sagst wie dann bin ich zufrieden ;)

btw wird OI nicht schon in diesem Croud demo von ATI verwendet ? oder sind das nur vertex shader ?

btw die demo ist ja auch für den NV40 "optimiert" ;) viell. ist das ja auch ausschlaggebend für "nur" 20% vorsrpung ;)

deekey777

2004-07-25, 13:56:44

Original geschrieben von BlackBirdSR
MOHAA:2
Kotor:2
ähm ja das wars soweit ich mich erinnern kann ;)

Bei MOH: PA würde ich keine Wetten abgeben, dass es mit 199%iger Wahrscheinlichkeit ein OpenGL Spiel sein wird. Überall steht, dass für dieses Spiel eine ganz neue Engine entwickelt wird, einige schreiben auch, dass es gar eine DX9 Engine ist. Zumindest kenne ich kein OpenGL Spiel, welches Havoc verwendet.

KOTOR 2 basiert wie der Vorgänger auf der NWN-Engine. Aber es ist ein neues OGL-Spiel.

LovesuckZ

2004-07-25, 13:59:21

Original geschrieben von Jesus
gut und wenn du mir jetzt noch sagst wie dann bin ich zufrieden ;)

Ab hier: http://www.forum-3dcenter.org/vbulletin/showthread.php?s=&postid=2049494#post2049494

Jesus

2004-07-25, 14:00:44

Original geschrieben von LovesuckZ
Ab hier: http://www.forum-3dcenter.org/vbulletin/showthread.php?s=&postid=2049494#post2049494

ich hab den thread gelesen, und selbst demi weiss (noch ) nicht genau wie sie es machen...

Demirug

2004-07-25, 14:01:48

Der FOURCC Hack wird gebraucht damit das Programm erkennen kann das es OI verweden kann. ATI hat sich damit sozusagen ein eigenes zusätzliches Capsbit gebaut.

Benutzt man OI bei einer Karte/Treiber der das nicht kann ist das Bild herlich kaputt. Das gibt die schönsten Renderfehler (gesehen auf einer GFFX). Im besten Fall. Im schlimmsten kann alles den Bach runtergehen.

Gast

2004-07-25, 16:15:44

Demirug könntest du vielleicht eine kurze Anleitung dafür schreiben wie man den 2.b-Renderpfad auf R3xx Karten zum laufen bingt bzw. PS3.0 auf den NV3x-Karten?

Gil-galad

2004-07-25, 16:23:08

Original geschrieben von Gast
Demirug könntest du vielleicht eine kurze Anleitung dafür schreiben wie man den 2.b-Renderpfad auf R3xx Karten zum laufen bingt bzw. PS3.0 auf den NV3x-Karten?

Demi hat da so ein kleines, feines Tool geschrieben, um es auf ner R3xx zum Laufen zu bekommen ;) Vielleicht stellt er es ja der breiten Masse zur Verfügung.

Allerdings sollte man von dem Pfad auch nicht zuviel erwarten. Hier mal ein paar Werte:

Athlon XP 3400+
Radeon 9700 Pro

Auflösung: 1024x768, 1xAA, 1xAF
Map: Bunker

SM 2.0: 72,9
SM 2.0b: 78,2 (+7,3 %)

Map: Boot

SM 2.0: 54,4
SM 2.0b: 53,3 (-2 %)

Auflösung: 1024x768, 2xAA, 16xAF
Map: Bunker

SM 2.0: 54,3
SM 2.0b: 56,7 (+4,4 %)

Map: Boot

SM 2.0: 37,7
SM 2.0b: 39,3 (+4 %)

Wieso ist der 2.0er Pfad bei "Boot" ohne AA/AF schneller als mit AA/AF? Hat AA/AF irgend nen Einfluss auf OI? Oder wo liegt da das Problem?

deekey777

2004-07-25, 16:46:22

@AiS|Gil-galad: Mit welchem Treiber hast du denn getestet? ;(

FarCry v.1.2 Tests Continued, Shader 2.b (http://www.digit-life.com/articles2/gffx/fc12-2.html) Wer kein Russisch kann, kann jetzt den Tests auf Englisch lesen - wenn er kann...

Gil-galad

2004-07-25, 16:58:43

Original geschrieben von deekey777
@AiS|Gil-galad: Mit welchem Treiber hast du denn getestet? ;(

FarCry v.1.2 Tests Continued, Shader 2.b (http://www.digit-life.com/articles2/gffx/fc12-2.html) Wer kein Russisch kann, kann jetzt den Tests auf Englisch lesen - wenn er kann...

Catalyst 4.7

Wieso das :(?

LovesuckZ

2004-07-25, 17:01:54

Original geschrieben von AiS|Gil-galad
Catalyst 4.7
Wieso das :(?

Weil dann OI keinen Einfluss hat.
Wahrscheinlich ist die "Boat" Demo CPU limitierend und bei AA/AF spart man durch die Passreduzierung Fuellrate, die man mit AF wieder verpulvern kann.

Demirug

2004-07-25, 17:18:04

Das Tool ist noch Beta und es gibt da noch ein paar Problemchen die ich aussortiert haben möchte.

Der Pfad macht auf NV3X/R3XX Karten nichts anderes als Lichtquellen zusammenzufassen. Bei den R3XX Karten bin ich dann gezwungen diese Multilicht-Shader teilweise weider in zwei Passes zu zerlegen weil SM2.0 das nicht in einem schaft. Der Erfolg hängt also im wesentlichen davon ab wie viele Lichtquellen zum Einsatz kommen. Erkennen kann man das recht gut an der Polygonenanzahl. Kann der Pfad Lichtquellen zusammenfassen reduziert sich von 2.0 nach 2.b/3.0 die Polyzahl. Gelingt das nicht sind die neuen Pfade allerdings in der Tendenz langsamer weil sie eine aufwendigere Lichtberechnung nutzen.

deekey777

2004-07-25, 17:51:12

Original geschrieben von AiS|Gil-galad
Catalyst 4.7

Wieso das :(?

Danke.
Und ich fand keinen passenden Smiley. Dieser ;( ist laut dem "Längster Thread der Welt"-Reglement ein Universalsmiley.

ZonK

2004-07-25, 18:49:41

also lt. driverheaven müsste lightning aber in einem pass mit sm2.0b gehen, oder hab ich das irgendwie falsch verstanden?

"Shader Model 2.0b path:
The main benefit of the Shader Model 2.0b path in FarCry is that you have much improved one pass lighting support. As this improves the performance of indoor areas (due to heavy use of lighting) the SM 2.0b path gives benefit in many levels within FarCry. Additionally the 2.0b path gives added support for other complex shaders throughout the game, again boosting performance."

mayo

2004-07-25, 19:11:08

Demirug

2004-07-25, 19:46:28

Original geschrieben von ZonK
also lt. driverheaven müsste lightning aber in einem pass mit sm2.0b gehen, oder hab ich das irgendwie falsch verstanden?

"Shader Model 2.0b path:
The main benefit of the Shader Model 2.0b path in FarCry is that you have much improved one pass lighting support. As this improves the performance of indoor areas (due to heavy use of lighting) the SM 2.0b path gives benefit in many levels within FarCry. Additionally the 2.0b path gives added support for other complex shaders throughout the game, again boosting performance."

Das hast du schon richtig verstanden. 2.B können aber nur die R420 Chips. Ich wollte nun aber den 2B Path von farcry auch auf R300 und anderen SM20 Chips (wie Deltachrom) nutzen.

2.B ist ja nun primär nichts anderes als 2.0 mit mehr Registern und grösseremprogrammspeicher. Die Länge der im 2B Pfad benutzen Shader ligt in einem Bereich der es erlaubt das man in auch mit 2 2.0 Shader ausführen kann. Die Kunst dabei ist es jetzt nur die richtige Stelle zum auftrennen zu finden und dann zu entscheiden welche Anweisungen in den ersten, den zweiten oder in beide Teile müssen. Das es sehr viele Shader gibt hat mein Tool entsprechenden Funktionen die diesen Job automatisch erledigen. Die Funktionen erkennen natürlich auch wenn der 2B Shader in einem Pass von einem 2.0 Chip ausgeführt werden kann. In diesem Fall wird nicht gesplitet.

Bei den FXen ist es einfacher. Diese können ja 2.A. was mächtiger ist als 2.B. Allerdings macht es bei den FXen mehr sinn den SM30 Pfad zu benutzten weil dieser ja primär für nVidiachips vorgesehen ist. Um den SM3 Pfad zum laufen zu bekommen müssen die 3.0 Shader in 2.A gewandelt werden. Dies ist mit enstsprechenden Funktionen möglich da Farcry keine Befehle benutzt die es nur bei 3.0 gibt. Daher kann jeder 3.0 Shader in einem 2.A Shader gewandelt werden.

ZonK

2004-07-25, 20:34:04

Demirug: Danke, sehr gute Erklärung!

Was mich jetzt noch interessieren würde ist ob es noch mehr solcher "Hidden"-Features im R300/R420 Core gibt die schon SM 3.0 entsprechen und in Zukunft durch neue Treiber aktiviert werden könnten?

Demirug

2004-07-25, 20:49:09

Original geschrieben von ZonK
Demirug: Danke, sehr gute Erklärung!

Was mich jetzt noch interessieren würde ist ob es noch mehr solcher "Hidden"-Features im R300/R420 Core gibt die schon SM 3.0 entsprechen und in Zukunft durch neue Treiber aktiviert werden könnten?

Genau weiss das wohl nur ATI. Bei den Shadern ist das aber eher unwahrscheinlich weil man das dann gleich in 2.B aufgenommen hätte.

LovesuckZ

2004-07-25, 22:01:27

Was ist effektiver als PS2.b, SM3.0 oder OI?
Ganz klar: FP16!
Siehe auch den ersten test mit dem durch einen Hack ermoeglichten OI von ATi beiXbitlabs.com (http://www.xbitlabs.com/articles/video/display/farcry20b.html).

/edit: Sry, aber dieser Test ist daemlich:
Entweder ich oder die Leute bei Xbitlabs.com sind blind. Kostprobe?

We also see almost no differences between NVIDIA’s and ATI’s image quality, - Nicht?

It is important to point out that ATI’s RADEON X800 XT and PRO graphics cards handle extreme geometry load better compared to NVIDIA’s GeForce 6800 Ultra and GT, which may mean that from this point ATI’s visual processing units have higher future-proof than NVIDIA’s latest graphics processing units do."

Wos? (http://www.xbitlabs.com/articles/video/display/farcry20b_12.html)

Schade, aber ich hielt Xbitlabs.com meisten fuer sehr kompetent.

deekey777

2004-07-25, 22:28:17

Kann es sein, dass es zumindest zw. SM2.0b und SM 3.0 im Archivscreenshot mehr als ein deutlicher visueller Unterschied gegeben ist? Irgendwie gibt die Taschenlampe bei der Radeon mehr Licht ab.

Bei mir gibt die Taschenlampe viel mehr Licht als die NV40.

Jesus

2004-07-25, 22:29:48

wieso ATI fps steigen im Verhältnis stärker an durch OI als NV ;)

ergo effizienter, obwohls nur ein hack ist ( wahrscheinlich ) ;) was soll daran falsch sein im Fazit ( ausser das es reichlich übertrieben klingt ;) ) ?

It is important to point out that ATI’s RADEON X800 XT and PRO graphics cards handle extreme geometry load better compared to NVIDIA’s GeForce 6800 Ultra and GT, which may mean that from this point ATI’s visual processing units have higher future-proof than NVIDIA’s latest graphics processing units do.

Additionally, ATI’s RADEON X800 XT traditionally calculates complex pixel shaders faster than everything else available today...

deekey777

2004-07-25, 22:34:17

Original geschrieben von Jesus
wieso ATI fps steigen im Verhältnis stärker an durch OI als NV ;)

ergo effizienter, obwohls nur ein hack ist ( wahrscheinlich ) ;) was soll daran falsch sein im Fazit ? ;)

Keiner weiss, wie OI bei den Radeons zustande kommt, zB ob die CPU eine grössere Rolle spielt oder nicht.

Jesus

2004-07-25, 22:34:56

Original geschrieben von deekey777
Kann es sein, dass es zumindest zw. SM2.0b und SM 3.0 im Archivscreenshot mehr als ein deutlicher visueller Unterschied gegeben ist? Irgendwie gibt die Taschenlampe bei der Radeon mehr Licht ab.

Bei mir gibt die Taschenlampe viel mehr Licht als die NV40.

jo ziemlich krasser unterschied, das habe ich auch schon vor 2 wochen mal hier gepostet, genauso wie den NV "Schattenbug (http://www.xbitlabs.com/images/video/farcry30/geforce_shadows.jpg)" ( reduzierte genauigkeit ) ... aber das intressiert auch niemanden wirklich, zumindest nicht von der NV fraktion ;)

Original geschrieben von deekey777
Keiner weiss, wie OI bei den Radeons zustande kommt, zB ob die CPU eine grössere Rolle spielt oder nicht.

ok das ist ein argument ;)

deekey777

2004-07-25, 22:39:52

Original geschrieben von Jesus
jo ziemlich krasser unterschied, das habe ich auch schon vor 2 wochen mal hier gepostet, genauso wie den NV "Schatten-bug" ( reduzierte genauigkeit ) ... aber das intressiert auch niemanden wirklich, zumindest nicht von der NV fraktion ;)

CB:

Zusätzlich wollen wir nochmals anhand zweier Ausschnitte aus den obigen Screenshots auf die Qualität der Schatten in Far Cry eingehen. So lässt sich beobachten, dass ATi-Karten (linkes/oberes Bild) - in diesem Falle eine Radeon 9800 XT - weitaus weichere Schatten zeichnet, als dies die GeForce 6800 Ultra (rechtes/unteres Bild) mit dem von uns verwendeten Treiber 61.45 (SM 3) tut. Wir hoffen, dass dieser Bug entweder im nächsten ForceWare-Treiber oder bis zum finalen Release des Patches behoben wird. Durch die verbesserte Darstellung der Schatten dürften auch keinerlei Performanceverluste eintreten, kann die Cry-Engine diese doch ohne große Anstrengungen rendern.
Umgekehrt hiesse es, dass der Shatten-bug auch keine Vorteile bringt.

Jesus

2004-07-25, 22:41:41

jo hoffen wir´s ;)

q@w

2004-07-26, 08:45:06

Der Xbit-Test ist komisch - je nach Level ist's entweder ziemlich ausgeglichen, mal liegt die XTPE 10% vorn, mal die 6800u - während die X800 Pro eher öfter von der GT geschlagen wird.

Aber das merkwürdige (und ein Argument, die Min-FPS nur über entweder mehrere Durchläufe zu mitteln oder sonstwie Ausreisser zu vermeiden) sind folgende Beispiele:

http://www.xbitlabs.com/images/video/farcry20b/pier_1600_pure.gif
(die minFPS der XTPE fallen graduell sogar unter das Level der GF6800 :bonk: )

http://www.xbitlabs.com/images/video/farcry20b/pier_1024_pure.gif
(die minFPS der XTPE sind zwar immer noch weit unter der 6800, aber zumindest konstant... WTF?)

http://www.xbitlabs.com/articles/video/display/farcry20b_10.html
(die minFPS sind gut geschüttelt, nicht gerührt)

http://www.xbitlabs.com/images/video/farcry20b/catacombs_1600_pure.gif
(die minFPS steigen auf beinahe das doppelte... WTF?)

Also die MinFPS-Angaben sind IMO mit Vorsicht zu genießen, da hier anscheinend nur wenige oder gar nur ein Durchlauf gemacht wurden und eventuell andere Faktoren, als Grafikkarte und CPU-Last dafür verantwortlich sind.

Zu guter Letzt:
http://www.xbitlabs.com/images/video/farcry20b/pier_1024_pure.gif

Also irgendwas ist da faul im Staate Dänemark - daß eine 6800 mit nur zwei dritteln der Füllrate einer XTPE diese schlägt, scheint IMO zumindest in Far Cry kaum möglich - zumal XBit selbst schreiben, daß "[...]geometry instancing does not provide huge speed benefit on this level. As a result, it is no surprise that the GeForce 6800 family of graphics processors continues to outperform rivalling RADEON X800 XT and RADEON X800 PRO along with the former champion RADEON 9800 XT."

:gruebel:

q@w

2004-07-26, 08:46:29

Quatsch, sind natürlich nur 47% der Füllrate einer XTPE... :bonk:

Gast

2004-07-26, 09:18:19

Hallo,

also diese Benchmarkergebnise sind der letzte Dreck,habe selbst mal einen Test durchgeführt mit ähnlicher Config. und bekommen weitaus bessere Werte,die Werte die schauen so aus als ob bei ATi AA/AF angeblieben ist und bei Nvidia es aus ist!!!

mfg

tombman

2004-07-26, 09:23:34

Original geschrieben von q@w
Quatsch, sind natürlich nur 47% der Füllrate einer XTPE... :bonk:

das Bild is unwichtig, viel geiler ist maximale Last mit extreme geometry auf 1600x1200.

EXTREME GEOMETRY
http://www.xbitlabs.com/images/video/farcry20b/pierhigh_1600_pure.gif

Und da ownt die X800XTPE alles weg -- oder soll 1024x768 ohne alles mit wenig Geometrie die Traumeinstellung für 6800ultra sein? :grübel: :lolaway:

Und ich bin gespannt, welche Werte rauskommen, wenn xbit-labs updated und AA/AF Werte hinzufügt ;)

LovesuckZ

2004-07-26, 09:36:30

Original geschrieben von tombman
Und da ownt die X800XTPE alles weg -- oder soll 1024x768 ohne alles mit wenig Geometrie die Traumeinstellung für 6800ultra sein? :grübel: :lolaway:

"Ownt"?
Rofl, nichtmal 30% schneller als 6800Ultra unter Verwendung des loosa Hacks und sowas von ineffizient.
Achja, Werte mit AF wollen wir ja nicht, soll ja fair bleiben!

/edit: Irgendwie lustig, dass ploetzlich so gut ueber OI gesprochen wird, wurde es doch noch letzte Woche mit den Toschlagargument "SM3.0 ist in naeherer Zukunft nutzlos" abgestempelt.
Aber das kennen wir von ATi usern, nichts neues...

Seraf

2004-07-26, 09:50:58

Toller Test.
Alle Optimierungen bei deiden Herstellern an.
Wer holt eigentlich mit der Optimiererei mehr raus. ATI oder NV?

Unoptimierte Benchmarks von NV u. ATI wären imho interessanter.

reunion

2004-07-26, 09:51:04

Original geschrieben von q@w
Zu guter Letzt:
http://www.xbitlabs.com/images/video/farcry20b/pier_1024_pure.gif

Also irgendwas ist da faul im Staate Dänemark - daß eine 6800 mit nur zwei dritteln der Füllrate einer XTPE diese schlägt, scheint IMO zumindest in Far Cry kaum möglich - zumal XBit selbst schreiben, daß "[...]geometry instancing does not provide huge speed benefit on this level. As a result, it is no surprise that the GeForce 6800 family of graphics processors continues to outperform rivalling RADEON X800 XT and RADEON X800 PRO along with the former champion RADEON 9800 XT."

:gruebel:

Jap, irgendetwas muss da faul sein, da sich die X800XT troz deutlich mehr Füllrate überhaupt nicht absetzten kann von der X800pro. Das würde klar auf einen CPU limitierung schließen wenn die NV40 riege da nicht noch um einiges schneller wäre!?

//Edit: Der Test ist überhaupt etwas seltsam, warum wird da total auf Qualitätsfeatures verzichtet?

Seraf

2004-07-26, 10:02:13

Original geschrieben von reunion
Jap, irgendetwas muss da faul sein, da sich die X800XT troz deutlich mehr Füllrate überhaupt nicht absetzten kann von der X800pro. Das würde klar auf einen CPU limitierung schließen wenn die NV40 riege da nicht noch um einiges schneller wäre!?

//Edit: Der Test ist überhaupt etwas seltsam, warum wird da total auf Qualitätsfeatures verzichtet?

Es stellt sich anscheinend wiedereinmal die höhere CPU-Lastigkeit der ATI Karten heraus.

Demirug

2004-07-26, 10:07:23

Ich weiss ja nicht genau wie da gebencht wurde aber mir selbst ist bei den neuen Pfaden von Farcry aufgefallen das diese zur Laufzeit Shader nachladen wenn sie zum ersten mal gebraucht werden.

Das bedeutet auch das man dann den Overhead für das Compileren der Shader im Treiber drin hat. Bei B3d war vor einiger Zeit jemand von ATI nicht sonderlich begeistert von der Idee Shader im Hauptloop nachzuladen.

Vielleicht brauchen wir mal einen Benchmark für die "Treiber-Shader-Compiler" Performance. Denn HL2/Source scheint auch einen Hang dazu zu haben Shader zur Laufzeit nachzuschieben.

Exxtreme

2004-07-26, 10:07:26

Original geschrieben von Seraf
Es stellt sich anscheinend wiedereinmal die höhere CPU-Lastigkeit der ATI Karten heraus.
Kann aber auch andere Gründe haben. Demirug meinte, daß der Speichercontroller der X800-Serie nicht ganz so effizient sei.

Demirug

2004-07-26, 10:14:42

Original geschrieben von Exxtreme
Kann aber auch andere Gründe haben. Demirug meinte, daß der Speichercontroller der X800-Serie nicht ganz so effizient sei.

Das mit dem Speicherkontroller war ein Verdacht aus der Erkenntniss das der R420 massive Probleme beim Umsetzten der vorhanden Füllrate in nutzbare Füllrate hat. Wobei das bei der Pro wesentlich schlimmer als bei der XT ist. Wenn also Pro und XT in etwa gleich liegen muss die bremse eher auf der CPU Seite zu suchen sein.

Ich bin leider mit dem Anforderungsprofil der besagten Pier Demo nicht sonderlich vertraut. Möglicherweise wäre es bei diesen Benchmarks interesant einen Balken hinzuzufügen was die CPU ohne Grafikkarte erreichen würde. Dann wüsste man zumindestens welche zusätzliche Last der Treiber verursacht.

TheCounter

2004-07-26, 10:23:29

Hmm, also ich glaube eher die haben das ganze nur 1 mal durchlaufen lassen. Wirkliche Ergebnisse bekommt man nur wenn man es min. 2-3 mal durchlaufen lässt. Ich lass es bei mir sogar immer 4 mal durchlaufen, da beim ersten Test komplett andere Test rauskommen. Selbst Crytek empfielt die Benches immer mehrmals durchlaufen zu lassen.

Um das ganze mal aufzuzeigen an einem Beispiel von einem meiner Tests:

==============================================================
TimeDemo Play Started , (Total Frames: 1512, Recorded Time: 46.65s) | 1024x768; Max. Details; 0xAA/0xAF; w/o DXTweaker
!TimeDemo Run 0 Finished.
Play Time: 38.44s, Average FPS: 39.33
Min FPS: 28.99 at frame 449, Max FPS: 63.18 at frame 727
Average Tri/Sec: 1796785, Tri/Frame: 45685
Recorded/Played Tris ratio: 0.93
!TimeDemo Run 1 Finished.
Play Time: 30.78s, Average FPS: 49.12
Min FPS: 28.99 at frame 449, Max FPS: 63.18 at frame 727
Average Tri/Sec: 2253958, Tri/Frame: 45891
Recorded/Played Tris ratio: 0.93
!TimeDemo Run 2 Finished.
Play Time: 30.91s, Average FPS: 48.91
Min FPS: 28.99 at frame 449, Max FPS: 63.18 at frame 727
Average Tri/Sec: 2248146, Tri/Frame: 45962
Recorded/Played Tris ratio: 0.92
!TimeDemo Run 3 Finished.
Play Time: 30.86s, Average FPS: 48.99
Min FPS: 28.99 at frame 449, Max FPS: 63.18 at frame 727
Average Tri/Sec: 2246937, Tri/Frame: 45866
Recorded/Played Tris ratio: 0.93
TimeDemo Play Ended, (4 Runs Performed)
==============================================================

Hmm... :???:

Oder es liegt wirklich an der CPU-Limitierung? Komisch die ganze Sache...

Demirug

2004-07-26, 10:39:27

Den ersten Durchlauf kann man grundsätzlich vergessen weil da immer noch Sachen nachgeladen werden. Da könnte sogar die Festplatte noch eine Rolle spielen. Wobei ich mir nicht ganz sicher bin weil bei meinen bisherigen System Farcry nicht vollständig in den Speicher gepasst hat. Ich weiss also nicht ob er nur was aus dem Swapfile oder wirklich zusätzliche Daten von der Platte geholt hat.

tRpii

2004-07-26, 10:39:49

Original geschrieben von LovesuckZ
"Ownt"?
Rofl, nichtmal 30% schneller als 6800Ultra unter Verwendung des loosa Hacks und sowas von ineffizient.
Achja, Werte mit AF wollen wir ja nicht, soll ja fair bleiben!

/edit: Irgendwie lustig, dass ploetzlich so gut ueber OI gesprochen wird, wurde es doch noch letzte Woche mit den Toschlagargument "SM3.0 ist in naeherer Zukunft nutzlos" abgestempelt.
Aber das kennen wir von ATi usern, nichts neues...

das fällt unter der rubrik "nice to have" und die Performancesteigerung mit diesem sogenannten "Hack" ist dennoch nicht zu verachten und irgendwie wird dies nun einige 6800 User eher ärgern da wenn ATi nun alles richtig anstellt die von NV so hochgelobten Eigenschaften wenigstens im Ansatz gleichwertig "verarbeiten" (wie auch immer) kann.

ATi User freuen sich und NV User machen eher das Gegenteil.

LovesuckZ

2004-07-26, 10:50:43

tRpii,
es spricht nichts dagegen, dass ATi OI einsetzt. Doch dafuer haetten Sie eben auch eine SM3.0 faehige Hardware fuer DX bauen muessen. Jetzt benutzen Sie Hacks, um die Designentscheidung zu umgehen.
Ansonsten, nur dank Nvidia haben die ATi user OI, oder warum vermarktet man es erst 2 Jahre nach dem Erscheinen des r300? Davon abgesehen, dass sie es nicht geschafft haben OI fuer MS schmackhaft zu machen in dieser Zeit, dass es sie es auch unter SM2.x verwenden koennen.
Dazu kommt, dass ploetzlich OI als das neue Feature gefeiert wird, vornehmlich von ATi usern, die sich noch letzte Woche gegen SM3.0 und damit auch gegen OI ausgesprochen haben. Nun kannst du mir das erklaeren?
Was ATi mit OI macht, sollte fuer MS untragbar sein. Ansonsten muessten sie DX oeffnen bzw. offiziell den Herstellern die Moeglichkeit geben eigene Feature selbst einzubinden. Das tun sie aber nach meinem Wissen nicht.
Und ATi muss sich, wie Nvidia an solche Designentscheidungen halten. Waere ja schoen, wenn jeder das macht, was er will...

Demirug

2004-07-26, 10:51:06

Original geschrieben von tRpii
das fällt unter der rubrik "nice to have" und die Performancesteigerung mit diesem sogenannten "Hack" ist dennoch nicht zu verachten und irgendwie wird dies nun einige 6800 User eher ärgern da wenn ATi nun alles richtig anstellt die von NV so hochgelobten Eigenschaften wenigstens im Ansatz gleichwertig "verarbeiten" (wie auch immer) kann.

ATi User freuen sich und NV User machen eher das Gegenteil.

Bei den Usern dürfte die freude eher davon abhängen welche Karte sie haben und weniger von wem sie kommt.

R420 :)
NV4X :)
R300 :(
NV3X :(

Bei echten Fanboys sieht das wahrscheinlich anders aus.

Der OI Hack von ATI ist aus Entwicklersicht ärgerlich und ich würde wirklich gerne wissen ob ATI da gepennt hat oder MS auf keinen Fall ein Capsbit dafür haben wollte. Da DX aber im allgemeinen für fast alles Capsbits hat glaube ich das ATI da geschlafen hat. Alternativ wäre es auch möglich das diese Entscheidung das es kein Capsbit für OI gibt gefallen ist als alle IHV davon ausgingen das sie OI erst mit SM3 Hardware bringen aber dort auf jeden Fall. In diesem Fall macht es natürlich Sinn dafür kein Extra Capsbit zu benutzten.

Mich würde es ehrlich gesagt nicht wundern das wenn ATI das OI wirklich auch für den R3XX bringt nVidia uns das ganze auch noch für den NV3X zeigen wird.