Tabula Rasa @ nVida & ATi

[AchtBit]

Vorgeschichte zum nv30+ vs r3x0.

Der Wirbel um den FX sorgte fuer wilde Spekulationen, Kritik und Abneigung gegenueber nV.
Beide Chips haben je ihren Schwachpunkt und angefangen hat all dies, als nV in der Oeffentlichkeit ATI vorwarf ihre Archtiktur sei vorsinnflutlich.
Das waren harte Worte, die aber den Schwachpunkt des Chips widerspiegeln. nV haette es aber lieber sein lassen sollen mit Steinen zu werfen waehrend sie selbst im Glashaus sitzen.
Denn anders als der FX, spiegelt der aktuelle Radeon exakte DX9 compliance wider. Was zumindest zeigt dass ATI ihre HW im Griff hat.

Als ATI auf dem 3D Zug aufsprang blieb nicht die Zeit fuer ein ergonmisches Design, um am aktuellen Markt anzuschliessen, waehlten sie daher die bewaehrte und einfach Datenfluss Architektur.
Durch den Technologiefortschritt war es ohne Probleme moeglich eben mit dieser Architektur bei der aktuellen Topperformance ohne aufwaendige Mittel mitzuhalten.
Durch die immer schneller werdende Enwicklung der Arthimetik fuer Grafikprozessoren ist aber das Ende dieser Architektur unausweichlich.
Noch ist sie, aktuell und in naher Zukunft, die beste Voraussetzung fuer eine HiEnd Performance. Mann koennte auch sagen, sie befindet sich gerade in ihrer Bluetezeit

Wie auch immer ATI wollte sich das nicht bieten lassen und konterte mit gleicher Haerte bei HL2 Presentation.
G. Nu(e)ll war das Sprachrohr. Sein Vorwurf der FX sei nur ein auffriesierter DX8 Chip, sowie die HL Performancepresentation, trafen widerum die Schwachstelle der nV Architektur.
Die Folge war eine weitreichende Misskreditierung des Chips sowie Zweifel an der Glaubwuerdigkeit von nV.

nV hatte bei der Chipentwicklung wesentlich mehr Zeit und ging schon seit geraumer Zeit den ergonomischen Weg und liess sich alle Moeglichkeiten, wie zb. den Einsatz einer Risc Core und die Transformation zur superskalaren Architektur, offen.
Nachteilig ist hier aber die Tatsache, dass ein Teil kontinuierlich immer in der Software weiterentwickelt werden muss. Dieser wesentliche Bestandteil einer superskalaren HW ist dafuer verantwortlich dass die Architektur virtuell erweiterbar ist.
Die Anpassung auf die API wird nicht 1:1 umgesetzt sondern erst per Software auf virtueller Ebene umgesetzt. Sowas zu entwickeln benoetigt faehige Mathematiker und viel Zeit.
Erst 35 Jahre nach der Erfindung(1965) konnten die superskalare Architektur den Prozessormarkt(1995) komplett dominiern. Wer den Pentium von innen kennt, weis welch ausgekluegelte Softwareimplementationen die Mechanismen zur Virtualisierung und Optimierung des Codes im P4 darstellen.
nV war scheinbar der Meinung mit dem FX ist der Zeitpunkt gekommen einen weiteren Schritt in diese Richtung zu gehen. Ein Grund wird wohl sein, dass die Entwicklung die HW schon laenger eingeholt hat und die Entwickler warten muessen bis die spezifizierte HW verfuegbar ist.
Durch die Einfuerung eine Hochsprache fuer Shader wird die Entwicklung abermals beschleunigt, so dass man bereits HW ausnuetzen koennte die erst viel spaeter machbar waere.
Fakto, der aktuell Chip koennte alles moegliche sein, das haengt davon ab wie man ihn steuert und wie faehig die Entwickler sind virtuelle Kontrollmechanismen zu implementieren
Verglichen an seiner physikalische Struktur, hatte G.N. mit den harten Worten, es sei nur ein dx8 chip, recht. Dennoch kann er in virtueller Hinsicht auch alles andere als das sein.
Auf dieser Ebene spielt die Struktur, phyisikalisch, nur eine untergeordnete Rolle.

Cheaten tun beide.

Wo auch immer die Grenze zwischen Cheat und Optimierung liegt war in der Vergangenheit schon immer ein Streitpunkt.
Wohl gerade desshalb hat nV 3 neue Grundsaetze fuer diese Problematik geschaffen. In einer Besprechung zw. ATI und nV sind sich beide ueber diese
Grundregeln einig geworden. Sprich es wurde das Kriegsbeil begraben und falls irgend eine Form von Optimierung eingesetzt wird, dann nur nachdem
eine Partei der anderen die Methode erlaeutert hat. Ab dem naechsten Catalyst wird ATI ihre 3Mark Cheats entfernt haben.
Differenzen, insbesondere mit FM, gibt es aber bezueglich der letzten Optimierung von nV. Der treiberinterne Shader Optimizer von nV wird zukuenftig
die Vertex Shader auf partiale Genauigkeit optimieren, so geschehen im 52.16 Deto. Eine Beinflussung der IQ ist nur unwesentlich bis gar nicht erkennbar.
Ist es ein Cheat? Jain. Eine klare Aussage gibt es im Moment nicht.
Aussagen der Optimizer von nV wurde deaktiviert sind grober Unfug.
Der Optimizer ist HW transparent und niemand kann was ausschalten, das offensichtlich nicht vorhanden ist.
Warum hat der Optimizer aber den Shader nach dem Patch aber nicht mehr optimieren koennen? Das laesst den Verdacht zu, dass hier einfach der CodePfad ausgetauscht wurde.
Hinsichtlich der Aussage von nV sowie der FX Architektur, ist das Vorhaben, den Vertex Shader immer teilgenau zu optimieren, ein logischer Ansatz.
Solange der Optimizer den Shadercode aber nicht genau bestimmen kann, was aktuell der Fall ist, bleibt es ein Cheat.
Ist der Optimizer faehig den Code zu erkennen, dann ist es eine Optimierung. Die Optimierung, wie schon erwaehnt, ist fuer den FX zeitaufwendig. Der Compiler ist noch lange nicht da wo er hinsoll.
Ist sowas machbar? ja, man wird in Zukunft ziemlich genau unterscheiden koennen welcher Code vertexshaderspezifisch ist und welcher nicht.
Fuer die Zukunft spiegelt der 3Dmark aktuell nicht die tatsaechliche Spieleleistung des FX unter Vertex Shader wider.
Wenn der Optimizer zuverlaessig laeuft, bleibt FM gar nichts anderes uebrig als einzuraeumen, dass es tatsaechlich eine Optimierung ist.

Performance und Zukunft beider Chips.

Aktuell ist die ATI HW leichte zu handlen. Das heisste der durchschnittliche Entwickler wird nicht optimierten fragmentierten dx9 Code schreiben.
Der ATI Chip gibt also derzeitig klar die Performance wider die er auch in spaeteren dx9 Spielen haben wird. Abhaengig ist seine Lebensdauer davon wann DX10 eingefuehrt wird.
Bei nv variert die Performance und zwar abhaengig von automatisierten Compiler und Optimizer, von der Anstrengung der Entwickler und ob nV,individuelle Optimierung einsetzt.
Er kann im Prinzip deutlich langsamer, aehnlich schnell oder deutlich schneller sein. Zu erwaehnen waere, dass bei exklusiven Games nV Handoptimierung, zusaetzlich zum Optimizer, anlegen wird.
Gurus wie J.C. werden eigene Optimierungen einsetzten, die massive Performanceschuebe erwarten lassen. Er selbst mutet sich zu locker ueber 100 Instruktionen auf einmal koordinieren zu koennen.
Waehrend der Durchschnitt bei weniger als 30 Instruktionen schon Probleme beim Uberblicken aufweist. Man kann im Endeffekt beim FX sagen, die Faehigkeit des Entwicklers laesst sich an der Performance des Games messen und zwar wesentlich klarer wie das frueher der Fall war.
Die Lebensdauer ist nicht abzusehen weil das Potenzial nicht erkennbar ist und virtuell auch dx9+ machbar waere. Eine Schaetzung war 2005 wobei die davon ausging, dass bis dahin die Performance der HW, der des nv35+ klar ueberlegen ist.
nV hat einen neuen intensiven Entwicklersupport eroeffnet wo auch auf Fragen betreffend des Compilers/Optimizers eingegangen wird.

aktueller Stand bei nV und ATI

Beide arbeiten wieder eng zusammen. Sie kennen die Schwaechen und Staerken ihrer Produkte genau.
ATI ist sich voellig klar, dass Sie langsam ihr Chiplayout, aufgrund der akuten HW Limitierung, an die moderne Architektur anpassen muessen.
Damit nicht wieder solche extemen Unterschiede in der Architekur vorkommen teilt nV jetzt seine Erkenntnisse mit ATI.
Beide streben zukuenftige identische Architekturen an. nV ist gespraechig geworden und will auch zukuenftig keine Fakten mehr verschleiern.
Der neue Support ist bereits eroeffnet. nV haette sich auch schon frueher im klaren sein muessen, dass man so ein Projekt nicht alleine stemmen kann.
War doch klar zu sehen welche Zusammenarbeit, das Intel gekostet hat, um vollstaendige Unterstuetzung fuer ihre Pentium CPUs zu gewaehren.
Es wuerde jedem helfen, wenn nV u. ATI detailierte Datenblatter ihrer Grafikprozessoren veroeffendlichen wuerden.

Pro und Contras.

nv35+
+ sehr flexible Programmierbarkeit ueber aktuelle Spezifikationen hinaus
+ bei sehr hohen Aufloesungen (16x12+) mit voller Qualitaetseinstellung fast immer schneller als der r3x0
+ Staerken der Architektur werden bei den kommenden Topgames ausgespielt werden
+ exzellent verarbeitet u. stabile Karten, detailierter health monitor im HiEndbereich
+ sehr gute kompatiblitaet der Treiber
+ im HiEndbereich billiger als gleichwertige ATI

- durchschnittliche dx9 Games auf einer 5900u+ kaum schneller als mit einer 9600 pro/xt
- durchschnittlicher User muss glauben was nV verspricht, sie luegen zwar nicht aber sie sagen eben auch nicht immer alles
- Einbauprobleme koennen auftreten
- viele Karten sind relativ laut
- bisher ist das Podenzial der Chips nur den ueberdurchschnittlichen Entwicklern zugaenglich

r3x0
+ real greifbare dx9 Performance und Kompatiblitaet
+ fast immer leiser als nV Karten
+ fast immer schneller als gleichwertiger nV35+ bei Aufloesungen < 16x12 mit voller Qualitaetseinstellung
+ gute Fortschritte beim Treibersupport
+ Entwicklerfreundliche HW

- mitunter billig verarbeitete Karten am Markt
- die's@dx10
- im HiEnd Sektor relativ teuer


So, ich habs so untechnisch wie moeglich geschrieben. Vor allen Dingen ist keine Mutmassung enthalten sondern es sind nur fundamentierte Aussagen.
Wenn jemand Fragen dazu hat, soll er diese moeglichst genau spezifizieren. Auf technische Fragen die keinen Hintergrund aufweisen werd ich nicht viel sagen koennen, denn ohne noetige Vorkenntnis der Fragers, wird eine kurze Antwort meinerseits nicht annaehernd ein Verstandnis vermitteln koennen.
und bitte nicht alle auf einmal.
Ich selbst habe mich kuerzlich fuer eine FX5900 Ultra mit 256MB entschieden. 2 Gruende gaben fuer micht den Ausschlag.

1.Die Karte war satte 100Euro billiger als eine R9800 pro mit 256MB u. ueber 200 Euro billiger als eine 9800XT.
2.Ich brauchte eine Karte, die jenseits von 75mhz AGP Takt keine Probleme macht.

Ich bin quasi in den Streit zw. den beiden reingeschlittert weil ich ne neue Kraka haben wollte. Es hat mich gute 2 Wochen gekostet die Fakten zu erodiern. Das Internet war voll von Informationen wobei nur ein winziger Gehalt an Fakten vorzufinden war. Es war das erste mal, dass ich dermassen mit Spam eingedeckt wurde, wenn ich mich ueber ein Produkt informieren wollte.
Das hat mich echt genervt. Ich hoffe dass meine Erkenntnisse dazu beitragen, einen potenziellen Kaeufer, sich den Spam zu ersparen und einen realen Einblick zu vermitteln.

Ich waere Euch auch sehr verbunden, wenn keine sinnlosen Flames entstehen.

P.S. wer Rechtschreibfehler findet, kann sie behalten.

[Exxtreme]

Ähhm, ich glaube, du verwechselst einige Begriffe. Beim Vertex Shader gibt es AFAIK keine Partial Precision, sondern beim Pixel Shader. :)

Edit: Ansonsten sehe ich viel mehr "Behauptungen" als "Fakten". :(

[StefanV]

Original geschrieben von AchtBit
R3x0
+ real greifbare dx9 Performance und Kompatiblitaet
+ fast immer leiser als nV Karten
+ fast immer schneller als gleichwertiger nV35+ bei Aufloesungen < 16x12 mit voller Qualitaetseinstellung
+ gute Fortschritte beim Treibersupport
+ Entwicklerfreundliche HW

- mitunter billig verarbeitete Karten am Markt
- die's@dx10
- im HiEnd Sektor relativ teuer


zum markierten:

:rofl::lol:

Sorry, aber das einzige, was auf 'ner Radeon Karte (außer ASUS und Hercules) billig verarbeitet sein kann, ist der Lüfter aufm Kühler, alle anderen sind mehr oder minder baugleich...

Aber dú hast einen wichtigen Punkt vergessen:

Die ATI Karten vertragen 'nur' max. 80MHz AGP Takt, die nVs packen auch mal 90MHz, was ein nicht zu unterschätzender vorteil ist :naughty:


Pro und Contras.

Original geschrieben von AchtBit
nv35+
+ sehr flexible Programmierbarkeit ueber aktuelle Spezifikationen hinaus
+ bei sehr hohen Aufloesungen (16x12+) mit voller Qualitaetseinstellung fast immer schneller als der r3x0
+ Staerken der Architektur werden bei den kommenden Topgames ausgespielt werden
+ exzellent verarbeitet u. stabile Karten, detailierter health monitor im HiEndbereich
+ sehr gute kompatiblitaet der Treiber
+ im HiEndbereich billiger als gleichwertige ATI

- durchschnittliche dx9 Games auf einer 5900u+ kaum schneller als mit einer 9600 pro/xt
- durchschnittlicher User muss glauben was nV verspricht, sie luegen zwar nicht aber sie sagen eben auch nicht immer alles
- Einbauprobleme koennen auftreten
- viele Karten sind relativ laut
- bisher ist das Podenzial der Chips nur den ueberdurchschnittlichen Entwicklern zugaenglich



Naja, also wenn ich an den Geräusch und Flimmerbug denke, dann denke ich, daß die ATI Karten 'besser verarbeitet' sind...

Aber diesen Teil wollen wir mal auseinandernehmen:

1. die FXen können NICHT mehr als in DX9 spezifiziert ist, von 'DX9+' zu reden ist auch glatt gelogen, da die jene Karten nichtmal PS und VS nach der 3.0 Spezifikation unterstützen.
Und wirklich flexibler sind die auch nicht, da z.B. einige Floatpoint Texturformate und MRTs den NV3x Karten fehlt...

2. bei der Bandbreite, die die NV35 hat, ists auch kein Wunder, wobei es schon fast peinlich ist, was nV aus der brutalen Bandbreite der NV35 rausholt...

3. welche Stärken?!
Mir fallen da nicht wirklich viele Stärken ein, daß sie in künftigen Anwendungen verwendung finden, ist auch nur Kaffesatzleserei, denn die Erfahrung der Vergangenheit hat gezeigt, daß man sich auf dem kleinsten Level trifft, ergo das, was FX und R300 können und dementsprechend sehen auch die Spiele aus...

4. naja, über die Verbreitung können wir auch nur Kaffesatzleserei betreiben...
Daß die NV35+ weiter verbreitet ist als die R3x0 Karten, dürfte nicht wirklich stimmen...
Naja, über die Stabilität reden wir lieber nicht, da es anscheinend selbst mit den aktuellen 52er Treibern noch diverse Probleme mit einigen Spielen gibt...
Battlefield 1942 ist da ein SPiel, was 'ab und an' Probleme hat, bei MP2 sollen einige Texturen gequirlt sein...

5. siehe 4...
Daß die Treiber kompatibler als die der R3x0 sind, ist ein Märchen aus vergangenen Tagen...
Aktuell schauts ev. anders aus...

6. nicht wirklich...
Aber was nützts, wenn man billiger ist, dafür aber teilweise weniger nützlicher Features, wie z.B. lack of 4x SSMSAA Mode...
Die SS+MS Hybrid Modes können das mitnichten ausgleichen, da der Performanceverlust enorm ist.

[AchtBit]

@Exxtreme, Du darfst nicht von dx9 Shader Programmierung auf die HW schliessen. Wie gesagt, mit der HW ist alles moeglich. Der Compiler reduziert die Genauigkeit des Shaders ohne dass dx9 das mitbekommt.

[AchtBit]

Sorry, aber das einzige, was auf 'ner Radeon Karte (außer ASUS und Hercules) billig verarbeitet sein kann, ist der Lüfter aufm Kühler, alle anderen sind mehr oder minder baugleich...

Club3d oder Powercolor verwenden Billigbauteile. Das betrifft Luefter, analoge Filter und Speicher.

Aber dú hast einen wichtigen Punkt vergessen:
Die ATI Karten vertragen 'nur' max. 80MHz AGP Takt, die nVs packen auch mal 90MHz, was ein nicht zu unterschätzender vorteil ist

Was fuer ein Vor - beziehungsweise Nachteil soll das sein?

Aber diesen Teil wollen wir mal auseinandernehmen:
1. die FXen können NICHT mehr als in DX9 spezifiziert ist, von 'DX9+' zu reden ist auch glatt gelogen, da die jene Karten nichtmal PS und VS nach der 3.0 Spezifikation unterstützen.
Und wirklich flexibler sind die auch nicht, da z.B. einige Floatpoint Texturformate und MRTs den NV3x Karten fehlt...
2. bei der Bandbreite, die die NV35 hat, ists auch kein Wunder, wobei es schon fast peinlich ist, was nV aus der brutalen Bandbreite der NV35 rausholt...
3. welche Stärken?!
Mir fallen da nicht wirklich viele Stärken ein, daß sie in künftigen Anwendungen verwendung finden, ist auch nur Kaffesatzleserei, denn die Erfahrung der Vergangenheit hat gezeigt, daß man sich auf dem kleinsten Level trifft, ergo das, was FX und R300 können und dementsprechend sehen auch die Spiele aus...
4. naja, über die Verbreitung können wir auch nur Kaffesatzleserei betreiben...
Daß die NV35+ weiter verbreitet ist als die R3x0 Karten, dürfte nicht wirklich stimmen...
Naja, über die Stabilität reden wir lieber nicht, da es anscheinend selbst mit den aktuellen 52er Treibern noch diverse Probleme mit einigen Spielen gibt...
Battlefield 1942 ist da ein SPiel, was 'ab und an' Probleme hat, bei MP2 sollen einige Texturen gequirlt sein...
5. siehe 4...
Daß die Treiber kompatibler als die der R3x0 sind, ist ein Märchen aus vergangenen Tagen...
Aktuell schauts ev. anders aus...
6. nicht wirklich...
Aber was nützts, wenn man billiger ist, dafür aber teilweise weniger nützlicher Features, wie z.B. lack of 4x SSMSAA Mode...
Die SS+MS Hybrid Modes können das mitnichten ausgleichen, da der Performanceverlust enorm ist.

Leider sind Deine Aussagen schon im Grundsatz falsch.
Ich kann Dir nichts erklaeren ohne das Du das benoetigte Hintergrundwissen dazu hast.

[Exxtreme]

Original geschrieben von AchtBit
@Exxtreme, Du darfst nicht von dx9 Shader Programmierung auf die HW schliessen. Wie gesagt, mit der HW ist alles moeglich. Der Compiler reduziert die Genauigkeit des Shaders ohne dass dx9 das mitbekommt.
Wenn der Treiber eigenhändig die Genauigkeit beim Vertex Shader stutzt (was ich mir wahrlich nicht vorstellen kann), dann ist's aus mit DX9-Konformität. Und dann gibt's wohl auch kein WHQL-Zertifikat mehr für diesen Treiber.

[Demirug]

Vertex Shader laufen immer mit vollen 32 Bit sonst hätte man Z-Fights ohne Ende. Vorallem warum sollte man an einer Stelle optimieren welche in aller Regel gar nicht der Flaschenhals ist?

[zeckensack]

AchtBit,
Leider sind Deine Aussagen schon im Grundsatz falsch.
Ich kann Dir nichts erklaeren ohne das Du das benoetigte Hintergrundwissen dazu hast :bäh:

[StefanV]

Original geschrieben von AchtBit
Club3d oder Powercolor verwenden Billigbauteile. Das betrifft Luefter, analoge Filter und Speicher.


Sorry, aber das ist blödsinn, vorallendingen da wir hier nur von den 'großen' Radeons sprechen!!
So ziemlich ALLE Radeon 9500/9700 und 9800 (PRO) Karten sind sog. BBA Karten also 'originale' ATI Karten.
Auch labeln alle Hersteller außer Tyan (welche ein komplett eigenes Design haben) und Hercules (welche 'nur' eine andere PCB Farbe haben) nur!!

Falls es dich interessiert, so hatten beide R300 Karten, welche in meinem Besitz gewesen sind bzw es sind eine SN, welche mit 109 begann und am oberen Linken Platinenrand der Vorderseite steht, was das bedeuten mag, werd ich hier nicht erläutern...

Original geschrieben von AchtBit
Was fuer ein Vor - beziehungsweise Nachteil soll das sein?


Jenen, den ich erwähnte...
Wann man einen erhöhten AGP Takt fährt, das musst du schon selbst rausfinden...

Und ja, es gibt durchaus einige Situationen, in denen man z.B. einen 89MHz AGP Takt fährt...

Original geschrieben von AchtBit
Leider sind Deine Aussagen schon im Grundsatz falsch.
Ich kann Dir nichts erklaeren ohne das Du das benoetigte Hintergrundwissen dazu hast.

Sorry, aber DU stellst hier Behauptungen in den Raum und wenn jemand sie mehr oder minder entkräftet bzw anderer Meinung ist, sprichst du ihm das wissen ab?!

Sorry, aber dazu fällt mir nicht wirklich was ein...

Aber wie heißts so schön:

Derjenige, der viel Wissen besitzt, wendet es nur an, wenn er es braucht und erscheint nach außen hin völlig normal.

Derjenige, der glaubt viel Wissen zu besitzen, handelt entgegen dem, der viel Wissen besitzt und weiß, daß er viel Wissen besitzt...

[AchtBit]

Wenn der Treiber eigenhändig die Genauigkeit beim Vertex Shader stutzt (was ich mir wahrlich nicht vorstellen kann), dann ist's aus mit DX9-Konformität. Und dann gibt's wohl auch kein WHQL-Zertifikat mehr für diesen Treiber.

Ja, es ist fast genauso wie Du sagtst. Der Compiler veraendert tatsaechlich Prezisionen, die nicht WHQL konform sind. Die WHQL Spezifikation ist auch der Hauptgrund der Streitigkeiten zwischen nV und M$.

Es waere auch noch moeglich den Vertexshader auf 8bit zu reduzieren ohne grossen sichtbaren Effekt an der Darstellung. Mit 16Bit musst Du 2 Standbilder schon mit Adleraugen vergleichen wenn Du den Unterschied erkennen willst.

Zu WHQL, wenn Dir die Bedeutung des Zertifikates bewusst ist, dann weist Du dass diese Spec. Verletzung nichts mit der Samplequalitaet zu tun hat. Sondern der Sicherheitsmechanismus der guten Daten und schlechten Unterscheiden muss denkt faelschlicherweise das eine Instruktion an die HW geht, die diese nicht ausfuehren kann. So, das ist das Problem mit M$, die muessen jetzt die Sicherheits Spezifikation auf virtuelle Intruktionen erweitern.

Ansonsten sehe ich viel mehr "Behauptungen" als "Fakten".

Ich sag ja, wenn Du spezifische Fragen hast kann ich sie Dir belegen.

[Aqualon]

Original geschrieben von AchtBit
- die's@dx10
Wenn ich die nette Grammatik hier mal richtig entziffere, denkst du, dass ein R3x0 nicht DX10 kompatibel sein wird. Damit magst du vielleicht Recht haben, aber die Aussage kann man genauso den NV3x-Karten zuschreiben. Und auch da wäre sie total nichtssagend, da DX10 noch in weiter Ferne liegt.

Original geschrieben von AchtBit
So, ich habs so untechnisch wie moeglich geschrieben. Vor allen Dingen ist keine Mutmassung enthalten sondern es sind nur fundamentierte Aussagen.
Deine Zukunftsbetrachtungen sind aber ziemliche Mutmassungen, denn du weisst auch nicht, wie sich die Chips von ATI und Nvidia weiterentwickeln werden (oder hast du eine Kristallkugel zu Hause?)

Aqua

[StefanV]

@Achtbit

8bit aufm Vertexshader KANN nicht dein ERnst sein, oder??

Sorry, aber das ist absolut bekloppt, wenn man bei Vertexdaten mit 8bit arbeitet, selbst 16bit sind teiweise schon recht eng...

Normalerweise arbeitet man beim VS und beim TnL mit vollen 32bit, allein schon um Z-Fighting zu minimieren, da machts absolut keinen Sinn 16bit einzusetzen, außer du hast Spaß dran, die Kunden zu ärgern...

[Birdman]

Original geschrieben von Stefan Payne
Naja, also wenn ich an den Geräusch und Flimmerbug denke, dann denke ich, daß die ATI Karten 'besser verarbeitet' sind...

Gerade solche Aussagen zeigen mal wieder wie "objektiv" du solche Sachen betrachten kannst und tust.
Wenn ich da mal an den massiven Flimmerbug der R300 Karten denke, oder die BildProbleme bei Sapphire Radeon Karten (Stichwort "grüne Streifen") dann sieht man:

a) wie gut die Verarbeitungsqualität der Radeon Karten im allgemeinen ist.
b) wie doch bloss ein anderer Lüfter (dies ist deine Aussage - da die Karten ansonsten ja komplett baugleich sein sollen) solche Bildfehler verursachen können.

[StefanV]

Original geschrieben von Aqualon
Wenn ich die nette Grammatik hier mal richtig entziffere, denkst du, dass ein R3x0 nicht DX10 kompatibel sein wird. Damit magst du vielleicht Recht haben, aber die Aussage kann man genauso den NV3x-Karten zuschreiben. Und auch da wäre sie total nichtssagend, da DX10 noch in weiter Ferne liegt.

Ja, vorallendingen da M$ ja auch dazu übergeht die Zeit von einem DX zum nächsten zu verlängern, dementsprechend sah/sieht ja auch schon DX9 aus, welches ja schon Pixel- und Vertexshader der Version 3.0 unterstützen.

Ähnliches wird für DX-Next erwartet, was wiederrum mit Longhorn erwartet wird...

Und, nunja, die Radeons werden wie viele anderen Karten auch noch von DX-Next unterstützt werden, nur ändert das nichts am Featureumfang, welcher unverändert bleibt...

[Exxtreme]

Original geschrieben von AchtBit
Ja, es ist fast genauso wie Du sagtst. Der Compiler veraendert tatsaechlich Prezisionen, die nicht WHQL konform sind. Die WHQL Spezifikation ist auch der Hauptgrund der Streitigkeiten zwischen nV und M$.

AFAIK waren überhöhte Chippreise der Hauptgrund für den Zwist zw. NV und M$. WHQL ist auch keine Spezifikation an sich sondern ein Testparcour für Treiber.
Original geschrieben von AchtBit
Es waere auch noch moeglich den Vertexshader auf 8bit zu reduzieren ohne grossen sichtbaren Effekt an der Darstellung. Mit 16Bit musst Du 2 Standbilder schon mit Adleraugen vergleichen wenn Du den Unterschied erkennen willst.

Sorry, aber da fällt mir nix mehr ein. Ich glaube nicht, daß du mit einem 8 Bit VS noch was erkennen könntest. Du hättest massivstes Z-Fighting.
Original geschrieben von AchtBit
Zu WHQL, wenn Dir die Bedeutung des Zertifikates bewusst ist, dann weist Du dass diese Spec. Verletzung nichts mit der Samplequalitaet zu tun hat. Sondern der Sicherheitsmechanismus der guten Daten und schlechten Unterscheiden muss denkt faelschlicherweise das eine Instruktion an die HW geht, die diese nicht ausfuehren kann. So, das ist das Problem mit M$, die muessen jetzt die Sicherheits Spezifikation auf virtuelle Intruktionen erweitern.

:???:
Original geschrieben von AchtBit
Ich sag ja, wenn Du spezifische Fragen hast kann ich sie Dir belegen.
Neee, lass mal. ;)

[reunion]

Original geschrieben von AchtBit
Vorgeschichte zum nv30+ vs r3x0.

Der Wirbel um den FX sorgte fuer wilde Spekulationen, Kritik und Abneigung gegenueber nV.
Beide Chips haben je ihren Schwachpunkt und angefangen hat all dies, als nV in der Oeffentlichkeit ATI vorwarf ihre Archtiktur sei vorsinnflutlich.
Das waren harte Worte, die aber den Schwachpunkt des Chips widerspiegeln. nV haette es aber lieber sein lassen sollen mit Steinen zu werfen waehrend sie selbst im Glashaus sitzen.
Denn anders als der FX, spiegelt der aktuelle Radeon exakte DX9 compliance wider. Was zumindest zeigt dass ATI ihre HW im Griff hat.

Als ATI auf dem 3D Zug aufsprang blieb nicht die Zeit fuer ein ergonmisches Design, um am aktuellen Markt anzuschliessen, waehlten sie daher die bewaehrte und einfach Datenfluss Architektur.
Durch den Technologiefortschritt war es ohne Probleme moeglich eben mit dieser Architektur bei der aktuellen Topperformance ohne aufwaendige Mittel mitzuhalten.
Durch die immer schneller werdende Enwicklung der Arthimetik fuer Grafikprozessoren ist aber das Ende dieser Architektur unausweichlich.
Noch ist sie, aktuell und in naher Zukunft, die beste Voraussetzung fuer eine HiEnd Performance. Mann koennte auch sagen, sie befindet sich gerade in ihrer Bluetezeit

Wie auch immer ATI wollte sich das nicht bieten lassen und konterte mit gleicher Haerte bei HL2 Presentation.
G. Nu(e)ll war das Sprachrohr. Sein Vorwurf der FX sei nur ein auffriesierter DX8 Chip, sowie die HL Performancepresentation, trafen widerum die Schwachstelle der nV Architektur.
Die Folge war eine weitreichende Misskreditierung des Chips sowie Zweifel an der Glaubwuerdigkeit von nV.

nV hatte bei der Chipentwicklung wesentlich mehr Zeit und ging schon seit geraumer Zeit den ergonomischen Weg und liess sich alle Moeglichkeiten, wie zb. den Einsatz einer Risc Core und die Transformation zur superskalaren Architektur, offen.
Nachteilig ist hier aber die Tatsache, dass ein Teil kontinuierlich immer in der Software weiterentwickelt werden muss. Dieser wesentliche Bestandteil einer superskalaren HW ist dafuer verantwortlich dass die Architektur virtuell erweiterbar ist.
Die Anpassung auf die API wird nicht 1:1 umgesetzt sondern erst per Software auf virtueller Ebene umgesetzt. Sowas zu entwickeln benoetigt faehige Mathematiker und viel Zeit.
Erst 35 Jahre nach der Erfindung(1965) konnten die superskalare Architektur den Prozessormarkt(1995) komplett dominiern. Wer den Pentium von innen kennt, weis welch ausgekluegelte Softwareimplementationen die Mechanismen zur Virtualisierung und Optimierung des Codes im P4 darstellen.
nV war scheinbar der Meinung mit dem FX ist der Zeitpunkt gekommen einen weiteren Schritt in diese Richtung zu gehen. Ein Grund wird wohl sein, dass die Entwicklung die HW schon laenger eingeholt hat und die Entwickler warten muessen bis die spezifizierte HW verfuegbar ist.
Durch die Einfuerung eine Hochsprache fuer Shader wird die Entwicklung abermals beschleunigt, so dass man bereits HW ausnuetzen koennte die erst viel spaeter machbar waere.
Fakto, der aktuell Chip koennte alles moegliche sein, das haengt davon ab wie man ihn steuert und wie faehig die Entwickler sind virtuelle Kontrollmechanismen zu implementieren
Verglichen an seiner physikalische Struktur, hatte G.N. mit den harten Worten, es sei nur ein dx8 chip, recht. Dennoch kann er in virtueller Hinsicht auch alles andere als das sein.
Auf dieser Ebene spielt die Struktur, phyisikalisch, nur eine untergeordnete Rolle.

Cheaten tun beide.

Wo auch immer die Grenze zwischen Cheat und Optimierung liegt war in der Vergangenheit schon immer ein Streitpunkt.
Wohl gerade desshalb hat nV 3 neue Grundsaetze fuer diese Problematik geschaffen. In einer Besprechung zw. ATI und nV sind sich beide ueber diese
Grundregeln einig geworden. Sprich es wurde das Kriegsbeil begraben und falls irgend eine Form von Optimierung eingesetzt wird, dann nur nachdem
eine Partei der anderen die Methode erlaeutert hat. Ab dem naechsten Catalyst wird ATI ihre 3Mark Cheats entfernt haben.
Differenzen, insbesondere mit FM, gibt es aber bezueglich der letzten Optimierung von nV. Der treiberinterne Shader Optimizer von nV wird zukuenftig
die Vertex Shader auf partiale Genauigkeit optimieren, so geschehen im 52.16 Deto. Eine Beinflussung der IQ ist nur unwesentlich bis gar nicht erkennbar.
Ist es ein Cheat? Jain. Eine klare Aussage gibt es im Moment nicht.
Aussagen der Optimizer von nV wurde deaktiviert sind grober Unfug.
Der Optimizer ist HW transparent und niemand kann was ausschalten, das offensichtlich nicht vorhanden ist.
Warum hat der Optimizer aber den Shader nach dem Patch aber nicht mehr optimieren koennen? Das laesst den Verdacht zu, dass hier einfach der CodePfad ausgetauscht wurde.
Hinsichtlich der Aussage von nV sowie der FX Architektur, ist das Vorhaben, den Vertex Shader immer teilgenau zu optimieren, ein logischer Ansatz.
Solange der Optimizer den Shadercode aber nicht genau bestimmen kann, was aktuell der Fall ist, bleibt es ein Cheat.
Ist der Optimizer faehig den Code zu erkennen, dann ist es eine Optimierung. Die Optimierung, wie schon erwaehnt, ist fuer den FX zeitaufwendig. Der Compiler ist noch lange nicht da wo er hinsoll.
Ist sowas machbar? ja, man wird in Zukunft ziemlich genau unterscheiden koennen welcher Code vertexshaderspezifisch ist und welcher nicht.
Fuer die Zukunft spiegelt der 3Dmark aktuell nicht die tatsaechliche Spieleleistung des FX unter Vertex Shader wider.
Wenn der Optimizer zuverlaessig laeuft, bleibt FM gar nichts anderes uebrig als einzuraeumen, dass es tatsaechlich eine Optimierung ist.

Performance und Zukunft beider Chips.

Aktuell ist die ATI HW leichte zu handlen. Das heisste der durchschnittliche Entwickler wird nicht optimierten fragmentierten dx9 Code schreiben.
Der ATI Chip gibt also derzeitig klar die Performance wider die er auch in spaeteren dx9 Spielen haben wird. Abhaengig ist seine Lebensdauer davon wann DX10 eingefuehrt wird.
Bei nv variert die Performance und zwar abhaengig von automatisierten Compiler und Optimizer, von der Anstrengung der Entwickler und ob nV,individuelle Optimierung einsetzt.
Er kann im Prinzip deutlich langsamer, aehnlich schnell oder deutlich schneller sein. Zu erwaehnen waere, dass bei exklusiven Games nV Handoptimierung, zusaetzlich zum Optimizer, anlegen wird.
Gurus wie J.C. werden eigene Optimierungen einsetzten, die massive Performanceschuebe erwarten lassen. Er selbst mutet sich zu locker ueber 100 Instruktionen auf einmal koordinieren zu koennen.
Waehrend der Durchschnitt bei weniger als 30 Instruktionen schon Probleme beim Uberblicken aufweist. Man kann im Endeffekt beim FX sagen, die Faehigkeit des Entwicklers laesst sich an der Performance des Games messen und zwar wesentlich klarer wie das frueher der Fall war.
Die Lebensdauer ist nicht abzusehen weil das Potenzial nicht erkennbar ist und virtuell auch dx9+ machbar waere. Eine Schaetzung war 2005 wobei die davon ausging, dass bis dahin die Performance der HW, der des nv35+ klar ueberlegen ist.
nV hat einen neuen intensiven Entwicklersupport eroeffnet wo auch auf Fragen betreffend des Compilers/Optimizers eingegangen wird.

aktueller Stand bei nV und ATI

Beide arbeiten wieder eng zusammen. Sie kennen die Schwaechen und Staerken ihrer Produkte genau.
ATI ist sich voellig klar, dass Sie langsam ihr Chiplayout, aufgrund der akuten HW Limitierung, an die moderne Architektur anpassen muessen.
Damit nicht wieder solche extemen Unterschiede in der Architekur vorkommen teilt nV jetzt seine Erkenntnisse mit ATI.
Beide streben zukuenftige identische Architekturen an. nV ist gespraechig geworden und will auch zukuenftig keine Fakten mehr verschleiern.
Der neue Support ist bereits eroeffnet. nV haette sich auch schon frueher im klaren sein muessen, dass man so ein Projekt nicht alleine stemmen kann.
War doch klar zu sehen welche Zusammenarbeit, das Intel gekostet hat, um vollstaendige Unterstuetzung fuer ihre Pentium CPUs zu gewaehren.
Es wuerde jedem helfen, wenn nV u. ATI detailierte Datenblatter ihrer Grafikprozessoren veroeffendlichen wuerden.

Pro und Contras.

nv35+
+ sehr flexible Programmierbarkeit ueber aktuelle Spezifikationen hinaus
+ bei sehr hohen Aufloesungen (16x12+) mit voller Qualitaetseinstellung fast immer schneller als der r3x0
+ Staerken der Architektur werden bei den kommenden Topgames ausgespielt werden
+ exzellent verarbeitet u. stabile Karten, detailierter health monitor im HiEndbereich
+ sehr gute kompatiblitaet der Treiber
+ im HiEndbereich billiger als gleichwertige ATI

- durchschnittliche dx9 Games auf einer 5900u+ kaum schneller als mit einer 9600 pro/xt
- durchschnittlicher User muss glauben was nV verspricht, sie luegen zwar nicht aber sie sagen eben auch nicht immer alles
- Einbauprobleme koennen auftreten
- viele Karten sind relativ laut
- bisher ist das Podenzial der Chips nur den ueberdurchschnittlichen Entwicklern zugaenglich

r3x0
+ real greifbare dx9 Performance und Kompatiblitaet
+ fast immer leiser als nV Karten
+ fast immer schneller als gleichwertiger nV35+ bei Aufloesungen < 16x12 mit voller Qualitaetseinstellung
+ gute Fortschritte beim Treibersupport
+ Entwicklerfreundliche HW

- mitunter billig verarbeitete Karten am Markt
- die's@dx10
- im HiEnd Sektor relativ teuer


So, ich habs so untechnisch wie moeglich geschrieben. Vor allen Dingen ist keine Mutmassung enthalten sondern es sind nur fundamentierte Aussagen.
Wenn jemand Fragen dazu hat, soll er diese moeglichst genau spezifizieren. Auf technische Fragen die keinen Hintergrund aufweisen werd ich nicht viel sagen koennen, denn ohne noetige Vorkenntnis der Fragers, wird eine kurze Antwort meinerseits nicht annaehernd ein Verstandnis vermitteln koennen.
und bitte nicht alle auf einmal.
Ich selbst habe mich kuerzlich fuer eine FX5900 Ultra mit 256MB entschieden. 2 Gruende gaben fuer micht den Ausschlag.

1.Die Karte war satte 100Euro billiger als eine R9800 pro mit 256MB u. ueber 200 Euro billiger als eine 9800XT.
2.Ich brauchte eine Karte, die jenseits von 75mhz AGP Takt keine Probleme macht.

Ich bin quasi in den Streit zw. den beiden reingeschlittert weil ich ne neue Kraka haben wollte. Es hat mich gute 2 Wochen gekostet die Fakten zu erodiern. Das Internet war voll von Informationen wobei nur ein winziger Gehalt an Fakten vorzufinden war. Es war das erste mal, dass ich dermassen mit Spam eingedeckt wurde, wenn ich mich ueber ein Produkt informieren wollte.
Das hat mich echt genervt. Ich hoffe dass meine Erkenntnisse dazu beitragen, einen potenziellen Kaeufer, sich den Spam zu ersparen und einen realen Einblick zu vermitteln.

Ich waere Euch auch sehr verbunden, wenn keine sinnlosen Flames entstehen.

P.S. wer Rechtschreibfehler findet, kann sie behalten.

Also ein Mix aus Spekulationen, blödsinn, wunschdenken und unwissenheit :bonk:

[StefanV]

Original geschrieben von Birdman
Gerade solche Aussagen zeigen mal wieder wie "objektiv" du solche Sachen betrachten kannst und tust.
Wenn ich da mal an den massiven Flimmerbug der R300 Karten denke, oder die BildProbleme bei Sapphire Radeon Karten (Stichwort "grüne Streifen") dann sieht man:

a) wie gut die Verarbeitungsqualität der Radeon Karten im allgemeinen ist.
b) wie doch bloss ein anderer Lüfter (dies ist deine Aussage - da die Karten ansonsten ja komplett baugleich sein sollen) solche Bildfehler verursachen können.

1. war nur als 'Argument' gegen die vermeintlich schlechtere Verarbeitungsqualität gedacht, was ja, wie gesagt nicht stimmt, da sowohl die großen FXe als auch die großen Radeons mehr oder minder gleich verarbeitet sind...

zu b)
SOrry, hab vergessen, daß Sapphire auch ein eigenes PCB hat, welches sogar einen Rage Threatre vorgesehen hat...

[AchtBit]

@Stefan Payne,

ich kann Dir nicht absprechen was Du einfach nicht hast.

Beispiel gleich die 1. Aussage

>>1. die FXen können NICHT mehr als in DX9 spezifiziert ist<<

Ein Beweis, dass Du einfach nicht kapieren willst, dass die FX HW alleine, physikalisch keine Aussage, ueber moegliche Kapazitaeten auf vitueller Ebene machen.

Es bringt absolut nix Dir was erklaeren zu wollen, desse Gundprinzip Du nicht verinnerlicht hast.

[nggalai]

Hi AchtBit,

nettes Posting, wenn auch etwas lang--aber hast Du auch Quellen? So muss ich den Thread schon fast ins Speku-Forum verschieben. Beispiele:

"G. Nu(e)ll war das Sprachrohr. Sein Vorwurf der FX sei nur ein auffriesierter DX8 Chip, sowie die HL Performancepresentation, trafen widerum die Schwachstelle der nV Architektur." Wo hat er das gesagt? Quelle?

"als nV in der Oeffentlichkeit ATI vorwarf ihre Archtiktur sei vorsinnflutlich." Quelle?

"Damit nicht wieder solche extemen Unterschiede in der Architekur vorkommen teilt nV jetzt seine Erkenntnisse mit ATI." Quelle?


93,
-Sascha.rb

[AchtBit]

Deine Zukunftsbetrachtungen sind aber ziemliche Mutmassungen, denn du weisst auch nicht, wie sich die Chips von ATI und Nvidia weiterentwickeln werden (oder hast du eine Kristallkugel zu Hause?)

Ja, die Anmerkung betreffen der Fakten war natuerlich nicht fuer meine Zukunftsprognose gedacht. Waer ja schon wenn ich schon immer die Zukunft kennen taet ;)

un..Ja, die Lebensdauer des Chips bis dx10 ist als Nachteil vielleicht etwas uebertrieben. Ich habs auch nur vermerkt hinsichtlich des FX, an dem DX nicht als Masstab fuer seine Lebensdauer, hergenommen werden kann.

[StefanV]

@Achtbit

Zeig mir die Dokumente, in denen steht, daß die FX mehr kann als in DX9 spezifiziert ist!!

Fakt ist, daß keine derzeit am Markt erhältliche Karte auch nur annähernd das bieten kann, was in DX9 spezifiziert ist...

[zeckensack]

Original geschrieben von AchtBit
<furchtbar lange Einleitung>
Auf dieser Ebene spielt die Struktur, phyisikalisch, nur eine untergeordnete Rolle.Weitgehend gefährliches Halbwissen. Zum letzten Satz:
Es spielt also keine Rolle, wieviele Funktionseinheiten da sind, wie diese verschaltbar sind, wieviele Register, wieviele Readports, etc? *gnarf*

Deine Ausführungen bzgl "ergonomisches Design" vs "Datenfluss Architektur" (deine Termini) möchte ich nur insofern kommentieren, als daß du dich dringend mal mit den Gründen, und den spezifisch Vor- und Nachteilen auseinandersetzen mußt. Dabei ist auch dringend zu unterscheiden zwischen offenen, direkt programmierten ISAs und über APIs abstrahierten Spezial-Prozessoren.

<jede Menge Text>]
die Vertex Shader auf partiale Genauigkeit optimieren, so geschehen im 52.16 Deto. Eine Beinflussung der IQ ist nur unwesentlich bis gar nicht erkennbar.Partielle Genauigkeit=FP16, non?
Dir ist hoffentlich bewußt, daß das nichtmal ausreicht, um den richtigen Pixel zu treffen. Insbesondere ist ab 1024x768 im rechten unteren Bildviertel keinerlei AA mehr möglich ...

Für reine Farbberechnungen: machbar. Ansonsten purster Käse.

Aussagen der Optimizer von nV wurde deaktiviert sind grober Unfug.
<wieder gekürzt>Stimmt.
Ist sowas machbar? ja, man wird in Zukunft ziemlich genau unterscheiden koennen welcher Code vertexshaderspezifisch ist und welcher nicht.Unfug. Shader-Code wird bereits auf Applikationsebene zwischen VS und PS strikt getrennt. Hier muß man nicht unterscheiden können.
Eine mögliche Verschiebung gewisser konstanter Operationen vom PS in den VS sind natürlich denkbar. Wenn du das meintest, dann schreib's bitte auch so.
<gekürzt>
Der ATI Chip gibt also derzeitig klar die Performance wider die er auch in spaeteren dx9 Spielen haben wird. Abhaengig ist seine Lebensdauer davon wann DX10 eingefuehrt wird.Nö.
Seine Lebensdauer ist dann beendet, wenn es eine signifikante Menge an Software gibt, die seine Möglichkeiten (PS2.0, VS2.0) übersteigen.
DX10 ist nicht spezifiziert, die NV3x-Reihe wird btw auch nicht damit kompliant sein können. Das wäre geradezu ein Wunder, denn DX9 enthält bereits die Vorgaben für VS3.0 und PS3.0, die von NV3x (wie auch R300) ebenfalls nicht unterstützt werden.
Bei nv variert die Performance und zwar abhaengig von automatisierten Compiler und OptimizerWie auch bei ATI.
, von der Anstrengung der Entwickler und ob nV,individuelle Optimierung einsetzt.
Er kann im Prinzip deutlich langsamer, aehnlich schnell oder deutlich schneller sein. Zu erwaehnen waere, dass bei exklusiven Games nV Handoptimierung, zusaetzlich zum Optimizer, anlegen wird.Handoptimierungen seitens der IHVs sind schlecht, eben weil eine Auswahl der zu optimierenden Shader getroffen werden muß, und der Arbeitsaufwand erheblich ist. Automatisch optimierende Treiber sind die einzige Lösung mit Zukunft.
Gurus wie J.C. werden eigene Optimierungen einsetzten, die massive Performanceschuebe erwarten lassen. Er selbst mutet sich zu locker ueber 100 Instruktionen auf einmal koordinieren zu koennen.... was aber in der Doom 3-Engine nicht zum Tragen kommt.
Hier geht's um relativ kurze Shader (<=16 Instruktionen), dafür schlagen Z-Fill-Optimierungen voll durch.
Waehrend der Durchschnitt bei weniger als 30 Instruktionen schon Probleme beim Uberblicken aufweist. Man kann im Endeffekt beim FX sagen, die Faehigkeit des Entwicklers laesst sich an der Performance des Games messen und zwar wesentlich klarer wie das frueher der Fall war.Contra. Die Fähigkeit der Treiberentwickler lässt sich an der Shader-Performance messen. Die Fähigkeit der Entwickler ist nur beim Erzeugen des übergebenen Shader-Codes meßbar, wenn man überhaupt ein solches Kriterium anlegen will.
Die Lebensdauer ist nicht abzusehen weil das Potenzial nicht erkennbar ist und virtuell auch dx9+ machbar waere. Eine Schaetzung war 2005 wobei die davon ausging, dass bis dahin die Performance der HW, der des nv35+ klar ueberlegen ist.DX9+ existiert nicht (du meintest wahrscheinlich PS2.0+; bitte die Termini erstmal lernen).
2005 wird sich keine Sau mehr für NV35 interessieren. Die Herausgabe vom Begründungen verweigere ich, das sollte offensichtlich sein.
nV hat einen neuen intensiven Entwicklersupport eroeffnet wo auch auf Fragen betreffend des Compilers/Optimizers eingegangen wird.NV hat eine Devrel-Abteilung, die für solche und ähnliche Fragen bereitsteht schon seit vielen vielen Jahren. Ebenso wie ATI.
<stark gekürzt>
nv35+
+ bei sehr hohen Aufloesungen (16x12+) mit voller Qualitaetseinstellung fast immer schneller als der r3x0

r3x0
+ fast immer schneller als gleichwertiger nV35+ bei Aufloesungen < 16x12 mit voller QualitaetseinstellungAuflösung ist hier irrelevant. Die erreichte Füllrate bestimmt sich eben über die Shader-Version (PS, nicht VS; gerne auch fixed function). Flüssig machbare Auflösung ist ein Resultat der erreichbaren Füllrate.

Wenn diese bei 1024x768 geringer ist als bei der Konkurrenz, ändert sich bei höheren Auflösungen auch nichts mehr daran.

So, ich habs so untechnisch wie moeglich geschrieben. Vor allen Dingen ist keine Mutmassung enthalten sondern es sind nur fundamentierte Aussagen.
Wenn jemand Fragen dazu hat, soll er diese moeglichst genau spezifizieren. Auf technische Fragen die keinen Hintergrund aufweisen werd ich nicht viel sagen koennen, denn ohne noetige Vorkenntnis der Fragers, wird eine kurze Antwort meinerseits nicht annaehernd ein Verstandnis vermitteln koennen.Ja, sicher doch :eyes:
Ich bin quasi in den Streit zw. den beiden reingeschlittert weil ich ne neue Kraka haben wollte. Es hat mich gute 2 Wochen gekostet die Fakten zu erodiern. Das Internet war voll von Informationen wobei nur ein winziger Gehalt an Fakten vorzufinden war. Es war das erste mal, dass ich dermassen mit Spam eingedeckt wurde, wenn ich mich ueber ein Produkt informieren wollte.Ja, das Netz ist voll von Fehlinformation und gefährlichem Halbwissen. Wozu auch dein Post nochmal enorm beigetragen hat.

Du hättest diese zwei Wochen sinnvoller nutzen können. Andererseits bin ich erstaunt, daß du dir nach zwei Wochen schon den "Expertenstatus" zutraust, den du ganz offensichtlich nicht besitzt.

[reunion]

Original geschrieben von AchtBit
@Stefan Payne,

ich kann Dir nicht absprechen was Du einfach nicht hast.

Beispiel gleich die 1. Aussage

>>1. die FXen können NICHT mehr als in DX9 spezifiziert ist<<

Ein Beweis, dass Du einfach nicht kapieren willst, dass die FX HW alleine, physikalisch keine Aussage, ueber moegliche Kapazitaeten auf vitueller Ebene machen.

Es bringt absolut nix Dir was erklaeren zu wollen, desse Gundprinzip Du nicht verinnerlicht hast.

Ic setzt sogar noch eins drauf: Die FXen können nichtmal annähernd alles was in DX9 spezifiziert ist ;)

[zeckensack]

Original geschrieben von Stefan Payne
Sorry, aber dazu fällt mir nicht wirklich was ein...

Aber wie heißts so schön:

Derjenige, der viel Wissen besitzt, wendet es nur an, wenn er es braucht und erscheint nach außen hin völlig normal.

Derjenige, der glaubt viel Wissen zu besitzen, handelt entgegen dem, der viel Wissen besitzt und weiß, daß er viel Wissen besitzt... Klassisch:
It's better to shut up and look like an idiot than to talk and remove all doubt.

[zeckensack]

Original geschrieben von reunion
Also ein Mix aus Spekulationen, blödsinn, wunschdenken und unwissenheit :bonk: Jo, das trifft's ganz gut :)

[Keel]

Original geschrieben von AchtBit
Pro und Contras.

nv35+
1. + sehr flexible Programmierbarkeit ueber aktuelle Spezifikationen hinaus
2. + Staerken der Architektur werden bei den kommenden Topgames ausgespielt werden
3. + exzellent verarbeitet u. stabile Karten, detailierter health monitor im HiEndbereich
4. + sehr gute kompatiblitaet der Treiber
5. + im HiEndbereich billiger als gleichwertige ATI

zu 1.: Was aber nützt einem die Flexibilität, wenn's an Speed vorn und hinten fehlt?!
zu 2.: Sehr gewagte Aussage. Wie du selbst festgestellt hast, ist das Potential nicht bekannt. Vielleicht ist es sehr viel größer als wir denken, vielleicht aber auch nicht. Außerdem interessieren mich nicht nur Top-Games, ich will doch nicht von NV vorgeschrieben bekommen, was ich spielen kann.
zu 3.: Das ist ein Argument?
zu 4.: Also zumindest atm finde ich es recht gewagt, bei NV-Treibern von guter Kompatibilität zu sprechen.
zu 5.: Na das halte ich für ein Gerücht. ;)
Original geschrieben von AchtBit
1. - durchschnittlicher User muss glauben was nV verspricht, sie luegen zwar nicht aber sie sagen eben auch nicht immer alles
2. - bisher ist das Podenzial der Chips nur den ueberdurchschnittlichen Entwicklern zugaenglich
zu 1.: NV lügt und betrügt wo es nur geht (ATI sicher auch). Ne, also das ist blanker Schwachsinn. -> Erst war die Rede davon, dass der Bri-Filter bei UT ein Bug sei, wenig später war es ein "Feature" und nun ist es durchweg in D3D. Ich muss und werde NV das nicht so einfach glauben.
zu 2.: Na toll, also kann ich nur die Top-Games spielen, alles was NV bei DX9 als nicht so toll sieht bzw. wo sie keinen so tollen Draht zu den Devs haben, kann ich nicht spielen.
Original geschrieben von AchtBit
1. - mitunter billig verarbeitete Karten am Markt
2. - im HiEnd Sektor relativ teuer
zu 1.: Die Lüfter mögen ja billig und anfällig sein, aber über den Rest hat sich wohl noch keiner beklagt.
zu 2.: Wie oben schon; das halte ich für etwas unwahrscheinlich.

[AchtBit]

Original geschrieben von nggalai
Hi AchtBit,

nettes Posting, wenn auch etwas lang--aber hast Du auch Quellen? So muss ich den Thread schon fast ins Speku-Forum verschieben. Beispiele:

"G. Nu(e)ll war das Sprachrohr. Sein Vorwurf der FX sei nur ein auffriesierter DX8 Chip, sowie die HL Performancepresentation, trafen widerum die Schwachstelle der nV Architektur." Wo hat er das gesagt? Quelle?

"als nV in der Oeffentlichkeit ATI vorwarf ihre Archtiktur sei vorsinnflutlich." Quelle?

"Damit nicht wieder solche extemen Unterschiede in der Architekur vorkommen teilt nV jetzt seine Erkenntnisse mit ATI." Quelle?


93,
-Sascha.rb

Quelle 1. PCGames 11/03
HL2 Spezial from ATI-Shader Day.

Auszug Nuell Ansprache,

Treat MV3X as DX8 hardware
- Customers can always set dx9 themselves would as saved us a lot of time.
- most developers won't have the budget to create their own mixed mode.
must use dx8 with the 5200/5600 to get playable framerates

Ist schon noch mehr. Vom ATI Shaderday findest bestimmt auch zahlreiche Berichte im Netz.

Quelle 2. FiringSquad nV Editors Day Report

http://www.firingsquad.com/features/nvidia_editors_day/page9.asp

Zitat:
The second matter is to discount NVIDIA’s claims of ATI’s technological backwardness and waste of engineering resources on discovering ‘optimizations’ in NVIDIA drivers.

Das ist leider nur n review was in der Vergangenheit geschah. Nvidias eigenen Worte dazu, find ich nicht mehr ist auch schon ne Weile her.

Quelle 3.
beyound3d: ATI Interview
http://www.beyond3d.com/articles/3dmark03/340/index.php?p=7

firingsquad: nv Editors Day Report
http://www.firingsquad.com/features/nvidia_editors_day/default.asp

[Demirug]

Eigentlich sollte ich es lassen in einem solchen Thread möglicherweise für noch mehr Verwirrung zu sorgen aber ich denke das ich das NV3X kann mehr als DX9 Thema mal richtig stellen muss.

Die kurze Antwort auf die Frage ob NV3X mehr kann als DX9 ist Ja. Die lange Antwort ist: Ja, aber jeder Chip kann mehr als die entsprechende DX-Version spezifiziert. Es gibt eben immer ein paar Spezialitäten die nicht in die DX-Spec aufgenommen wurde. Frag mal ATI wie viele Shaderanweisungen ein R300 kann. Und dann sagst du ihnen das du DX benutzt und plötzlich wird die Zahl kleiner. Das ist nun mal der Preis wenn man eine API haben möchte die vereinheitlicht.

[nggalai]

Hi AchtBit,

ich glaub', Du hast mich missverstanden. ;) Das waren Beispiele von Dingen, wo Quellenangaben hingehören. Dein Text ist voll davon. Und eben, deine drei Beispiel-Quellen widersprechen dir bereits:

1) Und wo redet Newell da von "auffrisierter DX8-Hardware"? Es geht um das Zitat. Wenn Du Gabe schon zitieren willst, dann mach's richtig, und schreib nicht deine Interpretation seiner tatsächlichen Aussagen. Gabe hat vorgeschlagen, 5200er und 5600er wie DX8-Hardware zu behandeln und dem User die Möglichkeit offen zu lassen, auf DX9-Features umzuschalten--aber eben, als Default lieber den DX8-Techlevel voreinstellen.

2) Da hast Du ja selbst eingestanden, dass das keine direkte Aussage von NV ist.

3) Im B3D-Artikel finde ich rein gar nix davon, dass NV ihre Erkenntnisse mit ATI teilt. Und im Firingsquad-Artikel das genaue Gegenteil--Da steht, wie NV ATI runterputzt und dann auch noch als weniger grossen Konkurrenten als Intel bezeichnet. NV macht ATI den VORWURF, ihre Treiber auseinanderzunehmen und dann an Veranstaltungen wie dem Shader Day die Presse mit Halbwahrheiten vollzubuttern. Von freiwilliger Zusammenarbeit seh ich da nix.

Nochmals--es geht mir nicht um die drei Beispiele. Höchstwarscheinlich findest Du für die 2) sogar eine Quelle. ;) Aber: Ohne Quellenangaben ist deine Post praktisch wertlos. Und wenn Du schon bei solchen nicht-technischen Sachen nur Interpretationen reinschreibst oder einfach die tatsächlichen Quellen unterschlägst, also so deiner Post einen ziemlich aggressiven Ton gibst, wie sieht's erst mit den technischen Details aus?

93,
-Sascha.rb

[AchtBit]

daß du dir nach zwei Wochen schon den "Expertenstatus" zutraust, den du ganz offensichtlich nicht besitzt.

Hab ich das behauptet?
Ich hab zwar nix mit dx9 Programmierung zu tun, stimmt, aber als Informatiker kann ich zumindest das Prinzip erkennen.

Zu den Terminussen, ich hab bei den letzten Postings schon gemerkt, du drehst gerne an Woerten rum. Wahrscheinlich ist das auch der Grund das du selbst Woerter gerne die Woerter verdrehst, z.B. P5 und P6, die in keinem Zusammenhang zum Text stehen und im richtigen Zusammenhang nicht einheitlich definiert sind. Ich musste quasi raten was Du meinst.

Ich frag mich auch wie Du auf Sachen kommst(VS) die angeblich gar nicht moeglich sind obgleich sie in der Vergangenheit der Standard ware.

[StefanV]

Original geschrieben von AchtBit
Hab ich das behauptet?
Ich hab zwar nix mit dx9 Programmierung zu tun, stimmt, aber als Informatiker kann ich zumindest das Prinzip erkennen.
Hm, analogie:

Weil ich Elektriker bin, muss ich wissen, wie ein Kraftwerk funzt, ebenso wie alle anderen el. Geräte?

Original geschrieben von AchtBit
Zu den Terminussen, ich hab bei den letzten Postings schon gemerkt, du drehst gerne an Woerten rum. Wahrscheinlich ist das auch der Grund das du selbst Woerter gerne die Woerter verdrehst, z.B. P5 und P6, die in keinem Zusammenhang zum Text stehen und im richtigen Zusammenhang nicht einheitlich definiert sind. Ich musste quasi raten was Du meinst.

Eigentlich nicht, zumindest wird auch in diversen c't Ausgaben von der P5 oder P6 sowie P7 Architektur gesprochen...
Ebenso bei Sandpile, was einige von uns gerne mal benutzen, da eigentlich recht zuverlässig, wo ebenfalls von P5 und P6 gesprochen wird...

Original geschrieben von AchtBit
Ich frag mich auch wie Du auf Sachen kommst(VS) die angeblich gar nicht moeglich sind obgleich sie in der Vergangenheit der Standard ware.



zu 'Partial Precision' im Vertexshader (aus einer Unterhaltung mit einem anderen Forumsteilnehmer, dem ich zugestehe WEIT mehr zu wissen als meinereiner):


bei geringerer Präzision könnte es sein, daß ich vor 'ner Wand stehe und das, was eigentlich hinter der Wand sein sollte, sich vor der Wand befindet, was ärgerlich ist ;)

schlimm wirds, wenn diese Situation anfängt zu 'flackern' und sich die Gegenstände mal vor und mal hinter der Wand befinden ;)

[zeckensack]

Original geschrieben von AchtBit
Hab ich das behauptet?
Deine Worte:
"So, ich habs so untechnisch wie moeglich geschrieben. Vor allen Dingen ist keine Mutmassung enthalten sondern es sind nur fundamentierte Aussagen.
Wenn jemand Fragen dazu hat, soll er diese moeglichst genau spezifizieren. Auf technische Fragen die keinen Hintergrund aufweisen werd ich nicht viel sagen koennen, denn ohne noetige Vorkenntnis der Fragers, wird eine kurze Antwort meinerseits nicht annaehernd ein Verstandnis vermitteln koennen."
"Ich hoffe dass meine Erkenntnisse dazu beitragen, einen potenziellen Kaeufer, sich den Spam zu ersparen und einen realen Einblick zu vermitteln."
Ich hab zwar nix mit dx9 Programmierung zu tun, stimmt, aber als Informatiker kann ich zumindest das Prinzip erkennen.Aha.
Zu den Terminussen, ich hab bei den letzten Postings schon gemerkt, du drehst gerne an Woerten rum. Wahrscheinlich ist das auch der Grund das du selbst Woerter gerne die Woerter verdrehst, z.B. P5 und P6, die in keinem Zusammenhang zum Text stehen und im richtigen Zusammenhang nicht einheitlich definiert sind. Ich musste quasi raten was Du meinst.Intel P5 (http://www.google.com/search?q=intel+p5&sourceid=opera&num=0&ie=utf-8&oe=utf-8)
Intel P6 (http://www.google.com/search?hl=en&lr=&ie=UTF-8&oe=utf-8&q=intel+p6&btnG=Google+Search)
ISA (http://www.google.com/search?q=instruction+set+architecture&sourceid=opera&num=0&ie=utf-8&oe=utf-8) (Kontext: Prozessoren)
Ich drehe nichts rum. Ich benutze die Termini so, wie sie eben benutzt werden und Punkt.
Ich erwarte von einem Fachfremden nicht, daß er alle Termini kennt. Was ich allerdings erwarte, ist daß man sich dann "fundamentierte" [sic] Analysen verkneift.
Ich frag mich auch wie Du auf Sachen kommst(VS) die angeblich gar nicht moeglich sind obgleich sie in der Vergangenheit der Standard ware. Wo?
Wo hat jemals ein VS (oder eine HW-T&L-Einheit, oder gar eine Software-T&L-Implementierung) mit 16 bit FP oder gar weniger gearbeitet?
*kopfschüttel*
Warte, ich helf dir. Die einzige Antwort die du finden könntest, ist OpenGL ES (http://www.khronos.org/opengles/). Aber das wußtest du sicher schon selber.

[SamLombardo]

Original geschrieben von reunion
Ic setzt sogar noch eins drauf: Die FXen können nichtmal annähernd alles was in DX9 spezifiziert ist ;)

Das ist wohl wahr. Allerdings können die Radeons noch weniger:)

@AchtBit
Keine Chance hier etwas positives zu NV Karten zu sagen ohne gleich in der Luft zerrissen zu werden:(

[Keel]

So, was haben wir hier nun?

Jemand, der nur schlecht die deutsche Sprache beherrscht. ;)
Jemand, der mit einem nicht vorhandenen Wissen protzt. (8 bit VS? Hilfe? Hab ich was verpasst?)
Jemand, der statt Fakten zu extrahieren, nur seine eigenen Interpretationen und Ansichten widergibt.
Jemand, der die Aussagen gewisser Persönlichkeiten verdreht, aus dem Kontext reißt und dementsprechend falsch deutet.
Jemand, der andere beschuldigt, sie würden nur unsinnige Mutmaßungen anstellen, es dann selber aber noch viel schlimmer macht.
Habe ich etwas Wichtiges vergessen?

An die Mods:
Eigentlich können wir diesen Thread doch getrost schließen, oder? Bestenfalls gehört der gerade so noch ins Speku-Forum.

[nggalai]

verschoben.

93,
-Sascha.rb

[Piffan]

Was sind Terminusse?

Ist schon hammerhart, diesen geballten Mix aus Spekulatius, Viertelwissen und sprachlichen Fehlgriffen zu lesen......

[Thowe]

Original geschrieben von Piffan
Was sind Terminusse?


Nix, ok, naja, Termini. Aber eigentlich heisst es eh terminus technicus für einen Fachbegriff, ich denke das er die meint. *auch mal ultraklugscheiss*

[Ailuros]

OT:

Achtbit kennen wir uns zufaellig? ;)

[KM]

Dieser Thread ist irgendwie :zzz:

@Achtbit
Ich habe eher das Gefühl, als ob du NV und ATI vertritts, vielleicht ABIT,ASUS...? ;)

[LOCHFRASS]

Original geschrieben von AchtBit
2.Ich brauchte eine Karte, die jenseits von 75mhz AGP Takt keine Probleme macht.

Wo es jetzt eh schon ins Geflame und OT abgedriftet ist, wie viel AGP Takt verkraftet die FX eigentlich? Leider hat das PC-DL kein AGP/PCI Fix und bei 165 MHz wären das dann 83 MHz...

[Gast]

Original geschrieben von AchtBit

[Eine Menge Komisches]



Bitte löscht diesen Thread... der ist nun wirklich nicht 3d-Center-würdig.

Gruß

Jörg

[StefanV]

Original geschrieben von LOCHFRASS
Wo es jetzt eh schon ins Geflame und OT abgedriftet ist, wie viel AGP Takt verkraftet die FX eigentlich? Leider hat das PC-DL kein AGP/PCI Fix und bei 165 MHz wären das dann 83 MHz...

Die FX packt bei mir 'mal eben' 89MHz AGP Takt.

Die Radeons (9800PRO, 9600) schafften auf meinem P4P800-DLX 80MHz bei leicht erhöhter AGP Spannung...

[Piffan]

Original geschrieben von Thowe
Nix, ok, naja, Termini. Aber eigentlich heisst es eh terminus technicus für einen Fachbegriff, ich denke das er die meint. *auch mal ultraklugscheiss*

Aha, also meint er termini technici oder so(mit den Fremdsprachen hab ichs auch nicht so, war häufig mal krank während der Schulzeit :D )...Naja, Professor Grzimek sprach in seiner Fernsehsendung auch gern von "Kaktussen", also befindet sich 8bit in guter Gesellschaft ;)

[Gast]

Original geschrieben von zeckensack
Wo?
Wo hat jemals ein VS (oder eine HW-T&L-Einheit, oder gar eine Software-T&L-Implementierung) mit 16 bit FP oder gar weniger gearbeitet?
*kopfschüttel*


PS1, der 66Mips Coprozessor hat imho mit 16bit Integer gearbeitet, da er als 32bit 33MHz -Prozessor beschrieben wird. Aber die PS1 gilt ja nicht, das ist keine richtige 3D-Hardware (ohne Z-Buffer, Filtering etc...).

[FatalError]

Original geschrieben von Piffan
Aha, also meint er termini technici oder so(mit den Fremdsprachen hab ichs auch nicht so, war häufig mal krank während der Schulzeit :D )...Naja, Professor Grzimek sprach in seiner Fernsehsendung auch gern von "Kaktussen", also befindet sich 8bit in guter Gesellschaft ;)

Die Schreibweise "Kaktusse" ist nach der neuen Rechtschreibreform auch erlaubt. :D /Klugscheissauch

Original geschrieben von Gast
Bitte löscht diesen Thread... der ist nun wirklich nicht 3d-Center-würdig.
Gruß

Jörg

ganz deiner Meinung...

mfg
FatalError

[Xmas]

Original geschrieben von Gast
PS1, der 66Mips Coprozessor hat imho mit 16bit Integer gearbeitet, da er als 32bit 33MHz -Prozessor beschrieben wird.
Was ist das denn für eine verworrene Begründung?

Ein 16bit Integer Koordinatensystem reicht für brauchbare Darstellung niemals aus. Damit kann man nicht mal einen Würfel vernünftig drehen, ohne dabei Ruckeln zu beobachten.

[Gast]

Original geschrieben von AchtBit
[...]

Ein Beweis, dass Du einfach nicht kapieren willst, dass die FX HW alleine, physikalisch keine Aussage, ueber moegliche Kapazitaeten auf vitueller Ebene machen.


Was meinst du mit physikalischer/vrtueller Ebene? Bitte genauer erklären.

MfG

[MikBach]

An achtbit:

Wundere dich nicht in einem Jahr, wenn deine Karte nur noch die Hälfte einer 9800PRO wert ist.

Ist abzusehen. IMO

[DrumDub]

Original geschrieben von Gast
Was meinst du mit physikalischer/vrtueller Ebene? Bitte genauer erklären.

MfG

physikalisch=gpu

virtuell=treiber

*eg*

meine interpretation: der forceware 71.xx wirds schon richten... ;)

[Gast]

Also der FX Treiber kann theoretisch unendlich lange PS Programme abarbeiten. Das ist ja ganz toll, aber was habe ich davon?

[MikBach]

Original geschrieben von MikBach
An achtbit:

Wundere dich nicht in einem Jahr, wenn deine Karte nur noch die Hälfte einer 9800PRO wert ist.

Ist abzusehen. IMO

Falls Du auch wissen willst warum, schau Dir mal vielleicht die letzten 2 Seiten des Beitrags 3dmark2003 patch 340 und die Auswirkungen an.

[LovesuckZ]

Original geschrieben von MikBach
Falls Du auch wissen willst warum, schau Dir mal vielleicht die letzten 2 Seiten des Beitrags 3dmark2003 patch 340 und die Auswirkungen an.

Das ist nur viel bla,bla. Aber nichts, was deine These stuetze.
Ich koennte nun auch mit Halo kommen und die bescheidene Leistung der r3x0 Karten anprangern (trotz ATi gerechten Shadern).
Was in Zukunft passiert, sollte man nicht versuchen zu erklaeren, denn man koennt bös auf den Mund fallen.

[MikBach]

Original geschrieben von LovesuckZ

Ich koennte nun auch mit Halo kommen und die bescheidene Leistung der r3x0 Karten anprangern (trotz ATi gerechten Shadern).


Bei Halo sind ATI und Nvidia gleichwertig, obwohl Nvidia die Shader programmiert hat.

[LovesuckZ]

Original geschrieben von MikBach
Bei Halo sind ATI und Nvidia gleichwertig, obwohl Nvidia die Shader programmiert hat.

Trotz die Shader nur mit dem 2.0 Compiler Profil "compiliert" (hoffe so richtig) wurden. Natuerlich steht auf der anderen Seite die durchgaengige reduzierte Genauigkeit (also _pp hint), was der Nvidia Architektur einen Vorteil und ATi keinen Nachteil bereitet.
Halo ist aber ein Argument gegen deine These. Und in einem Jahr, wenn die "wirklichen" DX9 in Aussicht kommen, muss man sowieso auf einen NV40 oder r420 wechseln.

[Dunkeltier]

Original geschrieben von LovesuckZ
Trotz die Shader nur mit dem 2.0 Compiler Profil "compiliert" (hoffe so richtig) wurden. Natuerlich steht auf der anderen Seite die durchgaengige reduzierte Genauigkeit (also _pp hint), was der Nvidia Architektur einen Vorteil und ATi keinen Nachteil bereitet.
Halo ist aber ein Argument gegen deine These. Und in einem Jahr, wenn die "wirklichen" DX9 in Aussicht kommen, muss man sowieso auf einen NV40 oder r420 wechseln.


Da scheinst du aber eine gut zu funktionierende Glaskugel zu haben. Wenn wir schon dabei sind: Die Geforce FX 59x0 reißt es bereits jetzt in DX9 Games mit PS2.0 (in Tomb Raider: Angel of Darkness) sowie in noch nicht erschienenden Spielen (siehe Half-Life 2) die Beine weg (beides an der Unspielbarkeitsgrenze aus meiner Sicht). :lol: Dagegen bringt die ATi auch in (noch nicht erschienenden) Spielen die besser der Geforce FX Architektur liegen (Doom III) noch sehr spielbare und gute Bildwiederholraten.

Quelle: Siehe aktuelle Benches die durchs Netz geistern, Threads im 3dcenter.de Forum und meine Glaskugel... ;)

[MikBach]

Original geschrieben von LovesuckZ
Trotz die Shader nur mit dem 2.0 Compiler Profil "compiliert" (hoffe so richtig) wurden. Natuerlich steht auf der anderen Seite die durchgaengige reduzierte Genauigkeit (also _pp hint), was der Nvidia Architektur einen Vorteil und ATi keinen Nachteil bereitet.
Halo ist aber ein Argument gegen deine These. Und in einem Jahr, wenn die "wirklichen" DX9 in Aussicht kommen, muss man sowieso auf einen NV40 oder r420 wechseln.

Genau, die reduzierte Genauigkeit(welche NVidia braucht) ist es. In Zukunft werden die Shader komplexer,dazu werden die volle Genaugkeit brauchen, um keine Artefakte zu bilden.

[LovesuckZ]

Wenn ich jetzt sagen würde: "typisch Fanatiker, zu dumm zum Lesen", waere ich bestimmt um einen Punkt reicher auf meiner "black List".
Daher lasse ich es und setze dich nur einfach auf meine Ignore Liste.
Einen wunderschoenen Tag noch!

[LovesuckZ]

Original geschrieben von MikBach
Genau, die reduzierte Genauigkeit(welche NVidia braucht) ist es. In Zukunft werden die Shader komplexer,dazu werden die volle Genaugkeit brauchen, um keine Artefakte zu bilden.

"Zukunft", das ist ein wunderschoenes Wort.
Du wirst mir nun auch ein einzigstes Spiel nennen, welches in der nahen Zukunft kommt und dessen Shader mindesten FP24 benoetigt (und Half Life 2 sollte es nicht sein :D ).

[Dunkeltier]

Original geschrieben von MikBach
Genau, die reduzierte Genauigkeit(welche NVidia braucht) ist es. In Zukunft werden die Shader komplexer,dazu werden die volle Genaugkeit brauchen, um keine Artefakte zu bilden.

nVidia braucht imho keine reduzierte Genauigkeit, sondern optimierten Shader-Code und keine FP32-Genauigkeit...

[MikBach]

Original geschrieben von LovesuckZ
"Zukunft", das ist ein wunderschoenes Wort.
Du wirst mir nun auch ein einzigstes Spiel nennen, welches in der nahen Zukunft kommt und dessen Shader mindesten FP24 benoetigt (und Half Life 2 sollte es nicht sein :D ).

Es geht hier nicht um bestimmte Spiele, sondern Effekte.

Alle Effekte, die sich mit "Durchsichtigkeit" befassen werden durch FP24 viel schöner, dazu zähle ich vor allem Wasser und jegliche Glasspiegelungen, ausserdem (bunter) Nebel usw.

[LovesuckZ]

Original geschrieben von MikBach
Es geht hier nicht um bestimmte Spiele, sondern Effekte.


Sollten Anweisungen mehr als FP16 benoetigen, dann steht immernoch FP32 zur Verfügung.

[Dunkeltier]

Original geschrieben von LovesuckZ
Sollten Anweisungen mehr als FP16 benoetigen, dann steht immernoch FP32 zur Verfügung.


Welcher seeeehr langsam ist...

[MikBach]

Original geschrieben von LovesuckZ
Sollten Anweisungen mehr als FP16 benoetigen, dann steht immernoch FP32 zur Verfügung.

Ich meinte natürlich nur FP. Nvidia soll ruhig kombi 16/32 machen, aber die sind auch in FP16 nicht der Bringer, und von FP32 will ich gar nicht erst reden.

[DrumDub]

Original geschrieben von MikBach
Es geht hier nicht um bestimmte Spiele, sondern Effekte.

Alle Effekte, die sich mit "Durchsichtigkeit" befassen werden durch FP24 viel schöner, dazu zähle ich vor allem Wasser und jegliche Glasspiegelungen, ausserdem (bunter) Nebel usw.

ähmm... wer sacht denn, dass bei nv dann für diese effekte nicht fp32 genommen wird? der sinn des mixed modes bzw. pp ist ja eben, die fp einheiten besser auszulasten, indem da, wo fp16 reicht, eben jenes genommen wird und bei entsprechenden effekten, die >fp16 benötigen fp32 genommen wird. problem bisher: es ist aufwändiger zu realisieren, so lange es noch kein entsprechendes compiler-profil für hlsl gab (siehe handoptimierte fx-shader in halo).

dennoch glaube ich, dass es nv mit der aktuellen fx-hardware nicht schaffen wird an die ps-leistung von ati ranzukommen. was fixed-funktion t&l bzw. vs angeht liegen sie ja sogar vor ati. gerade der nv36 mit der kompletten vs-einheit des nv35 kann hier mächtig zulegen:

http://www.anandtech.com/video/showdoc.html?i=1910&p=11

die frage ist für mich, ob das "problem" der atis bei halo nicht die vs sind?

http://www.anandtech.com/video/showdoc.html?i=1910&p=12

[MikBach]

Original geschrieben von DrumDub



[QUOTE][SIZE=1]
die frage ist für mich, ob das "problem" der atis bei halo nicht die vs sind?

http://www.anandtech.com/video/showdoc.html?i=1910&p=12

Ich glaube kaum, das der Polycount ein Problem der heutigen Grakas ist.

[AchtBit]

Weitgehend gefährliches Halbwissen. Zum letzten Satz:
Es spielt also keine Rolle, wieviele Funktionseinheiten da sind, wie diese verschaltbar sind, wieviele Register, wieviele Readports, etc? *gnarf*

Eine reale untergeordnete Rolle ist dann wohl keine Rolle?
Wenn Du alles so gelesen hast, dann kannst Du auch nur die Haelfte mitbekommen haben.

Handoptimierungen seitens der IHVs sind schlecht, eben weil eine Auswahl der zu optimierenden Shader getroffen werden muß, und der Arbeitsaufwand erheblich ist. Automatisch optimierende Treiber sind die einzige Lösung mit Zukunft.

Ich frag mich warum. Meinst Du etwa die naechsten 100 top Dx9 Games, die intensiv PS2.0 einsetzen?

... was aber in der Doom 3-Engine nicht zum Tragen kommt.
Hier geht's um relativ kurze Shader (<=16 Instruktionen), dafür schlagen Z-Fill-Optimierungen voll durch.

Wenn das fuer Dich der einzige gute Entwickler ist, dann wuerde das was Du sagst eine Rolle spielen.

Contra. Die Fähigkeit der Treiberentwickler lässt sich an der Shader-Performance messen.

Sehr witzig. Verdammt schwere Sache die Hardware im IO abzubilden. Wenn du Shader Compiler/Optimizer meinst, den entwickelt unter Garantie kein Treiberschreiber.

Die Fähigkeit der Entwickler ist nur beim Erzeugen des übergebenen Shader-Codes meßbar

Gute Idee, wenn ich demnaechst ne Exception catch, sag ich jetzt auch einfach, ich kann nix dafuer, hat sich einwandfrei compilieren lassen.
Ich weis nicht welche Kontrollstrukturen die einzelnen Shader besitzen aber ist es nicht auch eigentlich Sinn der Sache, dass moeglichst viele Streams per pass paralell laufen?
Sind nicht auch Registershifts/-statusabfragen oder Callbacks auf Registerbuffer fuer die Shader moeglich?
Darueber weis ich zuwenig. Ich wollt eigentlich nur ne gute Graka Empfehlung. Ohne das Wissen von M$ spezifischen Shaderstreams erfahr ich wohl nicht welche mir zusagt?
Du muss mir erst beweisen, dass kein Rollback moeglich ist. Wenn Du das kannst, bleibt aber immer noch die Kontrolle durch die Engine. Das waere dann so ein Fall wo sich die Faehigkeiten des Entwicklers zeigen.

DX9+ existiert nicht (du meintest wahrscheinlich PS2.0+ bitte die Termini erstmal lernen).

Ach was du nicht sagst. PS2.0 in der Hardware = DX9 Hardware. Ein Layer koennte > ps2.0 in der HW vortaeuschen. Da die FPU dann > als das DX9 interface u. < als das dx10 interface ist, bleibt das theoretisch dx9+.

DX10 ist nicht spezifiziert, die NV3x-Reihe wird btw auch nicht damit kompliant sein können. Das wäre geradezu ein Wunder

Ein Wunder braucht man zwar nicht aber weitaus mehr als ein paar IO fakes. Eine derartige Massnahme waere undenkbar.

Auflösung ist hier irrelevant. Die erreichte Füllrate bestimmt sich eben über die Shader-Version (PS, nicht VS; gerne auch fixed function). Flüssig machbare Auflösung ist ein Resultat der erreichbaren Füllrate.
Wenn diese bei 1024x768 geringer ist als bei der Konkurrenz, ändert sich bei höheren Auflösungen auch nichts mehr daran.

Selbst wenn das AA Supersampling waere, alle Qualitaets Einstellungen die gleichen Mechanismen verwenden und kein Z-Buffer definiert ist, deine Schlussfolgerung waere maximal als wahrscheinlich zu betrachten.

Ja, das Netz ist voll von Fehlinformation und gefährlichem Halbwissen. Wozu auch dein Post nochmal enorm beigetragen hat.

Der Unterschied zw. Dir und mir ist, dass ich mich zu meinem Halbwissen, insbesondere was Shader Makro Engines betrifft, bekenne.
Offensichtlich kennst Du viele Begriffe im Rahmen eines Systems, doch es laesst mitunter auch verkehrte Schluesse zu, wenn sie nicht zurueck zur Maschinenebene reichen.

Deine Worte:
"So, ich habs so untechnisch wie moeglich geschrieben. Vor allen Dingen ist keine Mutmassung enthalten sondern es sind nur fundamentierte Aussagen.
Wenn jemand Fragen dazu hat, soll er diese moeglichst genau spezifizieren. Auf technische Fragen die keinen Hintergrund aufweisen werd ich nicht viel sagen koennen, denn ohne noetige Vorkenntnis der Fragers, wird eine kurze Antwort meinerseits nicht annaehernd ein Verstandnis vermitteln koennen."
"Ich hoffe dass meine Erkenntnisse dazu beitragen, einen potenziellen Kaeufer, sich den Spam zu ersparen und einen realen Einblick zu vermitteln."
Also Expertenstatus ist da nicht erwaehnt. Seis drum es erfordern nicht besonders viel Anstrengung rauszufinden wie sich 2 Grafikprozessoren anhand ihrer Corestruktur unterscheiden.

Intel P5
Intel P6
ISA (Kontext: Prozessoren)
Ich drehe nichts rum. Ich benutze die Termini so, wie sie eben benutzt werden und Punkt.
Ich erwarte von einem Fachfremden nicht, daß er alle Termini kennt. Was ich allerdings erwarte, ist daß man sich dann "fundamentierte" [sic] Analysen verkneift.

Zeig mir ein Datenblatt von Intel Pentium Typen wo das -> P5 o. P6 zu finden ist.

Wo?
Wo hat jemals ein VS (oder eine HW-T&L-Einheit, oder gar eine Software-T&L-Implementierung) mit 16 bit FP oder gar weniger gearbeitet?
*kopfschüttel*
Warte, ich helf dir. Die einzige Antwort die du finden könntest, ist OpenGL ES. Aber das wußtest du sicher schon selber.

Ok, die Vertex Shader war nur eine Vermutung weil genau der VS - lastige Test die groessten Unterschiede aufwies. nV sagte dagenen was von, 3 PX Shader wurde optimiert.
Das ist auch nicht von Bedeutung. Der Hintergrund ist der Compiler und seine Faehigkeit optimalen Code zu erzeugen.


Ic setzt sogar noch eins drauf: Die FXen können nichtmal annähernd alles was in DX9 spezifiziert ist

Bloss falsch formuliert. So musst Dus es sagen. 'Ich kenn nichtmal annähernd alles was in DX9 spezifiziert ist'

So, was haben wir hier nun?
Jemand, der nur schlecht die deutsche Sprache beherrscht.
Jemand, der mit einem nicht vorhandenen Wissen protzt. (8 bit VS? Hilfe? Hab ich was verpasst?)
Jemand, der statt Fakten zu extrahieren, nur seine eigenen Interpretationen und Ansichten widergibt.
Jemand, der die Aussagen gewisser Persönlichkeiten verdreht, aus dem Kontext reißt und dementsprechend falsch deutet.
Jemand, der andere beschuldigt, sie würden nur unsinnige Mutmaßungen anstellen, es dann selber aber noch viel schlimmer macht.
Habe ich etwas Wichtiges vergessen?
An die Mods:
Eigentlich können wir diesen Thread doch getrost schließen, oder? Bestenfalls gehört der gerade so noch ins Speku-Forum.

Genau das trifft auch auf Dein Posting zu. + Kein Bezug zum Thread, Flames auf unwesentliche Details, Informationsgehalt -> 0.
Mein Psychologe wuerde sagen, nicht verstandene Intelligenz erzeugt offensive Aroganz aufgrund verdraengter Unzureichenheit.

Eigentlich sollte ich es lassen in einem solchen Thread möglicherweise für noch mehr Verwirrung zu sorgen aber ich denke das ich das NV3X kann mehr als DX9 Thema mal richtig stellen muss.
Die kurze Antwort auf die Frage ob NV3X mehr kann als DX9 ist Ja. Die lange Antwort ist: Ja, aber jeder Chip kann mehr als die entsprechende DX-Version spezifiziert. Es gibt eben immer ein paar Spezialitäten die nicht in die DX-Spec aufgenommen wurde. Frag mal ATI wie viele Shaderanweisungen ein R300 kann. Und dann sagst du ihnen das du DX benutzt und plötzlich wird die Zahl kleiner. Das ist nun mal der Preis wenn man eine API haben möchte die vereinheitlicht.

gthx @ Demirug.
Endlich einer der weis wovon er spricht. Der Hintergrund steht fest.

Keine Chance hier etwas positives zu NV Karten zu sagen ohne gleich in der Luft zerrissen zu werden

*g* Jo, genau deshalb muss ich sie verteidigen. Verdient haben sie aber nicht. Ihre unfaeren Methoden die Konkurrenten aus dem Markt zu pressen haben sogar die Intrigen von M$ uebertroffen.
Das aussen vor, bleibt die Tatsache des korrekten Schrittes in die Zukunft mit dieser Art von HW.

Wo es jetzt eh schon ins Geflame und OT abgedriftet ist, wie viel AGP Takt verkraftet die FX eigentlich? Leider hat das PC-DL kein AGP/PCI Fix und bei 165 MHz wären das dann 83 MHz...

Hi Lochfrass,

das laufen ist nicht so das Problem sondern die Temp. der Karte. Bei 76.5mhz ist die Temp. ,unter 2D 55-60C kontant, unter 3D 75-80C kontant.
Das ist noch im gruenen Bereich. 83mhz wuerde signaltechnisch wohl kaum ein Problem sein, jedoch kannst wahrscheinlich nochmal gute 10C im Schnitt mehr annehmen.
Mit etwas zusaetzlicher kalter Luft, sollte es aber im gruenen Bereich bleiben. Beim Untertackten faengt sie das zicken an. 8mhz unter Standard und sie friert just im 3d Mode den Rechner ein.


@All, also die wenigen gehaltvollen Posts gehen fast alle in den flames der trolls auf. Genau das sollte eigentlich nicht der Fall sein.

Fuer den Preis von 367Euro ist die Leadtek fx5900u 256MB retail erhaeltlich. Aufgefuehrt ist sie beim Geizhals.
Wer meint, dass er fuer eben diesen Preis eine Radeon9800pro mit 256MB retail bekommen kann, der hat eine Einwand und hoffentlich auch einen Link.
Das durchaus identische Bild beider Karten, rechfertigt in keiner weise 100 Euro mehr fuer die Radeon

Das allein garatiert mir keine AGP@76mhz++ Stabilitaet. In meine Fall war das eine wesentliche Voraussetzung.


O.T.

Achtbit kennen wir uns zufaellig?<<

Hey Ail, big slacker, you are still teaching trolls outhere in repectful behavior, aren't you?
how's it going man? it's a pleasure for me to recognize somebody's still sticking with his nick.
At least it turns out that's what indicates a reasonable user.

Hast Dein german weiter ausgebaut, right? ;)
As you might see my english's still as choppy as it were been back in slacker time. :)
Besucht Du immer noch die Refugees, gibts die ueberhaupt noch?

cu and give my regards to Greek

[MikBach]

Original geschrieben von AchtBit
Bloss falsch formuliert. So musst Dus es sagen. 'Ich kenn nichtmal annähernd alles was in DX9 spezifiziert ist'

Der Kollege auf den Du dich beziehst hat Recht, oder können die FXe PS/VS3.0, wohl kaum. das behauptet noch nicht mal Nvidia. Aber die sind in DX9 drin.

Original geschrieben von AchtBit
Fuer den Preis von 367Euro ist die Leadtek fx5900u 256MB retail erhaeltlich. Aufgefuehrt ist sie beim Geizhals.
Wer meint, dass er fuer eben diesen Preis eine Radeon9800pro mit 256MB retail bekommen kann, der hat eine Einwand und hoffentlich auch einen Link.
Das durchaus identische Bild beider Karten, rechfertigt in keiner weise 100 Euro mehr fuer die Radeon


Für etwas über 300€ krigst Du schon eine 9800(PRO)128MB.
Die 256MB bingen höchstens 5%. Also worauf willst Du hinaus?

[StefanV]

Original geschrieben von MikBach
Für etwas über 300€ krigst Du schon eine 9800(PRO)128MB.
Die 256MB bingen höchstens 5%. Also worauf willst Du hinaus?

Jap, vorallendingen, da bei der Radeon 9800 die zusätzlichen 128MB RAM mehr oder midner egal sind und eher die 10MHz mehrtakt des Speichers für eine bessere Performance verantwortlich ist...

Das die 256MB GF FX noch das Downfiltering bei 4x im 'RAMDAC' machen, erwähnte ich irgendwo schon.
Nur bringt 4x OGMSAA kaum einen Qualitätsvorteil im Vergleich mit 2x SSMSAA...

[AchtBit]

Der Kollege auf den Du dich beziehst hat Recht, oder können die FXe PS/VS3.0, wohl kaum. das behauptet noch nicht mal Nvidia. Aber die sind in DX9 drin.

Wo hat er den recht?

fload texture formate sind optional und nicht Voraussetzung der dx9 HW.

HW seitig werden alle diese fp formate bis auf mrt's unterstuetzt. Eine bis Dato fehlende Validierung fuer virtuellen Speicher in der WHQL Spec. ist der Grund weshalb die nicht aktiviert werden koennen.

Elaborate gibts hier >>

http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A0=DIRECTXDEV&D=0&F=&H=0&I=-3&O=T&S=&T=1

>>Für etwas über 300€ krigst Du schon eine 9800(PRO)128MB.
Die 256MB bingen höchstens 5%. Also worauf willst Du hinaus?<<

>=1600x1200x32 4xAA 8xAF

Selbst das ist mit 256MB auf einer Map in UT03 nicht moegliche ohne AGP Texturing bemuehen zu muessen.

Die Aussage, das geht mit 128MB, ist gerade zu laecherlich.
Die langen bei der 4600er Ti nicht mal um allem Maps in 1600x1200x32 per default, vom Videospeicher aus zu bedienen.

[che g]

Handoptimierungen seitens der IHVs sind schlecht, eben weil eine Auswahl der zu optimierenden Shader getroffen werden muß, und der Arbeitsaufwand erheblich ist. Automatisch optimierende Treiber sind die einzige Lösung mit Zukunft.



Ich frag mich warum. Meinst Du etwa die naechsten 100 top Dx9 Games, die intensiv PS2.0 einsetzen?


Weil es für alle wesentlich einfacher ist den Treiber die Arbeit machen zu lassen. Sonst sind wir wieder beim "optimieren auf verschiedene Hardware" = mind. doppelter Aufwand: nV, ATI und möglicherweise noch andere.


Auflösung ist hier irrelevant. Die erreichte Füllrate bestimmt sich eben über die Shader-Version (PS, nicht VS; gerne auch fixed function). Flüssig machbare Auflösung ist ein Resultat der erreichbaren Füllrate.
Wenn diese bei 1024x768 geringer ist als bei der Konkurrenz, ändert sich bei höheren Auflösungen auch nichts mehr daran.



Selbst wenn das AA Supersampling waere, alle Qualitaets Einstellungen die gleichen Mechanismen verwenden und kein Z-Buffer definiert ist, deine Schlussfolgerung waere maximal als wahrscheinlich zu betrachten.


Du verstehst hier etwas nicht: Karte 1 hat Füllrate x, Karte 2 Füllrate y wobei x > y. EGAL welche Auflösung du wählst, Karte 1 wird IMMER schneller als Karte 2 sein. (Gleiche Einstellungen/Systeme vorrausgesetzt)

Contra. Die Fähigkeit der Treiberentwickler lässt sich an der Shader-Performance messen.



Sehr witzig. Verdammt schwere Sache die Hardware im IO abzubilden. Wenn du Shader Compiler/Optimizer meinst, den entwickelt unter Garantie kein Treiberschreiber.


Lass dir das was zeckensack gesagt hat nocheinmal durch den Kopf gehen. Erinnere dich dabei an die Geschwindigkeitsentwickling der Radeon 9700PRO vom Catalyst 1.x bis jetzt.


Die Fähigkeit der Entwickler ist nur beim Erzeugen des übergebenen Shader-Codes meßbar



Gute Idee, wenn ich demnaechst ne Exception catch, sag ich jetzt auch einfach, ich kann nix dafuer, hat sich einwandfrei compilieren lassen.
Ich weis nicht welche Kontrollstrukturen die einzelnen Shader besitzen aber ist es nicht auch eigentlich Sinn der Sache, dass moeglichst viele Streams per pass paralell laufen?
Sind nicht auch Registershifts/-statusabfragen oder Callbacks auf Registerbuffer fuer die Shader moeglich?
Darueber weis ich zuwenig. Ich wollt eigentlich nur ne gute Graka Empfehlung. Ohne das Wissen von M$ spezifischen Shaderstreams erfahr ich wohl nicht welche mir zusagt?
Du muss mir erst beweisen, dass kein Rollback moeglich ist. Wenn Du das kannst, bleibt aber immer noch die Kontrolle durch die Engine. Das waere dann so ein Fall wo sich die Faehigkeiten des Entwicklers zeigen.


:???: :|


Der Unterschied zw. Dir und mir ist, dass ich mich zu meinem Halbwissen, insbesondere was Shader Makro Engines betrifft, bekenne.
Offensichtlich kennst Du viele Begriffe im Rahmen eines Systems, doch es laesst mitunter auch verkehrte Schluesse zu, wenn sie nicht zurueck zur Maschinenebene reichen.


Ausgerechnet zeckensack über sein Wissen über die Maschinenebene zu belehren...

[StefanV]

Original geschrieben von AchtBit
>>Für etwas über 300€ krigst Du schon eine 9800(PRO)128MB.
Die 256MB bingen höchstens 5%. Also worauf willst Du hinaus?<<

>=1600x1200x32 4xAA 8xAF

Selbst das ist mit 256MB auf einer Map in UT03 nicht moegliche ohne AGP Texturing bemuehen zu muessen.

Die Aussage, das geht mit 128MB, ist gerade zu laecherlich.
Die langen bei der 4600er Ti nicht mal um allem Maps in 1600x1200x32 per default, vom Videospeicher aus zu bedienen.

Sorry, aber das ist Blödsinn.

Du willst doch nicht ernsthaft von 'ner TI4600 auf 'ne Radeon 9800 schließen, oder?!

Desweiteren beweist diese (http://www.hardocp.com/article.html?art=NTI5LDY=) Seite meine Argumentation, wobei die Radeon 9800 PRO/128 nur geringfügig langsamer als die FX5900 ULTRA ist.

Wobei das Ergebnis für die FX eher erschütternd ist, da jene eine deutlich größere Bandbreite als die Radeon besitzt (~135MHz mehr Speichertakt!!)

[Keel]

Ok, die Vertex Shader war nur eine Vermutung weil genau der VS - lastige Test die groessten Unterschiede aufwies. nV sagte dagenen was von, 3 PX Shader wurde optimiert.

Also siehst du nun ein, dass das mit VS nicht stimmt? Ich frage bloß...
Was hast du eigentlich ständig mit den VS? Ich bin mir da jetzt zwar nicht zu 100% sicher, aber afaik hat NV gar keine Probleme mit den Vertex Shadern. Lediglich die Pixel Shader-Performance ist dann und wann mal unter aller Sau. Bzw. kann ich ja auch direkt fragen: Kannst du mir einen Test zeigen, welcher den NV-Karten eine schlechte VS-Performance attestiert?
"3 PX Shader wurde optimiert."
Du meinst sicher das Richtige, nur ist das für die NV3x-Linie nicht von Bedeutung. Die NV3x-Linie kann kein PS/VS3.0, da sagt NV auch nichts anderes. Das mit den PS/VS3.0 wird dann erst ab NV4x eine Bedeutung haben.

Genau das trifft auch auf Dein Posting zu. + Kein Bezug zum Thread, Flames auf unwesentliche Details, Informationsgehalt -> 0.
Mein Psychologe wuerde sagen, nicht verstandene Intelligenz erzeugt offensive Aroganz aufgrund verdraengter Unzureichenheit.
Natürlich war mein letzter Post OT; schön, dass dir das aufgefallen ist.
"Unwesentliche" Details? Hmm, 8 bit VS usw. usf. ist aber ein nicht ganz unwesentliches Detail.
BTW: Dein Psychologe? ?-) Das würde natürlich einiges erklären. :naughty:

(PS: Könntest du nicht einmal ein bisschen auf Rechtschreibung und Grammatik achten?)

[MikBach]

Original geschrieben von AchtBit
Wo hat er den recht?

fload texture formate sind optional und nicht Voraussetzung der dx9 HW.

HW seitig werden alle diese fp formate bis auf mrt's unterstuetzt. Eine bis Dato fehlende Validierung fuer virtuellen Speicher in der WHQL Spec. ist der Grund weshalb die nicht aktiviert werden koennen.


Wenn Du glaubst dass die FXe PS/VS3.0 beherrschen, dann bist Du für mich ein Träumer.


>
>Für etwas über 300€ krigst Du schon eine 9800(PRO)128MB.
Die 256MB bingen höchstens 5%. Also worauf willst Du hinaus?<<

>=1600x1200x32 4xAA 8xAF

Selbst das ist mit 256MB auf einer Map in UT03 nicht moegliche ohne AGP Texturing bemuehen zu muessen.

Die Aussage, das geht mit 128MB, ist gerade zu laecherlich.
Die langen bei der 4600er Ti nicht mal um allem Maps in 1600x1200x32 per default, vom Videospeicher aus zu bedienen.

Bei bestimmten Spielen trifft es zu. Aber die meisten neuen Spiele laufen ohne Probleme, oder es wird halt auf ATI als auch Nvidia ruckeln.
Auserdem wenn Du 4x AA nimmst, dann musst Du bei Nvidia 4xs nehmen, um die gleiche Qualität zu erreichen.
So jetzt fang mal an zu benchen, und poste uns Deine Ergebnisse.

[StefanV]

Original geschrieben von Keel
Also siehst du nun ein, dass das mit VS nicht stimmt? Ich frage bloß...
Was hast du eigentlich ständig mit den VS? Ich bin mir da jetzt zwar nicht zu 100% sicher, aber afaik hat NV gar keine Probleme mit den Vertex Shadern. Lediglich die Pixel Shader-Performance ist dann und wann mal unter aller Sau. Bzw. kann ich ja auch direkt fragen: Kannst du mir einen Test zeigen, welcher den NV-Karten eine schlechte VS-Performance attestiert?

1. AFAIK hat nV auch eine ausgezeichnete VS Performance, nach meinem Kenntnisstand.

2. richtig, die VS sind in Ordnung, nur die PS sind etwas missraten...

3. sorry, da muss ich passen.
Ich kann nur Benchmarks vorweisen, die der FX5800 eine recht gute VS Performance attestieren.
Könnte da u.A. dieses (http://service.futuremark.com/compare?2k1=7083396) für eine FX5800 und jenes (http://service.futuremark.com/compare?2k1=6780110) für eine Radeon 9700 (AFAIK PRO) anbieten.

[Piffan]

So, jetzt mal reinen Tisch: Ati ist derzeit besser und Punkt! :D

[MikBach]

Original geschrieben von Piffan
So, jetzt mal reinen Tisch: Ati ist derzeit besser und Punkt! :D

Ich wollte es nicht direct so schreiben. Aber wenn Du meinst , ich bin dabei.

[DrumDub]

Original geschrieben von MikBach
Ich wollte es nicht direct so schreiben. Aber wenn Du meinst , ich bin dabei.

me too. :D (aber nur für gamer. im cad/rendering-bereich ist nvidia besser.)

[MikBach]

Original geschrieben von DrumDub
me too. :D (aber nur für gamer. im cad/rendering-bereich ist nvidia besser.)

Ja.

[AchtBit]

So jetzt fang mal an zu benchen, und poste uns Deine Ergebnisse.

So und jetzt mag ich nichtmehr. Macht doch was ihr wollt. :p

UT2003 Build UT2003_Build_[2003-04-07_17.42]
Windows XP 5.1 (Build: 2600)
GenuineIntel PentiumPro-class processor @ 1613 MHz with 511MB RAM
NVIDIA GeForce4 Ti 4600 (4109)

dm-antalus?spectatoronly=true?numbots=12?quickstart=true?attractcam=true -benchmark -seconds=77 -exec=..\Benchmark\Stuff\botmatchexec.txt ini=..\Benchmark\Stuff\MaxDetail.ini userini=..\Benchmark\Stuff\MaxDetailUser.ini -nosound -UPT -1600x1200
8.205630 / 28.899292 / 54.318180 fps *(eine der Maps die mit standard 1600x1200x32 ohne Breaks durchlaeuft. = Gaming -> unspielbar


UT2003 Build UT2003_Build_[2003-11-16_20.21]
Windows XP 5.1 (Build: 2600)
GenuineIntel PentiumPro-class processor @ 1613 MHz with 511MB RAM
NVIDIA GeForce FX 5900 Ultra (5270)

dm-antalus?spectatoronly=true?numbots=12?quickstart=true?attractcam=true -benchmark -seconds=77 -exec=..\Benchmark\Stuff\botmatchexec.txt ini=..\Benchmark\Stuff\MaxDetail.ini userini=..\Benchmark\Stuff\MaxDetailUser.ini -nosound -UPT -1600x1200
16.543941 / 45.957153 / 82.210350 fps Gaming -> spielbar
16.377735 / 44.963776 / 81.602608 fps 2xAA Gaming -> spielbar
11.166676 / 39.112072 / 77.258904 fps 4xAA Gaming -> spielbar
9.578427 / 37.993004 / 72.348267 fps 4xAA 8xAF Gaming -> gerade so spielbar *(eine einzige large CTF Map hat damit nen kurzen Zucker gemacht, bei allen anderen waren die 256MB ausreichend

8xAA war ab hier nicht mehr rein vom Videopeicher machbar


UT2003 Build UT2003_Build_[2003-04-12_18.41]
Windows XP 5.1 (Build: 2600)
GenuineIntel PentiumPro-class processor @ 1613 MHz with 511MB RAM
NVIDIA GeForce4 Ti 4600 (4109)

dom-suntemple?spectatoronly=true?numbots=12 -benchmark -seconds=77 -exec=..\Benchmark\Stuff\botmatchexec.txt
4.733686 / 56.673080 / 112.402672 fps 1600x1200x32 *(unter 5 Frames war deutlicher Zugriff auf AGP Texturing warzunehmen) Gaming -> ich habs gleich bleiben lassen

DM-Icetomb?spectatoronly=true?numbots=12?quickstart=true?attractcam=true -benchmark -seconds=77 -exec=..\Benchmark\Stuff\botmatchexec.txt
0.587450 / 57.075096 / 1.#INF00 fps 1600x1200x32 *(das war zuviel des Guten. AGP Texturing Overload, Karte ist nicht mehr aus der Warteschleife zurueckgekommen Gaming -> Map war in 16x12 eine Gefahr fuer die Grafikkarte
Score = 56.759167

[zeckensack]

:eyes:
Original geschrieben von AchtBit
Eine reale untergeordnete Rolle ist dann wohl keine Rolle?Doch. Eben das sollte dieser Satz dir klar machen. Lies noch mal was du geschrieben hast:
"Auf dieser Ebene spielt die Struktur, phyisikalisch, nur eine untergeordnete Rolle."
Wenn Du alles so gelesen hast, dann kannst Du auch nur die Haelfte mitbekommen haben.Mit bestem Gruß zurück :wink:
Ich frag mich warum. Meinst Du etwa die naechsten 100 top Dx9 Games, die intensiv PS2.0 einsetzen?Mindestens. Und alle anderen auch. Gibt's ein Problem damit?
Wenn das fuer Dich der einzige gute Entwickler ist, dann wuerde das was Du sagst eine Rolle spielen.Du hast johnc ins Spiel gebracht. Lesen und Erinnern zum zweiten:
"Zu erwaehnen waere, dass bei exklusiven Games nV Handoptimierung, zusaetzlich zum Optimizer, anlegen wird.
Gurus wie J.C. werden eigene Optimierungen einsetzten, die massive Performanceschuebe erwarten lassen. Er selbst mutet sich zu locker ueber 100 Instruktionen auf einmal koordinieren zu koennen.
Waehrend der Durchschnitt bei weniger als 30 Instruktionen schon Probleme beim Uberblicken aufweist. Man kann im Endeffekt beim FX sagen, die Faehigkeit des Entwicklers laesst sich an der Performance des Games messen und zwar wesentlich klarer wie das frueher der Fall war."

Vielleicht kannst du mir ja nochmal kurz erklären, warum du das überhaupt geschrieben hast, wenn das ja so garnichts mit dem ganzen Rest zu tun hatte?
Sehr witzig. Verdammt schwere Sache die Hardware im IO abzubilden.API = application programming interface
Mehr gibt's dazu nicht zu sagen.
Wenn du Shader Compiler/Optimizer meinst, den entwickelt unter Garantie kein Treiberschreiber.Doch. Bumms (http://www.gamesdomain.com/news/19074.html)
"With the ForceWare release 50 graphics driver, NVIDIA continues to bring to market ground-breaking software technologies, such as our unified compiler technology, designed with one goal in mind - to enhance the end-user experience."

Boing (http://www.beyond3d.com/forum/viewtopic.php?t=8952&postdays=0&postorder=asc&start=346)
"We've had a shader optimizer in the driver for over a year"

Gute Idee, wenn ich demnaechst ne Exception catch, sag ich jetzt auch einfach, ich kann nix dafuer, hat sich einwandfrei compilieren lassen.
Ich weis nicht welche Kontrollstrukturen die einzelnen Shader besitzen aber ist es nicht auch eigentlich Sinn der Sache, dass moeglichst viele Streams per pass paralell laufen?
Sind nicht auch Registershifts/-statusabfragen oder Callbacks auf Registerbuffer fuer die Shader moeglich?
Darueber weis ich zuwenig. Ich wollt eigentlich nur ne gute Graka Empfehlung. Ohne das Wissen von M$ spezifischen Shaderstreams erfahr ich wohl nicht welche mir zusagt?
Du muss mir erst beweisen, dass kein Rollback moeglich ist.Oh Mann ... du hast keine Ahnung wovon du redest, brabbelst vor dich hin, und dann soll ich dir beweisen, daß du daneben liegst?
Callbacks? Registershifts? Registerbuffer? Das beweist nur, daß du keinen Schimmer hast. Lesen (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/directx9_c/directx/directx9cpp.asp) bildet (http://www.opengl.org/developers/documentation/OpenGL15.html).

Wenn Du das kannst, bleibt aber immer noch die Kontrolle durch die Engine. Das waere dann so ein Fall wo sich die Faehigkeiten des Entwicklers zeigen.Mir war so, als hätte ich folgendes geschrieben:
"Die Fähigkeit der Entwickler ist nur beim Erzeugen des übergebenen Shader-Codes meßbar, wenn man überhaupt ein solches Kriterium anlegen will."
Schon komisch. Vorausgesetzt, man erkennt einen Zusammenhang zwischen "Kontrolle durch die Engine" und "Erzeugen des übergebenen Shader-Codes".

Ach was du nicht sagst. PS2.0 in der Hardware = DX9 Hardware. Ein Layer koennte > ps2.0 in der HW vortaeuschen. Da die FPU dann > als das DX9 interface u. < als das dx10 interface ist, bleibt das theoretisch dx9+.*hup*
Bitte mal über die Shader-Profile von DX informieren, und dann wiederkommen.
Ein Wunder braucht man zwar nicht aber weitaus mehr als ein paar IO fakes. Eine derartige Massnahme waere undenkbar.Na immerhin. Danke.
Selbst wenn das AA Supersampling waere, alle Qualitaets Einstellungen die gleichen Mechanismen verwenden und kein Z-Buffer definiert ist, deine Schlussfolgerung waere maximal als wahrscheinlich zu betrachten.*zubeiß*
FP16 ala NVIDIA ist s10e5. Ergo zehn Bit für die Mantisse. Jetzt rechne mal nach, wieviele Bits man braucht, um 1024 Pixel zu addressieren.
Der Unterschied zw. Dir und mir ist, dass ich mich zu meinem Halbwissen, insbesondere was Shader Makro Engines betrifft, bekenne.
Offensichtlich kennst Du viele Begriffe im Rahmen eines Systems, doch es laesst mitunter auch verkehrte Schluesse zu, wenn sie nicht zurueck zur Maschinenebene reichen.No comment.
Also Expertenstatus ist da nicht erwaehnt.Erinnern wir uns (http://www.forum-3dcenter.org/vbulletin/showthread.php?postid=1355626#post1355626).
"Nun ich wage zu behaupten, ich kenne einige der tatsaechlichen Zusammenhaenge. Da ich hier zu 90% Mutmassungen gelesen habe, mit denen man getrost ein Buch fuellen koennte, dass unter dem Titel 'deutsche Heldensagen ausm 3DCenter Forum' als Lachmaerchen eine neue Kathegorie von Literatur revolutionieren wuerde, werde ich einen Artikel mit Fakten betreffend R3x0 vs. NV3x verfassen."

<snip>
Zeig mir ein Datenblatt von Intel Pentium Typen wo das -> P5 o. P6 zu finden ist.Google ist dein Freund (http://www.google.com/search?q=intel+p6+architecture+site:intel.com&sourceid=opera&num=0&ie=utf-8&oe=utf-8).

[MikBach]

Original geschrieben von AchtBit
So und jetzt mag ich nichtmehr. Macht doch was ihr wollt. :p

UT2003 Build UT2003_Build_[2003-04-07_17.42]
Windows XP 5.1 (Build: 2600)
GenuineIntel PentiumPro-class processor @ 1613 MHz with 511MB RAM
NVIDIA GeForce4 Ti 4600 (4109)

dm-antalus?spectatoronly=true?numbots=12?quickstart=true?attractcam=true -benchmark -seconds=77 -exec=..\Benchmark\Stuff\botmatchexec.txt ini=..\Benchmark\Stuff\MaxDetail.ini userini=..\Benchmark\Stuff\MaxDetailUser.ini -nosound -UPT -1600x1200
8.205630 / 28.899292 / 54.318180 fps *(eine der Maps die mit standard 1600x1200x32 ohne Breaks durchlaeuft. = Gaming -> unspielbar


UT2003 Build UT2003_Build_[2003-11-16_20.21]
Windows XP 5.1 (Build: 2600)
GenuineIntel PentiumPro-class processor @ 1613 MHz with 511MB RAM
NVIDIA GeForce FX 5900 Ultra (5270)

dm-antalus?spectatoronly=true?numbots=12?quickstart=true?attractcam=true -benchmark -seconds=77 -exec=..\Benchmark\Stuff\botmatchexec.txt ini=..\Benchmark\Stuff\MaxDetail.ini userini=..\Benchmark\Stuff\MaxDetailUser.ini -nosound -UPT -1600x1200
16.543941 / 45.957153 / 82.210350 fps Gaming -> spielbar
16.377735 / 44.963776 / 81.602608 fps 2xAA Gaming -> spielbar
11.166676 / 39.112072 / 77.258904 fps 4xAA Gaming -> spielbar
9.578427 / 37.993004 / 72.348267 fps 4xAA 8xAF Gaming -> gerade so spielbar *(eine einzige large CTF Map hat damit nen kurzen Zucker gemacht, bei allen anderen waren die 256MB ausreichend

8xAA war ab hier nicht mehr rein vom Videopeicher machbar


UT2003 Build UT2003_Build_[2003-04-12_18.41]
Windows XP 5.1 (Build: 2600)
GenuineIntel PentiumPro-class processor @ 1613 MHz with 511MB RAM
NVIDIA GeForce4 Ti 4600 (4109)

dom-suntemple?spectatoronly=true?numbots=12 -benchmark -seconds=77 -exec=..\Benchmark\Stuff\botmatchexec.txt
4.733686 / 56.673080 / 112.402672 fps 1600x1200x32 *(unter 5 Frames war deutlicher Zugriff auf AGP Texturing warzunehmen) Gaming -> ich habs gleich bleiben lassen

DM-Icetomb?spectatoronly=true?numbots=12?quickstart=true?attractcam=true -benchmark -seconds=77 -exec=..\Benchmark\Stuff\botmatchexec.txt
0.587450 / 57.075096 / 1.#INF00 fps 1600x1200x32 *(das war zuviel des Guten. AGP Texturing Overload, Karte ist nicht mehr aus der Warteschleife zurueckgekommen Gaming -> Map war in 16x12 eine Gefahr fuer die Grafikkarte
Score = 56.759167

Schön, ich gebe zu , dass ich alles nicht richtig durchgelesen habe, aber was soll das beweisen?

[zeckensack]

Original geschrieben von MikBach
Schön, ich gebe zu , dass ich alles nicht richtig durchgelesen habe, aber was soll das beweisen? Das beweist eindrucksvoll, daß eine Geforce 4 Ti4600 langsamer ist als eine Geforce FX5900 Ultra. Genau das wollte ich schon immer wissen :up:

[StefanV]

Original geschrieben von MikBach
Schön, ich gebe zu , dass ich alles nicht richtig durchgelesen habe, aber was soll das beweisen?

Frag ich mich auch gerad...

Besonders da UT2003 ein recht bescheuertes Mem Managment hat und 'etwas' verschwenderisch mitm Videspeicher umgeht und somit das einzige Game ist, was ansatzweise von 256MB profitiert...

[MikBach]

Original geschrieben von Stefan Payne
Frag ich mich auch gerad...

Besonders da UT2003 ein recht bescheuertes Mem Managment hat und 'etwas' verschwenderisch mitm Videspeicher umgeht

Ist Unreal2 auch davon betroffen, weil ich schon richtg miese Performance auf Video=64MB gesehen habe.

[StefanV]

Original geschrieben von MikBach
Ist Unreal2 auch davon betroffen, weil ich schon richtg miese Performance auf Video=64MB gesehen habe.

Ja, ist AFAIK die gleiche 3D Engine...

€Dit

AUßerdem sind die Benches fürn Anus, da mit Sound gebencht wurde, weshalb ich keine Ergebnisse posten werde.

[nggalai]

Original geschrieben von Stefan Payne
Frag ich mich auch gerad...

Besonders da UT2003 ein recht bescheuertes Mem Managment hat und 'etwas' verschwenderisch mitm Videspeicher umgeht und somit das einzige Game ist, was ansatzweise von 256MB profitiert... ... und ausserdem IMMER AGP-Texturing verwendet, ganz egal, wieviel V-Memory Du hast ...

93,
-Sascha.rb

[aths]

Original geschrieben von Demirug
Vertex Shader laufen immer mit vollen 32 Bit sonst hätte man Z-Fights ohne Ende. Vorallem warum sollte man an einer Stelle optimieren welche in aller Regel gar nicht der Flaschenhals ist? Ich wüsste auch nicht, wie man den VS durch verringerte Präzision schneller machen könnte, da ohnehin (seit NV10) FP32-Logik verwendet wird. Mit FP16 transformieren? S+M10+E5? Oder S+M11+E4? So oder so, wenn ich das jetzt richtig sehe, kann man meinetwegen bei gespeicherten Vertices durchaus auch mit FP24 auskommen, transformieren sollte man besser mit FP32. Sind pro Komponente 4 MUL und 3 ADD. FP16 hielte ich ja für ungenügend.

[Ailuros]

Hey Ail, big slacker, you are still teaching trolls outhere in repectful behavior, aren't you?
how's it going man? it's a pleasure for me to recognize somebody's still sticking with his nick.
At least it turns out that's what indicates a reasonable user.

Hast Dein german weiter ausgebaut, right?
As you might see my english's still as choppy as it were been back in slacker time.
Besucht Du immer noch die Refugees, gibts die ueberhaupt noch?

cu and give my regards to Greek.

Mein Deutsch war ein bisschen verrostet und ich arbeite immer noch daran.

Ich muss zugeben ich hab einen Killer-Instikt. :D

Das dumme ist dass ich jetzt fast ganze 5 Seiten durchlesen muss um zu sehen um was es hier ueberhaupt geht. Ich hab mal ganz schnell durchgekaemmt aber irgendwie hab ich das Gefuehl dass Du Sachen leicht zu Extremen gebracht hast. Ausser niemand interessiert meine Meinung, da kann mir den Spass gleich sparen.

Ich moderiere die refugees zur Zeit, ein paar extra Beruhigungspillen brauch ich zwar ab und zu aber ich kann's ertragen. Wir haben immer noch ab und zu die alten Bekannten wie Sharkfood, SirPauly, EvilEngine, JohnReynolds und eine Menge noch die ich jetzt aus Sparsamkeit nicht erwaehne. Ich hab mich schon gewundert wo zum Henker Du verschwunden bist :)

[Ailuros]

Achtbit,

Obwohl es kein absoluter Massstab fuer Sachen sein sollte, eine ausgezeichnete Lektuere ist:

http://www.3dcenter.de/artikel/cinefx/

Conspiracy theories zur Seite, ATI/NV haben durch den Prozess fuer die dx9.0 Definierung ihre Vorschlaege/Meinungen praesentiert und Microsoft entschied sich fuer die Loesung die ihnen logischer klang (mal ganz vereinfacht).

DX9.0 ist Microsoft's erstes API dass sich wohl ueber mehrere Generationen streckt (2.0, 2.0extended, 3.0) und daher sind jegliche Aesserungen ueber >PS2.0 momentan Spekulation und deshalb landete der Thread hier in diesem Forum.

Wie dem auch sei NVIDIA hat tatsaechlich Architektur-maessig bessere Vorraussetzungen um PS3.0 zu erreichen, aber da fast keiner von uns eine Idee hat was ATI fuer den naechsten Fruehling vorhat und mit was fuer einer Loesung, bleibt noch vieles offen.

Vom ganzen Shader-Wirrwarr mal abgesehen und dem ganzen "future-fool-proof" Schnickschnack, hab ich mir fuer diese Runde eine R300 geschnappt nur aus dem Grund weil IMHO fuer heutige Spiele/Applikationen meine Ansprueche besser decken kann im Durchschnitt unter anderem (wenn nicht hauptsaechlich) Anti-aliasing was bei mir schon immer eine sehr wichtige Rolle gespielt hat.

[Tigerchen]

Die nV'ler sollten nicht vergessen daß das Topteam das den R300 geschaffen hat schon seit einiger Zeit am R500 arbeitet.Alleine diese Tatsache läßt die Behauptung daß nVIDIA auf Grund ihrer Architektur bessere Chancen hat PS/VS 3.0 zu erreichen ziemlich gewagt erscheinen.Oder meint hier etwa jemand ATI ist so blöd und läßt so lange am R500 basteln um dann nur einen aufgebohrten R300 zu präsentieren der bei PS/VS 3.0 genauso alt aussieht wie heute nV mit den Shadern der Versionen 1.4/2.0 ????

[Ailuros]

Original geschrieben von Tigerchen

Die nV'ler sollten nicht vergessen daß das Topteam das den R300 geschaffen hat schon seit einiger Zeit am R500 arbeitet.Alleine diese Tatsache läßt die Behauptung daß nVIDIA auf Grund ihrer Architektur bessere Chancen hat PS/VS 3.0 zu erreichen ziemlich gewagt erscheinen.Oder meint hier etwa jemand ATI ist so blöd und läßt so lange am R500 basteln um dann nur einen aufgebohrten R300 zu präsentieren der bei PS/VS 3.0 genauso alt aussieht wie heute nV mit den Shadern der Versionen 1.4/2.0 ????


Wobei es aber zum kompletten Wiederspruch kommt wenn man die winzige Kleinigkeit in Betracht nimmt dass ATI's naechster Generation's - chip R420 (~Q1 2004) sein wird und R500 nicht vor Ende 2004 oder sogar Anfang 2005 vorgesehen ist.

Ich wuerde es nicht wagen mit Sicherheit zu sagen wie R420 bezueglich dem 3.0 Shader Bereich aussieht, aber von NV3x und R3xx im Vergleich ausgegangen liegt nichts falsches an dieser Behauptung, egal welche Vor- oder Nachteile jede Architektur momentan hat.

Waere PS/VS3.0 nur eine einfache Erhoehung der Anzahl von Anweisungen, dann waere es ein ganz anderes Kapitel.

[Tigerchen]

Original geschrieben von Ailuros
Wobei es aber zum kompletten Wiederspruch kommt wenn man die winzige Kleinigkeit in Betracht nimmt dass ATI's naechster Generation's - chip R420 (~Q1 2004) sein wird und R500 nicht vor Ende 2004 oder sogar Anfang 2005 vorgesehen ist.

Ich wuerde es nicht wagen mit Sicherheit zu sagen wie R420 bezueglich dem 3.0 Shader Bereich aussieht, aber von NV3x und R3xx im Vergleich ausgegangen liegt nichts falsches an dieser Behauptung, egal welche Vor- oder Nachteile jede Architektur momentan hat.

Waere PS/VS3.0 nur eine einfache Erhoehung der Anzahl von Anweisungen, dann waere es ein ganz anderes Kapitel.

nV40/R420 sehe ich nur als Fortführung der bisherigen Linie.
R500 ist NextGen.Und ja 2005.

[LovesuckZ]

Original geschrieben von Tigerchen
[COLOR=darkblue]
Die nV'ler sollten nicht vergessen daß das Topteam das den R300 geschaffen hat schon seit einiger Zeit am R500 arbeitet.Alleine diese Tatsache läßt die Behauptung daß nVIDIA auf Grund ihrer Architektur bessere Chancen hat PS/VS 3.0 zu erreichen ziemlich gewagt erscheinen.

Dann wollen wir für dich nicht hoffen, dass der NV40 PS3.0/VS3.0 hat und der r420 nicht.

[aths]

Original geschrieben von AchtBit
Cheaten tun beide. Allerdings.
Original geschrieben von AchtBit
Wo auch immer die Grenze zwischen Cheat und Optimierung liegt war in der Vergangenheit schon immer ein Streitpunkt.
Wohl gerade desshalb hat nV 3 neue Grundsaetze fuer diese Problematik geschaffen.Welche sie nicht einhalten.
Original geschrieben von AchtBit
In einer Besprechung zw. ATI und nV sind sich beide ueber diese Grundregeln einig geworden. Sprich es wurde das Kriegsbeil begraben und falls irgend eine Form von Optimierung eingesetzt wird, dann nur nachdem
eine Partei der anderen die Methode erlaeutert hat.Hm? Quelle?
Original geschrieben von AchtBit
Differenzen, insbesondere mit FM, gibt es aber bezueglich der letzten Optimierung von nV. Der treiberinterne Shader Optimizer von nV wird zukuenftig die Vertex Shader auf partiale Genauigkeit optimieren, so geschehen im 52.16 Deto. Eine Beinflussung der IQ ist nur unwesentlich bis gar nicht erkennbar.Soweit ich weiß — und anderes habe ich noch nirgendwo nur im Ansatz gelesen — kann der CineFX-Pixelshader mit halber Genauigkeit rechnen. (Präzisierung siehe Folgeposting.) Der Vertexshader nutzt grundsätzlich FP32.
Original geschrieben von AchtBit
Das laesst den Verdacht zu, dass hier einfach der CodePfad ausgetauscht wurde.Du meinst, dass da Shader ausgetauscht wurden?
Original geschrieben von AchtBit
Ist sowas machbar? ja, man wird in Zukunft ziemlich genau unterscheiden koennen welcher Code vertexshaderspezifisch ist und welcher nicht.Hm? Aktuell wird ohnehin explizit zwischen Vertex- und Pixelshader unterschieden.
Original geschrieben von AchtBit
Bei nv variert die Performance und zwar abhaengig von automatisierten Compiler und Optimizer, von der Anstrengung der Entwickler und ob nV,individuelle Optimierung einsetzt.Ist bei ATI im Prinzip auch so. Kannst ja mal im Pixelshader 'nen Sinus über die aritmetische Instruktion rechnen lassen, statt 'n Texture Lookup zu nehmen.
Original geschrieben von AchtBit
Die Lebensdauer ist nicht abzusehen weil das Potenzial nicht erkennbar ist und virtuell auch dx9+ machbar waere. Virtuell? Wie meinst du das? Seit DX8 gibt es interessante Features, die zur Compliance unbedingt in HW unterstützt werden müssen.
Original geschrieben von AchtBit
nV hat einen neuen intensiven Entwicklersupport eroeffnet wo auch auf Fragen betreffend des Compilers/Optimizers eingegangen wird. Diesen Support hat NV schon lange. (Selber nahm ich den noch nicht in Anspruch, aber es gibt Entwickler in diesem Forum, die das taten. Bin selbst kein Entwickler.)

Original geschrieben von AchtBit
Beide arbeiten wieder eng zusammen. Sie kennen die Schwaechen und Staerken ihrer Produkte genau.Beim zweiten stimme ich zu, beim ersten melde ich mal Zweifel an. (Ansonsten bitte die Quelle :))

[aths]

Original geschrieben von AchtBit
Damit nicht wieder solche extemen Unterschiede in der Architekur vorkommen teilt nV jetzt seine Erkenntnisse mit ATI.Woher weißt du das?
Original geschrieben von AchtBit
Es wuerde jedem helfen, wenn nV u. ATI detailierte Datenblatter ihrer Grafikprozessoren veroeffendlichen wuerden.Jo, z.B. auch XGI. Ich glaube nicht, dass das im Sinne von ATI oder NV ist.
Original geschrieben von AchtBit
nv35+

[...]

+ bei sehr hohen Aufloesungen (16x12+) mit voller Qualitaetseinstellung fast immer schneller als der r3x0Hab lange überlegt, wie du das meinst. Eine "Regime shift" bei Auflösungwechsel wäre wohl nur durch eklatante Unterschiede in der Bandbreite zu erklären. Wenn du 4x MSAA vs. 6x MSAA laufen lässt, kann in 1600x1200 der NV35U (bzw. NV38) durchaus schneller sein. Allerdings ist das kein sinniger Vergleich, einfach "volle Qualitätseinstellung" zu sagen, da die resultierende BQ differiert, aber die Framerate verglichen wird. Auch sehe ich alles in allem nicht so recht ein, warum eine Karte die in 1600x1200 schneller ist, in 1024x768 langsamer sein sollte. Da müsste man wohl noch eine CPU-Abhängigkeit der Treiber mit ins Spiel bringen, das würde mir jetzt langsam zu esoterisch. Zudem sind imo die Karten bei wirklich vollen Qualitäts-Einstellungen bei modernen Spielen in 1600x1200 noch nicht schnell genug.
Original geschrieben von AchtBit
r3x0

[...]

- die's@dx10So auch NV35. NV40, 45 werden wohl auch "nur" DX9-Karten sein...
Original geschrieben von AchtBit
So, ich habs so untechnisch wie moeglich geschrieben. Vor allen Dingen ist keine Mutmassung enthalten sondern es sind nur fundamentierte Aussagen. Beim ersten stimme ich zu, beim zweiten nicht.
Original geschrieben von AchtBit
Wenn jemand Fragen dazu hat, soll er diese moeglichst genau spezifizieren. Beginnen wir beim Anfang :)

Inwiefern sollte verringerte Präzision den CineFX VS nützen? Haben die FP16-Rechenwerke, die für full precision zu FP32-Rechnungen zusammen geschaltet werden*? Wie soll ein Optimizer erkennen, ob für Rechnung und Ergebnis FP16-Genauigkeit reichen? Bist du dir bewusst, wie grob FP16 über einen gegebenen Bereich (sagen wir z.B. -0,5 - 0,5, oder auch -1 bis +1) "am Rand" auflöst? (Von 8 Bit mal ganz zu schweigen...)

* Für den Pixelshader, der auch mit FP16 rechen kann ist anzunehmen, dass weiterhin mit FP32 gerechnet wird, aber Eingangs- und Ausgangsregister entsprechend expandiert bzw. zurechtgestutzt werden.

[AchtBit]

@aths,

da das Topic eh zur Spekulation geschoben wurde, habe ich es aufgegeben die Quellen im einzelnen zusammenzusuchen. Kaum hatte ich eine wiedergefunden, war der thread schon vom 100ten ins 1000te gekommen. Dadurch sind Aspekte aufgetaucht, die mit dem eigentlichen Ursprung nicht mehr das geringste zu tun haben.

Ich kann Dir aber die Links posten die in einem wesentlichen Teil den background des Topics ausmachten.

Das ist zum einem

http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A0=DIRECTXDEV&D=0&F=&H=0&I=-3&O=T&S=&T=1

und hier infos auf der Page und vor allen Dingen in den Foren.

http://www.beyound3d.com

Firingsquad hat ab und zu auch mal objektive Berichte zu bieten.

Ach und wenn ich virtuell erwaehnt habe, ist die Abstraktion aus sicht der Applikationsebene gemeint.


Schön, ich gebe zu , dass ich alles nicht richtig durchgelesen habe, aber was soll das beweisen?

das 128MB bei dieser Aufloesung(ohne filter) ungenuegend sind. Die doppelte Speicherbandbreite alleine, wuerde nicht genuegen um damit spielbare Ergebnisse zu bekommen. Es sei denn, man hat nichts dagegen das die Szene ab u. zu hustet(manche moegen das ja scheinbar).
Mein Fall waere es jedenfalls nicht. 256MB, egal ob ATI oder nVidia, waren hinsichtlich der Flux Engine und ihren enorm schnellen Texturememorymanagement fuer mich absolute Pflicht. Die Engine kann damit spitzen Performance, bei gleichzeitig enormen Datenmengen, leisten. Die Engine laesst sich alles andere, nur nicht als schlecht beschreiben.

Wenn eine Tuer Richtung Full Scene Texture Sampling geoeffnet wird, heisst dies bei weitem nicht, es wird in naher Zukunft verwirklicht sein. Vor allem Dingen nicht nach dem aktuellen Stand der Hardware. Texture Mapping wird noch eine ganze Weile die Szene beherrschen.


@zeckensack, ich kann Dir genau verraten weshalb wir auf keinem gemeinsamen Nenner kommen koennen. Du redest in M$ Begriffen, die auf der HW-ebene nicht existend sind. Ich unterscheide aber Begriffe nach ihrer Bedeutung auf der HW-Ebene. Wenn ich aus Sicht des virtuellen System von M$ spreche, andert das auch nichts daran. Irgendwann vererbt man sonst irgendwelche M$ Begriffe und ohne es zu merken frisst man aus der Hand von M$.

So betrifft es die API welche laengst weit mehr als ein Treiber ist. Es ist ehr eine Geraeteklasse die vererbbare Objekte mit unterschiedliche Funktionen einschliesst. Weit entfernt von einem Geraetetreiber.

Fuer die Entwickler hab ich hier was nettes. Eine hervorragene Diplomarbeit die Realtimeshading detailiert beschreibt sowie Konzepte aufzeigt, die die Moeglichkeiten aktueller HW an Flexibilitaet, weit uebersteigt. Wohl aber fuer zukunftiges Full Scene Shading Voraussetzung sein wird. Die Arbeit enstand im Okt. letzten Jahres also bevor M$'s HLSL. Der Inhalt ist aber alles andere als veraltet.

http://www.8bit.de/realtime_shader.pdf (2.2MB)


@Ail,
wow, Du hast aber fleissig geuebt. :o
Teilweise bessere Grammatik als beim mir :flöt:
Damals war ich nach dem Praktikum ein paar Monate offline und als ich dann in die Entwicklung gewechselt hab, blieb mir keine Zeit mehr die letzten Slacks zu verfolgen. Hab dann das Hartwareboard entdeckt, da konnte ich ziwschendurch auch mal nativ posten. Englische Foren, ausser die Dev Newsgroubs, hatte ich nur zum lesen besucht.

Den Artikel ueber CineFX kannte ich schon. :)

Ich kann Dir auch das PDF empfehlen, damit schaffts Du jede Doktorarbeit. ;)

... und ausserdem IMMER AGP-Texturing verwendet, ganz egal, wieviel V-Memory Du hast ...

AGP Texturing ist IMMER IMMER aktiv wenn der Bus der Master ist. Der Speicher wird linear gelesen und der AGP Texture Speicher ist immer Topmemory und es wird nur dann darauf zugegriffen, wenn die Speicherbandbreite das Limit des tatsaechlichen Speicher ueberschreitet.

[aths]

Original geschrieben von AchtBit
@aths,

da das Topic eh zur Spekulation geschoben wurde, habe ich es aufgegeben die Quellen im einzelnen zusammenzusuchen. Hast du es auch aufgeben, mein Posting im einzelnen zu beantworten? :-(*

Original geschrieben von AchtBit
Ich kann Dir aber die Links posten die in einem wesentlichen Teil den background des Topics ausmachten.

Das ist zum einem

http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A0=DIRECTXDEV&D=0&F=&H=0&I=-3&O=T&S=&T=1

und hier infos auf der Page und vor allen Dingen in den Foren.

http://www.beyound3d.comDu meinst vermutlich, www.beyond3d.com :) Ist in meiner Webride-Standardliste. Was das Forum angeht, dort werden oftmal Vermutungen und Spekulationen gewälzt, nicht alle Details kann man gleich für bare Münze sind, auch wenn sie von Dave persönlich stammen. (Trifft natürlich auch auf das 3dc-Forum zu.)

* Sorry für die harten Worte, doch einerseits emulierst du hier den Sachverständigen, auf der anderen Seite bringst du imo schon Grundbegriffe durcheinander. (16 bzw. 8 Bit reichten in bestimmten Fällen für den Pixelshader, jedoch nicht für den Vertexshader, in der Tat "optimiert" NV vermutlich ungefragt am PS rum.) Ich wäre ja froh, wenn sich jemand gegen die quasi etablierte 3DC-"Guru"**-Front stellt, doch bitte würde ich dann mehr lesen als nur Behauptungen und allgemeine Links.

** Ist witzig gemeint.

[Aquaschaf]

Ich will ja nicht flamen, aber ich habe noch niemanden erlebt der eine so unsinnige Argumentation von etwas, was er kein bischen zu verstehen scheint führt, es dann noch schafft Gegenargumente geschickt zu überlesen und trotzdem anderen vorzuwerfen sie würden keine Einsicht zeigen. Wenn keiner mit dir auf einen gemeinsamen Nenner kommt liegt es einfach daran, dass praktisch nichts von dem was du schreibst stimmt.

[Aquaschaf]

Doppelpost ???

[Quasar]

:massa: :massa:

Bitte bitte macht weiter!

Selten in der letzten Zeit habe ich so einen offenbarenden Thread gelesen. :up:

[AchtBit]

@aths,

ich geb keine detailierten Anworten mehr, weil ichs einfach satt bin, dass es sofort in einem Flame, der jeden weiteren thread embaert, ausartet.

Ich klaer das Missverstaendnis mit dem Vs, der laufend auftaucht aber nicht zu dem passt was ich darunter verstand. VS u. PS sind nV Begriffe fuer Prozessoreinheiten, die ich nur unter dem Namen Fliesskommaeinheit(FPU) und Geometrieeinheit krenne. Ich dachte erst VS ist der Begriff fuer die FPU, jetzt weis ich dass damit aquivalent der Geometrieprozessor gemeint ist PS die FPU darstellt. Bei alle spaeteren Postings betreffend des VS hab ich irgendwie nichtmehr geantwortet weil ich im Inhalt keine Zusammenhang sah. Ich habs dann schon geschnallt dass es andersherum ist aber hab auch keine Lust mehr gehabt, ein Missverstaendnis von der ersten Seite aufzugreifen und zu erlaeutern. Irgendwo sagte ich dann schon mal, dass ich was anderes gemeint hatte. Hat nicht viel gebrach. Der VS hat mich laufend wieder eingeholt. Ich hoffe dass es jetzt endgueltig geklaert ist. ;)

edit:
>>Du meinst vermutlich, www.beyond3d.com Ist in meiner Webride-Standardliste. Was das Forum angeht, dort werden oftmal Vermutungen und Spekulationen gewälzt, nicht alle Details kann man gleich für bare Münze sind, auch wenn sie von Dave persönlich stammen. (Trifft natürlich auch auf das 3dc-Forum zu.)<<

Ich weis, ich rede von den Topics, wo z.B. aufgeloest wurde, dass der HLSL Compiler, nvidia typische Makro Instruktionen faelschlicherweise in einzelne Instruktionen zerlegt, was natuerlich Performance kostet.
Mehre Versuche mit dem Compiler haben dies bestaetigt. Kurz darauf wurde es auch offiziell seitens M$ als Compiler Bug veroeffendlicht.

Diese Topics mein ich. ;) Beginnt auf der Startseite mit dem Interview der beiden Valve Fuzzis bezueglich FX in HL2

[Tigerchen]

Original geschrieben von LovesuckZ
Dann wollen wir für dich nicht hoffen, dass der NV40 PS3.0/VS3.0 hat und der r420 nicht.

Warum?
Wenn der nV40 meinem Anforderungsprofil voll entspricht dann wechsel ich wieder zu nVidia.So einfach ist dass.Nur rechnet selbst Richthofen nicht mit einem revolutionären Entwurf beim dynamischen Duo nV/ATI.

[LovesuckZ]

Original geschrieben von Tigerchen

Warum?
Wenn der nV40 meinem Anforderungsprofil voll entspricht dann wechsel ich wieder zu nVidia.So einfach ist dass.Nur rechnet selbst Richthofen nicht mit einem revolutionären Entwurf beim dynamischen Duo nV/ATI.


Anscheinend schreiben unter deinem Account 2 verschiedene Leute.
Denn das was du jetzt schreibst, steht in keinem Zusammenhang mit dem von mir zitierten Teil und meinen Text...

[aths]

Original geschrieben von AchtBit
@aths,

ich geb keine detailierten Anworten mehr, weil ichs einfach satt bin, dass es sofort in einem Flame, der jeden weiteren thread embaert, ausartet.Flames kannst du per Button melden, wir Mods kümmern uns dann darum :)

Zur Not kannst du die Antwort auch als PM oder Mail senden :)



Ansonsten dünkt mir, dass du dich etwas in Details verrennst, ohne eine mit uns "kompatible" Gesamtübersicht (inkl. der Fachbegriffe) zu haben.

[Piffan]

Meld! Ich habe geflamt! "Beschämt zu Boden schau....."

[aths]

Ich kann AchtBits Unmut verstehen, dass sein Thread teilweise zugemüllt wurde. Imo hat er da durchaus Mitschuld, da sein initiales Posting für den gebotenen Inhalt reichlich arrogant rüberkam (jedenfalls für meine Begriffe.) Trotzdem sollte es noch möglich sein, unbeachtet von einigen Fanatikern, bestimmte Vorteile der FXen zu diskutieren.


AchtBit, auch in anderen Threads fällt mir auf, dass du Jargon-mäßig irgendwie in einer anderen Welt zu leben scheinst. Du verwendest Begriffe oft anders, als "in der Szene" gebräuchlich. Kommen dann Belehrungen von dir, was die Termini wirklich bedeuten, wirkt das wenig der Diskussion zuträglich. Zum Beispiel hat zeckensack Programme anzubieten, die beweisen, dass er versteht wovon er spricht, während wir von dir bislang nichts weiter kennen.

Darf man fragen, welches Fach du studierst (bzw. studiert hast) und wie dein "Werdegang" im Bereich 3D-Technik ist? Vielleicht könnte man dann einige Verständigungsprobleme aus der Welt räumen.

[MikBach]

Original geschrieben von aths
Ich kann AchtBits Unmut verstehen, dass sein Thread teilweise zugemüllt wurde. Imo hat er da durchaus Mitschuld, da sein initiales Posting für den gebotenen Inhalt reichlich arrogant rüberkam (jedenfalls für meine Begriffe.) Trotzdem sollte es noch möglich sein, unbeachtet von einigen Fanatikern, bestimmte Vorteile der FXen zu diskutieren.


Ich kann seine Unmut auch verstehen, aber wenn man so provokative Behauptungen in den Raum stellt, na ja.

Werden die Vorteile der FXen immer nur Theorie bleiben, oder wird man auch in der Praxis was davon merken?

[aths]

Original geschrieben von MikBach
Werden die Vorteile der FXen immer nur Theorie bleiben, oder wird man auch in der Praxis was davon merken? Zunächst kann man diese Diskussion ja auf rein theoretischer Ebene führen. Mir scheint als hätten einige Radeon-Freaks quasi Angst, dass Nvidias Ansatz zu gut dastünde. Das kann dem einzelnen doch eigentlich egal sein, oder? Wichtig ist in theoretischen Diskussionen erst mal, dass man die gleiche Sprache spricht.

[LovesuckZ]

Original geschrieben von MikBach
Werden die Vorteile der FXen immer nur Theorie bleiben, oder wird man auch in der Praxis was davon merken?

Nein, siehe Halo :)

[MikBach]

Original geschrieben von aths
Zunächst kann man diese Diskussion ja auf rein theoretischer Ebene führen. Mir scheint als hätten einige Radeon-Freaks quasi Angst, dass Nvidias Ansatz zu gut dastünde. Das kann dem einzelnen doch eigentlich egal sein, oder? Wichtig ist in theoretischen Diskussionen erst mal, dass man die gleiche Sprache spricht.

Ich bin erst mal kein ATI-fan und auch nicht richtig Gamer.
Ich baue halt für paar Kumpels, die Gamer sind, die Rechner zusammen.
Vor Weihnachten ist immer ein grosser Ansturm bei mir, und alle wollen wissen, WAS?
Vor einem Jahr war die Antwort wesentlich leichter. Aber heute bei den ganzen Spekulationen weiss man selber nicht mehr, zu was man raten soll.
Die ersten Tests(DX9 Benchmarks, Spiele, halb fertige Spiele) laufen auf ATI viel besser.
Nun behauptet aber die Gegenseite, dass Nvidia besser ist. Worauf stützen sich die Aussagen der Nvidia-fans.

[MikBach]

Original geschrieben von LovesuckZ
Nein, siehe Halo :)

Wie bitte?

Das soll der Vorteil von NVidia sein?
Wenn Du Gleichstand mit Vorteil verbindest, dann muss Nvidia einem ja richtig leid tun.

[LovesuckZ]

Original geschrieben von MikBach
Wie bitte?
Das soll der Vorteil von NVidia sein?
Wenn Du Gleichstand mit Vorteil verbindest, dann muss Nvidia einem ja richtig leid tun.

Schade, anscheinend bist du dir über die technischen Unterschiede zwischen der FX und r3x0 Architektur nicht im klaren.
Aber ey, einen Fanatiker mehr in unseren reihen bringt das Forum ja nicht zum völligen abstuerz...

[aths]

Original geschrieben von MikBach
Nun behauptet aber die Gegenseite, dass Nvidia besser ist. Worauf stützen sich die Aussagen der Nvidia-fans. Natürlich behaupten sie das. Je nach den Settings können sie das auch belegen. Insgesamt laufen DX9-Shader nutzende Anwendungen, die dieses und nächstes Jahr heraus kommen, wohl "besser" (also schneller) auf R3xx als auf NV3x. Es gibt einige Spiele mit sehr großen Unterschieden, es gibt Spiele mit marginalen Unterschieden. Ist doch toll, dass ATIs Dominanz nicht allumfassend ist :) So müssen sich die Kanadier ins Zeug legen.

[MikBach]

Original geschrieben von LovesuckZ
Aber ey, einen Fanatiker mehr in unseren reihen bringt das Forum ja nicht zum völligen abstuerz...

Siehe mein post.

Meine 2 Rechner:

1. Duron 1400, R9100, 512MB

2. Duron 800, GF2, 512MB


Schade, anscheinend bist du dir über die technischen Unterschiede zwischen der FX und r3x0 Architektur nicht im klaren.

Nicht wirklich, mich interessiert halt nur, welche Hardware ich atm empfehlen kann.

[Aquaschaf]

Original geschrieben von MikBach
Ich kann seine Unmut auch verstehen, aber wenn man so provokative Behauptungen in den Raum stellt, na ja.

Werden die Vorteile der FXen immer nur Theorie bleiben, oder wird man auch in der Praxis was davon merken?

Es geht ja nicht um die Provokation des Initialpostings, sondern eher um das viele Falsche was darin steht und die recht arroganten Reaktionen auf Korrektur.

[StefanV]

Original geschrieben von MikBach
Nicht wirklich, mich interessiert halt nur, welche Hardware ich atm empfehlen kann.

Im großen und ganzen liegst du mit ATI eigentlich immer richtig, wobei die Kühler ev. recht anfällig sind.

Genau 'beweisen' kann ichs allerdings nicht, da ich momentan 'nur' eine FX5800 habe und die Anschaffung einer FX5900 nicht geplant ist.

Auf der ATI Seite besitze ich momentan auf der 'High End Schiene' eine Radeon 9800 PRO...

[MikBach]

Original geschrieben von aths
Insgesamt laufen DX9-Shader nutzende Anwendungen, die dieses und nächstes Jahr heraus kommen, wohl "besser" (also schneller) auf R3xx als auf NV3x. Es gibt einige Spiele mit sehr großen Unterschieden, es gibt Spiele mit marginalen Unterschieden. Ist doch toll, dass ATIs Dominanz nicht allumfassend ist :) So müssen sich die Kanadier ins Zeug legen.

Danke ich plane nur für ein Jahr.

[Piffan]

Wenn ich nicht völlig danebenliege, dann schafft NV einen Gleichstand, wenn die Shader mundgerecht serviert werden, soll heißen, auf die Besonderheiten der CineFX- Architektur sehr genau eingegangen wird.....

Ati hingegen ist auf extra- Würste nicht so stark angewiesen...dadurch sind nicht so heftige Einbrüche zu erwarten, sondern eher ne ausgeglichene Performance über alle Spiele weg....

Also: WEnn NV vorne liegt, dann eher knapp. Wenn NV einbricht, dann gründlich.....

Was auch alarmieren sollte: Kaum stellt Future mal was am 3d- Mark um, bricht NV schlimm ein. Egal woran das nun genau liegt, es belegt immerhin die These, dass NV entweder ne Extra- Wurst braucht oder die Progger bei NV treiberseitig kräftig nacharbeiten müssen....

Absolut ins Bild passt da auch, dass gewisse Mags/Seiten immer auf den Standardbenches rumreiten, wenn man die NV- Überlegenheit rausstellen will....das sagt doch alles...

Was nützt die tollste Programmierbarkeit der CineFX, wenn ich als Spieler davon nullkommanüschts habe. Der Verweis auf die Zukunft zieht nicht, gespielt wird mit den aktuellen Games....aber falls J. C. richtig zitiert wurde, dann hat er auch gesagt, dass die aktuellen NV- Chips entweder ne schlechtere Bildqualität liefern oder in der Geschwindigkeit stark verlieren...

edit: ....falls eine Engine von Pixelshadern nach DX9 ausgiebig Gebrauch macht....

[MikBach]

Original geschrieben von Piffan
Wenn ich nicht völlig danebenliege, dann schafft NV einen Gleichstand, wenn die Shader mundgerecht serviert werden, soll heißen, auf die Besonderheiten der CineFX- Architektur sehr genau eingegangen wird.....

Ati hingegen ist auf extra- Würste nicht so stark angewiesen...dadurch sind nicht so heftige Einbrüche zu erwarten, sondern eher ne ausgeglichene Performance über alle Spiele weg....
Das sehe ich nach den bisherigen "Erfahrungen" auch so.

Original geschrieben von Piffan
Was auch alarmieren sollte: Kaum stellt Future mal was am 3d- Mark um, bricht NV schlimm ein. Egal woran das nun genau liegt, es belegt immerhin die These, dass NV entweder ne Extra- Wurst braucht oder die Progger bei NV treiberseitig kräftig nacharbeiten müssen....
Hatten wir schon, 3dmark2003 patch 340...


Was nützt die tollste Programmierbarkeit der CineFX, wenn ich als Spieler davon nullkommanüschts habe...

Das ist für mich das Entscheidende, die Praxis.

Der Verweis auf die Zukunft zieht nicht, gespielt wird mit den aktuellen Games....aber falls J. C. richtig zitiert wurde, dann hat er auch gesagt, dass die aktuellen NV- Chips entweder ne schlechtere Bildqualität liefern oder in der Geschwindigkeit stark verlieren...

edit: ....falls eine Engine von Pixelshadern nach DX9 ausgiebig Gebrauch macht....

JC hat gesagt, dass Beide etwa gleich sind in der Performance. Nur braucht der NV einen speziellen Pfad.reduzierte Gebauigkeit usw.
http://www.pcgames.de/?article_id=224260

[zeckensack]

Original geschrieben von AchtBit
@zeckensack, ich kann Dir genau verraten weshalb wir auf keinem gemeinsamen Nenner kommen koennen. Du redest in M$ Begriffen, die auf der HW-ebene nicht existend sind. Ich unterscheide aber Begriffe nach ihrer Bedeutung auf der HW-Ebene. Wenn ich aus Sicht des virtuellen System von M$ spreche, andert das auch nichts daran. Irgendwann vererbt man sonst irgendwelche M$ Begriffe und ohne es zu merken frisst man aus der Hand von M$.Wenn du wüßtest ... :naughty:
Da du ja anscheinend die B3D-Foren liest, empfehle ich dir diesen Thread (http://www.beyond3d.com/forum/viewtopic.php?t=8589). Qualifiziert sich fast schon als Flamewar, ist auch sehr lang, aber IMO recht fruchtbar. Und vor allem kannst du dort auch nachlesen, was ich von MS'schem API-Design halte (Hint: nichts).
So betrifft es die API welche laengst weit mehr als ein Treiber ist. Es ist ehr eine Geraeteklasse die vererbbare Objekte mit unterschiedliche Funktionen einschliesst. Weit entfernt von einem Geraetetreiber.Das weiß ich wohl. Das ändert nichts an der Tatsache, daß man Grafik-HW eben nur über APIs sinnvoll ansprechen kann (wobei selbst der Thunk Layer von DXG - der Byte-Code-Strom, der letztendlich vom Treiber verarbeitet wird - eine solche API darstellt, wenn auch brutal schlecht dokumentiert und unhandlich).

Die Begriffe für die HW-Einheiten habe ich mir auch nicht ausgedacht, sondern es sind die gleichen Begriffe, die auch die Hersteller verwenden. "Vertex Shader" sagen sie eigentlich alle. Beim pixel shading (:=Operationen zwischen Trisetup/Interpolation und ROP) spricht NV ab NV10 von "register combiners" und "texture shader", ab NV30 von "shader core" (da fehlen dann aber noch ein paar Teile), ATI nennt das ganze ab R200 salopp "pixel shading unit". Davor waren die meisten damit zufrieden, diesen Teil der Pipeline "Combiner" zu nennen.
*schulterzuck*

Diese Begriffe sind sicher nicht falsch. Natürlich beschreiben sie eher die Funktion, und nicht den Aufbau, aber das ist bei hochspezialisierter HW auch erwünscht. "FPU" zB, wie von dir verwendet, ist dafür nicht präzise genug (kann sowohl VS als auch PS sein, wird allerdings idR als Teil der Host-CPU verstanden).


Und am aller wichtigsten: man kann die IHVs sowieso nicht darauf festnageln. Eben weil man an die Hardware nur über Abstraktion herankommt, haben sie weitgehend freie Hand bei der Implementierung. Sieht man ja auch an NV30 vs R300.
Die Struktur kann in zwei Jahren schon wieder ganz anders sein, ebenso wie die Struktur jetzt ganz anders ist als vor zwei Jahren.
(abgesehen von relativ feststehenden Kleinigkeiten wie dem Trisetup)

Fuer die Entwickler hab ich hier was nettes. Eine hervorragene Diplomarbeit die Realtimeshading detailiert beschreibt sowie Konzepte aufzeigt, die die Moeglichkeiten aktueller HW an Flexibilitaet, weit uebersteigt. Wohl aber fuer zukunftiges Full Scene Shading Voraussetzung sein wird. Die Arbeit enstand im Okt. letzten Jahres also bevor M$'s HLSL. Der Inhalt ist aber alles andere als veraltet.

http://www.8bit.de/realtime_shader.pdf (2.2MB)
Ich hab's überflogen. Nimm's mir nicht übel, aber ich glaube nicht daß ich aus dem PDF noch etwas neues lernen kann.
Auffällig ist der Anteil an abgeschriebenem Marketing-Material, was natürlich durch die Anforderungen einer solchen Arbeit (Präsentation, Menge) zu rechtfertigen ist.


edit:
Anstatt einfach zu behaupten, ich könnte was oder wüßte was, lasse ich mal zwei Fetzen Code sprechen.
1)Mein 'Shader-Compiler' bei der Arbeit:!!ARBfp1.0
OPTION ARB_precision_hint_fastest;
TEMP ccom_tmp;
TEMP chroma_tmp;
TEMP tcom_out;
TXP tcom_out,fragment.texcoord[0],texture[0],2D;
SUB chroma_tmp,tcom_out,program.env[1];
ABS chroma_tmp,chroma_tmp;
DP3 chroma_tmp,chroma_tmp,1.0;
SUB chroma_tmp.rgb,chroma_tmp,program.env[3].b;
KIL chroma_tmp;
MUL ccom_tmp.rgb,fragment.color,tcom_out;
MOV result.color.a,program_env[0].a;
MUL ccom_tmp.a,fragment.fogcoord.x,program.env[3].g;
LRP result.color.rgb,ccom_tmp.a,program.env[2],ccom_tmp;
END

2)Ein Klick der sich lohnt (http://www.forum-3dcenter.org/vbulletin/showthread.php?threadid=77975)

[AchtBit]

Ich kann AchtBits Unmut verstehen, dass sein Thread teilweise zugemüllt wurde. Imo hat er da durchaus Mitschuld, da sein initiales Posting für den gebotenen Inhalt reichlich arrogant rüberkam (jedenfalls für meine Begriffe.)

Das widerum, kann ich verstehen, denn Du weist sicher nicht, dass mein initiales Posting, aufgrund eines anderen Threads endstanden ist. Weis nur nimmer welcher.
Auf jeden fall wollte jemand wissen welche Graka besser ist. Ich hab da gepostet, dass man vom preislichen Verhaeltnis her auf jeden fall auch eine fx5900 oder hoeher in betracht ziehen kann.
War wohl ein grosser Fehler, denn das hat sofort einen Flame entfacht, der jeder vernuenftigen Erklaerung widersprach. Das Topic von mir, ist nur im weitere Verlauf dazu entstanden. Allein gelesen klingts wohl ehr gleich dem Elefant im Porzellanladen.

@Zeckensack, mit der Aussage FPU waere nicht praeziese liegst Du falsch. Der Begriff ist exakt.

PS entspricht equivalent einer FPU
VS enspricht equivalent einer ALU
Beide Einheiten zusammen bilden den mathematischen Coprozessor, welcher equivalent einem Geometrieprozessor entspricht.

Copros wurden fueher auch seperat von der Integereinheit eingesetzt und sind jetzt noch auf HiEnd Grafikkarten seperat bzw. asyncron realisiert. Unterschiede existieren nur in der Integereinheit.

Ich nehm an Nv hat andere Begriffe verwendet um fuer ihre PR Zwecke eine bessere Vorstellung der spezifischen Funktionen zu veranschaulichen. Wie so bei vielen anderen Teileinheiten auf einer Grafikkarte auch.

Das ändert nichts an der Tatsache, daß man Grafik-HW eben nur über APIs sinnvoll ansprechen kann

Das kling fast als ob Du alles andere als unmoeglich ansiehst.
Was sagst Du wenn ein Vendor es schaffen sollte, die HW so zu programmieren, dass sie sich waerend der Laufzeit von dem Interface entkoppeln liesse? Auf jedenfall wuerde M$ alles tun sich dem zu widersetzen.

@piffan,

wenn Du JC zitieren kannst, dass solltest Du eigentlich wissen, dass er von dem Konzept ueberzeugt ist.

Das mit den Shader ist schon richtig. Es bezieht sich aber nur auf den sichtbaren Bereich eines mit PS gesampelten Effektes und nicht auf die Qualitaet des Bildes. Zumindest wenn die PS optimal einsetzbar sind

[Aquaschaf]

PS und VS zusammen sind doch kein Geometrieprozessor.
Und wie Zeckensack schon gesagt hat, der Begriff FPU kann vieles heißen und wird eigentlich als Bezeichnung für den Teil einer CPU verwendet. Floating Point Unit ist eben alles andere als eine exakte Bezeichnung für einen VS oder PS.

[AchtBit]

PS und VS zusammen sind doch kein Geometrieprozessor.

Das ist wahr. Was aber nichts mit einem Unterschied des Prinzipes zu tun hat, sondern lediglich an dem noch primitiven statischen Aufbau liegt.

[StefanV]

Original geschrieben von Aquaschaf
PS und VS zusammen sind doch kein Geometrieprozessor.
Und wie Zeckensack schon gesagt hat, der Begriff FPU kann vieles heißen und wird eigentlich als Bezeichnung für den Teil einer CPU verwendet. Floating Point Unit ist eben alles andere als eine exakte Bezeichnung für einen VS oder PS.

Richtig, der VS ohne PS wäre nämlich schon der 'Geometrieprozessor', der PS-Teil wäre dementsprechend der Pixelprozessor.

@AchtBit

Ich weiß nicht, wo du das mit FPU und ALU aufgeschnappt hat, hier in diesem Forum weiß niemand, außer du, was du eigentlich sagen willst.
Es wäre schön, wenn du dich der Mehrheit anpassen würdest, was die Begriffe betrifft...

[Tigerchen]

Original geschrieben von LovesuckZ
Anscheinend schreiben unter deinem Account 2 verschiedene Leute.
Denn das was du jetzt schreibst, steht in keinem Zusammenhang mit dem von mir zitierten Teil und meinen Text...
Dein Orginaltext:
Dann wollen wir für dich nicht hoffen, dass der NV40 PS3.0/VS3.0 hat und der r420 nicht.


Versuch doch wenigstens mal meine Sichtweise zu verstehen.Wenn der NV40 PS/VS 3.0 hat und diese auch brauchbar sind und mir einen echten Vorteil in Games der nächsten 12 Monate verschaffen dann wechsel ich sofort zu nVIDIA.

.....wollen wir für dich nicht hoffen

Mir ist das doch völlig egal ob ATI das jetzt schafft oder nicht.Ich hab halt im Moment das Gefühl daß sie das packen.Wenn nicht dann eben nicht.

[LovesuckZ]

Original geschrieben von Tigerchen
[COLOR=darkblue]
Versuch doch wenigstens mal meine Sichtweise zu verstehen.

Das habe ich. Nur zur Errinerung dein Text:

Die nV'ler sollten nicht vergessen daß das Topteam das den R300 geschaffen hat schon seit einiger Zeit am R500 arbeitet.Alleine diese Tatsache läßt die Behauptung daß nVIDIA auf Grund ihrer Architektur bessere Chancen hat PS/VS 3.0 zu erreichen ziemlich gewagt erscheinen..

Du redest hier vom Frühjahrschip 2005. Und deswegen meine etwas böswillige Bemerkung.

[AchtBit]

Richtig, der VS ohne PS wäre nämlich schon der 'Geometrieprozessor', der PS-Teil wäre dementsprechend der Pixelprozessor.

Geometrie bezeichnet die Gesetzmaessigkeit und Beziehung an o. zwischen irgendwelchen sichtbaren Linien,Koerbern etc. Denk doch mal nach, unter diesem Begriff sind beide Einheiten eingeordnet.

ALU heisst Arthimetic and Logical Unit. Ein VS kann logische und arthimetische Operartionen durchfuehren.

Und ich sagte ja, ich muss erst mal die Begriffe von nV ihrer mathematische Funktion nach zuordnen um auch den richtigen Schluss daraus ziehen zu koennen.

[aths]

Original geschrieben von AchtBit
Das widerum, kann ich verstehen, denn Du weist sicher nicht, dass mein initiales Posting, aufgrund eines anderen Threads endstanden ist.Doch, dort hast du dich ziemlich hochnäsig über das Wissen anderer geäußert und einen Artikel angekündigt. (http://www.forum-3dcenter.org/vbulletin/showthread.php?postid=1355626#post1355626)

Original geschrieben von AchtBit
Allein gelesen klingts wohl ehr gleich dem Elefant im Porzellanladen.Auch deine Folgepostings wirken so auf mich.

Original geschrieben von AchtBit
@Zeckensack, mit der Aussage FPU waere nicht praeziese liegst Du falsch. Der Begriff ist exakt.Wenn man zeckensack korrigieren will, sollte man gute Argumente haben. Zeckensack gehört zu denen, die das "Guru" nicht nur im Titel tragen (wie z.B. bei mir der Fall. Ich bin ein Schreiberling, der gerne zuhört und hin und wieder das aufgeschnappte in einen Artikel packt.) Er ist aktiv, also liest nicht nur auf beyond3d, sondern programmiert auch selbst, und hat Kontakt mit anderen die sich damit beschäftigen. Will sagen, wenn Zeckensack einen Begriff verwendet, ist es sehr wahrscheinlich, dass er ihn richtig verwendet.

Original geschrieben von AchtBit
PS entspricht equivalent einer FPU
VS enspricht equivalent einer ALUKein Mensch sagt FPU, wenn er den Pixelshader meint, oder ALU, wenn er den Vertex Shader meint.

[Endorphine]

Die Vergleiche von VS = CPU im engeren Sinne (Integer) und PS = FPU (Gleitkomma) sind nun wirklich, sorry, Unfug. Eine GPU ist ein extrem applikationsspezifischer hochoptimierter ASIC und gleichzeitig ein Coprozessor zur CPU.

Was bringt dieser Vergleich überhaupt? Nur weil GPUs zunehmend flexibler werden will mir nicht in den Kopf, wieso man diesen Trend als Anlass nehmen will, VS/PS mit Integer- und Gleitkommaeinheiten zu vergleichen oder gar gleich zu setzen.

Kann man Tomaten auch mit Kürbissen vergleichen, nur weil diese durch Überzüchtung und genetische Modifikation immer grösser werden? Was gewinnt man durch diesen Vergleich? Wozu führt das überhaupt?

p.s. @ aths: niemand muss studiert haben, um hier mitreden zu können. Findest du es nicht unfair, jemandem förmlich die Achtung absprechen zu wollen, in dem du ihn fragst, was er studiert hat? Das ist IMHO ziemlich anmaßend. So las sich dein Posting zumindest für mich.

[MadManniMan]

Original geschrieben von Quasar
:massa: :massa:

Bitte bitte macht weiter!

:wink: Hey Q, kann dir nur vollstens zustimmen...

Ich dachte, ich mach nur mal ne kurze Zockpause, aber ich bin grad derart gefesselt... - herrlich!

:bigl:

[del_4901]

mhm, also 8bit ist nicht der einzigste mit gefährlichem Halbwissen. (Die, die sich angesprochen fühlen, wissen selber am besten wiso)

so und jetzt nochmal zum VS / PS ALU / FPU Debakel.

Wenn dann würde ich den VS noch mit ISSE vergleichen wollen, selbst dieser Vergleich hinkt, aber keinesfalls mit einer ALU, denn die Alu rechnet immernoch mit int. Weil sich da die Mathematischen Recheneinheiten für die Logischen Operationen "wiederverwenden" lassen. das geht zwar auch mit FP. das währe aber nicht im Sinne des "CPU-Entwicklers". Transistorcount... Ausserdem kann die ALU, genau wie die FPU beliebig lange Programme verarbeiten. VS und PS sind hier immernoch stark eingeschränkt, vielleicht haben wir ja in der Zukunft eine CPU-Artige Architektur auf Grakas, aber davon sind wir noch ein bissel weit entfernt.

Und korrigiert mich wenn ich mich irre, aber kann der Fragmentprozessor (PS) nicht auch Logische Operationen durchführen? Sonnst könnte ich doch keine Bedingungen prüfen öder?

Nach längerem Überlegen bin ich zu dem Schluss gekommen, das weder Fragment- noch Vertex-Prozessor logische Operationen beherschen. (man kann das zwar über mathematische Operationen beschreiben, aber die Hardware besitzt keine eigenen "Bool-Einheiten") Und wenn doch dann nur in sehr abgespeckter Form für Bedingungsprüfung vor Sprüngen/Iterationen.

Ich danke hiermit bei der allgemeinen Verwirrung beigetragen zu haben. *Kopfschmerzen hab*

[Xmas]

Original geschrieben von AchtBit
@Zeckensack, mit der Aussage FPU waere nicht praeziese liegst Du falsch. Der Begriff ist exakt.

PS entspricht equivalent einer FPU
VS enspricht equivalent einer ALU
Beide Einheiten zusammen bilden den mathematischen Coprozessor, welcher equivalent einem Geometrieprozessor entspricht.

Beides, sowohl PS als auch VS, ist bei DX9-Chips eine FPU, also eine "Floating Point Unit", und keine ALU, denn logische Befehle (AND, OR, XOR) kennen sie nicht. Die beiden unterscheiden sich dadurch, was sie tun, nicht was sie sind

Um mal auf die Diplomarbeit, die du verlinkt hast, einzugehen, da wird das eine als Vertex Processing Unit (VPU) und das andere als Fragment Processing Unit (FPU) bezeichnet. Das ist eigentlich nicht falsch. Aber FPU und VPU sind schon belegt. VPU ist ein Marketing-Term von 3Dlabs, "Visual Processing Unit", der auch von ATI übernommen wurde. Und FPU ist schon seit Jahrzehnten die "Floating Point Unit".

Wenn man über ein Thema diskutieren will, dann ist es schon hilfreich, wenn man sich die übliche Terminologie aneignet. Und üblich ist eben VS oder "Vertex Shader" für den Teil des Chips, der Berechnungen pro Vertex ausführt, und PS, "Pixel Shader" oder auch "Fragment Shader" für den Teil des Chips, der Berechnungen pro Pixel ausführt. Ob dir das gefällt oder nicht, das sind die üblichen Bezeichnungen. Wenn du andere Bezeichnungen verwenden willst, steht dir das frei. Aber dann musst du sie vorher klar definieren.

[StefanV]

Original geschrieben von Endorphine
p.s. @ aths: niemand muss studiert haben, um hier mitreden zu können. Findest du es nicht unfair, jemandem förmlich die Achtung absprechen zu wollen, in dem du ihn fragst, was er studiert hat? Das ist IMHO ziemlich anmaßend. So las sich dein Posting zumindest für mich.

Nö, find ich nicht, zumal aths nie erwähnte, daß jemand studiert haben muss...

Lies dir nochmal alle Postings durch, dann wirst ev. drauf kommen, WIE aths es meinte...

[ShadowXX]

Original geschrieben von Endorphine
p.s. @ aths: niemand muss studiert haben, um hier mitreden zu können. Findest du es nicht unfair, jemandem förmlich die Achtung absprechen zu wollen, in dem du ihn fragst, was er studiert hat? Das ist IMHO ziemlich anmaßend. So las sich dein Posting zumindest für mich.

Ich glaube kaum das aths das so gemeint hat....AchtBit hat von sich selber gesagt, dass er Informatik studiert...

Und aths wollte halt seine Spezialisierung wissen....

Ich glaube das AchtBit sich insgesamt seeeehr stark auf die von Ihm verlinkte Doktorarbeit und die dort benutzen termini bezieht.
Und Sie leider auch teilweise falsch interpretiert (siehe FPU=Floating... / FPU=Fragment.....).

Er geht dabei von dem (auch nicht immer falschen) Standpunkt aus, dass was in einer Doktorarbeit steht zu 100% richtig und unumwerflich ist...ist ja von jemanden der Studiert hat und deshalb "alles" wissen sollte...

Aber niemand ist unfehlbar, besonders nicht die Jungs die die Doktorarbeiten überprüfen.
Und auch, hat niemand immer recht, nur weil er Studiert hat....

Ich kenne überigens "mehrere" Doktoren und Studierte (war selbst mal einer), die erst mal "Lernen" mussten, dass Sie nicht immer und Grundsätzlich recht haben..

J.S.Shadow

[Endorphine]

Also meines Wissens studiert 8Bit gar nicht (hat er auch nicht), sondern ist Progger in der Wirtschaft.

[AchtBit]

Google -->
Prinzip ALU + Vertex Shader Grundprinzip = EINSICHT
vielleicht. nuff said.


http://www.8bit.de/vshader.gif

Endo, lass es. Du solltest eigentlich wissen, es dauert nie nie lange bis ich merk mich getaeuscht zu haben und dann hab ich kein Problem damit es auch zuzugeben.

[AchtBit]

Also meines Wissens studiert 8Bit gar nicht (hat er auch nicht), sondern ist Progger in der Wirtschaft.

Right, zu studieren gabs damals nix. Hab erst spaeter vom WKZ Macher zum Online Programmierer umgeschult aber bin kurze Zeit spaeter in die Anwendungsentwicklung gewechselt wo ich fuer die Entwicklung von Billingsoftware, speziell Datenbanklayer und bidirektionale Schnittstellen, verantwortlich bin.

[Demirug]

AchtBit, wenn du die entsprechenden Zeichnung für den Pixelshader nimmst steht dann dort auch ALU. Im Zusammenhang mit Shadern wird FPU und ALU als Begriff benutzt. Es handelt sich dabei aber nur um das interne Rechenwerk. Die ganzen anderen Teile des Shaders sind dabei nicht bestandteil.

Es ist allerdings nicht so das Vertex = ALU und Pixel/Fragment = FPU ist.

Rein Funktional sind sich PS und VS sehr ähnlich und verfügen ab VS/PS 3.0 auch über fast den gleichen Funktionsumfang. In der Implementierung gibt es aber (derzeit) noch grössere Unterschiede. Langfristig wird man aber wohl auf identische Einheiten setzten.

[Gast]

Original geschrieben von ShadowXX

Ich glaube das AchtBit sich insgesamt seeeehr stark auf die von Ihm verlinkte Doktorarbeit und die dort benutzen termini bezieht.



Diplomarbeit! ... und selbst als solche schrammt das Teil knapp an einer Frechheit vorbei. Eine solche Paraphrasierung von Marketinggeblubber hätte mir mein Prof rechts und links um die Ohren gehauen. (Sorry, wenn das jetzt großkotzig rüberkommt... ist es vermutlich ja auch.)

Gruß

Jörg

[ShadowXX]

Original geschrieben von Gast
Diplomarbeit! ... und selbst als solche schrammt das Teil knapp an einer Frechheit vorbei. Eine solche Paraphrasierung von Marketinggeblubber hätte mir mein Prof rechts und links um die Ohren gehauen. (Sorry, wenn das jetzt großkotzig rüberkommt... ist es vermutlich ja auch.)

Gruß

Jörg

Tschuldigung...ist nur eine Diplomarbeit....aber das Grundprinzip meiner Aussage bleibt gleich...

Aber so ist es leider Heutzutage: Was heute eine Diplomarbeit ist und auch als solche Anerkannt wird, wäre vor 10 Jahren noch eine Frechheit gewesen.....

J.S.Shadow

P.S.
das muss man auf die Ausbildungen insgesamt beziehen....wir suchten einen SAP-Dozenten und alle Bewerber konnten auch Diplome vorweisen...aber auf die Frage wie es denn mit SAP aussieht, kam die Antwort: "Wieso, dass will ich doch bei Ihnen Lernen...."

[AchtBit]

@Demirug,

Du willst es wohl auch nicht wahrhaben. Ein bunter Mix war es zu Zeiten als die Pipline nur statisch programmierbar war. Um so komplexer die Geometrieeinheit wird desto strikter werden die Funktionen getrennt sein. Was auch die einzig logische Folge ist. Deine Ansicht von Funktionszuordnungen entpricht exakto mundo einem binaerem Chaos.


ps2.0
http://msdn.microsoft.com/library/en-us/directx9_c/directx/graphics/reference/assemblylanguageshaders/pixelshaders/ps_2_0.asp
vs2.0
http://msdn.microsoft.com/library/en-us/directx9_c/directx/graphics/reference/assemblylanguageshaders/vertexshaders/vs_2_0.asp

Zum letzten mal,
VS weist den typischen Karakter eines Operators auf
PS weist den typischen Karakter eines Operanden auf

Die Einheiten befinden sich zwar noch in einem proprietaeren Zustand aber jede neuere Version hat Aenderungen aufzuweisen die eine klarere Aufteilung erkennen laesst.

So take it or leave it.

Vielleicht sollte ein eigenes Forum zum rumbohren auf Begriffsauslegungen aufgemacht werden.

P.S. In dem pdf steht nix drin was irgende eine Bedeutung in bezug auf die aktuelle PS Version haette. Der belegt die Shader mit Begriffen, die er scheinbar selbst erfunden hat.
Von PR Begriffen seh ich da ebenfalls nix.

[aths]

Original geschrieben von Endorphine
p.s. @ aths: niemand muss studiert haben, um hier mitreden zu können. Wirklich nicht...? (In die Rules guck... stimmt, hast recht.)

Im Ernst, angesichts dieses Nicht-3D-"Szene"-Ansatzes von 8Bit nehme ich an, dass er was in Richtung Info studiert hat und deshalb "seine" Termini benutzt. Auch beim seinem Posting über mir frage ich mich, aus welcher "Welt" (fachlich gesehen) er kommt, um solche unüblichen Ansätze zu wählen.
Original geschrieben von Endorphine
Findest du es nicht unfair, jemandem förmlich die Achtung absprechen zu wollen, in dem du ihn fragst, was er studiert hat? Das ist IMHO ziemlich anmaßend. So las sich dein Posting zumindest für mich. Wieso, studierst du nicht? http://www.aths.net/files/smilies/hm.gif Wer sich durch die Shader-Mathematik beißen kann, sollte per se studierfähig sein, von daher verstehe ich den gereizten Ton bei dir nicht. Für ein sowohl detailliertes als auch komplettes Verständnis vom Pixelshading wird ein übliches Studium allerdings kaum reichen. Da ist vermutlich Selbststudium gefragt.

Original geschrieben von ShadowXX
Aber niemand ist unfehlbar, besonders nicht die Jungs die die Doktorarbeiten überprüfen.
Und auch, hat niemand immer recht, nur weil er Studiert hat.... Eben. Für tiefere Einsichten ins Pixelshading braucht man allerdings Mathematik, die man nicht in der Schule beigebracht bekommt. Dot3 Lighting z.B. kann man auch allgemeinverständlich mit Worten erklären, einen Shader schreiben, der Dot3 Lighting macht, kann man nach solchen Erklärungen aber noch lange nicht. (Kann ich btw auch nicht.) Für meine Begriffe ist es nicht anmaßend zu fragen, was man studiert (hat). Fragen wird ja noch erlaubt sein.

Original geschrieben von ShadowXX
P.S.
das muss man auf die Ausbildungen insgesamt beziehen....wir suchten einen SAP-Dozenten und alle Bewerber konnten auch Diplome vorweisen...aber auf die Frage wie es denn mit SAP aussieht, kam die Antwort: "Wieso, dass will ich doch bei Ihnen Lernen...." Genau. Was man genau studiert hat bzw. welche Noten man hat, will keiner so genau wissen, falls man "auf seinem Gebiet" ein Spezi ist und dort Referenzen vorweisen kann. Man muss dazu auch nicht zwangsläufig studiert haben. Hier im Matrikel gibt's einige Studenten, die lernen zuhause, bestehen die Prüfungen, aber fallen nirgendwo durch besondere Stärken auf. Ich frage mich, ob die rein nur den Abschluss wollen (den will ich natürlich auch) oder noch ein höheres Ziel vor Augen haben.

Mit der Entscheidung für den "Dipl-Ing (fh)" habe ich ja bewusst eine praxisorientierte Ausbildung gewählt. Imo sollte man sich aber nicht über Theoretiker lustig machen, auch wenn es so genannte "Fachidioten" sind, ohne Spezialkenntnisse theoretischer Art wären wir technisch sicher nicht so weit, wie wir heute sind.

[Demirug]

AchtBit, gerade wenn du hier auf die MS Dokumentation verlinkst solltes du auch lesen was da steht. In beiden Fällen wird spricht MS von einer ALU.

Ein bunter Mix war es zu Zeiten als die Pipline nur statisch programmierbar war. Um so komplexer die Geometrieeinheit wird desto strikter werden die Funktionen getrennt sein.

Wie bitte? Nichts für ungut aber hast du jemals eine DX7-Pipeline "konfiguriert". Da gibt es zwischen dem Pixel und Vertexprocessing aber auch überhaupt keine Gemeinsamkeiten.

Mit den Shadern dagegen nehmen diese Gemeinsamkeiten immer mehr zu. Heute kann ich das gleichen Codesegment benutzten um ein Beleuchtungsmodel entweder pro Vertex oder pro Pixel rechnen zu lassen. Mit DX Next wird diese Vereinheitlichung weiter gehen.

Ich vermute jetzt einfach mal du vergleichst den Vertexshader einer Grafikkarte zu sehr mit der Geometrieeinheit der PlayStation 2 (VU0, VU1).

Zum letzten mal,
VS weist den typischen Karakter eines Operators auf
PS weist den typischen Karakter eines Operanden auf

Ich verstehe ehrlich gesagt nicht ganz was du damit sagen möchtest. Sowohl VS wie auch PS führen Operationen mit den Operanden (Register) durch.

[Gast]

Nanu...

Der Thread ist ja immer noch offen, bzw immer noch nicht auf die Spielwiese verschoben worden. Warum?

8bit will nichts lernen. Er glaubt tatsächlich er könnte Leuten wie Zeckensack, Demirug etc... vorschreiben wie die Sachen zu laufen haben und verteidigt seine Unkenntnis mit Händen und Füßen.

<grins>
wenn ich schätzen müsste, wie alt 8bit ist, würde ich sagen so 13-16 Jahre alt; mächtig angeberisch in seinem Freundeskreis und 100%ig überzeugt von seinem Nichtwissen. Hoffentlich hat er seine Kumpels eingeladen sich seine Ergüsse hier anzutun, damit die mitkriegen wie lächerlich er sich macht.
<grins>

also bitte verschiebt das ganze auf die Spielwiese, da gehört es auch hin. Mit 3D hat das hier nur sehr wenig zu tun, selbst hier im Spekulations-Forum finde ich den Thread unangebracht.

[AchtBit]

Für tiefere Einsichten ins Pixelshading braucht man allerdings Mathematik, die man nicht in der Schule beigebracht bekommt.


Mit dem vom VC++ abstammenden HLSL wird einem viel arbeit abgenommen. Polygone mit einfacher Geometrie in PS TextureSampling zu rendern, duerfte im Prinzip kaum andere Koordinierung erfordern als Texturmapping. Afaik stehen da nur die SampleStages gegen die Texturetypenwahl. Mathematik, die man nicht in der Schule lernt brauchst z.B. dann, wennst selbst ne feine schnelle Vektor Matrix entwerfen willst.

Hab den Code von der Doom Engine gesehen. Geproggt in C und die Vector/Matrix-Libs in 16bit ASM. Die Libs kamen mir vor wie boemische Doerfer obwohl ich selbst ein wenig ASM im Speicherframesrahmen geproggt hab. Dagegen ist ein shadercode in ASM wie Gold.

[AchtBit]

Um so komplexer die Geometrieeinheit wird desto strikter werden die Funktionen getrennt sein.

Da gibt es zwischen dem Pixel und Vertexprocessing aber auch überhaupt keine Gemeinsamkeiten.


Hoehh?? hab ich irgendwas gegenteiliges geschrieben???

Bei MS steht ganz gross und breit Vertex Shader Arthimetic Logic Unit(ALU) und zwar auch bei der PS20 Uebersicht.
Anders kann ich Dir wirklich nicht mehr dienen.

[nggalai]

Original geschrieben von AchtBit
Hoehh?? hab ich irgendwas gegenteiliges geschrieben???Ja. ;) Und Demirug falsch zitiert. Das gehört nämlich zusammen:

Nichts für ungut aber hast du jemals eine DX7-Pipeline "konfiguriert". Da gibt es zwischen dem Pixel und Vertexprocessing aber auch überhaupt keine Gemeinsamkeiten. Mit den Shadern dagegen nehmen diese Gemeinsamkeiten immer mehr zu. Heute kann ich das gleichen Codesegment benutzten um ein Beleuchtungsmodel entweder pro Vertex oder pro Pixel rechnen zu lassen. Mit DX Next wird diese Vereinheitlichung weiter gehen.

Während Du behauptest:Die Einheiten befinden sich zwar noch in einem proprietaeren Zustand aber jede neuere Version hat Aenderungen aufzuweisen die eine klarere Aufteilung erkennen laesst.

[...]

Ein bunter Mix war es zu Zeiten als die Pipline nur statisch programmierbar war. Um so komplexer die Geometrieeinheit wird desto strikter werden die Funktionen getrennt sein.Also das genaue Gegenteil.

93,
-Sascha.rb

[ShadowXX]

Original geschrieben von AchtBit
Hoehh?? hab ich irgendwas gegenteiliges geschrieben???

Bei MS steht ganz gross und breit Vertex Shader Arthimetic Logic Unit(ALU) und zwar auch bei der PS20 Uebersicht.
Anders kann ich Dir wirklich nicht mehr dienen.

Ich glaube wir kommen der Sache langsam näher:

Bei dir:
Vertex Shader Arthimetic Logic Unit = ALU

Bei "uns":
Vertex Shader Arthimetic Logic Unit = VS

Allerdings sollte man nicht jedes Wort von M$ auf die Goldwaage legen und ich glaube auch nicht das der PS in den M$ Docs Pixel Shader Floating/Fragment Logic Unit heisst...

Insbesondere wird wirklich jeder den du fragst mit ALU und/oder FPU die CPU in Verbindung bringen und nicht den Grafikchip....auch auf Beyond3D...

Du wirfst, viele Begriffe durcheinander bzw. kombinierst diese wie es Dir gerade in den Kontext passt...
Demi ist zB. ein Professioneller 3DEngine-Programmier...ich glaube schon das er weiss wovon er spricht...

J.S.Shadow

[Demirug]

Original geschrieben von AchtBit
Hoehh?? hab ich irgendwas gegenteiliges geschrieben???

Der Satz den du hier etwas aus dem Zusammenhang gerissen hast war ja nur als Einleitung zum Vergleich bestimmt. Du führst hier auf das es mit komplexeren Geometrieeinheiten (Ich denke du meinst den VS) eine striktere Funktionstrennung statfindet. Ich behauten aber nun das genaue Gegenteil. Zur Programmierung einer DX8/9 Geometrieeinheit braucht man viel weniger Funktionen als es noch bei einer DX7 Einheit üblich war.

Es könnte natürlich auch sein das du mit Geometrieeinheit etwas anderes als ich meinst. Für mich besteht die Geometrieeinheit primär aus dem VS und zum Teil auch noch aus dem Primitive Prozessor. Da man aber auf den PP derzeit nicht viel Einfluss hat ist er aus Sicht der Programmierung uninteresant.

Bei MS steht ganz gross und breit Vertex Shader Arthimetic Logic Unit(ALU) und zwar auch bei der PS20 Uebersicht.
Anders kann ich Dir wirklich nicht mehr dienen. [/SIZE]

Darum ging es mir:

PS entspricht equivalent einer FPU
VS enspricht equivalent einer ALU

Entweder beziechnet man beides als ALU (wie MS) oder eben beides als FPU. Aber zu behauten PS = FPU und VS = ALU ist in dieser Form einfach für die meisten verwirend und lässt einen Unterschied vermuten des es einfach nicht gibt.

[Demirug]

Original geschrieben von AchtBit
Mit dem vom VC++ abstammenden HLSL wird einem viel arbeit abgenommen. Polygone mit einfacher Geometrie in PS TextureSampling zu rendern, duerfte im Prinzip kaum andere Koordinierung erfordern als Texturmapping. Afaik stehen da nur die SampleStages gegen die Texturetypenwahl. Mathematik, die man nicht in der Schule lernt brauchst z.B. dann, wennst selbst ne feine schnelle Vektor Matrix entwerfen willst.

HLSL ist von C abgeleitet. Ich hätte persönlich lieber auch etwas mehr OOP ala C++ gesehen ist aber nun mal nicht. btw: VC++ ist Produktbezeichnung für die C++ die IDE von Microsoft.

Ob man Texturemapping nun mit einer DX7 Pipeline, oder den PS-ASM bzw HLSL vornimmt ist im Prinzip egal un völlig unabhänig von der Geometrie. Da kann man beliebig kombinieren.

Man braucht schon etwas Mathe die nicht zum üblichen Schulstoff gehört. Diese ganzen Lichtmodelgeschichten sind sehr mathematische Angehaucht. Natürlich bauen diese auch nur auf Vektor und Matrix rechnungen auf aber das muss ja nichts heisen.

[Endorphine]

Original geschrieben von aths
Wirklich nicht...? (In die Rules guck... stimmt, hast recht.)

Im Ernst, angesichts dieses Nicht-3D-"Szene"-Ansatzes von 8Bit nehme ich an, dass er was in Richtung Info studiert hat und deshalb "seine" Termini benutzt. Auch beim seinem Posting über mir frage ich mich, aus welcher "Welt" (fachlich gesehen) er kommt, um solche unüblichen Ansätze zu wählen.
Meines Wissens hat er nicht studiert und ist auch nicht dabei, an einer Hochschule zu studieren. Ich hab mir einfach nur vorgestellt, wie sich jemand fühlen muss, wenn er folgendes von dir liest: Original geschrieben von aths
Darf man fragen, welches Fach du studierst (bzw. studiert hast) und wie dein "Werdegang" im Bereich 3D-Technik ist? Vielleicht könnte man dann einige Verständigungsprobleme aus der Welt räumen. Klingt für sich allein genommen ganz gut, nur in dem Kontext kam es irgendwie so rüber: "du schmeisst mit ganz schön viel Mist um dich - hast du überhaupt studiert, um bei uns mitreden zu dürfen?". Da würde ich mir irgendwie als Mensch zweiter Klasse vorkommen, der in diesem Kreis von Akademikern nichts zu suchen hat (?). Viel mehr meinte ich gar nicht. Original geschrieben von aths
Wieso, studierst du nicht? http://www.aths.net/files/smilies/hm.gif Wer sich durch die Shader-Mathematik beißen kann, sollte per se studierfähig sein, von daher verstehe ich den gereizten Ton bei dir nicht. Für ein sowohl detailliertes als auch komplettes Verständnis vom Pixelshading wird ein übliches Studium allerdings kaum reichen. Da ist vermutlich Selbststudium gefragt. Doch, ich studiere derzeit, auch an der FH. Und ja, um Shader verstehen zu können braucht man auch aus meiner Sicht deutlich mehr als Schulmathematik. Zumindest ein intensives Selbststudium :) Original geschrieben von aths
Genau. Was man genau studiert hat bzw. welche Noten man hat, will keiner so genau wissen, falls man "auf seinem Gebiet" ein Spezi ist und dort Referenzen vorweisen kann. Muss man auf seinem Gebiet Spezialist sein und Referenzen vorweisen können, um hier ernst genommen zu werden? Das ist ja der Kernpunkt deiner Aussage, hier steht sie nicht zwischen den Zeilen, sondern kommt direkt 'rüber. IMHO würde das Forum sich sehr schnell bis auf eine Hand voll Leute leeren, wenn nur noch Spezialisten-auf-ihrem-Gebiet zugelassen sind, die auch noch Referenzen vorweisen können. Original geschrieben von aths
Mit der Entscheidung für den "Dipl-Ing (fh)" habe ich ja bewusst eine praxisorientierte Ausbildung gewählt. Imo sollte man sich aber nicht über Theoretiker lustig machen, auch wenn es so genannte "Fachidioten" sind, ohne Spezialkenntnisse theoretischer Art wären wir technisch sicher nicht so weit, wie wir heute sind. Interessant. Dich stört offensichtlich, dass einige sich über Theoretiker lustig machen. Warum denkst du auf dieser Basis nicht auch in die andere Richung und zeigst mehr Toleranz gegenüber nicht-Theoretikern, nicht-Spezialisten und nicht-"Fachidioten"? Das kommt mir vor wie Wasser predigen und Wein trinken, aths.

p.s. Sorry für OT.

[AchtBit]

Wenn ich equivalent sagte, dann war damit die Funktion gemeint. Irgendwo vorher hatte ich bereits gesagt der Shader ist eine Makroengine. Die PS wendet sampling in mehreren Stufen auf eine Textur an, welche mit hilfe einer pipeline per pass ausgefuehrt werden koennen. Der VS tut im Prinzip das gleiche nur mit geometrischen Daten.

Kann der PS einen Bezug zu einem Vertex herstellen???

Kann der PS ohne Vertex ein Objekt in der Matrix erfassen und rendern???

Hier kannst mich berichtigen, da ich nicht sicher bin wie die Funktionen im einzelnen genau heissen.

Welche fload Funktionen verwendet der PS? 5 glaub ich wenn mich nicht alles taeuscht.
fload adressing processing
fload color processing
fload blend processing
fload fog processing
fload texture processing

Der VS hat 2, wobei eine jedem Operator zu Grunde liegt
fload adressing processing
color adressing processing

Das einzig ungewoehnliche fuer mich, ist die fload Funktion fuer Farben, ansonsten seh ich klar welche Shader fload typisch sind und welche fuer logische u. arthimetische Operationen stehen.

Wie Du oben beschrieben hast, ist natuerlich per vertex shading moeglich aber es ist meines erachtens einer Zweckentfremdung des Operators, fload Vertex Coordinaten zum unnoetigen streamen heranzuziehen i.e. gleichzusetzen mit der Aktion, in der CPU ein Polygon mittels fload processing, von einen geometrischen Operator fuellen zu lassen. Im Prinzip tust den Operator degradieren, denn ein einfacher fload Operand waere genug, um im Bereich der Coordinaten das Polygon fuellen zu koennte.

Ich kann mir Vertexshading zum animieren von Wired Frame Daten vorstellen, aber mit dem Fuellen hab ich ein Problem.

Wenn ich irgendwo nicht recht haben sollte, dann lass ich mich in dem Fall gerne belehren.

[AchtBit]

Man braucht schon etwas Mathe die nicht zum üblichen Schulstoff gehört. Diese ganzen Lichtmodelgeschichten sind sehr mathematische Angehaucht. Natürlich bauen diese auch nur auf Vektor und Matrix rechnungen auf aber das muss ja nichts heisen.

Ich hasse lineare Gleichungen ausser ich kriegs vorgerechnet.


Was issn nur mit dem MySql Server los? Der lacked ohne Ende.

@Demirug,

ahh Student, jetzt wird mir einiges klar. Da wirds Zeit, dass Du mal richtige Erfahrungen sammeln tust. Aus Erfahrung weis ich, zumindest war es bei meinen FH Praktis so, dass die manche Sachen gern auf die leichte Schulter nahmen aber letztendlich an trivialen Problemen scheiterten, ist nicht persoenlich gemeint aber das betraf eben schon 3 von 5 FH Kandidaten. Einer, weis ich noch, hat sich ohne ende damit geblustert, dass er angeblich so toll ogl beherrscht, als er dann in die GUI einer unserers App einen manuellen drag/drop Mechanismus zw 3 Listviews proggen sollte, war er nicht faehig die Events so zu handeln, um im zeitlich logischen Ablauf des Vorgangs die richtigen Schritte fuer drag/move/drop des Obkjektes zu bestimmen und durchzufuehren. Davor hat er schliesslich kapituliert und glatt noch behauptet, dass wuerde in VB nicht funktionieren. (d/d manuell mit etwas verzwicktem eventhandling @ runtime bestens zum auf den Nerv fuehlen geeignet. hehe, aber machbar)

Ist echt so, und fast alle neuen Praktis koennen grundsaetzlich C++ und wenn ich se frag in welcher Klasse ich ne Methode zum oeffenen einer SystemInfobox finde, muss ich feststellen dass es nicht weit her ist mit ihren C++ Kuensten.

Ja so sans die Prinzen. ;) Hab aber auch schon 2 Praktis gehabt die Interesse zeigten und gelehreich waren.

[Demirug]

AchtBit, Ich glaube jetzt zu wissen warum wir aneinader vorbei reden. So wie mir scheint siehst du die Shader als Einheiten die mehrere Funktionen die vorher getrennt waren zusammenfassen.

Es ist allerdings mehr so das Shader allgemeine Funktionen zur Verfügung stellen mit denen man unter anderem auch die bekantten Funktionen übernehmen kann. Einem Shader ist es aber im Prinzip egal was er rechnet. Ob es sich nun im Vertexshader um Position oder Lichtberechnungen handelt ist dem Shader völlig egal. Eine Vektorrechung bleibt eine Vektorrechnung. Die Verwendung wird nur dadurch bestimmt auf welches Ausgangsregister man die Ergebnisse schreibt. Bei den Pixelshader ist es ähnlich dem Chip ist es völlig egal was man da rechnet. Dank HLSL kann man sogar schön Shadercode zwischen dem Pixel und Vertex Processing wiederverwenden.

Wie kommst du übrigens darauf das ich Student sein soll?

[aths]

Original geschrieben von Endorphine
Klingt für sich allein genommen ganz gut, nur in dem Kontext kam es irgendwie so rüber: "du schmeisst mit ganz schön viel Mist um dich - hast du überhaupt studiert, um bei uns mitreden zu dürfen?". Gemeint war etwas anderes, wie ja schon erwähnt.
Original geschrieben von Endorphine
Muss man auf seinem Gebiet Spezialist sein und Referenzen vorweisen können, um hier ernst genommen zu werden? Ob man bei technischen Fragen mitdiskutieren kann hängt natürlich auch davon ab, wie firm man selber in der Materie ist.

[Quasar]

Jubel!

*popcornauspack*

Auf die nächste Runde...

P.S.:
Ich glaube, Demi hat nicht studiert... wozu auch?

[Xmas]

Original geschrieben von AchtBit
Wenn ich equivalent sagte, dann war damit die Funktion gemeint. Irgendwo vorher hatte ich bereits gesagt der Shader ist eine Makroengine. Die PS wendet sampling in mehreren Stufen auf eine Textur an, welche mit hilfe einer pipeline per pass ausgefuehrt werden koennen. Der VS tut im Prinzip das gleiche nur mit geometrischen Daten.

Kann der PS einen Bezug zu einem Vertex herstellen???

Kann der PS ohne Vertex ein Objekt in der Matrix erfassen und rendern???

Hier kannst mich berichtigen, da ich nicht sicher bin wie die Funktionen im einzelnen genau heissen.

Welche fload Funktionen verwendet der PS? 5 glaub ich wenn mich nicht alles taeuscht.
fload adressing processing
fload color processing
fload blend processing
fload fog processing
fload texture processing

Der VS hat 2, wobei eine jedem Operator zu Grunde liegt
fload adressing processing
color adressing processing

Das einzig ungewoehnliche fuer mich, ist die fload Funktion fuer Farben, ansonsten seh ich klar welche Shader fload typisch sind und welche fuer logische u. arthimetische Operationen stehen.

Wie Du oben beschrieben hast, ist natuerlich per vertex shading moeglich aber es ist meines erachtens einer Zweckentfremdung des Operators, fload Vertex Coordinaten zum unnoetigen streamen heranzuziehen i.e. gleichzusetzen mit der Aktion, in der CPU ein Polygon mittels fload processing, von einen geometrischen Operator fuellen zu lassen. Im Prinzip tust den Operator degradieren, denn ein einfacher fload Operand waere genug, um im Bereich der Coordinaten das Polygon fuellen zu koennte.

Ich kann mir Vertexshading zum animieren von Wired Frame Daten vorstellen, aber mit dem Fuellen hab ich ein Problem.

Wenn ich irgendwo nicht recht haben sollte, dann lass ich mich in dem Fall gerne belehren.
Ehrlich, hättest du das obige Posting in Russisch verfasst, ich hätte nicht weniger davon verstanden. Das soll jetzt nicht beleidigend sein, aber du gebrauchst Begriffe in einer Weise, die von einem anderen Planeten zu kommen scheint.

Dass du z.B. Vertex Shading in Verbindung mit Wireframe-/Fill-Darstellung bringst, zeigt mir dass du keine "kompatible" Vorstellung davon hast. Es wäre vielleicht ganz hilfreich, wenn du mal in einfachen Worten, ohne Fachtermini, darlegen würdest was du dir unter Pixel/Fragment Shader und Vertex Shader vorstellst.

[Exxtreme]

Original geschrieben von zeckensack
Da du ja anscheinend die B3D-Foren liest, empfehle ich dir diesen Thread (http://www.beyond3d.com/forum/viewtopic.php?t=8589). Qualifiziert sich fast schon als Flamewar, ist auch sehr lang, aber IMO recht fruchtbar. Und vor allem kannst du dort auch nachlesen, was ich von MS'schem API-Design halte (Hint: nichts).
Ich habe mir den ganzen Thread gegeben. Jong, da qualmt die Birne. ?-) ?-)

Irgendwie sehe ich die Cheaterei von NV jetzt in einem ganz anderem Licht. :|

[Gast]

@Achtbit

Original geschrieben von ShadowXX

Demi ist zB. ein Professioneller 3DEngine-Programmier...ich glaube schon das er weiss wovon er spricht...

J.S.Shadow

Im Quote steht doch klar und deutlich was Demi macht. :)

manchmal frage ich mich shcon wie du manche Postings liest.(Könnte natürlich auch daran liegen dass deutsch nicht deine Muttersprache ist(was ich vemute), aber nicht auf den ersten Blick zu erkenn ist.

Und das mit dem Student war eigentlich auf dich bezogen... wobei das auch nicht richtig ist.

[MadManniMan]

Original geschrieben von Quasar
Jubel!

*popcornauspack*

Auf die nächste Runde...


:bier: Na? Auch wieder da zum Zugucken? :wink: Sitz hier grad gemütlich mit ein paar Erdnußflips und genieß das Ganze :D

[Ailuros]

@Demirug,

ahh Student, jetzt wird mir einiges klar. Da wirds Zeit, dass Du mal richtige Erfahrungen sammeln tust.

Achtbit,

Schoen langsam hier. Ich bezweifle dass Demirug genaue "credentials" in die Oeffentlichkeit schiessen wird, aber es handelt sich tatsaechlich um einen professionellen Entwickler mit langjaehriger Erfahrung.

[zeckensack]

Oh je :(

Funktionsblöcke in einem 3D-Chip (genauer: Dreiecks-Rasterizer, IMR)


Vertex Shader
Tritt an die Stelle des 'fixed function T&L' (ein VS ist eine flexiblere, weil programmierbare Übermenge davon). Die ganze Sauce war vor ein paar Jahren noch eine reine Software-Angelegenheit, aber egal.

Rein kommen 'vertices'. Raus kommen auch wieder vertices, und zwar im Verhältnis 1:1. Die Operationen dazwischen sind mittlerweile programmierbar, und umfassen allerlei nützliches für Vektor-Berechnungen.

Die primäre Aufgabe ist das Vernaschen der Geometrie, und die Kamera-Transformation derselben. Der VS kann selbstredend auch Animationsaufgaben bewältigen, indem zB zwischen zwei Animationsphasen eines Modells interpoliert, und erst dann transformiert wird.
Vertices sind aber nicht nur Geometrie, sondern auch Texturkoordinaten und Farben, oder Vektoren die man entweder gleich hier verwendet (zB die Normale für fixed function lighting ala OGL1.0 oder D3D7), oder gerne in den Pixel Shader rüberschieben möchte.

Der VS kann nur lesend auf Speicher zugreifen, und dies auch nicht wahlfrei, sondern lediglich in Form der einzelnen Vertices, die ihm übergeben werden.

Es können keine Daten geschrieben werden.


Perspektiv-Division
Ist an dieser Stelle nicht wirklich interessant, aber der Vollständigkeit halber ...
Geometrie liegt in Form von homogenen Koordinaten vor, und das muß erstmal 'korrigiert' werden. Die Hintergründe wurden hier (http://www.forum-3dcenter.org/vbulletin/showthread.php?threadid=104276) bereits angerissen.


Primitive assembly
Dieser Block ist dafür zuständig, aus den Eckpunkten Oberflächen zu formen, wobei es momentan noch keine freie Programmierbarkeit gibt, sondern nur eine Auswahlmöglichkeit zwischen wenigen vorgegebenen Strategien.
Im einzelnen wären dies (OGL-Tokens angegeben zum Nachschlagen)
1)Punkte (GL_POINTS)
2)einzelne Linien (2 verts pro Linie) (GL_LINES)
3)verbundene Linien (n+1 verts ergeben n Linien; GL_LINE_LOOP)
4)seperate Dreiecke (3 verts pro Dreieck; GL_TRIANGLES)
5)strips (n+2 verts ergeben n Dreiecke; GL_TRIANGLE_STRIP)
6)fans (n+2 verts ergeben n Dreiecke; GL_TRIANGLE_FAN)
7)Vierecke (4 verts ergeben pro Viereck; GL_QUADS)
8)'quad strips' (~äquivalent zu tristrips)
9)point sprites (ein Vertex ergibt ein Rechteck ...)

Backface Culling kann auch sinnvoll diesem Block zugeordnet werden. edit: Clipping eigentlich auch. Wenn man 'richtig' clippt ... ein bekannter, grüner IHV zB löst das nämlich wieder ganz anders :grübel:
Dieser Block hat keinerlei Zugriff auf Speicher. Er bekommt Daten vom VS, und gibt sie weiter an ...


Rasterizer
Hier wäre der Punkt erreicht, wo ich zugeben muß daß die Terminologie nicht 100%ig wasserdicht ist. Tri-Setup wäre auch ein schöner Begriff hierfür :|
Irgendwann mal verstand man unter einem "Rasterizer" eine komplette Grafikeinheit, ich meine jetzt allerdings nur folgendes:
Aufteilen der Flächen in die Punkte, die von ihnen bedeckt werden. Diese nennt man in GL-Terminologie Fragmente, bei DX heißen sie Pixel. Dazu passend die Interpolation der Vertex-Parameter (Texturkoordinaten, Farben, etc).

Speicherzugriff gibt's auch hier nicht zu vermelden.
Erwähnenswert noch die Tatsache, daß jeweils nur einzelne, isolierte Fragmente/Pixel weitergereicht werden, und zwar an vorzugsweise mehrere, parallel arbeitende ...


Pixel Shader
Generell eine programmierbare, flexiblere Übermenge von all dem, was es 'früher' mal so gab, den Textur-Combinern oä. Die Aufgabe dieser Einheit ist es, die letztendliche Farbe des Bildpunkts zu errechnen. Dazu bedient man sich den hereinkommenden interpolierten Parametern, die man entweder zum Texturieren benutzt (Textur-Koordinaten), oder direkt als Farbe, oder als Vektoren, die man erstmal kräftig verrechnet (N*(E-L) trallala ...), um ein Lichtmodell nachzubilden.
Texturkoordinaten kann man auch mehr oder weniger flexibel arithmetisch massieren, bevor man sie zum Lookup der Textur heranzieht ("dependent reads"). Und überhaupt, und so.

Da man Farben schön als RGBA-Vektoren verarbeiten kann, haben wir's auch hier wieder mit einem Vektorrechenwerk zu tun, was natürlich auch nützlich ist, wenn wir Lichtvektoren stilistisch wertvoll verbiegen wollen.

Modifikation des Z-Werts liegt ebenfalls im Bereich des hier machbaren. Modifikation von X oder Y allerdings nicht.

Hier gibt es wieder einen 1:1-Zusammenhang zwischen Input und Output zu bestaunen, wobei das nur halb wahr ist (KIL ...), aber der Einfachheit halber halten wir's mal so.

Speicherzugriff:
Der Input ist vorgegeben, er kommt vom Rasterizer.
Darüberhinaus gibt's natürlich Lesezugriff auf den Texturspeicher, in Form von Indirektion über die Texturkoordinaten (und die an die Sampler gebundenen Texturen, 'türlich). Dh es ist mal wieder nicht so ganz wahlfrei ...
Geschrieben wird hier noch nicht. Das trennt man modernerweise in den nächsten Block ab, der auf dem Fuße folgt.



ROP
Hier kommen die fertigen, schön bunten Fragmente/Pixel an, um endlich ihren Weg in den Framebuffer zu finden.
Dieser letzte Gang enthält so schöne Dinge wie Dithering, Alpha Blending, Alpha Test, Z- und Stencil-Operationen*, und die Handhabung von Multisampling. Um MRTs kümmert man sich hier auch.
Diese Einheit braucht Lese- und Schreibzugriff auf Color-, Z- und Stencil-Buffer. Im Falle von MRTs natürlich auf mehrere.


Und das war's
Die hübschen Bildchen liegen jetzt im Color Buffer, und können vom RAMDAC abgeholt werden.

*Z/Stencil kann - und sollte man - bereits früher in der Pipeline erledigen, sofern Z nicht vom Pixel Shader modifiziert werden will.


Oder ganz kurz:
Vorne Vertices rein, bunte Pixel hinten raus. Texturen werden hinten links angeflanscht (reiner Lesezugriff). Dazwischen gibt's nichts, was in irgendeiner Form auf Speicher zugreifen kann.

Dafür braucht's 'echtes' displacement mapping ala Matrox (die diese Features allerdings nur in Techdemos zu haben scheinen, und es nicht für Entwickler nutzbar machen ...), oder die nächste VS-Generation 3.0.

Und TruForm habe ich auch absichtlich vergessen.

Ansonsten müßte das so ungefähr hinkommen, +-5cm.

[Demirug]

+-5cm: (nur der vollständigkeit halber als Ergänzug zu der hervoragenden Vorarbeit von Zeckensack)

Vor dem Vertexshader gibt es eigentlich noch den Vertex-DMA. Dieser liest die Verticen aus den verschiedenen zugänglichen Speichern (Lokal, AGP) aus und verbindet diese zu Verticen. Bei Bedarf kann hier auch eine Umwandlung des Formats (Integer nach Float) durchgeführt werden.

Die Interpolation der Vertex-Parameter kann auch erst im PixelShader erfolgen. 3DLabs (P10/P9) und nVidia (NV3X) machen das auf jeden Fall so. Bei den anderen habe ich da keine Informationen.

Die Einheit welche das Primitive assembly übernimmt wird auch gernen als Primtive Prozessor bezeichnet. In diesem Zusammenhang hört man ja in letzer Zeit öfter auch mal etwas von einem Programmierbaren Primitive Prozessor (PPP).

Der Rasterizer ist in der Regel auch der Ort an dem das vorzeitige Verwerfen von Pixel(Blöcken) vorgenommen wird. (Early-Z)

KIL ist heute in der Regel so implementiert das in der Sample-Maske des Pixelblocks die entsprechenden Samples des Pixelblocks ausmakiert werden. Ausmakierte Samples werden von den ROPs nicht mehr bearbeitet. Das 1:1 Verhältniss bleibt also eigentlich bestehen.

Was die Z und Stencil Ops in den ROPs angeht so habe ich inzwischen gelernt das selbst wenn der Chip über Early-Z Verfahren verfügt in den ROPs immer noch den Z-Vergleich hat. Der eine Grund ist besagtes ändern der Z-Werte im Pixelshader. Der andere ist das beim Early-Z nur eine vereinfachte Auswertung durchgeführt wird ob mindestens ein Sample des Pixelblocks sichtbar ist. Die genaue Prüfung pro Sample machen dann erst die ROPs.

PS: Mit DX-Next wird dann alles ein wenig anders.

[mrdigital]

Auch wenn das hien ein wenig OT werden könnte, hab ich doch ne Frage zum technischen Verständniss...
Nachdem man alle Infromationen über ein Frame in die Grafikkarte gestopft hat, mit allem was so dazugehört, stösst man dann Rendervorgang an und erhält dann mit viel Magie ein Bild im Speicher (Monitor). Schön. Wenn man nun das nächste Frame generieren will, kann man dann die bereits in die Karte hochgelandenen Objekte wiederverwenden (an evtl. anderen Positionen) oder muss man das gesammte Frame wieder neu in die Karte hochladen, um dann den Rendervorgang erneut anzuwerfen? Will damit fragen, ob die Karte selbst weiss, welche Vertices zusammenhängen zu einem Objekt und ob man nun dieses Objekt auch manipulieren kann?

[gbm31]

[edit: vor]letzte 2 posts:

ahh, da lichtet sich was, jetzt versteh ich wenigstens ansatzweise was...


ansonsten:

weiter so, ist sehr unterhaltsam und es kommt sogar was informatives raus

[Demirug]

Original geschrieben von mrdigital
Auch wenn das hien ein wenig OT werden könnte, hab ich doch ne Frage zum technischen Verständniss...
Nachdem man alle Infromationen über ein Frame in die Grafikkarte gestopft hat, mit allem was so dazugehört, stösst man dann Rendervorgang an und erhält dann mit viel Magie ein Bild im Speicher (Monitor).

Bei einem IMR (Immediate Mode Renderer) wird schon angefangen zu Rendern bevor der Frame komplett ist.

Schön. Wenn man nun das nächste Frame generieren will, kann man dann die bereits in die Karte hochgelandenen Objekte wiederverwenden (an evtl. anderen Positionen) oder muss man das gesammte Frame wieder neu in die Karte hochladen, um dann den Rendervorgang erneut anzuwerfen?).


Texturen und Geometriedaten welche schon im lokalen Grafikkartenspeicher sind kann man wiederverwenden.

Will damit fragen, ob die Karte selbst weiss, welche Vertices zusammenhängen zu einem Objekt und ob man nun dieses Objekt auch manipulieren kann?

Die Informationen wie alles zusammengehört (wie sich aus den einzelnen Verticens ein Objekt formt und welche Texturen wo benutzt werden sollen) ist ein Teil des Kommandodatenstroms. Dieser wird normalerweise für jeden Frame neu übertragen. Die Datenmenge ist aber im Verhältniss zu den Geometrie und Texturedaten eher gering.

[mrdigital]

Original geschrieben von Demirug
...

Die Informationen wie alles zusammengehört (wie sich aus den einzelnen Verticens ein Objekt formt und welche Texturen wo benutzt werden sollen) ist ein Teil des Kommandodatenstroms. Dieser wird normalerweise für jeden Frame neu übertragen. Die Datenmenge ist aber im Verhältniss zu den Geometrie und Texturedaten eher gering.

D.h. also dass die Karte eine Indexliste führt (man muss ja die einzelnen Vertices wieder "adressieren" können), und dass meine Applikation nun mit diesen Indices arbeitet, so in der Art "Liebe Karte, Nummer 1,4,7 haben sich bewegt" oder verstehe ich da was grob falsch?

[Demirug]

Original geschrieben von mrdigital
D.h. also dass die Karte eine Indexliste führt (man muss ja die einzelnen Vertices wieder "adressieren" können), und dass meine Applikation nun mit diesen Indices arbeitet, so in der Art "Liebe Karte, Nummer 1,4,7 haben sich bewegt" oder verstehe ich da was grob falsch?

Wenn ich dich richtig verstanden gehst du davon aus das die komplette Szenze in der Grafikkarte gespeichert ist und dann von Frame zu Frame angepasst wird. Das ist so nicht richtig. Der Speicher enthält nur Rohdaten und der Chip bekommt von der CPU für jeden Frame die komplette Beschreibung wie aus den Rohdaten das gesamte Bild zu erzeugen ist.

Die Indexliste gehört zu den Geometriedaten und kann auch in der Grafikkarte gespeichert werden (nicht bei jeder). Man kann aber auch ohne Indexbuffer arbeiten wenn die Verticen schon in der richtigen Reihenfolge vorliegen.

Das mit den Komandos läuft in etwa so ab:

- Benutzte Indexliste "Baum1"
- Benutzte Verticen "Baum1"
- Benutzte als erste Texture "Blatt1"
- Benutzte als zweite Texture "Holz"
- Für jede Vertice tu das folgenden <...> (VS-Programm)
- Für jeden Pixel tu das folgenden <...> (PS-Programm)
- Rendere x Dreiecke (x ist dann eben die Anzahl der Dreiecke die man für den kompletten baum braucht)
...

Daten die man in der Grafikkarte speichert sind normalerweise statisch. Die Veränderungen (z.b. Bewegungen) lässt man dann für jeden Frame durch den Vertexshader berechnen. Dabei bleiben die Daten im Speicher aber unverändert nur intern rechnet der Chip mit den neuen Werten weiter. Man kann natürlich auch die Daten im Grafikspeicher jeden Frame von der CPU aus ändern aber das ist sehr ineffektiv.

Da die Daten explizit angesprochen werden müssen kann man natürlich auch Daten in der Grafikkarte haben die nicht benutzt werden.

[aths]

MMM, Q, könntet ihr sowas nicht im Chat oder per PM besprechen? Wir sind hier nicht in einer Arena. Danke für das Verständnis.


Zeckensack, *lufthüpf*, schon mal daran gedacht, einen Grundlagen-Artikel zu schreiben? So eine Art Kurzdurchlauf durch die Pipe, wie eben beschrieben?


Demi, dass dieses "einfache" Early Z bei NV25 und NV3x so gemacht wird, ist inzwischen klar. Ist es auch beim NV20 schon so? Hast du 'ne Ahnung, wie ATI-Karten das machen?

Der NV20 kann ja, wie NV25, pro Takt 16 Pixel verwerfen (oder (basierend auf einer Überlegung von Xmas) genauer gesagt, 4 Quads.)

Beim NV25 klappt das sogar noch mit MSAA, wobei ich jetzt nicht genau weiß, sondern mal hoffe, dass ebenfalls 4 Quads pro Takt rausfliegen können (und nicht nur 2 Quads bei 2x MSAA.)

Lange Rede, kurzer Sinn, mir dünkt als seien beim NV20 tatsächlich die Z-Units "nach vorne" schaltbar. Oder kann das Early Z beim NV20 einfach noch keine Z-"Abschätzung" für das Quad machen, sofern MSAA aktiv ist? Und letztlich muss doch für jedes Subpixel der Z-Wert bekannt sein um zu wissen, ob das Quad unsichtbar ist? Oder hat auch NV eine Art HierZ, dass pro Quad (oder pro 8x8-Tile oder wie auch immer) größter und kleinster Z-Wert gespeichert werden? (NV25 kann ja auch Fast Z Clear, wozu ohnehin der Z-Buffer extra in Tiles zerlegt werden muss, wohl etwas mehr "sophisticated" als für Z-Compression notwendig.)

[AchtBit]

@Demirug,

der Part mit dem Studenten war nicht fuer Dich sondern @aths gerichtet.


Irgendwie sehe ich die Cheaterei von NV jetzt in einem ganz anderem Licht.

@Exxtrem,

Jahh, das wollt ich hoeren. ;D
Das Ziel meines initalen Postings hat zumindest bei einem User auf indirekte Weise, durch Zeckensacks freundlicher Unterstuetzung(wenn auch ungewollt :) ) mit dem Link, Wirkung gezeigt und somit waren meine Bemuehungen nicht umsonst.
Wenn du weist warum Bigbrother 'you are dismissed' spielt, dann solltest Du mein Startposting auch besser verifizieren koennen. ;)

@Zeckensack,
interssantes Posting, obgleich ich die Bedeutung im Kern schon kannte, waren noch ein paar, fuer mich neue, Details bezueglich ati darin zu finden. Da Du ja scheinbar weist worum es geht, steht ja sogar im Klartext in einem der Posts, kann ich Dir die MS Developer Newsgroub empfehlen. Da dort keine Posting in der Art von b3d zugelassen sind, muss man etwas genauer hinsehen um den Sarkasmus darin zu erkennen. Insbesondere die von den nv und ati Mitarbeitern sind lustig wenngleich der Hintergrund ehr traurig ist.

http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A0=DIRECTXDEV&D=0&F=&H=0&I=-3&O=T&S=&T=1

Das Topic im Verlauf des Oktobers, in dem nach den DX9 Voraussetzungen verschiedener FP Formate gefragt wird, ist gehaltvoller wie es augenmerklich scheint. ;)

[Demirug]

aths, die Idee mit dem Vorschalten halte ich inzwischen für sehr unwahrscheinlich. Die Fläche die für die zusätzliche Singanlleitungen und Weichen benutzt werden müsste dürfte auch ausreichen um die Funktion zweimal zu implemnetieren. Zudem versauen dir solche Kondtruktionen leicht die Taktbarkeit.

Early-Z arbeitet IMHO wie von dir auch vermutet mit einem Min-Max Verfahren pro Quad. Beim NV20 funktioniert aber die Berechung nicht mehr wenn MSAA ins Spiel kommt. Entweder musste man Transitoren sparen, oder es ist ein Hardwarebug, oder jemand bei nV hat berechnet das der Flaschenhals beim Einsatz von MSAA durch Early-Z beim NV20 nicht beseitigt werden kann.

[zeckensack]

Original geschrieben von aths
Zeckensack, *lufthüpf*, schon mal daran gedacht, einen Grundlagen-Artikel zu schreiben? So eine Art Kurzdurchlauf durch die Pipe, wie eben beschrieben?:|
PCGH 02/2003 bis 05/2003 :spock:
Das ganze gibt's auf einer der späteren Ausgaben auch als PDF-Sammlung. :|

[MadManniMan]

Original geschrieben von zeckensack
:|
PCGH 02/2003 bis 05/2003 :spock:
Das ganze gibt's auf einer der späteren Ausgaben auch als PDF-Sammlung. :|

Kam einem in der Kurzform aber wesentlich komplizierter und detaillierter vor :kratz2:

[zeckensack]

Original geschrieben von MadManniMan
Kam einem in der Kurzform aber wesentlich komplizierter und detaillierter vor :kratz2: In der PCGH war das ganze auf Features aufgebaut (~Praxisbezug).
Hier stand die Struktur und der logische Ablauf im Vordergrund.

[MadManniMan]

Original geschrieben von zeckensack
In der PCGH war das ganze auf Features aufgebaut (~Praxisbezug).
Hier stand die Struktur und der logische Ablauf im Vordergrund.

Mal wieder ein Beispiel dafür, daß man mit Praxisbezug trotz viel mehr Text nicht immer die ganze Theorie erklärt bekommt.

[zeckensack]

Original geschrieben von MadManniMan
Mal wieder ein Beispiel dafür, daß man mit Praxisbezug trotz viel mehr Text nicht immer die ganze Theorie erklärt bekommt. Wohl wahr :)

[Exxtreme]

Original geschrieben von Exxtreme
Ich habe mir den ganzen Thread gegeben. Jong, da qualmt die Birne. ?-) ?-)

Irgendwie sehe ich die Cheaterei von NV jetzt in einem ganz anderem Licht. :|
Auf Wunsch von Henry erläutere ich mal warum ich die Cheaterei von NV jetzt in einem anderen Licht sehe.

Der Thread, den Zecki verlinkt hat, ist in der Tat interessant. Die OpenGL-Fans dort argumentieren, OpenGL viel flexibler ist als D3D und daß die IHVs bei OpenGL viel besser optimieren können da die Shader als HLSL an den Treiber übergeben werden. Die Information, was der Programmierer eigentlich wollte, geht nicht nicht verloren. Der Treiber kann da viel besser optimieren wenn es die HW erlaubt.

Die 2 großen Nachteile von OpenGL sind herstellerspezifische Extensions und man muss sich stärker auf die einwandfreie Funktion der OpenGL-Treiber verlassen da diese viel übernehmen.

Die DX-Fans argumentieren, daß DX es mehr oder weniger sicherstellt, daß die Spiele auf verschiedener Hardware gleich aussehen wenn die HW und der Treiber die geforderten Features unterstützen. Und da MS die Zügel in der Hand hält, wird sichergestellt, daß keiner der IHVs da irgendwas dreht. Und durch den Low-Level-Shader-Code kann man viel besser in den Renderingvorgang eingreifen.

Leider vernichtet die Shader-Compilierung viele Informationen über den Zweck des Shaders und der Low-Level-Shader-Code gibt die Vorgehensweise über den Renderingvorgang sehr stark vor. Die IHVs müssen viel mehr Aufwand bei der Optimierung treiben. Um das zu minimieren, wurden die Shaderprofile eingeführt. Aber diese haben auch ihre Tücken. Es könnte z.B. passieren, daß die PS2-Shader auf zukünftiger HW von ATi langsamer laufen könnten als auf jetziger. Um das zu umgehen müsste man das Spiel patchen aber welcher Hersteller würde das tun? Unter OpenGL passiert sowas eher nicht. Wenn der Treiber halbwegs schlau ist, wählt er die zur HW passendsten Code aus.


Lange Rede, kurzer Sinn. Die aktuellste GFFX könnte beim 3DMark2003 tatsächlich schneller laufen als jetzt wenn man dem Treiber die Möglichkeit geben würde, richtig zu optimieren. Der Low-Level-Shader-Code gibt aber mehr oder weniger den Weg vor, wie die GraKa gefälligst zu rendern hat. Das beeinträchtigt die Leistung aber von dem Problem ist ATi genauso betroffen. ATi ist aber wohl schon weiter was Shader-Optimierung angeht.

[Exxtreme]

P.S. Ich bin gespannt, wann Demirug mein Posting ausseinander nimmt. :D

[Demirug]

Original geschrieben von Exxtreme
Lange Rede, kurzer Sinn. Die aktuellste GFFX könnte beim 3DMark2003 tatsächlich schneller laufen als jetzt wenn man dem Treiber die Möglichkeit geben würde, richtig zu optimieren. Der Low-Level-Shader-Code gibt aber mehr oder weniger den Weg vor, wie die GraKa gefälligst zu rendern hat. Das beeinträchtigt die Leistung aber von dem Problem ist ATi genauso betroffen. ATi ist aber wohl schon weiter was Shader-Optimierung angeht.

Deiner Schlussfolgerung kann ich mich nicht ganz anschliessen. Deine Argumentation setzt vorraus das der Compiler wirklich Semantik vernichtet hat. Dummerweise erlaubt es keine der Shaderhochsprachen überhaupt genügend Semantik in den Code zu packen. Es gibt zum Beispiel keine getrenten Datentypen für Farbe und Vektoren. Alles das gleiche. Aber selbst wenn es möglich ist viel Semantik in einen Shader zu packen muss der Programmierer dies immer noch tun. Können wir uns sicher sein das FM dies getan hätte? Ist es nicht wahrscheinlicher das man den Karten so wenig Information wie möglich mitgegeben hätte um eine möglichst grosses Belastung zu erreichen?
In diesem Fall wäre wir wieder bei Punkt X die IHVs analysieren den eigentlichen Sinn und Zweg des Shaders und benutzten eigene Varianten die das gleiche erreichen.

In der ganzen Geschichte kann IMHO niemand der beteiligten seine Hände in Unschuld waschen.

[Demirug]

Original geschrieben von Exxtreme
P.S. Ich bin gespannt, wann Demirug mein Posting ausseinander nimmt. :D

Warum sollte ich? Deine Zusammenfassung des Threads ist doch sehr treffend (ausser das OpenGL kein HLSL benutzt aber das ist nebensächlich). Meine Meinung ist ja bekannt und ich habe ja auch einen Vorschlag gemacht um die Vorteile beider Lösungen zu vereinen.

Das ich mit deiner Schlussfolgerung nicht konform gehe ist dann ja was anderes und hat IMHO nichts mit auseinadernehmen zu tun.

[Exxtreme]

Original geschrieben von Demirug
Deiner Schlussfolgerung kann ich mich nicht ganz anschliessen. Deine Argumentation setzt vorraus das der Compiler wirklich Semantik vernichtet hat. Dummerweise erlaubt es keine der Shaderhochsprachen überhaupt genügend Semantik in den Code zu packen. Es gibt zum Beispiel keine getrenten Datentypen für Farbe und Vektoren. Alles das gleiche. Aber selbst wenn es möglich ist viel Semantik in einen Shader zu packen muss der Programmierer dies immer noch tun. Können wir uns sicher sein das FM dies getan hätte? Ist es nicht wahrscheinlicher das man den Karten so wenig Information wie möglich mitgegeben hätte um eine möglichst grosses Belastung zu erreichen?
In diesem Fall wäre wir wieder bei Punkt X die IHVs analysieren den eigentlichen Sinn und Zweg des Shaders und benutzten eigene Varianten die das gleiche erreichen.

In der ganzen Geschichte kann IMHO niemand der beteiligten seine Hände in Unschuld waschen.
Ich habe auch nur das wiedergegeben, wie ich diesen Thread, den Zecki gepostet hat, verstanden habe. :)

Naja, ob und wieviel Semantik vernichtet wurde, kann ich nicht beurteilen. Aber anscheinend hat es NV geschafft einen Shader unterzuschieben, der keinerlei Qualitätsverlust mit sich bringt. Die Frage ist jetzt auch, ob dieser Shader ausschliesslich im 3DMark2003 keinen Qualitätsverlust verursacht, oder er auch in anderen Anwendungen keinen Qualitätsverlust verursachen würde.

Und ja, unschuldig ist keine der Parteien.

[Demirug]

Original geschrieben von Exxtreme
Ich habe auch nur das wiedergegeben, wie ich diesen Thread, den Zecki gepostet hat, verstanden habe. :)

In dem Thread prallen ja soviele Meinungen aufeinadern das es schwer zu sagen ist wer nun wie viel Recht hat.

Naja, ob und wieviel Semantik vernichtet wurde, kann ich nicht beurteilen.

Das Problem hat wohl jeder. Zumindestens habe ich in dem Thread keinen Beitrag gesehen in dem jemand wirklich jemand mit harten Zahlen den Unterschied belegen konnte oder wollte.

Aber anscheinend hat es NV geschafft einen Shader unterzuschieben, der keinerlei Qualitätsverlust mit sich bringt. Die Frage ist jetzt auch, ob dieser Shader ausschliesslich im 3DMark2003 keinen Qualitätsverlust verursacht, oder er auch in anderen Anwendungen keinen Qualitätsverlust verursachen würde.

Ja, die Frage ist dabei nur ob ein Hochsprachenshader genügend Semantik enthalten hätte um das gleiche Mass an Optimierung automatisch zu erreichen. Scheinbar enthält ja auch der DX-Shader genügend Information für die Optimierung. Aber auch hier kommt die Frage auf ob es automatisch möglich ist. Zuerst müsste man aber wissen was nVidia da überhaupt macht.

Wie gesagt glaube ich nicht das nVidia aleine eine andere API-Schnittstelle gereicht hätte um ihrer Problem auf einen Schlag zu lösen. Sie haben ja schon eine halbe ewigkeit gebraucht das mit dem umsortieren hinzubekommen und ihr eigener Hochsprachencompiler (Cg) ist ja nun auch weit weg von der Perfektion.

Was nVidia eher gebraucht hätte wäre:

-eine PS 2.0 Version die auch Festpunkt (FX12) erlaubt.
-ein Shadercompiler der von Anfang an das jetzige 2.A Profil unterstützt hätte.
-Entwickler die nicht blind auf ATI vertraut hätten. (ATI hatte aber früher durchaus das umgekehrte Problem daher kann ich ATI da keinen richtigen Vorwurf machen)

[Ailuros]

ATI hatte aber früher durchaus das umgekehrte Problem daher kann ich ATI da keinen richtigen Vorwurf machen.

...und wenn man jetzt versuchen wuerde Verantwortungen auszuteilen, wird der Thread wahrscheinlich nochmal etliche Seiten laenger....ein perpetuum mobile ;)

[DrumDub]

Original geschrieben von Ailuros
...und wenn man jetzt versuchen wuerde Verantwortungen auszuteilen, wird der Thread wahrscheinlich nochmal etliche Seiten laenger....ein perpetuum mobile ;)

hehe... das bringts auf den punkt. außerdem ist das ja auch nicht unser problem... ;)

[AchtBit]

Abschliessend moecht ich nur noch sagen, dass man nicht allen Beurteilungen blind glauben schenken sollte, denn es hat sich oft genug herrausgestellt, dass hinter so manchem Thema mehr Schein als Sein zu finden ist. Das meine ich jetzt voellig unabhaengig vom hier vorangegangenen Topic. ;)