PDA

Ver la versión completa : segundo procesador



lib
31/12/2005, 15:51
una pregunta.... cuando se podra empezar a usar el segundo procesador de la gpx2 ???

los emuladores ya creados como el el mame de franxis, el drmd de reesy...tendran que reescribirse ??

de momento mis expectativas de gp2x estan casi casi cumplidas:

un drmd perfecto que ya casi esta conseguido y cps1 perfecto que parece ser que con el mame de franxis va todo viento en popa.....queda pendiente unas mejoras en el scummvm que no se si siguen con el proyecto o simplemente lo han portado sin mas

un saludo

dj syto
31/12/2005, 15:58
utilizar el segundo procesador depende de los programadores. si aun no lo han usado es porque no han kerido.

En el caso de usarse no seria necesario recodificar todo el emu. Sino "enviar" determinadas tareas al otro procesador. Vamos, repartirlas.

MonXP
31/12/2005, 16:32
El segundo procesador se empezará a usar realmente cuando el firmware de las facilidades para ello. Ahora mismo es bastante incómodo usarlo, aparte de poco eficaz. Si estuviera implementado por firmware, se podría hacer un fork en el ejecutable principal, ejecutando a partir de entonces 2 procesos separados y la misma gp2x haría que trabajaran en paralelo.

Yo creo que nadie lo utiliza porque es un trabajo bestial y en poco tiempo no valdrá para nada. Es más, yo diría que es más fácil modificar los programas de como están ahora a como se usarán para dos procesadores, que modificar los programas de usar 2 procesadores ahora a usarlos en el futuro.

antidark
31/12/2005, 17:31
Aparte piensa en esto si subiendo la frecuencia a 250 o 266 mhz las pilas se van volando, piensa cuanto duraran trabajando los dos procesadores a 200mhz , si los emuladores iran de fabula pero las pilas en 1 hora y media fulminadas. Pienso que los programadores iran puliendo sus emuladores y optimizandolos lo maximo que puedan. Yo la verdad es que estoy contengo con la scene y como van.

JC

MonXP
31/12/2005, 17:54
No creas que el consumo es mucho mayor poniendo los 2 micros a 200 que desactivando un micro y poniendo el otro a 266. Ten en cuenta que overclockeando el sistema, overclockeamos todo el sistema, no sólo el procesador, aumentando el consumo general. Además, jugando, las 2 cpus no están todo el rato al 100%, sobre todo el segundo, que tiene que esperar las direcciones de memoria del primero.

antidark
31/12/2005, 17:59
Ahmm perdona , es que cada uno es maestro en su campo, pues creo que el dia que se consigua llegar al segundo procesador tendremos un emu de psx, un emu de snes con sonido, aunque hay algo que hay que romper y que lo haran con el tiempo. Lo primero la limitacion de 32 megas , si no se supera eso, no se podra hacer un emu de cps2.

Saludos

JC

lib
31/12/2005, 18:31
a ver si se ponen las pilas esta gente de gph .....seguro que el mame de franxis iria mucho mas holgado con los dos micros......el tema supongo que depende de gph y su firmware.....aunke primero que arregle el tema de la duracion de las pilas y del parpadeo que muchos sufren.

supongo que usando los dos micros todo deberia ir bastante mejor....lo de la limitacion de la ram...eso es otro tema.... imaginad jugar un d&d en una portatil

taromaru
31/12/2005, 18:39
...supongo que usando los dos micros todo deberia ir bastante mejor....lo de la limitacion de la ram...eso es otro tema.... imaginad jugar un d&d en una portatil

No me calientes lib... :babea:

mortimor
31/12/2005, 18:41
Ufff veo algunos fallos de concepto :D:D:D No puede hacerse multitarea a nivel de procesos (con un fork()) en linux con la GP2X por el sencillo hecho de que el 940t no cuenta con MMU y por lo tanto depende casi por completo de que se configuren ciertos parametros por parte del procesador principal.

Hoy por hoy se puede usar el 940t, existe una serie de rutinas para cargar aprte del codigo en él y como dice syto es cuestion de repartir el codigo entre los procesadores, pero hay un problema: esto no es lo mismo que recompilar y ajustar -> hay que saber como funciona el emulador a fondo si se le quiere dividir de forma que pueda funcionar con los dos procesadores (porque existen dependencias dentro del codigo que hacen que este no pueda ejecutarse independientemente) y, ademas, obtener una mejora de rendimiento.

No estamos con un tema trivial. El MAME de Franxis puede mejorar (ya que él ha tocado el codigo muchisimo y lo conoce, en consecuencia existe un margen aceptable), Rlyeh y aesta trabajando en estos temas como se puede ver en su Minimallib para GP2X y hay otros que experimentan con ello. Eso si, no espereis que se beneficien del "multiproceso" otros ports que han surgido, por ejemplo aquellos inspirados en SDL y que son poco mas que recompilaciones con una configuracion adecuada para la GP2X.

pezezin
31/12/2005, 18:45
No creo que el firmware llegue a soportar el segundo procesador de manera sencilla. No tiene MMU, y por lo tanto es un poco difícil ejecutar un Linux en él...

WinterN
31/12/2005, 19:59
Como ya ha dicho mortimor, el cambio para el uso del segundo micro no es para nada intuitivo, aunque ya tenemos algunas cosas como las minilib de ryleh que facilitan la tarea.

A pesar de todo yo creo que algún día veremos unas librerías o una nueva implementación de SDL que aproveche el segundo micro de forma transparente o casi transparante al programador.

MonXP
31/12/2005, 20:18
Precisamente porque no tiene MMU digo que es a nivel de firmware donde tienen que hacer el proceso transparente, pezezin dice que al no tener MMU es muy dificil ejecutar un Linux sobre él, y es que no hay que ejecutarlo sobre él, sino sobre el 920, haciendo que este le pase de forma transparente para el programador, las direcciones de memoria a utilizar. Esto es perfectamente posible, y sería casi como si ambos procesadores tuvieran MMU.

pezezin
31/12/2005, 20:53
MonXP, tú decías que sería hacer un fork() en el programa principal, yo lo que digo es que no sería tan sencillo, habría que añadir alguna llamada especial. De todas maneras, ¿no había ya por ahí una biblioteca para cargar código en el segundo procesador?

MonXP
31/12/2005, 21:59
Yo decía que sería hacer un fork(), siempre que estuviera bien implementado en el firmware. Está claro que ahora mismo no es nada fácil. Y creo que es la minimal library de Rlyeh la que implementa instrucciones para trabajar con el segundo procesador, de todas maneras, esto sigue siendo inviable mientras no sea más intuítivo.