Lo del NAO32, no es para nada preocupante, realmente
no existe un "estándar" para imágenes HDR... es todo, más bien un compromiso entre el rendimiento del engine 3D y los resultados estéticos, luego, si eso es lo quie han encontrado como solución, seguro que no es una mala solución (el Xenos utiliza fp10 para no liarla y a mí, me vale de sobra...).
En cuanto a lo de los dos buses... por una parte es una chorrada (¿no se podía haber optado por una memoria unificada?) y complica un poco más la programación gráfica... y por otra es útil, por ejemplo, en una situación en la que veamos (ya que estamos con HDR, sigo el rollo por aquí) un exterior a través de un cristal, el efecto de bloom del EXTERIOR, se nos va al carajo, ya que en el modelo geométrico usado para hacer la mascara (datos para el framebuffer) tenemos un objeto delante que le impide "ver el fondo" y obvia esa información en Z para los efectos a partir de esa barrera. Si utilizásemos un SPE para calcular la geometría de los elementos que NO TENGAN valor de transparencia (es decir, renderizar LA GEOMETRÍA sin objetos tipo cristales y texturas que tengan información en el canal alpha), podríamos utilizar los datos para introducir información en Z en el framebuffer mucho más fiel a la realidad, pudiendo generar esos efectos de bloom a través de un cristal o de materiales translucidos o con agujeros, etc... esto que acabo de decir, no debería estar reñido con una solución de memoria unificada, se puede hacer también perfectamente en ese caso (si utilizaramos un esquema de memoria unificada en la PS3... para nada me estoy refiriendo a X360)... Lo que si que digo es que, al final, lo que dice el entrevistado de Ninja Theory, es un poco hacer de PR barriendo para casa, ya que, RSX parece que no llevará, por lo que se sabe hasta ahora eDRAM para operaciones de framebuffer (lo que siempre es un plus, aunque aún no se use), sino que por lo que dice, yo deduzco más, que existe la posibilidad de "forzar" la arquitectura, para que funcione como "memoria unificada" y que gracias a la potencia del Cell en determinados aspectos, eso le podría dar una ventaja a la hora de "dotar de infomación" al framebuffer, como el ejemplo que he puesto... la aplicación de efectos de video sobre geometrías de la escena (factor que podría generar mucha mayor riqueza de efectos que cualquier tipo de revisión de shaders que se haga), etc...
Esto es lo que yo deduzco... si alguien puede aportar más luz o señalar errores, bienvenido es.