Xbit-Labs testet Eignung des Semprons als OC-Chip

Original geschrieben von i_hasser

Das Schlimme ist, dass sich so Meinungen verbreiten weder Hand noch Fuß haben.
Genauso wie hier vor einer Weile ein Thread in einem anderen Forum gelinkt war - da behauptete jemand, die AMD CPUs seien wegen der anderen Ausführungszeiten für die Befehle inkompatibel zu Intel CPUs.
Auf den ersten Blick steckt da Technik dahinter, auf den 2. Blick ist es absoluter ...
Mach mich nicht sauer und stell mich nicht auf eine Stufe mit solchen Sachen.

Eigentlich hat die Auflösung da keinen Einfluss drauf, intern (also auf der Spiele-Enginge Ebene) läuft das ja sowieso alles in Floatpoint ab *noahnung*.
Oder meinst du, dass einfach die Pixel größer sind? *buck*
Das war ironisch gemeint.

Schon lange gibt es Techniken wie TnL, mit denen die GPU selbst die Vertexkoordinaten neu berechnet. Und seit 'neuerem' gibt es auch noch Pixel und Vertexshader, sowie deutlich mehr Möglichkeiten TnL in der GPU durchzuführen.
TnL - Texture and Lightning
http://www.tomshardware.de/news/19990801.html
Das Thema ist seit Jahren gegessen wie du siehst. Im Grunde sagt es nur, das man einer Textur auch einen Luminanzwert(eigenleuchten) mitgibt.

dieser Punkt stammt von einem älteren Beitrag dieses Threads:
Außerdem wird TnL heute leider noch sehr zaghaft benutzt, das würde die CPU schon sehr stark entlasten (Doom3 benutzt TnL zB. garnet).
Quake3 hat dieses Feature schon zum Erbrechen genutzt. Die Health-Packets sind selbstleuchtend - klassisches Beispiel für TnL - man braucht nur mit offenen Augen durch die Levels gehen um noch weitere zu finden.


Ein Beispiel was ich vorhin angesprochen hab ist Displacement Mapping (wurde gerade bei der Matrox Parhelia mit Trommeln und Trompeten eingeführt), das verdeutlicht die Sache imho sehr gut - die CPU schickt der GPU eine Heighmap und die GPU errechnet daraus selbstständig Vertexkoordinaten - die kann man dann über eine nicht-ebene Fläche legen, und so zB. ein Gesicht modelieren.
http://www.tomshardware.de/site/special/special1.html
Auf Seite 18 ist ein echt schönes Bildchen was Displacemant Mapping kann.
Kurz gefasst:
Man modelliert ein Gesicht beliebig Detailiert. Dann gibt man es in eine Art Compiler, der zerlegt dieses engmaschige Polygonnetz in ein weitmaschigeres Netz und eine Displacement Map.
Beides miteinander verknüpft in der GPU ergibt wieder das originale, detaillierte Polygonnetz.
Riesen Vorteil:
Die CPU hat nur noch eine sehr viel kleinere Anzahl an Polygone zu verschieben,rotieren.
Nehmen wir das Beispiel aus dem THG-Bericht. Der runzlige mann möchte den Mund öffnen.

Dies geschieht in der CPU:
Nun muss man alle Polygoneckpunkte um den Mund herum nach unten verschieben.
Sind die Punkte verschoben werden sie über glVertexPointer an die Graka weitergereicht.

Nun ist es ein riesen Unterschied ob man nur 500 "Kiefer"-Punkte verschieben muß oder 10.000"Kiefer"-Punkte.

500Punkte + Displacemant ergeben also dasselbe markante Kinn
wie 10.000Punkte. Nur müssen nach wie vor die geringere Anzahl an Polygone bewegt/berechnet werden.

Mit der Displacement Map lassen sich aber keine Haare erzeugen. Vielleicht ein 3-Tage-Bart, oder ein Bürstenschnitt, aber keine wallende Mähne. Dafür muss man schon Bezierkurven herbeibemühen.


Die anderen Sachen die du angesprochen hast (Raytracer usw.) haben mit den 3D APIs OpenGL, DirectX usw. garnix am Hut. Ein Raytracer funktioniert völlig anders als eine heutige Graka, das gilt auch für darauf aufbauende Programme.

Es gibt schöne Projekte wo versucht wurde mal einen Raytracer für Echtzeitgraphik zu schreiben. Ist imho was nettes rausgekommen, allerdings Leistungsmäßig nicht mit aktuellen Grakas zu vergleichen.
Mit der Erwähnung des Raytracers will ich eigentlich nur andeuten, wie dankbar ich Opengl das es mir dieses kleingefrickel Zeug erspart.


Core1 hat in der Zeit so ziemlich nix zu tun (hab ich schonmal gesagt...) und du hast ein Problem mit gelocktem Speicher (hab ich glaub ich auch schonmal gesagt, sowas wie ein Scratchpad gibt es bei x86 nicht offiziell). Und du simplifizierst den ganzen Ablauf viel zu stark. Beispielsweise muss erstmal die komplette KI Berechnung abgelaufen sein - das fehlt bei dir oben völlig.
Es gibt keinen gelockten Speicher, weil auch hier das Prinzip des zweiseitgen Buffers gilt. Der von mir beschriebene Shared Mem besteht aus zwei, wobei durch ein BufferSwitch(nur umhängen des Zeigers zum Synczeitpunkt) ein kollisionsfreies arbeiten ermöglicht.
Die KI wird komplett in Core1 berechnet und dann nicht mehr angefasst.


Und sagt dir eigentlich ein Vertex Buffer was? In sowas speichert man normalerweise bei statischen Objekten (also 90% aller Vertices) einmal die Vertexdaten und dann wird das in den GPU Speicher geschickt (und bleibt dort).
Für die Kollisionsberechnung braucht man aber trotzdem eine geometrisch ähnliche Abbildung im Hauptspeicher. Schon mal WipeOut 1 gezockt?
Wenn man hier komisch Abbiegt oder springt befindet man sich plötzlich ausserhalb der Fahrbahn, ein Beispiel für nicht allzu gute Kollisionsüberprüfung.

Eine Frage hab ich aber noch: Du hast 2mal auf die MSDN Pages gelinkt... wieso? Was interessieren mich die Speicherreservierungsfunktionen von Windoofs?
Jetzt kommt zum ersten mal bei dir auch Selbstironie ins Spiel *lol*
Vorhin schreibst du noch, das du bisher nur Erfahrung mit Direct3d im 3d-API-Sektor hast.
Ich habe meinen Vortrag auf einer Windoof-Kiste ausprogrammiert(du weisst schon Qualle und Rochen), da aber im Programmierraum nur Linux-Kisten standen musste ich schauen das auch das programmierte lief. Bei mir gab es keine Probleme, aber beim Thema Tesselation gab es schon sehr große Unterschiede zwischen der OpenGL-Spec und dem Linux-Treiber, wobei ich mich nicht über diese Tatsache lächerlich machen möchte.

Grüße,
Tom
 
Original geschrieben von i_hasser
Dumm nur, dass die CPU hauptsächlich an der Graphik rechnet...

??? Ich kann dir hier nicht mehr wirklich folgen. ???

Inwieweit sich der Grafikteil, der noch von der CPU berechnet wird, parallelisieren läßt, weiß ich nicht. Ich habe aber hauptsächlich von der KI geschrieben, und die läßt sich sehr stark parallelisieren. Daß die heute auch noch nicht sonderlich überragend ist, dürfte auch klar sein. Das meiste Zeugs ist immer noch vollständig gescriptet, was noch jede Menge Optimierungspotential offenbart. Wirklich autonome KI gibt es AFAIK in keinem Spiel. Der Grund dafür ist ganz einfach, daß die Rechenleistung dafür fehlt.
 
Original geschrieben von mocad_tom
Mach mich nicht sauer und stell mich nicht auf eine Stufe mit solchen Sachen.

Manchmal erzählst du aber schon ziemlich ziemlich weit hergeholte Sachen...


Das war ironisch gemeint.

Manchmal bin ich mir nicht mehr sicher was du ironisch meinst und was nicht. Nach meiner Sicht hättest du nämlich so einige Sachen ironisch meinen müssen...


TnL - Texture and Lightning
http://www.tomshardware.de/news/19990801.html
Das Thema ist seit Jahren gegessen wie du siehst. Im Grunde sagt es nur, das man einer Textur auch einen Luminanzwert(eigenleuchten) mitgibt.

NEIN! *heul* *traurig*

Jetzt ist zB. wieder so eine Situation.

Ich rede von TnL oder T&L - eingeführt mit der Geforce 256. Du redest auf einmal von irgend einer völlig anderen Technik und linkst auf einen THG Artikel, der geschrieben wurde als es TnL noch garnicht gab...

TnL bedeutet, dass die GPU auch Verschiebungen, Rotationen usw. (eben Transformationen) selbst berechnet... (nur so als kleiner Tipp am Rande ;)).

Also (merken!): TnL= Transform and Lightning

Quake3 hat dieses Feature schon zum Erbrechen genutzt. Die Health-Packets sind selbstleuchtend - klassisches Beispiel für TnL - man braucht nur mit offenen Augen durch die Levels gehen um noch weitere zu finden.
Quake3 kann das garnicht benutzt haben, weil es TnL damals noch garnicht gab.



http://www.tomshardware.de/site/special/special1.html
Auf Seite 18 ist ein echt schönes Bildchen was Displacemant Mapping kann.
Kurz gefasst:
Man modelliert ein Gesicht beliebig Detailiert. Dann gibt man es in eine Art Compiler, der zerlegt dieses engmaschige Polygonnetz in ein weitmaschigeres Netz und eine Displacement Map.
Beides miteinander verknüpft in der GPU ergibt wieder das originale, detaillierte Polygonnetz.
Riesen Vorteil:
Die CPU hat nur noch eine sehr viel kleinere Anzahl an Polygone zu verschieben,rotieren.
Nehmen wir das Beispiel aus dem THG-Bericht. Der runzlige mann möchte den Mund öffnen.

Ersteres hat nix mit Displacement Mapping zu tun. Das ist imho das Problem, du bist bei so einigen Sachen viel zu 'unsauber'.

Dies geschieht in der CPU:
Nun muss man alle Polygoneckpunkte um den Mund herum nach unten verschieben.
Sind die Punkte verschoben werden sie über glVertexPointer an die Graka weitergereicht.

Lass bitte den OpenGL speziefischen Krempel weg, das hat nix mit dem eigentlichen Displacement Mapping zu tun (wiedereinmal Thema 'unsauber').

Nun ist es ein riesen Unterschied ob man nur 500 "Kiefer"-Punkte verschieben muß oder 10.000"Kiefer"-Punkte.

500Punkte + Displacemant ergeben also dasselbe markante Kinn
wie 10.000Punkte. Nur müssen nach wie vor die geringere Anzahl an Polygone bewegt/berechnet werden.

Ja, das hab ich alles schon gesagt, warum wärmst du das nochmal auf??? (die Frage ist ernst gemeint, das bläht die Beiträge nur unnötig auf)

Eine Transformation von vielen Vertices um einen bestimmten Wert realisiert man übrigens über eine veränderte World-Matrix und nicht über Einzelverschiebungen.

Mit der Displacement Map lassen sich aber keine Haare erzeugen. Vielleicht ein 3-Tage-Bart, oder ein Bürstenschnitt, aber keine wallende Mähne. Dafür muss man schon Bezierkurven herbeibemühen.

Das hab ich auch nie und nirgends behauptet :]. Ich hab dir aber eine vergleichbare Technik erläutert, ich will jetzt nicht den gesamten DX9 Standard um mich werfen (weil ich ihn 1. nicht komplett kenne und einige Details erst nachlesen müsste, es 2. nicht zum Thema gehört und es 3. den Thread sprengen würde).


Mit der Erwähnung des Raytracers will ich eigentlich nur andeuten, wie dankbar ich Opengl das es mir dieses kleingefrickel Zeug erspart.

Aber was in 3 Teufelsnamen hat das denn mit dem Thema zu tun?


Es gibt keinen gelockten Speicher, weil auch hier das Prinzip des zweiseitgen Buffers gilt. Der von mir beschriebene Shared Mem besteht aus zwei, wobei durch ein BufferSwitch(nur umhängen des Zeigers zum Synczeitpunkt) ein kollisionsfreies arbeiten ermöglicht.
Die KI wird komplett in Core1 berechnet und dann nicht mehr angefasst.

Also mal langsam, du bringst hier elementare Sachen völlig durcheinander.

Gelockten Speicher hast du im RAM, nämlich wenn beide CPUs mit den selben Werten arbeiten müssen bzw. auf die selben Werte zugreifen müssen (liegen ein paar Bytes RAM im Cache der einen CPU kann die andere nicht davon ausgehen, dass der RAM in dem Moment konsistent ist da die CPUs Write Back Cache haben).

Was du mit irgend einem BufferSwitch willst weis ich ehrlich gesagt nicht, am ehesten würde das zum Page Flipping passen... nur was hat das bitteschön mit dem RAM zu tun???

Ich meine, sowas kann ich auch:

"Es können nicht mehrere CPUs die Graphik berechnen, weil das serielle Algorithmen sind die sich nicht über mehrere Threads mit verschiedenen CS:EIP Werten realisieren lassen. Des weiteren verhindert der Dirty-Status der WriteBack-Cache-Lines in der einen CPU den Zugriff der anderen CPU, die so garnicht an die Daten herankommen würde. Und zu guter letzt würden mehrere Threads nicht die nötige Synchronizität erreichen."

Klingt schön fachlich, ist aber inhaltlich gesehen Mist (wobei der Mist noch ganz gut zusammenpasst).

Für die Kollisionsberechnung braucht man aber trotzdem eine geometrisch ähnliche Abbildung im Hauptspeicher. Schon mal WipeOut 1 gezockt?
Wenn man hier komisch Abbiegt oder springt befindet man sich plötzlich ausserhalb der Fahrbahn, ein Beispiel für nicht allzu gute Kollisionsüberprüfung.

Ja, aber da reichen viel einfachere Formen aus. Es sei denn du willst einen Ego Shooter, wo ich mit meiner ASMD Rifle an der Nase des Gegners hängen bleiben kann *lol* (und selbst da würden für die Nase 10 Vertices ausreichen).

Gegenfrage: kennst du Tachyon?

Jetzt kommt zum ersten mal bei dir auch Selbstironie ins Spiel *lol*
Vorhin schreibst du noch, das du bisher nur Erfahrung mit Direct3d im 3d-API-Sektor hast.
Ich habe meinen Vortrag auf einer Windoof-Kiste ausprogrammiert(du weisst schon Qualle und Rochen), da aber im Programmierraum nur Linux-Kisten standen musste ich schauen das auch das programmierte lief. Bei mir gab es keine Probleme, aber beim Thema Tesselation gab es schon sehr große Unterschiede zwischen der OpenGL-Spec und dem Linux-Treiber, wobei ich mich nicht über diese Tatsache lächerlich machen möchte.

Grüße,
Tom

Inzwischen (schon seit einer ganzen Weile) bin ich auf Linux umgestiegen, desswegen interessiert mich der Speichermanager von Windoofs nicht sonderlich. Vor allem, da du mit malloc() sowieso einen Bereich zusammenhängenden Virtuellen Speicher bekommst. Selbst ein malloc(1<<27) gibt dir einen zusammenhängenden Bereich (falls du dich gerade fragst: das sind 128MB Ram).
Im physikalischen Speicher hängt das aber allerwahrscheinlichst nicht zusammen, das stört aber auch nicht.
 
Zurück
Oben Unten