Ver la versión completa : Ejemplo: Intercambio de información entre los dos cores
Puck2099
21/08/2006, 04:32
Hola,
Bueno, como dije, me ha basado en el código de Dzz para la reproducción de Ogg Vorbis en el segundo core para hacer mi propio programa de ejemplo.
El objetivo de este ejemplo es más o menos didáctico, por lo que lo he comentado bastante más de lo habitual en mi (¿verdad Misato? :D ). Más que mostrar que se pueden ejecutar cosas en el segundo core (que ya hemos visto con el código de Dzz que sí), me he querido centrar en la comunicación entre ambos procesadores y hacerlo más sencillito que el ejemplo de Dzz para que se pueda entender mejor.
El código básicamente lo que hace es generar números aleatorios en el primer core que se pasan al segundo para que éste haga una operación sencilla con ellos (suma, resta, multiplicación o división) y devuelva el resultado que tomará de nuevo el primer core para imprimirlo por el terminal. Se sale del programa pulsando START.
El código no está optimizado para nada, seguro que es incluso más lento que hacer esto mismo en un solo core, pero como digo solo quiero mostrar como intercambiar información y ponerlo en marcha, siendo bastante más útil paralelizando tareas que "chupen" bastante más CPU que una suma. Debe haber algún bug en el interbloqueo, pues de vez en cuando se imprime un signo de operación equivocado, pero espero que me podáis perdonar :angel1:
Bueno, para ver algo tenéis que tener la consola conectada via telnet, pues ahí es donde se mostrarán los resultados de las operaciones y lanzar el fichero test.gpe que tiene que estar junto al code940.bin (el código del segundo core).
Si hay alguna duda, problema o no entendéis qué hago, please, hacédmelo saber :brindis:
Espero que os sea de alguna ayuda.
Es genial que te hayas currado un ejemplo más claro, DZZ ya dijo que era un trozo de código arrancado del Vektar y ke pasaba un poco de dar más explicaciones, pero teniendo gente como tu, el segundo procesador estará en nada en el poder de cualkiera.
El mio no, eso si, yo solo me miro el código por curiosidad pero apenas entiendo nada xDDDDDDDD
Que alguien ponga los dos ejemplos en las noticiaaasss, que esto es una revolusión!!!!
Waninkoko
21/08/2006, 05:52
Hoy he estado toqueteando un poco el tema del segundo procesador y el caso es que he conseguido hacer una aplicacion y todo!
La aplicacion se basaba en calcular las raices cuadradas de los primeros 1000000 numeros y el cuadrado y el cubo de los primeros 333333333 numeros.
Funcionando solo en el ARM 920t la aplicacion tarda 40 segundos.
Si las raices se hacen en el ARM 920t y el resto en el ARM 940t tarda 27 segundos.
Cuando se termina de calcular todo lo que tiene que hacer el 940t se guarda un integer en la memoria compartida con el valor 1 para que el 920t sepa que el trabajo del 940t ha terminado.
Esto puede estar muuuuuy interesante.
Rivroner
21/08/2006, 05:59
Pues si pasa con cualquier tipo de programa esa mejora de más del 30% de rendimiento-velocidad estamos hablando de un descubrimiento importantísimo como ya se podía pensar O_o ^o^
¿Lo que no entiendo es por qué DZZ no liberó esto antes? Ya sé que es libre de hacer lo que quiera con su código pero seguro que él sabe hace meses como sacarle rendimiento a los 2 procesadores.Si lo hubiera liberado antes se podría haber avanzado más en emuladores por ejemplo.
Aunque bueno, más vale tarde que nunca.Lo importante es que lo ha liberado.
Puck2099
21/08/2006, 06:02
Pues si pasa con cualquier tipo de programa esa mejora de más del 30% de rendimiento-velocidad estamos hablando de un descubrimiento importantísimo como ya se podía pensar O_o ^o^
¿Lo que no entiendo es por qué DZZ no liberó esto antes? Ya sé que es libre de hacer lo que quiera con su código pero seguro que el sabe hace meses como sacarle rendimiento a los 2 procesadores.Si lo hubiera liberado antes se podría haber avanzado más en emuladores por ejemplo.
Aunque bueno, máas vale tarde que nunca.Lo importante es que lo ha liberado.
No liberó el código, pero sí comentó como usar los dos procesadores.
Por eso he sacado esto tan deprisa, porque yo ya sabía cómo usarlos de lo que leí en sus hilos en su día, lo que me faltaba es ver qué registros exactamente tocar y como generar el código del segundo core para cargarlo desde el primero :)
Saludos
Waninkoko
21/08/2006, 06:06
Mi aplicacion que usa los dos cores.
Source y ejecutable.
Puck2099
21/08/2006, 06:07
Mi aplicacion que usa los dos cores.
Source y ejecutable.
Muchas gracias, vamos a devorarlo :brindis:
Hombre, tambien hay que tener en cuenta que el uso que se le esta dando ahora en los test es un poco artificial, porque apenas requieren comunicación entre ellos. Supongo que en un tema como la emulación, en el cual la sincronización es tan importante, las ventajas no serán tan espectaculares.
Aunque en los juegos se puede notar muy mucho :D
Puck2099
21/08/2006, 06:31
Hombre, tambien hay que tener en cuenta que el uso que se le esta dando ahora en los test es un poco artificial, porque apenas requieren comunicación entre ellos. Supongo que en un tema como la emulación, en el cual la sincronización es tan importante, las ventajas no serán tan espectaculares.
Hombre, en mi test se comunican constantemente pasándose los datos de uno a otro :D
En cuanto a la emulación... ya veremos, no esperes que se doble el rendimiento, pero creo que éste será el empujoncito necesario para que los emuladores que van al 80% puedan ir a full :)
Ya, puck, pero tu no has hecho una comparación sobre el rendimiento que tienen los dos procesadores trabajando juntos o por separado (creo). Asi que no tenemos datos sobre lo eficiente que puede ser :D
Buenísimas noticias. *****, soys unos cracks...
Funcionando solo en el ARM 920t la aplicacion tarda 40 segundos.
Si las raices se hacen en el ARM 920t y el resto en el ARM 940t tarda 27 segundos.
Aunque de aquí tampoco se puedan sacar grandes conclusiones, porque los cálculos que asignas a un procesador son independientes de los que asignas al otro, y en condiciones normales me imagino que lo más habitual es que se tengan que comunicar muy a menudo, mola que os hayáis currado ejemplos de paralelización. Aunque, la verdad, mirando el código entiendo bien poco con tanto toqueteo de registros... :)
puck, pa cuando un exult paralelizado? >:·D
Y yo pregunto, ¿todo este trabajo no se había hecho antes?
Me suena que Rlyeh ya lo tiene implementado en su Minilib y que hasta había dado algun ejemplo.
En cuanto a benchmark en este hilo (http://www.gp32x.com/board/index.php?showtopic=22871&hl=) de Squidge ya se hizo.
¿Se os pasaron por alto, o no hablamos de lo mismo?
Puck2099
21/08/2006, 17:50
Y yo pregunto, ¿todo este trabajo no se había hecho antes?
Me suena que Rlyeh ya lo tiene implementado en su Minilib y que hasta había dado algun ejemplo.
En cuanto a benchmark en este hilo (http://www.gp32x.com/board/index.php?showtopic=22871&hl=) de Squidge ya se hizo.
¿Se os pasaron por alto, o no hablamos de lo mismo?
No, si hacerse se hizo, pero lo que no se hizo fue dejarlo tan clarito como aquí tienes los makefiles, aquí se carga el código, esto otro se compila así para que se pueda cargar en memoria, etc.
Osea, que la base estaba, pero muchos no sabíamos seguir a partir de ahí y con el código de Dzz, al menos yo, lo he visto todo mucho más claro porque nos lo da todo hecho :)
Saludos
Acerbaturix
21/08/2006, 18:00
Justo lo que ha dicho Puck2099 (gracias por el código comentado ;)). Yo estube hace unos días ojeando por encima el tema del doble procesador en la minilib y no me terminaba de aclarar del todo como hacia para compilar/cargar el código en el 2º procesador.
Con el ejemplo de Dzz y sobre todo los comentarios de puck, la cosa esta bastante mejor ;).
Yo creo que ahora lo que hace falta es encapsular todo el trabajo con la memoria compartida, etc. en una libreria de paso de mensajes entre los procesadores, para hacer la comunicación muuuucho más sencilla.
Si nadie está con ello, esta tarde entre que estudio y no estudio [wei6], me pongo a pensarlo un poco.
Nadie ha hecho una prueba del aumento de rendimiento con los dos procesadores comunicándose contínuamente entre ellos?
Si no es mucho pedir estaria bien que retocaseis el ejemplo ese que hace calculos con uno y otro procesador de forma que se viese en la pantalla de la gp2x lo que esta haciendo cada uno de ellos.
Lo digo por que seguro que muchos de los que no tenemos ni papa de programacion estamos impacientes por ver algo del uso del segundo procesador.
Gracias por anticipado y un saludo :brindis:
Acerbaturix
22/08/2006, 01:29
Nadie ha hecho una prueba del aumento de rendimiento con los dos procesadores comunicándose contínuamente entre ellos?
Mientras no se vea en un proyecto real, yo creo que las pruebas "sintéticas" sirven de poco (para ver el rendimiento, hacerlas hay que haerlas para ver como usarlo :D), por que el rendimiento extra obtenido, depende total y absolumente del programa en cuestión, por lo que hacer un programa especifico para probar el rendimiento no nos va aportar ningun dato relevante.
En el ejemplo de Puck se estan comunicando todo el rato, y aunque no se han tomado medidas de tiempo comparándolo con 1 solo procesador, tampoco seviría de nada (logicamente no era esta su intencion) por que realmente el primer procesador no está aprovechando para nada el tiempo extra que obtiene de ejecuttar las operaciones en el 2º procesador.
Yo tengo cierta experiencia en la programación de algoritmos paralelos en clusteres, y si no puedes conseguir una versión del algoritmo que requiera muy pocas comuniaciones, mejor hazlo secuencial.
De todas formas, en este caso el tema es algo distinto, pues la comunicación/sincronización mediante memoria compartidada es mucho más rapida que el paso de mensajes por red. Pero a lo que iba, el código ejecutado en el 940t debe suponer una cierta carga de trabajo, para poder compensar de sobra la perdida de tiempo que le supone al 920t pasarle los datos y sincronizar su ejecución con el.
Es decir, si ejecutar todo en el 920 te lleva 10 ciclos de CPU, si lo divides a la perfeccion (cosa complicada) te podría llevar 5, pero si tenemos como constante que hacer las comprobaciones de sincronización te lleva (por ejemplo) 4 ciclos, ya la hemos liado, por que se nos queda en 9. Sin embargo si el total llevase 100, en paralelo lo reduciríamos a 54 ;).
En muchos emuladores, coincido con puck en que puede ser ese puntito que les falta para ir a tope. Ya que en muchos caso se está emulado de forma sencuencial el comportamiento de muchas máquinas que en realidad es paralelo (CPU, chip grafico, chip de sonido...), si se manda la emulación de alguno de esos subsistemas al otro chip, la cosa seguro que mejora :D.
En juegos un puntazo importante creo que va a ser la musica, como esta haciendo Dzz, por que es algo que se ejecuta de forma bastante independiente del resto del juego y además metiendola en el 940 nos evitamos que el thread de sonido del SDL_mixer este pululando por el planificador del SO.
Otra cosa interesante puede ser dejar al 940t los calculos relacionados con IA, y que el 920t se encargue de la entrada(joystick)/salida(pantalla) de datos. Se podría estar calculando el comportamiento de un enemigo mientras ya estas dibujando al otro que calculaste antes...
Sin duda se pueden hacer muchas cosas, pero no nos pensemos que es la panacea, aparte de que la programación paralela no es sencilla.
fosfy, puedes probar a ejecutarlo con sterm, asi te ahorras entrar por telnet ;)
PDT: Como me enrollo... disculpar, pero siempre acabo escribiendo la tira :D
Escribes la tira pero cosas últiles y muy bien explicadas, gracias!
Rivroner
22/08/2006, 02:00
Un ejemplillo con alguna figura básica poligonal (si es texturizada mejor :D) con contador de frames incluido en el que primero apareciese la figura usando un sólo procesador y luego la mejora cuando se usan los 2 estaría muy bien :)
Lo que no sé es si este es un buen ejmplo para hacer una demostración del uso paralelo de los micros.
Es sólo una idea para ver si os animáis alguno y hacéis babear al personal un rato :D
A mí me preocupa el tema del consumo de energía. Es decir, estaría sencillamente genial que se estandarizara el uso del segundo procesador para hacer que aquellos emuladores, ports y demás que son casi perfectos o avanzan a pasos agigantados pudieran usar el segundo procesador para liberar carga de proceso y no hubiera necesidad de overclockear para conseguir un rendimiento óptimo.
El caso más claro que se me ocurre, por ejemplo, es con el gngeo, que se nota que con la emulación de sonido se resiente. Si se conseguiera modularizar el procesador de sonido en el segundo procesador, yo creo que se podría jugar al Garou como si estuvieramos en la mismísima recreativa (es una suposición). Pero claro, ¿qué pasa con el consumo de pilas? Actualmente una pilas de más de 2500 dan una autonomía media de 3 horas... habría que ver hasta qué punto el uso del segundo procesador reduciría éste tiempo, ya que si es mucho no sé hasta qué punto es preferible quedarse uno como está con un procesador...
¿Algún monstruo de los de aquí que se atreva a analizar éste factor?
Puck2099
22/08/2006, 02:53
Piensa en el reproductor de video y calcula a ojo con él, pues ahí se usan ambos cores :)
Saludos
Piensa en el reproductor de video y calcula a ojo con él, pues ahí se usan ambos cores :)
Saludos
Umm... pensaba que el primer core lo usaba mínimamente y casi toda la carga de proceso recaía sobre el segundo. De todas formas de ser así es una noticia fantástica, pues eso significa que tenemos también unas 3 horas de autonomía con los dos procesadores en paralelo (ésto hay que celebrarlo :brindis: :brindis: ).
Por cierto, ¿a alguien le suena que haya algún proyecto de visor de imágenes independiente del que trae la propia negrita? Me gustaría poder meterme en algún proyecto para un visor mejorado de imágenes, con soporte de ficheros comprimidos (.cbz, .crb y demás pesca) y controles avanzados para visualizar/leer imágenes secuenciales (vamos, comics). Ya se que tiene que ser un coñazo algo así en una pantalla tan reducida, pero me hace ilusión. :D
Es un simple deseo...
fosfy, puedes probar a ejecutarlo con sterm, asi te ahorras entrar por telnet ;)
Ta chulo; con el 920t.gpe tarda 20 segundos y con el 940t.gpe solo 14.
La pena es que solo informa de eso; quedaria chulo que mostrase los calculos que hace en pantalla.
Saludos.
El garou se resiente con sonido?
A 266?
A mi me va perfecto a 60 fps estables O_o
Menos cuando carga de la SD, ahi no, pero eso es normal :D
El garou se resiente con sonido?
A 266?
A mi me va perfecto a 60 fps estables O_o
Menos cuando carga de la SD, ahi no, pero eso es normal :D
Perdón por el offtopic. ¿Qué versión? Yo estoy con la última de gngeo y rage, configurado a nivel general con overclocking a 266, sonido a 22100, raster effect, etc. Me va a 40 fps cuando está suelto... se ralentiza a unos 15 fps cuando hay mucha carga... La verdad que me parece un poco raro, ya que incluso el Art of Fighting cuando tiene carga va a unos 40 fps, cuando me suena haberlo visto anteriormente (quizás con otra versión anterior de gngeo) sin descender de 60 fps. El gngeo lo tengo instalado en una SD de 2GB.
Por cierto, ¿el fichero de gráficos generado por gngeo tiene que estar por fuerza en el subdirectorio roms del emulador? Lo digo porque si cargo gngeo desde la NAND, me empieza a meter ahí los ficheros y no caben.
Rivroner
22/08/2006, 14:16
Es porque pones el sonido a 22.Si lo bajas a 11 no notarás la diferencia sonora mucho y ganarás rendimiento.Yo hace meses que juego sólo a 11 khz.
Prueba a ver.
Acerbaturix
22/08/2006, 16:25
Un ejemplillo con alguna figura básica poligonal (si es texturizada mejor :D) con contador de frames incluido en el que primero apareciese la figura usando un sólo procesador y luego la mejora cuando se usan los 2 estaría muy bien :)
Lo que no sé es si este es un buen ejmplo para hacer una demostración del uso paralelo de los micros.
Es sólo una idea para ver si os animáis alguno y hacéis babear al personal un rato :D
Estube ayer por la noche jugueteando un poquito con el 2º core. He hecho un pequeño ejemplo gráfico para tratar de probar un poco la idea que comentaba de dejar el 940 para hacer los cálculos de IA de los enemigos.
He hecho una pequeña demo (o algo asi) en la que hay un cuadrado rojo en un punto de la pantalla y por la parte superior de la pantalla aparecen 2000 cuadrodos rojos que se van acercando hacia el otro (he tenido que meter tantos para que le metiese chicha a la maquina, pero ahora hay tantos que se solapan unos a otros :D y se ve un raya roja). Pensar que el cuadrado del medio son los buenos, y los de arriba los marcianos que vienen a atacarlo :D.
Los malos se mueven 1 pixel en cada frame y su comportamiento consiste en ir hacia el otro cuadrado, asique hacen un par de comprobaciones y tal, para calcular hacia donde se deben de mover (esto sería la IA de los enemigos).
Lo que se pasa al 2º core es precisamente estos calculos, es decir el 2º core va calculando la posicion a la que se tiene que mover cada enemigo mientras el 1º los pinta en pantalla.
En las primeras pruebas de rendimiento, era ligeramente más rapido el programa sobre el 920 que sobre los 2. Sobre 2-3 fps mas, la razón es que la IA es tan sencilla que su calculo en paralelo no compensaba la sobrecarga introducida para sincronizar los procesadores (lo que ya comentaba yo en el mensaje anterior). Asique le metí "artificialmente" computacion adicional en el comportamiento de los enemigos (basicamente un bucle con un par de sumas y asignaciones) y asi la cosa ha cambiado notablemente (en un caso real ahí habria que hacer deteccion de colisiones y otras muchas cosas...).
Con 2000 enemigos y una comportamiento de cada enemigo algo constoso de computar, solo con el 920 va a unos 25-26 FPS y tarda en total unos 6700ms en llevar a todos los enemigos hasta la posicion de la nave amiga. Sin embargo con los 2 procesadores va a unos 37-38 FPS y tarda 4500 ms en llevar a todos los enemigos al destino.
Una aumento considerable de rendimiento...
Os dejo los 2 programas por si los quereis probar. Podeis ejecutarlos desde el menu, y ya llevan instrucciones de como salir y demás. Por la tarde cuelgo los fuentes, que tengo que hacer un par de Makefiles y ahora debería de estar estudiando :confused:
Puck2099
22/08/2006, 16:32
Con 2000 enemigos y una comportamiento de cada enemigo algo constoso de computar, solo con el 920 va a unos 25-26 FPS y tarda en total unos 6700ms en llevar a todos los enemigos hasta la posicion de la nave amiga. Sin embargo con los 2 procesadores va a unos 37-38 FPS y tarda 4500 ms en llevar a todos los enemigos al destino.
No esperaba menos del segundo core :)
Por cierto, ¿te dio algún problema de sincronización o algo?
Por la tarde cuelgo los fuentes, que tengo que hacer un par de Makefiles y ahora debería de estar estudiando :confused:
Lo espero ansioso. La verdad es que amo esta comunidad, me encanta como podemos aprender unos de otros compartiendo fuentes como estos :brindis:
Estopero
22/08/2006, 16:38
bueno aver si digo algo logico xD, tambien dependera mucho que la forma de sincronizar los hilos de ejecucion este optimizada no? porque podria darse casos de que uno hilo espere cuando no haga falta y demas, habra que mirar mucho ese tema para poder sacarle mejor provecho no?. Un saludo!
Puck2099
22/08/2006, 16:40
bueno aver si digo algo logico xD, tambien dependera mucho que la forma de sincronizar los hilos de ejecucion este optimizada no? porque podria darse casos de que uno hilo espere cuando no haga falta y demas, habra que mirar mucho ese tema para poder sacarle mejor provecho no?. Un saludo!
Sí, claro, todo depende de como sincronices las cosas.
Respecto a lo de los hilos... ¿qué ventaja hay en usar varios hilos? En mi ejemplo no he creado ningún hilo adicional, pues veía suficiente con tener un programa diferente en cada micro...
Rivroner
22/08/2006, 17:05
Con 2000 enemigos y una comportamiento de cada enemigo algo constoso de computar, solo con el 920 va a unos 25-26 FPS y tarda en total unos 6700ms en llevar a todos los enemigos hasta la posicion de la nave amiga. Sin embargo con los 2 procesadores va a unos 37-38 FPS y tarda 4500 ms en llevar a todos los enemigos al destino.
Una aumento considerable de rendimiento...
¡Jo_der qué caña! Como sea así con todo.Más o menos la mejora es del 35 %
Si al pasar el sonido ,etc al segundo core en todos los emus se consigue esta mejora el futuro de la GP2X nadie lo puede decir ahora mismo.Podemos tener emus que nadie hubiera soñado hace 2 días. [Ahhh]
Acerbaturix
22/08/2006, 22:22
Respecto a lo de los hilos... ¿qué ventaja hay en usar varios hilos? En mi ejemplo no he creado ningún hilo adicional, pues veía suficiente con tener un programa diferente en cada micro...
Imagino que con hilos se referia al hecho de ejecutar codigos diferentes en cada procesador. Por desgracia, al no puder usar el 940T como si fuese un sistema SMP (por la falta de MMU), no se pueden ejecutar hilos (entendiendolos como threads del sistema operativo) sobre el, debido a que el planificador del SO no puede planificar su ejecución allí, es una pena, por que sería mucho más facil trabajar como si fuese un sistema SMP.
Asique, en principio usar hilos no sirve para nada, en lo que a obtener mas rendimiento se refiere, ya que los hilos hechos con pthread se van a ejecutar siempre en el 920, salvo que dentro haga el chanchullo para ejecutar cosas en el 940.
Por cierto, ¿te dio algún problema de sincronización o algo?
Pues aquí os dejo el código de los 2 programas. Lo he cambiado ligeramente para que ahora los enemigos salgan de otro color, y poco más.
Sobre si tuve problemas, pues la verdad es que fué bastante sencillo y directo pasar de la versión secuencial a la paralela utilizando el código de tu ejemplo. Salvo por 2 detalles.
El primero es que en la versión paralela debo de tener algun puntero un poco perdido y por alguna razón el enemigo numero 0 no empieza en la parte superior de la pantalla, si no donde a el le parece... :loco: (lo hice todo un poco rápido, asique a ver que se me escapó).
Y el segundo problema, y muy raro por cierto, es que si no dejo en la estructura de memoria compartida un campo que se llama res (que tu utilizas tu ejemplo) que no se utiliza en ninguna parte del código (compila sin problemas sin el), el código de 2º procesador no se ejecuta... :confused:
Imagino que tienen que ser 2 tonterías del uso de la memoria compartida y de hacerlo deprisa y corriendo :D. Un día de estos con tiempo lo miraré bien y a ver si escribo un pequeño tutorial de como usar estas ideas para aprovechar el 2º core nuestros programas.
Os aviso que el código está escrito para acabar pronto y que fuese facil hacer las variables compartidas. Por ejemplo, las coordenadas de los enemigos estan en 2 arrays, uno para las x de todos y otro para las y [wei4]
¡Jo_der qué caña! Como sea así con todo.Más o menos la mejora es del 35 %
Si al pasar el sonido ,etc al segundo core en todos los emus se consigue esta mejora el futuro de la GP2X nadie lo puede decir ahora mismo.Podemos tener emus que nadie hubiera soñado hace 2 días. [Ahhh]
hay calla, que me emociono! [Ahhh]
P.D.: Posteo poco, pero cuando posteo me entra mono... xD
genial ejemplo, y algo más divertido que sumas y restas xDDDDDDDD
Estopero
23/08/2006, 01:49
jo =(, pues me referia a los pthreads precisamente, ya que si se programa bien automatiza todo y seguro q se conseguiria buen rendimiento, pero no sabia que solo se podria usar con el primer micro, Por cierto no estais de acuerdo en que acerbaturix recuerda a un uncanny 2? xDD un saludo!
Akui to Higeki
23/08/2006, 01:57
hay un cuadrado rojo en un punto de la pantalla y por la parte superior de la pantalla aparecen 2000 cuadrodos rojos que se van acercando hacia el otro (...). Pensar que el cuadrado del medio son los buenos, y los de arriba los marcianos que vienen a atacarlo .
Nota mental: No jugar nunca a un juego hecho por Acerbaturix. :D
Acerbaturix
23/08/2006, 03:52
jo =(, pues me referia a los pthreads precisamente, ya que si se programa bien automatiza todo y seguro q se conseguiria buen rendimiento, pero no sabia que solo se podria usar con el primer micro, Por cierto no estais de acuerdo en que acerbaturix recuerda a un uncanny 2? xDD un saludo!
Aaaps :P, pues en principio no se puede. Por que el 2º core, yo creo que pasa totalmente inadvertido para el kernel. No sabe que existe y no puede planificar procesos en el (los threads en Linux son como procesos, pero algo aligerados), y esto es debido a que le falta un componente esencial para ser usado por Linux como un procesador de proposito general, la MMU.
Entonces para usarlo, debe ser el programa que se encuentra en el 920T el encargado de cargar el código a ejecutar en el segundo procesador y ponerlo a andar. Al final es como si tuvieses 2 threads, que además se ejecutan realmente en paralelo (no como los threads con 1 único procesador). Lo que pasa es que no es tan facil de usar como pthreads, por que tienes que andar tu declarando las variables compartidas, cargar el programa del 2º procesador en memoria... pero aparte de eso es muy parecido.
Lo ideal, como comenté en un mensaje por ahí arriba, sería hacer una libreria que encapsulase la carga del programa y la declaración de las variables de compartidas, entre otras cosas. Asi no tendríamos todo es código "raro" por el medio :D. Estoy trabajando en ello, pero todavía no tengo muy claro como implementarla.
En la minilib existe algo parecido, pero segun tengo visto no deja hacer muchas virgerias en el código del 2º procesador... no se hasta que punto es una limitación de minilib o del 2º core (habrá que probar), pero si Dzz reproduce audio... se debería poder hacer de todo :D.
Nota mental: No jugar nunca a un juego hecho por Acerbaturix.
Jajaja, esta claro que la parte gráfica no es mi fuerte :D. Tengo una ideilla para un juego que tengo ganas de hacer... cuando tenga mas tiempo me pondré, pero voy a necesitar ayuda de alguien con los gráficos si no quereis ver moñigotes en blanco y negro por la pantalla [wei2]
Akui to Higeki
23/08/2006, 04:36
Os juro que estoy leyendo todo el thread, pero mi cerebro solo asimila como un 20%. Tendré que comprarme otro y ponerlo en paralelo.
Jajaja, esta claro que la parte gráfica no es mi fuerte . Tengo una ideilla para un juego que tengo ganas de hacer... cuando tenga mas tiempo me pondré, pero voy a necesitar ayuda de alguien con los gráficos si no quereis ver moñigotes en blanco y negro por la pantalla
Me refería al hecho de que fueran 2000 enemigos [Ahhh] , no a que fueran cuadrados rojos. De todas maneras, es igual, era broma. [wei4]
Acerbaturix
23/08/2006, 05:26
Os juro que estoy leyendo todo el thread, pero mi cerebro solo asimila como un 20%. Tendré que comprarme otro y ponerlo en paralelo.
Me refería al hecho de que fueran 2000 enemigos [Ahhh] , no a que fueran cuadrados rojos. De todas maneras, es igual, era broma. [wei4]
Ahh, jejejeje, son muchos si :D. Na, eso era solo para probar, es un programa muy sencillo, no le pide mucho a la máquina, asique para darle chicha había que meterle una cantidad de enemigos a controlar realmente grande :D
...Por cierto no estais de acuerdo en que acerbaturix recuerda a un uncanny 2? xDD un saludo!...Sobretodo en la cantidad de caracteres por post xD
Weno, volviendo al tema. Me siento tonto, muy tonto xD. Y pensar que hay un usuario de este foro que me tiene por dios de la programación xDDDD
En resumen, me pierdo bastante, aunque supongo que el problema de usar 2 procesadores es el mismo que pasa con los cables paralelos y serie, que al final uno serie "bien" hecho (como el usb) acaba siendo mejor que uno que lleve muchos datos que luego hay que sincronizar.
Aparte de música e IA, que otros procesos veis suficientemente "independientes" como para valer la pena de implementar en el 2º micro?
De ahí quito los emuladores, que al tener "piezas virtuales" se puede entender que cualquier hardware que ya tuviera procesador propio (sonido, video) sería susceptible de ser programado en el 2º micro.
Weno, empiezo a resurgir de las vacaciones y su postsindrome Y__Y
Aparte de música e IA, que otros procesos veis suficientemente "independientes" como para valer la pena de implementar en el 2º micro?
Un buen motor 3D quizás sería lo ideal, en el momento en que haya uno suficientemente eficiente y aprovechable.
Una duda que tengo es... ¿qué diferencias generales hay entre el procesador 920 y el 940? No en cuanto a tener MMU ni a los tamaños de registros, sino en cuanto a uso. ¿Alguien lo sabe?
Puck2099
24/08/2006, 00:43
Una duda que tengo es... ¿qué diferencias generales hay entre el procesador 920 y el 940? No en cuanto a tener MMU ni a los tamaños de registros, sino en cuanto a uso. ¿Alguien lo sabe?
¿A qué te refieres con lo del uso? En principio son prácticamente iguales en todo salvo caché y MMU.
¿A qué te refieres con lo del uso? En principio son prácticamente iguales en todo salvo caché y MMU.
Me refiero a sus diferentes denominaciones (920 vs. 940), aunque me imagino que vendrá precisamente de eso, de la diferencia de cache, MMU y PU.
Estopero
24/08/2006, 01:17
Aparte de música e IA, que otros procesos veis suficientemente "independientes" como para valer la pena de implementar en el 2º micro?
De ahí quito los emuladores, que al tener "piezas virtuales" se puede entender que cualquier hardware que ya tuviera procesador propio (sonido, video) sería susceptible de ser programado en el 2º micro.
q pasa compi! jeje
Pues veras no hace falta que sea una aprte independiente del programa para poder usarlo en el segundo micro, es decir no tiene porque estar el nucleo del emulador en un micro y la gpu en otro por ejemplo, o que sea una parte independiente del programa, lo que pasa es que es mas facil asi porque ya tienes las cosas separadas "desde la base", pero tambien se puede programar algo en paralelo haciendo bien las sincronizaciones intermedias y tal, controlando cuando se accede a las variables y esas cosas, siempre valdria la pena si se sincroniza bien =)) aunq es mas complicaillo claro =). Un saludo!
Acerbaturix
24/08/2006, 04:03
Me refiero a sus diferentes denominaciones (920 vs. 940), aunque me imagino que vendrá precisamente de eso, de la diferencia de cache, MMU y PU.
Los datasheets de ARM sobre el 940T dicen que los 2 llevan un núcleo ARM9TDMI, y a mayores se le mete caché y en un caso MMU y en otro la PU. Asique no parece haber mayor diferencia.
Pensando en como funciona todo este sitemilla del coprocesador, a nivel de uso, hay varias dudas que me asaltan... ¿se puede ejecutar llamadas al sistema desde el 940? Yo pienso que no, no parece muy viable técnicamente, no creo que el 940 pueda lanzar traps, ya que el kernel se esta ejecutando en el 920. Además tampoco sería una buena práctica de programación, mejor dejar al 920T el control del programa y la interacción con el sistema, mientras el 940 se encarga del procesamiento... He intentado compilar el código para el 940 con alguna llamada al sistema y el restulado es un fallo en el linkado, pero como no lo entiendo demasiado, no se si el problema es que ya no deja o que falta hacer algo mas :D
Otra duda que me asalta es sobre el uso de librerias externas en el 940T. En principio se deberían de poder utilizar, pero... como se linkan sin recompilar el codigo? He estado probando muy por encima (ando algo liado, dentro de 2 semanas tengo el que debería de ser el ultimo examen de la carrera, y no lo tengo mu claro :confused:), y tambien he acabado con errores de linkado...
Y la duda final :D, como se lo monta el kernel cuando hace un cambio de proceso en el planificador?. Es decir, tenemos un programas ejecutandose en el 920 y ha cargado un programa en el 940. Entonces el planificador de Linux decide quitarle el control a ese proceso y meter otro, que por ejemplo tiene otro programa en el 940.
En principio, de cara a que el 940 acceda al codigo correcto no debería haber mucho problema, pues la MMU del 920 haría el trabajo pero... ¿que pasa con los registros, el program counter, etc. del 940? ¿como los guarda? Imagino que los de MagicEyes han tenido que tocar el código del kernel para que tenga en cuenta esto...
Seguiré investigando el tema, que es muy interesante :).
Puck2099
24/08/2006, 04:13
Otra duda que me asalta es sobre el uso de librerias externas en el 940T. En principio se deberían de poder utilizar, pero... como se linkan sin recompilar el codigo? He estado probando muy por encima (ando algo liado, dentro de 2 semanas tengo el que debería de ser el ultimo examen de la carrera, y no lo tengo mu claro :confused:), y tambien he acabado con errores de linkado...
Mírate los Makefiles de mi ejemplo, en el del 940 linko una librería externa para poder acceder a la función de división.
Y la duda final :D, como se lo monta el kernel cuando hace un cambio de proceso en el planificador?. Es decir, tenemos un programas ejecutandose en el 920 y ha cargado un programa en el 940. Entonces el planificador de Linux decide quitarle el control a ese proceso y meter otro, que por ejemplo tiene otro programa en el 940.
En principio, de cara a que el 940 acceda al codigo correcto no debería haber mucho problema, pues la MMU del 920 haría el trabajo pero... ¿que pasa con los registros, el program counter, etc. del 940? ¿como los guarda? Imagino que los de MagicEyes han tenido que tocar el código del kernel para que tenga en cuenta esto...
Uhm, no te entiendo, pero yo creo que el kernel ni sabe que está ahí el 940, tú le pasas código y él lo ejecuta, si quieres meterle otro programa pues primero lo pausas, reseteas, metes el código, reinicias y ya está :)
Saludos
Acerbaturix
24/08/2006, 05:04
Mírate los Makefiles de mi ejemplo, en el del 940 linko una librería externa para poder acceder a la función de división.
Si, ya lo estube viendo, de hecho probé a utilizar funciones de la libmath y van sin problemas. Sin embargo intenté linkar otra librería mas "de verdad" (libmad) y daba problemas de linkado, algo así como que no era capaz de reservar suficiente espacio... pero creo que es mas bien un problema de las opciones del linker, mas que otra cosa.
Uhm, no te entiendo, pero yo creo que el kernel ni sabe que está ahí el 940, tú le pasas código y él lo ejecuta, si quieres meterle otro programa pues primero lo pausas, reseteas, metes el código, reinicias y ya está :)
Yo tambien creo que el kernel no se entera para nada de que el 940 está ahí y eres tu desde el 920 el que lo tiene que controlar.
Pero no me refería al hecho de cargar un programa en el 940, sino a que si tenemos en el sistema 2 procesos corriendo, procesos del sistema normales que corren sobre el 920.
Supongamos que uno de ellos carga un programa en el 940 y este empieza a ejecutarlo, mientras el propio programa en el 920 hace lo mismo. Poco después, antes der termina, se le acaba su "quantum" de tiempo, y el planificador de procesos del sistema operativo lo pausa y mete en ejecución el otro proceso. Este proceso, a su vez, tambien pretende hacer uso del 940, asique lo inicializa, carga el código y empieza a ejecutar... con lo que se ha cargado los registros del programa anterior del 940, el contador de programa, etc. Si el kernel no sabe que el 940 está ahí, y no ha guardado previamente todas estas cosillas para luego recuperarlas... plof, cuando el primer proceso recupere la CPU se va a encontrar con que en el 940 ya no se está ejecutando lo que el creía y el programa dejará de funcionar :confused:
Por desgracia, cuanto más lo pienso, más me da la impresión de que esto es así, y que si ejecutamos simulataneamente 2 programas que hacen uso del 940 van a cascar.... habrá que probar :D
Puck2099
24/08/2006, 05:25
Si, ya lo estube viendo, de hecho probé a utilizar funciones de la libmath y van sin problemas. Sin embargo intenté linkar otra librería mas "de verdad" (libmad) y daba problemas de linkado, algo así como que no era capaz de reservar suficiente espacio... pero creo que es mas bien un problema de las opciones del linker, mas que otra cosa.
Ah, pues no he probado con cosas más complejas, pero si funciona con la librería de Vorbis que metió Dzz no tendría que haber problemas, ¿no?
Por desgracia, cuanto más lo pienso, más me da la impresión de que esto es así, y que si ejecutamos simulataneamente 2 programas que hacen uso del 940 van a cascar.... habrá que probar :D
Sí, eso seguro, más que nada porque cuando inicializas el 940 hay que resetearlo, así que el programa que estuviera corriendo se va a la porra.
De todos modos, no creo que sea gran pérdida, pues no conozco apenas programas que se ejecuten simultáneamente en la GP2X...
Saludos
Acerbaturix
24/08/2006, 05:51
Ah, pues no he probado con cosas más complejas, pero si funciona con la librería de Vorbis que metió Dzz no tendría que haber problemas, ¿no?
Pienso que no debería de haberlos, pero el tema es que, por lo que ví, Dzz incluye y compila el código de la libreria vorbis en el propio ejemplo...
Sí, eso seguro, más que nada porque cuando inicializas el 940 hay que resetearlo, así que el programa que estuviera corriendo se va a la porra.
Justamente, por eso decía que habría que modificar el kernel para que cambiase el código y los registros del 940 cuando saca un proceso de la CPU. Pero bueno, casi seguro que no lo han hecho, pues no compensa demasiado arreglar eso.
De todos modos, no creo que sea gran pérdida, pues no conozco apenas programas que se ejecuten simultáneamente en la GP2X...
Cierto, era solo una curiosidad que se me ocurrió pensando en como funcionaba el sistema :D. No es muy habitual ejecutar varios procesos simultaneamente en la GP2X (ni en ningún dispositivo que vaya a utilizar un MMSP2), y mucho menos que los 2 utilicen el 940, asique no debería haber ningun problema :P.
No se si recordais me idea y mis recientes pruebas de hacer una GUI multitarea para la GP2X, pero cada vez me lo estoy pensando más, y esta es otra razón a tener en cuenta... [Ahhh]
Diablos, que conversación más interesante y a la vez más incomprensible xDDDDD
Yo solo pasaba por aqui para decirle a acerbaturix que si quiere gráficos para un juego me puede preguntar a mi, que estoy mas bien libre :D
Yo tenia ya una idea para un juego también, pero estoy viendo que lo que me falta es habilidad para ponerme a programarlo yo, y como veo que eso a ti no te va a faltar, pues mira xDDDD
Ah, pues no he probado con cosas más complejas, pero si funciona con la librería de Vorbis que metió Dzz no tendría que haber problemas, ¿no?Bueno, también hay que tener en cuenta que Dzz no usa ni enlaza con la librería Tremor precompilada en el 940, sino que modificó el archivo fuente de Tremor necesario para reproducir Ogg Vorbis en el 940 y lo usó directamente en su código de ejemplo, si hizo eso puede que sea no solo por reproducir archivos Ogg Vorbis en el 940 sino porque puede ser que intentar usar funciones de la librería normal de Tremor directamente en el 940 debe dar problemas.
También estaría esas pruebas de las he hablamos sobre usar librerías externas en el 940, incluso de funciones de la librería de C cuando se añadian al codigo del 940 para que se ejecutaran en el y devolvieran el resultado, como con abs() que no devolvía el valor absoluto de la variable que le pasabas, fue como si no hiciera lo que debe hacer esa función, y también daba errores de enlazado al principio que se solventó especificandole la ruta y la librería de C al enlazador para que pudiera enlazarse los archivos de código objeto previamente compilados (igual que la división que había que especificarle donde estaba la librería de GCC), vamos, si es de lo que se está hablando aquí.
Yo tambien creo que el kernel no se entera para nada de que el 940 está ahí y eres tu desde el 920 el que lo tiene que controlar.Si la gente de MagicEyes ni de GPH o los de Dignsys no modificaron el kernel Linux que lleva la GP2X en este aspecto, es lo más posible. El kernel Linux no debería tener problemas para usar un procesador con MMU como el 920, pero el 940 no tiene MMU sino MPU, así que no se puede usar algo como SMP propio del kernel y a parte su rol es ser un coprocesador del 920, y para que trabajará bien con el o han modificado el kernel (al estilo de ucLinux para funcionar en sistemas embebidos con procesadores sin MMU o con MPU) o como dices toca que nosotros controlemos al 920 para que a su vez use al 940 para lo que queramos, que parece que va a ser así.
Acerbaturix
24/08/2006, 16:24
Bueno, también hay que tener en cuenta que Dzz no usa ni enlaza con la librería Tremor precompilada en el 940, sino que modificó el archivo fuente de Tremor necesario para reproducir Ogg Vorbis en el 940 y lo usó directamente en su código de ejemplo, si hizo eso puede que sea no solo por reproducir archivos Ogg Vorbis en el 940 sino porque puede ser que intentar usar funciones de la librería normal de Tremor directamente en el 940 debe dar problemas.
Sip, eso mismo decía yo por ahí arriba, que no linkó con la libreria "normal", si no que incluyó el codigo en el zip y lo compila directamente...
También estaría esas pruebas de las he hablamos sobre usar librerías externas en el 940, incluso de funciones de la librería de C cuando se añadian al codigo del 940 para que se ejecutaran en el y devolvieran el resultado, como con abs() que no devolvía el valor absoluto de la variable que le pasabas, fue como si no hiciera lo que debe hacer esa función, y también daba errores de enlazado al principio que se solventó especificandole la ruta y la librería de C al enlazador para que pudiera enlazarse los archivos de código objeto previamente compilados (igual que la división que había que especificarle donde estaba la librería de GCC), vamos, si es de lo que se está hablando aquí.
Yo probé ayer, asi por encima con algunas funciones, y lo cierto es que es todo un poco raro, por que por ejemplo probé con las funciones abs() y floor() y funcionaron perfectamente, tanto pasandole -lm al linker como sin pasarselo (eso si, si se lo pasas algo hace, por que el tamaño del fichero varía...). Sin embargo, con la función pow(), tambien de la libmath, no iba. Compilaba todo perfecto, el programa se ejecutaba perfecto, pero en memoria aparecia un valor cualquiera (memoria sin inicializar) en vez del resultado de la operación...
Lo realmente curioso y raro es el hecho de que compile sin problemas, se ejecute sin problemas pero, no ejecute esa funcion :loco: (la única explicación que se me ocurre es que el compilador/linker no metieron ese código en el programa compilado)
Si la gente de MagicEyes ni de GPH o los de Dignsys no modificaron el kernel Linux que lleva la GP2X en este aspecto, es lo más posible. El kernel Linux no debería tener problemas para usar un procesador con MMU como el 920, pero el 940 no tiene MMU sino MPU, así que no se puede usar algo como SMP propio del kernel y a parte su rol es ser un coprocesador del 920, y para que trabajará bien con el o han modificado el kernel (al estilo de ucLinux para funcionar en sistemas embebidos con procesadores sin MMU o con MPU) o como dices toca que nosotros controlemos al 920 para que a su vez use al 940 para lo que queramos, que parece que va a ser así.
Tiene toda la pinta de que va a ser así, de hecho sería lo normal supongo... cuando tenga un rato probaré a lanzar otro proceso que cargé un programa tonto en el 940 mientras se está ejecutando el ejemplo que puse por aquí, y a ver que pasa, lo normal es que el ejemplo deje de funcionar.
Yo solo pasaba por aqui para decirle a acerbaturix que si quiere gráficos para un juego me puede preguntar a mi, que estoy mas bien libre
Yo tenia ya una idea para un juego también, pero estoy viendo que lo que me falta es habilidad para ponerme a programarlo yo, y como veo que eso a ti no te va a faltar, pues mira xDDDD
Mooola :D. Mi ideilla es un juego de coches que sería una mezcla entre un Micromachines y el viejo Death Rally de PC [wei2], pero estoy abierto a otras opciones :D. De todas formas, lo cierto es que tengo muy poca experiencia en programación de video juegos, asique antes estoy haciendo pequeñas chapucillas para practicar.
Cuando me quite de delante mi examen del día 5, ya hablaremos tu y yo a ver que podemos hacer :brindis:
The_Punisher
24/08/2006, 17:00
Mooola :D. Mi ideilla es un juego de coches que sería una mezcla entre un Micromachines y el viejo Death Rally de PC [wei2], pero estoy abierto a otras opciones :D. De todas formas, lo cierto es que tengo muy poca experiencia en programación de video juegos, asique antes estoy haciendo pequeñas chapucillas para practicar.
Cuando me quite de delante mi examen del día 5, ya hablaremos tu y yo a ver que podemos hacer :brindis:
:babea: Death Rally :babea:
Acerbaturix
25/08/2006, 06:04
Por cierto, he provado lo de los 2 programas que intentan usar el 940T al mismo tiempo, con el resultado esperado, los 2 programas se quedan fritos :). Asique se confirman nuestras sospechas.
Powered by vBulletin® Version 4.2.5 Copyright © 2026 vBulletin Solutions Inc. All rights reserved.