DoomIIIs Ausnutzung von GPU-Features

[Radeonator]

Das klingt ja fast so wie beim good old Q3.
"So hat man bisher drei Hardware-spezifische Backends zur Ausnutzung der erweiterten Hardware-Fähigkeiten einzelner Grafik-Chips geschrieben"
Sprich von diesem Spiel hat anscheinend jede GPU etwas und vielleicht werden wieder Features eingebracht, die jahre Später ausgenutzt werden können...was meint ihr???

Quelle:News 3d-center ;)

[nggalai]

*ins richtige Forum verschieb*

ta,
-Sascha.rb

[Demirug]

So hat man bisher drei Hardware-spezifische Backends zur Ausnutzung der erweiterten Hardware-Fähigkeiten einzelner Grafik-Chips geschrieben

Das ist eine schöne umschreibung. Übersetzt heist das:

Da wir mit standard OpenGL leidern nicht in der lage waren die Features die wir zum ereichen der gewüschten visuellen Effekte brauchen anzusprechen müssen wir für jede Kartenserie ein eigenes Backend schreiben. Bisher haben wir das für 3 Kartentypen gemacht. Wer nicht im Besitzt einer entsprechende Karte ist hat eben Pech. Auch wenn die Karte eigentlich in der lage wäre die Effekte darzustellen bekommt man nur das mit standard OpenGL mögliche zu sehen und das wir dann leider nicht das Bild sein welches man hinten auf der Verpackung oder in den vielen shoots im Internet sieht.

[KingLouis]

Ich hoffe das bis zum neuen Projekt von JC OpenGL 2.0 da ist. Das hat doch auch eine HLSL, odeR?

[Demirug]

Originally posted by KingLouis
Ich hoffe das bis zum neuen Projekt von JC OpenGL 2.0 da ist. Das hat doch auch eine HLSL, odeR?

Ja in OpenGL 2.0 sollen die Vertex und Fragmentpipeline vollständig über eine Hochsprache programmiert werden

[nggalai]

Hi Demiurg,Originally posted by Demirug


Das ist eine schöne umschreibung. Übersetzt heist das:

Da wir mit standard OpenGL leidern nicht in der lage waren die Features die wir zum ereichen der gewüschten visuellen Effekte brauchen anzusprechen müssen wir für jede Kartenserie ein eigenes Backend schreiben. Bisher haben wir das für 3 Kartentypen gemacht. Wer nicht im Besitzt einer entsprechende Karte ist hat eben Pech. Auch wenn die Karte eigentlich in der lage wäre die Effekte darzustellen bekommt man nur das mit standard OpenGL mögliche zu sehen und das wir dann leider nicht das Bild sein welches man hinten auf der Verpackung oder in den vielen shoots im Internet sieht. ;D

gut getroffen! *unterschreib*

DooM3 wird auf jedem Backend (fast) gleich aussehen, schlussendlich. Momentan sind's deren drei: der "standard OpenGL" Pfad (offenbar manchmal ohne specular map, muss mal die quote suchen) für Radeon, NV1x, Kyro, Matrox etc.; der NV2x-Pfad, plus der Radeon8500/9700er Pfad.

Ob Carmack darüber hinaus in der ENGINE auch zusätzliche Effekte zulassen wird, wird wohl nur die Zeit zeigen. DooM3 auf alle Fälle wird sowas nicht haben.

ta,
-Sascha.rb

[HOT]

Deshalb find ich die news so schwachsinnig - Carmack würde niemals eine M$ Sprache benutzen. genausowenig wie eine Sprache eine HW Herstellers. Er wird viel eher OpenGL 2.0 nutzen.

[Demirug]

Originally posted by HOT
Deshalb find ich die news so schwachsinnig - Carmack würde niemals eine M$ Sprache benutzen. genausowenig wie eine Sprache eine HW Herstellers. Er wird viel eher OpenGL 2.0 nutzen.

Das geht jetzt zwar schon wieder schwer ins offtopic.

Im bezug auf den aktuellen stand bei den Shaderhochsprachen gilt folgendes:

NVIDIAs Cg und MS HLSL benutzt die gleiche syntax.

Einem OpenGL gremium liegen AFAIK im Moment zwei Vorschläge für die Hochsprache von OpenGL 2.0 vor. Einer von 3dlabs und einer von NVIDIA/MS. Mann könnte sich dort aber auch für etwas ganz anderes entschliessen.

IMHO wäre es das beste wenn OpenGL 2.0 die NVIDIA/MS Hochsprache benutzen würde. Damit wäre eine Austauschbarkeit der Schaderprogramme zwischen DX und OpenGL ohne probleme möglich.

[tEd]

er hat 6 backends das hat er an der quakecon2002 gesagt:

standart->r100,matrox parhelia,sis
nv10/nv15(gf1,gf2)
nv20/25(gf3,gf4)
nv30
r200,r300(r8500,r9000,r9500,r9700)
3dlabs (p10)

je nachdem gibt es noch einen speziellen für die matrox parhelia

[RadioactiveMan]

Nur 3 Backends für Doom3?? Und Linux und MacOSX Freund Carmack soll mit M$ DX9 HLSL liebäugeln, aber von Hersteller-spezifischen Sprachen wie ATi´s RenderMonkey(?!) Abstand nehmen?

Dass selbst aths`s Grafikexperten hier nicht einen klaren Einspruch erheben, macht mich nachdenklich.

Um beim Thema zu bleiben, ein spezielles P10 Backend gibt es nicht, der Chip bzw. dessen Treiber unterstützt neben dem OGL2 Backend, den "NV10 register combiner"- sowie ARB_ extension(OGL1.x ohne specular highlights)-Codepath. Womit wir schon 3 Backends voll hätten, so ganz kann also die 3dcenter Meldung nicht stimmen.
Natürlich hat Carmack auch noch einen NV20 Codepath für Doom3, angeblich sogar einen für NV30(zumindest hört man das von der QuakeCon).
Einen extra Path für die R300 hat Carmack anscheinend nicht entwickelt, die PS 1.4 der R200 sind schon perfekt für Doom3.

Besonders von den einzelnen Backends profitieren die NVIDIOTS, im Gegensatz zu DX läßt sich die HW unter OpenGL viel besser ansprechen, die Register Combiner der NV10/20 können so voll genutzt werden, DX 8.1 PS 1.1-1.3 sind nur faule Kompromisse gegenüber anderen IHVs.

[nggalai]

Hi tEd,Originally posted by tEd
er hat 6 backends das hat er an der quakecon2002 gesagt:

standart->r100,matrox parhelia,sis
nv10/nv15(gf1,gf2)
nv20/25(gf3,gf4)
nv30
r200,r300(r8500,r9000,r9500,r9700)
3dlabs (p10)

je nachdem gibt es noch einen speziellen für die matrox parhelia Cool, danke für die Info. Ich hab' das Interview noch nicht durchgehört.

Dass ein P10/OGL2 backend kommen soll hab' ich gewusst, nicht aber, dass das Ding schon steht. Geil. :D Dass NV1x einen eigenen Pfad erhalten hat erstaunt mich ein wenig. Edit: Ah, ok, DAS wäre also das mit den specular highlights. OK. eigenes Backend. macht Sinn.

ta,
-Sascha.rb

[Radeonator]

Ich fand es bei Q3 z.B. faszinierend, das selbst erst später existierende Features(Simd, allgemeine GPU und andere) z.B. Surround gaming, dual Prozzi Unterstützung etc. bereits implementiert bzw. machbar waren/sind. Wenn DIII nun in diese Riege schlägt, wird das Game wohl frühestens 1Jahr nach erscheinen so aussehen, wie auf der Verpackung ;)

[aths]

Originally posted by nggalai
Dass NV1x einen eigenen Pfad erhalten hat erstaunt mich ein wenig.Wieso denn das? Da kann JC immerhin Register Combiner nutzen.

[Quasar]

Originally posted by Radeonator
Ich fand es bei Q3 z.B. faszinierend, das selbst erst später existierende Features(Simd, allgemeine GPU und andere) z.B. Surround gaming, dual Prozzi Unterstützung etc. bereits implementiert bzw. machbar waren/sind. Wenn DIII nun in diese Riege schlägt, wird das Game wohl frühestens 1Jahr nach erscheinen so aussehen, wie auf der Verpackung ;)

Häh? Das meiste davon (SIMD, SMP, GPU und Surround-Gaming) werden per Treiber ermöglicht, bzw. sind (im Falle von SMP) nativ in OpenGL enthalten.

Quake3 hat da nur den Vorteil der API, sonst nix. Wenn andere OpenGL Games das nicht haben/können, ist das imo eher eine bewusste Einschränkung der Programmierer oder (in vielen Fällen, ebenfalls imo) auf die ursprüngliche Auslegung des Games auf Glide zurückzuführen.

[Pitchfork]

Originally posted by aths
Wieso denn das? Da kann JC immerhin Register Combiner nutzen.

Genauer gesagt für Specular Highlights muß er es sogar. Es gibt zwei Möglichkeiten für Specular Highlights:

1. Dependant Texture Read: Also ab Pixel Shader Hardware.
2. Einen vorberechneten Wert im Shader mehrfach mit sich selbst multiplizieren. Das geht aber nur mit Zugriff auf Chip internas wie Register Combiner und Final Combiner. Das ganze ist auch unter DX über deren TSS Setup nur sehr schwer zu erreichen und deshalb wird es unter DX mit GF1/2/4mx in der Regel einfach nicht gemacht.

Er kann also unter OpenGL Specular Highlights nur unter Zugriff auf Hersteller Extension machen, also Fragment Shader oder Register Combiner. Also ein eigenes Backend für nv1x.

Pitchfork

[tEd]

was noch so toll ist in doom3 ist das jeder die geschwindigkeit selber bestimmen kann. Bei dir läuft doom3 zu langsam? nun puste einfache alle Lichter aus dann sollte es wieder ordentlich flutschen ;D

[nggalai]

Hi aths,Originally posted by aths
Wieso denn das? Da kann JC immerhin Register Combiner nutzen. eben--wie oben noch im edit erwähnt, ist mir da auch noch der Groschen gefallen. Ich konnte mich (mangels der Doku, die deine Sig ziert ;) ) nur noch düster an was mit "gibt was ohne specular highlights" erinnern, und hab' dann für mich den Standard- mit dem NV1x Pfad kombiniert/gleichgesetzt. ?-)

Aber jetzt ist's klar. Und auch dank an Pitchfork für die weiteren Erläuterungen. :)

ta,
-Sascha.rb

[Börk]

Was mich wundert, warum kriegt der NV30 einen eigenen Pfad und der R300 nicht??
Vielleicht weil der NV30 dann auch Pixelshader 1.4 unterstützt, weil Pixelshader 2.0 wirds ja noch net in DOOM3 geben.

[Demirug]

Originally posted by burk23
Was mich wundert, warum kriegt der NV30 einen eigenen Pfad und der R300 nicht??
Vielleicht weil der NV30 dann auch Pixelshader 1.4 unterstützt, weil Pixelshader 2.0 wirds ja noch net in DOOM3 geben.

OpenGL = nix Pixelshader
OpenGL = Hersteller spezifische Extensions

Der R300 braucht primär keinen eigenen Pfad da bereits der R200 alle für DOOM 3 benötigten Effekte in einem Pass rendern kann.

Die NV2x Chips benötigten aber 2-3 Passes für einen Effekt

Bei NV30 läst sich das auch in eienem Pass erledigen.


eigener Pfad für R300 bringt keinen (ok möglicherweise einen minimalen) geschwindkeitsgewinn.

eigner Pfad für NV30 dürfte zum einen wessentlich schneller und optisch besser als der NV2x pfad sein.

[Pitchfork]

Originally posted by burk23
Was mich wundert, warum kriegt der NV30 einen eigenen Pfad und der R300 nicht??
Vielleicht weil der NV30 dann auch Pixelshader 1.4 unterstützt, weil Pixelshader 2.0 wirds ja noch net in DOOM3 geben.

Yep. Das Doom3 Beleuchtungsmodell kann bei der Radeon Familie ab der R200 in einem Pass gerendert werden. Bei Geforce geht das erst ab nv30. Ein neues Backend für die R300 lohnt sich also erst, wenn dadurch auch neue Effekte oder Beleuchtungsmodelle möglich werden. Solange sich aber visuell nix ändern tut, ist der Aufwand bei der R300 überflüssig, während man bei dem Backend für die nv30 Passes einspart und damit extra Performance holt.

Und mit DX wäre das alles nicht passiert, dann hätte man nur 3 Backends schreiben müssen: Texture Stages (entspricht OpenGL pur), ps1.1 und ps1.4. Und zwei von drei Backends würden einen fast identischen C++ Code fahren können.

Pitchfork

[tEd]

[SIZE=1]Originally posted by Pitchfork


Yep. Das Doom3 Beleuchtungsmodell kann bei der Radeon Familie ab der R200 in einem Pass gerendert werden. Bei Geforce geht das erst ab nv30. Ein neues Backend für die R300 lohnt sich also erst, wenn dadurch auch neue Effekte oder Beleuchtungsmodelle möglich werden. Solange sich aber visuell nix ändern tut, ist der Aufwand bei der R300 überflüssig, während man bei dem Backend für die nv30 Passes einspart und damit extra Performance holt.

Es gab von john carmack schon ein hinweis auf der quakecon2002 das wohl die r9700 noch weitere optimierungen erfahren wird. Obwohl zwar die radeon8500 für die beleuchtungsberechnungen nur 1pass braucht ist das ja nur für ein licht und j.c rechnet durchschnittlich mit 2lichtern/oberfläche teilweise vielleicht sogar noch mehr darum könnte man für die r9700 und nv30 noch optimierungen machen bei welchen die karten dann mehrere lichter in einem pass rendern können und somit noch ein bisschen geschwindigkeitsgewinn herausholen kann.

im übrigen wurde auch in einem interview erwähnt das es vielleicht kein demo geben wird jedenfalls nicht unbedingt bevor doom3 released wird

:-(

[FormatC]

Keine Demo, oder kein "Doom3-Test" ?

[tEd]

Originally posted by FormatC
Keine Demo, oder kein "Doom3-Test" ?

doch aber es ist noch nicht sicher ob bevor oder nachdem doom fertig ist.

hier ein interview:
http://www.gamespy.com/articles/august02/quakecon2002/id/

[Pitchfork]

Originally posted by tEd


Es gab von john carmack schon ein hinweis auf der quakecon2002 das wohl die r9700 noch weitere optimierungen erfahren wird. Obwohl zwar die radeon8500 für die beleuchtungsberechnungen nur 1pass braucht ist das ja nur für ein licht und j.c rechnet durchschnittlich mit 2lichtern/oberfläche teilweise vielleicht sogar noch mehr darum könnte man für die r9700 und nv30 noch optimierungen machen bei welchen die karten dann mehrere lichter in einem pass rendern können und somit noch ein bisschen geschwindigkeitsgewinn herausholen kann.


Kann ich mir ehrlich gesagt schlecht vorstellen, da er pro Lichtquelle erst alle Schattenvolumen, die diese Lichtquelle erzeugt in den Stencilbuffer rendern muß, und dann alle Geometie, die potentiell von dieser Lichtquelle beleuchtet wird. Zwei Lichtquellen haben zwei verschiedene Schattenvolumensets, ohne Tricks wird das schwierig.... naja, er ist JC und ich nicht. Bin aber gespannt, ob er das machen kann und wie.

Pitchfork

[Demirug]

Ja aufgrund der Stencilschatten wird das nicht einfach. Aber mit den neuen möglichkeiten im Fragmentbereich läst sich da möglicherweise was drehen. Allerdings vermute ich das die Technik jedes Licht einzeln zu rendern so hoch in der Engine eingebaut ist das man es nicht für den NV30 und R300 einfach mal schnell ändern könnte.

[tEd]

Originally posted by Pitchfork


Kann ich mir ehrlich gesagt schlecht vorstellen, da er pro Lichtquelle erst alle Schattenvolumen, die diese Lichtquelle erzeugt in den Stencilbuffer rendern muß, und dann alle Geometie, die potentiell von dieser Lichtquelle beleuchtet wird. Zwei Lichtquellen haben zwei verschiedene Schattenvolumensets, ohne Tricks wird das schwierig.... naja, er ist JC und ich nicht. Bin aber gespannt, ob er das machen kann und wie.

Pitchfork

nun ich hab mich zuerst auch gewundert ob das mit der doom3 engine überhaupt geht (mehrere ppl/pass). ein paar typen im beyon3d forum haben mir gesagt das es gehen sollte .

[Leonidas]

Originally posted by nggalai
Hi Demiurg,;D

gut getroffen! *unterschreib*

DooM3 wird auf jedem Backend (fast) gleich aussehen, schlussendlich. Momentan sind's deren drei: der "standard OpenGL" Pfad (offenbar manchmal ohne specular map, muss mal die quote suchen) für Radeon, NV1x, Kyro, Matrox etc.; der NV2x-Pfad, plus der Radeon8500/9700er Pfad.




So gesehen vier: Du hast das 3Dlabs-Backend vergessen.


Und das mit den drei Backends für spezielle Hardware + default-Backend ist eine eben erst getroffenen Original-Aussage von J.C. Ich kann derzeit also keine 6 Backend nachvollziehen.

[tEd]

6backends wie ich geschrieben habe, das kommt übrigens direkt von seiner quakecon2002 rede etwa bei minute 19, die kann man glaube ich irgendwo runterladen weiss aber nicht mehr wo.

[Unregistered]

Originally posted by Demirug


Das geht jetzt zwar schon wieder schwer ins offtopic.

Im bezug auf den aktuellen stand bei den Shaderhochsprachen gilt folgendes:

NVIDIAs Cg und MS HLSL benutzt die gleiche syntax.

Einem OpenGL gremium liegen AFAIK im Moment zwei Vorschläge für die Hochsprache von OpenGL 2.0 vor. Einer von 3dlabs und einer von NVIDIA/MS. Mann könnte sich dort aber auch für etwas ganz anderes entschliessen.

IMHO wäre es das beste wenn OpenGL 2.0 die NVIDIA/MS Hochsprache benutzen würde. Damit wäre eine Austauschbarkeit der Schaderprogramme zwischen DX und OpenGL ohne probleme möglich.


Wäre natürlich klasse wenn das passiert, aber leider ist es nur ein flüchtiger Traum.

MS wird es niemals zulassen, das man für OpenGL und DirektX nur eine HLSL benutzen muss (deshalb sind sie sehr wahrscheinlich wegen Cg ziemlich aufgebracht).

Sie würden dann ja alle Vorteile gegenüber Apple (OpenBSD) und Linux verlieren. Es wäre dann ja möglich viele oder gar alle Spiele schnell zu portieren womit ein Hauptvorteil von Windows verloren geht.

[Exxtreme]

Originally posted by Unregistered
Sie würden dann ja alle Vorteile gegenüber Apple (OpenBSD) und Linux verlieren. Es wäre dann ja möglich viele oder gar alle Spiele schnell zu portieren womit ein Hauptvorteil von Windows verloren geht.
Full Ack!
Die Freaks würden sofort zu Linux abwandern. Die Games sind für Viele noch der einzige Grund bei Windows zu bleiben.

Gruß
Alex

[ow]

Originally posted by Unregistered


Sie würden dann ja alle Vorteile gegenüber Apple (OpenBSD) und Linux verlieren. Es wäre dann ja möglich viele oder gar alle Spiele schnell zu portieren womit ein Hauptvorteil von Windows verloren geht.


OGL ist seit jeher ein komplett OS-unabhängiges APi.
Für die Portierung bringt Cg also gar nichts.

[ow]

Originally posted by Exxtreme

Full Ack!
Die Freaks würden sofort zu Linux abwandern. Die Games sind für Viele noch der einzige Grund bei Windows zu bleiben.

Gruß
Alex


Und du stimmst da auch noch zu? :nono: ;);)