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?
Por otro lado segun la diapositiva de Dx12_1, son features soportadas por hardware. Lo dice claramente.
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
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.
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.
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.
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.
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.
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).
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.
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).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..
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.
"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".
cercata escribió:Y que librerías dedicadas son esas ?
cercata escribió:Y que librerías dedicadas son esas ?
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.
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.”
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.
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 ...
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 ...
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.
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í
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.
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.
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.
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.
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.
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í
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.”
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
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%):
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.
darksch escribió:Pero vamos a ver, que la potencia bruta ya no indica nada. De "chapuza" nada
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.
Szasz escribió:darksch escribió:Pero vamos a ver, que la potencia bruta ya no indica nada. De "chapuza" nada
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
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.
darksch escribió:Szasz escribió:darksch escribió:Pero vamos a ver, que la potencia bruta ya no indica nada. De "chapuza" nada
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.
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.???
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.