Estos datos provienen del usuario Urian de Revogamers.net
La consola no tiene 96MB sino que le quedan 96MB disponibles para los juegos comerciales.
La memoria se reparte así:
-32MB en la parte más alta de la memoria donde va el SO y las aplicaciones más utilizadas, estas aplicaciones vienen de serie con la consola y la mayoría son servicios que usan los diferentes juegos para cierta funcionalidad que comparten entre ellos, estas aplicaciones están siempre activas junto al SO.
-32MB en la parte siguiente para el segundo núcleo, este es el que hace funcionar los juegos, no se incluyen los datos gráficos.
-64MB para el PICA200 en modo 2D, la GPU es doble pero la segunda y primera GPU comparten el FIFO de comandos gráficos, la segunda GPU no se activa si no accedemos al modo 3D y no podemos usarla por separado respecto a la GPU base, ambas son iguales en caractéristicas técnicas.
-64MB espejo, se trata de la memoria reservada para la segunda GPU y así no entrar en conflicto con la primera, todo cambio que se haga en este pozo de RAM se verá automáticamente reflejado en el de la primera GPU y viceversa. No es accesible directamente por los programadores para otras tareas y cualquier cambio se reflejara en el banco de memoria.
-64MB para aplicaciones sin privilegios en modo multitarea, por ejemplo el navegador corre directamente en esta porción de memoria mientras estamos jugando, así como aplicaciones de la consola virtual, 3DSware, DSware e incluso software de apoyo que nos instalen los diferentes juegos que tengamos, el tamaño máximo de programa que puede tener cada aplicación es de 4MB pero pueden reservar para si mismas 8MB de memoria, haciendo que cada aplicación pueda ocupar hasta unos 12MB en total, si una aplicación no cabe en memoria se guardan sus datos de estado en la NAND Flash (primeros 512MB) y si es necesario se hace una "foto" del estado de sus direcciones de memoria.
Se ha de tener en cuenta que 3DS y DSi usan el mismo Sistema Operativo pero con algunos cambios para hacerlo más seguro, por ejemplo no puedes acceder al SO desde el slot de cartuchos.
-¿Los datos que aportas son de un modelo de SDK o de uno comercial?
Se trata de una consola debug, el cual lleva una pequeña aplicación que permite hacer testeos del uso de memoria de cada aplicación, porcentaje de uso de la CPU y en general todo lo necesario para optimizar el código de los juegos. Esta herramienta solo sirve para dar información en tiempo de ejecución y es eliminada de la consola final. Así que el dispositivo que estamos viendo es una consola comercial.
El motivo por el cual aparece la referencia al SDK es que solo puedes ejecutar el programa si tienes el SDK correspondiente, cada actualización de este viene con su consola+aplicación debug correspondiente.
-¿Estariamos hablando entonces de una RAM principal de 256 MB?
Si, pero esto es debido a una situación completamente curiosa.
Las especificaciones iniciales de 3DS usaban 64MB de memoria FCRAM de doble canal de 64 bits, esta memoria tiene un ancho de banda mayor por módulo que la memoria LPDDR y LPDDR2 pero es mucho más cara por MB, los desarrolladores han hecho presión sobre Nintendo para añadir más memoria lo que ha hecho que tengán que implementar la LPDDR2 en la consola.
El módulo mínimo licenciable es de 128MB pero por módulo solo existe un canal de 32 bits y para poder aumentarlo a 64 bits necesitas tener 2 módulos y es por ello que la consola ha acabado teniendo 256MB para poder mantener los anchos de banda originales y el rendimiento original de la consola.
-¿Confirmas entonces que la consola incorpora dos CPUs y una GPU de doble nucleo (PICA 200)?
De cara al desarrollo de juegos tienen una sola CPU y una sola GPU, el primer núcleo del ARM11MP se usa para la gestión del SO, tiene acceso a los primeros 32MB de memoria y no es accesible desde los juegos, aparte de eso es quien controla la E/S y el acceso a memoria a través del SO. Así como la ejecución de una serie de servicios y aplicaciones de las que todos los juegos se pueden aprovechar para funciones aún no reveladas.
En cuanto al uso de la segunda GPU, se ha de tener en cuenta que el 3D requiere duplicar recursos y por tanto aumentar la tasa de framerate al doble por lo que el sistema pasa a tener la mitad de tiempo para realizar el segundo frame, la segunda GPU no es accesible por el desarrollador y esta completamente controlada por el sistema, se encarga de hacer de apoyo a la primera y en el modo 2D de los juegos esta segunda GPU no hace acto de presencia y queda completamente apagada.
-¿Que sentido y/o aplicacion practica tiene duplicar esos 32 MB que comentas para la GPU en lugar de volcar los datos de los 32 MB "originales" en ambos nucleos?
En realidad son 64MB por núcleo, haciendo un total de 128MB.
El motivo de hacerlo es que tenemos dos módulos de memoria dentro de un mismo encapsulado, si se compartiese el canal dedicado a la GPU (es memoria DDR con dos canales y uno ya lo ocupa la CPU) entre ambas GPU nos encontraríamos que la que tiene menos privilegios de acceso estaría completamente con un retardo lo que significaría un descalabro a la hora de generar el 3D Estéreo al no coincidir las imágenes a tiempo en el buffer de imagen.
Es por ello que se duplica la memoria para que la segunda GPU tenga su propio canal de acceso y no tenga que interferir en los accesos de la primera GPU. Se hace más que nada por rendimiento.
-Ya que segun comentas el SO no es accesible desde los cartuchos ¿Sera posible actualizar la consola desde los jeugos o no?
Las actualizaciones de firmware no vendrán desde los juegos, sino que van completamente aparte. Para empezar la consola no tiene un modulo WiFi sino que dispone de dos de ellos, uno es para el online de los juegos y diversas aplicaciones, el segundo es para las actualizaciones y creeme que en muchos casos estás actualizaciones no se harán con permiso del usuario sino que serán completamente invisibles, realizadas desde el primer núcleo al que no tenemos acceso directo y con un módulo WiFi aparte al que tampoco tenemos acceso desde las aplicaciones comerciales.
No solo eso sino que además 3DS esta pensada para detectarse entre si, no solo a nivel de juegos sino también a nivel de firmware, por lo que lo que ocurrirá es que si un/una amigo/a ha actualizado su consola y tu no, puedes encontrarte que al estar los dos juntos con vuestra consola en Stand-By que su consola actualice la tuya.
-Solo me surge una duda mas a la vista de los datos que aportas y es esta: Casi todos los desarrolladores que han hablado sobre 3DS comentan que al desactivar el 3D habria un extra de potencia que permitiria algunas mejoras graficas, como aumento de la tasa de FPS o uso de algunos filtros y/o efectos, pero a la vista de lo que comentas no logro entender de donde podria salir ese "extra" ¿Podrias aclararmelo un poco o es que simplemente hablaban a nivel teorico?
No, no se gana potencia extra al desactivar el 3D ya que la segunda GPU solo se activa en ese modo, más bien lo que ocurre es otra cosa. A Capcom le dio por coger y aplicar efectos de postprocesado (Motion Blur, MSAAx4, HDR...) en su demostración técnica del MT Engine para 3DS, hay una explicación para el cual el rendimiento baja al activar estos efectos y porque no es recomendable usarlo en modo 3D.
El motivo es que en modo 2D tenemos 2MB para los buffers (triple buffer de 18 bits, Stencil Buffer de 8 bits y Z-Buffering de 24 bits) y 2MB para almacenar la geometría de escena para el multitexturizado, en el modo 3D tenemos la mitad disponible para cada núcleo. Si usamos el HDR, el MSAA y demás efectos entonces la imagen no cabe en la eDRAM y entonces tenemos que mover la información a la RAM principal, la cual tiene una velocidad de acceso mucho más baja y por tanto una latencia mayor, lo que se traduce en una pérdida sustancial del rendimiento. Los buffers en la eDRAM y la geometría en la eDRAM toman un número determinado de ciclos dependiendo de la instrucción, pero en el caso del acceso a la RAM esos accesos se doblan y el rendimiento se parte por la mitad.
Seguramente que en el modo 2D Capcom puede asignar buena parte de la memoria libre de la eDRAM a los efectos de postprocesado haciendo que sean viables, pero al necesitar un buffer para las dos imágenes y trasladarlo a la RAM principal pues...