PGR2 & GT - So nah an der Realität...

mia.max schrieb:
--=ZerO=-- schrieb:
Gabs da ein geheimes Hardware-Update bei der BOX???
Laut Specs kann die auch nur 6:1... :rolleyes:

Ju die Box kann auch "nur" S3TC (6:1).
Mehr Speicher hat sie trotzdem zur Verfügung 8-)

Hmm... Moment...
Hatte Nvidia nicht damals den S3TC Bug in allen GPU's? (Soll jetzt kein
bashen sein, ist mir nur grade wieder eingefallen...)

Die Frage ist eigentlich ob die Texturen überhaupt komprimiert werden/
eine Kompression notwendig ist. Ich denke beide XBOX und Cube
haben genügend speicher um bei durchschnittlichen Games auf
die Kompression zu verzichten...
 
resonic schrieb:
Die XBOX hat weit mehr Effekte usw.. auf Lager als der Cube.
Der Cube hat genau wie die PS2 den Vorteil das man nicht auf feste DX Algorithmen zurück greifen muss. Was du zudem auch noch unterschlägst ist die Tatsache das die Xbox pro Zyklus nur 2 und der Gamecube 4 Texturen pro Pixel legen kann.

Jetzt kommen wir zur Füllrate.. mei.. wird ja immer doller. Auch hier haste wohl keinen blassen Schimmer was da geht!?

Du redest so ein Scheiß, ehrlich. Die XBOX schafft pro renderpass 4 und der Cube 8 Texturen. Mit dem Unterschied das die XBOX 4fach Multisampling beherrscht. Was bedeutet das die XBOX bei 2 Texturen immernoch ihre 1 GP/s hat, die PS2 nur noch 0,6 und der Cube 0,3.


Das gute an der Xbox ist halt das sie pro Zyklus halt immer 2 texturen macht. Jedoch nicht über einen Peak von 31. Mio Polygonen kommt. Die PS2 Macht 75. Mio Polygone ohne Textur. 38 Mio. Polygone bei 1 Textur und halt 19 Mio. Bei 2 Texturen.

SCHWACHSINN! Wie oft noch! Die Fillrate hat NICHTS mit den Polygonen zu tun. Das machen die VErtexshader und die kommen auf 125 Millionen PPS Peak.

Damit bleibt mehr Spielraum offen da nicht zwangläufig alle Polygone texturiert werden müssen. Der Sinn hierbei ist das Sony versucht Details ausmodellieren zu lassen statt zu texturieren (Bsp. Skyline Rücklichter bei GT3). Welche Methode nun besser ist bleibt dahin gestellt da es jeweils eine andere Strategie ist. Fakt ist aber das bei der PS2 halt ein weitaus höherer Polygon-Durchsatz möglich ist, da die Möglichkeit besteht nicht zwangsläufig alle Polygone texturieren zu müssen. Bei der Xbox ist es hingegen egal ob 2, 1 oder keine Textur pro Polygon verwendet wird, die schafft immer nur maximal 31. Mio Polys. Somit sind bei der PS2 deutlich mehr Details im Polygonmodell und weitaus komplexere Szenen möglich als es bei der Xbox jemals sein könnte. Der Trend geht hier in eine ganz andere aber halt sinnvollere Lösung.

Beispielsweise müssten bei einem Fahrzeug z.B. nur bei einigen Polygonen Texturen verwendet und alle restlichen Details ausmodelliert werden.

Ohje.. ich gebs einfach auf, nur noch dummes Zeug!
 
RainbowSix schrieb:
resonic schrieb:
Die XBOX hat weit mehr Effekte usw.. auf Lager als der Cube.
Der Cube hat genau wie die PS2 den Vorteil das man nicht auf feste DX Algorithmen zurück greifen muss. Was du zudem auch noch unterschlägst ist die Tatsache das die Xbox pro Zyklus nur 2 und der Gamecube 4 Texturen pro Pixel legen kann.

Jetzt kommen wir zur Füllrate.. mei.. wird ja immer doller. Auch hier haste wohl keinen blassen Schimmer was da geht!?

Du redest so ein Scheiß, ehrlich. Die XBOX schafft pro renderpass 4 und der Cube 8 Texturen. Mit dem Unterschied das die XBOX 4fach Multisampling beherrscht. Was bedeutet das die XBOX bei 2 Texturen immernoch ihre 1 GP/s hat, die PS2 nur noch 0,6 und der Cube 0,3.


Ohje.. ich gebs einfach auf, nur noch dummes Zeug!


Hmm, stimmt, kommt viel dummes Zeug von Dir...
Die XBOX kommt bei maximaler, theoretischer Fillrate noch nichteinmal
auf 1GP/s... Maximal liegt die bei der BOX immernoch bei
933MP/s... und maximal bedeutet nicht unter Real-Bedingungen...
Also 1GP/s schafft die BOX nie... *klugscheiß*

Hmm vom Cube sind leider keine Maximalangaben bekannt
aber die dürften mindestens gleichauf sein...
 
--=ZerO=-- schrieb:
RainbowSix schrieb:
resonic schrieb:
Die XBOX hat weit mehr Effekte usw.. auf Lager als der Cube.
Der Cube hat genau wie die PS2 den Vorteil das man nicht auf feste DX Algorithmen zurück greifen muss. Was du zudem auch noch unterschlägst ist die Tatsache das die Xbox pro Zyklus nur 2 und der Gamecube 4 Texturen pro Pixel legen kann.

Jetzt kommen wir zur Füllrate.. mei.. wird ja immer doller. Auch hier haste wohl keinen blassen Schimmer was da geht!?

Du redest so ein Scheiß, ehrlich. Die XBOX schafft pro renderpass 4 und der Cube 8 Texturen. Mit dem Unterschied das die XBOX 4fach Multisampling beherrscht. Was bedeutet das die XBOX bei 2 Texturen immernoch ihre 1 GP/s hat, die PS2 nur noch 0,6 und der Cube 0,3.


Ohje.. ich gebs einfach auf, nur noch dummes Zeug!


Hmm, stimmt, kommt viel dummes Zeug von Dir...
Die XBOX kommt bei maximaler, theoretischer Fillrate noch nichteinmal
auf 1GP/s... Maximal liegt die bei der BOX immernoch bei
933MP/s... und maximal bedeutet nicht unter Real-Bedingungen...
Also 1GP/s schafft die BOX nie... *klugscheiß*

Doch schon sie schafft theoretisch:

3.728 GSamples/Sec mit 4-fachem Multisampling

;)

Aber hast schon recht, habe das nur von Resonic übernommen, es sind 932 MP!
 
Necrophorus schrieb:
Demnach müsste der GC mit seinen 648 Megapixel/s Pixelfüllrate ja die schwächste Konsole sein... :rolleyes:
Tja die 648MP/s sind "Reallife" Angaben...
Die theoretischen Maximalwerte dürften weit höher liegen!
mindestens 300.000MP/s ;)

Wobei zusätzlich zu beachten ist das alle Specs für den Cube
noch von der 405Mhz Version des GCN sind. Mittlerweile hat er 485Mhz...
... also alles relativ unaktuell...
 
virtuelle Funktion oder Klasse drüber gesetzt werden, welche die ursprüngliche Funktion entweder ersetzt oder ergänzt usw.
Das ist der Punkt! Wenn du nämlich nicht auf die DX Funktionen zurück greifen willst, was in den meissten Fällen der Fall sein dürfte, bist du dazu gezwungen die Funktion zu erweitern oder neu zu schreiben. Insofern besteht damit auch kein wirklicher Vorteil vor GC und PS2, wo man direkt einen zugriff auf die Hardware hat.

Zu Rainbows Kindergebrabel sag ich mal nix mehr, der hat sich ja nun schon von alleine disqualifiziert.

Was den GC angeht muss erwähnt werden das der Speicher dafür mit einem weitaus größeren Bus angebunden ist als bei der Xbox. Hier wird schliesslich genauso wie bei der PS2 geswappt und nicht alles in den Cache geschoben. Bei der Xbox stehen der GPU nämlich in der Theorie maximal 5.3GB/s (1.1GB/s für CPU) zur Verfügung. Beim GC sind es dagegen 2 MByte die als Cache für den Z-Buffer vorgesehen und mit 7,8 GByte/s angebunden sind. Dazu gesellt sich 1 MByte Textur-Cache, auf den der Grafikprozessor mit einer Transferrate von 10,4 GByte/s zugreifen kann. Da der Z-Buffer halt seinen eigenen Cache hat wird auch nicht der externe Bus belastet.

@mia.max
Direct 3D mache ich selber nicht, lern das alles von 2 befreundeten Codern :) Bin selber eher mit LW im 3D und eben auch im 2D Bereich unterwegs. Hauptsächlich Modelling und Texturing sowie alles was bei 2D anfällt :)
 
--=ZerO=-- schrieb:
Necrophorus schrieb:
Demnach müsste der GC mit seinen 648 Megapixel/s Pixelfüllrate ja die schwächste Konsole sein... :rolleyes:
Tja die 648MP/s sind "Reallife" Angaben...
Die theoretischen Maximalwerte dürften weit höher liegen!
mindestens 300.000MP/s ;)

:lol: Bei den Angaben gibts nur Peakwerte. Bei den Polygonmengen haben sie Realwerte angegeben und die zwei anderen Peak, aber nicht bei ner Fillrate! :lol: :lol: :lol:
 
Was den GC angeht muss erwähnt werden das der Speicher dafür mit einem weitaus größeren Bus angebunden ist als bei der Xbox. Hier wird schliesslich genauso wie bei der PS2 geswappt und nicht alles in den Cache geschoben. Bei der Xbox stehen der GPU nämlich in der Theorie maximal 5.3GB/s (1.1GB/s für CPU) zur Verfügung. Beim GC sind es dagegen 2 MByte die als Cache für den Z-Buffer vorgesehen und mit 7,8 GByte/s angebunden sind. Dazu gesellt sich 1 MByte Textur-Cache, auf den der Grafikprozessor mit einer Transferrate von 10,4 GByte/s zugreifen kann. Da der Z-Buffer halt seinen eigenen Cache hat wird auch nicht der externe Bus belastet.

Dafür ist der kleine Cache der XBOX 20GB/s schnell und beim Cube der Mainram nur ca. 2,6 GB/s.. harhar.. :lol:
 
resonic schrieb:
virtuelle Funktion oder Klasse drüber gesetzt werden, welche die ursprüngliche Funktion entweder ersetzt oder ergänzt usw.
Das ist der Punkt! Wenn du nämlich nicht auf die DX Funktionen zurück greifen willst, was in den meissten Fällen der Fall sein dürfte, bist du dazu gezwungen die Funktion zu erweitern oder neu zu schreiben. Insofern besteht damit auch kein wirklicher Vorteil vor GC und PS2, wo man direkt einen zugriff auf die Hardware hat.

*lol* noch einmal für dich:

1. auch auf der xbox kann man direkt auf die hardware zugreifen !

2. du hast wirklich kein bisschen verstanden was dx wirklich ist, wie's eingesetzt wird, was sdk's sind und wo der vorteil in objekt-orientierter programmierung liegt.
.... und es hat irgendwie auch wenig sinn mit jemanden zu diskutieren der von der sache keine ahnung hat.

nur noch soviel: was du da schreibst macht programmiertechnisch keinen sinn, aber wie soll man die vorteile von dx (oder opengl) auch verstehen, wenn man selbst noch nie damit gearbeitet hat...
resp. wenigstens mit anderen oo-sprachen programmiert hat (oder wenigstens überhaupt mal irgendwas programmiert hat).

noch n kleine hint für dich: direkt hardware ansteuerung, dass gewisse teile manuelle in asm-code (assembler) geschrieben werden.
kein einziges game wird aber heutzutage noch komplett in asm geschrieben... eben nur kleine teile, der rest erledigt das sdk.

auch dx ist ein sdk !
und nochma: auch sony und nintendo setzen sdk's ähnlich dx ein, nur sind diese dann halt auf ihre hardware abgestimmt.

omg... gibs auf, du diskutierst um ein thema bei dem du dich anscheinend nicht das kleinste bisschen auskennst.

edit:
resonic schrieb:
Direct 3D mache ich selber nicht, lern das alles von 2 befreundeten Codern Bin selber eher mit LW im 3D und eben auch im 2D Bereich unterwegs. Hauptsächlich Modelling und Texturing sowie alles was bei 2D anfällt

viel vom programmieren hast aber demfall noch nicht gelernt...
evtl. würd ich erstmal normales programmieren lernen, bevor du dich an COM Objekte ranwagst.
 
Hehe.. Das einzige Problem sind die pixelshader der XBOX. Diese Effekte sind wirklich aus ner Library rausgenommen und werden einfach verwendet wenn acuh immer etwas anders etc.. dafür ist sowas aber mit so einer Power wie Wasser auf nem Cube erst gar nicht darstellbar. Siehe Quantum Red´shift oder OPGR2. Wenn man sich ein wenig damit auskennt wird man schnell erkennen um wieviel mehr POwer die XBOX hat, auch wenn DX8 nicht das beste ist, aber besser als Cube und PS2 allemal, weit besser sogar. Da redet ihr imemr von der XBOX Power.. ich will ein GT4 sehen das ein Wasser genau wie bei Splashdown bietet und eine enorme Weitsicht mit massenweisen Polygonen dazu noch fetten Texturen und Lackeffekten etc.. das macht die XBOX alles, aber wenn man das nicht sehen will, sieht man es nicht. Einige reichen eben die einfachen PS2 Texturen...
 
resonic schrieb:
virtuelle Funktion oder Klasse drüber gesetzt werden, welche die ursprüngliche Funktion entweder ersetzt oder ergänzt usw.
Das ist der Punkt! Wenn du nämlich nicht auf die DX Funktionen zurück greifen willst, was in den meissten Fällen der Fall sein dürfte, bist du dazu gezwungen die Funktion zu erweitern oder neu zu schreiben. Insofern besteht damit auch kein wirklicher Vorteil vor GC und PS2, wo man direkt einen zugriff auf die Hardware hat.

Zu Rainbows Kindergebrabel sag ich mal nix mehr, der hat sich ja nun schon von alleine disqualifiziert.

Was den GC angeht muss erwähnt werden das der Speicher dafür mit einem weitaus größeren Bus angebunden ist als bei der Xbox. Hier wird schliesslich genauso wie bei der PS2 geswappt und nicht alles in den Cache geschoben. Bei der Xbox stehen der GPU nämlich in der Theorie maximal 5.3GB/s (1.1GB/s für CPU) zur Verfügung. Beim GC sind es dagegen 2 MByte die als Cache für den Z-Buffer vorgesehen und mit 7,8 GByte/s angebunden sind. Dazu gesellt sich 1 MByte Textur-Cache, auf den der Grafikprozessor mit einer Transferrate von 10,4 GByte/s zugreifen kann. Da der Z-Buffer halt seinen eigenen Cache hat wird auch nicht der externe Bus belastet.

Richtig.
Jedoch muss gesagt werden, dass die Xbox mit ihrer Speicherbandbreite von 6.4 GB/s (Abzüglich der Bandbreite für die CPU -> 0.8 GB/s, also 5.6 GB/s für die GPU) ihr komplettes Arsenal an Texturdaten durchfeuern kann per Frame, ohne dass die Pixelfüllrate beeinflusst wird. Bei 2 Texturen haben sowohl GC als auch PS2 schon größere Probleme.
 
Dafür ist der kleine Cache der XBOX 20GB/s schnell und beim Cube der Mainram nur ca. 2,6 GB/s.. harhar..
Und wo soll dieser Cache deiner Meinung nach stecken?
Siehe C'T -> http://www.heise.de/ct/02/05/106/default.shtml

@mia.max
Darauf will ich ja hinaus! Der Vorteil der DX Funktion entfällt komplett sofern man direkt per Assembler auf die Hardware zugreifen will und das wird schnell nötig um vor anderen Entwicklern einen Vorsprung zu haben. Es ist definitiv schneller und einfacher möglich gute Grafik hinzubekommen, das stimmt schon, jedoch geht hier ein Schuss Performance verloren.

also 5.6 GB/s für die GPU) ihr komplettes Arsenal an Texturdaten durchfeuern kann per Frame, ohne dass die Pixelfüllrate beeinflusst wird. Bei 2 Texturen haben sowohl GC als auch PS2 schon größere Probleme.
Sofern der Soundchip nicht auf den Speicher zugreift stehen ganze 5.3Gb/s zur Verfügung. Der Cube ist mit seinen 10.4GB/s weitaus besser dran, beides ist im Vergleich mit den weit über 40GB/s der PS2 aber gradezu mickrig.
 
Bei 2 Texturen haben sowohl GC als auch PS2 schon größere Probleme.

Richtig, bei 2 Texturen schon alleine sieht es so aus:

XBOX 932 MP/s
PS2 600 MP/s
Cube 324 MP/s

Dat werden dei Jungchen jetzt aber nur schwer schlucken können! :lol:
 
Dat werden dei Jungchen jetzt aber nur schwer schlucken können!
Bei einer Textur hat di Ps2 ihre Nase weit vorne und bei 4 Texturen lässt der Cube alles hinter sich. Wobei ich wie schon erwähnt auf die Tatsache hinweise das nicht alle Polygone mit 2 Texturen bzw. überhaupt einer Textur belegt werden müssen! Nach 5 Jahren 3D/2D weiß ich genau wie es beim Modelling und Texturing abläuft und wie schon gesagt geht man bei Sony halt dazu über teilweise Polygone nur mit einer Vertex Color zu versehen und Details auszumodellieren.
 
resonic schrieb:
@mia.max
Darauf will ich ja hinaus! Der Vorteil der DX Funktion entfällt komplett sofern man direkt per Assembler auf die Hardware zugreifen will und das wird schnell nötig um vor anderen Entwicklern einen Vorsprung zu haben. Es ist definitiv schneller und einfacher möglich gute Grafik hinzubekommen, das stimmt schon, jedoch geht hier ein Schuss Performance verloren.

der vorteil von dx entfällt komplett ???

dx selbst entfällt kein bisschen, weiss ned was du dir da für ne komische theorie zusammenreimst.

Wer manuell ASM coded hat das problem den code absolut perfekt programmieren zu müssen, wenn da etwas nicht stimmt kehrt sich der Performance-Vorteil schnell ins Gegenteil um.

Zudem wird ASM Code mit DX (resp. SDK-Befehlen und standart C++) kombiniert.
Da gehen keine Programmiervorteile verlohren, wär ja noch schöner.
 
Technical Data

NVIDIA XGPU

250 MHz
4 pixel pipelines
2 texels per pixel pipeline
8 texels per clock cycle (4 pixels with 2 texels per pixel)
Maximum of 4 texture layers per rendering pass (done in 2 clock cycles)
1.0 gigapixel per second
2.0 gigatexels per second
4.0 billion anti-aliased samples per second
Point, Bilinear, Trilinear, Anisotropic Mip-Map Filtering
Perspective-Correct Texture Mapping
DotProduct3 Bump Mapping (DOT3)
Environment Mapped Bump Mapping (EMBM)
Cubic Environment Mapping (CEM)
Volumetric Textures (3D Textures)
Z, Stencil, Shadow, and Multisampling buffers
S3TC and DirectX DXT1-DXT5 texture compression
Full-Scene Anti-Aliasing (2x, Quincunx, 4x)
Programmable Pixel and Vertex Shading Processors
2 Vertex Pipelines
125 million particles per second
125 million polygons per second (peak)
100 million polygons per second (sustained)
60 million polygons per second (with effects)
Triangle Tessellation
Z-buffer compression and Hidden Surface Removal (HSR) based on early Z-test
1 trillion operations per second (1000 BOPS)
95 to 116 GFLOPS (estimated)

Jaja... dann lag meine Rechnung ja soo daneben! :lol:

http://www.kingsgames.co.uk/xbox.htm
 
Wenn man das ganze in reinem DX codet geht viel Performance gegenüber eine Programmierung verloren, die großtenteil in Assembler geschrieben ist.

@Rainbow Six
:lol: :lol: :lol: :lol: Deine Quelle ist mal sowas von falsch^^ Hier wird nur 4 mal re-rendered. Daher auch die 125 Mio. Polys die in wirklichkeit nur 31 Mio. Polys sind. Genauso siehts da mit den 60 Mio. Polys aus!

" Most remeber the 4.0 GPixels on Microsoft's spec comparence sheet. Well, Microsoft was nice to include a "(anti-aliased)" next to it. What does "4.0 GPixels (anti-aliased)", mean? It's misleading. The Xbox has hardwired 4x FSAA, when this is turned on the actual total of 1.0 GPixels is re-rendered 4 times to remove aliasing."
 
Zurück
Top Bottom