Hablemos del interior de Xbox One

Yo los videos a no ser que sea juego exclusivo y que digan 30k veces que corresponde a Xbox One no me fio, porque me conozco bien como funciona el tema.

Luego yo hay una cosa que no entiendo, todo esos problemas que tienen las thirds para sacarle el rendimiento deseado a la Xbone son por problemas de aprendizaje del diseño del hardware o por herramientas poco maduras; si esto es asi no tendrian los mismo problemas los primeras exclusivas first y third?

GPU Xbox ONE-Graphics Core NextのCompute Unit


GPU Xbox ONE


Estimación arquitextura APU Xbox One


Audio proccesor


Main Soc

Me encanta el olor a raytracing por la mañana

Vaya con el chip de sonido. Menuda peste como se quiere minimizar con que algunos hagan un truco de magia y se saquen debajo de la manga algo que ya es igual o mejor porque sí, cuando la realidad es la ejecución por software de librerías similares (TrueAudio). Y encima todos tragando.

darksch escribió:Vaya con el chip de sonido. Menuda peste como se quiere minimizar con que algunos hagan un truco de magia y se saquen debajo de la manga algo que ya es igual o mejor porque sí, cuando la realidad es la ejecución por software de librerías similares (TrueAudio). Y encima todos tragando.

¿Puedes desarrollarlo más? No entiendo de sonido y tampoco entiendo a quién te refieres ¿A PS4?

Pensaba que las dos consolas tenían un sistema de sonido similar al final.

Igual se ha comentado ya en el post

Pues sí estás en lo cierto, pero ya se sabe que aquí no se puede comentar a "las otras"

Se sacaron de la manga a última hora un TrueAudio como que ya era igual o mejor que SHAPE, y lo que no dijeron (de forma directa o la gente no quiso entender) es que en realidad lo que tenían era las librerías TrueAudio implementadas, pero que quien lo hace correr es la CPU/GPU y no un chip dedicado, el cual lo único que hace es la des/compresión al vuelo (lo que ya se dijo que tenía al principio), pero la aplicación de efectos va a cargo de los componentes principales.

mapla escribió:

darksch escribió:Vaya con el chip de sonido. Menuda peste como se quiere minimizar con que algunos hagan un truco de magia y se saquen debajo de la manga algo que ya es igual o mejor porque sí, cuando la realidad es la ejecución por software de librerías similares (TrueAudio). Y encima todos tragando.

¿Puedes desarrollarlo más? No entiendo de sonido y tampoco entiendo a quién te refieres ¿A PS4?

Pensaba que las dos consolas tenían un sistema de sonido similar al final.

Igual se ha comentado ya en el post

XboxONE lleva procesadores SHAPE basados en una solucion de Tensilica, que realizan todo el procesamiento de audio de forma dedicada y por separado.
PS4 dedica 4 de sus 18CUs a tareas de GPGPU, entre las cuales, esta la implementacion de TrueAudio de AMD.

de esta forma, XboxONE tiene 12CUs a 853mhz dedicados a graficos, rindiendo de forma teorica a 1,31TFs. Mientras que PS4 tiene 14CUs a 800Mhz dedicados a graficos, rindiendo de forma teorica a 1,4TFs.

Adicionalmente, XboxONE tiene eSRAM y DMEs que PS4 no tiene.

El problema lo tendra PS4 en cuanto se empiece a usar DX12 y se estandarize el Render Tiling en eSRAM. Antiguamente, en la eDRAM de X360, los programadores tenian que renderizar 'en dos pasos' (porque el framebuffer no cabia en los 10MB) sobre la eDRAM y luego copiar a RAM, ese proceso de copia, aunque muy rapido, dejaba ociosa la GPU, que no pdia hacer nada mas mientras ocurria la copia. En XboxONE, el proceso de copia de la eSRAM a la RAM lo haran los DME, pudiendo la GPU dedicarse a otra cosa.

Por eso siempre hemos dicho que, independientemente de segunda capa o sin segunda en el SoC, XboxONE y PS4 estan MUY PAREJAS.

Volviendo al tema de las dos tuberías de renderizado he encontrado esto:

"la arquitectura de DUAL PIPE se dedica a trabajar simultaneamente así que mientras una está empezando a actuar la otra está todavía en proceso al final del pipe. Esto les permite maximizar el uso de la GPU porque el proceso no tiene que esperar el final de la carga y con esto consigues empezar a trabajar mientras en el otro se hace el trabajo. Es muy interesante. Si quieres hacer eso de una manera heterogénea y global, supongo que se necesita personalizar el hardware y el split, paralelizar algunos componentes. Que es lo MS hizo con sus ALU. De lo que describen, también se extrapola y explican que un pipe se dedica a sistema (supongo que como Snap -in) y el otro para los juegos . Creo que es aquí donde la arquitectura dual nativa junto al dual -driver, tiene sentido. - Con la API actual y el driver DX11.2 - el controlador sólo se puede abordar un solo pipe de renderizado para juegos. Con este controlador no tienes que preocuparte acerca de los recursos del sistema, pero no se puede maximizar la GPU (un render accionado de forma individual, no paralela) . - Con los nuevos SDK de FEBRERO- el controlador puede acceder a 2 render pipes para el juego. Supongo que en este caso, el hipervisor de la máquina se utiliza para distribuir el trabajo entre el sistema y el juego. Lo que significa que si se utiliza a pleno rendimiento durante un juego, el rendimiento será un poco limitado, pero también significa que si tu no utilizas recursos de la GPU reservados para el sistema puedes dedicar el dual pipe render para juegos. Y imagino que esto es lo que los desarrolladores de COD GHOST quisieron decir cuando pidieron a MSOFT liberar ciertos recursos extra que tenían ahí.. Mi suposición es que el doble PIPE nativo y el controlador no se puede utilizar de manera eficiente por DX11.2 porque en el fondo no puede "ver" las 2 render pipes y los 4 hilos del programador. Sólo funciona con un solo pipe de manera efectiva. Con la ayuda de DX12 se puede abordar de manera eficiente las 2 render pipes porque el trabajo asincrónico se puede abordar "directamente" a bajo nivel "to the metal". Desde las primeras entrevistas sobre DX12 insisten de paralelismo y el trabajo asincrónico. También explican por qué no podemos ver ahora mismo en beneficio de los nuevos procesadores el doble conductor. Tenemos que esperar hasta que DX12 esté disponible en plenitud para XBox One ."


Esta explicación la veo más creíble, ¿Por que? Pues porque no m creo q Microsoft se dedique a gastar tiempo y recursos en gestionar una segunda pipe, duplicar alus....etc para hacer un maldito snap mode. Si tenemos en cuenta q w8 lidia perfectamente con la multitarea, sería mucho mas sensato aumentar potencia bruta más común y no meter tantos elementos custom.

A lo q añado yo. Tenemos dos pipes, con todos los elementos q las gestionan y tenemos el doble de alus, q al parecer son DP. Sabemos q los DP son buenos para ggpu y tmb sabemos q el raytracing gasta mucha capacidad de computo. ¿Se podría utilizar una tubería para el raytracing usando los DP y la otra para el juego en si?

Szasz escribió:Volviendo al tema de las dos tuberías de renderizado he encontrado esto:

la arquitectura de DUAL PIPE se dedica a trabajar simultaneamente así que mientras una está empezando a actuar la otra está todavía en proceso al final del pipe. Esto les permite maximizar el uso de la GPU porque el proceso no tiene que esperar el final de la carga y con esto consigues empezar a trabajar mientras en el otro se hace el trabajo. Es muy interesante. Si quieres hacer eso de una manera heterogénea y global, supongo que se necesita personalizar el hardware y el split, paralelizar algunos componentes. Que es lo MS hizo con sus ALU. De lo que describen, también se extrapola y explican que un pipe se dedica a sistema (supongo que como Snap -in) y el otro para los juegos . Creo que es aquí donde la arquitectura dual nativa junto al dual -driver, tiene sentido. - Con la API actual y el driver DX11.2 - el controlador sólo se puede abordar un solo pipe de renderizado para juegos. Con este controlador no tienes que preocuparte acerca de los recursos del sistema, pero no se puede maximizar la GPU (un render accionado de forma individual, no paralela) . - Con los nuevos SDK de FEBRERO- el controlador puede acceder a 2 render pipes para el juego. Supongo que en este caso, el hipervisor de la máquina se utiliza para distribuir el trabajo entre el sistema y el juego. Lo que significa que si se utiliza a pleno rendimiento durante un juego, el rendimiento será un poco limitado, pero también significa que si tu no utilizas recursos de la GPU reservados para el sistema puedes dedicar el dual pipe render para juegos. Y imagino que esto es lo que los desarrolladores de COD GHOST quisieron decir cuando pidieron a MSOFT liberar ciertos recursos extra que tenían ahí.. Mi suposición es que el doble PIPE nativo y el controlador no se puede utilizar de manera eficiente por DX11.2 porque en el fondo no puede "ver" las 2 render pipes y los 4 hilos del programador. Sólo funciona con un solo pipe de manera efectiva. Con la ayuda de DX12 se puede abordar de manera eficiente las 2 render pipes porque el trabajo asincrónico se puede abordar "directamente" a bajo nivel "to the metal". Desde las primeras entrevistas sobre DX12 insisten de paralelismo y el trabajo asincrónico. También explican por qué no podemos ver ahora mismo en beneficio de los nuevos procesadores el doble conductor. Tenemos que esperar hasta que DX12 esté disponible en plenitud para XBox One .


Esta explicación la veo más creíble, ¿Por que? Pues porque no m creo q Microsoft se dedique a gastar tiempo y recursos en gestionar una segunda pipe, duplicar alus....etc para hacer un maldito snap mode. Si tenemos en cuenta q w8 lidia perfectamente con la multitarea, sería mucho mas sensato aumentar potencia bruta más común y no meter tantos elementos custom.

A lo q añado yo. Tenemos dos pipes, con todos los elementos q las gestionan y tenemos el doble de alus, q al parecer son DP. Sabemos q los DP son buenos para ggpu y tmb sabemos q el raytracing gasta mucha capacidad de computo. ¿Se podría utilizar una tubería para el raytracing usando los DP y la otra para el juego en si?

En realidad eso es muy relativo. Tal como ha dicho MS existe DP, uno para las capas de interfaz del SO y otro propio para los juegos, pero, ¿quién nos dice que el Pipe reservado para el SO no está usando sólo 1 CU? A lo que me refiero, es que si se ha hecho un split del pipeline para esto, lo normal es limitar al máximo el pipe del SO para no comerte el reservado para juegos, con lo que si al final, si se usara ese 2º pipe para juegos, tampoco creo que supusiera una gran mejora.

Creo recordar que MS habló sobre la posibilidad de renderizar la GUI de los juegos en paralelo y a una resolución diferente que la del juego (si se quiere, claro), así que probablemente a eso es a lo máximo que podría optar ese pipe. Quizás también se pueda usar ese pipe para tareas de postprocessing, quién sabe.

Grandes aportes

Ahora entiendo por qué Polyteres era tan tajante con esto. No veía lógico gestionar las pipes para juegos, porque nunca se ha hecho así. Pero si DX12 consigue facilitar esa tarea bienvenido sea.

Veamos lo que ya es seguro para xbox one:
+/-50% de recursos más para la CPU
Uso más eficiente de los 8 cores
Gestion herereogenea de los dos pipes
Facilidad de hacer ports Windows/Xbox One/smartphones/tablets
Más facilidad en usar move engines y esram

eloskuro escribió:Grandes aportes

Ahora entiendo por qué Polyteres era tan tajante con esto. No veía lógico gestionar las pipes para juegos, porque nunca se ha hecho así. Pero si DX12 consigue facilitar esa tarea bienvenido sea.

Veamos lo que ya es seguro para xbox one:
+/-50% de recursos más para la CPU
Uso más eficiente de los 8 cores
Gestion herereogenea de los dos pipes
Facilidad de hacer ports Windows/Xbox One/smartphones/tablets
Más facilidad en usar move engines y esram

Y a esa lista espero que podamos sumarle: Tileado automático y generación de tablas de indexación en la esram. Eso sería el mayor avance para la Xbox One, porque supondría tener una gestión de la esram transparente para aquellos engines que no quieran hacer una gestión manual. Es decir, tu engine trata la memoria del sistema como una única, pero la API, dependiendo del tamaño del buffer debería ser capaz de decidir si tilear y mover a la esram o dejarlo todo tal como esté y almacenar en la DDR3.

f5inet escribió:

mapla escribió:

darksch escribió:Vaya con el chip de sonido. Menuda peste como se quiere minimizar con que algunos hagan un truco de magia y se saquen debajo de la manga algo que ya es igual o mejor porque sí, cuando la realidad es la ejecución por software de librerías similares (TrueAudio). Y encima todos tragando.

¿Puedes desarrollarlo más? No entiendo de sonido y tampoco entiendo a quién te refieres ¿A PS4?

Pensaba que las dos consolas tenían un sistema de sonido similar al final.

Igual se ha comentado ya en el post

XboxONE lleva procesadores SHAPE basados en una solucion de Tensilica, que realizan todo el procesamiento de audio de forma dedicada y por separado.
PS4 dedica 4 de sus 18CUs a tareas de GPGPU, entre las cuales, esta la implementacion de TrueAudio de AMD.

de esta forma, XboxONE tiene 12CUs a 853mhz dedicados a graficos, rindiendo de forma teorica a 1,31TFs. Mientras que PS4 tiene 14CUs a 800Mhz dedicados a graficos, rindiendo de forma teorica a 1,4TFs.

Adicionalmente, XboxONE tiene eSRAM y DMEs que PS4 no tiene.

El problema lo tendra PS4 en cuanto se empiece a usar DX12 y se estandarize el Render Tiling en eSRAM. Antiguamente, en la eDRAM de X360, los programadores tenian que renderizar 'en dos pasos' (porque el framebuffer no cabia en los 10MB) sobre la eDRAM y luego copiar a RAM, ese proceso de copia, aunque muy rapido, dejaba ociosa la GPU, que no pdia hacer nada mas mientras ocurria la copia. En XboxONE, el proceso de copia de la eSRAM a la RAM lo haran los DME, pudiendo la GPU dedicarse a otra cosa.

Por eso siempre hemos dicho que, independientemente de segunda capa o sin segunda en el SoC, XboxONE y PS4 estan MUY PAREJAS.

Buenas, ¿me permites unas dudas?
Los procesadores de Tensilica hace bastante que se conocen. De los 15 "procesadores especiales" (que también se conocen), 8 estaban dedicados al audio. Los 4 DSP de Tensilica y otros cuatro para el resto de tareas relativas al audio (downsampling, mixing, etc.)

Lo de los 4 CUs de PS4 dedicados a GPGPU no es más que una recomendación, puedes usar 1, 2, 4, 8, o ninguno. De los pocos post-mortem que se han visto, no recuerdo que nadie haya trabajado el audio en la GPU, así que en teoría el audio debería ir a medias entre el chip secundario y la CPU.

No entiendo lo de que la PS4 va a tener problemas con el render tiling, primero ¿para qué vas a hacer render tiling si puedes usar framebuffers bastante grandes? ¿Para qué necesitas DMEs si no tienes una eSRAM a la que mover datos?
La solución de la ONE es muy buena (poner dos procesadores adicionales en el SOC para mover datos a y desde la eSRAM, que también está en el SoC), pero si no tienes esa eSRAM, entiendo que no los necesitas, es una forma diferente de hacer las cosas.

ok, ya habeis hablado uno de cada "lado"

¿podemos zanjar el tema de la ps4? Antes de que se convierta esto en un basurero

colets escribió:Buenas, ¿me permites unas dudas?
Los procesadores de Tensilica hace bastante que se conocen. De los 15 "procesadores especiales" (que también se conocen), 8 estaban dedicados al audio. Los 4 DSP de Tensilica y otros cuatro para el resto de tareas relativas al audio (downsampling, mixing, etc.)

Lo de los 4 CUs de PS4 dedicados a GPGPU no es más que una recomendación, puedes usar 1, 2, 4, 8, o ninguno. De los pocos post-mortem que se han visto, no recuerdo que nadie haya trabajado el audio en la GPU, así que en teoría el audio debería ir a medias entre el chip secundario y la CPU.

En todos los sitios que he leido, la configuracion 14+4 aparece como la 'por defecto'. ten por cuenta que en esos 4CUs de GPGPU tambien van calculadas las fisicas que, si hacemos caso a lo que dice microsoft, se calcularan en la nube en XboxONE. Dame una fuente primaria (capturas de semiaccurate, declaraciones de ingenieros de Sony o patentes de Sony, por ejemplo) donde se diga que esa configuracion de 4CUs para GPGPU es una 'recomendacion' y no una 'imposicion'.

colets escribió:No entiendo lo de que la PS4 va a tener problemas con el render tiling, primero ¿para qué vas a hacer render tiling si puedes usar framebuffers bastante grandes? ¿Para qué necesitas DMEs si no tienes una eSRAM a la que mover datos?
La solución de la ONE es muy buena (poner dos procesadores adicionales en el SOC para mover datos a y desde la eSRAM, que también está en el SoC), pero si no tienes esa eSRAM, entiendo que no los necesitas, es una forma diferente de hacer las cosas.

Correcto. la PS4 no necesita la eSRAM porque el ancho de banda con la RAM principal es lo suficientemente ancho para no necesitar de dicho parche. Aqui estamos defendiendo que dicho parche, ademas de solucionar un problema conocido (ancho de banda escaso con la RAM principal para GPU) se puede usar para mas cosas y superar en rendimiento la solucion del competidor si se usa de 'cierta forma'. ¿PS4 necesitaria eSRAM? No, para nada. seria un gasto superfluo e innecesario. ¿la eSRAM es el santo grial? No, pero permite ciertos trucos que, usados de la forma adecuada, superan en rendimiento al competidor.

eh? Pero si solo estaba intentando debatir de forma educada con f5inet, tampoco he dicho que ninguna manera de hacerlo sea mejor o peor, son simplemente, diferentes formas de hacer lo mismo.
Solo había alguna información en el mensaje del otro usuario que no me cuadraba.

Pero tienes razón, aquí es solo para hablar del interior de One, si un moderador me da un toque, ningún problema en que se borren mi post y el de f5inet.
Tema zanjado, aunque ahí me quedará la duda...

edito: perdona f5inet, no había visto tu respuesta, bastante de acuerdo con lo que dices: diferentes formas de hacer lo mismo. Una tiene una ventaja y la otra, otras. Lo de la recomendación, era en una charla de Cerny, voy a ver si lo encuentro y los posteo.

Colets
http://www.extremetech.com/gaming/164934-xbox-one-bus-bandwidths-graphics-capabilities-and-odd-soc-architecture-confirmed-by-microsoft

Microsoft claims a total of 15 non-CPU processing blocks, which works out to12 for the GPU[/b], two for audio, and an “other” possibly related to I/O or Kinect. The CPU, as previously reported, is an eight-core Jaguar variant. Microsoft claims the audio engine contains multiple discrete function blocks with their own impressive hardware stats, but a description of audio capability is beyond the scope of this discussion.

De donde sacas lo que dices? No lo digo a malas. Es solo por contrastar y desentrañar entre todos la realidad.

edito:

Y colets. Tu aporta sin tapujos Que para eso estamos. Lo mejor es no enfatizar como habeis hecho en ps4, pero alguna cosilla se puede decir sin pasarse, claro está.

Perdona eloskuro, que me estáis bombardeando un poco
¿Lo que digo respecto a qué? ¿Lo de los 15 procesadores especiales y los 8 de audio? Lo digo por hablar solo del hardware de One y no meternos en líos. ¿o algo de lo que he comentadode "la otra"?

¿Alguien sabe la funcionalidad de la SRAM situada entre los dos bloques Jaguar? ¿Su capacidad?
¿Y por qué los 32MB de eSRAM tras la GPU se distribuyen lógicamente -y físicamente- en 4 módulos de 8MB?

Lo del chip de audio dedicado no es de extrañar, cuando en x360 el procesamiento del audio necesitaba media cpu solo para ella (3 hilos creo recordar)

@eloskuro, de donde sale el +~50% de recursos para cpu?

KinderRey escribió:¿Alguien sabe la funcionalidad de la SRAM situada entre los dos bloques Jaguar? ¿Su capacidad?
¿Y por qué los 32MB de eSRAM tras la GPU se distribuyen lógicamente -y físicamente- en 4 módulos de 8MB?

A lo 1º se me ocurren varias cosas:
- Caché L3 compartida por los bloques.
- Mirror de datos homogéneos, un mirror de estos datos obtenidos por GPGPU que haría el DMA de turno en esa memoria para que la CPU lo tenga ya en su caché.

A lo 2º, podría ser:
- Porque no se fabriquen más grandes.
- Para parelelizar acceso, si es verdad lo del bus de 1024 bits podrían ser porque son 256x4. Puedes colocar 4 datos en el bus de una sola vez.

KinderRey escribió:¿Alguien sabe la funcionalidad de la SRAM situada entre los dos bloques Jaguar? ¿Su capacidad?
¿Y por qué los 32MB de eSRAM tras la GPU se distribuyen lógicamente -y físicamente- en 4 módulos de 8MB?

No se sabe. Yo entiendo q funciona como una cache l2\3 muy grande. Sino me falla la memoria los primeros quad core(intel), eran dos dual cores unidos(como dos clusters, al igual q xbox one, q dispone de dos clusters de 4 núcleos cada uno), al tener esa disposición tuvieron q aumentar la memoria cache de forma muy importante para no perder mucho rendimiento.

Edito: the Q6600 (no “X” because it’s not eXtreme) is really two Core 2 Duo CPUs in a single package. From a Windows licensing point of view, it looks like a single CPU with four cores.

Kentsfield, the code name for the quad-core chip, is literally two dies built into a single multi-chip module

Each die offers 4MB of shared L2 cache, but each cache is dedicated to the two cores on that die. If data needs to be passed back and forth between the two cores, it must be done over the 1066MHz (effective) shared front-side bus (FSB.) Intel suggests in its technical literature that the FSB has plenty of bandwidth to handle the kind of traffic used by a desktop CPU. As with the rest of the Core 2 line of CPUs, the QX6700 is manufactured on Intel’s 65nm process technology.

- En el tema de la sram de la gpu no tengo ninguna idea loca q aportar.

f5inet escribió:

colets escribió:Buenas, ¿me permites unas dudas?
Los procesadores de Tensilica hace bastante que se conocen. De los 15 "procesadores especiales" (que también se conocen), 8 estaban dedicados al audio. Los 4 DSP de Tensilica y otros cuatro para el resto de tareas relativas al audio (downsampling, mixing, etc.)

Lo de los 4 CUs de PS4 dedicados a GPGPU no es más que una recomendación, puedes usar 1, 2, 4, 8, o ninguno. De los pocos post-mortem que se han visto, no recuerdo que nadie haya trabajado el audio en la GPU, así que en teoría el audio debería ir a medias entre el chip secundario y la CPU.

En todos los sitios que he leido, la configuracion 14+4 aparece como la 'por defecto'. ten por cuenta que en esos 4CUs de GPGPU tambien van calculadas las fisicas que, si hacemos caso a lo que dice microsoft, se calcularan en la nube en XboxONE. Dame una fuente primaria (capturas de semiaccurate, declaraciones de ingenieros de Sony o patentes de Sony, por ejemplo) donde se diga que esa configuracion de 4CUs para GPGPU es una 'recomendacion' y no una 'imposicion'.

colets escribió:No entiendo lo de que la PS4 va a tener problemas con el render tiling, primero ¿para qué vas a hacer render tiling si puedes usar framebuffers bastante grandes? ¿Para qué necesitas DMEs si no tienes una eSRAM a la que mover datos?
La solución de la ONE es muy buena (poner dos procesadores adicionales en el SOC para mover datos a y desde la eSRAM, que también está en el SoC), pero si no tienes esa eSRAM, entiendo que no los necesitas, es una forma diferente de hacer las cosas.

Correcto. la PS4 no necesita la eSRAM porque el ancho de banda con la RAM principal es lo suficientemente ancho para no necesitar de dicho parche. Aqui estamos defendiendo que dicho parche, ademas de solucionar un problema conocido (ancho de banda escaso con la RAM principal para GPU) se puede usar para mas cosas y superar en rendimiento la solucion del competidor si se usa de 'cierta forma'. ¿PS4 necesitaria eSRAM? No, para nada. seria un gasto superfluo e innecesario. ¿la eSRAM es el santo grial? No, pero permite ciertos trucos que, usados de la forma adecuada, superan en rendimiento al competidor.

Creo que has dado y sigues dando muy buenos aportes, pero eso que te marco, creo que tiene más miga de lo que parece. Tenemos que tener en cuenta que Ps4 usa un SoC diseñado por AMD también, y que AMD ha diseñado Mantle para poder tener una API "bare to metal", así que seguramente Ps4 herede cosas de Mantle. Eso quiere decir que no existe configuración por defecto de los CU, es decir, deberías poder usar los 18CU's para gráficos y dejar las tareas de procesamiento de audio y físicas para los jaguars.

Del mismo modo, el offload de físicas en la nube no creo que lo debamos tomar aún como un hecho. Las físicas van a tener que ir a la GPU o a la CPU, gastando los recursos que toquen.

Creo que la diferencia aquí la van a marcar el 12CU+SHAPE+coprocesadores vs los 18CU adicionales que tiene Ps4. Habrá que ver cómo usan los engines una arquitectura y otra porque a mi se me hace imposible averiguar cuál de las dos podrá rendir mejor. Eso sí, parece, y digo parece, que al final una cosa por otra ambas plataformas están compensadas y son muy parecidas.

KinderRey escribió:¿Alguien sabe la funcionalidad de la SRAM situada entre los dos bloques Jaguar? ¿Su capacidad?
¿Y por qué los 32MB de eSRAM tras la GPU se distribuyen lógicamente en 4 bloques de 8MB?

Se me ocurre que podría ser para mejorar la velocidad de acceso a los datos. A menor tamaño de la memoria, menos tiempo se tarda en recorrerla. Eso ya es hablar a un nivel que se me escapa, porque realmente no sé cómo se implementa a nivel de hardware un salto directo en la memoria, y porque hace ya muchos años que estudié arquitectura de computadores jeje. Supongo que debe existir una tabla de índices con las direcciones de memoria físicas, y a mayor cantidad de memoria mayor es la tabla de índices y más tiempo se tarda en encontrar la dirección de memoria que le pida el controlador.

KinderRey escribió:¿Alguien sabe la funcionalidad de la SRAM situada entre los dos bloques Jaguar? ¿Su capacidad?
¿Y por qué los 32MB de eSRAM tras la GPU se distribuyen lógicamente -y físicamente- en 4 módulos de 8MB?

viewtopic.php?p=1735508446
Yo apuesto mas por el tema que los chicos de Redmond han añadido una extension al DirectX de la consola para meter los 'drawcall' en una mini-eSRAM y que sea la GPU quien lea y ejecute directamente esos Draw-Call, sin necesidad de estar siendo 'alimentada' por la CPU.

DirectX hasta la version 11.2 es muy dependiente de la velocidad de la CPU, mas que nada, porque DirectX siempre ha confiado en acaparar un unico nucleo para 'alimentar' la GPU de tareas. basicamente, aunque tengas la GPU mas potente del mundo, si no eres capaz de tenerla ocupada mandandole tareas, llega el momento que se vuelve 'ociosa' porque no tiene nada que hacer (la GPU se queda esperando a la CPU) y es cuando decimos que un juego o aplicacion es 'CPU-bound' (o sea, su rendimiento esta limitado por la CPU).

En TomsHardware teneis un monton de analisis en los cuales el mismo juego, aumenta de framerate al aumentar la potencia de la CPU, siendo la misma GPU.

Este caso es mucho mas sangrante con los cores Jaguar, que son de bajo rendimiento. La solucion que habran tomado en Microsoft es usar un pequeño pool de ram ultra-rapida (eSRAM) para 'encolar' los draw-calls y que sea la GPU quien los ejecute. adicionalmente, es posible que los draw-calls puedan ser marcados como 'alta prioridad' o 'baja prioridad'. Un ejemplo de un drawcall de alta prioridad seria ejecutar un shader grafico para pintar en pantalla, mientras que un drawcall de baja prioridad seria uno para calcular un reflejo en una textura (que si da tiempo en ese frame, perfecto, y sino, para el siguiente)


En la imagen, se ven los dos 'pools' de eSRAM en la derecha (2x16MB=32MB) y una pequeña eSRAM entre los modulos quad-jaguar. Esa pequeña eSRAM (que calculando a ojo serian 4MB) seria la cola de drawcalls que TODOS los cpus Jaguar podrian alimentar y seria la GPU quien sacara directamente los drawcalls para mantenerse alimentada.

Cabe destacar que la razon de esta arquitectura es por el pobre rendimiento y adaptacion de DirectX a entornos multicore de bajo rendimiento. DirectX no ha tenido problemas mientras tuviese una CPU potente capaz de mantener alimentada a la GPU, el problema surge CUANDO NO ES ASI, y es en estos momentos de la 'era multicore' (tener muchos cores de poca potencia, y apagar los que no necesites para ahorrar energia) cuando se le ven las verguenzas a DirectX. es por eso que se ha desarrollado Mantle y que los de OpenGL dicen que pueden superar en 4 o 5 veces el rendimiento de DirectX, y lo hacen, pero en CPUs MODESTAS. en CPUs que son potentes de por si, como un i7, DirectX no tiene tal problema.

El problema existia en DirectX, y los de Microsoft han desarrollado diversas tecnicas para superarlo, como crear una nueva version de DirectX (v12) que sea capaz de ejecutar drawcalls de forma asincrona y simultanea (adaptada y optimizada para entornos multicore) y metiendo una cola de tareas en XboxONE.

y la gran pregunta ¿Tiene OpenGL y/o PS4 este problema? es posible que en algun momento lo tuviesen. ¿lo han arreglado? Ya lo veremos. Lo que si es cierto es que XboxONE, a partir del update que meta DirectX12 y que las desarrolladoras tengan los SDKs actualizados a DX12, ya no tendran ese problema.

colets escribió:Perdona eloskuro, que me estáis bombardeando un poco
¿Lo que digo respecto a qué? ¿Lo de los 15 procesadores especiales y los 8 de audio? Lo digo por hablar solo del hardware de One y no meternos en líos. ¿o algo de lo que he comentadode "la otra"?

Digo lo de los 8 procesadores especiales para el audio. Que segun pone en extreme tech, 2 son para el audio, 12 para tareas de la GPU y el otro no saben.

Zokor: Del BUILD 2014. He puesto +/- porque en la xbox one no sabemos cuanto será el porcentaje real de mejora en la utilización de la CPU. Igual es un 20% o o un 60% Who know
http://blogs.msdn.com/b/jgalasyn/archive/2014/03/21/directx-12-announced-get-the-deets-here.aspx

3DMark – Multi-thread scaling + 50% better CPU utilization

If you’re a gamer, you know what 3DMark is – a great way to do game performance benchmarking on all your hardware and devices. This makes it an excellent choice for verifying the performance improvements that Direct3D 12 will bring to games. 3DMark on Direct3D 11 uses multi-threading extensively, however due to a combination of runtime and driver overhead, there is still significant idle time on each core. After porting the benchmark to use Direct3D 12, we see two major improvements – a 50% improvement in CPU utilization, and better distribution of work among threads. […]

f5inet escribió:Cabe destacar que la razon de esta arquitectura es por el pobre rendimiento y adaptacion de DirectX a entornos multicore de bajo rendimiento. DirectX no ha tenido problemas mientras tuviese una CPU potente capaz de mantener alimentada a la GPU, el problema surge CUANDO NO ES ASI, y es en estos momentos de la 'era multicore' (tener muchos cores de poca potencia, y apagar los que no necesites para ahorrar energia) cuando se le ven las verguenzas a DirectX. es por eso que se ha desarrollado Mantle y que los de OpenGL dicen que pueden superar en 4 o 5 veces el rendimiento de DirectX, y lo hacen, pero en CPUs MODESTAS. en CPUs que son potentes de por si, como un i7, DirectX no tiene tal problema.

Vamos, que en pleno 2014 la tan aclamada D3D sigue siendo una API monothread que lastra el resto del sistema. Menos mal que se supone que lo van a arreglar en DX12, porque vaya panorama xD

f5inet escribió:

KinderRey escribió:¿Alguien sabe la funcionalidad de la SRAM situada entre los dos bloques Jaguar? ¿Su capacidad?
¿Y por qué los 32MB de eSRAM tras la GPU se distribuyen lógicamente -y físicamente- en 4 módulos de 8MB?

http://www.elotrolado.net/viewtopic.php?p=1735508446
Yo apuesto mas por el tema que los chicos de Redmond han añadido una extension al DirectX de la consola para meter los 'drawcall' en una mini-eSRAM y que sea la GPU quien lea y ejecute directamente esos Draw-Call, sin necesidad de estar siendo 'alimentada' por la CPU.

DirectX hasta la version 11.2 es muy dependiente de la velocidad de la CPU, mas que nada, porque DirectX siempre ha confiado en acaparar un unico nucleo para 'alimentar' la GPU de tareas. basicamente, aunque tengas la GPU mas potente del mundo, si no eres capaz de tenerla ocupada mandandole tareas, llega el momento que se vuelve 'ociosa' porque no tiene nada que hacer (la GPU se queda esperando a la CPU) y es cuando decimos que un juego o aplicacion es 'CPU-bound' (o sea, su rendimiento esta limitado por la CPU).

En TomsHardware teneis un monton de analisis en los cuales el mismo juego, aumenta de framerate al aumentar la potencia de la CPU, siendo la misma GPU.

Este caso es mucho mas sangrante con los cores Jaguar, que son de bajo rendimiento. La solucion que habran tomado en Microsoft es usar un pequeño pool de ram ultra-rapida (eSRAM) para 'encolar' los draw-calls y que sea la GPU quien los ejecute. adicionalmente, es posible que los draw-calls puedan ser marcados como 'alta prioridad' o 'baja prioridad'. Un ejemplo de un drawcall de alta prioridad seria ejecutar un shader grafico para pintar en pantalla, mientras que un drawcall de baja prioridad seria uno para calcular un reflejo en una textura (que si da tiempo en ese frame, perfecto, y sino, para el siguiente)


En la imagen, se ven los dos 'pools' de eSRAM en la derecha (2x16MB=32MB) y una pequeña eSRAM entre los modulos quad-jaguar. Esa pequeña eSRAM (que calculando a ojo serian 4MB) seria la cola de drawcalls que TODOS los cpus Jaguar podrian alimentar y seria la GPU quien sacara directamente los drawcalls para mantenerse alimentada.

Cabe destacar que la razon de esta arquitectura es por el pobre rendimiento y adaptacion de DirectX a entornos multicore de bajo rendimiento. DirectX no ha tenido problemas mientras tuviese una CPU potente capaz de mantener alimentada a la GPU, el problema surge CUANDO NO ES ASI, y es en estos momentos de la 'era multicore' (tener muchos cores de poca potencia, y apagar los que no necesites para ahorrar energia) cuando se le ven las verguenzas a DirectX. es por eso que se ha desarrollado Mantle y que los de OpenGL dicen que pueden superar en 4 o 5 veces el rendimiento de DirectX, y lo hacen, pero en CPUs MODESTAS. en CPUs que son potentes de por si, como un i7, DirectX no tiene tal problema.

El problema existia en DirectX, y los de Microsoft han desarrollado diversas tecnicas para superarlo, como crear una nueva version de DirectX (v12) que sea capaz de ejecutar drawcalls de forma asincrona y simultanea (adaptada y optimizada para entornos multicore) y metiendo una cola de tareas en XboxONE.

y la gran pregunta ¿Tiene OpenGL y/o PS4 este problema? es posible que en algun momento lo tuviesen. ¿lo han arreglado? Ya lo veremos. Lo que si es cierto es que XboxONE, a partir del update que meta DirectX12 y que las desarrolladoras tengan los SDKs actualizados a DX12, ya no tendran ese problema.

Y a parte de una cola de drawcalls, que tiene bastante sentido que esté ahí, ¿podrían almacenarse ahí las tablas de índices de los Tiled Resources?, sería una manera de dejar los 32MB de esram completamente para texturas.

Lo de 256x4 está confirmado, y es la razón por la que se puede leer y escribir simultáneamente en la eSRAM.
Quería ir más allá.

En cuanto a lo 1º, si es una caché L3 sin más entre los dos bloques, por qué no aparece en los diagramas de Hot Chips?

Ah, ok eloskuro, al lío: creo que ese artículo de xtremetech está desfasado, mejor lee el de eurogamer donde hablan ingenieros de microsoft, que es más moderno y es una fuente más fiable:
http://www.eurogamer.net/articles/digit ... -interview
En concreto este párrafo:

Digital Foundry: You talk about having 15 processors. Can you break that down?

Nick Baker: On the SoC, there are many parallel engines - some of those are more like CPU cores or DSP cores. How we count to 15: [we have] eight inside the audio block, four move engines, one video encode, one video decode and one video compositor/resizer.

The audio block was completely unique. That was designed by us in-house. It's based on four tensilica DSP cores and several programmable processing engines. We break it up as one core running control, two cores running a lot of vector code for speech and one for general purpose DSP. We couple with that sample rate conversion, filtering, mixing, equalisation, dynamic range compensation then also the XMA audio block. The goal was to run 512 simultaneous voices for game audio as well as being able to do speech pre-processing for Kinect.

Si alguien quiere, puedo extenderlo un poco más, explicando para qué es cada "processor"


A mí ese bloque de eSRAM entre los dos Jaguar también me tiene un poco mosca. Podría lo que dice darksch, ¿una especie de caché para la CPU?
Su capacidad debería ser relativamente sencilla de obtener: Sabemos que en el SoC hay 47 MB en total, quitamos 32 de la eSRAM, quitamos todas las cachés y lo que quede, debería ser la capacidad de ese tercer bloque de eSRAM.
Lo de porqué repartir los 32 MB en bloques de 8, ni idea, la explicación de darsch me parece lógica.

Para f5inet:

Yo apuesto mas por el tema que los chicos de Redmond han añadido una extension al DirectX de la consola para meter los 'drawcall' en una mini-eSRAM y que sea la GPU quien lea y ejecute directamente esos Draw-Call, sin necesidad de estar siendo 'alimentada' por la CPU.

Se me olvidaba eso, claro que se usa para eso y DX12 lo usa para encolar ahí las tareas. 4MB son mucho sólo para draw-calls así que me parece que se usará para eso y como caché L3.
No es necesario una eSRAM para tal fin, y de hecho en PC no se tendrá, pero es otra solución más hardware que incorpora XO para esto. Es el típico detalle como otros tantos que tiene este hardware para ayudar a implementar y optimizar dichas soluciones. Es decir conseguir más rendimiento con componentes más pequeños, simplemente añadiendo un pequeño extra.
Sin embargo, una GPU no puede autoalimentarse, es la CPU (la C de Central) la que lo hace y por eso aún con DX12 se tiene uso de CPU pero menor y repartido. Sin embargo el tener una caché para distribuir por todos los núcleos ayuda seguro a evitar ciclos muertos.

y la gran pregunta ¿Tiene OpenGL y/o PS4 este problema?

Que yo sepa ahora mismo TODAS las API lo tienen, en OpenGL salvo que ya esté disponible la nueva versión lo va a solucionar al igual que hará DX12. Una vez se tenga cada uno tendrá que portar el nuevo OpenGL a su plataforma, por lo que Sony tendrá que hacerlo para su PS4.
Pero ahora mismo todas funcionan igual por eso se obtienen resultados similares y con los mismos inconvenientes.

Seran APIs graficas, porque APIs multithread hay multitud de ellas

hsaoud escribió:

Szasz escribió:Volviendo al tema de las dos tuberías de renderizado he encontrado esto:

la arquitectura de DUAL PIPE se dedica a trabajar simultaneamente así que mientras una está empezando a actuar la otra está todavía en proceso al final del pipe. Esto les permite maximizar el uso de la GPU porque el proceso no tiene que esperar el final de la carga y con esto consigues empezar a trabajar mientras en el otro se hace el trabajo. Es muy interesante. Si quieres hacer eso de una manera heterogénea y global, supongo que se necesita personalizar el hardware y el split, paralelizar algunos componentes. Que es lo MS hizo con sus ALU. De lo que describen, también se extrapola y explican que un pipe se dedica a sistema (supongo que como Snap -in) y el otro para los juegos . Creo que es aquí donde la arquitectura dual nativa junto al dual -driver, tiene sentido. - Con la API actual y el driver DX11.2 - el controlador sólo se puede abordar un solo pipe de renderizado para juegos. Con este controlador no tienes que preocuparte acerca de los recursos del sistema, pero no se puede maximizar la GPU (un render accionado de forma individual, no paralela) . - Con los nuevos SDK de FEBRERO- el controlador puede acceder a 2 render pipes para el juego. Supongo que en este caso, el hipervisor de la máquina se utiliza para distribuir el trabajo entre el sistema y el juego. Lo que significa que si se utiliza a pleno rendimiento durante un juego, el rendimiento será un poco limitado, pero también significa que si tu no utilizas recursos de la GPU reservados para el sistema puedes dedicar el dual pipe render para juegos. Y imagino que esto es lo que los desarrolladores de COD GHOST quisieron decir cuando pidieron a MSOFT liberar ciertos recursos extra que tenían ahí.. Mi suposición es que el doble PIPE nativo y el controlador no se puede utilizar de manera eficiente por DX11.2 porque en el fondo no puede "ver" las 2 render pipes y los 4 hilos del programador. Sólo funciona con un solo pipe de manera efectiva. Con la ayuda de DX12 se puede abordar de manera eficiente las 2 render pipes porque el trabajo asincrónico se puede abordar "directamente" a bajo nivel "to the metal". Desde las primeras entrevistas sobre DX12 insisten de paralelismo y el trabajo asincrónico. También explican por qué no podemos ver ahora mismo en beneficio de los nuevos procesadores el doble conductor. Tenemos que esperar hasta que DX12 esté disponible en plenitud para XBox One .


Esta explicación la veo más creíble, ¿Por que? Pues porque no m creo q Microsoft se dedique a gastar tiempo y recursos en gestionar una segunda pipe, duplicar alus....etc para hacer un maldito snap mode. Si tenemos en cuenta q w8 lidia perfectamente con la multitarea, sería mucho mas sensato aumentar potencia bruta más común y no meter tantos elementos custom.

A lo q añado yo. Tenemos dos pipes, con todos los elementos q las gestionan y tenemos el doble de alus, q al parecer son DP. Sabemos q los DP son buenos para ggpu y tmb sabemos q el raytracing gasta mucha capacidad de computo. ¿Se podría utilizar una tubería para el raytracing usando los DP y la otra para el juego en si?

En realidad eso es muy relativo. Tal como ha dicho MS existe DP, uno para las capas de interfaz del SO y otro propio para los juegos, pero, ¿quién nos dice que el Pipe reservado para el SO no está usando sólo 1 CU? A lo que me refiero, es que si se ha hecho un split del pipeline para esto, lo normal es limitar al máximo el pipe del SO para no comerte el reservado para juegos, con lo que si al final, si se usara ese 2º pipe para juegos, tampoco creo que supusiera una gran mejora.

Creo recordar que MS habló sobre la posibilidad de renderizar la GUI de los juegos en paralelo y a una resolución diferente que la del juego (si se quiere, claro), así que probablemente a eso es a lo máximo que podría optar ese pipe. Quizás también se pueda usar ese pipe para tareas de postprocessing, quién sabe.

Pero no hay ningún dato oficial que afirme que un pipe se reserva exclusivamente para el SO.

Que tener dos ayuda a que no moleste nada al renderizado del juego sí, que su uso solo sea ese no.

eloskuro escribió:Colets
http://www.extremetech.com/gaming/164934-xbox-one-bus-bandwidths-graphics-capabilities-and-odd-soc-architecture-confirmed-by-microsoft

Microsoft claims a total of 15 non-CPU processing blocks, which works out to12 for the GPU[/b], two for audio, and an “other” possibly related to I/O or Kinect. The CPU, as previously reported, is an eight-core Jaguar variant. Microsoft claims the audio engine contains multiple discrete function blocks with their own impressive hardware stats, but a description of audio capability is beyond the scope of this discussion.

De donde sacas lo que dices? No lo digo a malas. Es solo por contrastar y desentrañar entre todos la realidad.

edito:

Y colets. Tu aporta sin tapujos Que para eso estamos. Lo mejor es no enfatizar como habeis hecho en ps4, pero alguna cosilla se puede decir sin pasarse, claro está.

Ese discurso se lo he oído mucho a Herebus, anda que no es cabezón con el tema este del audio.

KinderRey escribió:¿Alguien sabe la funcionalidad de la SRAM situada entre los dos bloques Jaguar? ¿Su capacidad?
¿Y por qué los 32MB de eSRAM tras la GPU se distribuyen lógicamente -y físicamente- en 4 módulos de 8MB?

Y yo pregunto si saber: ¿Eso es SRAM seguro?

Porque a simple vista se parece mucho, pero a simple vista también es diferente. Parecida pero no identica.

De donde sacáis que sea SRAM?

Horizonte de sucesos escribió:
Pero no hay ningún dato oficial que afirme que un pipe se reserva exclusivamente para el SO.

Que tener dos ayuda a que no moleste nada al renderizado del juego sí, que su uso solo sea ese no.

Creo recordar que se puso hace uno o dos días el vídeo íntegro del debate entre desarrolladores de One moderado por Larry Hryb, y Boyd Multerer dijo que los dos pipes "PODÍAN" usarse para las dos funciones (juego y sistema) por separado para distribuir tareas, pero no que fuese necesario. Ni mucho menos se dijo que hubiese un tanto reservado para ello ni nada, porque son ajustables.

colets escribió:Ah, ok eloskuro, al lío: creo que ese artículo de xtremetech está desfasado, mejor lee el de eurogamer donde hablan ingenieros de microsoft, que es más moderno y es una fuente más fiable:
http://www.eurogamer.net/articles/digit ... -interview
En concreto este párrafo:

Digital Foundry: You talk about having 15 processors. Can you break that down?

Nick Baker: On the SoC, there are many parallel engines - some of those are more like CPU cores or DSP cores. How we count to 15: [we have] eight inside the audio block, four move engines, one video encode, one video decode and one video compositor/resizer.

The audio block was completely unique. That was designed by us in-house. It's based on four tensilica DSP cores and several programmable processing engines. We break it up as one core running control, two cores running a lot of vector code for speech and one for general purpose DSP. We couple with that sample rate conversion, filtering, mixing, equalisation, dynamic range compensation then also the XMA audio block. The goal was to run 512 simultaneous voices for game audio as well as being able to do speech pre-processing for Kinect.

Si alguien quiere, puedo extenderlo un poco más, explicando para qué es cada "processor"


A mí ese bloque de eSRAM entre los dos Jaguar también me tiene un poco mosca. Podría lo que dice darksch, ¿una especie de caché para la CPU?
Su capacidad debería ser relativamente sencilla de obtener: Sabemos que en el SoC hay 47 MB en total, quitamos 32 de la eSRAM, quitamos todas las cachés y lo que quede, debería ser la capacidad de ese tercer bloque de eSRAM.
Lo de porqué repartir los 32 MB en bloques de 8, ni idea, la explicación de darsch me parece lógica.

Para f5inet:

Lo siento pero no he podido encontrar las declaraciones en las que pensaba.
lo de 14+4 fijo viene de esta filtración de 2012, con el hardware no cerrado todavía:
http://www.vgleaks.com/playstation-4-ba ... nbalanced/

Pero en una entrevista posterior, Cerny da a entender (o yo lo interpreto así) que puedes usarlos como quieras:
http://www.eurogamer.net/articles/digit ... mark-cerny

Digital Foundry: Going back to GPU compute for a moment, I wouldn't call it a rumour - it was more than that. There was a recommendation - a suggestion? - for 14 cores [GPU compute units] allocated to visuals and four to GPU compute...

Mark Cerny: That comes from a leak and is not any form of formal evangelisation. The point is the hardware is intentionally not 100 per cent round. It has a little bit more ALU in it than it would if you were thinking strictly about graphics. As a result of that you have an opportunity, you could say an incentivisation, to use that ALU for GPGPU.

Si encuentyro algún sitio donde lo diga más claro, lo pongo.

http://semiaccurate.com/2013/08/30/a-deep-dive-in-to-microsofts-xbox-one-gpu-and-on-die-memory/

En semmiaccurate tambien lo exponen así como dices
For simplicity we will use a co-processor count of 7 in the GPU block, 8 in the Audio unit.

darksch escribió:

Yo apuesto mas por el tema que los chicos de Redmond han añadido una extension al DirectX de la consola para meter los 'drawcall' en una mini-eSRAM y que sea la GPU quien lea y ejecute directamente esos Draw-Call, sin necesidad de estar siendo 'alimentada' por la CPU.

Se me olvidaba eso, claro que se usa para eso y DX12 lo usa para encolar ahí las tareas. 4MB son mucho sólo para draw-calls así que me parece que se usará para eso y como caché L3.
No es necesario una eSRAM para tal fin, y de hecho en PC no se tendrá, pero es otra solución más hardware que incorpora XO para esto. Es el típico detalle como otros tantos que tiene este hardware para ayudar a implementar y optimizar dichas soluciones. Es decir conseguir más rendimiento con componentes más pequeños, simplemente añadiendo un pequeño extra.
Sin embargo, una GPU no puede autoalimentarse, es la CPU (la C de Central) la que lo hace y por eso aún con DX12 se tiene uso de CPU pero menor y repartido. Sin embargo el tener una caché para distribuir por todos los núcleos ayuda seguro a evitar ciclos muertos.

We wanted higher coherency between the GPU and the CPU so that was something that needed to be done, that touched a lot of the fabric around the CPU

En mi opinión, esa SRAM tiene que ver con lograr una arquitectura full HSA con un gran ancho de banda, la CPU alimenta a la GPU y viceversa. Una GPU full HSA puede monitorear y aceptar colas de trabajo de la CPU y de aplicaciones, y a su vez puede programarlas para si misma y para la CPU. La reducción de latencia es bestial.



Pero ahí hay algo más. Ese bloque no aparece explícitamente representado en los diagramas de Hot Chips por alguna razón.

Es que lo que dice FlasHBackMan360 tiene lógica, lo de Network on a Chip. NOC.

Si miras información se basa fundamentalmete en mejorar el flujo de información. Asumen que escalar potencia bruta es ahora mismo una via muerta y se centran en mejorar la comunicación entre lo diferentes componentes, en este caso CPU, GPU y los 15 copocesadores que ya han dicho que son como pequñas CPU. ¿Y si esos coprocesadores fueran rollo FPGA que pueden programarse en cada momento para que hagan lo que te salga del ciruelo? ¿Y si fueran lo que hicieran feura manejar datos a modo de routers para mejorar la eficiencia de la máquina?

Por otro todo lo que he leido de Network on a chip hace referencia al uso de la Sram y por otro lado hay una patente de microsoft para usar a la vez memoria flash y memoria DRam utilizando un pool de Sram que unifique el trabajo de ambas. ¿Y si la Flash se utiliza también para alimentar la SRam? Podría hacerlo y cuando se apague almacenar cosas. ¿Y si la nueb local fuera esa Flas? No hemos hablado muchas veces que azure calcularia una vez y guardaría los datos para distribuirlos? ¿Y si se almacenan en esa flash y se usan después?

Son todo tiros al aire de una persona que no entiende, que quede claro.

papatuelo escribió:Es que lo que dice FlasHBackMan360 tiene lógica, lo de Network on a Chip. NOC.

Si miras información se basa fundamentalmete en mejorar el flujo de información. Asumen que escalar potencia bruta es ahora mismo una via muerta y se centran en mejorar la comunicación entre lo diferentes componentes, en este caso CPU, GPU y los 15 copocesadores que ya han dicho que son como pequñas CPU. ¿Y si esos coprocesadores fueran rollo FPGA que pueden programarse en cada momento para que hagan lo que te salga del ciruelo? ¿Y si fueran lo que hicieran feura manejar datos a modo de routers para mejorar la eficiencia de la máquina?

Por otro todo lo que he leido de Network on a chip hace referencia al uso de la Sram y por otro lado hay una patente de microsoft para usar a la vez memoria flash y memoria DRam utilizando un pool de Sram que unifique el trabajo de ambas. ¿Y si la Flash se utiliza también para alimentar la SRam? Podría hacerlo y cuando se apague almacenar cosas. ¿Y si la nueb local fuera esa Flas? No hemos hablado muchas veces que azure calcularia una vez y guardaría los datos para distribuirlos? ¿Y si se almacenan en esa flash y se usan después?

Son todo tiros al aire de una persona que no entiende, que quede claro.

Yo pienso igual en lo relativo a la nube local, que va a ser la flash la que alimente con esos datos.

papatuelo escribió:Es que lo que dice FlasHBackMan360 tiene lógica, lo de Network on a Chip. NOC.

Si miras información se basa fundamentalmete en mejorar el flujo de información. Asumen que escalar potencia bruta es ahora mismo una via muerta y se centran en mejorar la comunicación entre lo diferentes componentes, en este caso CPU, GPU y los 15 copocesadores que ya han dicho que son como pequñas CPU. ¿Y si esos coprocesadores fueran rollo FPGA que pueden programarse en cada momento para que hagan lo que te salga del ciruelo? ¿Y si fueran lo que hicieran feura manejar datos a modo de routers para mejorar la eficiencia de la máquina?

Por otro todo lo que he leido de Network on a chip hace referencia al uso de la Sram y por otro lado hay una patente de microsoft para usar a la vez memoria flash y memoria DRam utilizando un pool de Sram que unifique el trabajo de ambas. ¿Y si la Flash se utiliza también para alimentar la SRam? Podría hacerlo y cuando se apague almacenar cosas. ¿Y si la nueb local fuera esa Flas? No hemos hablado muchas veces que azure calcularia una vez y guardaría los datos para distribuirlos? ¿Y si se almacenan en esa flash y se usan después?

Son todo tiros al aire de una persona que no entiende, que quede claro.

Yo no se si entiendes o no. Pero siempre q t veo estas aportando información valiosa. Saber a ciencia cierta lo q lleva y como trabaja Xbox One lo saben muy pocas personas en el mundo, es hardware completamente nuevo, asi q lo máximo q podemos hacer es buscar datos e información y compartirlo. Solo nos queda el ensayo y error.

¿Que es exactamente un NOC? Yo jamas lo había oído hasta ayer.

El propio cerny dijo por su boca sistema balanceado 14+4,esto es recomendado no impuesto pero si el arquitecto principal recomienda 14 para graficos y 4 para gpgpu sera porque de lo contrario seria contraproducente,no?

Con lo que tenemos 1,41vs1,31 realmente,a nadie le extrańa que ningun desarroyador se queje de la supuesta inferioridad de la gpu de one respecto a ps4?,no sera por que son practicamente iguales?,de lo que se quejan es del ancho de banda(creo)

papatuelo escribió:Es que lo que dice FlasHBackMan360 tiene lógica, lo de Network on a Chip. NOC.

Si miras información se basa fundamentalmete en mejorar el flujo de información. Asumen que escalar potencia bruta es ahora mismo una via muerta y se centran en mejorar la comunicación entre lo diferentes componentes, en este caso CPU, GPU y los 15 copocesadores que ya han dicho que son como pequñas CPU. ¿Y si esos coprocesadores fueran rollo FPGA que pueden programarse en cada momento para que hagan lo que te salga del ciruelo? ¿Y si fueran lo que hicieran feura manejar datos a modo de routers para mejorar la eficiencia de la máquina?

Por otro todo lo que he leido de Network on a chip hace referencia al uso de la Sram y por otro lado hay una patente de microsoft para usar a la vez memoria flash y memoria DRam utilizando un pool de Sram que unifique el trabajo de ambas. ¿Y si la Flash se utiliza también para alimentar la SRam? Podría hacerlo y cuando se apague almacenar cosas. ¿Y si la nueb local fuera esa Flas? No hemos hablado muchas veces que azure calcularia una vez y guardaría los datos para distribuirlos? ¿Y si se almacenan en esa flash y se usan después?

Son todo tiros al aire de una persona que no entiende, que quede claro.

Es que aunque entendieras, Xbox One tiene un hardware personalizado que no se parece a ninguna otra cosa. Tiene similitudes, pero no las suficientes como para decir a ciencia cierta cómo funcionará y rendirá.

Aquí creo que todos somos conscientes que con los conocimientos que tiene cada uno y la información que va soltando Microsoft, elaboramos nuestras teorías.

Lo gracioso es ver cómo hay gente a la que le sienta fatal este hilo.

Tu lees semmicurate, extremme tech o cualquier web especializada y te dicen en sus articulos de xbox one que aún hay incognitas muy interesantes por entender. Y luego te viene cualquiera por aqui y te dice que todo lo que hablamos ya se sabe y que no hay nada mas...

Es que hay una cosa que se llama prudencia que no solemos observar demasiado cuando opinamos... y cuando alguien quiere mantener su credibilidad cuida mucho ese aspecto.

Todo esto de la logica dual o componentes duplicados me recuerda a los comentarios que salieron en su tiempo diciendo que la nueva consola era como tener 2 ordenadores uno al lado del otro

Entonces la idea original de ms cual era,tener 2 SO (apps/y juegos)al mismo tiempo sin que se interfirieran entre si uno al otro con harware funcionando exclusivamente para cada uno?

Otra cosa que me llamo mucho la atencion,nadie se acuerda que a la hora de iniciar una partida multijugador al halo 4 unos segundos antes salia un mensage diciendo "calculando iluminacion especial espero un momento" o algo asi?,estaria ya 343 tanteando el cloud computing?,por que el halo 4 tiene una iluminacion bestial

Ope escribió:Es que hay una cosa que se llama prudencia que no solemos observar demasiado cuando opinamos... y cuando alguien quiere mantener su credibilidad cuida mucho ese aspecto.

Credibilidad quien la tenga, no creo q un maestro de educacion primaria, q en cada mensaje advierte q no tiene ni idea, tenga la mas minima credibilidad.

Ope escribió:Es que hay una cosa que se llama prudencia que no solemos observar demasiado cuando opinamos... y cuando alguien quiere mantener su credibilidad cuida mucho ese aspecto.

+1

papatuelo escribió:

Ope escribió:Es que hay una cosa que se llama prudencia que no solemos observar demasiado cuando opinamos... y cuando alguien quiere mantener su credibilidad cuida mucho ese aspecto.

Credibilidad quien la tenga, no creo q un maestro de educacion primaria, q en cada mensaje advierte q no tiene ni idea, tenga la mas minima credibilidad.

Parto de la base de que una persona, medio, empresa, lo que sea gana credibilidad demostrando unos conocimientos, excelencia en el servicio, fiabilidad y transpariencia en la información dada, etc. a lo largo del tiempo. Por lo que lo que comentas es lógico.

Ahora bien, una vez se ha conseguido ganar esa credibilidad, cualquier paso en falso puede minarla. Y es mucho más fácil perderla que ganarla.
Por esto comentaba que en el caso de medios especializados serios u opiniones expertas y respetadas, es muy difícil ver que se hagan afirmaciones universales y absolutas sin tener una garantía de que lo que se dice es cierto y difícilmente refutable, y todo ello motivado por la prudencia, ya que es alto el riesgo de perder credibilidad, que al final es lo que te hace ser referencia dentro de un sector o área de conocimiento.

KinderRey escribió:Me encanta el olor a raytracing por la mañana

Se que se sale del topic y que habra quien se moleste por tu post ya que no aporta nada al tema del hilo, pero como fan de Apocalypse now he de decir que me ha hecho mucha gracia

Un saludo!

darksch escribió:Pues sí estás en lo cierto, pero ya se sabe que aquí no se puede comentar a "las otras"

Se sacaron de la manga a última hora un TrueAudio como que ya era igual o mejor que SHAPE, y lo que no dijeron (de forma directa o la gente no quiso entender) es que en realidad lo que tenían era las librerías TrueAudio implementadas, pero que quien lo hace correr es la CPU/GPU y no un chip dedicado, el cual lo único que hace es la des/compresión al vuelo (lo que ya se dijo que tenía al principio), pero la aplicación de efectos va a cargo de los componentes principales.

f5inet escribió:XboxONE lleva procesadores SHAPE basados en una solucion de Tensilica, que realizan todo el procesamiento de audio de forma dedicada y por separado.
PS4 dedica 4 de sus 18CUs a tareas de GPGPU, entre las cuales, esta la implementacion de TrueAudio de AMD.

de esta forma, XboxONE tiene 12CUs a 853mhz dedicados a graficos, rindiendo de forma teorica a 1,31TFs. Mientras que PS4 tiene 14CUs a 800Mhz dedicados a graficos, rindiendo de forma teorica a 1,4TFs.

Adicionalmente, XboxONE tiene eSRAM y DMEs que PS4 no tiene.

El problema lo tendra PS4 en cuanto se empiece a usar DX12 y se estandarize el Render Tiling en eSRAM. Antiguamente, en la eDRAM de X360, los programadores tenian que renderizar 'en dos pasos' (porque el framebuffer no cabia en los 10MB) sobre la eDRAM y luego copiar a RAM, ese proceso de copia, aunque muy rapido, dejaba ociosa la GPU, que no pdia hacer nada mas mientras ocurria la copia. En XboxONE, el proceso de copia de la eSRAM a la RAM lo haran los DME, pudiendo la GPU dedicarse a otra cosa.

Por eso siempre hemos dicho que, independientemente de segunda capa o sin segunda en el SoC, XboxONE y PS4 estan MUY PAREJAS.

Muchas gracias a los dos.

Efectivamente yo me quedé con esa idea al salir a la palestra lo del True Audio. Me chocaba que, dado el enfoque "audivisual" de la One, su chip de sonido no fuera tan especial.

No soy precisamente alguien que defienda la potencia de estas nuevas consolas pero está bien valorar lo bueno que tiene One, que algo tiene. Es como la noticia de Avalanche creo que salió hace un tiempo diciendo que One tenía justo el ancho de banda necesario para aprovechar sus ROPS, mientras que PS4, teniendo muchos más ROPS y más ancho de banda, era incapaz de aprovecharlos todos, quedándose en unos 23 si no recuerdo mal en vez de los 32 que tiene. One podía aprovechar los 16 que tiene. En ese sentido es bastante eficiente.

No obstante, yo no creo que estén tan parejas, parejas estaban PS3 y 360 por ejemplo. Aunque tampoco es un caso PS2 y Xbox como muchos se empeñan. No quiero desviar esto a PS4, no obstante.

mapla escribió:...
No obstante, yo no creo que estén tan parejas, parejas estaban PS3 y 360 por ejemplo. Aunque tampoco es un caso PS2 y Xbox como muchos se empeñan. No quiero desviar esto a PS4, no obstante.

A causa de multitud de trolleos y flameos ya no se puede hablar de la consola contraria en los subforos de Xbox One y PS4. Yo lo entiendo y lo acepto como un mal menor, pero echo en falta un sitio en EOL donde poder hacer comparativas técnicas entre máquinas.

Son igual de parejas o mas que la xbox360 vs ps3...nada que me quería sumas a las chorradas del día..

digo yo que habrá que esperar a que salgan juegos que aprovechen el100% de las consolas para ver cual a llega mas lejos en temas gráficos ....o también sois de los que piensan que es mas potente porque en la xbox no salen todo los juegos a 1080p,porque si es eso mejor no perder el tiempo entonces...

y si que hay un hilo para hablar de las 2 consolas y desahogarse y soltar lo que te apetezca...en multiplataforma lo encontraras..

David Ricardo escribió:

mapla escribió:...
No obstante, yo no creo que estén tan parejas, parejas estaban PS3 y 360 por ejemplo. Aunque tampoco es un caso PS2 y Xbox como muchos se empeñan. No quiero desviar esto a PS4, no obstante.

A causa de multitud de trolleos y flameos ya no se puede hablar de la consola contraria en los subforos de Xbox One y PS4. Yo lo entiendo y lo acepto como un mal menor, pero echo en falta un sitio en EOL donde poder hacer comparativas técnicas entre máquinas.

Creo que para ello tienes un Foro Multiplataforma en el que poder hablar, opinar y comparar cualquier plataforma, pero como ya he dicho es un "creo".

Si se ha llegado a este punto es por que los usuarios no saben medir correctamente sus palabras a la hora de comparar u opinar y todo debate/comparación siempre lleva al mal rollo etc..

Vamos a ceñirnos al tema del Hilo (Xbox One) y dejar el resto de plataformas.