Hablemos del interior de Xbox One

cercata escribió:

O sea, que el cambio de DX11 a DX12 es como lo que dice tu enlace a wikipedia, cambiar el nombre de las variables de tu código.

Y OpenGL ya hacía lo que hace DX12, y por eso chronos group va a sacar ahora Vulkan, y por eso les está costando tanto sacarlo.

Lo que hay que oir. Yo soy el primero que dice que con DX12 nos están vendiendo la moto, pero no se puede negar que es un avance, aunque nos quieran vender que es mas de lo que es.

No te niego que no es un avance, por fin han quitado todo el overhead. No me refiero que han cambiado el nombre de las varibles/funciones, si quieres eso podemos decir que DX12 es Mantle ya que según parece solo funciona bien en AMD, por ahora. De OpenGL y Vulkan, son dos cosas distintas, OpenGL puede hacer eso pero de otra forma (busca indirect draw, agrupar todos los objetos con las mismas propriedades y hacer una única llamada) y Vulkan viene a ser lo mismo que DX12, quitar overhead y permitir paralelismo.

darksch escribió:Por esas palabras supongo que no has leído nada de los enlaces. No es ningún tipo de Refactoring, cambia totalmente la forma en que se programa, y los recursos de que dispone el programador.

Visto así si, estoy de acuerdo contigo. Pero miralo de esta forma, no hay overhead y ahora permiten paralalismo (nueva funcionalidad), por lo tanto todo lo que hay hasta ahora se tiene que refactorizar/modificar/adaptar/etc para permitir esta nueva funcionalidad que es muy importante a día de hoy. Pero en ningún momento has modifica el resultado de tu código, los valores de salida son los mismos. No se si me explico, no lo veo como una cosa de 1:1

https://docs.unrealengine.com/latest/INT/Programming/Rendering/ShaderDevelopment/AsyncCompute/index.html

@papatuelo esa documentación es genérica de UE4.9 o es una versión para desarrolladores de ONE ?

Pq me parece raro que no ponga en que plataformas esta soportado, lo normal en los APIs es que por cada funcion te documente en que plataformas y desde que versiones se puede usar ...

cercata escribió:@papatuelo esa documentación es genérica de UE4.9 o es una versión para desarrolladores de ONE ?

Pq me parece raro que no ponga en que plataformas esta soportado, lo normal en los APIs es que por cada funcion te documente en que plataformas y desde que versiones se puede usar ...

Yo diría q es generica, pero incluirá las novedades solo, el async PC y PS4 lo soportan desde Unreal 3 vitaminado como minimo.

papatuelo escribió:Yo diría q es genérica, pero incluira las novedades solo, el async PC y PS4 lo soportan desde Unreal 3 vitaminado como minimo.

Eso he pensao yo, pero luego me he fijado que era una pagina de dentro, no las notas de la versión.

Por otro lado, el UE es lo bastante listo como para no copiar datos entre CPU y GPU en las plataformas que soportan hUMA ?

Ya sé que los Devs están ahora empezando a usar UE4,como quien dice, pero ya con esta 4.9 avanzada, creeis que van a sacar de aquí al 2017 el 5.0? Igual estan parcheando el 4, pero el motor para dx12 y vulkan vaya a ser el 5

Si nos fijamos sigue siendo DX11 puro y duro, ya que usa ID3D11XCompute... y habla "del hilo" (único) de renderizado.

Bajo DX11 está bien que ya se pueda usar, pero sigue sin tener la eficiencia que bajo DX12 bien usado. Recuerdo haber leído en la documentación de DX12 que en DX11 las operaciones asíncronas no se garantizan su ejecución en el momento en que uno lo esperaría, cosa normal dada la gestión completamente bajo tutela de la propia API de todo. Es decir tu puedes tener alguna CU libre, ejecutar en async, y sin embargo DX11 no ejecutarlo inmediatamente y que tarde un rato en pillarlo y meterlo en la cola. Bajo DX12 en el mismo momento en que lo llamaras se ejecutaría, siendo el programa responsable de la sincronización en lugar de hacerlo la API a su bola, eso sí, automáticamente.

A este paso, Microsot quizás empiece a sacar juegos Full DirectX 12 para finales del año que viene. Las thirds... por lo menos hasta 2017 o más. Hay muchos juegos en desarrollo desde hace un tiempo y muchos desarrolladores están muy cómodos con DirectX 11.

Según Eurogamer la arquitectura de Xbox One le da ventaja en el filtrado de texturas frente a ps4, en muchos juegos las texturas se ven mas definidas en PC y Xbox. Parece que tener dos niveles de memoria no es tan malo como se creía.

http://www.eurogamer.net/articles/digitalfoundry-2015-vs-texture-filtering-on-console

indigo_rs escribió:Según Eurogamer la arquitectura de Xbox One le da ventaja en el filtrado de texturas frente a ps4, en muchos juegos las texturas se ven mas definidas en PC y Xbox. Parece que tener dos niveles de memoria no es tan malo como se creía.

http://www.eurogamer.net/articles/digitalfoundry-2015-vs-texture-filtering-on-console

Me parece que no hemos sacado las mismas conclusiones tras leer el articulo...

Yo lo que he sacado en claro es que hay muchos factores que influyen en el tipo de filtrado de texturas aplicado en cada juego y plataforma, y no esta claro que haya un factor comun a todos ellos. De hecho la prueba que hacen con una APU no demuestra nada, ya que esta utiliza un pool de memoria compartido y aun asi experimenta un impacto minimo al utilizar AF 16x.

Un saludo!

Según dicen las consolas tienen limitaciones por eso tratan de bajar el filtrado a pesar de emborronar las texturas, sin embargo en muchos juegos de Xbox One consiguen mantenerlo alto y las texturas se siguen viendo definidas.

Salocin, tu te acuerdas de que web fue la que hablo de la GPGPU de PS4 y One, y le pusiste por Twitter que One tenia 16 stream works por ACE en vez de los 8, y editaron el articulo?

Es que la he buscado para leer una cosa y no hay manera.

Cyborg_Ninja escribió:Salocin, tu te acuerdas de que web fue la que hablo de la GPGPU de PS4 y One, y le pusiste por Twitter que One tenia 16 stream works por ACE en vez de los 8, y editaron el articulo?

Es que la he buscado para leer una cosa y no hay manera.

Eso no fue saloncin, fue papatuelin y la página era wccftech.

La conclusión tiene delito:

Armed with this information, we can safely say, that (Xbox One) gamers should not expect any significant performance upgrades (where significant is defined as the Xbox being able to run games at higher resolutions than now) with the arrival of the DirectX 12 update

http://wccftech.com/xbox-one-directx-12-asynchronous-compute-hardware-specifications-ps4-comparison/5/

Gracias, cierto, cierto, siempre os confundo, y vuestro nick no se parece en nada

indigo_rs escribió:Según Eurogamer la arquitectura de Xbox One le da ventaja en el filtrado de texturas frente a ps4, en muchos juegos las texturas se ven mas definidas en PC y Xbox. Parece que tener dos niveles de memoria no es tan malo como se creía.

http://www.eurogamer.net/articles/digitalfoundry-2015-vs-texture-filtering-on-console

Yo me lei el articulo y no saque nada en claro, exponen teorías, pero luego sacan ejemplos ellos mismos que demuestran que esas teorías no son del todo validas ...

Yo si he visto un par de cosas claras del artículo:

An investigation into Ubisoft's The Crew in 2013 revealed there's a degree of allocation here; the graphics component has its own, faster 176GB/s memory bus labeled Garlic, while the CPU's Onion has a peak of 20GB/s via its caches. Even so, there's a tug-of-war at play here - a balancing act depending on the game.

En XOne es de 68GB/s máximo si lo usara todo. Parece que la GDDR5 a través de un bus único compartido nos da los problemas de los que siempre hemos hablado de cara a la CPU.

"The amount of AF [anisotropic filtering] has a big impact on memory throughput," Thrush says. "On PCs, lots of memory bandwidth is usually available because it's fully isolated to the graphics card. On consoles with shared memory architecture, that isn't quite the case, but the benefits you get from having shared memory architecture far outweigh the drawbacks."

Algo que habré dicho mil veces, y todo el mundo siempre respondiendo "si eso no cuesta nada".

Tampoco se ha comentado con qué pasa si usamos la eSRAM para almacenar las texturas a través de tiled resources, la multi-muestra del AF ya no parecería tan pesada, ¿verdad?, y lo que es mejor, de acceso simultáneo a la DDR3. Para algo tan específico seguramente hará falta el uso de DX12 y su posibilidad de gestión a bajo nivel, porque dudo mucho que DX11 lo haga por ti.

Ya os lo puse otra vez pero os lo pongo de nuevo porque quiza este relacionado con el tema. Esta es la patente del sistema de memorías de XBOX ONE.

PARALLEL MEMORIES FOR MULTIDIMENSIONAL DATA ACCESS

https://patentimages.storage.googleapis.com/pdfs/US20140310496.pdf

Hola, aquí saloncituelo xD

El tema no es tanto si usar uno o varios pools, si no que soportan los mismos, en el caso de xbox hay soporte para HuMa y lo que va a venir después (HSA) y eso ahorra muchísimo BW permitiendo meter otras cosas como el AF.

En PC no hay soporte para HuMa (sólo en apus) pero tener dos bancos de memoria separados también evita en gran medida el problema, además de contar normalmente con caches generosas en la CPU. En este caso la peor parte se la lleva la marca japonesa que tiene que usar un bus unificado sobre una memoria que no tiene este soporte para Huma, y al que desafortunadamente le ha recortado casi toda la caché, supongo que por recortar costes de producción, lo que hace que hay que recortar ancho de banda en otras cosas, y más si por temas propagandístico tiene un framebuffer a 1080 aunque la máquina no pueda manejarlo con soltura.

salocin21 escribió:Hola, aquí saloncituelo xD

El tema no es tanto si usar uno o varios pools, si no que soportan los mismos, en el caso de xbox hay soporte para HuMa y lo que va a venir después (HSA) y eso ahorra muchísimo BW permitiendo meter otras cosas como el AF.

En PC no hay soporte para HuMa (sólo en apus) pero tener dos bancos de memoria separados también evita en gran medida el problema, además de contar normalmente con caches generosas en la CPU. En este caso la peor parte se la lleva la marca japonesa que tiene que usar un bus unificado sobre una memoria que no tiene este soporte para Huma, y al que desafortunadamente le ha recortado casi toda la caché, supongo que por recortar costes de producción, lo que hace que hay que recortar ancho de banda en otras cosas, y más si por temas propagandístico tiene un framebuffer a 1080 aunque la máquina no pueda manejarlo con soltura.

Ahora que hablas de los bancos de ram en las APUs, una apu con 8gb en un solo banco rinde la mitad que la misma apu con los mismos 8 gb pero en dual channel.

Pero ambas consolas tienen las memorias dispuestas en más de un banco ¿no?

papatuelo escribió:

salocin21 escribió:Hola, aquí saloncituelo xD

El tema no es tanto si usar uno o varios pools, si no que soportan los mismos, en el caso de xbox hay soporte para HuMa y lo que va a venir después (HSA) y eso ahorra muchísimo BW permitiendo meter otras cosas como el AF.

En PC no hay soporte para HuMa (sólo en apus) pero tener dos bancos de memoria separados también evita en gran medida el problema, además de contar normalmente con caches generosas en la CPU. En este caso la peor parte se la lleva la marca japonesa que tiene que usar un bus unificado sobre una memoria que no tiene este soporte para Huma, y al que desafortunadamente le ha recortado casi toda la caché, supongo que por recortar costes de producción, lo que hace que hay que recortar ancho de banda en otras cosas, y más si por temas propagandístico tiene un framebuffer a 1080 aunque la máquina no pueda manejarlo con soltura.

Ahora que hablas de los bancos de ram en las APUs, una apu con 8gb en un solo banco rinde la mitad que la misma apu con los mismos 8 gb pero en dual channel.

Pero ambas consolas tienen las memorias dispuestas en más de un banco ¿no?

Dices a nivel físico o a nivel lógico?

Ambas tienen la memoria principal distribuida en más de un chip, pero a nivel lógico One soporta un acceso compartido a los mismos datos desde CPU y GPU, en la consola japonesa, hay áreas para los datos de la GPU y áreas para los datos de la CPU. (Que es el soporte HuMa, que decía antes)

Si tienes HuMa puedes acceder a los mismos datos desde GPU y CPU y no necesitas moverlos, lo que no es gratis, si no tienes soporte para pasar un dato necesitas moverlo, ya que aunque el pool fuera físicamente el mismo, no lo es a nivel lógico.

salocin21 escribió:

papatuelo escribió:

salocin21 escribió:Hola, aquí saloncituelo xD

El tema no es tanto si usar uno o varios pools, si no que soportan los mismos, en el caso de xbox hay soporte para HuMa y lo que va a venir después (HSA) y eso ahorra muchísimo BW permitiendo meter otras cosas como el AF.

En PC no hay soporte para HuMa (sólo en apus) pero tener dos bancos de memoria separados también evita en gran medida el problema, además de contar normalmente con caches generosas en la CPU. En este caso la peor parte se la lleva la marca japonesa que tiene que usar un bus unificado sobre una memoria que no tiene este soporte para Huma, y al que desafortunadamente le ha recortado casi toda la caché, supongo que por recortar costes de producción, lo que hace que hay que recortar ancho de banda en otras cosas, y más si por temas propagandístico tiene un framebuffer a 1080 aunque la máquina no pueda manejarlo con soltura.

Ahora que hablas de los bancos de ram en las APUs, una apu con 8gb en un solo banco rinde la mitad que la misma apu con los mismos 8 gb pero en dual channel.

Pero ambas consolas tienen las memorias dispuestas en más de un banco ¿no?

Dices a nivel físico o a nivel lógico?

Ambas tienen la memoria principal distribuida en más de un chip, pero a nivel lógico One soporta un acceso compartido a los mismos datos desde CPU y GPU, en la consola japonesa, hay áreas para los datos de la GPU y áreas para los datos de la CPU. (Que es el soporte HuMa, que decía antes)

Si tienes HuMa puedes acceder a los mismos datos desde GPU y CPU y no necesitas moverlos, lo que no es gratis, si no tienes soporte para pasar un dato necesitas moverlo, ya que aunque el pool fuera físicamente el mismo, no lo es a nivel lógico.

Ni idea de si digo a nivel lógico o físico.

Digo que en un PC la APu puede acceder simultaneamente a los dos bancos cuando la ram está en dual channel. Supongo que en consolas ocurre lo mismo que simultanemente se puede acceder a más de un banco.

Me suena que la one va a quad channel no?

Y bueno, en pc puedes tener cuatro bancos llenos e ir a single channel, ya que lo que importa es como repartes las direcciones. Al usar dual/triple/quad channel repartes las contiguas direcciones en distintos bancos, aumentando el bw en uso secuencial

Zokormazo escribió:Me suena que la one va a quad channel no?

Y bueno, en pc puedes tener cuatro bancos llenos e ir a single channel, ya que lo que importa es como repartes las direcciones. Al usar dual/triple/quad channel repartes las contiguas direcciones en distintos bancos, aumentando el bw en uso secuencial

Lo del dual, tri, etc lo sé, pero sé por experiencia propia que las apus en dual chanel rinden el doble.

Ya no sé si habrá diferencia entre dual chanel y quad.

Y creo que sí, que One tien quad.

Obviamenre hay diferencia. En quad channel tienes cuatro canales de comunicacion a la memoria, cada una a un banco, en vez de 2, doblando la tasa teorica maxima.

Vamos, teoricamente tienes exactamente la misma diferencia que entre single y double

EDIT:

Eso en cuanto a comunicacion entre pastillas y controlador de memoria. Si en la practica rendira el doble dependera de si tienes cuello en algun otro punto que no permita al controlador de memoria usar todo el ancho disponible.

En un sistema cerrado como una consola... para que añadirias 4 canales en memoria si el cuello en otro punto no te deja aprovecharlos?

Seria algo estupido montarlos si no habra diferencia notoria

Me refiero precisamente a eso, hasta donde yo se a efectos prácticos en un PC con CPU y GPU discreta no notas diferencia entre single y dual a la hora de jugar.

Con una APU pasas un benchmark y sacas el doble de puntuación.

Zokormazo escribió:Y bueno, en pc puedes tener cuatro bancos llenos e ir a single channel, ya que lo que importa es como repartes las direcciones. Al usar dual/triple/quad channel repartes las contiguas direcciones en distintos bancos, aumentando el bw en uso secuencial

No tengo ni idea, pero lo lógico sería hacerlo así, y también mejoraría en acceso aleatorio en la mayor parte de los casos. Eso para CPUs.

Pero a nivel de APUs, tiene sentido de que hagas algo asimétrico, ya que la GPU necesita mas ancho de banda que la CPU, y que por ejemplo 2 de 4 canales sean de uso exclusivo de la GPU.

Tranquilos que el controlador de memoria sabe como hacerlo. Lo lógico sería en plan RAID-0 tal y como se ha sugerido. Si nos fijamos sólo habría conflicto en caso de que ambos procesadores quisieran acceder al mismo banco a la vez, por ejemplo empezar a leer el 1er dato de una secuencia al mismo tiempo. Eso no es mucho problema, simplemente uno se espera 1 ciclo y al siguiente ya puede empezar a acceder en quad channel con sólo 1 paso de desfase respecto al que se dejó pasar antes.

Per PS4 soporta nUMA, tiene dos buses ONiON de 10Gbs si no recuerdo mal.

Horizonte de sucesos escribió:Per PS4 soporta nUMA, tiene dos buses ONiON de 10Gbs si no recuerdo mal.

Eso es correcto. No lo mencioné porque se supone que no es el hilo, pero es así.

¿Que diferencias hay entre nUMA y hUMA?

papatuelo escribió:¿Que diferencias hay entre nUMA y hUMA?

Simple fallo de escritura
El nombre es lo de menos al final es coherencia de datos y ya está.

Aún así no es lo mismo coherencia de datos, destinado a compartir, que memoria unificada, aunque una incluya a la otra. La memoria unificada destinada a varios dispositivos consiste en un único pool de cierto tamaño a distribuir entre dispositivos que accedan a conveniencia, frente a varias pool de memoria separadas de tamaños fijos.

Por lo general cuando se crean, a partir de este pool único, los distintos pool de datos de cada dispositivo, son separados y no pueden accederse desde un dispositivo al pool creado para otro. Fijaos que si se creara todo el pool en plan compartido, se tendría un ancho muy inferior al que podría dar, ya que el ancho de la tecnología hUMA (o similares) es muy inferior a un acceso directo. Cosa normal por sus requisitos y funcionalidad, y aún así para su propósito (computación y ejecución de código compartida) es más que suficiente.

Así por ejemplo si creo un pool de 2GB para la GPU (VRAM), la CPU no podrá acceder a ésta directamente, lo haría a través del bus de turno (el bus gráfico en este caso). La ventaja de la memoria unificada es poder repartir para cada aplicación según convenga, y no estar atados de antemano a un reparto fijo. Además el reparto puede hacerse de forma dinámica.

darksch escribió:

papatuelo escribió:¿Que diferencias hay entre nUMA y hUMA?

Simple fallo de escritura
El nombre es lo de menos al final es coherencia de datos y ya está.

Pues casualidad que NUMA tambien existe, y lo soportan los X86, esto es parte de lo que sale en mi PC si ejecuto coreinfo:

Logical Processor to NUMA Node Map:
**** NUMA Node 0

No NUMA nodes.

https://es.wikipedia.org/wiki/NUMA

Que yo sepa se usa cuando hay mas un procesador X86 en un ordenador, aunque podría ser interesante de cara a las APU's, no ?

En los multinúcleo imagino que será la norma que implementen NUMA, si no el acceso a RAM sería bastante más lento y se perdería gracia en tener varios núcleos. Pero no coincide con lo que se está tratando en este caso.

cercata escribió:

Zokormazo escribió:Y bueno, en pc puedes tener cuatro bancos llenos e ir a single channel, ya que lo que importa es como repartes las direcciones. Al usar dual/triple/quad channel repartes las contiguas direcciones en distintos bancos, aumentando el bw en uso secuencial

No tengo ni idea, pero lo lógico sería hacerlo así, y también mejoraría en acceso aleatorio en la mayor parte de los casos. Eso para CPUs.

Pero a nivel de APUs, tiene sentido de que hagas algo asimétrico, ya que la GPU necesita mas ancho de banda que la CPU, y que por ejemplo 2 de 4 canales sean de uso exclusivo de la GPU.

Estoy al movil y cuesta horrores explayarse. La explicacion esa no es del todo completa.

En single channel tienes un unico canal de comunicacion con todas las pastillas, asi que da igual como repartas las direcciones.

En dual/tri/quad channel tienes 2/3/4 canales distintos de comunicacion entre controlador y pastillas, conectada cada una a un(os) bancos, y aqui si que es importante distribuir las direcciones entre ellas para comunicarse concurrentemente y aumentar la tasa total

cercata escribió:

darksch escribió:

papatuelo escribió:¿Que diferencias hay entre nUMA y hUMA?

Simple fallo de escritura
El nombre es lo de menos al final es coherencia de datos y ya está.

Pues casualidad que NUMA tambien existe, y lo soportan los X86, esto es parte de lo que sale en mi PC si ejecuto coreinfo:

Logical Processor to NUMA Node Map:
**** NUMA Node 0

No NUMA nodes.

https://es.wikipedia.org/wiki/NUMA

Que yo sepa se usa cuando hay mas un procesador X86 en un ordenador, aunque podría ser interesante de cara a las APU's, no ?

Los PCs han sido clasicamente UMA (Uniform Memory Access - acceso a memoria unificado), donde los ComputeCores tenian acceso por igual al mismo pozo de RAM (traduzco pool por pozo en lugar de piscina, que me parece una traduccion mas 'cercana') y podian compartir datos, punteros e incluso pisarse en los accesos a RAM (la gestion de las colisiones ya es algo propio del sistema operativo, algunos los permiten y otros levantan excepciones que deben ser tratadas). Por supuesto, esto no es aplicable de hace unos 5 años para aca...

una arquitectura NUMA (Non Uniform Memory Access - Acceso a memoria NO unificado) es una arquitectura en la cual los ComputeCores (los nucleos que ejecutan codigo) no tienen un acceso unificado al mismo pozo de RAM. Un ejemplo clasico de arquitectura NUMA exitosa es PS3-CELL, en la que los SPE tienen una pequeña memoria local y si querian acceder a la RAM principal debian programar una transferencia DMA desde y/o hasta la RAM principal.

desde el momento que las GPU ejecutan codigo (GPGPU y/o OpenCL), tambien se interpreta que la arquitectura es NUMA, en la cual hay dos pozos de memoria, la VRAM y la RAM normal, y deben programarse transferencias de datos entre una y otra.

Y finalmente, llegamos a HUMA (Heterogeneus Uniform Memory Access - acceso a memoria uniforme heterogeneo), donde, a pesar que aun existen pools 'separados' de VRAM y RAM, se mapean dentro del mismo espacio de direcciones virtual, y un CPU-Core es capaz de acceder directamente al pozo VRAM y un GPU-Core es capaz de acceder directamente al pozo RAM sin necesidad de programar transferencias de RAM previas a su propio pozo.

Obviamente, el ancho de banda 'hacia un pozo ajeno' no tiene porque ser igual al de 'tu propio pozo'. de hecho, los anchos de banda a 'pozos ajenos' suele ser bastante inferior en las primeras arquitecturas HUMA, ya que cada acceso debe notificar al MMU (Memory Management Unit) de los Cores dueños del pozo que se va a acceder, que esa zona de su pozo esta siendo accedida a traves del bus HUMA (Onion+ en caso de arquitecturas Kaveri AMD, como por ejemplo, PS4).

Esto se resuelve con FULL-HSA 1.0 (que implementa HUMA+ como requisito para la certificacion), como por ejemplo, AMD CARRIZO

Que por cierto, ya casi es el momento de hablar de HSA... y si, XboxONE es FULL HSA 1.0.

Gracias por la explicación @f5inet, muy buena.

Y como soluciona HUMA+ el problema ? A mi la única solución que se me ocurre es que tener 3 pozos, uno para la CPU, otro para la GPU, y otro HUMA para las 2. De hecho la ESRAM de ONE es un poco eso que digo, sólo que sin el pozo de la CPU.

cercata escribió:Gracias por la explicación @f5inet, muy buena.

Y como soluciona HUMA+ el problema ? A mi la única solución que se me ocurre es que tener 3 pozos, uno para la CPU, otro para la GPU, y otro HUMA para las 2. De hecho la ESRAM de ONE es un poco eso que digo, sólo que sin el pozo de la CPU.

Vale, simplemente por ilustrar el concepto, vamos a coger el esquema de acceso a RAM de 'Liverpool', que es la APU de PS4, para explicar que es HUMA:


Con HUMA, cada tipo de ComputeCores tiene su bus de acceso a RAM y su MMU. Si acceden a RAM de la cual ellos son dueños, no hay problema, acceden a maxima velocidad de su bus (176GB/s mediante Garlic y 20GB/s del bus de CPU), sin embargo, si quieren acceder a RAM de la cual no son dueños, deben acceder a traves del bus de dueño de esa parte de RAM. si el trayecto es CPU->GPU->RAM no hay problema, porque la CPU no va a saturar Garlic ni mucho menos, pero si el trayecto es GPU->CPU->RAM a traves de Onion/Onion+, se produce un cuello de botella porque el ancho de banda de Onion/Onion+ es de solo 10GB*2, en lugar de los 176GB/s de pico teorico que tiene Garlic, ademas, que usar Onion satura el Bus de la CPU, que ya va un poco justita en esa arquitectura (y es por eso que insisten tanto en la particion 14+4 de los CUs de PS4, pero eso se sale del presente topico).

Con HUMA+, accedes a traves de tu propio bus. en el caso hipotetico de un 'liverpool' que fuese HUMA+, no tendriamos los buses Onion, y en su lugar, tendriamos un simple canal que intercomunica directamente las MMUs de la GPU y la CPU. Mediante este canal, se notifica a la MMU vecina que dicha porcion de RAM de la cual es actualmente dueña, va a ser accedida mediante otro canal, y que por tanto, debe vaciar los bufferes pendientes de escritura que tenga sobre ella, bloquear los accesos a dicha porcion de RAM, y debe notificar en caso que desee volver a usar dicha porcion. La MMU que recibe el mensaje, realiza el trabajo y permite a la MMU solicitante acceder a la RAM. la MMU solicitante accede a la porcion de RAM mediante su propio bus, a velocidad completa. Si la MMU que tenia originalmente dicha porcion de RAM necesita volver a usarla, lanzara una excepcion a la otra MMU y la otra MMU liberara inmediatamente la RAM solicitada (de nuevo, despues de vaciar los bufferes pendientes de escritura y tal).

¿Tiene XboxONE este canal para intercomunicar ambas MMU?

pues resulta que si...

para que esto sea operativo y el rendimiento no se resienta (por una tormenta de solicitudes y re-solicitudes entre ambas MMU que quieren acceder simultaneamente), es importante que la GPU (que es la que mas se resiente) soporte GRAPHICS PREEMPTION y multiples COLAS DE EJECUCION SIMULTANEAS a traves de diferentes COLAS.

¿tiene XboxONE estas cosas tambien? creo que en las ultimas 100 paginas se hablaba de algo asi...

Ya casi es el momento, pero aun no... aun hay que esperar un poco mas para empezar a hablar de HSA.

Muy interesante @f5inet ...

Pues esto puede ser la razón de que pq el Filtrado Anisotropico les cuesta mas hacerlo en PS4, que el articulo ese muy tocho, pero se olvidaron esto, que parece muy importante. La APU de PC con la que hicieron la prueba, tiene HUMA o HUMA+ ?

cercata escribió:Muy interesante @f5inet ...

Pues esto puede ser la razón de que pq el Filtrado Anisotropico les cuesta mas hacerlo en PS4, que el articulo ese muy tocho, pero se olvidaron esto, que parece muy importante. La APU de PC con la que hicieron la prueba, tiene HUMA o HUMA+ ?

No, el AF no depende de hUMA, ya que es completamente tarea GPU. En este caso el problema es el bus compartido que no deja suficiente ancho, si lo usas en otras cosas, para hacer las multi-muestras.
Además vemos que siguen haciendo falta las pool de memoria separadas, ya que el ancho del común sigue siendo muy inferior al exclusivo. En caso de la otra es de 20GB/s frente a los 175GB/s de pico exclusivo (a repartir), en caso de la más equilibrada, la XOne, es de unos 30GB/s frente a los 68GB/s del bus original.
Además "ensucia" las cachés de la CPU L1 y L2, por lo que queda claro que es para datos que vaya a usar la CPU a los que quiera tener acceso también la GPU, que no merece usarlo para "cualquier dato".

darksch escribió:

cercata escribió:Muy interesante @f5inet ...

Pues esto puede ser la razón de que pq el Filtrado Anisotropico les cuesta mas hacerlo en PS4, que el articulo ese muy tocho, pero se olvidaron esto, que parece muy importante. La APU de PC con la que hicieron la prueba, tiene HUMA o HUMA+ ?

No, el AF no depende de hUMA, ya que es completamente tarea GPU. En este caso el problema es el bus compartido que no deja suficiente ancho, si lo usas en otras cosas, para hacer las multi-muestras.
Además vemos que siguen haciendo falta las pool de memoria separadas, ya que el ancho del común sigue siendo muy inferior al exclusivo. En caso de la otra es de 20GB/s frente a los 175GB/s de pico exclusivo (a repartir), en caso de la más equilibrada, la XOne, es de unos 30GB/s frente a los 68GB/s del bus original.
Además "ensucia" las cachés de la CPU L1 y L2, por lo que queda claro que es para datos que vaya a usar la CPU a los que quiera tener acceso también la GPU, que no merece usarlo para "cualquier dato".

Mejor evitemos seguir hablando de PS4. no es el lugar. Simplemente puse el esquema de Liverpool como ejemplo de una arquitectura HUMA, que ya es un avance enorme sobre los NUMA que son actualmente los PCs. (o HUMA, en caso de PCs basados en Kaveri o superior)

Estoy bastante preocupado, los juegos que siguen saliendo son DX11, incluidos exclusivos. Si la consola fue diseñada para DX12 estamos perdiendo el tiempo y parece que no están dispuestos a cambiar, por lo menos a corto-medio plazo.

DX12 requiere un controlador grafico WDDM 2.0 que viene con Windows 10. Xbox ONE no tiene 'aun' Windows 10, luego aun no dispone del controlador grafico, luego aun no soporta DX12.

f5inet escribió:DX12 requiere un controlador grafico WDDM 2.0 que viene con Windows 10. Xbox ONE no tiene 'aun' Windows 10, luego aun no dispone del controlador grafico, luego aun no soporta DX12.

¿No iba el SO incluido en el juego?

malosoxxx escribió:

f5inet escribió:DX12 requiere un controlador grafico WDDM 2.0 que viene con Windows 10. Xbox ONE no tiene 'aun' Windows 10, luego aun no dispone del controlador grafico, luego aun no soporta DX12.

¿No iba el SO incluido en el juego?

Pues depende, cuando interesa el OS del fuego va incluido en el juego,y cuando no interesa pues hay que esperar....... lo que sea, con tal de no perder la esperanza, lo bueno es que los juegos siguen hablando, no?

f5inet escribió:DX12 requiere un controlador grafico WDDM 2.0 que viene con Windows 10. Xbox ONE no tiene 'aun' Windows 10, luego aun no dispone del controlador grafico, luego aun no soporta DX12.

Joder macho, eres un pozo de sabiduría!!!

malosoxxx escribió:

f5inet escribió:DX12 requiere un controlador grafico WDDM 2.0 que viene con Windows 10. Xbox ONE no tiene 'aun' Windows 10, luego aun no dispone del controlador grafico, luego aun no soporta DX12.

¿No iba el SO incluido en el juego?

Si, y Windows 10 para XboxONE aun esta en beta, y un juego no va a salir al mercado con un SO/SDK en beta.

@morepawer no se si estas de cachondeo o lo dices en serio, pero por si acaso...


¿y quien carajos es el tal Johan Anderson?
https://twitter.com/repi?ref_src=twsrc%5Etfw
El director tecnico del motor Frostbite de EA

chris76 escribió:

malosoxxx escribió:

f5inet escribió:DX12 requiere un controlador grafico WDDM 2.0 que viene con Windows 10. Xbox ONE no tiene 'aun' Windows 10, luego aun no dispone del controlador grafico, luego aun no soporta DX12.

¿No iba el SO incluido en el juego?

Pues depende, cuando interesa el OS del fuego va incluido en el juego,y cuando no interesa pues hay que esperar....... lo que sea, con tal de no perder la esperanza, lo bueno es que los juegos siguen hablando, no?

Yo no pierdo la esperanza, lo mismo tiene una Dreamcast dentro y es el nucleo Skynet.

Eso si, se ve que la consola salió verde de cojones en lo que respecta al software.

Edito: aclarar q no la cambio por las alternativas ni de coña. Ya se verá en 2016 si eso.

Algunos estudios seguro que tienen acceso a DX12 desde hace bastante,yo apostaría por Turn 10.

Pero el desarrollo de un juego es un ciclo largo, por lo menos 3 años, y cuando ya estas al final del ciclo, es muy arriesgado cambiar ciertas cosas ...

El paso a DX12 requiere de la rescritura completa de la parte gráfica del motor. Finales del 2016 me parece correcto para adaptar motores. Para motores nuevos incluso más allá sería lo normal.

Pasito a pasito se hace el caminito.

Mirad por ejemplo los shaders asincronos que no se habían usado nunca y ya los tenéis en el tomb raider, el resultado es espectacular:


O el computo en la nube de Crackdown 3:



Pues imaginad cuando hagan uso completo de todas la carácteríticas en un solo juego.