ikergarcia1996
Nuevo
- Registrado
- 8 Dic 2014
- Mensajes
- 30
- Puntos
- 0
- Edad
- 28
Como mi anterior post sobre por que AMD mejora más que Nvidia en DX12 y Vulkan os gustó, he decidido realizar otro hablando del cómputo asíncrono, algo de lo que hay más desinformación si cabe.
Si leísteis el anterior post os lo dejo por aquí: ¿Por que AMD gana más rendimiento que Nvidia en directX12?
Para los que os da pereza leer tochacos, aquí os dejo la versión audiovisual :guiño:
----------------------------------------------------------------------------------------------
Empezamos por ¿Qué es el cómputo asíncrono? Esta imagen de AMD lo resume a la perfección, se trata de llenar “huecos”. En DX11 las colas se iban procesando de una en una, como si tuviéramos un semáforo que iba diciendo que cola se iba a ejecutar en cada momento. Durante la ejecución de por ejemplo una cola gráfica nos encontramos con momentos en los que algunas unidades de procesamiento de la gráfica se quedan paradas ¿Qué hace el cómputo asíncrono? Dar trabajo a esas unidades de procesamiento ¿Por qué no ponerlas a realizar tareas de otra cola mientras están paradas para adelantar trabajo?
Gráficas GCN de AMD
Vamos a empezar hablando por las gráficas con arquitectura GCN de AMD. En GCN cada unidad de cómputo (a partir de ahora CU) se compone de 64 shaders, estas unidades de cómputo tienen la peculiaridad de poder pasar de un proceso a otro de forma extremadamente rápida gracias a un hardware dedicado. Las gráficas AMD cuentan con un procesador de comandos gráficos, este tiene acceso a toda la gráfica y como su nombre indica se encarga de las colas de comandos gráficos, además cuentan con varios ACEs (Asynchronous Compute Engines) que traban en paralelo con el procesador de comandos gráficos, estos pueden encargarse de hasta 8 colas de cómputo y solo tienen acceso a las shaders de la gráfica. En resumen, ahora tenemos varias colas de comandos para “dar de comer a CU”
Para entender cómo funciona vamos a poner un ejemplo muy sencillo, tenemos una tarea que a una CU le cuesta 10ms realizar, pero durante esa tarea, la CU va a estar parada desde el milisegundo 4 al el milisegundo 9 por que la tarea tiene algún tipo de dependencia externa y tiene que esperar a los datos. Lo que ocurrirá en la arquitectura GCN de AMD, es que la tarea se detendrá, los datos pasarán a una memoria caché, y la CU recibirá una tarea de computo de la cola, que completa en 3ms, luego volverá a la tarea anterior y la terminará. Por lo tanto en vez de ejecutar solo la primera tarea en 10ms, hemos ejecutado dos tareas en ese mismo tiempo.
Dominio del paint extremo xD
Gráficas NVIDIA
En el caso de Nvidia tenemos Streaming multiprocesors a partir de ahora SM, que se conforman de un número determinado de Cuda cores, Cuda cores es el nombre “guay” que pone Nvidia a sus shaders o stream processors, en el caso de maxwell 128 en el caso de Pascal 64.
Vamos a ver cómo funcionan con el mismo ejemplo de antes, tenemos una tarea gráfica que a una SM le cuesta 10ms y otra de cómputo que le cuesta realizar 3ms. Además vamos a suponer que nuestra gráfica tiene 10SMs
Ahora bien, con el fin de recortar el tiempo que tardamos en realizar estas tareas, vamos a asignar 8 SM a la tarea gráfica y 2 SM a la tarea de cómputo. Ahora la tarea gráfica se termina en 1.25ms y la tarea de cómputo en 1.5ms. Vamos a diferenciar lo que ocurre en la arquitectura Maxwell y en la arquitectura Pascal.
En Maxwell la tarea gráfica terminará y esas 8 SM se quedarán paradas 0.25ms hasta que las otras 2 SM terminen, ya que no podemos reasignar las SM dentro de los límites de una llamada de dibujado, tampoco podemos iniciar una nueva tarea hasta que ambas colas estén terminadas. ¿Soporta Maxwell el computo asíncrono? En la teoría si, en la práctica no, como veis, utilizar el cómputo asíncrono en Maxwell nos expone a poder desbalancear la carga y dejar parte de las SM inactivas. Para ser capaces de utilizar el computo asíncrono en Maxwell deberíamos ser capaces de determinar las particiones antes de la ejecución, además, solo nos beneficiaríamos del cómputo asíncrono si tenemos “huecos que llenar”, la arquitectura Maxwell es muy eficiente y en la mayoría de casos las tareas gráficas ya van a ser capaces de estresar las 10SM de nuestra gráfica imaginaria, así que tendremos pocos huecos y por lo tanto el beneficio que ganaremos del cómputo asíncrono será mínimo. Debido a que es extremadamente difícil de hacer funcionar y proporciona unos beneficios muy reducidos, el cómputo asíncrono fue deshabilitado en gráficas Maxwell.
En Pascal estos límites desaparecen con el llamado "dynamic load balancing", ahora si las colas finalizan de forma desbalanceada el driver junto con el scheduler (planificador de tareas de la gpu) son capaces de proporcionar trabajo de otras colas a las SM que han quedado inactivas.
Y aunque en la práctica esto debería proporcionar un gran aumento de rendimiento, solo funciona si encontramos “huecos” que rellenar, y eso en gráficas Nvidia es complicado debido a la optimización de la arquitectura, hablaremos de ello a continuación.
Vamos primero a ver unas imágenes para demostrar lo de arriba, están sacadas de la web de 3dmark. Se han probado 3 gráficas, la Fury, la 970 y la 1080 y se han analizado con el software GPU view que nos permite analizar cómo está trabajando DirectX. No vamos a profundizar en estas imágenes porque es un software muy complicado, pero vamos a fijarnos en lo básico, en el caso de la 970 solo una de las colas tiene carga, por lo tanto, no hay ningún tipo de cómputo asíncrono funcionando, en el caso de la 1080 y la Fury existe trabajo en la cola de computo, es decir, están haciendo uso del cómputo asíncrono.
GTX 970
GTX 1080
R9 Fury
La implementación de AMD se llama async shaders, y las gráficas Nvidia no son capaces de realizar eso. En Nvidia no existe la posibilidad de que cuando una tarea gráfica se detiene, la SM pase a realizar una tarea de cómputo y luego vuelva a la tarea gráfica original, debido a que ese cambio de contexto sería muy lento al no contar con hardware dedicado, pero si existe la posibilidad de que una SM que ha terminado su trabajo pase a realizar trabajo de otra cola.
Entonces ¿Cuál es mejor? Podríamos decir que las async shaders de AMD porque son más completas y ofrecen más posibilidades, pero no es tan simple, depende de la arquitectura, pongamos un ejemplo basado en la vida real, yo tengo un Ferrari que coje 300km/h y un Ford fiesta que coge 120km/h, el Ferrari corre mucho más, pero ¿me sirve de algo si voy por una carretera limitada a 80km/h? El Ferrari es la ostia, pero, si estoy limitado a 80km/h igual me renta más usar el Ford fiesta que consume menos gasolina. Aquí pasa exactamente lo mismo.
En el caso de las gráficas AMD existen muchos huecos que rellenar, en gran parte porque son malas en tareas geométricas, el procesador geométrico de las gráficas AMD no es capaz de dar trabajo a todas las shaders, provocando grandes “huecos” durante la ejecución de la cola gráfica que podemos rellenar.
En este benchmark podemos comprobarlo.
Este problema no lo sufren las gráficas Nvidia, las tareas gráficas son capaces de aprovechar todas las SM, por lo tanto apenas nos van a quedar huecos que rellenar y el beneficio que vamos a tener es mínimo.
Si Nvidia incluyera el mismo hardware que AMD para realizar el cómputo asíncrono el beneficio sería mucho menor, ya que apenas tienen “huecos” que rellenar debido a que su arquitectura es más eficiente, además las gráficas Nvidia cuentan con menos shaders que las gráficas AMD aunque estas van a velocidades mucho más altas, por ejemplo en la GTX 1060 tenemos 1280 cuda cores a que con el boost 3.0 trabajan a casi 2Ghz y en la RX 480 tenemos 2304 a 1,26Ghz, haciendo que encontrar SM sin trabajo sea aún mucho más complicado que en gráficas AMD. Incluir ese hardware no es gratis, consume y ocupa espacio, por lo tanto para un beneficio muy reducido, a Nvidia no le sale rentable añadirlo, ese espacio pueden usarlo para añadir más cuda cores y hacer gráficas más potentes o simplemente ahorrárselo para hacer un chip más pequeño y eficiente, de hecho, una de las razones por las que las gráficas Nvidia son muy superiores a las AMD en rendimiento / wattio es esta. Es decir, a Nvidia le sale más rentable no incluirlas que incluirlas, ya que supondría subir el consumo y aumentar el tamaño del chip (con el coste económico que eso conlleva), para una ganancia de rendimiento bastante pequeña, además con el balance de cargas ya ganan lo suficiente para no tener una gran desventaja respecto a AMD, es decir, las gráficas AMD ganan más con el computo asíncrono pero la diferencia, por ejemplo en la gráfica de time spy anterior entre la FuryX y la GTX 1080, es de un 6%, es decir, si un juego me va a 50fps son 3 fps extra que voy a tener en la FuryX al usar el computo asíncron,o algo prácticamente imposible de apreciar.
En resumen, no hay una implementación mejor y otra peor, hay una implementación para cada necesidad. ¿Añadirá Nvidia en gráficas futuras las async shaders? Todo depende de lo que vayan a conseguir con ello, es sencillo, si lo que ganan va a ser mayor que lo que pierden las añadirán si no, no. Seguramente las añadirán cuando tengan gráficas con muchos más cuda cores que las actuales dentro de varios años y cuando DX12 y el computo asíncrono estén mucho más asentados, igual que lo que hicieron con DX11, las gráficas Nvidia fueron durante mucho tiempo inferiores a las AMD en DX11, pero cuando DX11 se comenzó a estandarizar y a tomar importancia, lanzaron nuevas gráficas que eran incluso mejores que las AMD bajo esta API, al final es una forma de ganar dinero también, ya que haciendo esto haces que la gente actualice a tus últimas gráficas para tener el mejor rendimiento posible en la última API y que no se queden durante años con gráficas antiguas.
La conclusión del post podría ser la misma que la del anterior, la mejora de AMD proviene en gran parte de las ineficiencias existentes en DX11, sus gráficas ahora pueden sacar todo su potencial y rendir acorde a sus especificaciones, mientras que las gráficas Nvidia se quedan prácticamente igual porque bajo DX11 ya eran muy eficientes. La FuryX es un buen ejemplo, 4096 shaders y 8.6 teraflops que se veían superados por los 2816 cuda cores y 5.6 teraflops de la 980ti. Evidentemente son arquitecturas muy diferentes y no vamos a ver a la FuryX rendir el doble que la 980ti, pero sí que estamos viendo que mientras en DX11 la 980ti gana en prácticamente todas las pruebas, bajo DX12 la FuryX rinde más que la 980ti.
Por último quiero hacer una pequeña mención a la realidad virtual, porque de eso va a tratar el próximo post que tengo en mente, la implementación de AMD tiene una pega y son las tareas de alta prioridad, han incluido colas de alta prioridad pero no funcionan tan bien como en la teoría, las tareas críticas como los async warps en realidad cirtual no se realizan lo suficientemente rápido, Nvidia en cambio, ha introducido un sistema que permite parar en seco la ejecución de una tarea y realizar la tarea crítica. Esto hace a las gráficas Nvidia mucho mejores para realidad virtual, pero de eso hablaremos más adelante en detalle: D
Y hasta aquí el post, como en el anterior he intentado informarme lo máximo posible y hacerlo el post lo más imporcial posible, cualquier cosa que creáis que esta mal (habrá muchas xD) mencionarla en los comentarios para corregirla
Zona spam: Si os han gustado los dos post que he hecho sobre las nuevas APIs podeís pasaros por aquí -> https://www.youtube.com/hardware360grados
Si leísteis el anterior post os lo dejo por aquí: ¿Por que AMD gana más rendimiento que Nvidia en directX12?
Para los que os da pereza leer tochacos, aquí os dejo la versión audiovisual :guiño:
----------------------------------------------------------------------------------------------
Empezamos por ¿Qué es el cómputo asíncrono? Esta imagen de AMD lo resume a la perfección, se trata de llenar “huecos”. En DX11 las colas se iban procesando de una en una, como si tuviéramos un semáforo que iba diciendo que cola se iba a ejecutar en cada momento. Durante la ejecución de por ejemplo una cola gráfica nos encontramos con momentos en los que algunas unidades de procesamiento de la gráfica se quedan paradas ¿Qué hace el cómputo asíncrono? Dar trabajo a esas unidades de procesamiento ¿Por qué no ponerlas a realizar tareas de otra cola mientras están paradas para adelantar trabajo?
Gráficas GCN de AMD
Vamos a empezar hablando por las gráficas con arquitectura GCN de AMD. En GCN cada unidad de cómputo (a partir de ahora CU) se compone de 64 shaders, estas unidades de cómputo tienen la peculiaridad de poder pasar de un proceso a otro de forma extremadamente rápida gracias a un hardware dedicado. Las gráficas AMD cuentan con un procesador de comandos gráficos, este tiene acceso a toda la gráfica y como su nombre indica se encarga de las colas de comandos gráficos, además cuentan con varios ACEs (Asynchronous Compute Engines) que traban en paralelo con el procesador de comandos gráficos, estos pueden encargarse de hasta 8 colas de cómputo y solo tienen acceso a las shaders de la gráfica. En resumen, ahora tenemos varias colas de comandos para “dar de comer a CU”
Para entender cómo funciona vamos a poner un ejemplo muy sencillo, tenemos una tarea que a una CU le cuesta 10ms realizar, pero durante esa tarea, la CU va a estar parada desde el milisegundo 4 al el milisegundo 9 por que la tarea tiene algún tipo de dependencia externa y tiene que esperar a los datos. Lo que ocurrirá en la arquitectura GCN de AMD, es que la tarea se detendrá, los datos pasarán a una memoria caché, y la CU recibirá una tarea de computo de la cola, que completa en 3ms, luego volverá a la tarea anterior y la terminará. Por lo tanto en vez de ejecutar solo la primera tarea en 10ms, hemos ejecutado dos tareas en ese mismo tiempo.
Dominio del paint extremo xD
Gráficas NVIDIA
En el caso de Nvidia tenemos Streaming multiprocesors a partir de ahora SM, que se conforman de un número determinado de Cuda cores, Cuda cores es el nombre “guay” que pone Nvidia a sus shaders o stream processors, en el caso de maxwell 128 en el caso de Pascal 64.
Vamos a ver cómo funcionan con el mismo ejemplo de antes, tenemos una tarea gráfica que a una SM le cuesta 10ms y otra de cómputo que le cuesta realizar 3ms. Además vamos a suponer que nuestra gráfica tiene 10SMs
Ahora bien, con el fin de recortar el tiempo que tardamos en realizar estas tareas, vamos a asignar 8 SM a la tarea gráfica y 2 SM a la tarea de cómputo. Ahora la tarea gráfica se termina en 1.25ms y la tarea de cómputo en 1.5ms. Vamos a diferenciar lo que ocurre en la arquitectura Maxwell y en la arquitectura Pascal.
En Maxwell la tarea gráfica terminará y esas 8 SM se quedarán paradas 0.25ms hasta que las otras 2 SM terminen, ya que no podemos reasignar las SM dentro de los límites de una llamada de dibujado, tampoco podemos iniciar una nueva tarea hasta que ambas colas estén terminadas. ¿Soporta Maxwell el computo asíncrono? En la teoría si, en la práctica no, como veis, utilizar el cómputo asíncrono en Maxwell nos expone a poder desbalancear la carga y dejar parte de las SM inactivas. Para ser capaces de utilizar el computo asíncrono en Maxwell deberíamos ser capaces de determinar las particiones antes de la ejecución, además, solo nos beneficiaríamos del cómputo asíncrono si tenemos “huecos que llenar”, la arquitectura Maxwell es muy eficiente y en la mayoría de casos las tareas gráficas ya van a ser capaces de estresar las 10SM de nuestra gráfica imaginaria, así que tendremos pocos huecos y por lo tanto el beneficio que ganaremos del cómputo asíncrono será mínimo. Debido a que es extremadamente difícil de hacer funcionar y proporciona unos beneficios muy reducidos, el cómputo asíncrono fue deshabilitado en gráficas Maxwell.
En Pascal estos límites desaparecen con el llamado "dynamic load balancing", ahora si las colas finalizan de forma desbalanceada el driver junto con el scheduler (planificador de tareas de la gpu) son capaces de proporcionar trabajo de otras colas a las SM que han quedado inactivas.
Y aunque en la práctica esto debería proporcionar un gran aumento de rendimiento, solo funciona si encontramos “huecos” que rellenar, y eso en gráficas Nvidia es complicado debido a la optimización de la arquitectura, hablaremos de ello a continuación.
Vamos primero a ver unas imágenes para demostrar lo de arriba, están sacadas de la web de 3dmark. Se han probado 3 gráficas, la Fury, la 970 y la 1080 y se han analizado con el software GPU view que nos permite analizar cómo está trabajando DirectX. No vamos a profundizar en estas imágenes porque es un software muy complicado, pero vamos a fijarnos en lo básico, en el caso de la 970 solo una de las colas tiene carga, por lo tanto, no hay ningún tipo de cómputo asíncrono funcionando, en el caso de la 1080 y la Fury existe trabajo en la cola de computo, es decir, están haciendo uso del cómputo asíncrono.
GTX 970
GTX 1080
R9 Fury
La implementación de AMD se llama async shaders, y las gráficas Nvidia no son capaces de realizar eso. En Nvidia no existe la posibilidad de que cuando una tarea gráfica se detiene, la SM pase a realizar una tarea de cómputo y luego vuelva a la tarea gráfica original, debido a que ese cambio de contexto sería muy lento al no contar con hardware dedicado, pero si existe la posibilidad de que una SM que ha terminado su trabajo pase a realizar trabajo de otra cola.
Entonces ¿Cuál es mejor? Podríamos decir que las async shaders de AMD porque son más completas y ofrecen más posibilidades, pero no es tan simple, depende de la arquitectura, pongamos un ejemplo basado en la vida real, yo tengo un Ferrari que coje 300km/h y un Ford fiesta que coge 120km/h, el Ferrari corre mucho más, pero ¿me sirve de algo si voy por una carretera limitada a 80km/h? El Ferrari es la ostia, pero, si estoy limitado a 80km/h igual me renta más usar el Ford fiesta que consume menos gasolina. Aquí pasa exactamente lo mismo.
En el caso de las gráficas AMD existen muchos huecos que rellenar, en gran parte porque son malas en tareas geométricas, el procesador geométrico de las gráficas AMD no es capaz de dar trabajo a todas las shaders, provocando grandes “huecos” durante la ejecución de la cola gráfica que podemos rellenar.
En este benchmark podemos comprobarlo.
Este problema no lo sufren las gráficas Nvidia, las tareas gráficas son capaces de aprovechar todas las SM, por lo tanto apenas nos van a quedar huecos que rellenar y el beneficio que vamos a tener es mínimo.
Si Nvidia incluyera el mismo hardware que AMD para realizar el cómputo asíncrono el beneficio sería mucho menor, ya que apenas tienen “huecos” que rellenar debido a que su arquitectura es más eficiente, además las gráficas Nvidia cuentan con menos shaders que las gráficas AMD aunque estas van a velocidades mucho más altas, por ejemplo en la GTX 1060 tenemos 1280 cuda cores a que con el boost 3.0 trabajan a casi 2Ghz y en la RX 480 tenemos 2304 a 1,26Ghz, haciendo que encontrar SM sin trabajo sea aún mucho más complicado que en gráficas AMD. Incluir ese hardware no es gratis, consume y ocupa espacio, por lo tanto para un beneficio muy reducido, a Nvidia no le sale rentable añadirlo, ese espacio pueden usarlo para añadir más cuda cores y hacer gráficas más potentes o simplemente ahorrárselo para hacer un chip más pequeño y eficiente, de hecho, una de las razones por las que las gráficas Nvidia son muy superiores a las AMD en rendimiento / wattio es esta. Es decir, a Nvidia le sale más rentable no incluirlas que incluirlas, ya que supondría subir el consumo y aumentar el tamaño del chip (con el coste económico que eso conlleva), para una ganancia de rendimiento bastante pequeña, además con el balance de cargas ya ganan lo suficiente para no tener una gran desventaja respecto a AMD, es decir, las gráficas AMD ganan más con el computo asíncrono pero la diferencia, por ejemplo en la gráfica de time spy anterior entre la FuryX y la GTX 1080, es de un 6%, es decir, si un juego me va a 50fps son 3 fps extra que voy a tener en la FuryX al usar el computo asíncron,o algo prácticamente imposible de apreciar.
En resumen, no hay una implementación mejor y otra peor, hay una implementación para cada necesidad. ¿Añadirá Nvidia en gráficas futuras las async shaders? Todo depende de lo que vayan a conseguir con ello, es sencillo, si lo que ganan va a ser mayor que lo que pierden las añadirán si no, no. Seguramente las añadirán cuando tengan gráficas con muchos más cuda cores que las actuales dentro de varios años y cuando DX12 y el computo asíncrono estén mucho más asentados, igual que lo que hicieron con DX11, las gráficas Nvidia fueron durante mucho tiempo inferiores a las AMD en DX11, pero cuando DX11 se comenzó a estandarizar y a tomar importancia, lanzaron nuevas gráficas que eran incluso mejores que las AMD bajo esta API, al final es una forma de ganar dinero también, ya que haciendo esto haces que la gente actualice a tus últimas gráficas para tener el mejor rendimiento posible en la última API y que no se queden durante años con gráficas antiguas.
La conclusión del post podría ser la misma que la del anterior, la mejora de AMD proviene en gran parte de las ineficiencias existentes en DX11, sus gráficas ahora pueden sacar todo su potencial y rendir acorde a sus especificaciones, mientras que las gráficas Nvidia se quedan prácticamente igual porque bajo DX11 ya eran muy eficientes. La FuryX es un buen ejemplo, 4096 shaders y 8.6 teraflops que se veían superados por los 2816 cuda cores y 5.6 teraflops de la 980ti. Evidentemente son arquitecturas muy diferentes y no vamos a ver a la FuryX rendir el doble que la 980ti, pero sí que estamos viendo que mientras en DX11 la 980ti gana en prácticamente todas las pruebas, bajo DX12 la FuryX rinde más que la 980ti.
Por último quiero hacer una pequeña mención a la realidad virtual, porque de eso va a tratar el próximo post que tengo en mente, la implementación de AMD tiene una pega y son las tareas de alta prioridad, han incluido colas de alta prioridad pero no funcionan tan bien como en la teoría, las tareas críticas como los async warps en realidad cirtual no se realizan lo suficientemente rápido, Nvidia en cambio, ha introducido un sistema que permite parar en seco la ejecución de una tarea y realizar la tarea crítica. Esto hace a las gráficas Nvidia mucho mejores para realidad virtual, pero de eso hablaremos más adelante en detalle: D
Y hasta aquí el post, como en el anterior he intentado informarme lo máximo posible y hacerlo el post lo más imporcial posible, cualquier cosa que creáis que esta mal (habrá muchas xD) mencionarla en los comentarios para corregirla
Zona spam: Si os han gustado los dos post que he hecho sobre las nuevas APIs podeís pasaros por aquí -> https://www.youtube.com/hardware360grados
