Desarrollo para GP2X: Impresiones de los coders

[WinterN]

Alguien tiene una buena descripcion de la distribucion del hardware dentro del GP2X?, me gustaria saber como estan interfaceados los dos procesadores y la memoria.

Existe un documentación de MagicEyes muy completita del MMSP2 en pdf que se puede conseguir en varios sitios, como por ejemplo este.

[E.J.]

Muchas gracias WinterN, si linux usa el segundo chip para procesamiento de video quiere decir que entonces programaron alguna especie de driver para esto, me imagino que con un kernel modificado se podria usar el segundo procesador para otras cosas.

Creo que la pega no es el linux, son las restricciones que GP le estan poniendo al kernel, segun mi parecer el desarrollo de la GP2X se va a distribuir en algo asi como 3 ramas:

1. Los que estan felices con el kernel actual y solo se van a dedicar a portear aplicaciones
2. Los que no estan felices con el kernel actual y va a querer modificarlo para aprovechar mejor el hardware
3. Los que no estan satisfechos con ninguna de las dos opciones anteriores y quieren tener acceso directo a todo el hardware

Creo que a pesar de que estos ultimos van a tener que esperar un poco mas, las tres ramas son perfectamente viables e incluso recomendables.

[MonXP]

Estoy bastante de acuerdo con lo que dices, E.J., de todas maneras, lo que hay que tener en cuenta es que ninguna de las 3 ramas es incompatible con la otra. Lo explico:

Los que están contentos con el Kernel actual harán ports rápidamente, lo que en poco tiempo nos dará la oportunidad de usar programas de, por llamarlo de alguna manera, "poca potencia". En cambio, los que se dediquen a retocar el Kernel, lo que harán es conseguir que se puedan utilizar programas de "media potencia", pero los primeros se podrán seguir utilizando directamente, o, si hay que hacer algún cambio radical en el Kernel, con pocos arreglos. Los terceros se dedicarán a usar toda la potencia de la máquina, para conseguir usar aplicaciones de "gran potencia", pero muy posiblemente saldrá algún gestor de arranque (GRUB en GP2X? ) para que podamos seguir cargando nuestro Kernel Linux, con lo que los 2 primeros seguirán funcionando perfectamente. Entonces, y a menos que los terceros consigan algo bestial, dependiendo de qué queramos, arrancaremos Linux o el otro firmware.

De todas maneras, pienso que un kernel bien optimizado es muy ligero, nos da unas subrutinas muy cómodas para trabajar contra el hardware y recordar que C es un lenguaje muy potente, y siempre podemos hacer alguna parte del Kernel en ensamblador, para ganar potencia en ejecuciones críticas.

Lo que está claro es que el Kernel tiene que poder aprovecharse para subir/bajar la velocidad de los procesadores, para que los componentes que no se usen en un momento dado, salida de tv, aceleradora 2d, etc... no consuman, e incluso para dejar el segundo procesador en reposo si la aplicación no lo requiere, como escuchar mp3. La ejecución multitarea real me parece secundaria por ahora, ya se verá con el tiempo.

PD: Creo que lo de "poco potente", "media potencia" y "gran potencia" me han quedado fatal explicados, espero que se entienda.
PD2: Tengo que desempolvar mis apuntes de Laboratorio de sistemas operativos, a ver si hago un Kernel revolucionario y podemos emular Xbox360 en la GP2X

[E.J.]

Yo me apunto a la emulacion del 360 en GP2X!!! ( o por lo menus en fake para el dia de los inocentes).

Por supuesto seria genial tener un bootloader tipo grub o lilo para poder seleccionar el sistema operativo que queremos arrancar (jeje, esto cada vez suena mas lindo *.*)

Yo dudo que puedas optimizar el kernel de linux mas de lo que esta, ya de esto se han encargado los chorrocientos de programadores del kernel alrededor del mundo.

Lo que si se puede optimizar son los modulos adjuntos del kernel: I/O, sonido, video, aceleracion 2d. etc... esto porque los modulos si son muy dependientes de la plataforma sobre la que corren y mientras mas a bajo nivel los hagas pues mejor, lo mismo pasa con las librerias.

Seria muy bueno que la comunidad linux viera potencial en el GP2X y muchos de esos extremadamente habilidosos programadores le dedicaran un poco de tiempo.

En fin... como dice mi abuela, estamos contando los polluelos antes que se rompan los huevos, mejor esperamos a ver de que es capaz la GP2X.

[Franxis]

1. Esplicame como es que kernel+sdl se comen ese 15%+

2.3.4. Si como dices el segundro procesador solo sirve para decodificar mpeg4, entonces la gente de gamepark no deberia hacer la publicidad de que la consolita cuenta con doble procesador, si no mas bien con un chip de decodificacion de mpeg4....

5. .asm{}

6. Estoy completamente de acuerdo contigo

Creo que seria muy agradable poder poner a dormir al pinguino de vez en cuando para poder aprovechar todo el poder de la consolita, sin embargo tambien creo que subestiman mucho al pajaro ese y a SDL.

Alguien tiene una buena descripcion de la distribucion del hardware dentro del GP2X?, me gustaria saber como estan interfaceados los dos procesadores y la memoria.

Vamos a ver:

1. Utilizando SDL en lugar de acceso directo al hardware se pierde aproximadamente (según me ha contado gente que ha tratado con SDL) un 10-20% de rendimiento. Utilizando Linux en lugar de acceso directo a la GP2X sólo tienes acceso a la mitad de la memoria (32Mb) y además de esas 32Mb una parte está reservada para Linux, además de la merma de rendimiento que conlleva tener cargado el Linux por debajo... Y créeme que en las pruebas con el MAME GP32, al incrementar el tamaño de los ejecutables se perdía rendimiento...

2.3.4. Ahora el segundo procesador lo usa el kernel para acelerar la reproducción de videos, y se supone que se usará en las SDL para acelerar el rendimiento (cuando la nueva versión de las librerías se haga pública, a esperar...)

5. asm {}... xDDD no sa jodío.

[timofonic]

Vamos a ver:

1. Utilizando SDL en lugar de acceso directo al hardware se pierde aproximadamente (según me ha contado gente que ha tratado con SDL) un 10-20% de rendimiento. Utilizando Linux en lugar de acceso directo a la GP2X sólo tienes acceso a la mitad de la memoria (32Mb) y además de esas 32Mb una parte está reservada para Linux, además de la merma de rendimiento que conlleva tener cargado el Linux por debajo... Y créeme que en las pruebas con el MAME GP32, al incrementar el tamaño de los ejecutables se perdía rendimiento...

2.3.4. Ahora el segundo procesador lo usa el kernel para acelerar la reproducción de videos, y se supone que se usará en las SDL para acelerar el rendimiento (cuando la nueva versión de las librerías se haga pública, a esperar...)

5. asm {}... xDDD no sa jodío.

Franxis, creo que estas metiendo muchas escusas, no se si me vuelvo paranoico o es que quereis convencer a todo el mundo a que no use Linux...

La GP32 solo se parece a la GP2X con el micro. Esas pruebas no se a que sistema son, me parece demasiado bestia, además de que si no hay pruebas en condiciones sobre rendimiento pueden decir lo que quieran, me fio más de Chui que lo que hayan contado a alguien por muy buen coder que seas (que no lo discuto, ese MAME es una maravilla ).

Sobre la RAM, eso es un fallo de GPH y de sus multiples chapuzas, meten un "driver" que se queda con parte de la ram y el micro, pero que se use Linux en GP2X no implica que solo tengas 32MB, sino que es un fallo de GPH al no hacer las cosas en condiciones y cargar/descargar las cosas bajo demanda.

[A600]

1. Utilizando SDL en lugar de acceso directo al hardware se pierde aproximadamente (según me ha contado gente que ha tratado con SDL) un 10-20% de rendimiento.

Eso te lo puedo confirmar yo. La misma versión del xrick usando las SDL en la GP32 es un 15-20% más lenta que con el SDK de Gamepark.

[oankali]

Eso te lo puedo confirmar yo. La misma versión del xrick usando las SDL en la GP32 es un 15-20% más lenta que con el SDK de Gamepark.

Supongo que todo es cuestión de como se ha implementado el SDL para la GP32.
Sospecho que se podría conseguir la misma velocidad que con el GPSDK siempre y cuando el SDL no tenga que convertir los gráficos ya que eso de poder utilizar gráficos de cualquier formato (me refiero a colores), está muy bien pero tiene que repercutir por huevos en el rendimiento si se hace de forma generalizada (una rutina para todas las posibilidades usando las máscaras).

[Anarchy]

Franxis, creo que estas metiendo muchas escusas, no se si me vuelvo paranoico o es que quereis convencer a todo el mundo a que no use Linux...

De verdad que empiezas a ser cansino. Nadie quiere convencer a nadie de que no use Linux, solo se expone la situación REAL de la consola, tú te limitas a especular.

[mortimor]

Supongo que todo es cuestión de como se ha implementado el SDL para la GP32.
Sospecho que se podría conseguir la misma velocidad que con el GPSDK siempre y cuando el SDL no tenga que convertir los gráficos ya que eso de poder utilizar gráficos de cualquier formato (me refiero a colores), está muy bien pero tiene que repercutir por huevos en el rendimiento si se hace de forma generalizada (una rutina para todas las posibilidades usando las máscaras).

Creo que acabas de dar en el clavo con la cuestion. Es muy bonito disponer de la conversion de formato y luego quejarnos de que es mas lento. Es obvio que algo de rendimiento se lo quedan las SDL, pero creo que habria que probarlo en igualdad de condiciones y sin que se fuerce la conversion.

En lo que se nota diferencia no es entre GPSDL y GPSDK. Si pruebas a copiar los buffers y hacer el cambio de buffer con las "funciones" de MrSpiv veras que le ganas bastante rendimiento (de tener un scroll vertical y musica ogg a 25-30 fps y pasar a usar los registros directamente par hacer el scroll como MrSpiv y obtener 35-40 fps). Pero es normal sacrificar potencia a cambio de facilidad de uso , puedes tener mas de 100 sprites(por decir algo, se pueden bastantes mas, si no recuerdo mal) de 16x16 en pantalla a 60fps y 16 bpp, pero es un coñazo molestarse en ir mas alla de una demo y meterlo en un juego.