GPU

Uno de los dilemas más divergentes y poco especificadas las diferencias en la edición de vídeo es sobre la codificación de vídeo por CPU vs GPU. Sabemos que las GPU pueden hacerlo mucho más rápido que la CPU por tener mayor capacidad de cómputo en coma flotante, pero… ¿los resultados son los mismos o mejores?

En las comparativas que utilizaremos aclararemos ahora como se han hecho y lo que se hará después. En los dos códec más populares en la codificación de vídeo actuales (h264 y h265 HEVC), utilizaremos un RyZen 2700X @ 4.165GHz en CCX0 y en CCX1 4.115GHz con memorias a 3433MHz CL14, totalmente estable bajo instrucciones vectoriales avanzadas (100% estable).

A su vez, estas pruebas se repetirán en otra plataforma que hemos adquirido para Disruptive Kernel, actualizando este artículo posteriormente e incluyéndolas en la entrada actual, plataforma la cual no desvelaremos actualmente pero está basada en la plataforma HEDT (alto rendimiento) de Intel bajo el chipset X299 (Ahora seremos #DisruptiveHintel y no #DisruptiveAmede).

¿Porqué decimos esto?, es importante recalcar que el tipo de instrucciones avanzadas vectoriales (AVX o AVX2 e incluso actualmente AVX512F) puede influir en la velocidad y codificación de vídeo de manera significativa, los cuales los RyZen de segunda generación o inferior salen perjudicados por la distribución y tamaño de sus unidades vectoriales, los cuales te explicamos en este artículo donde analizamos la arquitectura Zen vs Zen 2.

– Un poco de historia

– Codec H264 y su década de oro

El codec H264 básicamente ha sido un codec estándar en la última década por su buen ratio de compresión/calidad, ha inundado miles y miles de vídeos que se mueven por la red con un gran resultado.

Es un codec que no hace un uso intensivo de instrucciones vectoriales avanzadas y que funciona muy bien al trabajar con la GPU, al no usar estas extensiones en profundidad también se le da muy bien a los RyZen basados en arquitecturas inferiores a Zen 2, con un buen resultado de tiempo lineal respecto al conteo de núcleos de la CPU/IPC/Frecuencia como consecuencia.

Tiene soporte prácticamente en todos los dispositivos medianamente modernos del mercado por todo ello, lo cual apostar por él será un éxito si el tamaño del archivo no es relevante para tu conexión o dispositivo a usar.

– Codec H265 HEVC (High Efficiency Video Coding), presente y futuro

H265 o HEVC es un codec que viene para quedarse. Su diseño nace de la época en la que la banda ancha no estaba tan expandida como ahora, la necesidad de conseguir la misma calidad con un bitrate menor (tamaño final de archivo menor si no hablamos de una transmisión), un codec que al final se imponía a gritos para los medios digitales que hacen uso del streaming, pero que no pudo expandirse rápido por la nula retrocompatibilidad de H264 y la lenta adopción de los dispositivos del mismo.

Actualmente es el hoy y el mañana, en características en su codificación se define como un codec que en CPU si hace uso medio de instrucciones vectoriales avanzadas de 256 bits, e incluso hay implementación en codificadores por parte de Intel que hacen uso de unidades de 512 bits, beneficiando enormemente a sus procesadores que son los únicos que disponen actualmente de este conjunto de instrucciones (en la gama HEDT y servidor, que no doméstica aún).

Su adopción en dispositivos ya es bastante buena, las GPU modernas también admiten su codificación y de-codificación por hardware, solo queda que el mundo lo utilice mayormente.

– Las pruebas

– Resultados obtenidos en Zen+ y Vega 64 con codificador AMD VCE

– Tamaños de archivo resultante

Como codificador hemos utilizado Handbrake, del cual hicimos una review… con la misma configuración en todas las codificaciones realizadas pero cambiando el tipo de codec y su aceleración mediante hardware, todas las codificaciones realizadas con el mismo vídeo. El resultado de los tamaños de vídeo es el siguiente:

Recordad que para ver los resultados en su tamaño real, podéis hacer click en el botón derecho de vuestro ratón y seleccionar (Abrir imagen en una nueva pestaña), o simplemente confiar en el resumen que os haré a continuación.

• Codificación en H264 CPU vs GPU: 3,42x de archivo menor a favor de la CPU, siendo este de 1,75GB vs 6GB.
• Codificación en H265 CPU vs GPU: 4,22X de archivo menor a favor de la CPU, siendo este de 1,28GB vs 5,41GB.

Creo que en este apartado la diferencia de tamaño entre archivos es tremenda, que si buscamos un ratio de compresión alto y es nuestra principal “baza”, la prueba de codificación de vídeo por CPU vs GPU nos muestra que la CPU no tiene rival en los mismos parámetros de configuración.

– Tiempo de codificación

– Calidad

Hemos parado las cuatro variantes codificadas en el mismo minuto y hemos hecho cuatro capturas del mismo. Se subirán sin compresión (tipo de archivo PNG) para que juzguéis las calidades vosotros mismos. En cada fotograma hay una muy pequeña variable, y es que es complicado cuadrar exactamente el mismo momento, pero se puede diferenciar por varios patrones las diferencias de calidad, las cuales no vamos a dar nuestra opinión, simplemente os pedimos que juzguéis vosotros mismos.

Os recuerdo que para abrir la imagen a pantalla completa, debéis clickar al botón derecho y “Abrir imagen en nueva pestaña” o en su defecto, si es un teléfono desde donde nos ves, quedarte clickando encima de la imagen con la pantalla y esperar a que nos salga la opción de abrirla en nueva pestaña. (Pronto lo corregiremos, para que al hacer click, se abra simplemente en una nueva pestaña sin hacer este procedimiento.)

Hasta aquí el artículo de codificación de vídeo por CPU vs GPU, recordad que actualizaremos esta entrada cuando tengamos en marcha la nueva plataforma, para ver como se comporta en tiempos y resultados la CPU con las instrucciones avanzadas vectoriales al completo.

Recordad también que los enlaces son en color verde, y que os llevan a lugares donde se explica bien que estamos hablando, para la gente menos preparada.

¡Gracias por vuestro tiempo!

Cuello de botella de la CPU en juegos y como distinguirlo, uno de los dilemas en los que la gente comenta mucho pero comúnmente se interpretan de manera errónea, con viejos pretextos como “a mayor resolución no tendré cuello de botella“, los cuales no son ciertos del todo y requiere un planteamiento de hasta donde es válido este concepto.

– Localizar el último componente que hará cuello de botella

Tenemos que tener claro que el cuelo de botella puede provenir de tres elementos principales que son primordiales en la ejecución de un juego, que son la CPU, la GPU o nuestro monitor.

Con esta imagen entenderemos los tres escenarios que se nos pueda plantear, pues el cuello real sucederá en el que más lento trabaje de todo el conjunto, lo cual eso no significa que sea malo y nos permite un margen de juego a la hora de comprar un componente, el margen se basará en lo que realmente necesitemos.

Aquí tenemos un ejemplo muy común, muchas veces innecesario pero que sucede, lo cual se compra hardware sobre-dimensionado… una CPU que es capaz de procesar 210 Fotogramas por segundo (FPS), una tarjeta gráfica que es capaz de dar solo 180 FPS (a la resolución determinada del monitor, luego aclaramos esto) y un monitor que solo es capaz de mostrarnos 144 FPS.

Evidentemente el cuello en esta imagen es nuestro monitor, puesto que la CPU y la GPU rebasan sobradamente la tasa de frames que el monitor es capaz de mostrar, lo cual mayormente hemos comprado componentes sobre-dimensionados para esta configuración en el mayor de los casos (luego aclaramos esto también).

Este ejemplo es muy similar al anterior, solo cambiando el microprocesador, el cual esta vez el micro es capaz de hacer menos llamadas de renderizado a la GPU de las que esta puede ofrecernos, pero nos encontramos en un escenario muy similar al primero realmente, el cuello de botella seguiría en el monitor así que el escenario sería prácticamente el mismo rendimiento a pesar de usar un microprocesador mucho más barato.

Ahora pondremos uno de los ejemplos muy comunes, en las que la gente pica mucho por marketing pero por falta de desconocimiento muchas veces pagan de más llevando un equipo totalmente sobredimensionado.

¿En este caso?, evidentemente el cuello principal es la tarjeta gráfica (dependiendo del motor gráfico del juego al que nos refiramos), si no muy probablemente será el monitor… en este caso el ejemplo es del motor Frosbite que usa el juego Battlefield V (puede haber variaciones dependiendo de memorias, relojes de la GPU y demás, pero se le acerca bastante a este resultado).

¿Conclusión?, 270€ de presupuesto que se podrían gastar en refrigeración que una CPU puede traer y otra no, una mejor gráfica y monitor para hacer un equipo más compensado, discos o una buena fuente de alimentación, la elección es a vuestra imaginación.

Lo importante es hacer equipos equilibrados, no dejarse llevar por el marketing de un microprocesador o las malas lenguas de cualquiera que ronde la web ni guiarse por fanatismos, si no buscar datos reales y de fuentes fiables sobre lo que tenemos pensado montar, lo que queremos obtener y por cuanto tiempo queremos nos dure.

En estos ejemplos se habla de Hz/FPS de average (media), lo que realmente pesa para ver el rendimiento de un componente, en el siguiente artículo comentaremos las variaciones del mínimo y el máximo, los cuales también son importantes y depende de muchos factores distintos.

– Mitos y realidades sobre el cuello de botella respecto a la resolución

Algo que escuchamos actualmente, es que un procesador que hace cuello de botella a una GPU, se palía subiendo la resolución y el cuello de botella dejará de existir.

Esto es cierto a medias, una CPU es capaz de hacer un número determinado de llamadas a la GPU para renderizar una cantidad de frames, esto significa que si nuestro microprocesador es capaz de hacer 180 llamadas esto se traducirá en 180 frames máximo si la GPU es capaz de mantener ese framerate a la resolución que estamos jugando.

Si nuestra CPU es capaz de llamar 180 veces a la GPU por segundo, nuestra GPU es capaz de atender 220 llamadas a 1080p y nuestro monitor capaz de mostrarnos 210Hz, tendremos una CPU que está haciendo cuello de botella al conjunto entero y un monitor que está haciendo cuello a la GPU en el caso de solucionar el cuello de la CPU, lo cual el cuello en esta configuración y en todas finalmente se quedará en el elemento más lento de la cadena, porque la CPU que no puede abastecer el requisito de los demás…

Estas llamadas son totalmente independientes de la resolución, es decir da igual que tu estés jugando a 1080p que a 4K, tu procesador será capaz de atender 180 llamadas a cualquier resolución en ese motor gráfico (puede variar en cada uno dependiendo de IPC, aprovechamiento multihilo…), luego será la GPU la que tenga que dibujar todo lo que pide esas llamadas y dependiendo del modelo y su capacidad está si será determinante a la hora de una u otra resolución en el framerate a diferencia de la CPU.

El tema de que una CPU deja de hacer cuello de botella al subir la resolución es relativo, dejará de hacerlo porque exigimos más trabajo a la gráfica, la cual seguramente baje por debajo de la tasa de frames máximas a las que la CPU es capaz de abastecer enmascarando el cuello de botella que si teníamos a otra resolución, pero no significa que el problema esté solucionado totalmente, sobretodo si estamos buscando una tasa de frames concreta que la CPU no pueda darnos, la cual si nuestra CPU no consigue a una resolución inferior, jamás lo hará en otra superior aunque montemos la GPU más potente del mercado, puesto que la cantidad de frames capaz de dar el micro será siempre la misma (dependiendo de cada motor gráfico y su aprovechamiento).

Se puede intentar paliar el cuello de botella de la CPU en juegos aumentando el número de llamadas a la GPU por parte de la CPU haciendo overclock, al igual que dependiendo de la arquitectura del procesador, si es más dependiente de la RAM tal vez montando módulos más rápidos o haciendo overclock a estos podamos aumentarlas, pero esto tiene un límite determinado .

El porcentaje de cuello de botella de una CPU hacía una GPU se calcula entorno al número de FPS que una GPU puede llegar a dar en determinada resolución por encima de las que la CPU puede solicitar, por ejemplo si una 2080Ti es capaz de darnos 300 FPS en 1080p y un 9900K es capaz de gestionar 230 FPS (230 llamadas por segundo a la GPU), el cuello será el resultado de 300/230… es decir un 30%, lo cual es un escenario totalmente válido y que nos podemos encontrar hoy en día, ya que a 1080p es una resolución que cualquier GPU tope de gama ahora mueve muy sobradamente, lo cual incluso las CPU más poderosas pueden tener cuello de botella.

Hasta aquí el cuello de botella de la CPU en juegos… ¡cualquier duda recordad que tenéis los comentarios!