Hablemos del interior de Xbox One

Urian escribió:¿Por qué mientes tanto?

Urian escribió:

Szasz escribió:¿Entonces si yo juego en modo ventana en mi PC y pongo el internet explorer en modo Snap, estoy usando 2 CPs?

¿Por que el GPU MMU tiene 16 espacios virtuales?
¿Por que ha modificado Microsoft los ACEs y los ha cambiado por CPs con al menos el doble de work streams?
¿Por que pone en el paper q no es definitivo y q puede haber cambios más adelante?
¿Para q un Shape y diferentes modificaciones en I+D en puntos "sensibles" de la arquitectura?
¿Sistema virtualizado?
¿Por que tengo tantas dudas en tantas partes, cuando todo esta tan claro?

¿Todo para kinect y snap mode? Me resulta tan difícil de creer....

¿Por qué mientes tanto?

serrano_22 escribió:Esto se está convirtiendo en una discusión de besugos. No creo que haya más solución. El hilo finalmente se cerrará. No logro entender tanto interés en desacreditarlo todo.

Es una verdadera pena, porque aunque no me entero de muchas cosas, me gustaba ver como muchos compañeros lanzaban sus teorías, fueran o no descabelladas. Al fin y al cabo de eso se trata no? de pasar ratos agradables viendo cosillas de lo que lleva xbox one por dentro. De si podrá hacer esto o lo otro.

Y lo siento pero, aunque la culpa es de ambos bandos, no me entra en al cabeza poner tantisimo empeño en enturbiar ciertas opiniones, sean pajas mentales o no lo sean.

Saludos para todos, por favor moderar vuestro comentarios, si no preveo un cierre FINAL del hilo. Al tiempo

darksch escribió:No, os pongáis como os pongáis un CP no está exclusivamente dedicado al sistema. Sería absurdo dedicar la mitad de los recursos a algo que necesita un 10%. El 2o puede cambiar perfectamente entre juego y sistema, y de hecho es lo que hace. La otra unidad de geometría supongo que también estará dedicada al sistema...venga no os flipéis.

Si el reparto fuera 50/50 pues si lo más natural sería eso. Pero es 90/10 por lo que el 2o lo que hace es cambiar de contexto entre sistema y juego. Por lo que en teoría es tener 1,80 CP para el juego, en la practica algo menos por esos cambios que tiene que hacer la 2a, pero en la practica todo es siempre menos que en la teoría.

Pero si además lo dice la propia entrevista que se ha puesto hace nada, la parte final, donde dice claramente lo de rellenar huecos y hacer 2 cosas a la vez en el tiempo que el sistema no lo necesita, dedicarlo a la aplicación high. No entiendo la necesidad de negar algo que tenéis delante mismo.

The current reservation provides strong isolation between the title and the system and simplifies game development (strong isolation means that the system workloads, which are variable, won't perturb the performance of the game rendering). In the future, we plan to open up more options to developers to access this GPU reservation time while maintaining full system functionality.

To facilitate this, in addition to asynchronous compute queues, the Xbox One hardware supports two concurrent render pipes.

pspskulls escribió:Bueno, dado el despropósito al que se está llegando en este hilo voy a explicar lo que significa el PDF famoso.

Primero unas preguntas y respuestas rápidas importantes para entender la explicación:
- ¿Tiene Xbox ONE doble GPU?: NO.
- ¿Reserva ONE CPs o CUs para el sistema?: NO.
- ¿Podemos tener una GPU que admita multihilo sin tener doble contexto gráfico?: SI. Podemos tener 2 CP pidiendo tareas a la GPU y la GPU irá realizando las tareas pero no simultáneamente (por ejemplo pensad en un núcleo de CPU de 2 hilos, lo que ejecutan no es simultáneo sino que los hilos cogen la capacidad de proceso según el otro hilo ya no lo necesita). Para que una GPU realice dos tareas GRÁFICAS en paralelo DEBE tener 2 contextos gráficos (no podemos pintar en un lienzo en dos puntos al mismo tiempo si no tenemos dos pinceles). Resalto gráficas porque una GPU puede realizar GPGPU al mismo tiempo que renderiza.

Aquí habláis desde la teoría pero no desde la práctica., y es por eso que no se entiende el porqué de la estructura de One. Para entender la tecnología hay que entender el rendering, el porqué y el cómo se hacen las distintas técnicas actuales y futuras. El factor determinante es el doble contexto gráfico. Ésto es MUY importante, la clave es la palabra "gráfico".

Un ejemplo muy sencillo de renderizado de sombras seria: CPU prepara y pide crear una sombra de un objeto, la GPU entra en juego y la genera. Y así sucesivamente por cada sombra. Hay que tener una cosa MUY clara, renderizar una sombra no necesita PARA NADA los 12 CUs de la consola, ni por tener 12 o 18 va a renderizarla más rápido, una sombra necesita una capacidad de cómputo determinada y que posiblemente con 1 única CU nos bastaría. El problema es que cuando se renderiza se OCUPA la GPU, por lo tanto aunque no necesitemos los 12 CUs, los 12 CUs se van a bloquear para poder pintar la sombra. Obviamente podemos distribuir los CUs, y decir que sólo queremos usar un máximo de CUs para renderizado, y el resto para GPGPU (y aprovechar así el tiempo de renderizado para sacar cómputo). Pero a la hora de renderizar y para los CUs asignados a renderizar TODOS quedan bloqueados.

A partir de aquí C es CPU y G es GPU. Si queremos generar 4 sombras tenemos:
C > G > C > G > C > G > C > G

¿Qué sucede en One?. Que al tener 2 contextos gráficos puede renderizar 2 sombras al mismo tiempo. Con lo que nos queda:

> G > G
C > C
> G > G

Esto es, ni más ni menos, que la mitad del tiempo. ¿Estamos duplicando en este caso el rendimiento gráfico de One?: SÍ. ¿Es One más potente por ello?: NO. La capacidad de cómputo de One es la misma solo que el rendimiento es el doble.

Otro ejemplo seria un engine gráfico basado en tiled forward (http://www.cse.chalmers.se/~olaolss/main_frame.php?contents=publication&id=tiled_shading). Esta implementación se basa en generar el frame final a base de tiles o porciones de pantalla pequeñas (pequeños rectángulos). A parte de las características negativas y positivas de ésta técnica (toda técnica tiene su lado bueno y su lado malo), a dónde quiero ir a parar es en el hecho en el que... teniendo 2 contextos gráficos simultáneos podemos dibujar 2 de esas porciones SIMULTÁNEAMENTE. Con lo que el resultado es que obtenemos el frame en la mitad del tiempo y por tanto doblamos el rendimiento. Aquí también quiero hacer incapié en otra característica única de One: su eSRAM. Dado que esta técnica no requiere de gran ancho de banda, lo que más le beneficia es una memoria RÁPIDA, es decir de bajísima latencia (no confundir RAPIDEZ con ANCHO DE BANDA, no tienen NADA que ver, la rapidez la determina el tiempo para que la memoria vuelva a estar disponible para una nueva petición y ahí importa la latencia, el ancho de banda sólo sirve para MOVER grandes cantidades de memoria de un punto A a un punto B). Quiero decir con esto que de aplicar esta técnica en ambas consolas, One ganaría por absoluta goleada. Pero si aplicamos técnicas más antiguas como un deferred engine PS4 tiene ventaja por su ancho de banda (y de aquí vienen las diferencias en multis hasta ahora en cuanto a resolución o framerate).

A todo esto hay que añadirle que One tiene Full HSA, es decir coherencia total de memoria, algo básico si tenemos más de un contexto gráfico y además GPGPU, porque sí, One puede renderizar dos cosas y hacer GPGPU AL MISMO TIEMPO y compartiendo la MISMA memoria. Y esto es MUY potente y da una serie de posibilidades únicas.

¿Bien... significa todo esto que One doblará su rendimiento?: NO. One doblará su rendimiento GRÁFICO en múltiples tareas gráficas pero el rendimiento GLOBAL de un juego no SÓLO depende de la GPU. Hay muchos otros factores: CPU, memoria, técnicas gráficas utilizadas...

Ahora bien, si a mi se me pregunta: ¿Cuánto crees en promedio que mejorará el rendimiento de One?. Sinceramente y, bajo MI opinión, One incrementará con DX12 el rendimiento entre un 50 a un 75%.

Sorry por el tocho y espero haber dejado bastantes cosas claras.

To facilitate this, in addition to asynchronous compute queues, the Xbox One hardware supports two concurrent render pipes.

amovilar escribió:

pspskulls escribió:Bueno, dado el despropósito al que se está llegando en este hilo voy a explicar lo que significa el PDF famoso.

Primero unas preguntas y respuestas rápidas importantes para entender la explicación:
- ¿Tiene Xbox ONE doble GPU?: NO.
- ¿Reserva ONE CPs o CUs para el sistema?: NO.
- ¿Podemos tener una GPU que admita multihilo sin tener doble contexto gráfico?: SI. Podemos tener 2 CP pidiendo tareas a la GPU y la GPU irá realizando las tareas pero no simultáneamente (por ejemplo pensad en un núcleo de CPU de 2 hilos, lo que ejecutan no es simultáneo sino que los hilos cogen la capacidad de proceso según el otro hilo ya no lo necesita). Para que una GPU realice dos tareas GRÁFICAS en paralelo DEBE tener 2 contextos gráficos (no podemos pintar en un lienzo en dos puntos al mismo tiempo si no tenemos dos pinceles). Resalto gráficas porque una GPU puede realizar GPGPU al mismo tiempo que renderiza.

Aquí habláis desde la teoría pero no desde la práctica., y es por eso que no se entiende el porqué de la estructura de One. Para entender la tecnología hay que entender el rendering, el porqué y el cómo se hacen las distintas técnicas actuales y futuras. El factor determinante es el doble contexto gráfico. Ésto es MUY importante, la clave es la palabra "gráfico".

Un ejemplo muy sencillo de renderizado de sombras seria: CPU prepara y pide crear una sombra de un objeto, la GPU entra en juego y la genera. Y así sucesivamente por cada sombra. Hay que tener una cosa MUY clara, renderizar una sombra no necesita PARA NADA los 12 CUs de la consola, ni por tener 12 o 18 va a renderizarla más rápido, una sombra necesita una capacidad de cómputo determinada y que posiblemente con 1 única CU nos bastaría. El problema es que cuando se renderiza se OCUPA la GPU, por lo tanto aunque no necesitemos los 12 CUs, los 12 CUs se van a bloquear para poder pintar la sombra. Obviamente podemos distribuir los CUs, y decir que sólo queremos usar un máximo de CUs para renderizado, y el resto para GPGPU (y aprovechar así el tiempo de renderizado para sacar cómputo). Pero a la hora de renderizar y para los CUs asignados a renderizar TODOS quedan bloqueados.

A partir de aquí C es CPU y G es GPU. Si queremos generar 4 sombras tenemos:
C > G > C > G > C > G > C > G

¿Qué sucede en One?. Que al tener 2 contextos gráficos puede renderizar 2 sombras al mismo tiempo. Con lo que nos queda:

> G > G
C > C
> G > G

Esto es, ni más ni menos, que la mitad del tiempo. ¿Estamos duplicando en este caso el rendimiento gráfico de One?: SÍ. ¿Es One más potente por ello?: NO. La capacidad de cómputo de One es la misma solo que el rendimiento es el doble.

Otro ejemplo seria un engine gráfico basado en tiled forward (http://www.cse.chalmers.se/~olaolss/main_frame.php?contents=publication&id=tiled_shading). Esta implementación se basa en generar el frame final a base de tiles o porciones de pantalla pequeñas (pequeños rectángulos). A parte de las características negativas y positivas de ésta técnica (toda técnica tiene su lado bueno y su lado malo), a dónde quiero ir a parar es en el hecho en el que... teniendo 2 contextos gráficos simultáneos podemos dibujar 2 de esas porciones SIMULTÁNEAMENTE. Con lo que el resultado es que obtenemos el frame en la mitad del tiempo y por tanto doblamos el rendimiento. Aquí también quiero hacer incapié en otra característica única de One: su eSRAM. Dado que esta técnica no requiere de gran ancho de banda, lo que más le beneficia es una memoria RÁPIDA, es decir de bajísima latencia (no confundir RAPIDEZ con ANCHO DE BANDA, no tienen NADA que ver, la rapidez la determina el tiempo para que la memoria vuelva a estar disponible para una nueva petición y ahí importa la latencia, el ancho de banda sólo sirve para MOVER grandes cantidades de memoria de un punto A a un punto B). Quiero decir con esto que de aplicar esta técnica en ambas consolas, One ganaría por absoluta goleada. Pero si aplicamos técnicas más antiguas como un deferred engine PS4 tiene ventaja por su ancho de banda (y de aquí vienen las diferencias en multis hasta ahora en cuanto a resolución o framerate).

A todo esto hay que añadirle que One tiene Full HSA, es decir coherencia total de memoria, algo básico si tenemos más de un contexto gráfico y además GPGPU, porque sí, One puede renderizar dos cosas y hacer GPGPU AL MISMO TIEMPO y compartiendo la MISMA memoria. Y esto es MUY potente y da una serie de posibilidades únicas.

¿Bien... significa todo esto que One doblará su rendimiento?: NO. One doblará su rendimiento GRÁFICO en múltiples tareas gráficas pero el rendimiento GLOBAL de un juego no SÓLO depende de la GPU. Hay muchos otros factores: CPU, memoria, técnicas gráficas utilizadas...

Ahora bien, si a mi se me pregunta: ¿Cuánto crees en promedio que mejorará el rendimiento de One?. Sinceramente y, bajo MI opinión, One incrementará con DX12 el rendimiento entre un 50 a un 75%.

Sorry por el tocho y espero haber dejado bastantes cosas claras.

Una explicación increíble, sencilla y para todos los públicos

Me quito el sombrero

darksch escribió:No, os pongáis como os pongáis un CP no está exclusivamente dedicado al sistema. Sería absurdo dedicar la mitad de los recursos a algo que necesita un 10%. El 2o puede cambiar perfectamente entre juego y sistema, y de hecho es lo que hace. La otra unidad de geometría supongo que también estará dedicada al sistema...venga no os flipéis.

Si el reparto fuera 50/50 pues si lo más natural sería eso. Pero es 90/10 por lo que el 2o lo que hace es cambiar de contexto entre sistema y juego. Por lo que en teoría es tener 1,80 CP para el juego, en la practica algo menos por esos cambios que tiene que hacer la 2a, pero en la practica todo es siempre menos que en la teoría.

Pero si además lo dice la propia entrevista que se ha puesto hace nada, la parte final, donde dice claramente lo de rellenar huecos y hacer 2 cosas a la vez en el tiempo que el sistema no lo necesita, dedicarlo a la aplicación high. No entiendo la necesidad de negar algo que tenéis delante mismo.

papatuelo escribió:Bonito libro de...¿1992?

papatuelo escribió:La primera edición creo que es de 1992, por eso lo pone como ejemplo de sistemas operativos "modernos". Todo el mundo sabe que desde el 92 no ha pasado nada, ¿que va a pasar en 22 años de nada?

pspskulls escribió:Bueno, dado el despropósito al que se está llegando en este hilo voy a explicar lo que significa el PDF famoso.

Primero unas preguntas y respuestas rápidas importantes para entender la explicación:
- ¿Tiene Xbox ONE doble GPU?: NO.
- ¿Reserva ONE CPs o CUs para el sistema?: NO.
- ¿Podemos tener una GPU que admita multihilo sin tener doble contexto gráfico?: SI. Podemos tener 2 CP pidiendo tareas a la GPU y la GPU irá realizando las tareas pero no simultáneamente (por ejemplo pensad en un núcleo de CPU de 2 hilos, lo que ejecutan no es simultáneo sino que los hilos cogen la capacidad de proceso según el otro hilo ya no lo necesita). Para que una GPU realice dos tareas GRÁFICAS en paralelo DEBE tener 2 contextos gráficos (no podemos pintar en un lienzo en dos puntos al mismo tiempo si no tenemos dos pinceles). Resalto gráficas porque una GPU puede realizar GPGPU al mismo tiempo que renderiza.

Aquí habláis desde la teoría pero no desde la práctica., y es por eso que no se entiende el porqué de la estructura de One. Para entender la tecnología hay que entender el rendering, el porqué y el cómo se hacen las distintas técnicas actuales y futuras. El factor determinante es el doble contexto gráfico. Ésto es MUY importante, la clave es la palabra "gráfico".

Un ejemplo muy sencillo de renderizado de sombras seria: CPU prepara y pide crear una sombra de un objeto, la GPU entra en juego y la genera. Y así sucesivamente por cada sombra. Hay que tener una cosa MUY clara, renderizar una sombra no necesita PARA NADA los 12 CUs de la consola, ni por tener 12 o 18 va a renderizarla más rápido, una sombra necesita una capacidad de cómputo determinada y que posiblemente con 1 única CU nos bastaría. El problema es que cuando se renderiza se OCUPA la GPU, por lo tanto aunque no necesitemos los 12 CUs, los 12 CUs se van a bloquear para poder pintar la sombra. Obviamente podemos distribuir los CUs, y decir que sólo queremos usar un máximo de CUs para renderizado, y el resto para GPGPU (y aprovechar así el tiempo de renderizado para sacar cómputo). Pero a la hora de renderizar y para los CUs asignados a renderizar TODOS quedan bloqueados.

A partir de aquí C es CPU y G es GPU. Si queremos generar 4 sombras tenemos:
C > G > C > G > C > G > C > G

¿Qué sucede en One?. Que al tener 2 contextos gráficos puede renderizar 2 sombras al mismo tiempo. Con lo que nos queda:

> G > G
C > C
> G > G

Esto es, ni más ni menos, que la mitad del tiempo. ¿Estamos duplicando en este caso el rendimiento gráfico de One?: SÍ. ¿Es One más potente por ello?: NO. La capacidad de cómputo de One es la misma solo que el rendimiento es el doble.

Otro ejemplo seria un engine gráfico basado en tiled forward (http://www.cse.chalmers.se/~olaolss/main_frame.php?contents=publication&id=tiled_shading). Esta implementación se basa en generar el frame final a base de tiles o porciones de pantalla pequeñas (pequeños rectángulos). A parte de las características negativas y positivas de ésta técnica (toda técnica tiene su lado bueno y su lado malo), a dónde quiero ir a parar es en el hecho en el que... teniendo 2 contextos gráficos simultáneos podemos dibujar 2 de esas porciones SIMULTÁNEAMENTE. Con lo que el resultado es que obtenemos el frame en la mitad del tiempo y por tanto doblamos el rendimiento. Aquí también quiero hacer incapié en otra característica única de One: su eSRAM. Dado que esta técnica no requiere de gran ancho de banda, lo que más le beneficia es una memoria RÁPIDA, es decir de bajísima latencia (no confundir RAPIDEZ con ANCHO DE BANDA, no tienen NADA que ver, la rapidez la determina el tiempo para que la memoria vuelva a estar disponible para una nueva petición y ahí importa la latencia, el ancho de banda sólo sirve para MOVER grandes cantidades de memoria de un punto A a un punto B). Quiero decir con esto que de aplicar esta técnica en ambas consolas, One ganaría por absoluta goleada. Pero si aplicamos técnicas más antiguas como un deferred engine PS4 tiene ventaja por su ancho de banda (y de aquí vienen las diferencias en multis hasta ahora en cuanto a resolución o framerate).

A todo esto hay que añadirle que One tiene Full HSA, es decir coherencia total de memoria, algo básico si tenemos más de un contexto gráfico y además GPGPU, porque sí, One puede renderizar dos cosas y hacer GPGPU AL MISMO TIEMPO y compartiendo la MISMA memoria. Y esto es MUY potente y da una serie de posibilidades únicas.

¿Bien... significa todo esto que One doblará su rendimiento?: NO. One doblará su rendimiento GRÁFICO en múltiples tareas gráficas pero el rendimiento GLOBAL de un juego no SÓLO depende de la GPU. Hay muchos otros factores: CPU, memoria, técnicas gráficas utilizadas...

Ahora bien, si a mi se me pregunta: ¿Cuánto crees en promedio que mejorará el rendimiento de One?. Sinceramente y, bajo MI opinión, One incrementará con DX12 el rendimiento entre un 50 a un 75%.

Sorry por el tocho y espero haber dejado bastantes cosas claras.

castigo diario escribió:

pspskulls escribió:Bueno, dado el despropósito al que se está llegando en este hilo voy a explicar lo que significa el PDF famoso.

Primero unas preguntas y respuestas rápidas importantes para entender la explicación:
- ¿Tiene Xbox ONE doble GPU?: NO.
- ¿Reserva ONE CPs o CUs para el sistema?: NO.
- ¿Podemos tener una GPU que admita multihilo sin tener doble contexto gráfico?: SI. Podemos tener 2 CP pidiendo tareas a la GPU y la GPU irá realizando las tareas pero no simultáneamente (por ejemplo pensad en un núcleo de CPU de 2 hilos, lo que ejecutan no es simultáneo sino que los hilos cogen la capacidad de proceso según el otro hilo ya no lo necesita). Para que una GPU realice dos tareas GRÁFICAS en paralelo DEBE tener 2 contextos gráficos (no podemos pintar en un lienzo en dos puntos al mismo tiempo si no tenemos dos pinceles). Resalto gráficas porque una GPU puede realizar GPGPU al mismo tiempo que renderiza.

Aquí habláis desde la teoría pero no desde la práctica., y es por eso que no se entiende el porqué de la estructura de One. Para entender la tecnología hay que entender el rendering, el porqué y el cómo se hacen las distintas técnicas actuales y futuras. El factor determinante es el doble contexto gráfico. Ésto es MUY importante, la clave es la palabra "gráfico".

Un ejemplo muy sencillo de renderizado de sombras seria: CPU prepara y pide crear una sombra de un objeto, la GPU entra en juego y la genera. Y así sucesivamente por cada sombra. Hay que tener una cosa MUY clara, renderizar una sombra no necesita PARA NADA los 12 CUs de la consola, ni por tener 12 o 18 va a renderizarla más rápido, una sombra necesita una capacidad de cómputo determinada y que posiblemente con 1 única CU nos bastaría. El problema es que cuando se renderiza se OCUPA la GPU, por lo tanto aunque no necesitemos los 12 CUs, los 12 CUs se van a bloquear para poder pintar la sombra. Obviamente podemos distribuir los CUs, y decir que sólo queremos usar un máximo de CUs para renderizado, y el resto para GPGPU (y aprovechar así el tiempo de renderizado para sacar cómputo). Pero a la hora de renderizar y para los CUs asignados a renderizar TODOS quedan bloqueados.

A partir de aquí C es CPU y G es GPU. Si queremos generar 4 sombras tenemos:
C > G > C > G > C > G > C > G

¿Qué sucede en One?. Que al tener 2 contextos gráficos puede renderizar 2 sombras al mismo tiempo. Con lo que nos queda:

> G > G
C > C
> G > G

Esto es, ni más ni menos, que la mitad del tiempo. ¿Estamos duplicando en este caso el rendimiento gráfico de One?: SÍ. ¿Es One más potente por ello?: NO. La capacidad de cómputo de One es la misma solo que el rendimiento es el doble.

Otro ejemplo seria un engine gráfico basado en tiled forward (http://www.cse.chalmers.se/~olaolss/main_frame.php?contents=publication&id=tiled_shading). Esta implementación se basa en generar el frame final a base de tiles o porciones de pantalla pequeñas (pequeños rectángulos). A parte de las características negativas y positivas de ésta técnica (toda técnica tiene su lado bueno y su lado malo), a dónde quiero ir a parar es en el hecho en el que... teniendo 2 contextos gráficos simultáneos podemos dibujar 2 de esas porciones SIMULTÁNEAMENTE. Con lo que el resultado es que obtenemos el frame en la mitad del tiempo y por tanto doblamos el rendimiento. Aquí también quiero hacer incapié en otra característica única de One: su eSRAM. Dado que esta técnica no requiere de gran ancho de banda, lo que más le beneficia es una memoria RÁPIDA, es decir de bajísima latencia (no confundir RAPIDEZ con ANCHO DE BANDA, no tienen NADA que ver, la rapidez la determina el tiempo para que la memoria vuelva a estar disponible para una nueva petición y ahí importa la latencia, el ancho de banda sólo sirve para MOVER grandes cantidades de memoria de un punto A a un punto B). Quiero decir con esto que de aplicar esta técnica en ambas consolas, One ganaría por absoluta goleada. Pero si aplicamos técnicas más antiguas como un deferred engine PS4 tiene ventaja por su ancho de banda (y de aquí vienen las diferencias en multis hasta ahora en cuanto a resolución o framerate).

A todo esto hay que añadirle que One tiene Full HSA, es decir coherencia total de memoria, algo básico si tenemos más de un contexto gráfico y además GPGPU, porque sí, One puede renderizar dos cosas y hacer GPGPU AL MISMO TIEMPO y compartiendo la MISMA memoria. Y esto es MUY potente y da una serie de posibilidades únicas.

¿Bien... significa todo esto que One doblará su rendimiento?: NO. One doblará su rendimiento GRÁFICO en múltiples tareas gráficas pero el rendimiento GLOBAL de un juego no SÓLO depende de la GPU. Hay muchos otros factores: CPU, memoria, técnicas gráficas utilizadas...

Ahora bien, si a mi se me pregunta: ¿Cuánto crees en promedio que mejorará el rendimiento de One?. Sinceramente y, bajo MI opinión, One incrementará con DX12 el rendimiento entre un 50 a un 75%.

Sorry por el tocho y espero haber dejado bastantes cosas claras.

Primero gracias por la explicación, pero hay una cosa que no comprendo....si se duplica el rendimiento gráfico (o casi) con directx12 cómo se explica que no sea más potente?

No quiere decir eso que podrá mostrar más y mejores gráficos con directx12 y su hardware y conforme se mejore más el api mejores aún?

Alguien también va a decir ahora que no tiene más y mejor margen de mejora que la competencia al tener un hardware pensado para un futuro cercano?

Salu2

pspskulls escribió:

castigo diario escribió:

pspskulls escribió:Bueno, dado el despropósito al que se está llegando en este hilo voy a explicar lo que significa el PDF famoso.

Primero unas preguntas y respuestas rápidas importantes para entender la explicación:
- ¿Tiene Xbox ONE doble GPU?: NO.
- ¿Reserva ONE CPs o CUs para el sistema?: NO.
- ¿Podemos tener una GPU que admita multihilo sin tener doble contexto gráfico?: SI. Podemos tener 2 CP pidiendo tareas a la GPU y la GPU irá realizando las tareas pero no simultáneamente (por ejemplo pensad en un núcleo de CPU de 2 hilos, lo que ejecutan no es simultáneo sino que los hilos cogen la capacidad de proceso según el otro hilo ya no lo necesita). Para que una GPU realice dos tareas GRÁFICAS en paralelo DEBE tener 2 contextos gráficos (no podemos pintar en un lienzo en dos puntos al mismo tiempo si no tenemos dos pinceles). Resalto gráficas porque una GPU puede realizar GPGPU al mismo tiempo que renderiza.

Aquí habláis desde la teoría pero no desde la práctica., y es por eso que no se entiende el porqué de la estructura de One. Para entender la tecnología hay que entender el rendering, el porqué y el cómo se hacen las distintas técnicas actuales y futuras. El factor determinante es el doble contexto gráfico. Ésto es MUY importante, la clave es la palabra "gráfico".

Un ejemplo muy sencillo de renderizado de sombras seria: CPU prepara y pide crear una sombra de un objeto, la GPU entra en juego y la genera. Y así sucesivamente por cada sombra. Hay que tener una cosa MUY clara, renderizar una sombra no necesita PARA NADA los 12 CUs de la consola, ni por tener 12 o 18 va a renderizarla más rápido, una sombra necesita una capacidad de cómputo determinada y que posiblemente con 1 única CU nos bastaría. El problema es que cuando se renderiza se OCUPA la GPU, por lo tanto aunque no necesitemos los 12 CUs, los 12 CUs se van a bloquear para poder pintar la sombra. Obviamente podemos distribuir los CUs, y decir que sólo queremos usar un máximo de CUs para renderizado, y el resto para GPGPU (y aprovechar así el tiempo de renderizado para sacar cómputo). Pero a la hora de renderizar y para los CUs asignados a renderizar TODOS quedan bloqueados.

A partir de aquí C es CPU y G es GPU. Si queremos generar 4 sombras tenemos:
C > G > C > G > C > G > C > G

¿Qué sucede en One?. Que al tener 2 contextos gráficos puede renderizar 2 sombras al mismo tiempo. Con lo que nos queda:

> G > G
C > C
> G > G

Esto es, ni más ni menos, que la mitad del tiempo. ¿Estamos duplicando en este caso el rendimiento gráfico de One?: SÍ. ¿Es One más potente por ello?: NO. La capacidad de cómputo de One es la misma solo que el rendimiento es el doble.

Otro ejemplo seria un engine gráfico basado en tiled forward (http://www.cse.chalmers.se/~olaolss/main_frame.php?contents=publication&id=tiled_shading). Esta implementación se basa en generar el frame final a base de tiles o porciones de pantalla pequeñas (pequeños rectángulos). A parte de las características negativas y positivas de ésta técnica (toda técnica tiene su lado bueno y su lado malo), a dónde quiero ir a parar es en el hecho en el que... teniendo 2 contextos gráficos simultáneos podemos dibujar 2 de esas porciones SIMULTÁNEAMENTE. Con lo que el resultado es que obtenemos el frame en la mitad del tiempo y por tanto doblamos el rendimiento. Aquí también quiero hacer incapié en otra característica única de One: su eSRAM. Dado que esta técnica no requiere de gran ancho de banda, lo que más le beneficia es una memoria RÁPIDA, es decir de bajísima latencia (no confundir RAPIDEZ con ANCHO DE BANDA, no tienen NADA que ver, la rapidez la determina el tiempo para que la memoria vuelva a estar disponible para una nueva petición y ahí importa la latencia, el ancho de banda sólo sirve para MOVER grandes cantidades de memoria de un punto A a un punto B). Quiero decir con esto que de aplicar esta técnica en ambas consolas, One ganaría por absoluta goleada. Pero si aplicamos técnicas más antiguas como un deferred engine PS4 tiene ventaja por su ancho de banda (y de aquí vienen las diferencias en multis hasta ahora en cuanto a resolución o framerate).

A todo esto hay que añadirle que One tiene Full HSA, es decir coherencia total de memoria, algo básico si tenemos más de un contexto gráfico y además GPGPU, porque sí, One puede renderizar dos cosas y hacer GPGPU AL MISMO TIEMPO y compartiendo la MISMA memoria. Y esto es MUY potente y da una serie de posibilidades únicas.

¿Bien... significa todo esto que One doblará su rendimiento?: NO. One doblará su rendimiento GRÁFICO en múltiples tareas gráficas pero el rendimiento GLOBAL de un juego no SÓLO depende de la GPU. Hay muchos otros factores: CPU, memoria, técnicas gráficas utilizadas...

Ahora bien, si a mi se me pregunta: ¿Cuánto crees en promedio que mejorará el rendimiento de One?. Sinceramente y, bajo MI opinión, One incrementará con DX12 el rendimiento entre un 50 a un 75%.

Sorry por el tocho y espero haber dejado bastantes cosas claras.

Primero gracias por la explicación, pero hay una cosa que no comprendo....si se duplica el rendimiento gráfico (o casi) con directx12 cómo se explica que no sea más potente?

No quiere decir eso que podrá mostrar más y mejores gráficos con directx12 y su hardware y conforme se mejore más el api mejores aún?

Alguien también va a decir ahora que no tiene más y mejor margen de mejora que la competencia al tener un hardware pensado para un futuro cercano?

Salu2

La potencia está marcada por el hardware que incorpora la consola y eso no va a cambiar con o sin DX12. A ésto de hecho se refirió Phil Spencer con sus famosas palabras.

Rendimiento significa aprovechar algo, en este caso esa potencia. Y sí, mayor rendimiento lógicamente significan mejores gráficos, porque por cada frame dispones de MÁS tiempo disponible. Si tu tienes un juego a 30fps, y necesitas 33ms para generar cada frame, si con DX12 mejoras un 50% significa que para ese mismo frame tardarías 24ms para generarlo, con lo que los restantes ms hasta 33 puedes usarlos para mejorar la capacidad visual del frame.

Tu puedes tener un coche con 200CV (potencia), pero su máximo de velocidad y capacidad para mantener esa velocidad puede ser menor a un coche que tiene 150CV pero que con un menor diseño (peso, adherencia, tracción, etc) permite aprovechar mucho mejor cada uno de esos CV.

Aldebaran323 escribió:Impresionante cada una de tus explicaciones pspskulls

pspskulls escribió:Bueno, dado el despropósito al que se está llegando en este hilo voy a explicar lo que significa el PDF famoso.

Primero unas preguntas y respuestas rápidas importantes para entender la explicación:
- ¿Tiene Xbox ONE doble GPU?: NO.
- ¿Reserva ONE CPs o CUs para el sistema?: NO.
- ¿Podemos tener una GPU que admita multihilo sin tener doble contexto gráfico?: SI. Podemos tener 2 CP pidiendo tareas a la GPU y la GPU irá realizando las tareas pero no simultáneamente (por ejemplo pensad en un núcleo de CPU de 2 hilos, lo que ejecutan no es simultáneo sino que los hilos cogen la capacidad de proceso según el otro hilo ya no lo necesita). Para que una GPU realice dos tareas GRÁFICAS en paralelo DEBE tener 2 contextos gráficos (no podemos pintar en un lienzo en dos puntos al mismo tiempo si no tenemos dos pinceles). Resalto gráficas porque una GPU puede realizar GPGPU al mismo tiempo que renderiza.

Aquí habláis desde la teoría pero no desde la práctica., y es por eso que no se entiende el porqué de la estructura de One. Para entender la tecnología hay que entender el rendering, el porqué y el cómo se hacen las distintas técnicas actuales y futuras. El factor determinante es el doble contexto gráfico. Ésto es MUY importante, la clave es la palabra "gráfico".

Un ejemplo muy sencillo de renderizado de sombras seria: CPU prepara y pide crear una sombra de un objeto, la GPU entra en juego y la genera. Y así sucesivamente por cada sombra. Hay que tener una cosa MUY clara, renderizar una sombra no necesita PARA NADA los 12 CUs de la consola, ni por tener 12 o 18 va a renderizarla más rápido, una sombra necesita una capacidad de cómputo determinada y que posiblemente con 1 única CU nos bastaría. El problema es que cuando se renderiza se OCUPA la GPU, por lo tanto aunque no necesitemos los 12 CUs, los 12 CUs se van a bloquear para poder pintar la sombra. Obviamente podemos distribuir los CUs, y decir que sólo queremos usar un máximo de CUs para renderizado, y el resto para GPGPU (y aprovechar así el tiempo de renderizado para sacar cómputo). Pero a la hora de renderizar y para los CUs asignados a renderizar TODOS quedan bloqueados.

A partir de aquí C es CPU y G es GPU. Si queremos generar 4 sombras tenemos:
C > G > C > G > C > G > C > G

¿Qué sucede en One?. Que al tener 2 contextos gráficos puede renderizar 2 sombras al mismo tiempo. Con lo que nos queda:

> G > G
C > C
> G > G

Esto es, ni más ni menos, que la mitad del tiempo. ¿Estamos duplicando en este caso el rendimiento gráfico de One?: SÍ. ¿Es One más potente por ello?: NO. La capacidad de cómputo de One es la misma solo que el rendimiento es el doble.

Otro ejemplo seria un engine gráfico basado en tiled forward (http://www.cse.chalmers.se/~olaolss/main_frame.php?contents=publication&id=tiled_shading). Esta implementación se basa en generar el frame final a base de tiles o porciones de pantalla pequeñas (pequeños rectángulos). A parte de las características negativas y positivas de ésta técnica (toda técnica tiene su lado bueno y su lado malo), a dónde quiero ir a parar es en el hecho en el que... teniendo 2 contextos gráficos simultáneos podemos dibujar 2 de esas porciones SIMULTÁNEAMENTE. Con lo que el resultado es que obtenemos el frame en la mitad del tiempo y por tanto doblamos el rendimiento. Aquí también quiero hacer incapié en otra característica única de One: su eSRAM. Dado que esta técnica no requiere de gran ancho de banda, lo que más le beneficia es una memoria RÁPIDA, es decir de bajísima latencia (no confundir RAPIDEZ con ANCHO DE BANDA, no tienen NADA que ver, la rapidez la determina el tiempo para que la memoria vuelva a estar disponible para una nueva petición y ahí importa la latencia, el ancho de banda sólo sirve para MOVER grandes cantidades de memoria de un punto A a un punto B). Quiero decir con esto que de aplicar esta técnica en ambas consolas, One ganaría por absoluta goleada. Pero si aplicamos técnicas más antiguas como un deferred engine PS4 tiene ventaja por su ancho de banda (y de aquí vienen las diferencias en multis hasta ahora en cuanto a resolución o framerate).

A todo esto hay que añadirle que One tiene Full HSA, es decir coherencia total de memoria, algo básico si tenemos más de un contexto gráfico y además GPGPU, porque sí, One puede renderizar dos cosas y hacer GPGPU AL MISMO TIEMPO y compartiendo la MISMA memoria. Y esto es MUY potente y da una serie de posibilidades únicas.

¿Bien... significa todo esto que One doblará su rendimiento?: NO. One doblará su rendimiento GRÁFICO en múltiples tareas gráficas pero el rendimiento GLOBAL de un juego no SÓLO depende de la GPU. Hay muchos otros factores: CPU, memoria, técnicas gráficas utilizadas...

Ahora bien, si a mi se me pregunta: ¿Cuánto crees en promedio que mejorará el rendimiento de One?. Sinceramente y, bajo MI opinión, One incrementará con DX12 el rendimiento entre un 50 a un 75%.

Sorry por el tocho y espero haber dejado bastantes cosas claras.

pspskulls escribió:Bueno, dado el despropósito al que se está llegando en este hilo voy a explicar lo que significa el PDF famoso.

Primero unas preguntas y respuestas rápidas importantes para entender la explicación:
- ¿Tiene Xbox ONE doble GPU?: NO.
- ¿Reserva ONE CPs o CUs para el sistema?: NO.
- ¿Podemos tener una GPU que admita multihilo sin tener doble contexto gráfico?: SI. Podemos tener 2 CP pidiendo tareas a la GPU y la GPU irá realizando las tareas pero no simultáneamente (por ejemplo pensad en un núcleo de CPU de 2 hilos, lo que ejecutan no es simultáneo sino que los hilos cogen la capacidad de proceso según el otro hilo ya no lo necesita). Para que una GPU realice dos tareas GRÁFICAS en paralelo DEBE tener 2 contextos gráficos (no podemos pintar en un lienzo en dos puntos al mismo tiempo si no tenemos dos pinceles). Resalto gráficas porque una GPU puede realizar GPGPU al mismo tiempo que renderiza.

Aquí habláis desde la teoría pero no desde la práctica., y es por eso que no se entiende el porqué de la estructura de One. Para entender la tecnología hay que entender el rendering, el porqué y el cómo se hacen las distintas técnicas actuales y futuras. El factor determinante es el doble contexto gráfico. Ésto es MUY importante, la clave es la palabra "gráfico".

Un ejemplo muy sencillo de renderizado de sombras seria: CPU prepara y pide crear una sombra de un objeto, la GPU entra en juego y la genera. Y así sucesivamente por cada sombra. Hay que tener una cosa MUY clara, renderizar una sombra no necesita PARA NADA los 12 CUs de la consola, ni por tener 12 o 18 va a renderizarla más rápido, una sombra necesita una capacidad de cómputo determinada y que posiblemente con 1 única CU nos bastaría. El problema es que cuando se renderiza se OCUPA la GPU, por lo tanto aunque no necesitemos los 12 CUs, los 12 CUs se van a bloquear para poder pintar la sombra. Obviamente podemos distribuir los CUs, y decir que sólo queremos usar un máximo de CUs para renderizado, y el resto para GPGPU (y aprovechar así el tiempo de renderizado para sacar cómputo). Pero a la hora de renderizar y para los CUs asignados a renderizar TODOS quedan bloqueados.

A partir de aquí C es CPU y G es GPU. Si queremos generar 4 sombras tenemos:
C > G > C > G > C > G > C > G

¿Qué sucede en One?. Que al tener 2 contextos gráficos puede renderizar 2 sombras al mismo tiempo. Con lo que nos queda:

> G > G
C > C
> G > G

Esto es, ni más ni menos, que la mitad del tiempo. ¿Estamos duplicando en este caso el rendimiento gráfico de One?: SÍ. ¿Es One más potente por ello?: NO. La capacidad de cómputo de One es la misma solo que el rendimiento es el doble.

Otro ejemplo seria un engine gráfico basado en tiled forward (http://www.cse.chalmers.se/~olaolss/main_frame.php?contents=publication&id=tiled_shading). Esta implementación se basa en generar el frame final a base de tiles o porciones de pantalla pequeñas (pequeños rectángulos). A parte de las características negativas y positivas de ésta técnica (toda técnica tiene su lado bueno y su lado malo), a dónde quiero ir a parar es en el hecho en el que... teniendo 2 contextos gráficos simultáneos podemos dibujar 2 de esas porciones SIMULTÁNEAMENTE. Con lo que el resultado es que obtenemos el frame en la mitad del tiempo y por tanto doblamos el rendimiento. Aquí también quiero hacer incapié en otra característica única de One: su eSRAM. Dado que esta técnica no requiere de gran ancho de banda, lo que más le beneficia es una memoria RÁPIDA, es decir de bajísima latencia (no confundir RAPIDEZ con ANCHO DE BANDA, no tienen NADA que ver, la rapidez la determina el tiempo para que la memoria vuelva a estar disponible para una nueva petición y ahí importa la latencia, el ancho de banda sólo sirve para MOVER grandes cantidades de memoria de un punto A a un punto B). Quiero decir con esto que de aplicar esta técnica en ambas consolas, One ganaría por absoluta goleada. Pero si aplicamos técnicas más antiguas como un deferred engine PS4 tiene ventaja por su ancho de banda (y de aquí vienen las diferencias en multis hasta ahora en cuanto a resolución o framerate).

A todo esto hay que añadirle que One tiene Full HSA, es decir coherencia total de memoria, algo básico si tenemos más de un contexto gráfico y además GPGPU, porque sí, One puede renderizar dos cosas y hacer GPGPU AL MISMO TIEMPO y compartiendo la MISMA memoria. Y esto es MUY potente y da una serie de posibilidades únicas.

¿Bien... significa todo esto que One doblará su rendimiento?: NO. One doblará su rendimiento GRÁFICO en múltiples tareas gráficas pero el rendimiento GLOBAL de un juego no SÓLO depende de la GPU. Hay muchos otros factores: CPU, memoria, técnicas gráficas utilizadas...

Ahora bien, si a mi se me pregunta: ¿Cuánto crees en promedio que mejorará el rendimiento de One?. Sinceramente y, bajo MI opinión, One incrementará con DX12 el rendimiento entre un 50 a un 75%.

Sorry por el tocho y espero haber dejado bastantes cosas claras.

pspskulls escribió:Bueno, dado el despropósito al que se está llegando en este hilo voy a explicar lo que significa el PDF famoso.

Primero unas preguntas y respuestas rápidas importantes para entender la explicación:
- ¿Tiene Xbox ONE doble GPU?: NO.
- ¿Reserva ONE CPs o CUs para el sistema?: NO.
- ¿Podemos tener una GPU que admita multihilo sin tener doble contexto gráfico?: SI. Podemos tener 2 CP pidiendo tareas a la GPU y la GPU irá realizando las tareas pero no simultáneamente (por ejemplo pensad en un núcleo de CPU de 2 hilos, lo que ejecutan no es simultáneo sino que los hilos cogen la capacidad de proceso según el otro hilo ya no lo necesita). Para que una GPU realice dos tareas GRÁFICAS en paralelo DEBE tener 2 contextos gráficos (no podemos pintar en un lienzo en dos puntos al mismo tiempo si no tenemos dos pinceles). Resalto gráficas porque una GPU puede realizar GPGPU al mismo tiempo que renderiza.

Aquí habláis desde la teoría pero no desde la práctica., y es por eso que no se entiende el porqué de la estructura de One. Para entender la tecnología hay que entender el rendering, el porqué y el cómo se hacen las distintas técnicas actuales y futuras. El factor determinante es el doble contexto gráfico. Ésto es MUY importante, la clave es la palabra "gráfico".

Un ejemplo muy sencillo de renderizado de sombras seria: CPU prepara y pide crear una sombra de un objeto, la GPU entra en juego y la genera. Y así sucesivamente por cada sombra. Hay que tener una cosa MUY clara, renderizar una sombra no necesita PARA NADA los 12 CUs de la consola, ni por tener 12 o 18 va a renderizarla más rápido, una sombra necesita una capacidad de cómputo determinada y que posiblemente con 1 única CU nos bastaría. El problema es que cuando se renderiza se OCUPA la GPU, por lo tanto aunque no necesitemos los 12 CUs, los 12 CUs se van a bloquear para poder pintar la sombra. Obviamente podemos distribuir los CUs, y decir que sólo queremos usar un máximo de CUs para renderizado, y el resto para GPGPU (y aprovechar así el tiempo de renderizado para sacar cómputo). Pero a la hora de renderizar y para los CUs asignados a renderizar TODOS quedan bloqueados.

A partir de aquí C es CPU y G es GPU. Si queremos generar 4 sombras tenemos:
C > G > C > G > C > G > C > G

¿Qué sucede en One?. Que al tener 2 contextos gráficos puede renderizar 2 sombras al mismo tiempo. Con lo que nos queda:

> G > G
C > C
> G > G

Esto es, ni más ni menos, que la mitad del tiempo. ¿Estamos duplicando en este caso el rendimiento gráfico de One?: SÍ. ¿Es One más potente por ello?: NO. La capacidad de cómputo de One es la misma solo que el rendimiento es el doble.

Otro ejemplo seria un engine gráfico basado en tiled forward (http://www.cse.chalmers.se/~olaolss/main_frame.php?contents=publication&id=tiled_shading). Esta implementación se basa en generar el frame final a base de tiles o porciones de pantalla pequeñas (pequeños rectángulos). A parte de las características negativas y positivas de ésta técnica (toda técnica tiene su lado bueno y su lado malo), a dónde quiero ir a parar es en el hecho en el que... teniendo 2 contextos gráficos simultáneos podemos dibujar 2 de esas porciones SIMULTÁNEAMENTE. Con lo que el resultado es que obtenemos el frame en la mitad del tiempo y por tanto doblamos el rendimiento. Aquí también quiero hacer incapié en otra característica única de One: su eSRAM. Dado que esta técnica no requiere de gran ancho de banda, lo que más le beneficia es una memoria RÁPIDA, es decir de bajísima latencia (no confundir RAPIDEZ con ANCHO DE BANDA, no tienen NADA que ver, la rapidez la determina el tiempo para que la memoria vuelva a estar disponible para una nueva petición y ahí importa la latencia, el ancho de banda sólo sirve para MOVER grandes cantidades de memoria de un punto A a un punto B). Quiero decir con esto que de aplicar esta técnica en ambas consolas, One ganaría por absoluta goleada. Pero si aplicamos técnicas más antiguas como un deferred engine PS4 tiene ventaja por su ancho de banda (y de aquí vienen las diferencias en multis hasta ahora en cuanto a resolución o framerate).

A todo esto hay que añadirle que One tiene Full HSA, es decir coherencia total de memoria, algo básico si tenemos más de un contexto gráfico y además GPGPU, porque sí, One puede renderizar dos cosas y hacer GPGPU AL MISMO TIEMPO y compartiendo la MISMA memoria. Y esto es MUY potente y da una serie de posibilidades únicas.

¿Bien... significa todo esto que One doblará su rendimiento?: NO. One doblará su rendimiento GRÁFICO en múltiples tareas gráficas pero el rendimiento GLOBAL de un juego no SÓLO depende de la GPU. Hay muchos otros factores: CPU, memoria, técnicas gráficas utilizadas...

Ahora bien, si a mi se me pregunta: ¿Cuánto crees en promedio que mejorará el rendimiento de One?. Sinceramente y, bajo MI opinión, One incrementará con DX12 el rendimiento entre un 50 a un 75%.

Sorry por el tocho y espero haber dejado bastantes cosas claras.

darksch escribió:No, os pongáis como os pongáis un CP no está exclusivamente dedicado al sistema. Sería absurdo dedicar la mitad de los recursos a algo que necesita un 10%. El 2o puede cambiar perfectamente entre juego y sistema, y de hecho es lo que hace. La otra unidad de geometría supongo que también estará dedicada al sistema...venga no os flipéis.

Si el reparto fuera 50/50 pues si lo más natural sería eso. Pero es 90/10 por lo que el 2o lo que hace es cambiar de contexto entre sistema y juego. Por lo que en teoría es tener 1,80 CP para el juego, en la practica algo menos por esos cambios que tiene que hacer la 2a, pero en la practica todo es siempre menos que en la teoría.

Pero si además lo dice la propia entrevista que se ha puesto hace nada, la parte final, donde dice claramente lo de rellenar huecos y hacer 2 cosas a la vez en el tiempo que el sistema no lo necesita, dedicarlo a la aplicación high. No entiendo la necesidad de negar algo que tenéis delante mismo.

aelio escribió:Genial el símil del pintor con dos pinceles!! Felicitaciones pspskulls!!

@Urian
En vez de poner la portada de un libro, que no dudo explique las bases de todo SO operativo moderno, cúrrate más tus apotaciones. Sin duda puedes ser muy didáctico, como has demostrado muchas veces en tu blog, pero desde luego tu actitud aquí como en otro foro que conoces no aporta nada más que una imagen de arrogancia

Saludos

pspskulls escribió:

castigo diario escribió:

pspskulls escribió:Bueno, dado el despropósito al que se está llegando en este hilo voy a explicar lo que significa el PDF famoso.

Primero unas preguntas y respuestas rápidas importantes para entender la explicación:
- ¿Tiene Xbox ONE doble GPU?: NO.
- ¿Reserva ONE CPs o CUs para el sistema?: NO.
- ¿Podemos tener una GPU que admita multihilo sin tener doble contexto gráfico?: SI. Podemos tener 2 CP pidiendo tareas a la GPU y la GPU irá realizando las tareas pero no simultáneamente (por ejemplo pensad en un núcleo de CPU de 2 hilos, lo que ejecutan no es simultáneo sino que los hilos cogen la capacidad de proceso según el otro hilo ya no lo necesita). Para que una GPU realice dos tareas GRÁFICAS en paralelo DEBE tener 2 contextos gráficos (no podemos pintar en un lienzo en dos puntos al mismo tiempo si no tenemos dos pinceles). Resalto gráficas porque una GPU puede realizar GPGPU al mismo tiempo que renderiza.

Aquí habláis desde la teoría pero no desde la práctica., y es por eso que no se entiende el porqué de la estructura de One. Para entender la tecnología hay que entender el rendering, el porqué y el cómo se hacen las distintas técnicas actuales y futuras. El factor determinante es el doble contexto gráfico. Ésto es MUY importante, la clave es la palabra "gráfico".

Un ejemplo muy sencillo de renderizado de sombras seria: CPU prepara y pide crear una sombra de un objeto, la GPU entra en juego y la genera. Y así sucesivamente por cada sombra. Hay que tener una cosa MUY clara, renderizar una sombra no necesita PARA NADA los 12 CUs de la consola, ni por tener 12 o 18 va a renderizarla más rápido, una sombra necesita una capacidad de cómputo determinada y que posiblemente con 1 única CU nos bastaría. El problema es que cuando se renderiza se OCUPA la GPU, por lo tanto aunque no necesitemos los 12 CUs, los 12 CUs se van a bloquear para poder pintar la sombra. Obviamente podemos distribuir los CUs, y decir que sólo queremos usar un máximo de CUs para renderizado, y el resto para GPGPU (y aprovechar así el tiempo de renderizado para sacar cómputo). Pero a la hora de renderizar y para los CUs asignados a renderizar TODOS quedan bloqueados.

A partir de aquí C es CPU y G es GPU. Si queremos generar 4 sombras tenemos:
C > G > C > G > C > G > C > G

¿Qué sucede en One?. Que al tener 2 contextos gráficos puede renderizar 2 sombras al mismo tiempo. Con lo que nos queda:

> G > G
C > C
> G > G

Esto es, ni más ni menos, que la mitad del tiempo. ¿Estamos duplicando en este caso el rendimiento gráfico de One?: SÍ. ¿Es One más potente por ello?: NO. La capacidad de cómputo de One es la misma solo que el rendimiento es el doble.

Otro ejemplo seria un engine gráfico basado en tiled forward (http://www.cse.chalmers.se/~olaolss/main_frame.php?contents=publication&id=tiled_shading). Esta implementación se basa en generar el frame final a base de tiles o porciones de pantalla pequeñas (pequeños rectángulos). A parte de las características negativas y positivas de ésta técnica (toda técnica tiene su lado bueno y su lado malo), a dónde quiero ir a parar es en el hecho en el que... teniendo 2 contextos gráficos simultáneos podemos dibujar 2 de esas porciones SIMULTÁNEAMENTE. Con lo que el resultado es que obtenemos el frame en la mitad del tiempo y por tanto doblamos el rendimiento. Aquí también quiero hacer incapié en otra característica única de One: su eSRAM. Dado que esta técnica no requiere de gran ancho de banda, lo que más le beneficia es una memoria RÁPIDA, es decir de bajísima latencia (no confundir RAPIDEZ con ANCHO DE BANDA, no tienen NADA que ver, la rapidez la determina el tiempo para que la memoria vuelva a estar disponible para una nueva petición y ahí importa la latencia, el ancho de banda sólo sirve para MOVER grandes cantidades de memoria de un punto A a un punto B). Quiero decir con esto que de aplicar esta técnica en ambas consolas, One ganaría por absoluta goleada. Pero si aplicamos técnicas más antiguas como un deferred engine PS4 tiene ventaja por su ancho de banda (y de aquí vienen las diferencias en multis hasta ahora en cuanto a resolución o framerate).

A todo esto hay que añadirle que One tiene Full HSA, es decir coherencia total de memoria, algo básico si tenemos más de un contexto gráfico y además GPGPU, porque sí, One puede renderizar dos cosas y hacer GPGPU AL MISMO TIEMPO y compartiendo la MISMA memoria. Y esto es MUY potente y da una serie de posibilidades únicas.

¿Bien... significa todo esto que One doblará su rendimiento?: NO. One doblará su rendimiento GRÁFICO en múltiples tareas gráficas pero el rendimiento GLOBAL de un juego no SÓLO depende de la GPU. Hay muchos otros factores: CPU, memoria, técnicas gráficas utilizadas...

Ahora bien, si a mi se me pregunta: ¿Cuánto crees en promedio que mejorará el rendimiento de One?. Sinceramente y, bajo MI opinión, One incrementará con DX12 el rendimiento entre un 50 a un 75%.

Sorry por el tocho y espero haber dejado bastantes cosas claras.

Primero gracias por la explicación, pero hay una cosa que no comprendo....si se duplica el rendimiento gráfico (o casi) con directx12 cómo se explica que no sea más potente?

No quiere decir eso que podrá mostrar más y mejores gráficos con directx12 y su hardware y conforme se mejore más el api mejores aún?

Alguien también va a decir ahora que no tiene más y mejor margen de mejora que la competencia al tener un hardware pensado para un futuro cercano?

Salu2

La potencia está marcada por el hardware que incorpora la consola y eso no va a cambiar con o sin DX12. A ésto de hecho se refirió Phil Spencer con sus famosas palabras.

Rendimiento significa aprovechar algo, en este caso esa potencia. Y sí, mayor rendimiento lógicamente significan mejores gráficos, porque por cada frame dispones de MÁS tiempo disponible. Si tu tienes un juego a 30fps, y necesitas 33ms para generar cada frame, si con DX12 mejoras un 50% significa que para ese mismo frame tardarías 24ms para generarlo, con lo que los restantes ms hasta 33 puedes usarlos para mejorar la capacidad visual del frame.

Tu puedes tener un coche con 200CV (potencia), pero su máximo de velocidad y capacidad para mantener esa velocidad puede ser menor a un coche que tiene 150CV pero que con un menor diseño (peso, adherencia, tracción, etc) permite aprovechar mucho mejor cada uno de esos CV.

En realidad mejor ejemplo para el coche de 200CV es si de repente cambiamos la gasolina que gasta por una mucho mejor llamada DX12, pues alcanzará mayor velocidad y con mejor estabilidad.

Urian escribió:

aelio escribió:Genial el símil del pintor con dos pinceles!! Felicitaciones pspskulls!!

@Urian
En vez de poner la portada de un libro, que no dudo explique las bases de todo SO operativo moderno, cúrrate más tus apotaciones. Sin duda puedes ser muy didáctico, como has demostrado muchas veces en tu blog, pero desde luego tu actitud aquí como en otro foro que conoces no aporta nada más que una imagen de arrogancia

Saludos

Arrogancia no, el hecho de que se utilicen dos procesadores de comandos en la GPU tiene que ver con la forma en la que un SO lleva los procesos que comunican con el hardware. De ahí la recomendación del libro, no es por joder, es porque esta gratuito por internet y es con el que yo y mucha gente ha estudiado.

pspskulls escribió:Bueno, dado el despropósito al que se está llegando en este hilo voy a explicar lo que significa el PDF famoso.

Primero unas preguntas y respuestas rápidas importantes para entender la explicación:
- ¿Tiene Xbox ONE doble GPU?: NO.
- ¿Reserva ONE CPs o CUs para el sistema?: NO.
- ¿Podemos tener una GPU que admita multihilo sin tener doble contexto gráfico?: SI. Podemos tener 2 CP pidiendo tareas a la GPU y la GPU irá realizando las tareas pero no simultáneamente (por ejemplo pensad en un núcleo de CPU de 2 hilos, lo que ejecutan no es simultáneo sino que los hilos cogen la capacidad de proceso según el otro hilo ya no lo necesita). Para que una GPU realice dos tareas GRÁFICAS en paralelo DEBE tener 2 contextos gráficos (no podemos pintar en un lienzo en dos puntos al mismo tiempo si no tenemos dos pinceles). Resalto gráficas porque una GPU puede realizar GPGPU al mismo tiempo que renderiza.

Aquí habláis desde la teoría pero no desde la práctica., y es por eso que no se entiende el porqué de la estructura de One. Para entender la tecnología hay que entender el rendering, el porqué y el cómo se hacen las distintas técnicas actuales y futuras. El factor determinante es el doble contexto gráfico. Ésto es MUY importante, la clave es la palabra "gráfico".

Un ejemplo muy sencillo de renderizado de sombras seria: CPU prepara y pide crear una sombra de un objeto, la GPU entra en juego y la genera. Y así sucesivamente por cada sombra. Hay que tener una cosa MUY clara, renderizar una sombra no necesita PARA NADA los 12 CUs de la consola, ni por tener 12 o 18 va a renderizarla más rápido, una sombra necesita una capacidad de cómputo determinada y que posiblemente con 1 única CU nos bastaría. El problema es que cuando se renderiza se OCUPA la GPU, por lo tanto aunque no necesitemos los 12 CUs, los 12 CUs se van a bloquear para poder pintar la sombra. Obviamente podemos distribuir los CUs, y decir que sólo queremos usar un máximo de CUs para renderizado, y el resto para GPGPU (y aprovechar así el tiempo de renderizado para sacar cómputo). Pero a la hora de renderizar y para los CUs asignados a renderizar TODOS quedan bloqueados.

A partir de aquí C es CPU y G es GPU. Si queremos generar 4 sombras tenemos:
C > G > C > G > C > G > C > G

¿Qué sucede en One?. Que al tener 2 contextos gráficos puede renderizar 2 sombras al mismo tiempo. Con lo que nos queda:

> G > G
C > C
> G > G

Esto es, ni más ni menos, que la mitad del tiempo. ¿Estamos duplicando en este caso el rendimiento gráfico de One?: SÍ. ¿Es One más potente por ello?: NO. La capacidad de cómputo de One es la misma solo que el rendimiento es el doble.

Otro ejemplo seria un engine gráfico basado en tiled forward (http://www.cse.chalmers.se/~olaolss/main_frame.php?contents=publication&id=tiled_shading). Esta implementación se basa en generar el frame final a base de tiles o porciones de pantalla pequeñas (pequeños rectángulos). A parte de las características negativas y positivas de ésta técnica (toda técnica tiene su lado bueno y su lado malo), a dónde quiero ir a parar es en el hecho en el que... teniendo 2 contextos gráficos simultáneos podemos dibujar 2 de esas porciones SIMULTÁNEAMENTE. Con lo que el resultado es que obtenemos el frame en la mitad del tiempo y por tanto doblamos el rendimiento. Aquí también quiero hacer incapié en otra característica única de One: su eSRAM. Dado que esta técnica no requiere de gran ancho de banda, lo que más le beneficia es una memoria RÁPIDA, es decir de bajísima latencia (no confundir RAPIDEZ con ANCHO DE BANDA, no tienen NADA que ver, la rapidez la determina el tiempo para que la memoria vuelva a estar disponible para una nueva petición y ahí importa la latencia, el ancho de banda sólo sirve para MOVER grandes cantidades de memoria de un punto A a un punto B). Quiero decir con esto que de aplicar esta técnica en ambas consolas, One ganaría por absoluta goleada. Pero si aplicamos técnicas más antiguas como un deferred engine PS4 tiene ventaja por su ancho de banda (y de aquí vienen las diferencias en multis hasta ahora en cuanto a resolución o framerate).

A todo esto hay que añadirle que One tiene Full HSA, es decir coherencia total de memoria, algo básico si tenemos más de un contexto gráfico y además GPGPU, porque sí, One puede renderizar dos cosas y hacer GPGPU AL MISMO TIEMPO y compartiendo la MISMA memoria. Y esto es MUY potente y da una serie de posibilidades únicas.

¿Bien... significa todo esto que One doblará su rendimiento?: NO. One doblará su rendimiento GRÁFICO en múltiples tareas gráficas pero el rendimiento GLOBAL de un juego no SÓLO depende de la GPU. Hay muchos otros factores: CPU, memoria, técnicas gráficas utilizadas...

Ahora bien, si a mi se me pregunta: ¿Cuánto crees en promedio que mejorará el rendimiento de One?. Sinceramente y, bajo MI opinión, One incrementará con DX12 el rendimiento entre un 50 a un 75%.

Sorry por el tocho y espero haber dejado bastantes cosas claras.

Urian escribió:

aelio escribió:Genial el símil del pintor con dos pinceles!! Felicitaciones pspskulls!!

@Urian
En vez de poner la portada de un libro, que no dudo explique las bases de todo SO operativo moderno, cúrrate más tus apotaciones. Sin duda puedes ser muy didáctico, como has demostrado muchas veces en tu blog, pero desde luego tu actitud aquí como en otro foro que conoces no aporta nada más que una imagen de arrogancia

Saludos

Arrogancia no, el hecho de que se utilicen dos procesadores de comandos en la GPU tiene que ver con la forma en la que un SO lleva los procesos que comunican con el hardware. De ahí la recomendación del libro, no es por joder, es porque esta gratuito por internet y es con el que yo y mucha gente ha estudiado.

Nuhar escribió:Ya que estamos con los tiles, una duda que tengo personal a raiz de todo esto.


Los renders de diseño grafico con un motor como el vray, renderizan de diferente forma que un juego. ¿Cuales son las principales diferencias al renderizar?

Es que con lo del tile forward, la explicacion, me he acordado que vray usa un tile por nucleo de cpu y ya me ha entrado la duda de como se genera todo esto

pspskulls escribió:Bueno, dado el despropósito al que se está llegando en este hilo voy a explicar lo que significa el PDF famoso.

Primero unas preguntas y respuestas rápidas importantes para entender la explicación:
- ¿Tiene Xbox ONE doble GPU?: NO.
- ¿Reserva ONE CPs o CUs para el sistema?: NO.
- ¿Podemos tener una GPU que admita multihilo sin tener doble contexto gráfico?: SI. Podemos tener 2 CP pidiendo tareas a la GPU y la GPU irá realizando las tareas pero no simultáneamente (por ejemplo pensad en un núcleo de CPU de 2 hilos, lo que ejecutan no es simultáneo sino que los hilos cogen la capacidad de proceso según el otro hilo ya no lo necesita). Para que una GPU realice dos tareas GRÁFICAS en paralelo DEBE tener 2 contextos gráficos (no podemos pintar en un lienzo en dos puntos al mismo tiempo si no tenemos dos pinceles). Resalto gráficas porque una GPU puede realizar GPGPU al mismo tiempo que renderiza.

Aquí habláis desde la teoría pero no desde la práctica., y es por eso que no se entiende el porqué de la estructura de One. Para entender la tecnología hay que entender el rendering, el porqué y el cómo se hacen las distintas técnicas actuales y futuras. El factor determinante es el doble contexto gráfico. Ésto es MUY importante, la clave es la palabra "gráfico".

Un ejemplo muy sencillo de renderizado de sombras seria: CPU prepara y pide crear una sombra de un objeto, la GPU entra en juego y la genera. Y así sucesivamente por cada sombra. Hay que tener una cosa MUY clara, renderizar una sombra no necesita PARA NADA los 12 CUs de la consola, ni por tener 12 o 18 va a renderizarla más rápido, una sombra necesita una capacidad de cómputo determinada y que posiblemente con 1 única CU nos bastaría. El problema es que cuando se renderiza se OCUPA la GPU, por lo tanto aunque no necesitemos los 12 CUs, los 12 CUs se van a bloquear para poder pintar la sombra. Obviamente podemos distribuir los CUs, y decir que sólo queremos usar un máximo de CUs para renderizado, y el resto para GPGPU (y aprovechar así el tiempo de renderizado para sacar cómputo). Pero a la hora de renderizar y para los CUs asignados a renderizar TODOS quedan bloqueados.

A partir de aquí C es CPU y G es GPU. Si queremos generar 4 sombras tenemos:
C > G > C > G > C > G > C > G

¿Qué sucede en One?. Que al tener 2 contextos gráficos puede renderizar 2 sombras al mismo tiempo. Con lo que nos queda:

> G > G
C > C
> G > G

Esto es, ni más ni menos, que la mitad del tiempo. ¿Estamos duplicando en este caso el rendimiento gráfico de One?: SÍ. ¿Es One más potente por ello?: NO. La capacidad de cómputo de One es la misma solo que el rendimiento es el doble.

Otro ejemplo seria un engine gráfico basado en tiled forward (http://www.cse.chalmers.se/~olaolss/main_frame.php?contents=publication&id=tiled_shading). Esta implementación se basa en generar el frame final a base de tiles o porciones de pantalla pequeñas (pequeños rectángulos). A parte de las características negativas y positivas de ésta técnica (toda técnica tiene su lado bueno y su lado malo), a dónde quiero ir a parar es en el hecho en el que... teniendo 2 contextos gráficos simultáneos podemos dibujar 2 de esas porciones SIMULTÁNEAMENTE. Con lo que el resultado es que obtenemos el frame en la mitad del tiempo y por tanto doblamos el rendimiento. Aquí también quiero hacer incapié en otra característica única de One: su eSRAM. Dado que esta técnica no requiere de gran ancho de banda, lo que más le beneficia es una memoria RÁPIDA, es decir de bajísima latencia (no confundir RAPIDEZ con ANCHO DE BANDA, no tienen NADA que ver, la rapidez la determina el tiempo para que la memoria vuelva a estar disponible para una nueva petición y ahí importa la latencia, el ancho de banda sólo sirve para MOVER grandes cantidades de memoria de un punto A a un punto B). Quiero decir con esto que de aplicar esta técnica en ambas consolas, One ganaría por absoluta goleada. Pero si aplicamos técnicas más antiguas como un deferred engine PS4 tiene ventaja por su ancho de banda (y de aquí vienen las diferencias en multis hasta ahora en cuanto a resolución o framerate).

A todo esto hay que añadirle que One tiene Full HSA, es decir coherencia total de memoria, algo básico si tenemos más de un contexto gráfico y además GPGPU, porque sí, One puede renderizar dos cosas y hacer GPGPU AL MISMO TIEMPO y compartiendo la MISMA memoria. Y esto es MUY potente y da una serie de posibilidades únicas.

¿Bien... significa todo esto que One doblará su rendimiento?: NO. One doblará su rendimiento GRÁFICO en múltiples tareas gráficas pero el rendimiento GLOBAL de un juego no SÓLO depende de la GPU. Hay muchos otros factores: CPU, memoria, técnicas gráficas utilizadas...

Ahora bien, si a mi se me pregunta: ¿Cuánto crees en promedio que mejorará el rendimiento de One?. Sinceramente y, bajo MI opinión, One incrementará con DX12 el rendimiento entre un 50 a un 75%.

Sorry por el tocho y espero haber dejado bastantes cosas claras.

darksch escribió:@Urian como quiera que un SO haga ese reparto pues a lo suyo. Te percatarás de tu error en que entonces las GPU con sólo 1 CP qué pasa, que no pueden hacer más que una cosa. Pues si ese CP puede cambiar de contexto por qué el 2º de la XOne no va a poder. Es decir, es que las GPU ya lo hacen con cualquier SO. Pon un juego en modo ventana y me dices que o se mueve el juego o el sistema, pero no ambos. Y que yo sepa ahora mismo ni los SSOO ni las GPU se preocupan de repartir específicamente, y menos en un entorno de hardware abierto donde no sabes que es lo que te vas a encontrar de GPU. Se cambia el contexto juego/sistema y que lo pille quien pueda en la GPU como se diría, y oye hasta funciona y todo. Ya si sé que tengo 2 (hardware cerrado) y hago el sistema para su uso específico, pues mira. Según tu razonamiento, si tengo una GPU con 2 CP y lo pongo en modo ventana la mitad de la GPU sería para el sistema, y no es así.

aelio escribió:Nos hemos olvidado de una cosa, y es que en realidad Xbox One no tiene 2 OS, si no TRES!!
http://wccftech.com/xbox-one-architecture-explained-runs-windows-8-virtually-indistinguishable/

Y es precisamente el Host OS el que controla todo los recursos, así que los otros dos sistemas operativos no se comunican directamente con la GPU, si no que lo hacen a través de este otro OS.

Tal y como se indica en el enlace,
"All the Direct X draw calls go straight from the Exclusive OS down to the Host OS"
No son dos OS, si no uno solo el que controla la GPU, según dan a entender.

Saludos

Urian escribió:

darksch escribió:@Urian como quiera que un SO haga ese reparto pues a lo suyo. Te percatarás de tu error en que entonces las GPU con sólo 1 CP qué pasa, que no pueden hacer más que una cosa. Pues si ese CP puede cambiar de contexto por qué el 2º de la XOne no va a poder. Es decir, es que las GPU ya lo hacen con cualquier SO. Pon un juego en modo ventana y me dices que o se mueve el juego o el sistema, pero no ambos. Y que yo sepa ahora mismo ni los SSOO ni las GPU se preocupan de repartir específicamente, y menos en un entorno de hardware abierto donde no sabes que es lo que te vas a encontrar de GPU. Se cambia el contexto juego/sistema y que lo pille quien pueda en la GPU como se diría, y oye hasta funciona y todo. Ya si sé que tengo 2 (hardware cerrado) y hago el sistema para su uso específico, pues mira. Según tu razonamiento, si tengo una GPU con 2 CP y lo pongo en modo ventana la mitad de la GPU sería para el sistema, y no es así.

¿Mi razonamiento? ¿El que has cagado tu y luego has autoconsumido? No tengo la culpa de que aquí algunos me tengáis manía. Sí no tienes capacidad de comprensión y/o en su defecto desconoces como funcionan cierta cosas mejor calladito y al rincón.

Pero no pongas palabras en la boca de los demás que no han dicho.

Arrogancia no, el hecho de que se utilicen dos procesadores de comandos en la GPU tiene que ver con la forma en la que un SO lleva los procesos que comunican con el hardware. De ahí la recomendación del libro, no es por joder, es porque esta gratuito por internet y es con el que yo y mucha gente ha estudiado.

No te preocupes, Polyteres ha puesto a continuación el porque estoy tan seguro de ello.