Doom 3 auf Pandora? (Giga News)

[sbock]

Um es noch mal ganz klar zu sagen: Der Pandora Bericht beruft sich auf ein bestätigtes Web Interview mit Craigix.
Giga für schlechte recherche in diesem Fall zu kritisieren halte ich gelinde gesagt für unfair. Craigx hat den Namen Doom III doch nicht zufällig oder unbedacht gewählt. Er wollte Publicity und Doom III reißt nun mal mehr Leute vom Hocker. Open Sorce als solches interessiert in der Masse doch die wenigsten. Mit dem TV Bericht ist das passiert was gewollt war: Giga hat den Köder geschnappt und schon hat man eine schöne Werbung für umme.
Die Möglichkeit GP32x.com als Recherchequelle zu nutzen halte ich für gewagt: Für einen Außenstehenden ist es kaum möglich Fakten und Dichtung auseinanderzuhalten. Nein, Redakteure müssen sich an solche mehr oder minder offiziellen Interviews bzw. Angaben halten. Sich selber einen Eindruck vom Gerät zu machen scheidet ja im Augenblick wohl auch noch aus. Das Gerät ist noch nicht fertig.
Ob Giga die Headline nicht auch anders hätte formulieren können, ein Fragezeichen setzen oder den Bericht sachlicher präsentieren können, steht auf einem ganz anderen Blatt.

 

[Seraptin]

Dem muss ich auch zustimmen...

Ich persoenlich halte auch nicht allzuviel von den GIGA Moderatoren bzw. allgemein dem ganzen Aufbau von Giga. ABER man muss halt auch die Zielgruppe von ihnen sehen und das sind nunmal Kinder/Jugendliche im alter von 14 bis 18 Jahren die einfach nur zocken und nicht allzuviel drumherum wissen. Ich haette auch gerne eine Show die sich ein wenig mit dem ganzen dahinter, mit Hardware (nicht was is die neueste GraKa) usw. beschaeftigt, aber das will Giga wohl garnicht sein.

Ich finde es ja schon toll das man ueber Giga wenigstens vom Gp2x/Wiz/Pandora erfahren kann, mag es noch so "dilettantisch" sein. Der eine oder andre wechselt so vielleicht die schiene und probiert mal etwas neues aus und das wollen wir schliesslich.

 

[hans-wurst]

*schmoll* Gehöre ich jetzt auch mit zu der Zielgruppe Kinder/Jugendliche?

 

[Seraptin]

^^

Naja man kann Giga schon auch als Erwachsener anschauen, nur finde ich eben das dass Programm immer mehr auf diese Zielgruppe zugeschnitten wird. <_<

 

[wejp]

Mit einem 1,5GHz Pentium 4 unter Windows dürfte der OMAP bei guter Programmrierung leicht mithalten können.

Ich habe mich extra wegen dieser Bemerkung in diesem Forum angemeldet: NIE im Leben! Ich habe schon einiges auf ARM programmiert, der Cortex ist zwar ein anderes Kaliber als ein ARM9, ich würde den Cortex aber ohne die Koprozessoren auf etwa Pentium-MMX-Niveau ansiedeln (was aus 300mW Leistungsaufnahme schon ein ausgesprochenes technisches Wunder ist!). Und Doom III setzt ja nun auch ein paar Koprozessoren a.k.a. eine dicke Grafikkarte voraus, d.h. die Koprozessoren werden den Kohl nicht fett machen.

Ob der OMAP mit einem 1,5 GHz Pentium 4 mithalten kann, sei mal dahin gestellt. Aber deine Aussage bzgl. der Performance ist völlig falsch. Ein ARM Cortex A8 spielt in einer komplett anderen Liga, als ein Pentium MMX. Selbst wenn man den Cortex mit dem selben niedrigen Takt laufen lassen würde, wie ein Pentium MMX (maximal 233 MHz), wird der Cortex erheblich schneller sein.
Ein Pentium MMX dürfte eher auf dem Level vom ARM9 liegen, was die Integer-Performance angeht. Wenn man natürlich irgendwelche Fließkommaberechnungen durchführt, und darauf seinen Vergleich basieren lässt, ist das natürlich reichlich unfair für den ARM-Prozessor und dazu noch ziemlich sinnlos, da man kaum ernsthaft fließkommalastige Anwendungen auf so einer CPU laufen lassen wird.

 

[Anonymous]

Aber deine Aussage bzgl. der Performance ist völlig falsch. Ein ARM Cortex A8 spielt in einer komplett anderen Liga, als ein Pentium MMX. Selbst wenn man den Cortex mit dem selben niedrigen Takt laufen lassen würde, wie ein Pentium MMX (maximal 233 MHz), wird der Cortex erheblich schneller sein.

Glaube ich nicht. Aber tatsächlich meinte ich einen Vergleich pro MHz, nicht absolute Geschwindigkeit.

Ein Pentium MMX dürfte eher auf dem Level vom ARM9 liegen, was die Integer-Performance angeht.

Nein! Ein ARM9 kann einen Integerbefehl alle zwei Takte starten, sind die Register unabhängig, kann er einen Integerbefehl pro Takt starten. Der erste Pentium war bereits superskalar, das heißt, er konnte mehr als einen Befehl pro Takt starten (einer musste dabei aus dem vollen Befehlssatz entstammen und der zweite aus einem reduzierten, der nur einfachere Befehle enthielt). Der Cortex A8 ist nun auch superskalar und damit von der Architektur wenigstens auf Pentiumniveau. Er ist sicherlich höher getaktet und verfügt auch über eine Vektoreinheit. Diese ist beim Pentium mit dem MMX eingeführt worden. Eine FPU hatte der Pentium auch schon immer. Was der Pentium zweifellos nicht hat, ist ein DSP, der ist aber nicht Teil des ARM. Außerdem wird man dafür komplexe Codeanpassungen vornehmen müssen, um den gewinnbringend einzusetzen. Eine vollwertige Portierung von Doom3 dürfte dadurch kaum machbarer werden.

Ach, und die Compiler für ARM sind ziemlicher Schrott, da geht auch noch mal viel Leistungspotential verloren.

Wenn man natürlich irgendwelche Fließkommaberechnungen durchführt, und darauf seinen Vergleich basieren lässt, ist das natürlich reichlich unfair für den ARM-Prozessor und dazu noch ziemlich sinnlos, da man kaum ernsthaft fließkommalastige Anwendungen auf so einer CPU laufen lassen wird.

In Engines wie Doom3 wird inzwischen fast alles in Fließkomma gemacht. Beleuchtung, Schattenwurf, prozedurale Texturen, Bump Mapping, Displacement Mapping usw. werden nicht mehr wie in den frühen Demos über Tricks, Fake-Texturen und vor allem Integercode hingezaubert, sondern in FPU und Vektoreinheit korrekt berechnet. Was hierbei den Cortex weit hinter jeden Desktopprozessor der Pentiumklasse zurückfallen lassen wird, ist die Speicherbandbreite und der Cache. Einfaches Texturemapping kommt prinzipiell mit einem Speicherzugriff pro Pixel aus. Kommen Antialiasing, Lightsourcing, Bump Mapping & Co hinzu, multiplizieren sich die Zugriffe auf den Speicher. Spätestens hier wird der Cortex nicht im Entferntesten mithalten können.

Es ist ja nicht so, dass ich nicht begeistert auf die Pandora warten würde. Zudem bin ich ein großer Freund der ARM-Architektur (ich programmiere mehr in Assembler als in Hochsprachen), aber man sollte realistisch bleiben. Und es darf ruhig gesagt werden: ein Prozessor, der mit 0,3 Watt Leistungsaufnahme das macht, was der Cortex A8 macht, ist ein technisches Wunder. Aber bitte trotzdem immer auf dem Boden der Tatsachen bleiben...

 

[wejp]

Ein Pentium MMX dürfte eher auf dem Level vom ARM9 liegen, was die Integer-Performance angeht.

Nein! Ein ARM9 kann einen Integerbefehl alle zwei Takte starten, sind die Register unabhängig, kann er einen Integerbefehl pro Takt starten. Der erste Pentium war bereits superskalar, das heißt, er konnte mehr als einen Befehl pro Takt starten (einer musste dabei aus dem vollen Befehlssatz entstammen und der zweite aus einem reduzierten, der nur einfachere Befehle enthielt). Der Cortex A8 ist nun auch superskalar und damit von der Architektur wenigstens auf Pentiumniveau. Er ist sicherlich höher getaktet und verfügt auch über eine Vektoreinheit. Diese ist beim Pentium mit dem MMX eingeführt worden. Eine FPU hatte der Pentium auch schon immer.

Dass man keine Vergleiche machen darf, die eine FPU benötigen, hatte ich doch bereits gesagt. Das ist ganz klar.
MMX vom Pentium mit der NEON-Erweiterung vom Cortex zu vergleichen ist aber recht albern. Klar, beides sind gewissermaßen "Vektoreinheiten" weil sie mehrere Eingabedaten gleichzeitig bearbeiten können. Das war es dann mit der Ähnlichkeit aber auch. NEON ist erheblich leistungsfähiger als MMX.

Die Theorie ist ja schön und gut, die Praxis sieht aber etwas anders aus. Nehmen wir doch mal ein einfaches Beispiel, wie einen (Integer-)MP3-Dekoder. Deiner Aussage nach, müsste der ja auf einem (sagen wir mal gleich schnell getakteten) Pentium erheblich schneller laufen, als auf einer ARM9-CPU. Wieso tut er das aber nicht, wenn der Pentium doch so viel schneller ist und dazu noch die ARM-Compiler so schlecht sind?

Die Speicheranbindung ist bei ARM-CPUs ohne Frage oft sehr langsam verglichen mit Desktop-Computern. Ein Pentium konnte allerdings auch nicht grade mit einer überragend schnellen Speicheranbindung glänzen.

 

[fusion_power]

Ach, und die Compiler für ARM sind ziemlicher Schrott, da geht auch noch mal viel Leistungspotential verloren.

Du klingst, als hättest du Ahnung von der Materie.
ABer ich hoffe, du irrst dich mit den ARM Compilern. Wenn mich was stört, dann vorhandene Super-Hardware die aber gar nicht effektiv und in vollem Umfang genutzt werden kann (genutzt wird), was für ne Verschwendung von Ressourcen. (Siehe PC und unoptimierte Software aber da is es wohl ehr die Faulheit der Programmierer und die schiere Rohpower der heutigen Prozessoren)

Ich hoffe eben im Falle der Pandora, dass der OMAP auch effizient genutzt wird und zeigen kann, was in ihm steckt. Wer will schon ein einfaches Homebrew-Pong Game, dass 500MHz braucht um halbwegs flüssig zu laufen. :lol:

 

[EvilDragon]

Was ich mich immer frage... warum laufen auf dem veralteten gp2x mit schlechterem Prozessor und nur 200 MHz die meisten Emulatoren deutlich schneller als auf meinem alten PC mit 1 GHz?
Sind die soviel besser programmiert?

 

[wejp]

Ach, und die Compiler für ARM sind ziemlicher Schrott, da geht auch noch mal viel Leistungspotential verloren.

Du klingst, als hättest du Ahnung von der Materie.
ABer ich hoffe, du irrst dich mit den ARM Compilern. Wenn mich was stört, dann vorhandene Super-Hardware die aber gar nicht effektiv und in vollem Umfang genutzt werden kann (genutzt wird), was für ne Verschwendung von Ressourcen. (Siehe PC und unoptimierte Software aber da is es wohl ehr die Faulheit der Programmierer und die schiere Rohpower der heutigen Prozessoren)

Ich hoffe eben im Falle der Pandora, dass der OMAP auch effizient genutzt wird und zeigen kann, was in ihm steckt. Wer will schon ein einfaches Homebrew-Pong Game, dass 500MHz braucht um halbwegs flüssig zu laufen. :lol:

Die Aussage mit den schrottigen ARM-Compiliern kommt wohl daher, dass der GCC bis vor garnicht so langer Zeit tatsächlich ziemlich unoptimierten ARM-Code erzeugt hat. Mit aktuellen GCC-Versionen hat sich das aber durchaus schon verbessert.

Was ich mich immer frage... warum laufen auf dem veralteten gp2x mit schlechterem Prozessor und nur 200 MHz die meisten Emulatoren deutlich schneller als auf meinem alten PC mit 1 GHz?
Sind die soviel besser programmiert?

Tja, da lautet die Antwort wohl tatsächlich ja. Auf dem GP2X muss man halt optimieren, wenn die Geschwindigkeit noch nicht reicht, um ein brauchbares Ergebnis zu erzielen - abgesehen von einem gewissen Übertaktungspotenzial ist die Hardware ja ziemlich unveränderlich. Auf dem PC erhöht man einfach die Systemanforderungen der Software, dann läuft es eben nicht auf dem 1 GHz-Rechner, sondern erst ab 1,5 GHz.

 

[hans-wurst]

Auf dem PC erhöht man einfach die Systemanforderungen der Software

Jetzt weiß ich warum Vista so hohe Anforderungen hat, man nimmt sich das einfach raus ohne vielleicht zu optimieren!

 

[fusion_power]

Was ich mich immer frage... warum laufen auf dem veralteten gp2x mit schlechterem Prozessor und nur 200 MHz die meisten Emulatoren deutlich schneller als auf meinem alten PC mit 1 GHz?
Sind die soviel besser programmiert?

Jupp, der GP2X ist ein super Beispiel, was man alles aus der Hardware rausholen kann, wenn man gescheit optimiert. Ich sag nur Picodrive und SVP Chip, da sieht mein "GENS" Emu am PC alt aus.
Dass CPS2 Games sammt QSound auf dem GP2X flüssig laufen hätt ich anfangs auch nicht gedacht. Aber dank diesem irren, unbekannten Japaner, der den CPS2 EMU in nur einem Monat perfekt für unseren Handheld umgesetzt hat, können wir uns auch daran erfreuen.

Es ist zwar längst nicht jede Homebrew Software so gut gecodet und optimiert, wie wir es von den Vorzeige-Sahnestücken auf dem GP2X kennen aber dank der limitierten Hardware des GP2X wird der geneigte Coder wohl meißtens schon automatisch genauer hinsehn, bevor er Ressourcen verschwendet. Sowas würd ich mir auch von PC Programmen wünschen.

Auf der Pandora gehen bestimmt noch krassere Sachen ab, im Moment läuft ja noch alles unoptimiert und in Software. Wer weiß, was z.B. notaz noch so alles aus seinem Sega Emulator rausholt, wenn er richtig die Hardware ausquetscht.
Nur darf es nicht passieren, dass die Coder wegen der schieren Rohpower der Pandora nur noch unoptimierte Programme abliefern, die zwar flüssig läuft aber viel mehr MHz und damit auch Akkulaufzeit braucht, als nötig währe... aber da mach ich mir nicht zu große Sorgen, es gibt ja genug gute Programmierer.

 

[Anonymous]

Deiner Aussage nach, müsste der ja auf einem (sagen wir mal gleich schnell getakteten) Pentium erheblich schneller laufen, als auf einer ARM9-CPU. Wieso tut er das aber nicht

Tut er nicht? Derselbe Code auf einem Linuxsystem mit gcc übersetzt? Würde mich stark wundern, wenn der Pentium nicht schneller wäre, lasse mich aber gerne anhand von Fakten belehren.

 

[Anonymous]

Die Aussage mit den schrottigen ARM-Compiliern kommt wohl daher, dass der GCC bis vor garnicht so langer Zeit tatsächlich ziemlich unoptimierten ARM-Code erzeugt hat. Mit aktuellen GCC-Versionen hat sich das aber durchaus schon verbessert.

Naja, ich habe in letzter Zeit eine ganze Menge Kompilate aktuellerer gcc-Versionen unter der Nase gehabt und da einige ziemliche Schoten gesehen. Insbesondere ignoriert der gcc ganz offensichtlich die Registerabhängigkeitsgeschichte beim ARM9. Da wird gnadenlos Code dieser Art produziert:

op1 r0, r1, r2
op2 r3, r4, r0
op3 r5, r6, r7
op4 r8, r9, r5

Durch schlichtes Umstellen der Reihenfolge auf op1, op3, op2, op4 wäre die Geschwindigkeit des Codes mal eben doppelt so hoch. Allerdings will ich für die verwendeten Compiler-Parameter nicht meine Hand ins Feuer legen...

 

[wejp]

Deiner Aussage nach, müsste der ja auf einem (sagen wir mal gleich schnell getakteten) Pentium erheblich schneller laufen, als auf einer ARM9-CPU. Wieso tut er das aber nicht

Tut er nicht? Derselbe Code auf einem Linuxsystem mit gcc übersetzt? Würde mich stark wundern, wenn der Pentium nicht schneller wäre, lasse mich aber gerne anhand von Fakten belehren.

Nein, tut er nicht. Der selbe Code (nimm beispielsweise mpg123 mit dem generic-no-fpu-decoder, natürlich auf beiden CPUs den selben Decoder benutzen), jeweils mit gcc übersetzt. (Der Pentium-optimierte Decoder vom mpg123 ist auf dem Pentium zwar schneller, als der Integer-Decoder auf der ARM9-CPU, allerdings auch nicht doppelt so schnell.)

Ach übrigens, ein ARM-Cortex kann mit Hilfe der NEON-Erweiterung MP3 bei 10 MHz CPU-Takt dekodieren. Das schafft definitiv kein Pentium, auch nicht bei Zuhilfenahme von MMX.

Die Aussage mit den schrottigen ARM-Compiliern kommt wohl daher, dass der GCC bis vor garnicht so langer Zeit tatsächlich ziemlich unoptimierten ARM-Code erzeugt hat. Mit aktuellen GCC-Versionen hat sich das aber durchaus schon verbessert.

Naja, ich habe in letzter Zeit eine ganze Menge Kompilate aktuellerer gcc-Versionen unter der Nase gehabt und da einige ziemliche Schoten gesehen. Insbesondere ignoriert der gcc ganz offensichtlich die Registerabhängigkeitsgeschichte beim ARM9. Da wird gnadenlos Code dieser Art produziert:

op1 r0, r1, r2
op2 r3, r4, r0
op3 r5, r6, r7
op4 r8, r9, r5

Durch schlichtes Umstellen der Reihenfolge auf op1, op3, op2, op4 wäre die Geschwindigkeit des Codes mal eben doppelt so hoch. Allerdings will ich für die verwendeten Compiler-Parameter nicht meine Hand ins Feuer legen...

Wäre interessant, was für Compileflags verwendet wurden und welche GCC-Version. Gerade bei aktuellen GCC-Versionen >4.1 hat sich ja doch mal was getan, bei der ARM-Optimierung. Mit -O0 wird natürlich nichts optimiert, wobei bei deinem Beispiel die Frage ist, ob das überhaupt eine "Optimierung" ist. Das sollte man ja schon erwarten, dass der Compilier solche Eigenheiten der CPU kennt.

 

[Anonymous]

Der selbe Code (nimm beispielsweise mpg123 mit dem generic-no-fpu-decoder, natürlich auf beiden CPUs den selben Decoder benutzen), jeweils mit gcc übersetzt. (Der Pentium-optimierte Decoder vom mpg123 ist auf dem Pentium zwar schneller, als der Integer-Decoder auf der ARM9-CPU, allerdings auch nicht doppelt so schnell.)

Problem: ich habe zwar durchaus einen ARM9 verfügbar, aber keinen Pentium oder Pentium MMX

Ach übrigens, ein ARM-Cortex kann mit Hilfe der NEON-Erweiterung MP3 bei 10 MHz CPU-Takt dekodieren. Das schafft definitiv kein Pentium, auch nicht bei Zuhilfenahme von MMX.

Naja, die TI-Prozessoren sind ja nun von vornherein auf das Kodieren und Dekodieren zugeschnitten (wobei das bisher eher in einer TI-eigenen Vektorengine geschah als mit dem ARM-Teil), von daher ist mp3 vielleicht nicht so der faire Maßstab, wenn man von einer FPU-lastigen general-purpose Aufgabe wie Doom3 ausgegangen ist. Schon der DM270 von TI konnte 640x480 MPEG4 Videos in Echtzeit enkodieren, was normale CPUs schon herausfordert. Dafür kam er auf der GP-CPU-Seite mit einem lachhaften 80 MHz ARM7 daher...

 

[wejp]

Der selbe Code (nimm beispielsweise mpg123 mit dem generic-no-fpu-decoder, natürlich auf beiden CPUs den selben Decoder benutzen), jeweils mit gcc übersetzt. (Der Pentium-optimierte Decoder vom mpg123 ist auf dem Pentium zwar schneller, als der Integer-Decoder auf der ARM9-CPU, allerdings auch nicht doppelt so schnell.)

Problem: ich habe zwar durchaus einen ARM9 verfügbar, aber keinen Pentium oder Pentium MMX

Ich habe beide CPU-Typen (Pentium und Pentium MMX) noch irgendwo rumfliegen und auch ein geeignetes Board. Eine ARM9-CPU habe ich ja im GP2X. Falls ich mal echt zu viel Zeit über haben sollte, kann ich mal genau die Zeit ausmessen, die jede der CPUs für das Dekodieren einer bestimmten Datei braucht. Ich kann allerdings nicht versprechen, dass ich das in nächster Zeit schaffe, da ich wieder echt viel zu tun habe.

Ach übrigens, ein ARM-Cortex kann mit Hilfe der NEON-Erweiterung MP3 bei 10 MHz CPU-Takt dekodieren. Das schafft definitiv kein Pentium, auch nicht bei Zuhilfenahme von MMX.

Naja, die TI-Prozessoren sind ja nun von vornherein auf das Kodieren und Dekodieren zugeschnitten (wobei das bisher eher in einer TI-eigenen Vektorengine geschah als mit dem ARM-Teil), von daher ist mp3 vielleicht nicht so der faire Maßstab, wenn man von einer FPU-lastigen general-purpose Aufgabe wie Doom3 ausgegangen ist. Schon der DM270 von TI konnte 640x480 MPEG4 Videos in Echtzeit enkodieren, was normale CPUs schon herausfordert. Dafür kam er auf der GP-CPU-Seite mit einem lachhaften 80 MHz ARM7 daher...

Ja, aber der NEON-Teil ist ja tatsächlich ein Teil der ARM-CPU, halt vergleichbar mit den CPU-Erweiterungen bei x86-CPUs (wie z.B. MMX beim Pentium). Sicher ist auch diese Erweiterung genau auf solche Aufgaben zugeschnitten, aber MMX ist ja auch eine "Multimedia-Erweiterung", da sollte man ja erwarten können, dass die auch darauf optimiert ist. :wink:

 

[Nr.56]

Was ist das Spiel? Ein First-Person-Shooter mit exzellenter Grafik. Wenn ich nun die Grafik (Texturen und Polygonanzahl) entsprechend runterschraube und die Level und "Rätsel" noch genauso funktionieren, kann ich es auch auf anderen Hardwares unter dem Namen "Doom3" anbieten. Das sieht dann aber eben aus wie besagtes "Defender of the Crown" auf dem C=64. Am Beispiel Doom3 könnte man auch in der Quake2-Engine die Levels nachbauen und dann von "Doom3" reden, allein es ist nicht vergleichbar mit dem Doom3 vom PC.

Okay, wir haben eine deutlich geringere Aufloesung, bei einer deutlich kleineren Bilddiagonale. Wenn man eben dieses in unsere Betrachtungen einbezieht und die Texturgroesse prozentual anpasst haben wir 2 Fliegen mit einer Klappe geschlagen: Speicherverbrauch drastisch reduziert und Rechenleistung gespart, wobei die Optik nicht leidet (vermutlich nicht einmal wenn Polygone reduziert werden) . Das Bild ist vergleichbar (aber natuerlich kleiner) als am PC.
Quake 2 z.B. sieht auf einem kleinen Display (logischerweise) deutlich besser aus (und natuerlich schaerfer) als auf einem Monitor. Man koennte also deutlich Texturqualitaet abbauen um ein Bild aehnlich dem PC zu erreichen.

... abwarten und Tee trinken! :wink:

 

[shure]

[editiert] info wurde schon gebracht

lief wie hier shcon erwähnt auf einem 733mhz 64mb ram system wieso sollte es da mit der pandora nicht klappen ?

 

[Anonymous]

kennt ihr noch diese etwas klobige ältere konsole namens Xbox ? ja darauf gab es auch einmal doom3 ;D

Das wurde hier ja durchaus erwähnt...