doom3 engine und radeon8500:)

[alex_x]

hi


in den 3dcenter news steht das die doom3 engine die radeon8500 bevorzugt!:)wegen dem pixel shader 1.4 und den 6texturen!was meint ihr?bringen die 2 features viel mehr???



gruß:Alex

[Exxtreme]

Laut J.C. kann die R8500 11 Texturzugriffe in einem Pass ausführen und das gefällt J.C. so an der Karte. Die R8500 könnte somit mehr fps bei Doom3 schaffen als eine GF4Tixxx denn Speicherzugriffe kosten Performance. Die GF4Tixxx wird mehrere Passes brauchen um die Spielegrafik darzustellen. Wie es sich aber auf die Performance tatsächlich auswirkt, steht in den Sternen.

Gruß
Alex

P.S. Auch J.C. hat anscheinend die Bekanntschaft mit dem "High-Polygon-Bug" gemacht.

[Liszca]

Originally posted by Exxtreme
Auch J.C. hat anscheinend die Bekanntschaft mit dem "High-Polygon-Bug" gemacht.

Was ist das für ein bug? (ein käfer ???)

[Exxtreme]

Originally posted by Liszca


Was ist das für ein bug? (ein käfer ???)
Vieeel schlimmer ;)
Im Ernst. Dieser Bug tritt auf, wenn die Polygonmenge eine "krittische Masse" erreicht. Mit dem GLExcess-Bench kann man es am Besten reproduzieren. In der Szene 6 brechen die Frameraten extrem ein wenn so ein glänzendes Raumschiff verbeifliegt. Ist das Schiff weg, läuft alles wieder wie gewohnt.
Du kannst auch im Rage3D-Forum nachschauen. Dort flennen die deswegen schon seit längerem rum.

Gruß
Alex

[Liszca]

Kann es sein das sich die karte mit irgendwelchen environment texturen schwer tut?

[Exxtreme]

Originally posted by Liszca
Kann es sein das sich die karte mit irgendwelchen environment texturen schwer tut?
Nein, denn bei MOH und SS:SE tritt dieser Fehler ebenfalls auf. Übrigens D3D ist nicht betroffen.

Gruß
Alex

[Liszca]

Originally posted by Exxtreme

...Übrigens D3D ist nicht betroffen.

Gruß
Alex

Dann behaupte ich mal es liegt am schlechten treiber oder?

[Unregistered]

wollen wir mal schwer hoffen , denn im j.c artikel spricht er über sehr gute leistungen der radeon 8500 auf dem papier , die jedoch in game nie erreicht werden . es könnte sich um einen fehler handeln , der möglicherweise nicht in der aktuellen grakageneration behoben werden kann... ich hab meine 8500 erst knapp ein monat , und wenn dies wirklich ein hardware fehler ist , lege ich ati nahe sich schon mal warm anzuziehen ... ;). ich bin sehr enttäuscht das seitens ati kein kommentar zu dem fehler abgegeben wird. doch bestimmt wird alles gut , ich finde es nur sehr schlecht gute kunden in der unwissenheit tappen zu lassen .

[Liszca]

Meinst du wirklich die kümmern sich darum?

[Exxtreme]

Originally posted by Liszca
Meinst du wirklich die kümmern sich darum?

Laut david (aus dem Rage3D-Forum) ist der Fehler bei ATI bekannt und wird in den nächsten Treibern behoben sein.

Gruß
Alex

[Liszca]

Interessant, aber die rücken natürlich auch nicht raus woran es genau liegt oder?

[Exxtreme]

Originally posted by Liszca
Interessant, aber die rücken natürlich auch nicht raus woran es genau liegt oder?
Es gibt Anzeichen woran das liegt. Und zwar kann man bei SS:SE diesen Fehler umgehen indem man Shadowmaps-Caching einschaltet. So wie es aussieht liegt es irgendwie am Texturmanagement des Treibers, das durcheinander kommt, wenn sehr viele Polygone dargestellt werden.


Gruß
Alex

[Exxtreme]

Nachtrag: Der "High-Poly-Bug" ist gefixt.
NitroGL (Einer aus dem Rage3D-Forum) hat neue Betas bekommen, in denen das Problem nicht mehr auftritt - siehe hier (http://www.rage3d.com/board/showthread.php?s=&threadid=33604465&perpage=20&pagenumber=1).

Gruß
Alex

[Liszca]

Nur will er den ICD nicht rausbringen, und die tabelle sagt mir irgendwie nichts!

[Exxtreme]

Originally posted by Liszca
Nur will er den ICD nicht rausbringen, und die tabelle sagt mir irgendwie nichts!
Er DARF(!) den ICD nicht veröffentlichen, da er ein NDA unterschrieben hat. Es wäre quasi Vertragsbruch.

Zur Tabelle:
http://evilman00.multimania.com/glxs.gif
Die einzelnen Spalten stehen für jede Szene in dem Benchmark.
Nur die Szene 6 ist vom Bug betroffen. Mit dem "High-Poly-Bug" bekomme ich bei "MIN" ca. 30 fps - eben dann, wenn das glänzende Schiff vorbeifliegt. In der Tabelle stehen 122 fps - ohne Bug.

Gruß
Alex

[Liszca]

Wenn du mir nun noch sagst was ss:SE heisst verstehe ich dich vollständig, und wo wir schon dabei sind sag mir doch bitte was imho nochmal bedeutet! =)

[Xmas]

SS:SE = Serious Sam: Second Encounter
IMHO = in my humble opinion (meiner bescheidenen Meinung nach...)

[Exxtreme]

Originally posted by Liszca
Wenn du mir nun noch sagst was ss:SE heisst verstehe ich dich vollständig, und wo wir schon dabei sind sag mir doch bitte was imho nochmal bedeutet! =)
;)
Aaaalso, SS:SE bedeutet Serious Sam : Second Encounter und IMHO heisst In my humble Opinion, sprich "Meiner bescheidenen Meinung nach".

Gruß
Alex

[Liszca]

Danke!

[Exxtreme]

Originally posted by Liszca
Danke,
und wie funktioniert die Tabelle?

Also.
Der Benchmark hat 12 verschiedene Tests, auch Szenen genannt. Jede Spalte in der Tabelle steht für die Ergebnisse einer Szene. Die Spalte ganz links steht für die Szene 1, die nächste für Szene 2 usw. Jede Spalte enthält 3 Zeilen, in denen 3 Werte stehen. Die Beschreibung der Zeilen steht ganz links. Die Zeilen sind mit "MIN", "AVG" und "MAX" beschriftet. MIN steht für die kleinste Framerate, die gemessen wurde, AVG steht für die Durchschnittsframerate und MAX steht für die höchste Framerate, die in der Szene gemessen wurde. Die unterste Zeile, mit "Summaries" beschriftet, zeigt die Punkte, die in den Einzelbereich erreicht wurden.
Hoffe das hilft.

Gruß
Alex

[Liszca]

Ich habe es dann doch kapiert gehabt, und hatte es geedited (oder wie soll ich das schreiben) aber warum hast du noch meinen alten post?

[Exxtreme]

Originally posted by Liszca
Ich habe es dann doch kapiert gehabt, und hatte es geedited (oder wie soll ich das schreiben) aber warum hast du noch meinen alten post?
Weil ich auf "Quote" gedrückt habe, bevor du mit dem Editieren fertig warst. Wenn du auf "Quote" drückst, übernimmt das Forum den Text, der zu diesem Zeitpunkt drin steht.

Gruß
Alex

[ow]

Originally posted by Exxtreme

Vieeel schlimmer ;)
Im Ernst. Dieser Bug tritt auf, wenn die Polygonmenge eine "krittische Masse" erreicht. Mit dem GLExcess-Bench kann man es am Besten reproduzieren. In der Szene 6 brechen die Frameraten extrem ein wenn so ein glänzendes Raumschiff verbeifliegt. Ist das Schiff weg, läuft alles wieder wie gewohnt.
Du kannst auch im Rage3D-Forum nachschauen. Dort flennen die deswegen schon seit längerem rum.

Gruß
Alex


An der Polygonmasse des polygonarmen glexcess kann es nicht liegen.
Die Raumschiffszene bewaeltigt selbst mein Riva TNT problemlos.

[Exxtreme]

Originally posted by ow



An der Polygonmasse des polygonarmen glexcess kann es nicht liegen.
Die Raumschiffszene bewaeltigt selbst mein Riva TNT problemlos.
Sie hat auch diesen "Bug" nicht ;). So wie es aussieht, liegt es doch nicht an der Polygonmenge, sondern am Texturmanagement. Der "Bug" hat diesen Namen bekommen, weil in diesem Test die Polygonmenge sehr hoch ist und die Leute einen Zusammenhang damit asoziiert haben. Sobald eine bestimmte Konstellation auftritt, bricht die Performance schlagartig ein. Wie gesagt, der Fix dafür existiert, ist aber noch unter NDA und darf nicht veröffentlicht werden. Weitere Informationen stehen hier (http://www.rage3d.com/board/showthread.php?s=&threadid=33604465&perpage=20&pagenumber=1).

Gruß
Alex

[Pengo]

Originally posted by alex_x
hi


in den 3dcenter news steht das die doom3 engine die radeon8500 bevorzugt!:)wegen dem pixel shader 1.4 und den 6texturen!was meint ihr?bringen die 2 features viel mehr???



gruß:Alex

Wenn es in den 3DCenter News drin steht, heißt es noch lange nicht daß es stimmt.

PS 1.4 kann die Doom 3 Engine gar nicht bevorzugen, da es keine DirectX Engine ist.

Doom 3 wird sicherlich auf der Radeon 8500 sehr gut laufen, ob schneller als auf einer GF3 bleibt abzuwarten.

[Liszca]

Also du willst damit tatsächlich im ernst sagen das OpenGL die shader nicht ausseinander halten kann? Die Professionellste schnittstelle nach Glide?

[Liszca]

Übrigens OpenGL beherrscht schon seit 1.1 T&L! Dann könnt ihr euch ja denken welches die fortschritlicher schnittstelle ist (noch zur ergänzung OpenGL 1.1 gab es lange vor der GF 256!)

[Hamster]

Originally posted by Liszca
Also du willst damit tatsächlich im ernst sagen das OpenGL die shader nicht ausseinander halten kann? Die Professionellste schnittstelle nach Glide?


??? war glide nicht eine abwandlung der opengl schnittstelle??

[Xmas]

Originally posted by Hamster
??? war glide nicht eine abwandlung der opengl schnittstelle??
Nicht wirklich. Es gibt zwar Ähnlichkeiten, aber das ist bei APIs mit ähnlichem Zweck kaum verwunderlich.

Glide als "professionelle" Schnittstelle? Wohl kaum. Glide war nur für Spiele gedacht und sehr nah an der Hardware. Glide ist die spartanischste Schnittstelle, die wirklich praktisch nichts tut außer die Hardware zugänglich zu machen.

OpenGL 1.3 ist übrigens überhaupt nicht besonders "fortschrittlich". Aber dank der Extensions kann jedes Hardware-Feature angesprochen werden.

[ow]

Originally posted by Hamster



??? war glide nicht eine abwandlung der opengl schnittstelle??



Ja.

3dfx hat das OGLl-API komplett fuer ihre Zwecke (=Spiele) umgebaut und stark reduziert (kein 32Bit, keine hochaufloesenden Texturen, kein windowed-rendering,....).

Die komplette API Struktur von Glide hat nichts mehr mit der OGL-API-Struktur (ICD, MCD als Treiber) zu tun.

[ow]

Originally posted by Liszca
Übrigens OpenGL beherrscht schon seit 1.1 T&L! Dann könnt ihr euch ja denken welches die fortschritlicher schnittstelle ist (noch zur ergänzung OpenGL 1.1 gab es lange vor der GF 256!)



Ich denke T&L ist schon in der ersten offiziellen OGL-Spec (1.0/1992) enthalten.


Grakas mit T&L gibt es im Profi-Bereich seit mehr als 10Jahren. T&L ist dort praktisch Pflicht.

[TBird]

Originally posted by Liszca
Übrigens OpenGL beherrscht schon seit 1.1 T&L! Dann könnt ihr euch ja denken welches die fortschritlicher schnittstelle ist (noch zur ergänzung OpenGL 1.1 gab es lange vor der GF 256!)

Leider sieht das Microsoft ein wenig anders. ;)

[Doomtrain]

Originally posted by TBird


Leider sieht das Microsoft ein wenig anders. ;)

Wenn interessiert schon die Meinung von Microsoft???

[Xmas]

Originally posted by ow
3dfx hat das OGLl-API komplett fuer ihre Zwecke (=Spiele) umgebaut und stark reduziert (kein 32Bit, keine hochaufloesenden Texturen, kein windowed-rendering,....).

Die komplette API Struktur von Glide hat nichts mehr mit der OGL-API-Struktur (ICD, MCD als Treiber) zu tun.
In Glide ist kaum etwas wie in OpenGL, eine Abstammung ist wirklich nicht zu erkennen.
Allerdings konnte auch Glide (zumindest 3.x) im Fenster rendern, vorausgesetzt die Hardware konnte das auch.

[TBird]

Originally posted by Doomtrain


Wenn interessiert schon die Meinung von Microsoft???


Leider hat die Meinung Microsofts nicht auf OpenGL zu setzen sondern (wie sollte es auch anders sein) auf ihren eigenen hausgemachten Standard DX Auswirkungen auf die gesamte Spieleindustrie.

[ow]

Originally posted by Xmas

In Glide ist kaum etwas wie in OpenGL, eine Abstammung ist wirklich nicht zu erkennen.
Allerdings konnte auch Glide (zumindest 3.x) im Fenster rendern, vorausgesetzt die Hardware konnte das auch.


Wenn Glide nicht wie OGL ist, wie kann 3dfx dann einen OGL-Glide Wrapper als ICD anbieten??

Ausgangspunkt fuer die Glide-Entwicklung war OGL.

Die Struktur des Glide-API hat allerdings nichts mehr mit der von OGL (Server-Client) zu tun.

[Xmas]

Originally posted by ow
Wenn Glide nicht wie OGL ist, wie kann 3dfx dann einen OGL-Glide Wrapper als ICD anbieten??

Ausgangspunkt fuer die Glide-Entwicklung war OGL.

Die Struktur des Glide-API hat allerdings nichts mehr mit der von OGL (Server-Client) zu tun.
Es gibt auch OGL-D3D-Wrapper. ;)

Mag ja sein, dass OpenGL Ausgangspunkt für die Glide-API war, es programmiert sich aber einfach anders.

[Unregistered]

Glide war echt spitze, sehr einfach zu erlernen, sehr logisch und übersichtlich aufgebaut und praktisch kein Overhead.