Gpsp2x v9006 - erste öffentliche Beta!

[Damien]

Na da bin ich ja mal gespannt... Ich hoffe das die Jungs es so gut wie möglich optimieren OHNE den zweiten Prozessor zu nutzen, denn dass würde ja den Stromverbrauch unterwegs wieder in die Höhe schrauben...

 

[Elektranox]

Na da bin ich ja mal gespannt... Ich hoffe das die Jungs es so gut wie möglich optimieren OHNE den zweiten Prozessor zu nutzen, denn dass würde ja den Stromverbrauch unterwegs wieder in die Höhe schrauben...

Es wird gerade heftigst vom ursprungsautor überarbeitet (zottd hat ja nen PSP Emulator als Basis genommen, der Autor hat jetzt auch ne GP2X ). Er hat schon bekannt gegeben, dass er das dynarec verändert hat, so dass der Code übersichtlich und besser ist. Mal sehen

 

[TheDark]

Meine Kirby-Sucht ist wieder auf ihrem Höhepunkt :lol:

 

[fusion_power]

Auf dem stark von Exophase optimierten DynaRec läuft schon das Bios und ein paar kleinere Spiele

Auf dem GPSP Emu den ich hab laufen auch große Spiele :lol:
Nun, super,dass der Exophase anscheinend richtig ranklotzt, laut seinem Blog:
http://gpsp-dev.blogspot.com/
Nur versteh ich meißt nur Bahnhof. Vieleicht kann ein Experte das hier ab und an zusammenfassen. (Yo, Eds Post war eigentlich schon ne Zusammenfassung, ^_^ )

Also ich währe für den 2. Prozessor, der kann ja richtig Speed rausholen, siehe PicoDrive. Ich wundere mich noch immer warum das nicht gleich bei den anderen Emus eingebaut wird, für Sound scheint es ja richtig was zu bringen. :huh:
Und wegen Batterieverbrauch: natürlich muss auch ne Option zum deaktivieren des 2. Prozessors her. Bei weniger aufwendigen MD Games hab ich den in Picodrive auch aus.

 

[Elektranox]

Auf dem stark von Exophase optimierten DynaRec läuft schon das Bios und ein paar kleinere Spiele

Auf dem GPSP Emu den ich hab laufen auch große Spiele :lol:
Nun, super,dass der Exophase anscheinend richtig ranklotzt, laut seinem Blog:
http://gpsp-dev.blogspot.com/
Nur versteh ich meißt nur Bahnhof. Vieleicht kann ein Experte das hier ab und an zusammenfassen. (Yo, Eds Post war eigentlich schon ne Zusammenfassung, ^_^ )

Also ich währe für den 2. Prozessor, der kann ja richtig Speed rausholen, siehe PicoDrive. Ich wundere mich noch immer warum das nicht gleich bei den anderen Emus eingebaut wird, für Sound scheint es ja richtig was zu bringen. :huh:
Und wegen Batterieverbrauch: natürlich muss auch ne Option zum deaktivieren des 2. Prozessors her. Bei weniger aufwendigen MD Games hab ich den in Picodrive auch aus.

das liegt daran, dass es gar nicht so einfach ist für die 2. CPU zu programmieren

 

[Beltar]

[

das liegt daran, dass es gar nicht so einfach ist für die 2. CPU zu programmieren

Also wenn ich nicht falsch informiert bin regelt das beim PC das Betriebssystem das die Threads aufgeteilt werden.

Was muss man denn beim GP2x machen das der die zweite nutzt?

 

[sbock]

[

das liegt daran, dass es gar nicht so einfach ist für die 2. CPU zu programmieren

Also wenn ich nicht falsch informiert bin regelt das beim PC das Betriebssystem das die Threads aufgeteilt werden.

Was muss man denn beim GP2x machen das der die zweite nutzt?

Ja, unter normalen Umständen regelt das Betriebssystem die Aufteilung der Threads. Um das machen zu können, braucht das Programm allerdings mehr als einen Thread und da muß dann nun auch der Entwickler ran.
Beim GP2x wird die 2. CPU von Linux garnicht als solche erkannt. Also muß der Programmierer sein Programm für die 2. CPU optimieren.

Viele Emulatoren nutzen von Haus an nur einen Thread. So gesehen ist es also generell kein Nachteil, daß das Betriebssystem sich beim GP2x nicht um die Aufteilung kümmert.
Ein viel größerer Nachteil ist, daß es sehr schwer ist, mit der 2. CPU etwas brauchbares anzufangen, aufgrund der technischen Implementierung.

Gruß,
Stephan

 

[Beltar]

Ja, unter normalen Umständen regelt das Betriebssystem die Aufteilung der Threads. Um das machen zu können, braucht das Programm allerdings mehr als einen Thread und da muß dann nun auch der Entwickler ran.
Beim GP2x wird die 2. CPU von Linux garnicht als solche erkannt. Also muß der Programmierer sein Programm für die 2. CPU optimieren.

Viele Emulatoren nutzen von Haus an nur einen Thread. So gesehen ist es also generell kein Nachteil, daß das Betriebssystem sich beim GP2x nicht um die Aufteilung kümmert.
Ein viel größerer Nachteil ist, daß es sehr schwer ist, mit der 2. CPU etwas brauchbares anzufangen, aufgrund der technischen Implementierung.

Gruß,
Stephan

Also bringt das nichts wenn ich einfach mein Programm in threads aufteile

 

[sbock]

Also bringt das nichts wenn ich einfach mein Programm in threads aufteile

Also ob es generell "einfach" ist, ein Programm in mehrere Threads aufzuteilen bezweifle ich. Aber nein, man muß beim GP2x dem Programm schon explizit sagen, was es denn auf dem zweiten Prozessor machen soll.
Aufgrund von Limitierungen der Hardware, sind auch nur ganz bestimmte Aufgaben sinnvoll. Nur weil bei PicoDrive die FM und MP3 Emulation gut auf dem 940 laufen, bedeutet das noch lange nicht, daß Gpsp von einer Soundausgabe mit 2 CPUs profitieren muß. Möglicherweise gibt es bei der GBA Emulation andere Dinge, die sich auslagern lassen...

Gruß,
Stephan

 

[fusion_power]

Ich dachte, wenn das mit der 2. CPU erst einmal einer gemacht hat, braucht man nur seinen Quellcode in die jeweiligen Emus einzubauen und fertich... ^_^ Ob man da wirklich gleich den ganzen EMU neu proggen muss?

 

[Modran]

das liegt daran, dass es gar nicht so einfach ist für die 2. CPU zu programmieren

Ich würde es so formulieren: die Programmierung der 2. CPU erfolgt exakt genauso wie die der ersten (mit nur wenigen Einschränkungen). Man kann aber nicht einfach so ein Programm auf 2 CPUs aufteilen. Stattdessen muß man 2 (mehr oder weniger unabhängige) Programme (Threads) schreiben, die man dann auf die beiden CPUs verteilt.

Meiner Meinung nach läßt sich Musik ideal auf die zweite CPU legen (da sie unabhängig davon läuft, was im Hauptprogramm gerade passiert), ich habe aber noch nicht herausgefunden, wie genau das gemacht werden muß und ob der SDL-Mixer auch auf der 2. CPU läuft.
Es sollte jedenfalls viel einfacher sein als z.Bsp. eine Grafikengine auf die 2.CPU zu legen, da eine Musikengine nicht viele Steuerparameter braucht (Start, Stop, Lautstärke - fertig).

 

[Crazy_Borg]

Eine andere brauchbare Anwendung für die 2. CPU bei Gpsp wäre ein bilinearer Resizer, der einfach die Bilder von der GBA Auflösung (240*160) auf GP2x Niveau (320*240) hochrechnet, und dass nicht so krumm wie der bereits eingebaute resizer (der wohl mit Pixelverdoppelung von bestimmten Bildschirmteilen arbeitet).

 

[Modran]

Ich glaube nicht, daß dies eine "gute" Aufgabe für die 2. CPU ist, da man die Umrechnung von Bildern sinnvollerweise nur ein einziges Mal machen sollte, und somit keine Notwendigkeit für Parallelbetrieb besteht. Die 2. CPU ist gut für Sachen, die in Echtzeit IMMER WIEDER gemacht werden müssen (und asynchron gemacht werden KÖNNEN).

Andererseits hat man in einem Emu wenig Einfluß auf die originäre Bildverarbeitung,, und die 940 KÖNNTE 60 mal pro Sekunde das Gesamtbild umrechnen - aber so richtig optimal wäre das nicht.
In der Praxis habe ich festgestellt, daß gerade bei kleinen Bildern ein hartes herunterskalieren (so wie es die GP2X-Hardware kann) oft bessere Ergebnisse liefert als ein weiches neu-rendern (bei dem viele Kontraste verlorengehen, insbesondere scharfe Konturlinien verblassen dabei arg). Besonders die schnell bewegten Sprites wirken dadurch schwammig und verwaschen.