Hablemos del interior de Xbox One

Szasz escribió:
Shynobyn escribió:
darksch escribió:Casualidad, casualidad [cof, cof].


Casualidad ninguna, no hay ningun bloque extra repecto a GCN 1.1, solo indican los bloques renovados.


The GPU design was modified to include new logical blocks. What’s new is Command Processor, Geometry Processor, Multimedia Cores, Display Engine and upgraded L2 Cache and Memory Controller.

¿Te parece poco? ¿No ves ningún parecido con Xbox One?


Bloques que como digo ya tiene GCN 1.1, salvo por el hardware sheduler que no estoy seguro si en las dedicadas hay algo equivalente, sin embargo las APU basadas en GCN 1.1 si tienen.

Por otro lado segun la diapositiva de Dx12_1, son features soportadas por hardware. Lo dice claramente.


No, solo indica que la GPU reporta su feature level segun sus capacidades, en singular además constatando lo que he comentado. De hecho toda la presentación se centra en el software. Más abajo en las notas tambien especifica:

"On device create, app provides a list of supported feature levels" (lista)
"Runtime will return the highest level the hardware implements" (uno)
Nuhar escribió:Lo de la luz tiene mucha tela detras, no son solo rebotes, que tambien, sino que cada cuerpo desprende una luz, y aunque es minima, afecta a los colores ambientales.

Yo lo que creo es que esta gen es transitoria, hay muchas nuevas tecnologias que dentro de 3-4 años van a dejarnos asombrados, por eso pienso que esta gen es transitoria y la proxima va a tener un enorme salto


Lo he dicho antes, pero nadie se acuerda de esto.

Imagen


Ray tracing en DX12 mostrado en el GDC de este año:

Imagen

Para quien no viera la GDC les dire que literalmente dijeron que era una demo antigua de XBOX.

Visita de los chicos de engadget al laboratorio de silicio de XBOX ONE en mayo 2013.

Imagen

@Shynobin, dice "hardware implements". Warp lo que permite es hacer por fuerza bruta aquello para lo que no hay hardware implement, de hecho Warp lo ejecuta la CPU hasta donde yo sé y no la GPU.

¿GCN 1.1 tiene hardware scheduler en las APUs? ¿GCN 1.1 tiene multimedia cores?

¿Podrías enlazar una fuente de información para esas afirmaciones? Lo digo basicamente porque no es la información que to manejo y si estoy equivocado me gustaría que me pasaras fuentes fiables.
Bastante más impresionante que cualquier demo de RT que haya visto de ese estilo.

Imagen
papatuelo escribió:
@Shynobin, dice "hardware implements". Warp lo que permite es hacer por fuerza bruta aquello para lo que no hay hardware implement, de hecho Warp lo ejecuta la CPU hasta donde yo sé y no la GPU.

¿GCN 1.1 tiene hardware scheduler en las APUs? ¿GCN 1.1 tiene multimedia cores?

¿Podrías enlazar una fuente de información para esas afirmaciones? Lo digo basicamente porque no es la información que to manejo y si estoy equivocado me gustaría que me pasaras fuentes fiables.


Por ejemplo al final del quinto slide de ese documento habla del hardware scheduler de kaveri:

https://www.amd.com/Documents/Compute_C ... epaper.pdf

Y luego GCN tiene los multimedia accelerators que es solo otra manera de llamar a lo mismo.

EDIT: Pero vamos que el comentario no iba por ti sino por darkshd que todas las coincidencias con Polaris que ha destacado tambien son coincidencias con GCN1.1 por lo que no se puede sacar ninguna conlusión de todo eso.

Habria que entrar en que cambios concretos se han producido, como tu ya has tratado de hacer, pero aun así parece que todo lo que has comentado relaciona One con GCN 1.2 a lo sumo, pero no con Polaris.
Shynobyn escribió:
papatuelo escribió:
@Shynobin, dice "hardware implements". Warp lo que permite es hacer por fuerza bruta aquello para lo que no hay hardware implement, de hecho Warp lo ejecuta la CPU hasta donde yo sé y no la GPU.

¿GCN 1.1 tiene hardware scheduler en las APUs? ¿GCN 1.1 tiene multimedia cores?

¿Podrías enlazar una fuente de información para esas afirmaciones? Lo digo basicamente porque no es la información que to manejo y si estoy equivocado me gustaría que me pasaras fuentes fiables.


Por ejemplo al final del quinto slide de ese documento habla del hardware scheduler de kaveri:

https://www.amd.com/Documents/Compute_C ... epaper.pdf

Y luego GCN tiene los multimedia accelerators que es solo otra manera de llamar a lo mismo.


Gracias, veo que si mencionan "1 hardware scheduler" por gpu, aun así también veo que mantienen los 8 ACEs por GPU y por lo tanto los 8 hilos por ACE. Con los ACEs y Hardware scheduler de GCN 1.2 manejas el doble de hilos por ACE. Además de que en GCN 1.2 son dos Hardware Schedulers.

Lo bueno es que veo que son cosas relacionadas con el HSA.

Por otro lado los multimedia cores podrían ser eso o no, eso aun no se sabe.

Lo dicho gracias por la info.

Shynobin, el tema es que son muchas coincidencias que ya te he puesto más atrás. Algunas que ya estaban en GCN 1.1 y otras que no. Por ejemplo, logicamente el command procesor ya existía, pero tanto en polaris como en ONE se ha tocado. Seguramente también en GCN 1.2. El tema es que GCN 1.2 tampoco existía cuando xbox salio a la calle y que aun con eso, por ejemplo como tu has visto en los CUs, no existe aun una coincidencia total con lo que ya se ve el XBOX ONE.

Si quieres ayudar y aportar bienvenido.

Veo que sabes de esto, ¿serías capaz de explicar la disposición en los CU de la consola? No es un reto, te lo pregunto totalmente en serio.
@papatuelo en realidad eso ya lo dije hace tiempo. Con los modelos de cada vez mayor computación, veo que en el futuro mezclen render por polígonos con raytracing para "tapar" las vergüenzas del render poligonal en sus puntos flacos (esferas, fluidos, etc.) que al raytracing le van al dedo.
darksch escribió:@papatuelo en realidad eso ya lo dije hace tiempo. Con los modelos de cada vez mayor computación, veo que en el futuro mezclen render por polígonos con raytracing para "tapar" las vergüenzas del render poligonal en sus puntos flacos (esferas, fluidos, etc.) que al raytracing le van al dedo.


Además de que esta cantado, entre la demo RayTracing del laboratorio y que ya se dijo abiertamente en el GDC que era de XBOX y las noticias que salieron de que estaban consiguiendo cosas increible con ray tracing.
[url]
http://www.dualshockers.com/2014/04/08/ ... irectx-12/[/url]
http://isaac.gelado.cat/sites/isaac.gel ... ca2014.pdf

The main goal of this work is to enable fine-grained scheduling
of multiprogrammed workloads running on the GPU

Y ahora un texto de Urian (q no es muy santo de mi devoción pero q habla del tema):


El concepto del paralelismo de “grano fino” es la siguiente, tu puedes dividir el código en partes muy pequeñas para ser ejecutado en una gran cantidad de procesadores, este tipo de paralelismo tiene mucho sentido en las GPU actuales ya que tienen una enorme cantidad de núcleos funcionando (cientos de ellos) y unas memorias de las que ejecutan muy pequeñas (64KB cada 16 núcleos en el caso de las HD 7×00 de AMD). Pero la clave esta en que se refiere al cambio de contexto en un sistema gráfico, el cual es clave para una plataforma como la que estamos hablando. Algunos os preguntaréis como es que la patente habla de rendering por software y la respuesta tiene fácil solución, a medida que las GPU pueden ir haciendo funcionar código más complejo estamos viendo un retorno a la programación gráfica por software, esto significa el descarte total de las API y la posibilidad de usar lenguajes de alto nivel, sí antes he mencionado a Herb Sutter y su “Bienvenido a la Jungla” fue por su presentación del C++ AMP para sistemas heterogéneos en el AMD Fusion Developer Summit de 2011, la idea de programar en un lenguaje como C++ una GPU significa volver a los tiempos del “renderizado por software”

"La clave es que esta GPU es la única de AMD que permite dos cosas que definirán los videojuegos los años siguientes, lo primero es el “Software Rendering” que es el final de desarrollar los juegos a través de una API sino que se programarán directamente en un lenguaje de propósito general, el segundo es el del cambio de contexto, el motivo por el cual no se elegiría una GPU de una arquitectura anterior es por el hecho de que el paralelismo de “grano fino” requiere continuas lecturas mientras que las GPU anteriores de AMD usan arquitectura VLIW para disminuir el número de lecturas a memoria al máximo posible, algo que va en contra del paradigma que pretende Microsoft."


Recordad q el context switch es una característica de la GPU de Xbox One.
Szasz escribió:http://isaac.gelado.cat/sites/isaac.gelado.cat/files/publications/tanasic-isca2014.pdf

The main goal of this work is to enable fine-grained scheduling
of multiprogrammed workloads running on the GPU

Y ahora un texto de Urian (q no es muy santo de mi devoción pero q habla del tema):


El concepto del paralelismo de “grano fino” es la siguiente, tu puedes dividir el código en partes muy pequeñas para ser ejecutado en una gran cantidad de procesadores, este tipo de paralelismo tiene mucho sentido en las GPU actuales ya que tienen una enorme cantidad de núcleos funcionando (cientos de ellos) y unas memorias de las que ejecutan muy pequeñas (64KB cada 16 núcleos en el caso de las HD 7×00 de AMD). Pero la clave esta en que se refiere al cambio de contexto en un sistema gráfico, el cual es clave para una plataforma como la que estamos hablando. Algunos os preguntaréis como es que la patente habla de rendering por software y la respuesta tiene fácil solución, a medida que las GPU pueden ir haciendo funcionar código más complejo estamos viendo un retorno a la programación gráfica por software, esto significa el descarte total de las API y la posibilidad de usar lenguajes de alto nivel, sí antes he mencionado a Herb Sutter y su “Bienvenido a la Jungla” fue por su presentación del C++ AMP para sistemas heterogéneos en el AMD Fusion Developer Summit de 2011, la idea de programar en un lenguaje como C++ una GPU significa volver a los tiempos del “renderizado por software”

"La clave es que esta GPU es la única de AMD que permite dos cosas que definirán los videojuegos los años siguientes, lo primero es el “Software Rendering” que es el final de desarrollar los juegos a través de una API sino que se programarán directamente en un lenguaje de propósito general, el segundo es el del cambio de contexto, el motivo por el cual no se elegiría una GPU de una arquitectura anterior es por el hecho de que el paralelismo de “grano fino” requiere continuas lecturas mientras que las GPU anteriores de AMD usan arquitectura VLIW para disminuir el número de lecturas a memoria al máximo posible, algo que va en contra del paradigma que pretende Microsoft."


Recordad q el context switch es una característica de la GPU de Xbox One.


Ese lo puse hace muchisimo.

Dos cosas:
1) Presentado en el Isca 2014 durante la jornada que comenzaba con el keynote: Insight into the MICROSOFT XBOX ONE Technology. En la que participaron Dug Burguer (microsoft), Ian Spilinger (arquitecto xbox one) y otros compañeros de Spilinger en Israel.
2) El paper lo firma Mateo Valero entre otros, del centro que Microsoft tiene en Barcelona.

Urian antes estaba muy en linea con todo lo que se decía aquí, de la noche a la mañana le dio la vuelta a todo.
Sí, ese paper lo vi la primera vez gracias a ti. Complemento con otro, q es hacia donde debe ir la GPU next gen (software pipeline) y hacia donde va polaris:

http://graphics.stanford.edu/papers/gra ... -tog09.pdf


"This landscape of high-performance processors presents interesting choices for future rendering system architects. GPUs constitute a simple-to-use,heavily tuned platform for rasterization based real time rendering but offer only limited benefits for alternative graphics algorithms. Incontrast, increasingly parallel CPU - based throughput architectures offer the flexibility of CPU programming; nevertheless, implementing an advanced rendering system that leverages multicore, multithreaded, and SIMD processing is a daunting task."

"In general, streaming research has focused on intensive static compiler analysis to perform key optimizations like data prefetching, blocking, and scheduling of asynchronous data transfers and kernel execution. Static analysis works best for regular programs that exhibit predictable data access and tightly bounded numbers of kernel inputs and outputs"

"Irregular computations are difficult to statically schedule because program behavior is not known at compile time. Unfortunately, graphics pipelines contain irregular components, and standard offline stream compilation techniques are insufficient for high performance. "
Morepawer está baneado por "hater, flames y clones"
@papatuelo a @Shynobyn "¿serías capaz de explicar la disposición en los CU de la consola? No es un reto, te lo pregunto totalmente en serio."

Se ha esfumado!!! .Día 12 y no tenemos respuesta de Shynobin........
A ver esto ya es así desde hace tiempo, solo que es difícil de explicar. Desde que las GPU son programables, y le metes un programa, es software. El problema es que ya, indebidamente, se ha asociado GPU = hardware y CPU = software. Pues no, eso no es así. Tu ejecutas un programa en la GPU, igual que en la CPU, solo que cada una tiene unas características que la hacen buena en su propio campo. ¿Acaso ejecutar tareas en punto flotante con la FPU de la CPU no sería hardware igualmente que con las unidades de la GPU?, es exactamente igual, solo que tiene muchas menos.
Se podría decir, "entonces por qué cuando ejecuto esto va mucho más rápido si lo hago en la GPU, eso es hardware entonces". No, eso es ejecutar el software en la unidad que lo procesa más rápido, porque a la inversa también pasa, la CPU ejecuta cosas mucho más rápido que la GPU aún teniendo muchas menos unidades.

Por lo tanto, actualmente se podría decir que hardware es el disponer de unidades nativas para procesar la tarea en cuestión, y software si hay que usar otras no nativas. Un claro ejemplo es el punto flotante, si tienes FPU lo haces por hardware, ya tengas 1 o 50 unidades para ello, la diferencia es la velocidad con que lo harás, no el que lo hagas por software o hardware; y si no la tienes pues toca computarlo por software, usando unidades no preparadas para ello, por lo que usarás muchos más ciclos para hacer lo mismo.
Pero hoy en día, tanto a la CPU como a la GPU se les envía un programa que lo ejecutan, por lo tanto ambas están ejecutando software mediante sus unidades hardware.
darksch escribió:A ver esto ya es así desde hace tiempo, solo que es difícil de explicar. Desde que las GPU son programables, y le metes un programa, es software. El problema es que ya, indebidamente, se ha asociado GPU = hardware y CPU = software. Pues no, eso no es así. Tu ejecutas un programa en la GPU, igual que en la CPU, solo que cada una tiene unas características que la hacen buena en su propio campo. ¿Acaso ejecutar tareas en punto flotante con la FPU de la CPU no sería hardware igualmente que con las unidades de la GPU?, es exactamente igual, solo que tiene muchas menos.
Se podría decir, "entonces por qué cuando ejecuto esto va mucho más rápido si lo hago en la GPU, eso es hardware entonces". No, eso es ejecutar el software en la unidad que lo procesa más rápido, porque a la inversa también pasa, la CPU ejecuta cosas mucho más rápido que la GPU aún teniendo muchas menos unidades.

Por lo tanto, actualmente se podría decir que hardware es el disponer de unidades nativas para procesar la tarea en cuestión, y software si hay que usar otras no nativas. Un claro ejemplo es el punto flotante, si tienes FPU lo haces por hardware, ya tengas 1 o 50 unidades para ello, la diferencia es la velocidad con que lo harás, no el que lo hagas por software o hardware; y si no la tienes pues toca computarlo por software, usando unidades no preparadas para ello, por lo que usarás muchos más ciclos para hacer lo mismo.
Pero hoy en día, tanto a la CPU como a la GPU se les envía un programa que lo ejecutan, por lo tanto ambas están ejecutando software mediante sus unidades hardware.


Sí y no. Es así desde q tenemos GCN (otra cosa es q se utilice), pero hay algunas optimizaciones q se tienen q hacer, y por ahí es donde considero q irá polaris.

Ya no es cuestión de si se puede o no se puede hacer con GCN, sino cuanto eficiente es realizando paralelamente un algoritmo de ray tracing (por poner un ejemplo). Ese es el camino de la industria, correr paralelamente al juego diferentes algoritmos de GPGPU.

Si te fijas Ps4 ha seguido un camino diferente, pero el objetivo es el mismo. Ha reservado 4 CUs para GPGPU (si miramos su documentación es la misma Sony la q desaconseja utilizarlos para gfx). Nick Baker ya dijo q el camino de Sony le parecía correcto, pero q ellos habían apostado por otro, q no solo se reduce a meter más CUs. Decidieron aumentar la coherencia de las caches, retocar los CPs para aumentar el rendimiento CPU (instruction pre-fetch), coprocesadores, paginaciones virtuales, doble contexto.....etc, todo orientado a ser una máquina más HSA, más optimizada.

Esos retoques son parecidos a los q vendrán en polaris (algunos ya han venido con kaveri y carrizo). Polaris se supone q sera la arquitectura más optimizada de AMD (tmb tendrá q ver la reducción de proceso productivo, pero eso no nos afecta).

El hardware es el q es y los rops (por poner un ejemplo) no van aumentar, pero algunas tareas "fijas" q se hacian en las tuberías de renderizado se podrán realizar por otro lado (recuerdo decir a f5inet q los ROPs ya no serían tan importantes).
@Darksch @Szasz

Podrían haber tomado otra aproximación, un trabajo de un ingeniero del equipo de Ian Spilinger:

En el Isca 2014, recordad que ese día comenzaba con el Keynote: Insight into the MICROSOFT XBOX ONE Technology, debajo del paper de Valero sobre switch context (en el que usan gráficas Nvidia aunque ya se sabe que realmente es una tecnología también presente en XBOX ONE).

Imagen
Imagen
Imagen

The CUDA-compatible SGMF architecture is positioned as an energy efficient design alternative for GPGPUs.




Each SGMF core is composed of four types of units:a)compute units;b)load/store units;c)control units; andd)specialcompute units.


The compute unit is similar to an NvidiaFermi CUDA core. It comprises an arithmetical-logical unit(ALU) and a single-precision floating point unit (FPU).


La investigación entorno a los SGMF es de un investiador del equipo de Ian Spillinger, el mismo que dio la charla inicial ese día en el Isca..

Imagen

Y además por lo que se ve el uso de este sistema requiere de replantear el sistema de memorias.

Finally, we motivate further research into the design of theSGMF architecture, and specifically its memory system. Weshow how the raw energy efficiency of the SGMF architectureis hindered by the use of existing GPGPUs’ memory systems,which are tuned to the existing SIMT execution model ratherthan the SGMF model.
Bueno pero la velocidad no está relacionado con la capacidad. Un 486DX hace lo mismo que un 386DX en el mismo programa pero más rápido. No quiere decir que el 486DX lo haga por hardware y el 386DX por software.
papatuelo escribió:@Darksch @Szasz

Podrían haber tomado otra aproximación, un trabajo de un ingeniero del equipo de Ian Spilinger:

En el Isca 2014, recordad que ese día comenzaba con el Keynote: Insight into the MICROSOFT XBOX ONE Technology, debajo del paper de Valero sobre switch context (en el que usan gráficas Nvidia aunque ya se sabe que realmente es una tecnología también presente en XBOX ONE).

Imagen
Imagen
Imagen

The CUDA-compatible SGMF architecture is positioned as an energy efficient design alternative for GPGPUs.




Each SGMF core is composed of four types of units:a)compute units;b)load/store units;c)control units; andd)specialcompute units.


The compute unit is similar to an NvidiaFermi CUDA core. It comprises an arithmetical-logical unit(ALU) and a single-precision floating point unit (FPU).


La investigación entorno a los SGMF es de un investiador del equipo de Ian Spillinger, el mismo que dio la charla inicial ese día en el Isca..

Imagen

Y además por lo que se ve el uso de este sistema requiere de replantear el sistema de memorias.

Finally, we motivate further research into the design of theSGMF architecture, and specifically its memory system. Weshow how the raw energy efficiency of the SGMF architectureis hindered by the use of existing GPGPUs’ memory systems,which are tuned to the existing SIMT execution model ratherthan the SGMF model.


Sí, podrían haber cogido esa aproximación, es algo q es difícil de saber a ciencia cierta. Pero tengo claro q en esa dirección si q han trabajado.
Ambas versiones correrán a 60 frames por segundo pero, como el fundador de Kunos Simulazioni ya ha anunciado, la edición de PlayStation 4 contará con una resolución de 1080p y la de Xbox One con una de 900p.
"Hemos luchado mucho por tener Full HD también para Xbox One, pero no hemos encontrado modo de hacerlo", reconocía Marco Massarutto al portal británico Eurogamer. "Forza ha hecho un gran trabajo, pero ellos tienen librerías dedicadas. Pero insisto en que han hecho un gran trabajo, cuando jugué a su videojuego pensé `wow´, qué resultado han conseguido con los efectos gráficos".
Y que librerías dedicadas son esas ?
cercata escribió:Y que librerías dedicadas son esas ?


Según el SDK que hayan usado los de el Asetto Corsa.

La cosa es que Turn10 tiene gente y medios para crear ellos mismos funciones propias a bajo nivel y los del asetto son 27 personas.
cercata escribió:Y que librerías dedicadas son esas ?


Yo creo que basicamente se refiere a lo que hemos dicho muchas veces.

Las consolas ya no son tan close to metal como lo eran.

Los de asetto ya tienen en juego en DX11 y lo que se han dedicado a hacer es portar a GMNx y a la API de XBOX ONE, pero sin llegar a exprimir ni la una ni la otra.

Siempre lo digo, ultimamente la gente se infla a decir que las consolas son close to metal bla bla bla, pero al mismo tiempo cuando sale un multi los mismos llegan y dicen: el juego rinde igual que en una GPU equivalente de PC.

Imagen

Pues... o lo primero o lo segundo, las dos cosas son imposibles.
Eso me cuadra mas, que no hayan querido optimizarlo mucho, ya que optimizar sale bastante caro ...

Pq vamos, no tendría ningún sentido un API secreto que Microsoft no quiera dar a otros. Seguramente Turn10 haya tenido acceso anticipado a Mono y DX12 para probarlo, pero actualmente no creo que tengan nada que no tengan disponible los demas.
cercata escribió:Eso me cuadra mas, que no hayan querido optimizarlo mucho, ya que optimizar sale bastante caro ...

Pq vamos, no tendría ningún sentido un API secreto que Microsoft no quiera dar a otros. Seguramente Turn10 haya tenido acceso anticipado a Mono y DX12 para probarlo, pero actualmente no creo que tengan nada que no tengan disponible los demas.


Si no es cuestion de tener disponible o no.

Es sencillamente pensar en DX12.

¿ Con DX12 la consola tiraría mejor? Yo opino que indudablemente sí. Y no hay que buscar explicaciones esotéricas, hasta ahora los ports no sacan partido de las consolas xq son basicamente los mismo juegos que en PC y como mucho bajan algo de nivel con un par de extensiones y a correr.

Lo dijo bocachancla hace mucho tiempo, ¿puedo ir más bajo en consolas? Sí que puedo, si quieres me cojo y me pongo a hacer los juegos en ensamblador... Pero no lo voy a hacer, primero xq debo ser muy bueno y segundo xq tengo que hacer mínimo tres versiones diferentes.

DX12 no hará otra cosa que facilitar la vida a los desarrolladores para, que una vez que tienen la versión de PC, sacar más partido a las consolas.

Pero es que aun no lo hemos visto ni en PC, ese es el problema, y esto es algo que va a beneficiar a todos. A los que lo dijimos hace dos años y los que se han dedicado a llamar locos a los demás, los mismos que ahora se les hace el culo pesi-cola con Vulkan.

Saldrán nuevos motores además de las APIS y veremos un rendimiento más alto en todas las plataformas, PC, PS4 y XBOX ONE. Ya dijeron que de vulkan era mucho más facil portar a consolas y en DX12 es lo mismo.

Por cierto, parece que Hitman sí será DX12.

IO Interactive are hosting a panel at GDC titled “Rendering Hitman with DirectX 12,” something that Overclocked3D noticed. This seems to imply that the game was designed for DirectX 12- and indeed, the description for the panel seems to confirm as much, while also mentioning Vulkan.

“This talk will give a brief overview of how the Hitman Renderer works, followed by a deep dive into how we manage everything with DirectX 12, including Pipeline State Objects, Root Signatures, Resources, Command Queues and Multithreading,” the description reads,

“How to write a fast and efficient DirectX 12 / Vulkan engine, and how to use the new HW features to implement new graphics techniques. Learn from real shipping game developers experiences.”


http://gamingbolt.com/hitman-reportedly ... directx-12
DX12 es como directamente usar la API exclusiva desde el minuto 0. Otra cosa distinta es si sabes usarla o te lía tanto que delegas.
Ya, pero es que Forza 6 no es DX12 ? Ya veremos donde llega Forza 7, pero que yo sepa Forza 6 es Mono, y deberían poder llegar todos los estudios a ese nivel AHORA!! Digo ahora pq el API se liberó hace ya bastante.

papatuelo escribió:Lo dijo bocachancla hace mucho tiempo, ¿puedo ir más bajo en consolas? Sí que puedo, si quieres me cojo y me pongo a hacer los juegos en ensamblador... Pero no lo voy a hacer, primero xq debo ser muy bueno y segundo xq tengo que hacer mínimo tres versiones diferentes.

Ahí si que la clavó el bocachancla ... [tadoramo] [tadoramo]

De GPU no se, pero de CPU, aunque escribas en C/C++, si quieres optimizar de verdad, tienes que conocer bien el hardware que hay por debajo, y como traduce a ensamblador el compilador, y eso lo hacen muy pocos programadores, aunque en el mundo de videojuegos AAA, el porcentaje de programadores que lo hacen imagino que será bastante alto.

Los de Kunos Simulazioni no se si no son lo bastante buenos, o que no tienen recursos, pero yo no me esperaría gran cosa de ellos, Asseto Corsa en mi PC ni arranca la partida ... :(
cercata escribió:Ya, pero es que Forza 6 no es DX12 ? Ya veremos donde llega Forza 7, pero que yo sepa Forza 6 es Mono, y deberían poder llegar todos los estudios a ese nivel AHORA!! Digo ahora pq el API se liberó hace ya bastante.

papatuelo escribió:Lo dijo bocachancla hace mucho tiempo, ¿puedo ir más bajo en consolas? Sí que puedo, si quieres me cojo y me pongo a hacer los juegos en ensamblador... Pero no lo voy a hacer, primero xq debo ser muy bueno y segundo xq tengo que hacer mínimo tres versiones diferentes.

Ahí si que la clavó el bocachancla ... [tadoramo] [tadoramo]

De GPU no se, pero de CPU, aunque escribas en C/C++, si quieres optimizar de verdad, tienes que conocer bien el hardware que hay por debajo, y como traduce a ensamblador el compilador, y eso lo hacen muy pocos programadores, aunque en el mundo de videojuegos AAA, el porcentaje de programadores que lo hacen imagino que será bastante alto.

Los de Kunos Simulazioni no se si no son lo bastante buenos, o que no tienen recursos, pero yo no me esperaría gran cosa de ellos, Asseto Corsa en mi PC ni arranca la partida ... :(


Forza no es DX12, pero es exclusivo hecho por un equipo que ha colaborado en el desarrollo de la máquina. Lo que debería conseguir DX12 es que los dev sean capaces de hacer lo que hace Turn10, pero sin esfuerzo.
papatuelo escribió:Forza no es DX12, pero es exclusivo hecho por un equipo que ha colaborado en el desarrollo de la máquina. Lo que debería conseguir DX12 es que los dev sean capaces de hacer lo que hace Turn10, pero sin esfuerzo.

Mas que sin esfuerzo, sin mucho esfuerzo, que hacer un juego cañero en cualquier plataforma no es moco de pavo, pero sí :P

La verdad es que la facilidad para programar una plataforma la subestiman muchos arquitectos, ya pasó con Kutaragi, que como con PS2 le salió bien la jugada por suerte, con PS3 fue aun mas lejos, y le paso factura ...

Con DX12, han hecho alguna librería/biblioteca nueva para facilitar el uso de ESRAM ? Pq ese es el talón de aquiles de la ONE, como no uses bien la ESRAM, pierdes una burrada de rendimiento gráfico. Yo lo ultimo que lei es que habían sacado un profiler para la ESRAM, que te permite monitorizarlo mejor.

Con suerte la versión DX12 de Unreal y Cryengine gestionaran ya la ESRAM, de forma que los programadores mediocres o que no tengan tiempo, obtengan ya resultados bastante buenos.
Aun sin conocer la mitad de conceptos que se tratan en este hilo, a mí lo que me parece es que una desarrolladora que tiene el juego desarrollado el juego para PC en directx 11 (todo lo que ha salido hasta hoy día 22/01/2016 y la One salió el 22/11/2013, más de dos años), tiene por ejemplo 1000 horas para hacer el port a consolas, en ese caso si repartes 500 horas en One y 500 horas en la otra, la otra saca mejor resultado... normalmente 900p vs 1080p.

¿Esto significa que la One no puede llegar a 1080p? EVIDENTEMENTE NO! pero ¿porque van a destinar más horas en One que en la otra, si 900p ya se ve bien y además la otra y parqué de consolas superior?

¿Esto es un problema de Microsoft o de la desarrolladora? bajo mi punto de vista Microsoft apostó por una tecnología de futuro con una potencia un poco justa cuando creo que debería haber sacado una máquina que permitiera al desarrollador sacar provecho desde el minuto 0.

Yo soy el primero que cree que directx 12 mejorará el rendimiento, pero ¿cuando? ¿cuando la consola ya lleve más de la mitad de su vida comercial? Igual le habría salido muchísimo más barato a Micro una máquina con 2tflops compatible con DX11 y DX12, sin tanta virguería pero que se sacara el máximo provecho desde el primer momento...
cercata escribió:
papatuelo escribió:Forza no es DX12, pero es exclusivo hecho por un equipo que ha colaborado en el desarrollo de la máquina. Lo que debería conseguir DX12 es que los dev sean capaces de hacer lo que hace Turn10, pero sin esfuerzo.

Mas que sin esfuerzo, sin mucho esfuerzo, que hacer un juego cañero en cualquier plataforma no es moco de pavo, pero sí :P

La verdad es que la facilidad para programar una plataforma la subestiman muchos arquitectos, ya pasó con Kutaragi, que como con PS2 le salió bien la jugada por suerte, con PS3 fue aun mas lejos, y le paso factura ...

Con DX12, han hecho alguna librería/biblioteca nueva para facilitar el uso de ESRAM ? Pq ese es el talón de aquiles de la ONE, como no uses bien la ESRAM, pierdes una burrada de rendimiento gráfico. Yo lo ultimo que lei es que habían sacado un profiler para la ESRAM, que te permite monitorizarlo mejor.

Con suerte la versión DX12 de Unreal y Cryengine gestionaran ya la ESRAM, de forma que los programadores mediocres o que no tengan tiempo, obtengan ya resultados bastante buenos.


Aquí tienes una entrevista del bocachancla donde habla de todo esto.

https://youtu.be/47cnFWK0dRM

Habla de todo lo que acabamos de hablar y dice lo de que fue decisión de marketing decir que DX12 "solo" aumentaba el rendimiento en un 40%.
cercata escribió:Ya, pero es que Forza 6 no es DX12 ? Ya veremos donde llega Forza 7, pero que yo sepa Forza 6 es Mono, y deberían poder llegar todos los estudios a ese nivel AHORA!! Digo ahora pq el API se liberó hace ya bastante.

Es DX11 + exclusive API, como ya fue Forza 5. La API exclusiva es algo que la mayoría, y multis ninguno diría yo, no tienen precisamente mucha gana de meterle mano, por ser más complicado y, sobre todo, específico de una plataforma, no rentable. Forza entre que es un estudio interno y que sólo va a salir en esa plataforma, tenía las manos libres.
De ahí las "quejas" de que Turn10 disponen de recursos que ellos no. Y es comprensible, no es que no lo tengan disponible, es que no les renta usarlo tal y como está ahora mismo planteado su uso.

DX12 desde el principio es usar la máquina desde su base, y con una API multiplataforma. Ahí ya sí deberían meterle mano todos.
darksch escribió:
cercata escribió:Ya, pero es que Forza 6 no es DX12 ? Ya veremos donde llega Forza 7, pero que yo sepa Forza 6 es Mono, y deberían poder llegar todos los estudios a ese nivel AHORA!! Digo ahora pq el API se liberó hace ya bastante.

Es DX11 + exclusive API, como ya fue Forza 5. La API exclusiva es algo que la mayoría, y multis ninguno diría yo, no tienen precisamente mucha gana de meterle mano, por ser más complicado y, sobre todo, específico de una plataforma, no rentable. Forza entre que es un estudio interno y que sólo va a salir en esa plataforma, tenía las manos libres.
De ahí las "quejas" de que Turn10 disponen de recursos que ellos no. Y es comprensible, no es que no lo tengan disponible, es que no les renta usarlo tal y como está ahora mismo planteado su uso.

DX12 desde el principio es usar la máquina desde su base, y con una API multiplataforma. Ahí ya sí deberían meterle mano todos.


Tengo una pregunta.

¿Qué es compute-shader based screen space ambient occlusion?

Sé que es SSAO, pero que añade ese compute-shader??? Porque como tal no lo encuentro por internet.
papatuelo escribió:Tengo una pregunta.

¿Qué es compute-shader based screen space ambient occlusion?

Sé que es SSAO, pero que añade ese compute-shader??? Porque como tal no lo encuentro por internet.

Por ese nombre diría que es usar la computación para la oclusión. Acorde a ir aligerando el trabajo del render que por la limitación de unidades necesarias para render dejan una parte de las CUs sin usar. En no mucho tiempo diría que buena parte, o al menos cierta parte, de lo que se ve en pantalla recaerá en computación. Así no estarás tan limitado por aspectos como ROPs, texture units, etc. que "estrangulan" a la capacidad total de las CUs montadas.
darksch escribió:
papatuelo escribió:Tengo una pregunta.

¿Qué es compute-shader based screen space ambient occlusion?

Sé que es SSAO, pero que añade ese compute-shader??? Porque como tal no lo encuentro por internet.

Por ese nombre diría que es usar la computación para la oclusión. Acorde a ir aligerando el trabajo del render que por la limitación de unidades necesarias para render dejan una parte de las CUs sin usar. En no mucho tiempo diría que buena parte, o al menos cierta parte, de lo que se ve en pantalla recaerá en computación. Así no estarás tan limitado por aspectos como ROPs, texture units, etc. que "estrangulan" a la capacidad total de las CUs montadas.


Eso es, el GPU compute es hacía donde va la industria. Por eso tmb es esencial Dx12 y dejar un poco atras las técnicas antiguas q tiraban de unidades fijas (ROPs...etc).

El Local cloud del q habló Phil.

Quantum Break en Xbox One y Tomorrow Children de Ps4 serán buenos ejemplos de lo q esta por venir.
cercata escribió:
papatuelo escribió:Forza no es DX12, pero es exclusivo hecho por un equipo que ha colaborado en el desarrollo de la máquina. Lo que debería conseguir DX12 es que los dev sean capaces de hacer lo que hace Turn10, pero sin esfuerzo.

Mas que sin esfuerzo, sin mucho esfuerzo, que hacer un juego cañero en cualquier plataforma no es moco de pavo, pero sí :P

La verdad es que la facilidad para programar una plataforma la subestiman muchos arquitectos, ya pasó con Kutaragi, que como con PS2 le salió bien la jugada por suerte, con PS3 fue aun mas lejos, y le paso factura ...

Con DX12, han hecho alguna librería/biblioteca nueva para facilitar el uso de ESRAM ? Pq ese es el talón de aquiles de la ONE, como no uses bien la ESRAM, pierdes una burrada de rendimiento gráfico. Yo lo ultimo que lei es que habían sacado un profiler para la ESRAM, que te permite monitorizarlo mejor.

Con suerte la versión DX12 de Unreal y Cryengine gestionaran ya la ESRAM, de forma que los programadores mediocres o que no tengan tiempo, obtengan ya resultados bastante buenos.


“It’s completely different but you are going to get a substantial benefit. The part I think that users will care about is that it should address the resolution stuff for most people. That’s what I think is the most glaring thing that people are upset about. But it won’t do anything magically. The developers still have to use it, it’s not like your old games will magically be faster.”

“Yeah, it should do that [on resolving the resolution issues due to eSRAM], because in DirectX11 it’s really a pain to make good use of the eSRAM. Where as supposedly in DirectX12 and this is all theory, I haven’t used it myself but the new API is supposed to make it alot easier to optimize your use of the eSRAM memory.

“The API is there for me to use as a tool for the piece of hardware. And the one that was in DirectX11 was not easy, it was a very trial and error process to make use of the eSRAM. In DirectX12 they’ve tried to make it easier to make use with and the easier it is to use, the more likely you’re going to get developers who optimize for it correctly.”


http://wccftech.com/dx12-alleviate-xbox ... on-issues/
Pos eso, lo que llevo diciendo mucho tiempo :)
darksch escribió:Pos eso, lo que llevo diciendo mucho tiempo :)



¿El que?
Pues que es muy distinto y que no se usa solo. Por lo que mencionar de un tanto de mejora es hablar por hablar, normal que Phil fuera reticente a dar dicho dato. Es otra forma de trabajar y punto, que permite acceder a todo el potencial de la máquina de forma manual, y cada cual le sacará el provecho que sepa.

Y los juegos DX11 con "DX12 añadido", puro marketing. Que quede claro que no se pueden mezclar DX11 y DX12, no puedes mezclar trozos con DX12 como se quiere dar a entender muchas veces. Son tan distintos desde su base que para usar DX12 requiere que esté completamente escrito en DX12, ya que cambia desde los procedimientos básicos como enviar comandos a la GPU y su sincronización.
Por lo tanto, estos juegos lo que usan son las características DX12 desbloqueadas en DX11, o dicho de otra forma, usan el famoso DX11.3+, que aunque use características disponibles en DX12, se siguen usando de la manera al estilo DX11, y esta es con su gestión interna automatizada por parte de la API.
Que es eso de que xbox one y ps4 han desbloqueado un 7 nucleo de la consola?
Es un pegote o es verdad
juan66bcn escribió:Que es eso de que xbox one y ps4 han desbloqueado un 7 nucleo de la consola?
Es un pegote o es verdad


Es verdad. Tenían 2 núcleos reservados para el SO, ahora solo 1.
Y eso en que lo notaremos nosotros?
Así que la gpu de XBOX ONE es un nucleo GCN 1.1 (Bonaire/Tobago) con 768 SP, pero con un chapuza de sistema de memoria, eSRam+DDR3 en lugar de GDDR5.

Vamos que la Grafica de ONE es está pero encima con peor sistema de memoría y con un 21% menos de rendimiento 1.6 Tflos (121%) vs 1.33 (100%):

Imagen

Imagen

Imagen


Pues el Tomb Raider esta optimizado de pelotas:

First and foremost, the venerable DF budget PC with an i3 processor and GTX 750 Ti finally met its match with Rise of the Tomb Raider. Running with settings similar to Xbox One, we found that testing areas saw the game turn in frame-rates between 13 and 25fps. In comparison, the AMD test featuring an R7 360 fared even worse with performance numbers dropping all the way into the single digits at these settings.
papatuelo escribió:Así que la gpu de XBOX ONE es un nucleo GCN 1.1 (Bonaire/Tobago) con 768 SP, pero con un chapuza de sistema de memoria, eSRam+DDR3 en lugar de GDDR5.

Vamos que la Grafica de ONE es está pero encima con peor sistema de memoría y con un 21% menos de rendimiento 1.6 Tflos (121%) vs 1.33 (100%):

Imagen

Imagen

Imagen


Pues el Tomb Raider esta optimizado de pelotas:

First and foremost, the venerable DF budget PC with an i3 processor and GTX 750 Ti finally met its match with Rise of the Tomb Raider. Running with settings similar to Xbox One, we found that testing areas saw the game turn in frame-rates between 13 and 25fps. In comparison, the AMD test featuring an R7 360 fared even worse with performance numbers dropping all the way into the single digits at these settings.



Para que veamos todos , que no es solo potencia gráfica , sino también que este todo bien optimizado y programado
A ver cuando enseñan gameplay de Gears 4. Con el motor Unreal 4, dedicándose en exclusiva a One y en D12. Ese será un buen baremo de lo que es capaz realmente la consola.
Pero vamos a ver, que la potencia bruta ya no indica nada. De "chapuza" nada [carcajad]

Si esos son los resultados del RoTR demuestra que lo que quiere renderizar es bastante exigente.

Por cierto, esos consumos tienen truco además. La GPU R7 360 consume 100W ella sola, añade ahora una CPU, lo que no dice ahí es que el de la XOne son 95W incluyendo a la CPU, porque todo el sistema sin Kinect consume 105W.
darksch escribió:Pero vamos a ver, que la potencia bruta ya no indica nada. De "chapuza" nada [carcajad]

Si esos son los resultados del RoTR demuestra que lo que quiere renderizar es bastante exigente.

Por cierto, esos consumos tienen truco además. La GPU R7 360 consume 100W ella sola, añade ahora una CPU, lo que no dice ahí es que el de la XOne son 95W incluyendo a la CPU, porque todo el sistema sin Kinect consume 105W.


Eso del consumo es bastante curioso. En la pegatina debajo de mi One pone q el consumo es de 180W cuando esta a full.
Szasz escribió:
darksch escribió:Pero vamos a ver, que la potencia bruta ya no indica nada. De "chapuza" nada [carcajad]

Si esos son los resultados del RoTR demuestra que lo que quiere renderizar es bastante exigente.

Por cierto, esos consumos tienen truco además. La GPU R7 360 consume 100W ella sola, añade ahora una CPU, lo que no dice ahí es que el de la XOne son 95W incluyendo a la CPU, porque todo el sistema sin Kinect consume 105W.


Eso del consumo es bastante curioso. En la pegatina debajo de mi One pone q el consumo es de 180W cuando esta a full.

Será por cubrirse las espaldas e ir acorde con el alimentador. Medido con un medidor de consumo, 105W (con algún pico a 110) sin Kinect y 120W con éste durante un juego.
Szasz escribió:
darksch escribió:Pero vamos a ver, que la potencia bruta ya no indica nada. De "chapuza" nada [carcajad]

Si esos son los resultados del RoTR demuestra que lo que quiere renderizar es bastante exigente.

Por cierto, esos consumos tienen truco además. La GPU R7 360 consume 100W ella sola, añade ahora una CPU, lo que no dice ahí es que el de la XOne son 95W incluyendo a la CPU, porque todo el sistema sin Kinect consume 105W.


Eso del consumo es bastante curioso. En la pegatina debajo de mi One pone q el consumo es de 180W cuando esta a full.


Es fácil que con DX12 aumente su consumo, su temperatura y su sonoridad.
darksch escribió:
Szasz escribió:
darksch escribió:Pero vamos a ver, que la potencia bruta ya no indica nada. De "chapuza" nada [carcajad]

Si esos son los resultados del RoTR demuestra que lo que quiere renderizar es bastante exigente.

Por cierto, esos consumos tienen truco además. La GPU R7 360 consume 100W ella sola, añade ahora una CPU, lo que no dice ahí es que el de la XOne son 95W incluyendo a la CPU, porque todo el sistema sin Kinect consume 105W.


Eso del consumo es bastante curioso. En la pegatina debajo de mi One pone q el consumo es de 180W cuando esta a full.

Será por cubrirse las espaldas e ir acorde con el alimentador. Medido con un medidor de consumo, 105W (con algún pico a 110) sin Kinect y 120W con éste durante un juego.


Lo has medido tu Darksch???

Por alguna casualidad no tendrás el Tomb Raider y podrás medir el consumo cuando entra interiores con la antorcha y todo eso.???
papatuelo escribió:Lo has medido tu Darksch???

Por alguna casualidad no tendrás el Tomb Raider y podrás medir el consumo cuando entra interiores con la antorcha y todo eso.???

Sí lo medí yo mismo. El RoTR no lo tengo. Lo medí con el Forza 5 que en aquella época le metía caña a la máquina. Pero vamos, el consumo es el mismo con cualquier juego, creo que cuando entra en modo juego se pone en modo de energía alto rendimiento (lo que sería en PC) y a tope. Luego ya lo que se caliente por más o menos caña internamente es otra cosa, pero el consumo poco poco varía de un juego a otro.
darksch escribió:
papatuelo escribió:Lo has medido tu Darksch???

Por alguna casualidad no tendrás el Tomb Raider y podrás medir el consumo cuando entra interiores con la antorcha y todo eso.???

Sí lo medí yo mismo. El RoTR no lo tengo. Lo medí con el Forza 5 que en aquella época le metía caña a la máquina. Pero vamos, el consumo es el mismo con cualquier juego, creo que cuando entra en modo juego se pone en modo de energía alto rendimiento (lo que sería en PC) y a tope. Luego ya lo que se caliente por más o menos caña internamente es otra cosa, pero el consumo poco poco varía de un juego a otro.


Pero si no me equivoco, en ese juego y sobre todo en interiores esta usando asincrono, el consumo creo debería aumentar.

En contra de lo que la gente cree lo que más está pidiendo en ese juego son los interiores de las tumbas y las criptas, ahí es imposble que one mantuviera el tipo si no hace nada y más teniendo en cuenta que en ciertas ocasiones, no siempre, la ilumincación en one es más potente y en PC se desactivan cosas incluso en very high.

Estoy leyendo gente que iba tan feliz a 2K/60 con su 980 (very high) y al llegar a la tumba del barco han llegado a tener caidas a 38 frames a 1080p.

Yo diría que eso es por la iluminación que en ONE corre en asincrono.
Si ya, al igual que será en QB y Fable Legends lo más seguro. Por fin se está produciendo la migración y parece ser ya no tanto eso de "el hardware es el que es". Cuando se use DX12 nativo (desde 0) se liberará más CPU entre otras cosas aún.
17587 respuestas