Diskussion zum Matrox Parhelia Preview [Archiv] - Seite 2

HOT

2002-05-19, 13:54:38

Razor, ich finds ehrlichgesagt vollkommen scheisse, dass du hier gegen den PS 1.4 wetterst, obwohl bisher absolut nicht feststeht, ob diese Pixelshaderimplementation wirklich genutzt wird (aber das passt zu dir :D). Das ganze Thema kann man auch aus einer ganz anderen Perspektive sehen. Deine Ansicht ist sicherlich eine Möglichkeit, das will ich nicht leugnen!
Allein die Tatsache, dass NVidia im G4 keinen PS 1.3 drin hat, sagt noch ABSOLUT nicht aus, ob der PS 1.4 nicht doch viel unterstützt wird! Matrox und SIS haben nur einen verschwindend geringen Marktanteil. Das wird sich jetzt selbstredend ändern, aber SIS würd ich da schonmal wieder getrost aussenvor lassen, da ich nicht an perfekte Treiber glaube und die ganze Sabre Serie eher eine Billigproduktion ist - deshalb auch ganz klar die Wahl der PS 1.3.
Bei Matrox passte es nur einfach besser zum Design, das sehe ich im mom auf jeden Fall so.
Es liegt sogar im Bereich des Möglichen, dass in Zukunft sogar der PS 1.4 (mit Fallback auf 1.1) absoluter Standart werden wird, da das der kleinste gemeinsame Nenner werden wird, wenn P10, KyroIII, NV30 und R300 erscheinen werden!!! Wie ich vor mehr als einem Jahr schon gesagt haben, der Geforce3 ist absolut untere Grenze und der R200 ist REFERENZ!!! (der K3 könnte hier Zünglein an der Waage weden :D)
Den grössten und bekanntesten Hersteller von 3D Spieleengines (id Software) hat ATI ja schon sozusagen auf seiner Seite - was mit Sicherheit Schule machen wird bei der Konkurrenz! Denn auch hier gilt: Doom3 ist wie seine bebenden Vorgänger REFERENZ!!!
Desweiteren gibt es noch viele andere vielversprechende Engines! z.B. die in Elderscolls III zum Einsatz gekommene und bald für DAoC erscheinende NDL Netimmerse 4.0 Engine. Doch was les ich da auf der www.darkageofcamelot.com page - die haben jetzt Nteimmerse 4.2 lizensiert (ich vermute mal dass das Update im Herbst/Winter soweit sein wird)! Und jetzt ratet mal was die mehr kann, als die 4.0 :D ;)
Weite interessante Aspekte tun sich hier noch bei SW Galaxies und anderen (vor allem Online-) Games auf.

Razor

2002-05-19, 13:57:17

@zeckensack

Nur zur Erinnerung:
Es ging hier ursprünglich (oder sagt man ursächlich ?) um die Kritik am Parhelia eben keine PS1.4 zu unterstützen. Und da man dies auch anderen Karten vorwirft, wollte ich dem mal auf den Grund gehen.

Und dieser scheint sich wie folgt darzustellen:

PS1.4-Fähigkiten = bessere Performance (in bestimmten Situationen), besser Handhabung (für Entwickler, wenn PS1.4 genutzt werden) und anscheinen KEINEN visuellen Vorteil (wie von ATI dargestellt).

Es ging hier mit Sicherheit nicht darum, daß ATI irgend etwas ändern sollte...
Ganz im Gegenteil (habe ich auch schon erwähnt) kommt ihnen die Entwicklung beim R300 ja zugute, da dieser doch wohl hoffentlich PS2.0 unterstützen wird.

Bis denne

Razor

Exxtreme

2002-05-19, 13:58:22

Diese Demo hat AFAIK Humus aus dem B3D/Rage3D-Forum geproggt. Leider nutzt das Teil AFAIK den PS1.4 gar nicht richtig. Es gab aber mal bei B3D mal einen Screenshot, bei dem man einen Unterschied sah. Da hat die GF3 AFAIK mit dem Overbright-Rendering so ihre Probleme bekommen, während die R8500 alles korrekt renderte. Ich weiss leider nicht ob es tatsächlich am PixelShader lag. Muss mal dort bisschen suchen.

Gruß
Alex

MadManniMan

2002-05-19, 13:59:08

@MadManniMan

Ich bitte Dich inständig, Dir wenigstens meine Posts durchzulesen (auch wenn es etwas viel für Dich ist)//danke für die blumen//[/], wenn Du sie schon kritisierst.

[b]//hab ich bis vor ca. 5 posts auch getan, nur schreibst du halt immer arg viel//

Ich versuche hier gar nichts unter den Tisch zu keheren, auch habe ich den Performance-technischen Gesichtspunkt sogar mehrfach erwähnt.

durchaus richtig, allerdings läßt das gros deiner posts durchscheinen, daß dieser punkt für dich mehr oder minder zu vernachlässigen ist. in jedem fall bist du nicht gewillt, auch nur ein gutes haar am 1.4er zu lassen. stört mich insofern, daß leute wie du immer die voodoo-reihe schlechtgeredet haben(du verstehst...)//

Also was genau willst Du eigentlich ?
???

//dich von deinem verqueren standpunkt zu meinem ultimativ richtigen bekehren?//

Razor

//angenehm//

Razor

2002-05-19, 14:02:40

Originally posted by Exxtreme
Diese Demo hat AFAIK Humus aus dem B3D/Rage3D-Forum geproggt. Leider nutzt das Teil AFAIK den PS1.4 gar nicht richtig. Es gab aber mal bei B3D mal einen Screenshot, bei dem man einen Unterschied sah. Da hat die GF3 AFAIK mit dem Overbright-Rendering so ihre Probleme bekommen, während die R8500 alles korrekt renderte. Ich weiss leider nicht ob es tatsächlich am PixelShader lag. Muss mal dort bisschen suchen.
Jup alex, Beyond3D war das und dort habe ich das auch gelesen...

Allerdings hat man dazu keine gf3 genommen, sondern lediglich eine R8500 und hat diese dann eben beschnitten, um den Unterschied zu verdeutlichen. Als aber besagter Humus eben doch die Unterstützung für die gf3 implementierte war der Unterscheid lange nicht mehr so groß (wenn überhaupt noch vorhanden). Insofern sich seine ursprüngliche Kritik am Design der gf3 dann ja auch relativierte...

Bis denne

Razor

MadManniMan

2002-05-19, 14:02:59

Originally posted by Razor

PS1.4-Fähigkiten = bessere Performance (in bestimmten Situationen)

wie kommt es, daß dieser punkt für deine posts auf einmal wieder von relevanz ist?

@exxtreme:

sag ich doch. selbige demo ward übrigens einst von ram verwendet, um in einem PCGH artikel overbright lighting zu erklären

allerdings weiß ich auch nicht mehr, obs an der hadware(interne renderinggenauigkeit) oder am PS lag :/

Razor

2002-05-19, 14:06:33

Ach Manni...

Soll ich Dir wirklich alle Stellen vorkauen, wo ich das erwähnte ?
Eher nicht, oder ?
:D

Und ja, die visuelle Qualität ist für mich sehr viel mehr von Relevanz, als quantitative Performance. War es schon immer und wird es immer sein...

Und nicht Aufregen... schadet nur der Gesundheit.

Razor

zeckensack

2002-05-19, 14:12:56

Zur Demo:
Ich hab' da irgendwo in einem Thread auf Rage3d - den Link könnte ich suchen, fühle mich aber noch nicht ausreichend ermutigt ;) - gelesen, daß das ursprünglich 'bessere' Abschneiden der Radeon8500 auf einem Treiberbug beruhte. In der Spec steht, daß das Resultat von DOT3-Operationen am Ende mit Faktor 4 skaliert werden muß, die Geforce 3 hat's gemacht, die ATI nicht, deswegen war die Geforce 3 zu hell und hatte Probleme mit clamping und auf der ATI sah alles richtig aus .... bis dann ein neuer Treiber kam ;)

MadManniMan

2002-05-19, 14:16:25

was nützt dir die beste quali ohne vernünftige performance?

naja, hm... laß mich mal einen fall konstruieren, an dem sich deine argumentation in den schwanz beißt...

sagen wir mal, onkel carmack möchte für eine szene 5 texturschichten benützen. banal und ohne andere umstände berücksichtigend ausgedrückt, braucht die gf3/4 2, wo die r85 1 pass braucht. nun könnte man halt eine schicht weglassen, wo du wieder nünfitge performance mit deiner gf3 hättest, allerdings müßtest du auf BQ verzcihten...

verstehst du , worauf ich hinaus will?

Demirug

2002-05-19, 14:17:32

Razor,

du schreibts ja genauso lange romane wie ich.

Mit deinen optischen Qualitäten geb ich dir vollkommen recht. Im Prinzip kann man mit jeder Karte jeden beliebigen Effect darstellen. Man tut es aber nicht weil die Speed eben einbricht.

Da man mit ps1.4 die gleichen effekte mit weniger Resourcen Einsatz erreichen kann ist es möglich noch bessere Effekte zu machen. Diese Effekte erfordern aber im Regelfall arbeit von den Designern und Grafikern. Wenn also ein Spiel primär an einer Gforce3 ausgerichtet wird werden die Grafiker keine Texturen für Effekte machen die den Leistungsrahmen der GF sprengen. Das wäre nähmlich Geld rausgeworfen. Ergo wird der Einsatz von PS1.4 im Regelfall nur zu einer Geschwindigkeitssteigerung führen aber zu mehr auch nicht.

Ich persönlich glaube auch nicht das DOOM III auf einem R200 besser aussieht. Die primären Entwicklungskarten bei IDSoft kommen von NVidia (der besseren Treiber wegen). Es wird also lediglich um die FPS gehen. Das DOOM III übrigens die pixelshader des R200 unterstützt hat einen ziemlich einfachen grund. Es geht nicht anders.

Es gibt im Moment zu mindestens aus wirtschaftlicher Sicht keinen Grund als Engineentwickler auf PS1.4 zu setzten. Das lohnt sich bei der derzeitigen verfügbarkeit von PS1.4 fähigen karten einfach nicht.

Wer gute Argumente dafür hat möge mir diese nehnen den aus technischer Sicht bin ich natürlich interesiert PS1.4 in unsere Engine einzubauen.

Aufgrund dieser Situation kann ich Razor nur recht geben das PS1.4 aus wirtschaftlicher sicht für ATi ein Fehlschlag war.

Wenn Matrox und SIS ebenfalls auf den PS1.4 Zug aufgesprungen wären hätte sich ATi natürlich freuen können. Es war eben ein Risiko das sich nicht gelohnt hat.

MadManniMan

2002-05-19, 14:20:04

darf man fragen, bei wem und an welcher engine du bastelst?

Demirug

2002-05-19, 14:25:23

Originally posted by MadManniMan
darf man fragen, bei wem und an welcher engine du bastelst?

Fragen darfs du schon aber die Antwort würde dir nichts nützen da das Studio nicht bekannt ist. Wir arbeiten an unserem Erstlingswerk und ich darf eigentlich nichts sagen da wir noch nicht so weit sind an die öffentlichkeit zu gehen.

Thowe

2002-05-19, 14:31:35

Originally posted by Demirug

Fragen darfs du schon aber die Antwort würde dir nichts nützen da das Studio nicht bekannt ist. Wir arbeiten an unserem Erstlingswerk und ich darf eigentlich nichts sagen da wir noch nicht so weit sind an die öffentlichkeit zu gehen.

Das wohl längste Nein der Welt :D ;) :)

*scnr*

MadManniMan

2002-05-19, 14:51:39

du bist bestimmt onkel cramack himself, oder? :D

Demirug

2002-05-19, 15:06:44

Originally posted by MadManniMan
du bist bestimmt onkel cramack himself, oder? :D

Das würde aber nicht ganz passe. erstens carmack hat mit IDSoft schon einige Spiele auf den Markt gebracht. zweitens IDSoft ist kein unbekanntes Studio und drittens Carmack benutzt OpenGL und wir DX.

Thowe

2002-05-19, 15:29:35

Originally posted by Demirug

Das würde aber nicht ganz passe. erstens carmack hat mit IDSoft schon einige Spiele auf den Markt gebracht. zweitens IDSoft ist kein unbekanntes Studio und drittens Carmack benutzt OpenGL und wir DX.

Tarnung :| :D

aths

2002-05-19, 15:58:34

Razor,

nicht in diesem Tonfall! - Dann lassen wir es.

aths

2002-05-19, 16:02:23

Demirug,

Bitte entschuldige das Wegeditieren deines Postings. Es war keine Absicht, sondern eine Fehlbedienung des Forums meinerseits.

Du hast mich dort zu Aufwand von PS.1.4 gefragt.

Lass mich etwas ausschweifender antworten. Es wurden schon mal modulare Engines angesprochen. Angenommen, ein Objekt soll mit "Marmor" texturiert werden. Man könnte der Engine also sagen: "Klebe hier Marmor drauf!" Diese prüft vorher, ob überhaupt PixelShader vorhanden sind, und wenn ja, welche. Ohne PixelShader wird eine normale Textur geladen. Mit PixelShader wird einfach der passende Shader für dieses Material geladen. Da müssten dann ein mal Profis für jeden in HW vorhandenen PS für jedes gewünschte Material einen Shader schreiben. Die eigentlichen Spiel-Entwickler bräuchten sich gar nicht mehr darum zu kümmern.

Wäre eine Engine von vornherein auf "Material" statt "Zeiger auf Texturen" ausgelegt, wäre auch ein Nachrüsten mit PixelShader-Technologie möglich: Der Spieler lädt einen Patch mit dem neuen Material-Satz (also den Shadern und dazugehörigen Texturen) und das alte Spiel erstrahlt in neuem Glanz.

Ohne Abstraktion stelle ich es mir auch sehr (zu) aufwändig vor, weniger verbreitete Technik zu unterstützen.

Xmas

2002-05-19, 16:13:28

Originally posted by Razor
Die Entwickler solltes es tun, weil es schenller auf einer Handvoll Karten ist ?
Eher nicht...
Diese "Handvoll Karten" ist vielleicht mehr als du denkst...

Mehr Übersicht vielleicht, aber keine visuellen Vorteile...
Davon war ja auch nicht die Rede.

Inwiefern sollten N-Patches (ATI) noch sinnvoll sein, wenn DM und die polyFlachen zum Einsatz kommen ?
???
Weil sie schön platzsparend und einfach zu generieren sind? Nicht immer ist die Flexibilität anderer HOS vonnöten.

Soweit ich informiert bin, entscheidet nch immer der Treiber, was er der API meldet...
Entweder meldet der Treiber DirectX Unterstützung von PS1.1, was dazu führt dass DX alle PS >1.1 ablehnt, oder der Treiber meldet PS1.3-Unterstützung, was aber offensichtlich nicht ganz stimmt und somit zu Fehlern führen könnte, weil der entsprechende Shader dann doch nicht unterstützt wird.

Schon wieder...
Da behauptet jemand einfach etwas, ohne es zu belegen und schon wird es nachgeplappert (ist wirklich nicht böse gemeint !). Bitte sei doch so gut und führe ein Demo an (wie ich es oben tat), welches diese Aussage stützt. Die performance-technischen Vorteile laß ich zu 100% gelten, aber den visuellen Vorteil wage ich in Frage zu stellen !
Razor, meinst du nicht dass du damit etwas viel verlangst? Soll jetzt jemand, der am besten noch beide Karten haben sollte, sich hinsetzen und seine Zeit damit verplempern, sich irgendeinen popligen Effekt auszudenken und diesen mit beiden PS optimal zu realisieren, nur um dir zu beweisen dass man mit 12 Bit eben doch etwas mehr anfangen kann als mit 9?
Ich kann jedenfalls mit meiner Freizeit was besseres anfangen...

Und da hier nun mal das 3 zu 1 Prinzip herrscht (ev auch 4 zu 1 mit dem P10)
3 zu 2 mit dem P10. Der P10 kann viel mehr als nur PS 1.4.

Demirug

2002-05-19, 16:35:54

Demirug,

Bitte entschuldige das Wegeditieren deines Postings. Es war keine Absicht, sondern eine Fehlbedienung des Forums meinerseits.

Egal, kann ja mal passieren

Du hast mich dort zu Aufwand von PS.1.4 gefragt.

Lass mich etwas ausschweifender antworten. Es wurden schon mal modulare Engines angesprochen. Angenommen, ein Objekt soll mit "Marmor" texturiert werden. Man könnte der Engine also sagen: "Klebe hier Marmor drauf!" Diese prüft vorher, ob überhaupt PixelShader vorhanden sind, und wenn ja, welche. Ohne PixelShader wird eine normale Textur geladen. Mit PixelShader wird einfach der passende Shader für dieses Material geladen. Da müssten dann ein mal Profis für jeden in HW vorhandenen PS für jedes gewünschte Material einen Shader schreiben. Die eigentlichen Spiel-Entwickler bräuchten sich gar nicht mehr darum zu kümmern.

Wäre eine Engine von vornherein auf "Material" statt "Zeiger auf Texturen" ausgelegt, wäre auch ein Nachrüsten mit PixelShader-Technologie möglich: Der Spieler lädt einen Patch mit dem neuen Material-Satz (also den Shadern und dazugehörigen Texturen) und das alte Spiel erstrahlt in neuem Glanz.

Ohne Abstraktion stelle ich es mir auch sehr (zu) aufwändig vor, weniger verbreitete Technik zu unterstützen.

Im Prinzip werden moderen Engines genauso aufgebaut. Bei der Vielzahl der Karten geht das auch gar nicht mehr anders. Es gibt dabei aber einen kritischen Teil: Dynamisches Licht und Schatten. Dafür müssen die Blendingoperationen zur Laufzeit kalkuliert werden.

Da sich Ps1.0 - 1.3 und PS 1.4 technologisch stark unterscheiden braucht man dafür jeweils einen eignen Codepfad zusätzlich zu dem Pfad ohne ps.

In diesem Bereich liegt eine Menge arbeit wenn man es ordentlich machen will. Und ob man diese Arbeit nun 2 oder 3 mal macht ist schon ein unterschied.

Zum anderen Steck in den Texturen eine Menge arbeit da werden nicht einfach mal schnell ein paar neue gemacht.

Demirug

2002-05-19, 16:52:16

Weil sie schön platzsparend und einfach zu generieren sind? Nicht immer ist die Flexibilität anderer HOS vonnöten.

Ganz so einfach zu generieren sind sie leider nicht aber ansonsten gebe ich dir recht. Ist aber alles wieder eine Aufwand Nutzen Fragen.

Entweder meldet der Treiber DirectX Unterstützung von PS1.1, was dazu führt dass DX alle PS >1.1 ablehnt, oder der Treiber meldet PS1.3-Unterstützung, was aber offensichtlich nicht ganz stimmt und somit zu Fehlern führen könnte, weil der entsprechende Shader dann doch nicht unterstützt wird.

Genau! Und die ganze Diskussion um diesen Punkt bringt am ende doch eh nichts. Was die Treiber melden ist verbindlich daran kann weder der Programmiere noch der Spieler etwas ändern.

Razor, meinst du nicht dass du damit etwas viel verlangst? Soll jetzt jemand, der am besten noch beide Karten haben sollte, sich hinsetzen und seine Zeit damit verplempern, sich irgendeinen popligen Effekt auszudenken und diesen mit beiden PS optimal zu realisieren, nur um dir zu beweisen dass man mit 12 Bit eben doch etwas mehr anfangen kann als mit 9?
Ich kann jedenfalls mit meiner Freizeit was besseres anfangen...

War zwar jetzt nicht auf mich gemünzt aber meiner Meinung nach sollte das nicht irgendwer machen sonder Ati. Die Demos von ihnen sind nur bedingt für vergleiche geeignet. Wer mir da noch einfällt wäre MadOnion.

3 zu 2 mit dem P10. Der P10 kann viel mehr als nur PS 1.4.
Auf dem Papier. Der Chip muss erst noch beweisen was seine ps-emulation in der Praxsis leisten kann.

MadManniMan

2002-05-19, 17:00:02

mich würde mal interessieren, was onkel carmack(ich bleib dabei ;) ) alias demirug von shadow buffern hält

afaik verwendet die lustige inseln demo von ati shadow buffer in rauhen mengen

Demirug

2002-05-19, 17:15:21

Originally posted by MadManniMan
mich würde mal interessieren, was onkel carmack(ich bleib dabei ;) ) alias demirug von shadow buffern hält

afaik verwendet die lustige inseln demo von ati shadow buffer in rauhen mengen

Ich konnte dich also nicht überzeugen???

Weis zwar noch nicht was von dem onkel carmark halten soll aber zum Thema.

Meiner Meinung nach war es eine gute Idee shadow buffern in der HW zu implentieren.

Sie vereinnen die Vorteile von Projections shadows und Stencil shadows habe aber kaum nachteile.

MadManniMan

2002-05-19, 17:23:55

Xmas

2002-05-19, 17:24:01

Originally posted by Demirug
War zwar jetzt nicht auf mich gemünzt aber meiner Meinung nach sollte das nicht irgendwer machen sonder Ati. Die Demos von ihnen sind nur bedingt für vergleiche geeignet. Wer mir da noch einfällt wäre MadOnion.
Problem: ATI müsste sich dann aber bestimmt den Vorwurf gefallen lassen, PS1.3 nicht optimal zu nutzen, um das eigene Produkt im besseren Licht dastehen zu lassen.
Die Treasure Chest Demo ist AFAIK die einzige Vergleichsmöglichkeit, wenn auch nur eingeschränkt. Immerhin gibt es dafür den Sourcecode.

Auf dem Papier. Der Chip muss erst noch beweisen was seine ps-emulation in der Praxsis leisten kann.
Da mache ich mir mal keine Sorgen ;)

Demirug

2002-05-19, 17:49:17

schau dir meinen nick und meine sig an und dann weißt du, was du davon zu halten hast, wenn ich mit gewissen forenmembern eine andere art der geistigen verbindung eingehe, wie mit dem gros(nggalai kann dir ein lied davon singen :D )

Mir schwant schlimmes:D

zum thema:

da ich mir nicht vorstellen kann, daß man die kanten der shadow texutres filtern kann, sehe ich persönlich probleme mit der auflösung der texturen, da ich schon einmal las, daß wohl kaum mehr als 512*512 verwendet werden. wieviel performance schlucken die eigentlich? muß ja nen grund gegeben haben, daß JC... äh, ich meine du auf vertex shader bei den schattenspielchen setzt

Natürlich lassen sich die kanten filtern. Ist doch blos eine normale Textur bei der die u und v korrdinaten eben auf andere Weise bestimt werden. Dadurch werden bei shadow buffers die Kanten auch weicher als bei Stencil Schatten. Die Auflösung ist im Regelfall kein Problem. Wenn sich die Lichtquelle aber in einem ungünstigen Winkel zum Betrachter befindet kann es leichte Probleme geben.

Die Performance ist nicht schlecht im Verhältnis zu Stencil Shadows sogar Spitze.

Was die Vertex shader angeht. Die kann (und sollte) man für alle Arten der Schattenspiele benutzen.

Demirug

2002-05-19, 17:51:53

Originally posted by Xmas

Problem: ATI müsste sich dann aber bestimmt den Vorwurf gefallen lassen, PS1.3 nicht optimal zu nutzen, um das eigene Produkt im besseren Licht dastehen zu lassen.
Die Treasure Chest Demo ist AFAIK die einzige Vergleichsmöglichkeit, wenn auch nur eingeschränkt. Immerhin gibt es dafür den Sourcecode.

Guter Einwand. Warten wir eben auf DOOM III zum vergleichen.

MadManniMan

2002-05-19, 18:14:21

vertex shader generierte lichtereien scheinen allerdings gewisse vorteile gegenüber shadow buffers zu haben, sonst würde onkel john die ja auch nicht nehmen

... da fällt mir ein, gibt es nicht bei shadow buffern probs, wenn die lichtquell NICHT rein eine richtung beleuchtet... bäh, scheiße auszudrücken... mom...

was ist, wenn der schatten auch dahin gehen soll, w.. ach du scheiße, ich glaube, ich hab das prinzip nich verstanden...

der bericht bei tommti muß meinenm hirn falsch geverstanden worden sein...

kann mir nochmal einer die genaue arbeitsweise erklären?

Demirug

2002-05-19, 18:28:06

vertex shader generierte lichtereien scheinen allerdings gewisse vorteile gegenüber shadow buffers zu haben, sonst würde onkel john die ja auch nicht nehmen

Nochmal zum verständnis auch bei den shadow buffers brauchst du den vertex shader. Die Aussage das der vertex shader für die Schatten verwendet wird sagt nicht mehr aus als das es Schatten gibt.

... da fällt mir ein, gibt es nicht bei shadow buffern probs, wenn die lichtquell NICHT rein eine richtung beleuchtet... bäh, scheiße auszudrücken... mom...

Du meinst sicher Punktlichter. Da braucht man halt einen Cube Shadow Buffer. Ist ein bischen mehr aufwand. Im Regelfall aber trotzdem nicht so ein Bandbreitenkiller wie Stencil Shadows.

kann mir nochmal einer die genaue arbeitsweise erklären?
Das Prinzip ist ganz einfach. In dem Schadow Buffer sind die entfernungen der Polys von der Lichtquelle hinterlegt. Beim Render wird dann einfach die Entfernung eines Punkts zur Lichtquelle berechnet Ist diese größer als die dazugehörige Entfernung im Buffer liegt der Punkt im Schatten ansonsten eben nicht.

MadManniMan

2002-05-19, 18:38:12

dann hab ichs doch richtig verstanden

ich konnte mir nur nicht vorstellen, daß neben dem arschlahmen cube env mapping noch etwas mit cub daherkommt... :P

moment, die darstellungsfehler vom cube env sind ja bekannt, muß man mit diesen auch bei cubic shadow buffern rechnen?

Razor

2002-05-19, 19:31:06

@zeckensack
Zur Demo:
Ich hab' da irgendwo in einem Thread auf Rage3d - den Link könnte ich suchen, fühle mich aber noch nicht ausreichend ermutigt ;) - gelesen, daß das ursprünglich 'bessere' Abschneiden der Radeon8500 auf einem Treiberbug beruhte. In der Spec steht, daß das Resultat von DOT3-Operationen am Ende mit Faktor 4 skaliert werden muß, die Geforce 3 hat's gemacht, die ATI nicht, deswegen war die Geforce 3 zu hell und hatte Probleme mit clamping und auf der ATI sah alles richtig aus .... bis dann ein neuer Treiber kam ;)
So kann's dann mal auch gehen, gell ?
:D

@MadManniMan
was nützt dir die beste quali ohne vernünftige performance?

naja, hm... laß mich mal einen fall konstruieren, an dem sich deine argumentation in den schwanz beißt...

sagen wir mal, onkel carmack möchte für eine szene 5 texturschichten benützen. banal und ohne andere umstände berücksichtigend ausgedrückt, braucht die gf3/4 2, wo die r85 1 pass braucht. nun könnte man halt eine schicht weglassen, wo du wieder nünfitge performance mit deiner gf3 hättest, allerdings müßtest du auf BQ verzcihten...

verstehst du , worauf ich hinaus will?
Ich verstehe durchaus, worauf Du hinaus willst...
Nun nehmen wir die Parhelia mit ihren 8 Texturen und tauschen deine 5 gegen 7 Texturen.
Was bitte nützt dann PS1.4 ?

Werstehst Du nun worauf ich hinaus will ?

@Demirug
du schreibts ja genauso lange romane wie ich.
Nur sind Deine um einiges Inhaltsreicher !
;-)
Ich persönlich glaube auch nicht das DOOM III auf einem R200 besser aussieht. Die primären Entwicklungskarten bei IDSoft kommen von NVidia (der besseren Treiber wegen). Es wird also lediglich um die FPS gehen. Das DOOM III übrigens die pixelshader des R200 unterstützt hat einen ziemlich einfachen grund. Es geht nicht anders.
Klar, wenn man unter OpenGL proggt...
Insofern fand ich dieses Beispiel doch ziemlich an den Haaren herbei gezogen.
Wenn Matrox und SIS ebenfalls auf den PS1.4 Zug aufgesprungen wären hätte sich ATi natürlich freuen können. Es war eben ein Risiko das sich nicht gelohnt hat.
Und diese Situation hatten schon einige damals kommen sehen...
Aus der ATI-Fraktion hatte man natürlich heftigst dagegen gewettert (was ja auch verständlich war), aber genützt hat's im Endeffekt natürlich wenig. Auch wenn Matrox sich nicht bewußt gegen den PS1.4 entscheiden haben (was man aus heutiger sicht nur schwer sagen kann) so haben sie doch endgültig die Weichen gestellt. Denn es war von Anfang an klar, daß die PS1.4 nicht genutzt würden, wenn ATI der einzige Chiphersteller bliebe.

Aber es geht mir hier gar nicht darum, nun ATI den schwarzen Peter zu zuschieben, sondern ich möchte die Kritik an dem Parhelia entkräften, den PS1.4 nicht zu unterstützen. Man hätte sich zum Teil auf ATI's Chiparchitektur stützen müssen und das, wo der Parhelia vermutlich sehr viel leistungsfähiger sein wird, als eine R200 oder ein NV25.

Und auf nichts anderes wollte ich hinaus !

@aths

Was für einen Tonfall meintest Du ?
(der, daß Du mich als albern bezeichnet hatst ?)
???

Vermute allerdings eher, daß Dir die Argumente ausgegangen sind...

@Xmas

"Diese "Handvoll Karten" ist vielleicht mehr als du denkst..."

Ich vermute, daß Du weißt, wie ich das meinte.

-> Gemessen an der Marktverbreitung der gf3/4-Karten und den zukünftigen Marktteilnehmern, von denen zumindest SiS ins untere Marktsegment stoßen, sind's bei R8500 eben sehr viel weniger, wodurch der Aufwand, einen zusätzlichen Codepath zu generieren, nicht gerechtfertigt erscheint.
(hoffe mich nun korrekt ausgedrückt zu haben)

[PS1.4 = visuelle Vorteile]
"Davon war ja auch nicht die Rede."

Dann habe ich Dich mißverstanden...

"Weil sie schön platzsparend und einfach zu generieren sind? Nicht immer ist die Flexibilität anderer HOS vonnöten."

Nun ja, schöner wärs auf jeden Fall, wenn die Darstellungsqualität darunter nicht leiden würde und somit ist die aufwenidigere Form dann doch qualitativ sehr viel günstiger. Aber auch dieses Feature (N-Patches von ATI) scheint eines zu sein, welches, wenn überhaupt, nur aufgrund der einfachen (wenn auch qualitativ fragwürdigen) Implementierung sinn macht.
Entweder meldet der Treiber DirectX Unterstützung von PS1.1, was dazu führt dass DX alle PS >1.1 ablehnt, oder der Treiber meldet PS1.3-Unterstützung, was aber offensichtlich nicht ganz stimmt und somit zu Fehlern führen könnte, weil der entsprechende Shader dann doch nicht unterstützt wird.
Auf nichts anderes wollte ich hinaus...
Razor, meinst du nicht dass du damit etwas viel verlangst? Soll jetzt jemand, der am besten noch beide Karten haben sollte, sich hinsetzen und seine Zeit damit verplempern, sich irgendeinen popligen Effekt auszudenken und diesen mit beiden PS optimal zu realisieren, nur um dir zu beweisen dass man mit 12 Bit eben doch etwas mehr anfangen kann als mit 9?
Ich kann jedenfalls mit meiner Freizeit was besseres anfangen...
Es gibt Menschen, die tun noch sehr viel sinnlosere Sachen...

Und die Qualitäten einer Chip-generation voll auszureizen, dürfte für Programmierer schon einen Sinn machen, so wie andere sich damit beschäftigen, aus ihrem Auto das letzte heraus zu holen und dafür ihre gesamte Freizeit opfern. Daß dies in Sachen Grafikeffekten offensichtlich nicht der Fall ist, hast Du ja nun einderucksvoll unter Beweis gestellt.

Ich habe mir zumindest die Mühe gemacht, ein Demo heraus zu suchen, um wenigstens einen Punkt in der Praxis gegenüber zu stellen. Von anderen, die ständig behaupten, daß es Vorteile gibt, die offensichtlich, wenn existent, noch Niemand (!) auch nur ansatzweise gezeigt und/oder gegenüber gestellt hat, kann man das nicht sagen.

So muß ich daraus schließen, daß die theoretischen Vorteile, die hier genannt werden, eben keine sind, sondern eben nur Marketingzeugs, welches keinen Vergleich zuläßt.

Wenn aber nicht einmal in Techdemo's der visuelle Vorteil belegt werden kann, dann ist das zumindest auch schon eine inhaltliche Aussage...

"3 zu 2 mit dem P10. Der P10 kann viel mehr als nur PS 1.4."

Hättest Du dafür bitte einen Beleg ?
Mir ist klar, daß es mehr oder weniger 'frei programmierbar' sein soll, aber daß er explizit PS1.4 (oder DM) unterstützt, wäre mir neu... Soweit ich bisher weiß, soll er keinen PS2.0 unterstützen, insofern wage ich Deine Aussage bezüglich der PS1.4 (die doch den PS2.0 sehr ähnlich sein sollen) in Frage zu stellen.

Ich wäre sehr dankbar, wenn sich dieser mögliche Irrtum meinerseits korrigieren ließe...

Bis denne

Razor

Exxtreme

2002-05-19, 19:37:28

Originally posted by Razor

Ich verstehe durchaus, worauf Du hinaus willst...
Nun nehmen wir die Parhelia mit ihren 8 Texturen und tauschen deine 5 gegen 7 Texturen.
Was bitte nützt dann PS1.4 ?

Bis denne

Razor
So wie es z.Zt. aussieht, kann der Parhelia keine 8 Texturen pro Pass auftragen sondern nur 4.

Gruß
Alex

StefanV

2002-05-19, 19:44:40

Originally posted by Exxtreme

So wie es z.Zt. aussieht, kann der Parhelia keine 8 Texturen pro Pass auftragen sondern nur 4.

Gruß
Alex

Richtig, deswegen kann die Parhelia auch keinen PS 1.4

Allerdings glaube ich auch nicht, daß Matrox 'nur' einen 'NV Kompatiblen' PS1.3 hat, sondern sicher auch noch ein paar eigene Erweiterungen...

@Razor

Der PS1.4 ist Fortschrittlicher und besser als der PS 1.3 Punkt

Der Rest interessiert nicht!

Exxtreme

2002-05-19, 19:48:57

Originally posted by Stefan Payne

Allerdings glaube ich auch nicht, daß Matrox 'nur' einen 'NV Kompatiblen' PS1.3 hat, sondern sicher auch noch ein paar eigene Erweiterungen...

Glaube ich nicht. Das wäre reine Silizium-Verschwendung. Ich glaube nicht, daß diese Erweiterungen jemals einen Weg in irgendein Game gefunden hätten und dessen ist sich Matrox auch bewusst.

Gruß
Alex

Demirug

2002-05-19, 19:57:29

Originally posted by Exxtreme

Glaube ich nicht. Das wäre reine Silizium-Verschwendung. Ich glaube nicht, daß diese Erweiterungen jemals einen Weg in irgendein Game gefunden hätten und dessen ist sich Matrox auch bewusst.

Gruß
Alex

Seh ich genausso. Bei der größe des Chips baut man da nichts unnötiges rein. Und von Features die so gut wie keiner benutzt hat Matrox wahrscheinlich genung.

Razor

2002-05-19, 20:32:27

Originally posted by Exxtreme

So wie es z.Zt. aussieht, kann der Parhelia keine 8 Texturen pro Pass auftragen sondern nur 4.

Gruß
Alex
Ups...
Hatte ich mit dem P10 verwechselt...

Aber auch hier greift die Argumentation mit der Anpassung der eigenen Architektur auf ATI-Verhälnisse. Warum sollte das ein Chip-Hersteller machen ?

-

Hab' gerade nochmal in das hiesige Parhelia-Preview geschaut (der Texturen pro Pass wegen) und auch dort steht nichts von "P10 kann PS1.4" (sondern lediglich PS1.3). Insofern würde mich dann doch noch mal interessieren, wie Xmas darauf kommt...

Bis denne

Razor

Demirug

2002-05-19, 20:45:49

Originally posted by Razor

Hab' gerade nochmal in das hiesige Parhelia-Preview geschaut (der Texturen pro Pass wegen) und auch dort steht nichts von "P10 kann PS1.4" (sondern lediglich PS1.3). Insofern würde mich dann doch noch mal interessieren, wie Xmas darauf kommt...

Bis denne

Razor

Strenggenommen hat der P10 überhaupt keine Pixelshader. Er hat 64 programmierbare Éinheiten für diesen Zweg. Es ist nun die Aufgabe des Treibers diese Einheiten so zu programmieren das sie einen PS emulieren. Es ist sicher möglich einen PS nach 1.4 Norm zu emulieren über die Speed ist aber nur schwer eine aussage zu machen.

Desweiteren ist zu bedenken das der P10 ja 8 Texturen pro Pass beherscht. Bei einer PS 1.4 emulation bleiben dann 2 ungenutzt. Bei einer PS 1.0 - 1.3 Emulation wäre es unter Umstanden möglich einen dualen PS zu enumlieren und alle Textureinheiten zu nutzen. Aber auch hier lassen sich keine Speedaussagen treffen.

aths

2002-05-19, 21:33:21

Razor,

die Argumente im Fall PixelShader betrifft, so stehst du praktisch alleine gegen das gesamte Forum da, worunter sich einige hochkarätige Profis befinden. Schade, dass du das nicht einsiehst und nun diese Ebene einschlagen willst. Wie schon gesagt: In diesem Tonfall ist eine Diskussion mit mir nicht möglich.

aths

2002-05-19, 21:36:50

Stefan,

dass Parhelia nicht PS.1.4-kompatibel ist hat auch, aber natürlich nicht nur mit den 4 Texturen pro Pass zu tun. Der 1.4-er PixelShader erfordert soweit ich das verstanden habe auch eine etwas andere Combiner-Logik als 1.0 - 1.3.

Demirug

2002-05-19, 21:54:41

Originally posted by aths
Stefan,

dass Parhelia nicht PS.1.4-kompatibel ist hat auch, aber natürlich nicht nur mit den 4 Texturen pro Pass zu tun. Der 1.4-er PixelShader erfordert soweit ich das verstanden habe auch eine etwas andere Combiner-Logik als 1.0 - 1.3.

Die einzelen Zellen des PS1.4 sind im wesentlichen mit den PS1.0 -PS1.3 Zellen identisch. Sie unterstützen eben zusätzliche Befehle. Der Hauptunterschied der PS1.4 ist das die Zellen 2 mal mit unterschiedlichen Befehlen durchlaufen werden können. Dadurch ergibt sich die Möglichkeit jede Textur 2 mal zu verwenden und durch die zusätzlichen Befehle können die texturkoordinaten in der 1.Phase verändern und dann in der zweiten Phase benutzen werden.

aths

2002-05-19, 22:02:46

Demirug,

PS.1.4 hat letztlich weniger Befehle als 1.3. Dabei sind die Operationen, die ein Befehl 1.4-er Befehl ausführt, in der Regel weniger komplex als ein 1.3-Befehl, soweit ich die DX8.1 SDK Doku interpretiert habe.

Schnitzl

2002-05-19, 22:12:22

Originally posted by Andre
[B]Du hast, in gewohnter Art und Weise, leider nix von dem verstanden, was ich sagen wollte.
Man sollte nichts beurteilen, was man nicht beurteilen kann, da es NICHT existent ist.
Also so ganz im dunklen Nebel bewegen wir uns auch nicht....
Es gibt zumindest vielversprechende Daten und diverse "Aussprüche":

Tim Sweeney, Epic's chief 3D guru working on next-generation Unreal engine technology had this to say about it: "We've had our hands on a Parhelia for the past few days, and have Unreal Tournament 2003 up and running in triple-monitor mode -- it's very immersive, and surprisingly fast (rendering at 1280*3 x 1024)." The UT engine has had adjustable FOV for quite some time now, and UT 2003 obviously does too, so when that title ships this summer, it will in all likelihood support Surround Gaming.
Also ich schliesse daraus, das die Karte recht schnell ist und das die Treiber zumindest UT2003 zum laufen bringen.
Für ein Prototyp find ich das recht cool!

MfG

Demirug

2002-05-19, 22:24:17

Originally posted by aths
Demirug,

PS.1.4 hat letztlich weniger Befehle als 1.3. Dabei sind die Operationen, die ein Befehl 1.4-er Befehl ausführt, in der Regel weniger komplex als ein 1.3-Befehl, soweit ich die DX8.1 SDK Doku interpretiert habe.

Mit den Pixelshader programmierst du eigentlich zwei Einheiten des Chips:

1.Die TMUs dafür sind die Texture address instructions gut
2.Die Combiner-Logik dafür sind die Arithmetic instructions dar.

Die eigentlichen Combiner-Logik Zellen sind fast identisch.

Bei den TMUs sind dagegen ehrhebliche unterschiede. Die ATI TMUs sind einfacher aufgebaut und deswegen gibt es beim PS 1.4 (der ja special für ATI eingebaut wurde) weniger Befehle dafür.

Dewegen braucht man beim PS1.4 ja auch zwei phasen. In der ersten führt man die nötigen matematischen funktionen auf die Texturekoordinaten durch um sie dann bei der nächsten Phase zu benutzen.

Bei den PS 1.0 - 1.3 Stellt man die mathematische Funktion direkt an der TMU ein und erledigt alles in einem Schritt.

Wenn man nun beim R200 einen PS 1.0 - 1.3 verwendet teilt er die Aktionen intern auf die beiden Phasen auf.

Der PS 1.4 ist dadurch etwas flexibler da er beim texturzugriff nicht auf die max. 18 Zugrifsmöglichkeiten der PS 1.0 - PS 1.3 beschrängt ist.

Alle Klarheiten beseitig?

MadManniMan

2002-05-19, 23:41:54

ämm, razorle, argumentierst du bitte nochmal? :D

Xmas

2002-05-20, 02:24:19

Originally posted by Razor
[PS1.4 = visuelle Vorteile]
"Davon war ja auch nicht die Rede."

Dann habe ich Dich mißverstanden...
Scheinbar bist du nicht in der Lage mehreren Diskussionen gleichzeitig zu folgen...

Xmas: Bei den PS1.2-Instruktionen muss man noch anfügen dass die beiden Arithmetikinstruktionen cmp und dp4 eigentlich nur Makros sind, die sich bei PS1.1 genauso realisieren lassen.

Razor: Die ja zudem noch über die PS1.0/1.1 emuliert werden können...
(wie Xmas ja später noch dargelegt hat)

Xmas: Zwei, aber nicht alle!
Das hat auch nix mit "emulieren" zu tun. Diese Befehle sind Makrobefehle, Kurzformen für kleine Befehlsketten, die dem Programmierer mehr Übersicht geben.

Razor: Mehr Übersicht vielleicht, aber keine visuellen Vorteile...

Xmas: Davon war ja auch nicht die Rede.

Jetzt klar? Es ging nicht um PS 1.4...

"Weil sie schön platzsparend und einfach zu generieren sind? Nicht immer ist die Flexibilität anderer HOS vonnöten."

Nun ja, schöner wärs auf jeden Fall, wenn die Darstellungsqualität darunter nicht leiden würde und somit ist die aufwenidigere Form dann doch qualitativ sehr viel günstiger. Aber auch dieses Feature (N-Patches von ATI) scheint eines zu sein, welches, wenn überhaupt, nur aufgrund der einfachen (wenn auch qualitativ fragwürdigen) Implementierung sinn macht.
Die Darstellungsqualität leiden??? Wo nimmst du denn das her? Wenn N-Patches richtig verwendet werden sehen sie genauso "ordentlich" wie RT-Patches aus. Und wenn man sie falsch verwendet, sehen sie eben falsch aus... wie RT-Patches auch.

Auf nichts anderes wollte ich hinaus...
Warum widersprichst du mir dann, wenn ich sage dass es nicht im Ermessen von NVidia liegt? Sollen die etwa einen absichtlich fehlerhaften Treiber rausbringen, damit ein paar PS1.3 Shader laufen (und andere einen Fehler verursachen)?
Man könnte höchstens einen "experimentellen" Regkey wie beim Radeon verwenden.

Ich habe mir zumindest die Mühe gemacht, ein Demo heraus zu suchen, um wenigstens einen Punkt in der Praxis gegenüber zu stellen. Von anderen, die ständig behaupten, daß es Vorteile gibt, die offensichtlich, wenn existent, noch Niemand (!) auch nur ansatzweise gezeigt und/oder gegenüber gestellt hat, kann man das nicht sagen.
Ich habe auch eine Demo "herausgesucht": Treasure Chest. In Ermangelung einer R8500 (und weil der REF bei mir einen Absturz verursacht) kann ich allerdings nichts über die Unterschiede sagen...

"3 zu 2 mit dem P10. Der P10 kann viel mehr als nur PS 1.4."

Hättest Du dafür bitte einen Beleg ?
Mir ist klar, daß es mehr oder weniger 'frei programmierbar' sein soll, aber daß er explizit PS1.4 (oder DM) unterstützt, wäre mir neu... Soweit ich bisher weiß, soll er keinen PS2.0 unterstützen, insofern wage ich Deine Aussage bezüglich der PS1.4 (die doch den PS2.0 sehr ähnlich sein sollen) in Frage zu stellen.

DX9 erfordert anscheinend, dass der Chip mit Fließkommazahlen rechnet, was der P10 nicht kann.
Wenn der Chip aber mit OpenGL 2.0 Shadern umgehen kann (und damit rechne ich fest), muss ich einfach davon ausgehen, dass der Chip auch PS1.4 bietet.

StefanV

2002-05-20, 02:48:09

Originally posted by aths
Stefan,

dass Parhelia nicht PS.1.4-kompatibel ist hat auch, aber natürlich nicht nur mit den 4 Texturen pro Pass zu tun. Der 1.4-er PixelShader erfordert soweit ich das verstanden habe auch eine etwas andere Combiner-Logik als 1.0 - 1.3.

Richtig, das hätte ich auch angenommen ;)

nur dürfte es schwieriger sein 'mal eben' 2 zusätzliche TMUs zu integrieren als die Combiner.

Ich bin mir sicher, daß MGA PS1.4 sehr gerne eingebaut hätte, es aber aus Zeitgründen ihnen nicht mehr möglich war...

Möglich wäre, daß MGA bald eine überarbeitete Version des Parhelias rausbringt, der 6 TMUs hat und PS1.4 kann ...

Oder halt gleich einen PS2.0, dann aber für 0,13µ, was ja noch nicht alle Produzenten im Griff haben...

aths

2002-05-20, 03:57:50

Stefan,

so gesehen halte ich 3 TMUs / 2x Loopback noch für sinnvoller als 6 TMUs. Für letzteres gäbe es kaum genügend Bandbreite...

Razor

2002-05-20, 09:00:27

@Xmas

"Scheinbar bist du nicht in der Lage mehreren Diskussionen gleichzeitig zu folgen... "

In diesem einen speziellen Fall magst Du recht haben...
Ansonsten bin ich der Meinung, daß ich das schon ganz gut auf die Reihe bekomme.

"Jetzt klar? Es ging nicht um PS 1.4..."

Ist mir jetzt auch klar, aber der vorherige Spruch wäre dazu nicht notwendig gewesen...
Die Darstellungsqualität leiden Wo nimmst du denn das her? Wenn N-Patches richtig verwendet werden sehen sie genauso "ordentlich" wie RT-Patches aus. Und wenn man sie falsch verwendet, sehen sie eben falsch aus... wie RT-Patches auch.
Wenn die N-Patches 'richtig' verwendet werden, dann sind sie ähnlich aufwändig zu programmieren, wie eben polynominale Flächen und der eigentlich Vorteil ist dahin und sie sind damit noch überflüssiger... (weil eben nicht kompatibel)

Aber hier geht es eigentlich nicht um N-Patches...
Sorry, daß ich sie erwähnte.
Warum widersprichst du mir dann, wenn ich sage dass es nicht im Ermessen von NVidia liegt? Sollen die etwa einen absichtlich fehlerhaften Treiber rausbringen, damit ein paar PS1.3 Shader laufen (und andere einen Fehler verursachen)?
Man könnte höchstens einen "experimentellen" Regkey wie beim Radeon verwenden.
Wo ist der Unterschied zwischen einem 'fehlerhafen Treiber' und einem 'experimentellen RegKey' ?
Und ja, so ähnlich habe ich mir das vorgestellt...
(Treiber der sich auch auf der gf3 mit PS1.3 meldet, wenn gewünscht - also aktivierbar/deaktiverbar)
Ich habe auch eine Demo "herausgesucht": Treasure Chest. In Ermangelung einer R8500 (und weil der REF bei mir einen Absturz verursacht) kann ich allerdings nichts über die Unterschiede sagen...
Diese Demo's habe ich zuvor schon ausgeschlossen (wer hat hier nun die Diskussion nicht verfolgt ?).
Übrigens läuft TresureChest ganz hervorragend bei mir (bis PS1.3 ;-)...

Und zwar aus folgendem Grund:
ATI hat nicht versucht, die PS1.4-Effekte auf PS1.1 umzusetzen, obwohl dies nach einhelliger Meinung möglich wäre. Hätte ATI damit gezeigt, daß die PS1.4 eben bei Nutzung dieser sehr viel schneller gewesen wären oder gar bei höherer Präzision gar eine bessere visuelle Qualität erreicht hätten, als bei der 'emulation' über die PS1.1, würde das Sinn machen. Natürlich nur, wenn der Source-Code offen gelegt würde, um auszuschließen, daß ATI da getrixt hat...

So aber machen die ATI-Demo's leider überhaupt keinen Sinn.
Deswegen habe ich ja das 'EngineDemo' genannt, weil es beide Techniken (allerdings unter OpenGL) gegenüber stellt und ev einen Unterschied zutage gefördert hätte. Aber offensichtlich läßt dies das Prog nicht zu, oder die Leutz hier mit einer R8500 können keinen Unterschied zutage fördern (wie auch im B3D-Forum fest gestellt) und damit gibt es effektiv KEIN Beispiel für eine bessere visuelle Qualität durch Darstellung mit PS1.4(-Fähigkeiten).

Und so bleibt meine Vermutung, daß die PS1.4 lediglich Performance-Vorteile (bei Nutzung dieser !) haben eben im Raum stehen, wenn niemand einen Gegenbeweis erbringen kann oder will...
DX9 erfordert anscheinend, dass der Chip mit Fließkommazahlen rechnet, was der P10 nicht kann.
Wenn der Chip aber mit OpenGL 2.0 Shadern umgehen kann (und damit rechne ich fest), muss ich einfach davon ausgehen, dass der Chip auch PS1.4 bietet.
Sehr spekulativ, oder ?
(ich habe wenigstens ein 'ev' dazu geschrieben)

Insofern bleibt es noch bei einem 3-zu-1 und einem Fragezeichen bei dem P10, über den trotz offizieller Vorstellung noch zu viel spekuliert wird...

@aths

Das 'ganze Forum' ?
Also manchmal hat es echt keinen Sinn mit Dir...

Bis denne

Razor

nggalai

2002-05-20, 09:09:23

Err, Razor . . .

Diese Demo's habe ich zuvor schon ausgeschlossen (wer hat hier nun die Diskussion nicht verfolgt ?).
Übrigens läuft TresureChest ganz hervorragend bei mir (bis PS1.3 ;-)...

Und zwar aus folgendem Grund:
ATI hat nicht versucht, die PS1.4-Effekte auf PS1.1 umzusetzen, obwohl dies nach einhelliger Meinung möglich wäre. Hätte ATI damit gezeigt, daß die PS1.4 eben bei Nutzung dieser sehr viel schneller gewesen wären oder gar bei höherer Präzision gar eine bessere visuelle Qualität erreicht hätten, als bei der 'emulation' über die PS1.1, würde das Sinn machen. Natürlich nur, wenn der Source-Code offen gelegt würde, um auszuschließen, daß ATI da getrixt hat...

So aber machen die ATI-Demo's leider überhaupt keinen Sinn.

Xmas said:
Die Treasure Chest Demo ist AFAIK die einzige Vergleichsmöglichkeit, wenn auch nur eingeschränkt. Immerhin gibt es dafür den Sourcecode. Konkrete Fragen:

Woher weisst Du, dass ATi nicht versucht hat, die PS1.4-Effekte auf 1.1 umzusetzen? Woher weisst Du, dass diese speziellen Effekte nach einhelliger Meinung umgesetzt werden können?

Und eben--Sourcecode ist da. Happy hunting. ;)

ta,
.rb

Razor

2002-05-20, 11:03:11

Originally posted by nggalai
Err, Razor . . .

Konkrete Fragen:

Woher weisst Du, dass ATi nicht versucht hat, die PS1.4-Effekte auf 1.1 umzusetzen? Woher weisst Du, dass diese speziellen Effekte nach einhelliger Meinung umgesetzt werden können?

Und eben--Sourcecode ist da. Happy hunting. ;)

Hmmm...
Jemand hat mal den Sourcecode vom TreasureChest gesichtet (Link ist mir 'entfallen') und eben fest gestellt, daß lediglich die PS1.1 und PS1.4 genutzt werden (PS1.1 für die 'obere Reihe', PS1.4 für die 'untere'...). Beim 3DMurks ist offensichtlich zu sehen, daß der 'Advanced Pixel Shader' Test, sowohl auf gf3, als auch auf R200 Hardware läuft, somit hier wohl nur eine Umstzung von PS1.1 auf PS1.4 erfolgt ist, oder eben umgekehrt. Auch konnte mir (AFAIK auch niemanden sonst) ein Effekt auf Basis der PS1.4 gezeigt werden, der nicht durch die PS1.1 dargestellt werden kann.

Auch hätte ATI kein Interesse daran (meine Vermutung !), zu zeigen, daß es zumindest keinen visuellen Unterschied zwischen den PS1.4 (-Fähigkeiten) und denen der Konkurrenz gibt, zumal sie selber postulierten, daß dem so sein sollte, das aber von verschiedenen Stellen (u.a. nVidia) wiederlegt wurde. Und die Performance ist ja bekanntlich von der Hardware abhängig, so könnte es auf einer einfach ausgelegten PS1.1-Karte zwar langsamer laufen, aber auf einer doppelt ausgelegten (ev P10, NV30) dann vielleicht doch schneller, so daß auch dieser 'Vorteil' dahin wäre...

Lange Rede, kurzer Sinn:
Solange mir nicht jemand ein Beispiel eines Effektes oder eine Scene zeigt, die mit den PS1.1 (bis 1.3) nicht darstellbar sind, hat die Aussage ATI's, daß der PS1.4 (bzw. dessen zugrunde liegenden Fähigkeiten) visuelle Vorteile bringt (eigene Anmerkung: die nicht nur auf reiner Performance basieren), keinen Wert !

Und daraus gefolgert, hat es auch keinen (qualitativen) Nachteil, die PS1.4 nicht zu unterstützen und Matrox tat recht daran, sich nicht auf die Architektur ATI's einzulassen.

-

Könnte mir gut vorstellen, daß Du mir nun ev vorhältst, nicht auf Deine Fragen geantwortet zu haben.
Also hier dann nochmal kurz:

"Woher weisst Du, dass ATi nicht versucht hat, die PS1.4-Effekte auf 1.1 umzusetzen?"
-> Weil das Demo dann vermutlich 'anders' aussehen/ausgelegt sein würde...

"Woher weisst Du, dass diese speziellen Effekte nach einhelliger Meinung umgesetzt werden können?"
-> Da der Hauptunterschied die Adressierung von Texturen und die Nutzung von 6 statt 4 Texturen zu sein scheint. Somit diese Effekte dann zwar nicht in einem Renderpass generiert werden können, wohl aber mit mehreren. Und somit meine Gegenfrage: Was sollte dagegen sprechen ?

Bis dann

Razor

Exxtreme

2002-05-20, 11:23:34

@ Razor
Du hast vielleicht einen Aspekt übersehen. Du schreibst selber, daß der PS1.4 Performancevorteile bringen kann. Dadurch _könnte_ man die Qualität/Quantität der PS-Effekte erhöhen ohne daß es zu langsam wird. Und damit _könnten_ die Games doch schöner werden als mit dem PS1.3.

Gruß
Alex

Razor

2002-05-20, 11:43:01

Originally posted by Exxtreme
@ Razor
Du hast vielleicht einen Aspekt übersehen. Du schreibst selber, daß der PS1.4 Performancevorteile bringen kann. Dadurch _könnte_ man die Qualität/Quantität der PS-Effekte erhöhen ohne daß es zu langsam wird. Und damit _könnten_ die Games doch schöner werden als mit dem PS1.3.
Nein, Alex...
Übersehen habe ich diesen Aspekt sicher nicht (zumal er ja auch schon öfters genannt wurde).

Aber schon mit einer etwas anderen Architektur (Dual-PS z.Bsp.) lassen sich diese Effekte dann vermutlich sogar schneller als auf einem R200 via Multipass und ohne PS1.4 realisieren. Auch steht der PS2.0 vor der Tür, der sich dann noch einmal kräftig von den PS1.4 unterscheidet. Insofern halte ich es für wesentlich sinnvoller, wenn man sich auf die PS1.3 beschränkt und dann eben gleich auf die PS2.0 geht.

Die Frage ist halt, ob nun lediglich für den (reinen Zwischenschritt) PS1.4 und damit verbunden die R200 von ATI ein eigener Codepath sinnvoll erscheint, oder eben nicht. Und dazu hat's hier wohl schon genug Aussagen gegeben...

Ich würde sagen: NEIN !
(und IMHO ist das auch gut so)

Bis denne

Razor

Demirug

2002-05-20, 12:04:04

Razor,

Bitte nimm es als gegeben hin das der P10 zu 99% sicher in der Lage ist einen PS1.4 zu emulieren. Die Logikkette dafür ist schlüssig.

1. Der P10 ist laut aussage von 3dLabs OpenGL2.0 fähig und es gibt Prototyptreiber.
2. Die OpenGL20 Fragment-Shader Sprache enthält alle nötigen mathematischen Operationen die für PS1.0 benötigt werden.
3. Die OpenGL20 Fragment-Shader Sprache enthält Texturzugriffsfunktionen die ausreichen für PS1.4
4. Die minimale Anzahl von Konstanten und Variablen bei OpenGL 2.0 Karten im Fragment-Shader bereich ist ebenfalls aureichend.

Zum 3dMark:
Offizieles Statement von MadOnion:

The Advanced Pixel Shader test has a fall-back, using pixel shader 1.1, which is supported by your GF3/4. Hence the name Advanced Pixel Shader test, and not Pixel Shader 1.4 test. That same water effect can be achieved using pixel shader 1.1, but then the water surface is drawn in two passes, compared to a single pass on pixel shader 1.4 (or higher) hardware.

The Advance Pixel Shader test is what we call a Feature Test, which means that we above all want to present some new technology. It was decided that a fall-back was to be included in addition to the 1.4 pixel shader, since a same looking effect can be achieved using pixel shader 1.1. These two different modes of that same test work a bit differently, and should therefore not be directly compared. Both two modes could be optimized to show more performance either way, but now the test is just optimized for maximum compatibility. Vertex shader performance also affects the score somewhat due to this compatibility optimization.

Zur PS 1.4 emulation mit PS 1.x (x <=3). Es gibt Möglichkeiten die man nicht emulieren kann in wie weit diese Sinn machen wäre allerdings noch zu prüfen.

Was nun die Qualität angeht. Wenn eine Engine aufgrund PS1.4 schneller läuft kannst du dich entweder an den FPS erfreuen oder in den meisten fällen dieses mehr an FPS in Qualität umwnadelen (besseres Filtern, AA, Auflösung). So gesehen kann der PS1.4 schon optische Vorteile bringen allerdings nur indirekt.

Edit:
Ups da war jemand schneller. Was deinen Einwand angeht Razor so hast du im Moment recht. Sobald aber NVidia sagt das der NV30 PS1.4 unterstützt ändert sich die Situation wieder etwas und die unterstützung von PS 1.4 muss neu überdacht werden. Bei OpenGL stellt sich die frage ja nicht.
/Edit

Im Endeffekt kann man ATI für das Design des Pixelshaders des R200 loben. Mit ihrem versämniss es rechtzeitig in den DX8 standard aufzunehmen haben sie sich allerdings nicht mit Ruhm bekleckert. Denn das dürfte der Primäre Grund dafür sein das es SIS, Matrox und sogar Nividia es nicht geschaft haben PS 1.4 in Silizium zu verwirklichen.

Hat nun der Endkunden einen Schaden durch diese Situation? Nein! den der Chip hätte unabhängig davon ob nun PS 1.3 oder PS 1.4 implementiert das gleiche gekostet. Die Transitoren häte man dann für etwas anderes verbraten. Un es ist ja mittlerweile eh standard das ein gewisser Prozentsatz der Chipfläche für Features draufgeht die keiner nutzt. Ein weiter Teil ist für Features die erst in 2 jahren Anwendung finden.

StefanV

2002-05-20, 14:25:16

Originally posted by aths
Stefan,

so gesehen halte ich 3 TMUs / 2x Loopback noch für sinnvoller als 6 TMUs. Für letzteres gäbe es kaum genügend Bandbreite...

Nunja, MGA hat sich halt dazu entschieden auf LB zu verzichten und dafür mehr TMUs zu nutzen.

Für zukünftige Games ist das sicher sinniger, da die Perhelia so mehr Leistung hat, was sicher bald von Vorteil sein kann.

Wir werden sehen, was MGA macht (möglicherweise soger einen PS1.5 auf Basis des PS1.4 *eg*)

Aber ehrlichgesagt fehlt mir auch ein Loopback bei der Parhelia.
8 Texturen wären mit lieber als 4.
Aber vielleicht kann die Parhelia das ja...

@Razor

Eine Radeon 8500 hat 60Mio Transistoren, eine GF3 57Mio und eine GF4 63Mio Transistoren.

Allerdings ist die Radeon ein neueres Design als die GF3, die ja bekanntlich auf der TNT Architektur basiert (unified Treiber machen IMO nur bei ähnlichen Architekturen sinn).

Das Heißt, daß ATI ein kleineres DIE haben könnte als NV, was wiederum heißt, daß ATI den Chip billiger Produziern lassen kann, da sie weniger Silizium brauchen und die Ausbeute höher ist (kleineres DIE->höhere Ausbeute).

Sogesehen ist deine Aussage, daß der Radeon mit PS 1.3 billiger sein könnte schwachsinn, auch da ATI an anderer Stelle gespart hat.

Ebenso ist es schwachsinnig von dir, zu behaupten, daß eine fortschrittlichere Architektur schlechter ist.

Jetzt behaupte ich:

DDR-SDRAM ist schwachsinn, SDR RAM hätte gereicht.
TnL ist schwachsinn, da es kaum genutzt wird und Transistoren verbraucht.
RT Patches sind schwachsinn, da sie nie genutzt werden, zumindest nicht zu Lebzeiten der GF3.
32bit Rendering ist schwachsinn.
36bit Internes Rendering ist schwachsinn, da man ja nur maximal 32bit braucht.
Multi Texturing ist schwachsinn, da man ja alles auch mit Single Texturing darstellen kann.

Aber dennoch haben alle aktuellen Chips die meisten der von mir genannten Features!!!
Entweder waren sie leicht zu implementieren, nötig oder haben was gebracht!!!

Genauso ist PS1.4 fortschrittlicher als PS1.3, sei es auch nur, weil der PS1.4 schneller ist.
Multi Texturing hat man zu Lebzeiten der Banshee auch kaum genutzt!!!
Dennoch war der Banshee der letzte Chip, der 'nur' ST konnte!!

Zum Thema zwischenschritt:
Der Riva128 war ein Zwischenschritt zum TNT, der ein zwischenschritt zur GF1, die wiederum zur GF2, GF3 und GF4.

So gesehen ist ALLES ein Zwischenschritt!!
TnL ist ein Zwischenschritt zum Vertex Shader...
Multi Texturing ein Zwischenschritt zum Pixel Shader.

Pixel Shader 1.4 ein Zwischenschritt zum PS2.0, was wiederum ein Zwischenschritt zum PS3.0, was wiederum ein Zwischenschritt zum PS3.0 werden wird.

Der Markt ist in Bewegung, das heißt, daß ALLES nur 'notlösungen' sind, da die entsprechenden Möglichkeiten zum Zeitpunkt des Erscheinens eines Chips nicht unbedingt gegeben sind!!

Die TNT war alles, was man aus den damaligen Fertigungs Prozess (0,35µ) rausholen konnte.

Die GF1 war das beste, was man aus 0,22µ rausholen konnte...

PS2 sind mit dem aktuellen 0,15µ Prozess nicht mehr möglich, da das DIE dann zu groß wird.

Und ab einer bestimmten Größe ist die Fertigung eines DIEs nicht mehr Wirtschaftlich, da man zu viel Ausschuss hätte und das einzelne DIE zu teuer wäre!!

Wie ich erwähnt hab: größeres DIE->größere Kosten, größerer Ausschuß.
Irgendwann hat man dann nur noch 1-2 'gute' Cores pro Wafer, was ja auch nicht sonderlich sinnig ist...

Quasar

2002-05-20, 14:43:30

Originally posted by Demirug

Mit den Pixelshader programmierst du eigentlich zwei Einheiten des Chips:
1.Die TMUs dafür sind die Texture address instructions gut
2.Die Combiner-Logik dafür sind die Arithmetic instructions dar.
Die eigentlichen Combiner-Logik Zellen sind fast identisch.
Bei den TMUs sind dagegen ehrhebliche unterschiede. Die ATI TMUs sind einfacher aufgebaut und deswegen gibt es beim PS 1.4 (der ja special für ATI eingebaut wurde) weniger Befehle dafür.
Dewegen braucht man beim PS1.4 ja auch zwei phasen. In der ersten führt man die nötigen matematischen funktionen auf die Texturekoordinaten durch um sie dann bei der nächsten Phase zu benutzen.
Bei den PS 1.0 - 1.3 Stellt man die mathematische Funktion direkt an der TMU ein und erledigt alles in einem Schritt.
Wenn man nun beim R200 einen PS 1.0 - 1.3 verwendet teilt er die Aktionen intern auf die beiden Phasen auf.
Der PS 1.4 ist dadurch etwas flexibler da er beim texturzugriff nicht auf die max. 18 Zugrifsmöglichkeiten der PS 1.0 - PS 1.3 beschrängt ist.
Alle Klarheiten beseitig?

Nicht ganz, aber danke für diese, für mich komplett neue Information.

Bevor ich mich hier zu vorschnellen Äußerungen hinreißen lasse, will ich erstmal sicher gehen, daß ich das auch richtig verstanden habe:

1. PS1.4-TMUs (gibt ja momentan nur eine Sorte..) sind also simpler, deswegen kann/muss man ihnen Textur- und Mathe-Ops getrennt vorkauen?

2. PS1.3-TMUs (offenbar alle anderen bisher) sind komplexer (=! fortschrittlicher) und deswegen kann/muss man ihnen alles in einem Rutsch vor den Latz knallen?

3. Dadurch entstehen größere Flexibilitäten bei Verwendung von PS1.4, ähnlich wie bei RISC/CISC-Prozessoren?

Frage:
Sind deshalb PS1.1-PS1.3 Emulationen auf PS1.4-Hardware in der Geschwindigkeit etwas gebremst, da sie offenbar "emuliert" werden müssen?

Sind PS1.3 bzw. PS1.4 die lineare Fortführung von hier wiederholt angesprochenen Combinern, die bei nV angeblich schon seit den TNTs flexibler als die ATi-Pendants waren?

Demirug

2002-05-20, 15:37:50

Originally posted by Stefan Payne

Nunja, MGA hat sich halt dazu entschieden auf LB zu verzichten und dafür mehr TMUs zu nutzen.

Für zukünftige Games ist das sicher sinniger, da die Perhelia so mehr Leistung hat, was sicher bald von Vorteil sein kann.

Wir werden sehen, was MGA macht (möglicherweise soger einen PS1.5 auf Basis des PS1.4 *eg*)

Aber ehrlichgesagt fehlt mir auch ein Loopback bei der Parhelia.
8 Texturen wären mit lieber als 4.
Aber vielleicht kann die Parhelia das ja...

Also das mit dem PS1.5 finde ich keine gute Idee das gibt ja noch mehr stress für mich. Bring mir da bloss niemanden auf dumme Ideen:nono: :D

Das mit dem Loopback ist aber ein bischen kritisch. Für jeden Pixel die TMUs 2 mal umprogrammieren. Könnte schlecht für die Performance sein. Dann doch lieber ein paar TMUs mehr. Die nach dem ATI-Model brauchen ja eh weniger Platz und nach dem DIE Shrink sollte das möglich sein.

@Razor

Allerdings ist die Radeon ein neueres Design als die GF3, die ja bekanntlich auf der TNT Architektur basiert (unified Treiber machen IMO nur bei ähnlichen Architekturen sinn).

Naja das mit "unified" glaube ich eh nicht so ganz. Das einzige was da wohl gleich geblieben ist dürfte das Commando Interface in der AGB-Schnittstelle des Treibers sein.

Deinen restlichen aussagen kann ich zustimmen. Ausser dehnen die provokativ gemeint waren:D

StefanV

2002-05-20, 15:46:44

Originally posted by Demirug
[B]

Also das mit dem PS1.5 finde ich keine gute Idee das gibt ja noch mehr stress für mich. Bring mir da bloss niemanden auf dumme Ideen:nono: :D

Das mit dem Loopback ist aber ein bischen kritisch. Für jeden Pixel die TMUs 2 mal umprogrammieren. Könnte schlecht für die Performance sein. Dann doch lieber ein paar TMUs mehr. Die nach dem ATI-Model brauchen ja eh weniger Platz und nach dem DIE Shrink sollte das möglich sein.

Nunja, 'PS1.5' muß ja sich nicht groß von PS1.4 unterscheiden ;)
nur hat MGA 4 TMUs/Pipe, bei LB hätten sie 8.
PS 1.4 kann 'nur' mit 6 Texturen umgehen, daher meine 'Idee' mit PS1.5, der sich von PS 1.4 nur darin unterscheidet, daß er 8 Texturen verarbeiten kann.
Ansonsten sollten sie möglichst identisch sein, da es sonst kaum Sinn macht...

PS1.5=PS1.4, das mit 8 Texturen umgehen kann, aber unter OGL gleich angesprochen wird (mehr oder minder).

Naja das mit "unified" glaube ich eh nicht so ganz. Das einzige was da wohl gleich geblieben ist dürfte das Commando Interface in der AGB-Schnittstelle des Treibers sein.
Viel versteh ich von Treibern zwar nicht, allerdings würde eine UMA Architektur nur dann sinn machen, wenn ein großer Teil des Codes für alle Chips verwendet warden kann.
Das Bedeutet IMO auch, daß viele Teile von 2 Chips gleich sein müssen.

Deinen restlichen aussagen kann ich zustimmen. Ausser dehnen die provokativ gemeint waren:D

Welche waren denn Provokativ gemeint?? ;)

Demirug

2002-05-20, 16:04:05

Originally posted by Quasar

Nicht ganz, aber danke für diese, für mich komplett neue Information.

Bevor ich mich hier zu vorschnellen Äußerungen hinreißen lasse, will ich erstmal sicher gehen, daß ich das auch richtig verstanden habe:

1. PS1.4-TMUs (gibt ja momentan nur eine Sorte..) sind also simpler, deswegen kann/muss man ihnen Textur- und Mathe-Ops getrennt vorkauen?

Die PS1.4 TMUs sind simpler. Sie können im Gegensatz zu den PS 1.0- PS1.3 (wir sollte uns hier mal eine abkürzung einfallen lassen) nur ganz einfache Mathe-Ops. Die komplizierten Sachen (Matrix-Multiplikationen) werden bei dieser Architecktur von den gleichen Zellen übernommen die auch die farbwerte berechnen. Deswegen gibt es bei PS1.4 ja auch 2 Phasen.

2. PS1.3-TMUs (offenbar alle anderen bisher) sind komplexer (=! fortschrittlicher) und deswegen kann/muss man ihnen alles in einem Rutsch vor den Latz knallen?

=! fortschrittlicher: Sie sind anders bewerten will ich das nichts.
Sie können eben nur eine beschrängte Anzahl von OPS diese aber sehr schnell.

3. Dadurch entstehen größere Flexibilitäten bei Verwendung von PS1.4, ähnlich wie bei RISC/CISC-Prozessoren?

Genau wobei der RISC/CISC vergleich nicht ganz past. Wir haben aber bisher noch kein Beispiel gefunden das diese Flexibilitäten nutzt.

Frage:
Sind deshalb PS1.1-PS1.3 Emulationen auf PS1.4-Hardware in der Geschwindigkeit etwas gebremst, da sie offenbar "emuliert" werden müssen?

Das ist schwer zu beantworten. Es hängt von der spezifischen implementierung der PS1.4 architecktur ab.

Sind PS1.3 bzw. PS1.4 die lineare Fortführung von hier wiederholt angesprochenen Combinern, die bei nV angeblich schon seit den TNTs flexibler als die ATi-Pendants waren?

Die NV Combinern sind gleichzusetzten mit den Zellen für die Mathe-Ops bei PS1.0-PS1.3. Bei NV können diese allerdings nur mit Farben und Alpha Werten rechnen. Die PS1.4 Combinder können zusätzlich noch mit Texturkorrdinaten rechnen.

Bei den PS 1.4 haben wir es also mit einer Verschiebung der Zuständigkeiten zu tuhen. Vorher wurde die Texturkorrdinaten von den TMUs berechnet jetzt machen es die Combinder.

Ich könnte mir durchaus vorstellen das ATi zu dieser Technik gewechselt weil sie weniger Transitoren braucht (Spekulation). Und am ende war dann eben im Pixelshader Bereich noch platz für zwei zusätzliche TMUs. So wie man heute Chips desingt waren die schnell einzufügen. Zumindestens würde das für mich einiged erklären.

Falls ich mich irgendwo nicht verständlich genung ausgedrückt habe einfach nachharcken.

Demirug

2002-05-20, 16:12:15

Originally posted by Stefan Payne

Nunja, 'PS1.5' muß ja sich nicht groß von PS1.4 unterscheiden ;)
nur hat MGA 4 TMUs/Pipe, bei LB hätten sie 8.
PS 1.4 kann 'nur' mit 6 Texturen umgehen, daher meine 'Idee' mit PS1.5, der sich von PS 1.4 nur darin unterscheidet, daß er 8 Texturen verarbeiten kann.
Ansonsten sollten sie möglichst identisch sein, da es sonst kaum Sinn macht...

PS1.5=PS1.4, das mit 8 Texturen umgehen kann, aber unter OGL gleich angesprochen wird (mehr oder minder).

Ok damit könnte ich leben. Allerdings müsste man auch die Anzahl der Matheops erhöhen.

Viel versteh ich von Treibern zwar nicht, allerdings würde eine UMA Architektur nur dann sinn machen, wenn ein großer Teil des Codes für alle Chips verwendet warden kann.
Das Bedeutet IMO auch, daß viele Teile von 2 Chips gleich sein müssen.

Das ist nicht zwangsläufig so. Ich kenne eine Firma deren Karten (keine GraKas) werden alle durch einen einzigen Treiber gesteuert. Die Karten haben aber ein gänzlich unterschiedliches Desgin.

Trotzdem werden gewisse Teile des TNT Desgins immer noch in der GF4 drinstecken. Das hängt einfach mit der Art und weise wie man heute Chips designt zusammen.

Welche waren denn Provokativ gemeint?? ;)

Ich meine das was nach "Jetzt behaupte ich:" kamm. Das ja wohl ein bischen zur provokation gedacht war.

zeckensack

2002-05-20, 16:27:02

Originally posted by Razor
Wenn die N-Patches 'richtig' verwendet werden, dann sind sie ähnlich aufwändig zu programmieren, wie eben polynominale Flächen und der eigentlich Vorteil ist dahin und sie sind damit noch überflüssiger... (weil eben nicht kompatibel)

Aber hier geht es eigentlich nicht um N-Patches...
Sorry, daß ich sie erwähnte.Sorry, daß ich darauf antworte ;)
Alles, was man für N-Patches braucht, sind vernünftige Vertex Normals. Man muß seine Geometrie halt so aufbauen, daß auch Hardwarebeleuchtung funktionieren würde, ie auf 'weichen' Oberflächen sitzt auf einem Eckpunkt die gemittelten Oberflächennormale der angrenzenden Dreiecke, bei harten Kanten muß der Vertex mit unterschiedlichen Normalen verdoppelt werden. Wenn ein Mesh diese Voraussetzungen erfüllt (nochmal: HW-Licht braucht genau die gleichen), dann kann ich TruForm und N-Patches problemfrei nutzen, ohne wenn und aber.

StefanV

2002-05-20, 16:33:33

Originally posted by Demirug
Ok damit könnte ich leben. Allerdings müsste man auch die Anzahl der Matheops erhöhen.

Dürfte auch kein Problem sein, oder?

Das ist nicht zwangsläufig so. Ich kenne eine Firma deren Karten (keine GraKas) werden alle durch einen einzigen Treiber gesteuert. Die Karten haben aber ein gänzlich unterschiedliches Desgin.

hm, dann ist es wohl ein 'Treiberpaket', das den richtigen auswählt, damit der User bei einer automatischen Installation keine Fehler machen kann...

Trotzdem werden gewisse Teile des TNT Desgins immer noch in der GF4 drinstecken. Das hängt einfach mit der Art und weise wie man heute Chips designt zusammen.
Was ich für schlecht halte, da ich das Design des TNT für 'nicht optimal' halte (groß, verbrät viel Leistung, 16->32bit starker einbruch).
Der Rage 128 war damals vom Design her besser, da er weniger verlustleistung hatte und der Einbruch von 16bit auf 32bit nicht so stark war.
und der Rage128 ließ sich etwas höher takten als die TNT (90->103MHz)
auch hat der TNT recht viele Transistoren verschlungen...

Ich meine das was nach "Jetzt behaupte ich:" kamm. Das ja wohl ein bischen zur provokation gedacht war.

Gewürzt mit einer Prise sarkasmus ;)

Außer DDR-SDRAM hat keins der von mir genannten Features wirklich was gebracht oder war sinnvoll nutzbar.
Heute könnte man ohne diese Features (außer RT-Patches) nicht mehr leben...
Ich hätte noch mehr Features nennen können, die zum Zeitpunkt der Einführung nix gebracht haben, heute aber oft genutzt werden, aber ich wollte nicht mehr schreiben ;)

Was ich damit sagen wollte sit folgendes:

Wir können jetzt schwer beurteilen, ob PS1.4 sinnvoll ist oder nicht.
Das können wir wohl erst in 1-2 Jahren, ähnlich, wie es bei Multi Texturing damals war.
Als die Banshee rauskam wurde es auch kaum genutzt, heute wird es in jedem Spiel genutzt.
Gleiches für 32bit Rendering:
Damals war es kaum sinnvoll, da die Performance für 32bit kaum gereicht hat, weswegen die Spielehersteller auf 16bit optimiert haben und 32bit als Option bieten.
Heute ist es umgekehrt ;)
Die Spiele werden auf 32bit 'optimiert' und bieten 16bit als Option an.

ergo:
ob NVPS (PS1.0-1.3) oder PS1.4 besser ist, das können wir jetzt nicht beurteilen!
Genausowenig wie MT, TnL und 32bit bei der Einführung.

StefanV

2002-05-20, 16:36:52

Originally posted by zeckensack
Sorry, daß ich darauf antworte ;)
Alles, was man für N-Patches braucht, sind vernünftige Vertex Normals. Man muß seine Geometrie halt so aufbauen, daß auch Hardwarebeleuchtung funktionieren würde, ie auf 'weichen' Oberflächen sitzt auf einem Eckpunkt die gemittelten Oberflächennormale der angrenzenden Dreiecke, bei harten Kanten muß der Vertex mit unterschiedlichen Normalen verdoppelt werden. Wenn ein Mesh diese Voraussetzungen erfüllt (nochmal: HW-Licht braucht genau die gleichen), dann kann ich TruForm und N-Patches problemfrei nutzen, ohne wenn und aber.

Ich geh mal davon aus, daß bald einige Games erscheinen, die von N-Patches 'richtig' gebrauch machen.

Und keine Pseudo Truform anpassungen sind.

Der Vorteil von N-Patches gegenüber RT-Patches ist die bessere abwärtskompatiblität zu Chips, die das nicht haben.

Bei RT-Patches brauch ich für die kompatiblität zu herkömlichen Renderern eine 'emulation' in der Engine oder aber 2 Meshes.
N-Patches werden von Chips, die es nicht können ignoriert.
Ist also lauffähig, sieht aber bescheiden aus, da nur wenige 3ecke genutzt werden.

Xmas

2002-05-20, 16:39:09

Originally posted by Razor
Diese Demo's habe ich zuvor schon ausgeschlossen (wer hat hier nun die Diskussion nicht verfolgt ?).
Nun, ich schließe TC eben nicht aus, wieso auch?

Und zwar aus folgendem Grund:
ATI hat nicht versucht, die PS1.4-Effekte auf PS1.1 umzusetzen, obwohl dies nach einhelliger Meinung möglich wäre.
Natürlich haben sie das nicht! Sie haben versucht, PS1.4-Effekte zu zeigen, die nicht mit PS1.1 machbar sind. Wie sollten sie diese auf PS1.1 "umsetzen"?

So wie du dir das vorstellst programmiert man keine Shader. Da geht man von einem physikalischen Modell für einen bestimmten Sachverhalt aus und versucht dies, so gut es geht mit den gegebenen Möglichkeiten nachzuahmen. Dass dann die PS1.4-Variante anders als die PS1.1-Variante aussieht, und nicht nur PS1.1 mit höherer Rechenpräzision ist, ist nicht verwunderlich.

"Nach einhelliger Meinung" - Wessen Meinung? Nach meiner jedenfalls nicht.

Hätte ATI damit gezeigt, daß die PS1.4 eben bei Nutzung dieser sehr viel schneller gewesen wären oder gar bei höherer Präzision gar eine bessere visuelle Qualität erreicht hätten, als bei der 'emulation' über die PS1.1, würde das Sinn machen. Natürlich nur, wenn der Source-Code offen gelegt würde, um auszuschließen, daß ATI da getrixt hat...

So aber machen die ATI-Demo's leider überhaupt keinen Sinn.
Dann hast du denn Sinn nur nicht verstanden.

Originally posted by Razor
Auch konnte mir (AFAIK auch niemanden sonst) ein Effekt auf Basis der PS1.4 gezeigt werden, der nicht durch die PS1.1 dargestellt werden kann.
ATI-Demos?

Auch hätte ATI kein Interesse daran (meine Vermutung !), zu zeigen, daß es zumindest keinen visuellen Unterschied zwischen den PS1.4 (-Fähigkeiten) und denen der Konkurrenz gibt, zumal sie selber postulierten, daß dem so sein sollte, das aber von verschiedenen Stellen (u.a. nVidia) wiederlegt wurde.

Lange Rede, kurzer Sinn:
Solange mir nicht jemand ein Beispiel eines Effektes oder eine Scene zeigt, die mit den PS1.1 (bis 1.3) nicht darstellbar sind, hat die Aussage ATI's, daß der PS1.4 (bzw. dessen zugrunde liegenden Fähigkeiten) visuelle Vorteile bringt (eigene Anmerkung: die nicht nur auf reiner Performance basieren), keinen Wert !
ATI haben mit ihren Demos vorgelegt. Einen Gegenbeweis, dass all das auch mit PS1.1 möglich ist, habe ich noch nicht gesehen, nur schwammige Aussagen von NVidia.

"Woher weisst Du, dass diese speziellen Effekte nach einhelliger Meinung umgesetzt werden können?"
-> Da der Hauptunterschied die Adressierung von Texturen und die Nutzung von 6 statt 4 Texturen zu sein scheint. Somit diese Effekte dann zwar nicht in einem Renderpass generiert werden können, wohl aber mit mehreren.
Sehr spekulativ, findest du nicht?

Demirug

2002-05-20, 16:45:58

Originally posted by zeckensack
Sorry, daß ich darauf antworte ;)
Alles, was man für N-Patches braucht, sind vernünftige Vertex Normals. Man muß seine Geometrie halt so aufbauen, daß auch Hardwarebeleuchtung funktionieren würde, ie auf 'weichen' Oberflächen sitzt auf einem Eckpunkt die gemittelten Oberflächennormale der angrenzenden Dreiecke, bei harten Kanten muß der Vertex mit unterschiedlichen Normalen verdoppelt werden. Wenn ein Mesh diese Voraussetzungen erfüllt (nochmal: HW-Licht braucht genau die gleichen), dann kann ich TruForm und N-Patches problemfrei nutzen, ohne wenn und aber.

Du hast vollkommen recht für den Programmier sind TruFrom und N-Patches ein leichtes. Zumindestens unter DX. Unter OpenGL wirds aber wohl genauso einfach sein.

Das Problem ist nur die Geometrie. Die Momentan verwendeten Modler (3ds, Maya, usw.) sind im Bezug auf erzeugen von brauchbarer Geometrie für TruFrom einfach nicht das wahre.

Man braucht diese Normalen zwar auch fürs Vertexlight aber wer benutzt das schon. Und selbst wenn bis dann noch die Texturen drauf sind fält es meistens nicht auf da Vertex Light sowieso bescheiden ist. Wenn allerdings die Geometire plötzlich Löcher oder ähnliches hat sticht einem das sofort ins Auge. Ist also mal wieder eine Frage des Mehraufwandes.

Demirug

2002-05-20, 16:53:50

Originally posted by Stefan Payne

Dürfte auch kein Problem sein, oder?

Nein man muss halt nur daran denken sonst sind die 2 zusätzlichen Texturen nutzlos weil man nicht genug Ops hat um sie zu verechnen.

Was ich für schlecht halte, da ich das Design des TNT für 'nicht optimal' halte (groß, verbrät viel Leistung, 16->32bit starker einbruch).
Der Rage 128 war damals vom Design her besser, da er weniger verlustleistung hatte und der Einbruch von 16bit auf 32bit nicht so stark war.
und der Rage128 ließ sich etwas höher takten als die TNT (90->103MHz)
auch hat der TNT recht viele Transistoren verschlungen...

Bei den momentanen Update intervallen bleibt dir fast nicht anderes übrig als gewiesse Teile des Desgins wieder zu verwenden. Was die Transitoren und Taktrateangeht könnte das durchaus auch an einem besseren Chipcompiler gelegen haben.

Was ich damit sagen wollte sit folgendes:

Wir können jetzt schwer beurteilen, ob PS1.4 sinnvoll ist oder nicht.
Das können wir wohl erst in 1-2 Jahren, ähnlich, wie es bei Multi Texturing damals war.
Als die Banshee rauskam wurde es auch kaum genutzt, heute wird es in jedem Spiel genutzt.
Gleiches für 32bit Rendering:
Damals war es kaum sinnvoll, da die Performance für 32bit kaum gereicht hat, weswegen die Spielehersteller auf 16bit optimiert haben und 32bit als Option bieten.
Heute ist es umgekehrt ;)
Die Spiele werden auf 32bit 'optimiert' und bieten 16bit als Option an.

ergo:
ob NVPS (PS1.0-1.3) oder PS1.4 besser ist, das können wir jetzt nicht beurteilen!
Genausowenig wie MT, TnL und 32bit bei der Einführung.

Richtig. Im Prinzip können die Chiphersteller nur irgenwelche Dinge einbauen und abwarten ob wir Spieleentwickler darauf anspringen.

Razor

2002-05-20, 17:08:28

@Demirug
Bitte nimm es als gegeben hin das der P10 zu 99% sicher in der Lage ist einen PS1.4 zu emulieren. Die Logikkette dafür ist schlüssig.
Ich habe es mit einem Fragezeichen versehen, das sollte reichen...
(allem weiteren werden wir dann ja gwahr ;-)
Zur PS 1.4 emulation mit PS 1.x (x <=3). Es gibt Möglichkeiten die man nicht emulieren kann in wie weit diese Sinn machen wäre allerdings noch zu prüfen.
Und diese in Praxis (!) überführten Möglichkeiten interessieren mich eben, natürlich auch deren Sinn...
Was nun die Qualität angeht. Wenn eine Engine aufgrund PS1.4 schneller läuft kannst du dich entweder an den FPS erfreuen oder in den meisten fällen dieses mehr an FPS in Qualität umwnadelen (besseres Filtern, AA, Auflösung). So gesehen kann der PS1.4 schon optische Vorteile bringen allerdings nur indirekt.
Du sagtest selber "Wenn eine Engine aufgrund PS1.4..."...
Und dieses würde mich ja ebenfalls interessieren. Auch hat Dein Zitat von MadOnion ja heraus gestellt, daß es sogar möglich ist, daß die PS1.0/3 (wäre doch eine passende Abkürzung ;-) durchaus schneller sein können, als die PS1.4, je nachdem wie der Effekt realisiert wurde, bzw. auf welchen PS er optimiert wurde.

Insofern ist nicht einmal die generelle Aussage zu halten, daß PS1.4 grundsätzlich schneller sind.
(Danke nochmal für dieses Zitat)
Ups da war jemand schneller. Was deinen Einwand angeht Razor so hast du im Moment recht. Sobald aber NVidia sagt das der NV30 PS1.4 unterstützt ändert sich die Situation wieder etwas und die unterstützung von PS 1.4 muss neu überdacht werden. Bei OpenGL stellt sich die frage ja nicht.
Was abzuwarten bliebe, aber durchaus wahrscheinlich sein könnte...
Würde aber voraussetzen, daß der P10 tatsächlich PS1.4 emulieren kann (zwei PS1.3 halte ich für wahrscheinlicher, was sich aber nicht ausschließen muß). Aber selbst dann wäre die Hardwarebasis dafür noch für eine lange Zeit verschwindend gering. Auch würde ja noch der R300 dazu kommen, der dann ebenfalls PS2.0 unterstützen wird. Insofern sich dann natürlich die Frage stellt, warum das die Situation für PS1.4 ändern sollte (und sich nicht doch eher in Richtung PS2.0 entwicklelt)...

Aber das ist sehr viel Spekulation und ausgehend von der jetzigen Situation siehts halt 'etwas' anders aus.
Im Endeffekt kann man ATI für das Design des Pixelshaders des R200 loben. Mit ihrem versämniss es rechtzeitig in den DX8 standard aufzunehmen haben sie sich allerdings nicht mit Ruhm bekleckert. Denn das dürfte der Primäre Grund dafür sein das es SIS, Matrox und sogar Nividia es nicht geschaft haben PS 1.4 in Silizium zu verwirklichen.

Hat nun der Endkunden einen Schaden durch diese Situation? Nein! den der Chip hätte unabhängig davon ob nun PS 1.3 oder PS 1.4 implementiert das gleiche gekostet. Die Transitoren häte man dann für etwas anderes verbraten. Un es ist ja mittlerweile eh standard das ein gewisser Prozentsatz der Chipfläche für Features draufgeht die keiner nutzt. Ein weiter Teil ist für Features die erst in 2 jahren Anwendung finden.
Du behandelst hier das Thema, ob R8500-Kunden dadurch (PS1.4 Nicht-Akzeptanz) einen wirtschaftlichen Schaden erlitten ? So habe ich das nicht gemeint... Ihre Karte ist ja erst sehr spät gekommen (und viele haben darauf gewartet). Auch kommt der wirkliche Fortschritt dieser Karte (PS1.4) nicht zum Zuge, weil sie so spät kam. Auch scheinen keine (DX-)Entwickler dies zu nutzen, insofern hätten sie vielleicht mehr (unnütze) Features erhalten, hätte ATI lediglich auf den PS1.0/3 gesetzt und wäre dafür sehr viel früher am Markt gewesen.

Aber das ist natürlich nur rein hypothetisch und führt eigentlich zu nichts.
Und nein, einen wirtschaftlichen Schaden hatte ich nicht gemeint.
Naja das mit "unified" glaube ich eh nicht so ganz. Das einzige was da wohl gleich geblieben ist dürfte das Commando Interface in der AGB-Schnittstelle des Treibers sein.
Dieser Müll kam von Stefan, der ja bekanntlich ein leichtes Problem mit NV hat. Zu behaupten, daß die gf3/4-Technik noch immer auf dem TNT basiert (ja, alle Karten benutzen Transistoren ! :D) ist schon ein hartes Stück. Auch hat er offensichtlich nicht verstanden, was mit dem Begriff UDA ('Unified Driver Archtecture') gemeint ist. Der einzig logische Schluß ist für ihn wohl offensichtlich, daß nicht der Trieber eine ähnliche Architektur besitzt, sondern die Hardware. Aber Du kannst gerne versuchen, ihn vom Gegenteill zu überzeugen...
;-)

@zeckensack
Wenn ein Mesh diese Voraussetzungen erfüllt (nochmal: HW-Licht braucht genau die gleichen), dann kann ich TruForm und N-Patches problemfrei nutzen, ohne wenn und aber.
Ohne, daß Dinge 'gerundet' werden, die nicht 'gerundet' werden sollen ?
???

@Xmas
Nun, ich schließe TC eben nicht aus, wieso auch?
TC ?
???
Natürlich haben sie das nicht! Sie haben versucht, PS1.4-Effekte zu zeigen, die nicht mit PS1.1 machbar sind. Wie sollten sie diese auf PS1.1 "umsetzen"?
Dafür bist nun aber Du den Beweis schuldig...
(so wie ihn nggalai von mir forderte)
So wie du dir das vorstellst programmiert man keine Shader. Da geht man von einem physikalischen Modell für einen bestimmten Sachverhalt aus und versucht dies, so gut es geht mit den gegebenen Möglichkeiten nachzuahmen. Dass dann die PS1.4-Variante anders als die PS1.1-Variante aussieht, und nicht nur PS1.1 mit höherer Rechenpräzision ist, ist nicht verwunderlich.
Meine mal gelesen zu haben, daß alle im TresureChest-Demo gezeigten Effekte auch mit dem PS1.0/1 generiert werden können. Insofern sage mir doch bitte mal, was an den TresureChest (PS1.4) Effekten denn nicht mit den 'niedrigeren' PS gemacht werden kann...
Dann hast du denn Sinn nur nicht verstanden.
Den Sinn von was ?
???
ATI-Demos?
Irgedwie drehen wir uns im Kreis !
;D
ATI haben mit ihren Demos vorgelegt. Einen Gegenbeweis, dass all das auch mit PS1.1 möglich ist, habe ich noch nicht gesehen, nur schwammige Aussagen von NVidia.

-

Sehr spekulativ, findest du nicht?
Nicht unbedingt...
Zumal es andere gibt, die ähnliches darlegten...

Bis denne

Razor

P.S.: Stefan, zu Deinem langen Redeschwall (der fast komplett am Thema vorbei geht) fällt mir eigenlich nur eines ein:

Du bist also der Meinung, daß es KEINEN Standard gibt ?

zeckensack

2002-05-20, 17:11:33

Originally posted by Razor @zeckensack

Ohne, daß Dinge 'gerundet' werden, die nicht 'gerundet' werden sollen ?
???Ganz genau.
Link folgt sogleich ...

edit: Hier isser:
http://www.reactorcritical.com/review-truform/review-truform.shtml
edit2: Insbesondere Seite #4 "The Problems" sollte die Erleuchtung bringen.

Exxtreme

2002-05-20, 17:14:01

StefanV

2002-05-20, 17:17:41

P.S.: Stefan, zu Deinem langen Redeschwall (der fast komplett am Thema vorbei geht) fällt mir eigenlich nur eines ein:

Du bist also der Meinung, daß es KEINEN Standard gibt ?

Nein!!

Ich bin der Meinung, daß man bei erscheinen eines Features nicht beurteilen kann, ob es sinnvoll ist, oder nicht!!

Dazu muß das Feature mindestens 2 Jahre auf dem Markt sein, meist noch mehr, bis man 'richtige' Resultate sieht.

zu N-Patches:

Hättest du meinen Post zu N-Patches gelesen, dann wüsstest du, daß N-Patches im Gegensatz zu RT-Pachtes zu bestehender Hardware kompatibel ist!!

Ist genauso kompatibel, wie eine auf HW TnL ausgelegte Engine, nur daß die Poligone in diesem Fall etwas eckiger sind...

noch etwas:

Dieser Müll kam von Stefan, der ja bekanntlich ein leichtes Problem mit NV hat. Zu behaupten, daß die gf3/4-Technik noch immer auf dem TNT basiert (ja, alle Karten benutzen Transistoren ! ) ist schon ein hartes Stück. Auch hat er offensichtlich nicht verstanden, was mit dem Begriff UDA ('Unified Driver Archtecture') gemeint ist. Der einzig logische Schluß ist für ihn wohl offensichtlich, daß nicht der Trieber eine ähnliche Architektur besitzt, sondern die Hardware. Aber Du kannst gerne versuchen, ihn vom Gegenteill zu überzeugen...

Tja, dafür liefen bei mir bislang alle ATI Karten ohne Nennenswerte Probleme *eg*

Auch verstehe ich nicht, was daran so schlimm sein soll, das die GFs auf der TNT basieren, was mir Demirug ja bestätigt hat??

zeckensack

2002-05-20, 17:20:12

Originally posted by Demirug
Das Problem ist nur die Geometrie. Die Momentan verwendeten Modler (3ds, Maya, usw.) sind im Bezug auf erzeugen von brauchbarer Geometrie für TruFrom einfach nicht das wahre.

Man braucht diese Normalen zwar auch fürs Vertexlight aber wer benutzt das schon. Und selbst wenn bis dann noch die Texturen drauf sind fält es meistens nicht auf da Vertex Light sowieso bescheiden ist. Wenn allerdings die Geometire plötzlich Löcher oder ähnliches hat sticht einem das sofort ins Auge. Ist also mal wieder eine Frage des Mehraufwandes. Umgekehrt geht's aber auch wieder:
Durch TruForm wird Vertex Lighting ganz plötzlich brauchbar, da es die Zahl der Abtastpunkte für die Beleuchtung massiv erhöht ;)

Man könnte das doch so lösen:
1)Man hat ein TruForm-taugliches Mesh
2)Auf Karten ohne TruForm benutzt man dieses mit Lightmapping
3)Auf Karten mit TruForm schaltet man das HW-Licht an und läßt die Lightmap weg

Exxtreme

2002-05-20, 17:21:23

Originally posted by Razor

Ohne, daß Dinge 'gerundet' werden, die nicht 'gerundet' werden sollen ?
???

Man muss halt die Stellen im Objekt markieren, die gerundet werden sollen. Mehr nicht. Aber anscheinend schaffen es die Leute irgendwie nicht und setzen die Rundungen für das gesamte Objekt. Wie es am Ende aussieht wissen wir ja.

Gruß
Alex

StefanV

2002-05-20, 17:25:52

Originally posted by Exxtreme

Man muss halt die Stellen im Objekt markieren, die gerundet werden sollen. Mehr nicht. Aber anscheinend schaffen es die Leute irgendwie nicht und setzen die Rundungen für das gesamte Objekt. Wie es am Ende aussieht wissen wir ja.

Richtig.

Vereinfacht ausgedrückt muß man bei N-Patches 'nur' die Stellen Markieren, die 'geTruformt' werden sollen.

Macht man das nicht, so ist das Ergebnis nicht so schön, was wir ja an bestehenden Spielen, die N-Patches verwenden, sehen...

Wobei das meist '5min Implementierungen' sind...

Demirug

2002-05-20, 17:28:48

Originally posted by zeckensack
Umgekehrt geht's aber auch wieder:
Durch TruForm wird Vertex Lighting ganz plötzlich brauchbar, da es die Zahl der Abtastpunkte für die Beleuchtung massiv erhöht ;)

Richtig das war ja eine der Ideen hinter TruForm und den HOS im Allgemeinen.

Man könnte das doch so lösen:
1)Man hat ein TruForm-taugliches Mesh
2)Auf Karten ohne TruForm benutzt man dieses mit Lightmapping
3)Auf Karten mit TruForm schaltet man das HW-Licht an und läßt die Lightmap weg

Nette Idee. Aber ganz im vertrauen die meisten Engines unterstützen HW-Licht nicht richtig. Um alos TruFrom richtig zu nutzen müssten die Entwickler erstmal iheren HW-Licht support aufmöbeln. Deshalb hat das mit der ATi Idee das es jetzt für alle Spiele TruForm Patches gibt nicht hingehauen. Denn wenn du eine Vorher gerechnete Lightmap plötzlich mit TruForm verbindest können witzige sachen passieren.

Korak

2002-05-20, 17:29:55

darf ich hier mal kurz einen Cut machen?

Ich misch mich ja nur ungern in diese sehr äh interessante :bonk: Diskussion ein, aber ich glaub es wird mal Zeit dafür. Denn ehrlich gesagt blick ich hier nicht mehr durch wer,was von wem wegen was bewiesen haben will.
Seh ich das richtig, dass ihr alle(!) versucht Razor zu überzeugen, dass der PS 1.4 mehr kann als der PS 1.1/1.3???
Und seh ich das richtig, dass Razor der Meinung ist, dass man mit PS 1.1 und 1.3 in der Lage ist alles zu emulieren??? (wenn ja wozu dann PS 1.3?/ wenn nein dann können wir die Diskussion ja beenden ;))
Ich will das nur schnell mal geklärt haben. Denn wie schon gesagt verlier ich den Überblick. :)

StefanV

2002-05-20, 17:32:19

Originally posted by Korak
darf ich hier mal kurz einen Cut machen?

Ich misch mich ja nur ungern in diese sehr äh interessante :bonk: Diskussion ein, aber ich glaub es wird mal Zeit dafür. Denn ehrlich gesagt blick ich hier nicht mehr durch wer,was von wem wegen was bewiesen haben will.
Seh ich das richtig, dass ihr alle(!) versucht Razor zu überzeugen, dass der PS 1.4 mehr kann als der PS 1.1/1.3???
Und seh ich das richtig, dass Razor der Meinung ist, dass man mit PS 1.1 und 1.3 in der Lage ist alles zu emulieren??? (wenn ja wozu dann PS 1.3?/ wenn nein dann können wir die Diskussion ja beenden ;))
Ich will das nur schnell mal geklärt haben. Denn wie schon gesagt verlier ich den Überblick. :)

Nein, du hast ihn nicht verloren ;)

Es ist genau so, wie du es gesehen hast *eg*

Demirug

2002-05-20, 18:09:25

Also ich hab hier noch ein paar Infos von jemand der gute Beziehungen zu MS und den Chip hersteller hat:

1. Jede Karte die ps2.0 unterstützt muß auch ps1.4 unterstützen.

2. Auf einer Radeon 8500 ist der gleiche Effect mit ps1.4 schneller als mit ps1.0/3.

Xmas

2002-05-21, 00:43:02

Originally posted by Razor
TC ?
???
Treasure Chest

Dafür bist nun aber Du den Beweis schuldig...
(so wie ihn nggalai von mir forderte)
Den Beweis für was? Dass man die Effekte der TC-Demo nicht mit PS1.1 darstellen kann? Nun, ich verlange den Gegenbeweis. Denn der wäre, falls es ihn denn überhaupt gibt, viel einfacher zu erbringen: mit einem Beispiel, dass es geht.

Meine mal gelesen zu haben, daß alle im TresureChest-Demo gezeigten Effekte auch mit dem PS1.0/1 generiert werden können. Insofern sage mir doch bitte mal, was an den TresureChest (PS1.4) Effekten denn nicht mit den 'niedrigeren' PS gemacht werden kann...
Ich meine auch mal gelesen zu haben dass es einen Weltmarkt für vielleicht 5 Computer gibt.
Ich werd jetzt sicher nicht die TC-Source auseinandernehmen, da lass ich dich lieber in dem Glauben dass PS1.1 schon alles kann.

Den Sinn von was ?
???
Liest du auch was ich quote?

Razor: So aber machen die ATI-Demo's leider überhaupt keinen Sinn.

Irgedwie drehen wir uns im Kreis !
;D
Ich dreh mich jedenfalls nicht im Kreis, höchstens meine Hand...

wulfman

2002-05-21, 11:23:01

ich sorge jetzt einfach mal für etwas abwechslung, ein ut2003 screenshot ist aufgetaucht, aber was für einer...

entschuldigt das große bild.
http://home.t-online.de/~zsack/UT2003-3.jpg

mfg
wulfman

PS.: erbarmt sich jemand und hostet die datei auf einem schnelleren server? [edit] thx zeckensack

PPS.: http://forums.matroxusers.com/showthread.php?s=&threadid=33171

Demirug

2002-05-21, 12:03:25

Hüsch! Ein "Surround Gaming" Shot?

Das Gras ist sehr gut vorgetäust. Musste 2 mal hinschauen bis ichs gemerkt habe.

Was mich aber mehr interesiert hätte wären dynamischen licht und schatten effekte. Aber sowas sieht man ja eh nur in Videos.

Quasar

2002-05-21, 13:24:01

Für FSAA hat's dann aber wohl doch nicht gereicht....schade.

zeckensack

2002-05-21, 15:36:58

Hab den Shot auch mal hier geuppt:
http://home.t-online.de/~zsack/UT2003-3.jpg

PS: dauert immer ein paar Minuten.

Torian.cc

2002-05-21, 20:30:54

@zeckensack

WOW, das ist schon seeeeehr beeindruckend!!

Vor allem wenn man dabei berücksichtigt, daß das ganze in einer Auflösung von 3840 x 1024 läuft!
Wenn dann noch die Framerate in spielbaren Regionen bleibt...., ich glaube, Parhelia-Käufer mit "nur" einem Monitor brauchen sich Performance-mäßig keine Sorgen zu machen ;o)

MfG
Tori
__________

MATROX RULEZ

jedi

2002-05-21, 20:49:20

Originally posted by zeckensack
Hab den Shot auch mal hier geuppt

Wieder so ein Beispiel, wo das Anti-Aliasing nur zu einem Bruchteil funktioniert. Die Kabel am oberen Bildschirmrand sehen geglättet aus, die Hügelkanten und der Zaun nicht.

nggalai

2002-05-21, 21:03:32

Hi Jedi,Die Kabel am oberen Bildschirmrand sehen geglättet aus, die Hügelkanten und der Zaun nicht.FAA scheint nicht aktiviert zu sein--die geglätteten Kannten sehen mir mehr nach geschickten Alpha Blending aus (schaut euch auch das Gras an).

ta,
-Sascha.rb

Quasar

2002-05-21, 21:10:06

Wie schon gesagt, FSAA ist sicherlich nicht aktiv. Dazu gibt's über's Bild verstreut einfach zu vielen Treppen.

In Tripple-Head wär's evtl. auch ein wenig viel für den Parhelia, der ja angeblich im jetzigen Stadium "nur" 20-30% mehr leistet als eine Ti4600...

der-Leo

2002-05-22, 09:44:20

also ich denke bei einer auflösung von 3840x1024!!!
muss man nicht unbedingt AA erwarten.
vielleicht sollte man erstmal eine andere grafikkarte finden die solch eine auflösung überhaupt mal schafft.

d-L

nggalai

2002-05-23, 09:09:17

Ben konnte an der E3 mit der Parhelia rumspielen:

http://www.beyond3d.com/forum/viewtopic.php?t=1050I'm not going to gvie any guesses on performance , as the boards I played on this morning are beta. However here's what I got from my meeting (excluding anything that might be considered um off the record)

1. Displacement mapping absolutely rocks . Adding arbitrary geometry to figures or in outdoors terrain is a serious step in the right direction.
2. FAA absolutely also rocks. Swimming textures in buildings in FS 2002? GONE.
3. 10bit color was a little bit of a disappointment. Because the LCD monitors that were used in the demo, it downsampled to 8bit color. While there is a difference in banding, it was less apparent than I expected. When I test the card with 3 CRTs I'll take a deeper look into it.
4. It will not be a Quake3 Geforce4 Ti killer with the way most reviewers run the benchmarks. Of course with 80 million transistors on a .15um process, there's likely to be a lot of heat, and it's unlikely that the Parhelia 512 will have a more than 300mhz gclock.
5. Having said that, Matrox suggests, and I agree with them 100% that performance in Quake3 is fast enough today. Turn on FSAA (games with stencil buffers have issues with FAA) anisotropic filtering and Surround Gaming , and it should be completely playable
6.Surround gaming absolutely rocks. I got to play Quake3 and on 3 monitors it was absoletly smooth. One little note, while playing , I didn't consciously look to my right or left, but in my peripheral vision caught movement on the extra monitors and I was able to react without thinking
7. Matrox suggests, and after walking around the show floor, I agree, that DX 8 games will be more prevalent this Christmas. The number of DX9 games will be very limited if any at all. Thus their decision to go with DX8.1
8. If you have a chance and are at E3 go to the AMD/Matrox/Alienware lot (last year's G.O.D) lot , take it. Soldier Of Fortune II and F1 2002 makes great use of surround gaming . The HUGE monitors for the racing game are the way to play a racing game.
9. Parhelia 512 can multipass render . 8 textures per pixel is possible on a Parhelia
10. Review cards are likely to be sent out in early June. WOOHOO!!! Final retail boards will likely be out in late June/early July.
12. Did I mention Displacement Mapping totally rocks ??? Watching a character be N-Patched , then displacement mapped, makes a totally different look
13. To give you a sense of how powerful the pixel shaders are capable of being. The ocean demo with a shark, the bass, a school of fish? Everything is bumpmapped and using 4 textures per pixel. The Bass consists of 8 pixel shaders with 100 pixel shader instructions.
14. The anisotropic filtering did sharpen Quake3. The Parhelia is capable of dynamically allocating 64 texture samples in a pass . In other words 1 pixel with 64 sample anisotropic filtering, or alternatively 4 pixels with 16 sample aniso in a single clock.
15. Performance hit with 16x FAA in one application (no numbers, sorry) was about 20% with their 4x FSAA around 50% . Sorry , can't say more.
16 Only one mode of FAA 16x at the moment.Zu 10. : gutes Timing. Liegt genau in meinem Aufrüst-Plan. ;)

ta,
-Sascha.rb

2002-05-23, 09:35:11

Wenn's denn im Juni schon soweit sein soll, dann koennte jetzt ruhig mal was ueber die Preise und Varianten der Karten bekannt werden denke ich.

StefanV

2002-05-23, 10:39:48

Originally posted by ow
Wenn's denn im Juni schon soweit sein soll, dann koennte jetzt ruhig mal was ueber die Preise und Varianten der Karten bekannt werden denke ich.

Nicht bei Matrox *eg*

Demirug

2002-05-23, 10:49:25

Originally posted by ow
Wenn's denn im Juni schon soweit sein soll, dann koennte jetzt ruhig mal was ueber die Preise und Varianten der Karten bekannt werden denke ich.

Aus marketing technischer sicht wäre das nicht sehr klug. Das die Karte(n) nicht bilig wird vermuten wir ja alle. Ergo darf man den Leuten nicht so viel Zeit geben über den Preis nachzudenken. Bei Hochpreisprodukten muss in dem Moment wenn der Preis genannt wird die Bestellung schon möglich sein.

Wobei was mich interesieren würde ist was sie zur Kartenvorstellung ausser den Karten noch zeigen um den unentschlossenen den letzten Kick zu geben.

Torian.cc

2002-05-23, 15:48:25

Hola,

ich habe zwar zum größten Teil verstanden, was nggalai da über seinen E3-Besuch geschrieben hat, wäre es aber vielleicht trotzdem möglich, daß hier jemand mal eine übersetzte Version postet?

Danke und MfG
Tori
__________

MATROX RULEZ

nggalai

2002-05-23, 15:57:47

Hi Torian,

das war zwar nicht mein Besuch, aber ich werd's mal übersetzen. :)

ta,
-Sascha.rb

nggalai

2002-05-23, 16:12:22

OK, 10-Minuten-Schnell-Übertragung (keine Wort-für-Wort-Übersetzung):Ich werde keine Einschätzungen der Leistungsfähigkeit der Karte weitergeben, da die Karten, mit welchen ich am Morgen rumspielte, noch Betas waren. Aber hier eine Liste der Dinge, welche ich aus dem Treffen mitnehmen konnte (ausschliesslich einiger Sachen, welche man als "vertraulich" bezeichnen könnte).

1. Displacement mapping ist voll toll. Figuren oder Aussenszenen mit zusätzlicher (sic) Geometrie zu versehen ist ein ernsthafter Schritt in die richtige Richtung.
2. FAA ist ebenfalls sehr cool. "Schwimmende" Texturen an den Häusern in FS 2002 gehören der Vergangenheit an.
3. 10bit Farbtiefe pro Kanal war ein wenig enttäuschend. Das lag wohl auch an den LCD Monitoren, auf welchen die Demo lief--die haben auf 8bit runtergerechnet. Obwohl's klar weniger Farb-Bänderung gab, war der Unterschied weniger deutlich als erwartet. Sobald ich die Karte an 3 CRT-Monitoren teste, werde ich der Sache genauer nachgehen.
4. Die Karte wird nicht der Quake3-Geforce4Ti-Killer--jedenfalls nicht in Benchmarks, wie die meisten Tester sie wohl fahren werden. Ist auch klar, bei 80Mio Transistoren in .15um Fabrikation wird der Chip sehr heiss, und es ist unwarscheinlich, dass die Parhelia-512 mit mehr als 300MHz betrieben wird.
5. Ich sollte trotzdem erwähnen, dass Matrox der Meinung ist (und ich mich dem zu 100% anschliesse), dass die Leistung für Quake3 heutzutage eh ausreichend sein dürfte. Wenn man noch FSAA anschaltet (Spiele mit Stencil Buffer haben Probleme mit FAA), anisotropes Filtering und Surround Gaming aktiviert, sollte alles immernoch vollkommen spielbar laufen.
6. Surround Gaming rockt. Ich durfte Quake3 damit spielen, und selbst mit 3 Monitoren war's absolut flüssig. Kleiner Hinweis: während ich spielte habe ich nicht bewusst nach Rechts oder Links geschaut, sondern die Bewegung auf den Zusatz-Monitoren aus den Augenwinkeln wahrgenommen und unbewusst darauf reagiert.
7. Matrox meint--und nachdem ich durch die E3 lief schliesse ich mich dem an--dass DX8-Spiele so um Weihnachten im Kommen sein werden. Die Anzahl an echten DX9 Spielen wird äusserst klein sein, daher auch Matrox' Entscheidung für DX8.1.
8. Falls Ihr die Chance habt, die E3 zu besuchen, dann kommt am AMD/Matrox/Alienware-Stand vorbei (da, wo letztes Jahr G.O.D. zu finden waren). Soldier Of Fortune II und F1 2002 zeigen sehr schön, was Surround Gaming bringen kann. Und RIESIGE Monitore für Rennspiele sind das einzig Wahre.
9. Parhelia 512 kann multipass rendering. 8 Texturen pro Pixel sind möglich.
10. Karten werden so Anfangs Juni an Tester verschickt werden. WOOHOO!!! Die endgültigen Karten sollten Ende Juni / Anfangs Juli im Verkauf erhältlich sein.
12. Habe ich schon erwähnt, dass Displacement Mapping voll toll ist? ??? Wenn man sieht, wie eine Figur zuerst mit N-Patches erweitert wird und dann noch Displacement Mapping erhält, macht das doch noch sehr viel aus.
13. Als Beispiel, wie mächtig die Pixel Shader sind: das Ocean Demo mitm Haifisch, dem Barsch und der Fisch-Schule? Das war alles mit Bump Mapping versehen, 4 Texturen pro Pixel. Der Barsch wurde mit 8 Pixel Shader mit total 100 Shader-Instruktionen dargestellt.
14. Anisotropes Filtering hat Quake 3 schärfer dargestellt. Parhelia kann dynamisch 64 Textur-Samples pro Pass verwenden. In anderen Worten: entweder 1 Pixel mit 64 Samples, oder 4 Pixel mit 16 Samples pro Takt. (sic)
15. Der Leistungseinbruch mit 16x FAA in einer Applikation, welche ich sah (sorry, keine genauen Zahlen), war so um die 20%, mit 4x FSAA rund 50%. Sorry, darf nicht mehr sagen.
16 Momentan unterstützt FAA ausschliesslich 16x.

Bitte quotet das nicht direkt, sondern verwendet das Englische Original. Und nochmals: das war Ben, nicht ich. ;)

ta,
-Sascha.rb

Edit: Tippfehle.rb

zeckensack

2002-05-23, 16:14:35

Übersetzung:

Ich werde nicht über die Geschwindigkeit reden, da die Karten auf denen ich heute morgen gespielt habe, alle noch beta sind. Nujo, das hier habe ich aus dem Meeting mitgenommen (ausgenommen die Sachen, die nicht für die Öffentlichkeit gedacht waren):

1. Displacement Mapping ist saucool. Beliebige Geometrie zu Figuren oder Outdoor-Terrains hinzufügen, das ist ein großer Schritt in die richtige Richtung.
2. FAA ist saucool. Wabernde Texturen in (auf?) Gebäuden in FS2002? WEG.
3. 10bit Farben waren etwas enttäuschend. Wegen der LCDs, die für die Demo benutzt wurden, wurde eh' alles wieder auf 8bit runtergerechnet. Das Banding war zwar schwächer, aber es war weniger deutlich wahrzunehmen, als erwartet. Wenn ich die Karte mit drei Röhrenmonitoren teste, schau' ich mir das mal näher an.
4. Es wird kein Geforce4Ti Killer in Quake 3, so wie die meisten Tester die Benchmarks laufen lassen. 80Mio Transistoren in .15um verursachen natürlich eine Menge Abwärme, daher ist es unwahrscheinlich, daß der Parhelia 512 schneller als mit 300MHz getaktet wird.
5. Wo wir dabei sind, Matrox ist der Meinung, und ich stimme ihnen da absolut zu, daß Quake 3 heute bereits schnell genug ist. Man kann FSAA (Spiele mit Stencil haben Probleme mit FAA), Aniso und Surround Gaming hinzuschalten, und es sollte absolut spielbar sein.
6.Surround Gaming ist saucool. Ich durfte Quake 3 spielen und es war auf 3 Monitoren absolut flüssig. Eine Bemerkung hierzu, ich habe beim Spielen garnicht bewußt nach links oder rechts geschaut, konnte aber trotzdem die Bewegungen im peripheren Sichtfeld wahrnehmen. Ich konnte reagieren, ohne nachzudenken.
7. Matrox meint, und nachdem ich mir die Show angeschaut habe, stimme ich zu, daß DX8 Spiele diese Weihnachten klar in der Mehrheit sein werden. DX9 Spiele wird es nur wenige geben, wenn überhaupt. Deswegen ihre Entscheidung für DX8.1.
8. Wenn ihr die Chance habt und auf der E3 seit, geht auf den AMD/Matrox/Alienware Parkplatz (da, wo letztes Jahr GOD waren). SoF2 und F1 2002 machen guten Gebrauch von Surround Gaming. Die RIESIGEN Monitore für das Rennspiel, so muß das sein.
9. Parhelia 512 beherrscht Multipass rendering. 8 Texturen pro Pixel sind möglich.
10. Testkarten werden wahrscheinlich Anfang Juni losgeschickt. JIPIIIEH!!! Zu kaufen geben wird es die Teile voraussichtlich Ende Juni/Anfang Juli.
12. Hab' ich erwähnt, das Displacement Mapping saucool ist? Es macht einen Riesenunterschied, eine Figur mit N-Patches (TruForm, Anm. d. Übers. ;) )und dann mit Displacement Mapping zu sehen.
13. Um euch einen Eindruck von der Leistungsfähigkeit der Pixel Shader zu geben, die Ocean Demo mit einem Hai, einem ... Fisch (???) und einem Fischschwarm. Alles benutzt Bumpmapping und 4 Texturen pro Pixel. Der Fisch (???) besteht aus 8 Pixel Shadern mit 100 Instruktionen.
14. Der anisotrope Filter macht Quake 3 tatsächlich schärfer. Der Parhelia kann dynamisch 64 Texel pro Pass verwenden und auf seine Pipeline verteilen. In anderen Worten, 1 Pixel mit 64 Texeln (8xAniso), oder alternativ 4 Pixel mit jeweils 16 Texeln (4xAniso) pro Takt.
15. Der Leistungseinbruch mit 16x FAA in einer Anwendung (sorry, gebe keine Zahlen an) war ungefährt 20%, mit 4xFSAA ungefähr 50%. Tut mir leid, mehr darf ich nicht sagen.
16 Es gibt im Moment nur einen FAA-Modus, nämlich 16-fach.

zeckensack

2002-05-23, 16:15:41

Crap. I need to type faster next time :D

nggalai

2002-05-23, 16:21:48

:lol:

der war gut, Z-Bag. Hehe. Timing ahoy.

Naja, jetzt hammer wenigstens zwei Übersetzungen zum Quervergleichen. Die Wahrheit liegt wohl irgendwo dazwischen. ;)

ta,
-Sascha.rb

P.S. Guter Text. *nickt* .rb

MadManniMan

2002-05-23, 16:47:02

HERRLICH!

allein schon der kontrast zwischen JIPIIIEH!!! und WOOHOO!!! ist 1A

btw: morpht die beiden mal zusammen :D

Torian.cc

2002-05-23, 17:17:52

@nggalai+zeckensack

Toll, daß es solch` freundliche Members im 3DCenter-Forum gibt!!
Jaaa, dieses Forum ist nicht umsonst das geilste, welches im Web existiert ;o)

Nochmal schönen Dank für die Mühe, die Ihr Euch gemacht habt!

MfG
Tori
__________

MATROX RULEZ

Torian.cc

2002-05-25, 00:08:58

Gehört zwar eher in´s Spiele-Forum unter den Doom3-Thread, aber hat ja wohl auch mit der Parhelia zu tun....

Ihr habt sicher auch schon das Interview mit John Carmack gelesen, in dem steht, daß die ATI 8500 technisch gesehen momentan am schnellsten die Doom3-Engine berechnen kann.
Wenn keine Treibermacken auftreten zumindest..., ansonsten ist wohl die GeForce 4 TI4600 schneller.

Auf wat ich nu` hinaus will...., ich hoffe, daß Meister Carmack noch nicht die Möglichkeit hatte, sein Doom3 mit der Parhelia zu testen, sonst wäre diese Aussage nicht sonderlich befriedigend für mich "Wartenden"!
Oder wisst Ihr schon was Gegenteiliges (?)?

Ich bin total scharf auf Doom3!!! Und wenn sich nachher herausstellt, daß Doom3 schlecht, oder garnicht auf der Parhelia läuft, wäre das sogar fast ein Grund, sich den Kauf nochmal zu überlegen.

*spekulierspekulierspekulier*
Es wäre schön, endlich mal was handfestes zu erfahren, um sich nicht selber alles schönreden oder sich verrückt machen zu müssen....

MfG
Tori
__________

MATROX RULEZ

P.S.: Hieß es nicht kurz vor Beginn der E3, daß Carmack eine speziell angepasste Version seines Doom3 präsentieren wollte?!

Demirug

2002-05-25, 00:17:35

@Torian.cc:

Bleibt doch einfach ganz ruhig. DOOM III ist noch nicht auf dem Markt. Die Parhelia Karten gibts auch noch nicht zu kaufen.

Was nun die Performance angeht. Die Frage dabei ist ob die OpenGL Treiber schon gut genung sind und ob sie neue für DOOM III relevante Extensions enthalten. Falls ja muss die DOOM Engine erst noch angepast werden und dafür hatte Carmack dann wahrscheinlich noch keine Zeit.

Ich denke aber mal das es bestimmt noch eine Aussage von Carmack zu diesem Thema gibt.

Torian.cc

2002-05-25, 01:22:52

@Demirug

Du hast ja Recht (tiiiief einatmen, und wieder ausatmen *puuuh*).

Dennoch sind Doom3 und die/der Parhelia die einzigen Dinge im PC-Markt die momentan noch für einen beschleunigten Herzschlag bei mir sorgen können ;)

Aber sicher...., erst einmal "slow-down". Sich verrückt zu machen, treibt die Hardware- und Softwareentwicklung auch nicht vorran.

Es ist schonmal beruhigend zu wissen, daß die Doom3-Engine "nur" von DX8 kompatiblen Karten kompletten Gebrauch macht und DX9 nicht vonnöten ist.

Ich glaube, da habe ich was falsch verstanden! Ist die Doom3-Engine nicht in OpenGL programmiert? Oder war nur die Rede von den OpenGL Fähigkeiten einer DX8 Graka? Oder hat sich John Carmack breitschlagen lassen und OpenGL den Rücken gekehrt (was ich mir nur schlecht vorstellen kann...)!?

Wie lang` geht die E3 jetzt eigentlich noch?

MfG
Tori
__________

MATROX RULEZ

wulfman

2002-05-25, 09:34:24

ich bin so frei:

Carmack: There are interesting things to be said about the upcoming cards, but NDAs will force me to just discuss the available cards.

ich würde die parhelia nicht unter "available" einstufen.

mfg
wulfman

Demirug

2002-05-25, 11:48:27

@Torian.cc:

Carmack benutzt immer noch OpenGL. Da aber Dinge wie Vertex und PixelShader mit der OpenGL API bei jedem hersteller anders funktionieren ist es einfacher die Karten über Direct X zu klasifizieren. Obwohl auch das nicht richtig ist.

Was deine DX9 Karten angeht: Ist noch eine lange Zeit bis zur Veröffentlichung. Die Grafik wird sich aber kaum noch ändern.

@wulfman:

Diesen Spruch hört man regelmäsig von Carmack. Er kann sich eben noch über Kleinigkeiten freuen. War jetzt nicht als Abwertung der parhelia gedacht.

Razor

2002-05-25, 15:32:12

Sorry, liebe Leut', aber irgendwie sind mir unheimlich wichtige Dinge dazwischen gekommen !
(hab' 'nen wirklich erfreuliches Päckchen aus dem Ammiland bekommen *freu* ;-)

Egal...

@zeckensack

Herzlichen Dank für den Link, aber es ist genauso, wie ich vermutet habe... TruForm richtig einzusetzen bedeutet also, dies von vornherein in der Engine zu berücksichtigen und quasi ein paralleles Obektmodell zu fahren (ich weiß auch, daß die n-patches abwärtskompatibel sind). Und das war ja auch der Punkt, auf den ich hinaus wollte, denn soooo einfach, wie es ATI darstellte, TruForm in den Games 'vernünftig' (davon sagten sie allerings nichts ;-) zu integrieren ist es nun wirklich nicht. So kommt dann halt doch die Marktverbreitung zum Tragen, die dem Einsatz in 'unabhängigen' Games (bei welchen ATI nicht die Implementierung bezahlt ;-) entgegenwirken dürften...

Aber wie gesagt, nochmals danke für den Link !

@Exxtreme

"Nicht kompatibel?? Zu was? AFAIK ist TruForm kompatibel zu alter Hardware. Nur da hat es keine Wirkung. Ich glaube, daß du RT-Patches meinst. Da müsste man tatsächlich die ganzen Grafik-Engines neu umkrempeln."

Da haben wir uns etwas mißverstanden...
Mit 'nicht kompatibel' meinte ich den Aufwand, der für die Implementierung getrieben werden muß. Wie oben schon geschrieben lohnt sich IMHO die 'vernünftige' Implementierung nicht, wenn lediglich nur ein einziger GraKa-Chip eines Herstellers davon profitiert (dessen Marktverbreitun zusätzlich noch nicht gerade ein Argument ist). Hätte mich da klarer ausdrücken sollen, sorry...

"Man muss halt die Stellen im Objekt markieren, die gerundet werden sollen. Mehr nicht. Aber anscheinend schaffen es die Leute irgendwie nicht und setzen die Rundungen für das gesamte Objekt. Wie es am Ende aussieht wissen wir ja."

Schon klar... und Dank auch an Dich für die Erklärung...

@Stefan

"Macht man das nicht, so ist das Ergebnis nicht so schön, was wir ja an bestehenden Spielen, die N-Patches verwenden, sehen..."

Und sehr viel mehr wird vermutlich (meine Meinung !) auch nicht für dieses 'Spezial-HOS' kommen...

@Demirug

"Also ich hab hier noch ein paar Infos von jemand der gute Beziehungen zu MS und den Chip hersteller hat:

1. Jede Karte die ps2.0 unterstützt muß auch ps1.4 unterstützen."

Halt' ich für ein Gerücht !
Aus welchem Grund müssen die PS2.0 zu den PS1.4 kompatibel sein ?
Gibt es da irgendetwas Offizielles ?

Daß die PS2.0 aufgrund ihrer Spezifikation vermutlich in der Lage sind, PS1.4-Effekte zu 'emulieren', ähnlich, wie es die PS1.4 mit den PS1.0/3 machen, halte ich schon eher für wahrscheinlich, aber ein zwingendes muss halte ich für abwegig... ist aber nur meine persönliche Vermutung die sicherlich keinen Anspruch auf die Wahrheit erhebt.

"2. Auf einer Radeon 8500 ist der gleiche Effect mit ps1.4 schneller als mit ps1.0/3."

Das wiederum wurde durch Deinen eigenen Quaote (MadOnion) wiederlegt, sorry.

Wenn ich das eichtig verstanden habe, ist es eine Sache der Implementierung, ob ein solcher Effekt auf der einen oder eben der anderen PS-Version effizienter läuft. Was im übrigen auch durchaus Sinn macht...

Würde man beide Renderpaths mit maximaler Effizienz implementieren, könnte das ev hinkommen, was aber zumindest mit einem Fragezeichen versehen werden sollte (leider keine Vergleichsmöglichkeit !). Auf der anderen Seite müsste man mir aber doch erklären, warum ein Engine-Entwickler das machen sollte (außer JC vielleicht, der es 'just-for-fun' macht ;-)...

@Xmas

Geht's auch etwas freundlicher ?
Kann gut sein, daß ich mich manchmal in meinen Gedankengängen ein wenig verzettele, aber das ist noch kein Grund...

Und ja, ich lese Deine Posts i.d.R. vollständig und mit Verstand.

@wolfman

Hübscher Shot !
;-)

@Torian.cc

"...daß die ATI 8500 technisch gesehen momentan am schnellsten die Doom3-Engine berechnen kann.
Wenn keine Treibermacken auftreten zumindest..., ansonsten ist wohl die GeForce 4 TI4600 schneller."

Die R8500 rendert die Polys in einem Pass, die gf4ti in zweien... letztere ist dabei aber schneller.
Vermutlich wird auch die gf4ti4600 nicht in der Lage sein, das Game mit maximalen Details, AA & AF bei einer normalen Auflösung (1024+) zu rendern... aber das ist alles noch Zukunftsmusik. Bezeichnend ist allerdings, daß man einen P4 2.2GHz mit einer 'next-gen' ATI-Karte kombinieren mußte, um das Game 'in ganzer Pracht' zu zeigen...

"Ich bin total scharf auf Doom3!!! Und wenn sich nachher herausstellt, daß Doom3 schlecht, oder garnicht auf der Parhelia läuft, wäre das sogar fast ein Grund, sich den Kauf nochmal zu überlegen."

Vermutungen über Vermutungen...
;-)

Warte doch erst einmal ab, bis erste Benches und vor allem User-Erfahrungen da sind. Ohne diese würd ich die Karte auf keinen Fall kaufen...

"Es ist schonmal beruhigend zu wissen, daß die Doom3-Engine "nur" von DX8 kompatiblen Karten kompletten Gebrauch macht und DX9 nicht vonnöten ist."

Wo steht das geschrieben ?
Es kann gut sein (vermutlich ist das sogar sehr wahrscheinlich), daß JC wieder mal auch noch nicht verfügbare Hardware unterstützt (wie er ja selber sagte, 'darf' er nichts dazu sagen, i.e. ist er diesbezüglich einem NDA unterlegen). Wie sonst sollte die Engine für die nächsten 3-4 Jahre 'fit' sein ?
???

Ansonsten bliebe dazu zu sagen, daß es schon fast fervelhaft wäre, mit seiner Engine nicht OpenGL 2.0 zu unterstützen. Aber wie schon gesagt: Abwarten !

Die Parhelia wird noch ein paar Monate auf sich warten lassen, Doom3 mit Sicherheit noch mindestens ein halbes Jahr.

Bis denne

Razor

Demirug

2002-05-25, 15:55:05

@Razor:

Ein TruForm Objectmodel kann man auch auf nicht N-Patch fähigen Karten benutzen aber der mehraufwand für gute N-Patch Modle lohnt eben nicht.

Was nun die DX9 Features angeht darf ich seit heute eigentlich nichts mehr spezifisches sagen (NDA). Da die Information aber bereits auf einer anderen Seite öffentlich war kann ich sie bestätigen.

Was nun deinen einspruch im Bezug auf die Radeon angeht kann ich dir nicht ganz folgen. Die Aussage (nicht von mir) sagt lediglich das bei Effecten die sowohl mit ps 1.3 und ps 1.4 ereicht werden können die ps 1.4 Variante auf der Radeon 8500 schneller ist.

Razor

2002-05-25, 16:07:52

Originally posted by Demirug
@Razor:

Ein TruForm Objectmodel kann man auch auf nicht N-Patch fähigen Karten benutzen aber der mehraufwand für gute N-Patch Modle lohnt eben nicht.

Was nun die DX9 Features angeht darf ich seit heute eigentlich nichts mehr spezifisches sagen (NDA). Da die Information aber bereits auf einer anderen Seite öffentlich war kann ich sie bestätigen.

Was nun deinen einspruch im Bezug auf die Radeon angeht kann ich dir nicht ganz folgen. Die Aussage (nicht von mir) sagt lediglich das bei Effecten die sowohl mit ps 1.3 und ps 1.4 ereicht werden können die ps 1.4 Variante auf der Radeon 8500 schneller ist.
Irgendwie habe ich wohl ein echtes Problem, mich korrekt auszudrücken...
:D

Dein erster Satz entspricht exakt dem, was ich zum Ausdruck bringen wollte !

Mit den DX9-Features meinst Du vermutlich den PS2.0 und dessen Kompatibilität zu den PS1.4. Und ich habe ja bereits geäussert, daß der PS2.0 aufgrund seiner Spezifikation vermutlich zu einer Emulation in der Lage ist. Aber daß die PS1.4 absolute Voraussetzung für die PS2.0 sind, möchte ich dann doch lieber von offizieller Stelle bestätigt haben. Ausschließen würde ich das in keinem Fall wollen...

Zu der Geschwindigkeit von PS1.1/3 vs. PS1.4:
These two different modes of that same test work a bit differently, and should therefore not be directly compared. Both two modes could be optimized to show more performance either way, but now the test is just optimized for maximum compatibility. Vertex shader performance also affects the score somewhat due to this compatibility optimization.
Ist Dein eigener Quote gewesen...
;-)

Bis denne

Razor

zeckensack

2002-05-25, 16:19:46

Originally posted by Razor
Mit den DX9-Features meinst Du vermutlich den PS2.0 und dessen Kompatibilität zu den PS1.4. Und ich habe ja bereits geäussert, daß der PS2.0 aufgrund seiner Spezifikation vermutlich zu einer Emulation in der Lage ist. Aber daß die PS1.4 absolute Voraussetzung für die PS2.0 sind, möchte ich dann doch lieber von offizieller Stelle bestätigt haben. Ausschließen würde ich das in keinem Fall wollen...Wieso Voraussetzung? Voraussetzung für den PS2.0 ist auf jeden Fall Hardware, die sehr viel flexibler als PS1.4-Hardware ist.

Exxtreme

2002-05-25, 16:23:02

Originally posted by Demirug
@Razor:

Ein TruForm Objectmodel kann man auch auf nicht N-Patch fähigen Karten benutzen aber der mehraufwand für gute N-Patch Modle lohnt eben nicht.

Wieso lohnt sich der Aufwand nicht? Man muss ja blos die Polygone markieren, die gerundet werden sollen. Ich denke nicht, daß man da sehr lange dazu braucht. Und soetwas unterscheidet eine gute Spieleschmiede von einer weniger guten - die Extras.

Gruß
Alex

Demirug

2002-05-25, 16:32:27

@Razor:

Wenn du eine offizielle Bestätigung braust must du warten bis DX9 released ist. Mir reicht was ich haben.

Der Quote ist von mir. Es geht dabei aber um den vergleich GeForce und Radeon. Er sagt also nicht über die unterschiedlichen Ausführungsgeschwindigkeiten von PS 1.0/3 und PS1.4 aus.

Von meiner Seite ist es verständlich das die PS1.4 schneller sind da sie der Hardwarestruktur näher kommen.

Das gleiche Problem werden wir bei den PS2.0 wieder bekommen. Ein Effeckt wird mit PS2.0 schneller sein als mit PS1.x auf der gleichen Hardware.

Demirug

2002-05-25, 16:51:20

Originally posted by Exxtreme

Wieso lohnt sich der Aufwand nicht? Man muss ja blos die Polygone markieren, die gerundet werden sollen. Ich denke nicht, daß man da sehr lange dazu braucht. Und soetwas unterscheidet eine gute Spieleschmiede von einer weniger guten - die Extras.

Gruß
Alex

Ganz so einfach ist das leider nicht. Die Rundungen ergeben sich über die Normalen der Polys. Dadurch muss man nicht die Rundungen makieren sondern die Kanten von Dreicken mit unterschiedlichen Rundungen. Wenn das nicht mit absoluter Sorgfalt geschieht gibt es Löcher oder überschneidungen. Da die benutzten Programme (3dsmax, Maya) für sowas nicht ausgelegt sind ist der Aufwand im Moment nicht gerechtfertigt.

Du führst hier nun auf das es sich bei solchen Dinge um den Unterschied zwischen einer guten und einer weniger guten
Spieleschmiede handelt.

Als ATi Fan und Spieler hast du recht aus kaufmänischer Sicht allerdings nicht.

Eine gute Spieleschmiede ist eine die Profit macht (ja es ist wirklich so profan).

Nun frage ich mich:
Ist TruForm ein Verkaufsargument?
Wieviele Kopien kann ich mehr Verkaufen wenn ich Truform unterstütze?

Die Antwort auf die erste Frage lautet: Maximal ein sehr kleines. Den Besitzer von nicht ATi Karten ist das völlig egal. Es bleiben also nur noch die ATi Karten besitzer übrig. Ein großer Teil kauft das Spiel auch ohne Truform oder weis noch nicht mal was das ist.

Die Antwort auf die zweite Frage ergibt sich aus der ersten.

Resüme:
Der Mehraufwand für Truform lohnt nicht weil man damit den Absatz nicht um das nötige Mass erhöhen kann.

Razor

2002-05-25, 17:05:45

@zeckensack

"Wieso Voraussetzung? Voraussetzung für den PS2.0 ist auf jeden Fall Hardware, die sehr viel flexibler als PS1.4-Hardware ist."

War auf die Aussage von Demirug bezogen...
Sinngemäß: "PS2.0 muss PS1.4 unterstützen"

@Exxtreme

"Wieso lohnt sich der Aufwand nicht? Man muss ja blos die Polygone markieren, die gerundet werden sollen. Ich denke nicht, daß man da sehr lange dazu braucht. Und soetwas unterscheidet eine gute Spieleschmiede von einer weniger guten - die Extras."

Jedes (zu TruForm-ende) Polygon muss makiert werden !
Und das soll keinen Aufwand bedeuten ?

Klar, bei 'ner Handvoll Polys von Q1/2 wird's wohl nur ein paar Tage dauern, aber bei Games ala RTCW, MoHAA, SOF2 (oder ähnlichen) dürfte der Aufwand sehr viel heftiger sein...

Zumal es wohl keine Entwicklungs-Kits gibt, die diese Form der 'Objekt-Markierung' unterstützten. Wie stellst Du Dir das also vor, dies in relativ kurzer Zeit (nachträglich ?) zu bewerkstelligen ?
???

@Demirug

Ich will Dir auf keinen Fall Deine Kompetenz absprechen, was mir auch überhaupt nicht zusteht. Trotzdem wage ich nicht-offizielle Dinge in Frage zu stellen, bis sie offiziell sind. Ist also kein Angriff auf Dein Wissen, sondern lediglich eine Vorgehensweise meinerseits, mit der ich bisher auch immer gut gefahren bin.

"Der Quote ist von mir. Es geht dabei aber um den vergleich GeForce und Radeon. Er sagt also nicht über die unterschiedlichen Ausführungsgeschwindigkeiten von PS 1.0/3 und PS1.4 aus.

Von meiner Seite ist es verständlich das die PS1.4 schneller sind da sie der Hardwarestruktur näher kommen."

Klar ist der Quote von Dir (dachte dies korrekt gepostet zu haben). Aber offizell kam dies von MadOnion. Und dort wird ausdrücklich darauf hingewiesen, daß man insbesondere den "Advanced Pixel Shader Test" (der auch den PS1.4 unterstützt) nicht Performance-Seitig vergleichen dürfe, da je nach Implementierung die eine oder andere Variante schneller sein würde. Ansonsten ist der PS1.4 speziell auf die Hardware der R8500 ausgelegt, die im Vergleich zu anderen (nicht nur nVidia) eben 6 statt nur 4 Texturen nutzen kann. Auch wurde schon darauf hingewiesen, daß eine gf4ti mit 2 passes (4+2+1 ?) schneller ist, als eine R8500 mit einem pass (6+1). Insofern ist der PS1.4 schon mal in diesem (auch nicht gerade 'real world' Beispiel ;-) langsamer...

Es dürfte schwer sein, hier eine generelle Aussage zu treffen.

Aber eines ist sicher, zumindest theoretisch müsste der PS1.4 schneller sein.
:D

Bis denne

Razor

P.S.: Ich habe gerade Deine Antwort zu dem Post von Exxtreme gelesen. Könnte man also sagen, daß eine 'sogfältige' Implementierung von TruForm ähnlich aufwendig wie RT-Patches (polynominale Flächen) sind und nicht einmal auf vorhandene Modellierungs-Umgebungen zurück gegriffen werden kann ?

Demirug

2002-05-25, 17:19:02

@Razor:

Das ist keine Frage der Kompetenz. Ich dachte du hättest den wink mit der NDA verstanden.

Nun zu deiner TruForm frage. RT-Patches sind noch aufwendiger da man dort einen komplett neuen Satz von Geodaten braucht.

Es gibt für die Modellierungs-Umgebungen schon ein paar Plugins zur Unterstützung aber das ist nicht das Wahre und den Designer gefällt das nicht wirklich.

Xmas

2002-05-25, 17:26:34

Originally posted by Demirug
Ist TruForm ein Verkaufsargument?
Wieviele Kopien kann ich mehr Verkaufen wenn ich Truform unterstütze?

Die Antwort auf die erste Frage lautet: Maximal ein sehr kleines. Den Besitzer von nicht ATi Karten ist das völlig egal. Es bleiben also nur noch die ATi Karten besitzer übrig. Ein großer Teil kauft das Spiel auch ohne Truform oder weis noch nicht mal was das ist.

Die Antwort auf die zweite Frage ergibt sich aus der ersten.

Resüme:
Der Mehraufwand für Truform lohnt nicht weil man damit den Absatz nicht um das nötige Mass erhöhen kann.
Was bringen Models mit 10000 Dreiecken, die steigern den Absatz gegenüber welchen mit 9000 auch nicht wirklich... So kann man nicht immer argumentieren. Zum Glück werden nicht alle Entscheidungen nach wirtschaftlichen Gesichtspunkten getroffen.

Beeindruckende Grafik als ganzes sorgt oftmals für gute Verkaufszahlen - und wenn die Grafik mit Truform noch etwas beeindruckender wird, dann hat das schon eine Wirkung.
Der Aufwand, Models N-Patch-gerecht zu gestalten ist IMHO vertretbar.

Und in Zukunft wirds ja auch mit der Hardware-Unterstützung besser - jetzt R200, bald RV250, R300, Parhelia, P10... und möglicherweise sogar NV30.

Razor

2002-05-25, 17:32:51

@Xmas

Du meinst die DX9 N-Patches ?
Sind die nich auch wieder optional ?
Sind die zu denen der R200/RV250 kompatibel ?
Und Parhelia/P10 unterstützen das ATI TruForm ?
???

Sorry, aber davon höre ich jetzt das erste mal...

Razor

zeckensack

2002-05-25, 17:36:41

@demirug:
Was ist denn daran so kompliziert, ein Modell TruForm-tauglich zu machen ???

Ich habe zwar keine Pro-Modeler wie Max oder Lightwave, aber das 'Korrigieren' der Geometrie ist doch trivial. Ein entsprechendes Export-Plugin sollte jemand mit Erfahrung ziemlich flott zusammenbasteln können, womit der 'Mehraufwand' komplett negiert wird.

Das geht doch so:
1)Berechne für jedes Dreieck eine Oberflächennormale (einfaches Kreuzprodukt, dann normalisieren)
2)Identifiziere für jedes Dreieck seine direkten Nachbardreiecke (Dreiecke mit einer gemeinsamen Kante)
3)Bestimme den Winkel zwischen den Oberflächennormalen
4)Vergleiche den Winkel mit einem vorher festzulegenden Schwellwert (zB 30°, bei Low-Poly Modellen bis zu 90°)
4a)Winkel>=Schwellwert: Scharfe Kante, darf nicht gerundet werden
-> Verdopple die Kanteneckpunkte, streiche die Dreiecke an dieser Kante aus der 'Nachbarliste'
4b)Winkel<Schwellwert: Weiche Kante, darf gerundet werden
-> Mache erstmal nichts, der Rest passiert dann in Schritt 5

5)Alle Eckpunkte erhalten jetzt als ihre Normale einen Mittelwert der Oberflächennormalen aller Dreiecke, in denen sie enthalten sind. Merke: durch die Verdopplung von Eckpunkten, fließen Oberflächennormalen 'jenseits' harter Kanten automatisch nicht mehr ein.

Einfach, gell? ;)

bendel

2002-05-25, 17:42:00

Natürlich wird Hardware, die PS2.0 bietet, acuh die alten Shader unterstützen. Erstens wäre ziemlich unpraktisch, wenn sie nicht abwärtskompatibel wären und zweitens sind die höheren Shaderversionen mächtiger, so dass es kein Problem ältere Sachen darauf umzusetzen (Der Treiber muß aus dem Shadercode ja sowieso den Microcode für die Karte erzeugen).
Auch in der DX8 Doku steht, dass eine Version immer eine niedere einschließt:

"Each implementation sets the PixelShaderVersion member to indicate the maximum pixel shader version that it can fully support. This implies that implementations should never fail the creation of a valid shader of the version less than or equal to the version reported by PixelShaderVersion."

Geschwindigkeitsvergleiche sollte man glaube ich momentan nicht zwischen PS1.4 und 1.1-1.3 ziehen. Momentan gibt es ja nur die ATI und Nvidia Implementationen (käuflich). Und der Shader von Pixelshader von ATI(8500) ist nummal langsamer als der von NVidia(GF3). Beim VertexShader ist es umgekehrt. Das liegt aber wohl eher an der Implementation als am grundsätzlichen Design.

Demirug

2002-05-25, 17:42:10

@Xmas:

Die Anzahl der Dreiecke zu erhöhen bringt aber auf jeder Karte etwas.
Und was dich jetzt vielleicht wundern wird:

Mehr Dreiecke -> weniger Aufwand -> weniger Kosten

"Zum Glück werden nicht alle Entscheidungen nach wirtschaftlichen Gesichtspunkten getroffen."

Wenn ich jetzt gehäsig bin würde ich sagen das deshalb im Moment in Deutschland ein Studio nach dem anderen Konkurs anmelden muss.

"Beeindruckende Grafik als ganzes sorgt oftmals für gute Verkaufszahlen - und wenn die Grafik mit Truform noch etwas beeindruckender wird, dann hat das schon eine Wirkung."

Und wenn die Grafik dann auf einer neuen GeForce nicht so ist wie in den TruFrom Screenshots hab ich Ärger mit der Kundschaft.

"Der Aufwand, Models N-Patch-gerecht zu gestalten ist IMHO vertretbar."

Erste Grundregel im Gamedesign: Jedes Feature welches nicht unbedingt erforderlich ist wird gestrichen um die Kosten zu senken.

zeckensack

2002-05-25, 17:45:13

Originally posted by Demirug
"Der Aufwand, Models N-Patch-gerecht zu gestalten ist IMHO vertretbar."

Erste Grundregel im Gamedesign: Jedes Feature welches nicht unbedingt erforderlich ist wird gestrichen um die Kosten zu senken. Nach meiner Einschätzung kostet TruForm nichts ???
(sofern einmal ein Plugin dafür geschrieben/gezogen wurde)

Exxtreme

2002-05-25, 17:59:10

Originally posted by Demirug

Nun frage ich mich:
Ist TruForm ein Verkaufsargument?
Wieviele Kopien kann ich mehr Verkaufen wenn ich Truform unterstütze?

Die Antwort auf die erste Frage lautet: Maximal ein sehr kleines. Den Besitzer von nicht ATi Karten ist das völlig egal. Es bleiben also nur noch die ATi Karten besitzer übrig. Ein großer Teil kauft das Spiel auch ohne Truform oder weis noch nicht mal was das ist.

Die Antwort auf die zweite Frage ergibt sich aus der ersten.

Resüme:
Der Mehraufwand für Truform lohnt nicht weil man damit den Absatz nicht um das nötige Mass erhöhen kann.
Dann könnte man es mit dem High-Poly-Modellen gleich lassen. Sie bedeuten einen erhöhten Aufwand für den Entwickler und wenn man nur auf Low-Poly-Modelle setzt, verkaufen sich diese so oder so. Mag sein, daß TruForm aus der kaufmännischen Sicht kein direktes Verkaufsargument ist. Aber solche "Boni" können das Ansehen einer Spieleschmiede erhöhen. Und gutes Ansehen ist ein grosser Vorteil.

Gruß
Alex

Xmas

2002-05-25, 18:04:31

Originally posted by Razor
@Xmas

Du meinst die DX9 N-Patches ?
Sind die nich auch wieder optional ?
Sind die zu denen der R200/RV250 kompatibel ?
Und Parhelia/P10 unterstützen das ATI TruForm ?
???

Sorry, aber davon höre ich jetzt das erste mal...

Razor
Ich wüsste nicht dass es verschiedene "Versionen" von N-Patches gibt... Ich meine allgemein N-Patches, so wie sie schon in DX8 enthalten sind.
Parhelia unterstützt N-Patches (s. Displacement Mapping PDF), der P10 sollte eigentlich alle möglichen HOS berechnen können. Stellt sich nur die Frage ob Matrox und 3DLabs auch die ATI-OpenGL-Extensions übernehmen. Aber selbst wenn sie eigene verwenden, ist der zusätzliche Aufwand diese zu unterstützen geradezu winzig.

Razor

2002-05-25, 18:04:41

@bendel

"Natürlich wird Hardware, die PS2.0 bietet, acuh die alten Shader unterstützen. Erstens wäre ziemlich unpraktisch, wenn sie nicht abwärtskompatibel wären und zweitens sind die höheren Shaderversionen mächtiger, so dass es kein Problem ältere Sachen darauf umzusetzen (Der Treiber muß aus dem Shadercode ja sowieso den Microcode für die Karte erzeugen)."

Was spricht dagegen, sowohl PS2.0, als auch PS1.3 zu unterstützen ?
Aber ich will da mal (vorerst) Demirug Glauben schenken...

"Auch in der DX8 Doku steht, dass eine Version immer eine niedere einschließt:"

Vorsicht !
Es gibt keine Karte der Welt, die zur Zeit volle DX8-Unterstützung bietet...

Will sagen, es gibt zwingende Voraussetzungen für einen Treiber, der DX-Compliant ist und eben auch Optionales, wie z.Bsp. die PS1.4, die eben nicht (!) Voraussetzung für eine DX8.1-Compliance ist... (weswegen ja auch Parhelia und gf3/4ti DX8.1-Compliant sind)

Bei Voraussetzungen gebe ich Dir recht, nur bin ich mir halt noch nicht sicher, wie das mit optionalen Features ist...

Bis denne

Razor

Exxtreme

2002-05-25, 18:10:03

Originally posted by Razor

Jedes (zu TruForm-ende) Polygon muss makiert werden !
Und das soll keinen Aufwand bedeuten ?

Klar, bei 'ner Handvoll Polys von Q1/2 wird's wohl nur ein paar Tage dauern, aber bei Games ala RTCW, MoHAA, SOF2 (oder ähnlichen) dürfte der Aufwand sehr viel heftiger sein...

Du übersiehst wahrscheinlich eine Sache. Du kannst weiter mit Low-Poly-Modellen ala Q2 arbeiten und diese dann zu High-Poly-Modellen per TruForm konvertieren. Keiner zwingt dich High-Poly-Modelle ala RtCW zu 'truformen'. somit könntest du TruForm als eine Art Geometriekompression 'missbrauchen'. Das würde auch den AGP entlasten, da über diesen Bus nur Low-Poly-Modelle geschickt werden und diese dann in der GraKa zu High-Poly-Modellen umgewandelt werden.

Gruß
Alex

Demirug

2002-05-25, 18:18:46

@zeckensack:

Pro-Modeler arbeitem im Bezug auf die normalen ein bischen anders. Dort ist ist es möglich an einen Punkt mehrer Normalen anzuhängen.

Was nun dein Verfahren angeht so löst es aber IMO ein Problem nicht.

Beispiel:

Man hat eine Quadratische Platte die an eine Seitenfläche (Nord) abgerundet ist. Um polys zu sparen wurden allerdings nur 2 Kanten in der gerundeten Fläsche eingefügt.

Wenn man nun dein Verfahren benutzt haben wir folgende Abschnitte

1. Süd
2. West
3. Ost
4. Oben+Unten+Nord

Das Porblem entsteht nun beim Tesslasieren an der Verbindung 4 zu 2 und 4 zu 3.

Da bei der West und Ost Fläche alle Normalen jeweils in eine Richtung zeigen wird an der Fläche nichts verändert.

Dadurch entstehen an der im LowPoly model geschlossenen Kante in TruForm Löcher.

Xmas

2002-05-25, 18:32:52

Originally posted by Demirug
@Xmas:

Die Anzahl der Dreiecke zu erhöhen bringt aber auf jeder Karte etwas.
Und was dich jetzt vielleicht wundern wird:

Mehr Dreiecke -> weniger Aufwand -> weniger Kosten
Ich weiß, war ein schlechtes Beispiel. Die Models werden ja i.A. vereinfacht bis die Polygonzahl passt. Ich denke aber was ich damit meinte war klar.

Allerdings bringen mehr Dreiecke auch nicht auf jeder Karte etwas - nicht wenn die Karte dann zu langsam ist... ;)

"Zum Glück werden nicht alle Entscheidungen nach wirtschaftlichen Gesichtspunkten getroffen."

Wenn ich jetzt gehäsig bin würde ich sagen das deshalb im Moment in Deutschland ein Studio nach dem anderen Konkurs anmelden muss.
Vielleicht weil sie es übertreiben, aber Gamedesign ist nun mal auch eine künstlerische Arbeit, und ein Designer hat sicher nicht als oberstes Ziel, maximalen Profit herauszuschlagen.

Und wenn die Grafik dann auf einer neuen GeForce nicht so ist wie in den TruFrom Screenshots hab ich Ärger mit der Kundschaft.
Finde ich etwas übertrieben.

Erste Grundregel im Gamedesign: Jedes Feature welches nicht unbedingt erforderlich ist wird gestrichen um die Kosten zu senken.
Das mag die erste Grundregel für den Publisher, aber nicht für die Designer sein. Wenn man sich daran immer halten würde, würden Spiele recht ärmlich aussehen...

Quasar

2002-05-25, 18:40:52

Originally posted by Xmas

Und wenn die Grafik dann auf einer neuen GeForce nicht so ist wie in den TruFrom Screenshots hab ich Ärger mit der Kundschaft.

Finde ich etwas übertrieben.

Erinnerst du dich noch an die Aufregung, als bei irgendeinem C6C auf der Packung tolle Explosionen zu sehen waren, die's im Game dann aber doch nicht gab?

Ich denke, hier hat Demirug durchaus recht...

Demirug

2002-05-25, 18:41:59

Originally posted by Xmas

Ich weiß, war ein schlechtes Beispiel. Die Models werden ja i.A. vereinfacht bis die Polygonzahl passt. Ich denke aber was ich damit meinte war klar.

Mir ist schon klar was du sagen wolltes.

Allerdings bringen mehr Dreiecke auch nicht auf jeder Karte etwas - nicht wenn die Karte dann zu langsam ist... ;)

Das ist ja der Grund warum sich Highpoly noch nicht durchgesetzt.

Vielleicht weil sie es übertreiben, aber Gamedesign ist nun mal auch eine künstlerische Arbeit, und ein Designer hat sicher nicht als oberstes Ziel, maximalen Profit herauszuschlagen.

Das nicht aber er hat ein Buget an das er sich halten muss.

Finde ich etwas übertrieben.

Zugegeben war etwas überspitzt. Aber die Typen gibts wirklich die beim Support anrufen und sich beschweren warum bei ihnen die Grafik nicht so aussieht wie im Promovideo aus dem Internet.

Das mag die erste Grundregel für den Publisher, aber nicht für die Designer sein. Wenn man sich daran immer halten würde, würden Spiele recht ärmlich aussehen...

Nein. Das ganze ist ja eine Spirale. Jedes "sinnvolle" Feature das mein direkter Mitbewerber hat brauche ich auch und dann noch etwas mehr.

Xmas

2002-05-25, 19:05:53

Originally posted by Razor
Jedes (zu TruForm-ende) Polygon muss makiert werden !
Und das soll keinen Aufwand bedeuten ?

Zumal es wohl keine Entwicklungs-Kits gibt, die diese Form der 'Objekt-Markierung' unterstützten. Wie stellst Du Dir das also vor, dies in relativ kurzer Zeit (nachträglich ?) zu bewerkstelligen ?
???
Hier scheint ein Missverständnis vorzuliegen.
Das "Markieren" soll nur den Vorgang etwas vereinfacht beschreiben, genauer gesagt muss man an allen Kanten, die nicht gerundet werden sollen, die Eckpunkte/Normalen verdoppeln bzw. auftrennen. Wieviel Aufwand das ist, hängt natürlich auch vom Model und Modeler ab. Es kann aber auch zum großen Teil automatisch geschehen (wie Zeckensack beschrieben hat), auch wenn dann Korrekturen nötig sein könnten.
Aber da man das Resultat sofort sehen kann, sieht man auch sofort wo nachgebessert werden muss.

Originally posted by Razor
"Natürlich wird Hardware, die PS2.0 bietet, acuh die alten Shader unterstützen. Erstens wäre ziemlich unpraktisch, wenn sie nicht abwärtskompatibel wären und zweitens sind die höheren Shaderversionen mächtiger, so dass es kein Problem ältere Sachen darauf umzusetzen (Der Treiber muß aus dem Shadercode ja sowieso den Microcode für die Karte erzeugen)."

Was spricht dagegen, sowohl PS2.0, als auch PS1.3 zu unterstützen ?
?
Das ist doch mit Abwärtskompatibilität gemeint. Eine PS2.0-Karte sollte auch mit "alteren" Shadern wunderbar zurechtkommen.

"Auch in der DX8 Doku steht, dass eine Version immer eine niedere einschließt:"

Vorsicht !
Es gibt keine Karte der Welt, die zur Zeit volle DX8-Unterstützung bietet...

Will sagen, es gibt zwingende Voraussetzungen für einen Treiber, der DX-Compliant ist und eben auch Optionales, wie z.Bsp. die PS1.4, die eben nicht (!) Voraussetzung für eine DX8.1-Compliance ist... (weswegen ja auch Parhelia und gf3/4ti DX8.1-Compliant sind)

Bei Voraussetzungen gebe ich Dir recht, nur bin ich mir halt noch nicht sicher, wie das mit optionalen Features ist...
Das hat nichts mit Voraussetzungen oder Optionalem zu tun. Wenn eine Karte PS Version X unterstützt, dann muss sie auch alle Versionen <X unterstützen. Das sagt die DX-Dokumentation aus, und ich bin mir sicher MS wird diese Konvention mit DX9 nicht ändern.

Originally posted by Quasar

Erinnerst du dich noch an die Aufregung, als bei irgendeinem C6C auf der Packung tolle Explosionen zu sehen waren, die's im Game dann aber doch nicht gab?

Ich denke, hier hat Demirug durchaus recht...
Ich erinnere mich an die "Screenshots", allerdings habe ich die "Aufregung" wohl nicht mitbekommen...
Zudem bekommt man N-Patches ja im Spiel zu sehen - auf entsprechender Hardware. Für PixelShader braucht man ja auch die entsprechende Hardware...

Demirug,
ich hab dein Beispiel leider nicht ganz verstanden. Könntest du das mal grafisch zeigen?

Demirug

2002-05-25, 19:38:50

So ich hab mal was gezeichnet. Sieht aber nicht so toll aus. Kann nicht zeichnen.

Also die roten Kanten habe alle eine 90 Grad Winkel und werden deshalb als Harte Kante angesehen.

Bei den grünen Kanten haben wir einen 135 Grad Winkel = weiche Kante.

Bei den blauen Stellen entstehen bei Truform Löcher.

Die Stellen oben und unten wären noch relative leicht entfernbar.

Razor

2002-05-26, 08:53:27

@Exxtreme
Du übersiehst wahrscheinlich eine Sache. Du kannst weiter mit Low-Poly-Modellen ala Q2 arbeiten und diese dann zu High-Poly-Modellen per TruForm konvertieren. Keiner zwingt dich High-Poly-Modelle ala RtCW zu 'truformen'. somit könntest du TruForm als eine Art Geometriekompression 'missbrauchen'. Das würde auch den AGP entlasten, da über diesen Bus nur Low-Poly-Modelle geschickt werden und diese dann in der GraKa zu High-Poly-Modellen umgewandelt werden.
Und genau das würde bedeuten, daß Games dann auf einer TruForm-Karte sehr viel besser aussehen, als auf allen anderen Karten... (oder anders herum, sieht's auf nicht-Truform-Karten dann sehr schlecht aus), aber das hatten wir schon mal. Es könnte also die Entwickler dazu führen, nur noch Low-Poly-Modelle zu benutzen und den Rest dann durch die GraKa machen zu lassen. Ob das so sinnvoll ist ?

Auch würden die meisten Nutzer da draußen außen vor gelassen werden, was sicher nicht im Sinne der Game-Designer sein kann.

Da finde ich den Ansatz von Matrox, eben DM zu nutzen, doch um einiges interessanter, auch wenn es bedeutet,in der nächsten Zeit dann quasi 2 Engines zu designen...

@Xmas
Hier scheint ein Missverständnis vorzuliegen.
Das "Markieren" soll nur den Vorgang etwas vereinfacht beschreiben, genauer gesagt muss man an allen Kanten, die nicht gerundet werden sollen, die Eckpunkte/Normalen verdoppeln bzw. auftrennen. Wieviel Aufwand das ist, hängt natürlich auch vom Model und Modeler ab. Es kann aber auch zum großen Teil automatisch geschehen (wie Zeckensack beschrieben hat), auch wenn dann Korrekturen nötig sein könnten.
Aber da man das Resultat sofort sehen kann, sieht man auch sofort wo nachgebessert werden muss.
Nun ja, Demirug hat doch ganz gut beschrieben, daß der Anzatz von zeckensack (der sicherlich in bestimmten Situationen funktionieren kann) nicht unbedingt zum gewünschten Ergebnis führt. Habe natürlich nicht den technischen Durchblick, um hier mitzureden, aber es ist durchaus nachvollziehbar, daß das beste Ergebnis noch immer dann erzielt wird, wenn man es von vornherein im Modell-Design berücksichtigt (siehe auch polynominale Flächen).

Der einzige Vorteil liegt IMHO bei TruForm noch immer in der 'leichten' Implementierung, die dann aber nicht das gewünschte Ergebnis bringt. Wenn es also 'richtig' gemacht werden soll, kommen wirtschaftliche Gesichtspunkte zum Tragen...
?
Das ist doch mit Abwärtskompatibilität gemeint. Eine PS2.0-Karte sollte auch mit "alteren" Shadern wunderbar zurechtkommen.
Du hast meinen Post nicht richtig gelesen...

Ich schieb:
"Was spricht dagegen, sowohl PS2.0, als auch PS1.3 zu unterstützen ?"

Wenn die PS2.0 nun einen völlig neuen Ansatz verfolgen, dann heißt dies doch nicht zwangsläufig ALLES vorherige untertützt werden muß. Analog zum VertexShader vs. HW T&L kann es wie bei der gf3 über ein und dasselbe ausgeführt werden, oder eben über 2 Einheiten ala R200 (und vermutlich auch NV30). Mir geht es um die zwingende Notwendigkeit, für den PS2.0 eben auch PS1.4 zu unterstützen.

Da für die DX8.1-Complinace offensichtlich der PS1.1 ausreicht, könnte ich mir gut vorstellen, daß auch nur dieser dann voraussetzung für den PS2.0 ist, nicht aber zwingend die 'Erweiterungen'... Sicher kann das dann noch via emu implementiert werden, aber ein 'muss' ist dann doch etwas anderes, als ein 'kann', oder ? Schließlich ist der PS1.4 auch bei DX8.1 nur optional...
Das hat nichts mit Voraussetzungen oder Optionalem zu tun. Wenn eine Karte PS Version X unterstützt, dann muss sie auch alle Versionen <X unterstützen. Das sagt die DX-Dokumentation aus, und ich bin mir sicher MS wird diese Konvention mit DX9 nicht ändern.
Die PixelShader wurden doch erst mit DX8 eingeführt. Daß dies also für die PS1.x-Versionen gilt, kann ich sehr gut nachvollziehen. Ob es dann allerdings auch für die DX-Hauptsprünge gilt, wage ich zumindest in Frage zu stellen...

Was ist denn, wenn eine Hardware nur 4 oder 8 Texturen nutzen kann ?
Ist sie dann dazu gezwungen im Falle der PS1.4 dann eben 2 brach liegen zu lassen ?
Heißt es dann für den PS2.0, daß dann auch zwingend 6 Texturen in einem Pass verarbeitet werden müssen (ist ja schließlich eine Hardware-Implementierung, oder liege ich da jetzt flasch ?) ?
Hmmm...

Wenn die offizielle DX9-Compliance vergeben wird, dan wissen wir sicherlich mehr...
Ich erinnere mich an die "Screenshots", allerdings habe ich die "Aufregung" wohl nicht mitbekommen...
Zudem bekommt man N-Patches ja im Spiel zu sehen - auf entsprechender Hardware. Für PixelShader braucht man ja auch die entsprechende Hardware...
Für die Pixel-Shader gibt es ja auch in jedem Fall ein FallBack (was dann eben nicht so schön aussieht). Bei TruForm müsste der FallBack dann aber eben HighPolyModelle sein, wodurch sich dan für die Entwickler kein Vorteil mehr ergibt, da sie ja nicht ausschließlich auf LowPolyModelle setzen können.

Ein paar Shader-Effekte zu unterschlegen ist ja noch legitim (siehe z.Bsp. Morrowind oder Comache 4). Aber die Details dann extrem herunter zu schrauben, nur weil eine Karte (die meisten !) dann keine N-Patches unterstützen, ist nicht vertretbar. Und bei HighPolyModellen kann man ja uch noch immer in den Einstellungen dann Justierungen vornehmen, die es einem gestatten, die Poly-Fülle auf die eigenen GraKa anzupassen, wenn man will !

Bis denne

Razor

AlfredENeumann

2002-05-26, 11:55:28

Razor. Ich sehe du hast den Sinn von TruForm immer noch nicht verstanden.

Xmas

2002-05-26, 18:03:21

Originally posted by Demirug
So ich hab mal was gezeichnet. Sieht aber nicht so toll aus. Kann nicht zeichnen.

Also die roten Kanten habe alle eine 90 Grad Winkel und werden deshalb als Harte Kante angesehen.

Bei den grünen Kanten haben wir einen 135 Grad Winkel = weiche Kante.

Bei den blauen Stellen entstehen bei Truform Löcher.

Die Stellen oben und unten wären noch relative leicht entfernbar.
Nun, man müsste an diesen Stellen entsprechende "Füllpolygone" einfügen, was auch automatisch geschehen kann.
Das Problem bei diesen Füllpolygonen wäre nur, dass ihre Normalen nicht "korrekt" wären, sondern so gewählt dass die N-Patches die passende Form haben. Allerdings kann man diese Normalen per Vertex Shader ja wieder ersetzen.

Originally posted by Razor
Nun ja, Demirug hat doch ganz gut beschrieben, daß der Anzatz von zeckensack (der sicherlich in bestimmten Situationen funktionieren kann) nicht unbedingt zum gewünschten Ergebnis führt. Habe natürlich nicht den technischen Durchblick, um hier mitzureden, aber es ist durchaus nachvollziehbar, daß das beste Ergebnis noch immer dann erzielt wird, wenn man es von vornherein im Modell-Design berücksichtigt (siehe auch polynominale Flächen).

Der einzige Vorteil liegt IMHO bei TruForm noch immer in der 'leichten' Implementierung, die dann aber nicht das gewünschte Ergebnis bringt. Wenn es also 'richtig' gemacht werden soll, kommen wirtschaftliche Gesichtspunkte zum Tragen...
Man kann es ja von vornherein im Model-Design berücksichtigen. Eine TruForm-Vorschau von ein paar tausend Polygonen ist problemlos in "Echtzeit" möglich. Der Modeler kann während seiner Arbeit permanent überprüfen, ob irgendwo kleinere Fehler drin sind.

Bevor ich zu PS antworte, ein paar Anmerkungen.

Man muss bei PS drei Dinge unterscheiden: Die Sprache, die Definition was damit alles möglich ist (Featureset) und die Hardware-Implementation (Pipeline).
(Mit "Shader" meine ich im Folgenden ein PS-Programm)

Die Sprache ist von PS1.0 zu PS1.3 nur erweitert worden, bei PS1.4 wurde sie abgeändert.
PS1.3 ist "sprachlich" abwärtskompatibel, PS1.4 nicht.
Nimmt man einen PS1.0-Shader und ändert die Versionsnummer am Anfang auf 1.3, läuft es immer noch (sofern die Hardware PS 1.3 unterstützt), setzt man sie auf 1.4 funktioniert es höchstwahrscheinlich nicht.

Das Featureset wurde von PS1.0 zu 1.4 immer erweitert. Alles was PS1.0 kann kann PS1.1 auch. Alles was PS1.3 kann kann PS1.4 auch (der Schritt war hier etwas größer).
Die sprachliche Umsetzung ist aber im Falle eines PS1.4-Shaders eine andere.

Die Pipeline ist in ihrem Aufbau nicht an die Sprache gebunden.
Es ist nur recht praktisch wenn Ähnlichkeiten vorhanden sind. Da die PS-Versionen ja zum großen Teil von NVidia und ATI stammen, ist hier natürlich eine direkte Entsprechung Sprache <-> Hardware keine Überraschung.
Andere Firmen können durchaus eine völlig andere Implementierung wählen, wichtig ist nur dass das entsprechende Featureset unterstützt wird, nicht wie es unterstützt wird.
Auch ist die Pipeline nicht auf dieses Featureset beschränkt, sondern kann evtl. auch weit mehr bieten. Darauf könnte man dann aber unter DirectX nicht zugreifen.

Du hast meinen Post nicht richtig gelesen...

Ich schieb:
"Was spricht dagegen, sowohl PS2.0, als auch PS1.3 zu unterstützen ?"
Also meinst du, PS1.3-Pipelines und PS2.0-Pipelines getrennt im Chip zu implementieren...
Halte ich ehrlich gesagt für völlig unnötige Verschwendung von Chipfläche. PS2.0-fähige Pipelines unterstützen auch das PS1.3-Featureset. Warum sollte man das tun?

Wenn die PS2.0 nun einen völlig neuen Ansatz verfolgen, dann heißt dies doch nicht zwangsläufig ALLES vorherige untertützt werden muß. Analog zum VertexShader vs. HW T&L kann es wie bei der gf3 über ein und dasselbe ausgeführt werden, oder eben über 2 Einheiten ala R200 (und vermutlich auch NV30). Mir geht es um die zwingende Notwendigkeit, für den PS2.0 eben auch PS1.4 zu unterstützen.
Das PS2.0-Featureset wird eine Obermenge des PS1.4-Featuresets sein. Sonst wäre PS2.0 praktisch unbrauchbar.
Ich glaube übrigens nicht dass der R200 wirklich zwei getrennte Einheiten hat, lediglich Teile doppelt ausgelegt. Noch weniger glaube ich dass der NV30 eine festverdrahtete T&L-Einheit haben wird.

Da für die DX8.1-Complinace offensichtlich der PS1.1 ausreicht, könnte ich mir gut vorstellen, daß auch nur dieser dann voraussetzung für den PS2.0 ist, nicht aber zwingend die 'Erweiterungen'... Sicher kann das dann noch via emu implementiert werden, aber ein 'muss' ist dann doch etwas anderes, als ein 'kann', oder ? Schließlich ist der PS1.4 auch bei DX8.1 nur optional...
DX-Compliance ist eh ein sehr schwammiger Begriff, den die Hersteller anscheinend verwenden wie sie gerade wollen.
Was meinst du mit "via Emu"? Ich finde der Begriff Emulation passt hier nicht.

Was ist denn, wenn eine Hardware nur 4 oder 8 Texturen nutzen kann ?
Ist sie dann dazu gezwungen im Falle der PS1.4 dann eben 2 brach liegen zu lassen ?
Klar. Ebenso wie eine R8500 gezwungen ist, bei PS1.3-Shadern den zweiten möglichen Loopback nicht zu nutzen.

Heißt es dann für den PS2.0, daß dann auch zwingend 6 Texturen in einem Pass verarbeitet werden müssen (ist ja schließlich eine Hardware-Implementierung, oder liege ich da jetzt flasch ?) ?
Hmmm...
PS2.0 erlaubt/erfordert AFAIK 8 Texturkoordinaten, 16 Texturen und 32 Texturzugriffe sowie 64 mathematische Operationen pro Pass. Das ist wohl etwas mehr...

Demirug

2002-05-26, 19:53:47

@Xmas:

Ich wollte mit meinem Beispiel auf zwei Problem aufmerksam machen.

1. Das ermitteln ob eine Kante hart oder weich sein soll geht nicht alleine über die Winkel der Flächennormale.

2. Mit den Füllpolygonen ist das nicht so einfach. Bei Karten ohne Trueform dürfen ja keine erzeugt werden. Und selbst für TruForm Karten finde ich im Moment keine möglichkeit die Normalen so zu setzen das es keine Löcher gibt. Ich will damit aber nicht behaupten das es keine gibt.

Ich denke das DM mehr Zukunft hat vorausgesetzt es gibt genügend gute Tools für die Grafiker und alle großen Chip-Hersteller unterstüzen es.

Was die Pixelshader angeht:

Full Ack.

Noch was zu dem Bergriff "Complinace" in Verbindung mit Direct X. So etwas gibt es nicht. DirectX ist lediglich eine Sammlung von genormten Features. Jeder Hersteller sucht sich selber aus welche er unterstützen will.

Razor

2002-05-26, 19:58:57

@AlfredENeumann
Razor. Ich sehe du hast den Sinn von TruForm immer noch nicht verstanden.
Dann bist Du ziemlich blind...
Irgendwie schein der Inhalt dieser Diskussion an Dir vorbei gegangen zu sein.

@Xmas
Nun, man müsste an diesen Stellen entsprechende "Füllpolygone" einfügen, was auch automatisch geschehen kann.
Das Problem bei diesen Füllpolygonen wäre nur, dass ihre Normalen nicht "korrekt" wären, sondern so gewählt dass die N-Patches die passende Form haben. Allerdings kann man diese Normalen per Vertex Shader ja wieder ersetzen.
Und wie ist das dann mit der Abwärtskompatibilität ?
Man kann es ja von vornherein im Model-Design berücksichtigen. Eine TruForm-Vorschau von ein paar tausend Polygonen ist problemlos in "Echtzeit" möglich. Der Modeler kann während seiner Arbeit permanent überprüfen, ob irgendwo kleinere Fehler drin sind.
Und das soll nicht aufwändig sein ?
Auch würde dies voraussetzen, daß auch mit einer R200 entwickelt wird, was viele Entwickler wohl offensichtlich noch nicht tun (aus welchem Grund auch immer). Meiner Meinung nach ein wenig zu viel Voraussetzungen, oder findest Du das nicht ?

Das es grundsätzlich möglich wäre, will ich doch überhaupt nicht abstreiten, es geht mir ausschlißlich um den Aufwand der damit getrieben werden muß. Zu viele 'wenn' und 'aber' und das für eine sehr kleine Käuferschicht, die zudem vermutlich eher auf Multimedia aus ist, denn auf's Spielen...

Sorry, der Aufwand, um TruForm zu implementieren, mag zwar lange nicht so hoch sein, wie ich es mir zuerst vorstellte, aber ist immer noch zu viel, um einen wirtschaftlichen Nutzen zu erkennen. In der Demo-Scene kann man übrigens auch sehr gut erkennen, daß sich TruForm dort offensichtlich überhaupt nicht 'eingebürgert' hat. Daran ist doch eigentlich sehr gut zu erkennen, daß die 'richtigen' Künstler (diejenigen, die wirklich aus reinem Spaß an der Freud Dinge hervorzaubern und so gut wie keine wirtschaftlichen Abhängigkeiten haben) dafon offensichtlich überhaupt nicht begeistert sind.
Man muss bei PS drei Dinge unterscheiden: Die Sprache, die Definition was damit alles möglich ist (Featureset) und die Hardware-Implementation (Pipeline).
(Mit "Shader" meine ich im Folgenden ein PS-Programm)

Die Sprache ist von PS1.0 zu PS1.3 nur erweitert worden, bei PS1.4 wurde sie abgeändert.
PS1.3 ist "sprachlich" abwärtskompatibel, PS1.4 nicht.
Nimmt man einen PS1.0-Shader und ändert die Versionsnummer am Anfang auf 1.3, läuft es immer noch (sofern die Hardware PS 1.3 unterstützt), setzt man sie auf 1.4 funktioniert es höchstwahrscheinlich nicht.

Das Featureset wurde von PS1.0 zu 1.4 immer erweitert. Alles was PS1.0 kann kann PS1.1 auch. Alles was PS1.3 kann kann PS1.4 auch (der Schritt war hier etwas größer).
Die sprachliche Umsetzung ist aber im Falle eines PS1.4-Shaders eine andere.
Herzlichen Dank nochmal, Xmas, für diese sehr dezaillierte und leicht verständliche Darstellung !
Bis hierhin trifft diese Darstellung meinen Kenntnisstand...
Die Pipeline ist in ihrem Aufbau nicht an die Sprache gebunden.
Es ist nur recht praktisch wenn Ähnlichkeiten vorhanden sind. Da die PS-Versionen ja zum großen Teil von NVidia und ATI stammen, ist hier natürlich eine direkte Entsprechung Sprache <-> Hardware keine Überraschung.
Andere Firmen können durchaus eine völlig andere Implementierung wählen, wichtig ist nur dass das entsprechende Featureset unterstützt wird, nicht wie es unterstützt wird.
Auch ist die Pipeline nicht auf dieses Featureset beschränkt, sondern kann evtl. auch weit mehr bieten. Darauf könnte man dann aber unter DirectX nicht zugreifen.
Schon klar...
Die Hardware ist Herstellersache, der Rest eine Sache des Treibers...

Und da DirectX keine Hersteller-spezifischen Implementierungen vorsieht (wie bei OpenGL), gibt es sowohl Dinge, die eine Hardware/Treiber-Combo, die ansonsten DX-Compliant ist, unterstützt und eben Dinge die es nicht unterstützt (wie z.Bsp. bei der DX8.1-Karte gf3/4, die eben keinen PS1.4 unterstützt, was aber auch keine Voraussetzung ist). Zusätzlich eben auch Features haben kann, die aus zuvor genannten Gründen nicht Einzug in DX fanden und somit von dieser API nicht unterstützt werden und es einer Applikation, die darüber auf den Treiber zugreift, eben auch unmöglich macht, diese zu nutzen...

Soweit, so gut.
Also meinst du, PS1.3-Pipelines und PS2.0-Pipelines getrennt im Chip zu implementieren...
Halte ich ehrlich gesagt für völlig unnötige Verschwendung von Chipfläche. PS2.0-fähige Pipelines unterstützen auch das PS1.3-Featureset. Warum sollte man das tun?
Nein, das meinte ich anders...
Warum soll die Pipeline nicht in der Lage sein, sowohl Shader der Version 2.0 auszzuführen, wie auch Shader der Version bis 1.3. Aber eben nicht Shader der Version 1.4, da diese sich ja, wie Du schon vorher dargestellt hast, doch in der Sprache sehr unterschiedlich darstellen. Eben nicht PS1.0/3 und vermutlich auch nicht PS2.0 (wohl aber sehr ähnlich). Es wäre eine Sache des Treibers, die PS1.4-Sprache in eine PS2.0-Kompatible Version zu übersetzen, wenn die Pipeline grundsätzlich dazu in der Lage wäre, die Shader der Version 1.4 über 2.0 auszuführen. Wenn ich das richtig verstanden habe, versteht die Pipeline die PS1.0/3-Sprache je ebenso nicht (ich spreche hier von dem umgesetzten Microcode !), insofern der Treiber die PS1.0/3 Shader in PS1.4 Shader übersetzt, um diese dann auszuführen...
Das PS2.0-Featureset wird eine Obermenge des PS1.4-Featuresets sein. Sonst wäre PS2.0 praktisch unbrauchbar.
Ich glaube übrigens nicht dass der R200 wirklich zwei getrennte Einheiten hat, lediglich Teile doppelt ausgelegt. Noch weniger glaube ich dass der NV30 eine festverdrahtete T&L-Einheit haben wird.
Wieso wäre der PS2.0 unbrauchbar, wenn er keine Obermenge der PS1.4 ist ?
???

Auch wird beim NV30 nicht von einer festverdrahteten T&L-Einheit im Sinne von DX7 T&L die Rede sein. nVidia selber nennte das Wohl TT&L und meint damit vermutlich eine DX8/9 T&L-Einheit ala Vertex/Pixel-Shader...
DX-Compliance ist eh ein sehr schwammiger Begriff, den die Hersteller anscheinend verwenden wie sie gerade wollen.
Was meinst du mit "via Emu"? Ich finde der Begriff Emulation passt hier nicht.
Die DX-Compliance wird von M$ vergeben, was aber das Ganze nich unbedigt weniger 'schwammig' macht...

Und mit 'via emu' meine ich schlicht und ergreifend die Übersetzung eines PS1.4 Shaders in einen PS2.0 Shader vor Ausführung. Ein ganz normale 'emu' halt... eine Art Wrapper vielleicht...
Klar. Ebenso wie eine R8500 gezwungen ist, bei PS1.3-Shadern den zweiten möglichen Loopback nicht zu nutzen.
Genau das habe ich gemeint !
PS2.0 erlaubt/erfordert AFAIK 8 Texturkoordinaten, 16 Texturen und 32 Texturzugriffe sowie 64 mathematische Operationen pro Pass. Das ist wohl etwas mehr...
Ahhh....
Das wußte ich nicht nicht.
Thx for the info !

Bis denne und nochmals vielen Dank für die sehr ausführliche, auch für mich verständliche Darstellung.

Razor

nggalai

2002-05-26, 20:10:32

Hi Razor,

nur kurz:Wieso wäre der PS2.0 unbrauchbar, wenn er keine Obermenge der PS1.4 ist ?
???XMas spricht da vom Featureset. Und ja, wenn PS2.0 nicht alle Features von PS1.4 unterstützen würde, wäre er echt unbrauchbar--weshalb braucht man denn eine höhere, bessere Version wenn sie noch nicht mal alle Effekte des Vorgängers beherrscht? Stell dir mal vor was los wäre, wenn man mit Pixelshadern kein DOT3 Bump Mapping umsetzen könnte . . . oder Du kaufst Dir Word2002, und plötzlich kann's bedeutend weniger als Word2001 . . . ;)

Ansonsten: lies bitte XMas (übrigens sehr gutes) Posting nochmals aufmerksam durch. Die meisten deiner Einwürfe und Fragen werden darin bereits beantwortet.

ta,
-Sascha.rb

Demirug

2002-05-26, 20:15:53

zeckensack

2002-05-26, 20:20:36

Originally posted by Demirug
Damit mit dieser Pixelshader geschichte endlich mal Ruhe ist:

Ein DX Treiber meldet die maximale Pixelshader Version die er unterstützen kann. Dadurch müssen aber auch alle Pixelshader mit e einer kleinere Versionnummer unterstützt werden.

Demirug, DirectX 9 Beta Tester Danke :)

Exxtreme

2002-05-26, 20:22:33

Und zeckensack? Haste deine R8500 schon bekommen?

Gruß
Alex

zeckensack

2002-05-26, 20:27:02

Originally posted by Exxtreme
Und zeckensack? Haste deine R8500 schon bekommen?

Gruß
Alex Ohhh, dieser Schmerz ;(

Näheres dazu hab ich hier (http://www.forum-3dcenter.org/vbulletin/showthread.php?threadid=20481) schon geschrieben. :bawling:

nggalai

2002-05-26, 20:29:06

Damit mit dieser Pixelshader geschichte endlich mal Ruhe ist:

Ein DX Treiber meldet die maximale Pixelshader Version die er unterstützen kann. Dadurch müssen aber auch alle Pixelshader mit e einer kleinere Versionnummer unterstützt werden.

Demirug, DirectX 9 Beta TesterDanke, Demiurg.

Hmm. Beta ist ja draussen, das heisst wohl, dass deine Ferien jetzt auch flöten sind, nicht? ;)

ta,
.rb

Demirug

2002-05-26, 20:35:08

Originally posted by nggalai
Danke, Demiurg.

Hmm. Beta ist ja draussen, das heisst wohl, dass deine Ferien jetzt auch flöten sind, nicht? ;)

ta,
.rb

Nein, auf die eine Woche kommt es nicht an. Da ich ja sowieso Technophil veranlagt bin ist es für mich keine Arbeit sich mit etwas neuen zu beschäftigen. Mir gehen eher Routine jobs auf die Nerven.

Xmas

2002-05-27, 00:17:18

Originally posted by Razor
Nein, das meinte ich anders...
Warum soll die Pipeline nicht in der Lage sein, sowohl Shader der Version 2.0 auszzuführen, wie auch Shader der Version bis 1.3.
Na dazu ist sie doch auf jeden Fall in der Lage! Wie ich schon oben schrieb, das Featureset der PS2.0 ist eine Obermenge von PS1.x. Eine PS2.0-fähige Pipeline kann alles was eine PS1.x-fähige auch kann - und mehr! Nur nicht zwangsläufig auf dieselbe Art und Weise.

Analogie: Ein Pentium kann alles was ein 8086er auch kann - und mehr! Nur nicht zwangsläufig auf dieselbe Art und Weise.

Aber eben nicht Shader der Version 1.4, da diese sich ja, wie Du schon vorher dargestellt hast, doch in der Sprache sehr unterschiedlich darstellen. Eben nicht PS1.0/3 und vermutlich auch nicht PS2.0 (wohl aber sehr ähnlich). Es wäre eine Sache des Treibers, die PS1.4-Sprache in eine PS2.0-Kompatible Version zu übersetzen, wenn die Pipeline grundsätzlich dazu in der Lage wäre, die Shader der Version 1.4 über 2.0 auszuführen. Wenn ich das richtig verstanden habe, versteht die Pipeline die PS1.0/3-Sprache je ebenso nicht (ich spreche hier von dem umgesetzten Microcode !), insofern der Treiber die PS1.0/3 Shader in PS1.4 Shader übersetzt, um diese dann auszuführen...
Razor,
in meinem obigen Posting steht ein ganz wichtiger Satz, den du leider scheinbar nicht so verstanden hast wie ich mir das gewünscht hätte:

Die Pipeline ist in ihrem Aufbau nicht an die Sprache gebunden.

Es gibt keine Pipeline, die PS x.y versteht, sondern nur eine die PS x.y kann (d.h. das entsprechende Featureset unterstützt)

Zudem gibt es bei aktueller Hardware noch keinen "umgesetzten Microcode". Aktuelle Combinerlogik arbeitet nicht wie eine CPU auf "Instruktionsbasis". Das wird sich in Zukunft ändern (P10). Aber ob es Microcode gibt oder der Treiber sonstwie States setzt ist auch unerheblich.

Ich schreibe zwei kurze Programme, eins in C, eins in Pascal. Beide tun genau dasselbe, sehen aber aufgrund der Sprachen im Quelltext anders aus. Wenn ich beide Programme für dieselbe Maschine kompiliere, ist es gut möglich dass derselbe Maschinencode dabei herauskommt.

Ich schreibe ein kurzes C-Programm und kompiliere es einmal für eine Motorola 68k-CPU und einmal für eine Intel x86-CPU. Der Quelltext ist in beiden Fällen gleich, das Programm tut in beiden Fällen genau dasselbe. Aber der generierte Maschinencode ist unterschiedlich.

Ich denke diese beiden Beispiele sollten gut zeigen, was ich mit obiger Aussage meine.

Wieso wäre der PS2.0 unbrauchbar, wenn er keine Obermenge der PS1.4 ist ?
???
Wie nggalai schon sagte...

Stell dir mal vor, TaschenRechner 1.0 kann achtstellige Zahlen addieren. Mit TR1.3 kommt noch das Subtrahieren hinzu.
TR1.4 kann sogar Multiplizieren und mit zehnstelligen Zahlen umgehen, wenn man dies allerdings nutzen will muss man die Operation in anderer Reihenfolge eingeben.

Nun ist es Zeit für TR2.0. Wirft man da die Multiplikation wieder raus?

Und PS1.x sind zur Zeit wirklich nicht mehr als "Grundrechenarten".

Auch wird beim NV30 nicht von einer festverdrahteten T&L-Einheit im Sinne von DX7 T&L die Rede sein. nVidia selber nennte das Wohl TT&L und meint damit vermutlich eine DX8/9 T&L-Einheit ala Vertex/Pixel-Shader...
TT&L wurde soweit ich weiß von NVidia noch nicht erwähnt... und ich halte es momentan auch eher für einen Scherz.

Und mit 'via emu' meine ich schlicht und ergreifend die Übersetzung eines PS1.4 Shaders in einen PS2.0 Shader vor Ausführung. Ein ganz normale 'emu' halt... eine Art Wrapper vielleicht...
s.o.
Wieso sollte man ein Pascal-Programm erst in C übersetzen bevor man es kompiliert?