GPU

Comenzamos la noticia con un tema algo polémico, NVIDIA Driver Game Ready 436.02, supuesto 23% en entredicho.

En varios medios y por parte de NVIDIA, se ha hecho eco de que este driver viene con un aumento de rendimiento para unas GPU Turing de hasta un 23%, en concreto el modelo Super, el cual porta las mismas versiones de silicio que las versiones RTX normales, puesto que son los mismos silicios de la gama RTX normal a diferencia que poseen algunos shaders más/menos, silicios que han quedado a medio camino entre gamas y los han sacado con un rebrand de gama para no desperdiciarlos, algo común en todas las compañías y totalmente respetable.

Esto significa por tanto que la gama RTX común también debería recibir mejoras concretas con este driver, si bien puede ser que no tan pronunciadas por carecer de un porcentaje de shaders, al menos pronunciables al ver las mejoras anunciadas.

Personalmente hemos tardado en emitir esta noticia porque hemos estado comprobando la realidad de este porcentaje anunciado, intentando contrastarlo con fuentes fiables para ver que hay de realidad directamente, en vez de hacer un copy-paste de cualquier otro medio como han hecho otros compañeros… lo cual gracias a eso hemos encontrado unos resultados bastante relevantes, incluso sorprendente en los cuales algunos de los juegos no son los anunciados en las mejoras, pero otros si.

– Mejoras reales, pruebas…

La GPU utilizada para las pruebas es una RTX 2070 con una CPU Ryzen 5 2600X bajo XFR2, 16GB de RAM… ambas pruebas en las mismas condiciones, en Shaders esta GPU se equipara muy próxima a una RTX 2060 Super, como comentamos atrás enseñando las especificaciones de ambas, son los mismos silicios Turing con características muy similares (TU106), por lo que deberían recibir también mejoras de rebote, a no ser que NVIDIA haya decidido no mejorar estas gamas de manera intencionada con el poco tiempo que llevan en el mercado, algo inusual que no creemos que haya sucedido.

– Forza Horizon 4:

– Mejora anunciada por NVIDIA bajo este juego en distintas resoluciones con el driver 436.02:

– Driver 436.02, resultado de test de rendimiento:

– Driver 430.64, resultado de test de rendimiento:

En el anuncio de NVIDIA se reporta una mejora de un 17.1% en este juego bajo el último driver recién estrenado, por el contrario en las pruebas reales en los mismos escenarios, nos encontramos una pérdida de rendimiento en los FPS mínimos entorno a un 4.7%.

No disponemos de acceso a más juegos en los que se reportan mejoras, pero fuentes ya me han informado de que la mejora que existe en muchos casos se remite a la misma que el anterior ejemplo, así que no sabemos que ha sucedido con este driver ni de donde sale ese 23% que se anuncia.

Ahora seguiremos con las demás características de este polémico driver, algunas interesantes y otras no tanto…

– Modo latencia “ultra baja”

Esta opción viene dada principalmente como ofensiva haca los controladores de AMD producto de la competencia, a estos se ha incluido esta opción similar… que curiosamente ya existía en el driver, solo que al parecer no funcionaba como debía bajo determinadas versiones de DirectX.

Normalmente en una configuración del driver predeterminada, la GPU pone en cola 3 frames para ser renderizados… en un modo de baja latencia común en esta cola solo pasa a haber un frame que se renderiza de manera inmediata al terminar el anterior, pero queda en espera en la cola. Con el modo de latencia ultra baja es similar a este último, simplemente no pasa por una cola, se envía directamente a renderizar al terminar.

La mejora abarca todas las versiones de Maxwell, Pascal y Turing al parecer.

– Escala de enteros, opción beta solo para Turing

La gente que juegue juegos retro o Pixel Art está de suerte, ahora Turing soporta escalada de enteros para ver las imágenes bastante más nítidas.

– Filtro Sharpening

Como ofensiva de nuevo por la competencia, NVIDIA también ha integrado un filtro de sharpening, la cual ya podríamos disfrutar mediante ReShade en todas las GPU tanto AMD como NVIDIA.

Agradecimientos a los compañeros @SeveenPs por hacer las pruebas del driver con su RTX 2070 y a @Shinobi por hacerlas con Maxwell, aunque los drivers ya en esta arquitectura apenas sufren mejoras y por ello no se han incluido en la prueba y en general a todos nuestros lectores, ¡que cada día sois más!.

Hoy vamos a hablar de dos tecnologías que poco a poco están liderando el progreso de gráficos en videojuegos sin que las conozcamos de manera más profunda, Tile-Based Rendering y Variable Rate Shading en GPU.

– Tile-Based Rendering (TBR), divide y vencerás:

En el pasado, a la hora de renderizar un frame, las GPU de la época lo hacían en su totalidad (inmediate renderting), Esto no cambiaba para nada la calidad del frame ni nada, simplemente se puede resumir de manera muy sencilla en que las GPU necesitaban recursos bastante mayores tanto en memoria como en el ancho de banda de la misma con este método de renderizado, además de no poder incluir nuevas tecnologías que sacasen partido del TBR como es el Variable Rate Shading (VRS) que explicaremos a continuación.

TBR se basa en dividir el frame en una cuadrícula bajo las mismas porciones y renderizar cada parte de la misma por separado, obteniendo ventajas sin necesitar un ancho de banda desproporcionado ni mucha VRAM.

– Variable Rate Shading (VRS), rendimiento inteligente:

La tecnología VRS aprovecha las ventajas del tile-based rendering para reducir o aumentar la tasa de sombreado de cada porción, para ganar rendimiento o calidad en ciertas partes del frame dependiendo de la importancia visual que tenga esa parte en el momento de la escena.

Esto permite al desarrollador del juego hacerlo de forma sencilla bajo una API permitiendo que GPUs más modestas ganen más rendimiento o que las más potentes no sufran tanto en altas resoluciones, sin que veamos una pérdida de calidad importante, ya que normalmente se aprovechan partes visuales en los que el ojo no incide profundamente en la escena.

– GPU, ¿cuales cuentan con estas tecnologías?

TBR lleva bastante tiempo con nosotros a pesar de que últimamente empiece a llamar la atención, con NVIDIA lleva acompañándonos desde su arquitectura Maxwell, solamente TBR puesto que VRS ha empezado a formar parte desde la reciente arquitectura Turing.

AMD por el contrario equipa Draw Stream Binning Rasterizer (DSBR), es una forma distinta de trabajar a TBR pero el concepto final es el mismo, dividir el frame en cierta parte del proceso para mejorar el rendimiento. Se podría decir que es casi una forma de TBR pero sin ser un TBR, una implementación total y formal por TBR la encontramos a partir de RDNA2, en RDNA ya tenemos una implementación casi plena al igual que su propia implementación de VRS.

En resumen, Tile-Based Rendering y Variable Rate Shading en GPU lo encontraremos plenamente en ambas marcas a partir de 2020, cuando se presente RDNA2 y Ampere, ventajas muy prometedoras para los futuros juegos.

NVIDIA últimamente está tomando una posición bastante abierta con las características de sus drivers, algo que siempre ha sido totalmente al contrario cuando no disponían de competencia alguna o no tenían vísperas de que existiera, esta vez NVIDIA libera los 30 bit de color en GTX y RTX.

Para obtener esta característica, hasta hace bien poco era necesario obtener una GPU de la gama Quadro (gama profesional), puesto que en todas las gráficas de la gama mainstream eran compatibles a nivel de hardware, NVIDIA capaba esta característica para forzar al consumidor a comprar una GPU mucho más cara, similar a lo que sucedía con G-Sync hasta hace bien poco, demostrando que podía dar soporte a monitores Adaptive Sync pero sin hacerlo para obligar a sus compradores a pasar por caja, como sucede actualmente también a la hora de utilizar CUDA y GPUs mainstream para cálculo en entornos profesionales (si lo haces, estarías cumpliendo los términos de licencia del driver con lo que ello conlleva si eres una organización y se enteran).

Estas políticas e iniciativa que está tomando NVIDIA parece responder a un movimiento por parte de la competencia, en el cual parece que por fin volverán si no a ponerse a la misma altura a nivel de tecnología, quedar bastante cerca, aunque esto es una suposición personal, pero la experiencia me dice que nadie regala características sin un motivo, sobretodo cuando no lo ha hecho nunca y las ha cobrado a precio de oro con éxito liderando el mercado en todos los ámbitos en los que compite. Pero bueno, de esto nos beneficiamos todos sea con la finalidad que sea, así que nos quedamos contentos con estas nuevas políticas que parece ir tomando NVIDIA con su tecnología.

Podemos activar estas características descargando los controladores studio desde su página oficial.

La eficiencia energética en el hardware, un tema que actualmente está en boca de todos por diversas circunstancias y que a día de hoy incluso condiciona la elección de un componente de mejores características generales a mejor precio con peor eficiencia, por debajo de las de otro con peores prestaciones generales y peores precios pero más eficiente.

Pero… ¿hasta que punto está justificada la eficiencia y a que niveles deberíamos tenerla en cuenta realmente?

Si estamos preocupados por el consumo y el gasto monetario que esto puede suponer a un nivel real, no solo debemos tener en cuenta el consumo de los componentes… si no sobretodo analizar nuestra situación personal, basarnos en el tiempo en el que ese componente lo tendremos a máxima carga, por que un componente puede tener mayor consumo que otro pero mayormente esto sucede a máxima carga y esta situación no es una situación constante en un equipo normalmente, es más suele ser muy poco frecuente.

Otro de los factores es el tiempo en el que tendremos el equipo en marcha, al final la variable de eficiencia está basada en tres pilares, que a resumidas cuentas es consumo, tiempo y la carga del componente, siendo estas dos últimas factor nuestro.

En los ejemplos de a continuación, compararemos el componente en el que más notamos la eficiencia o no en un PC, además de ser el que más valoramos a la hora de elegirlo por su eficiencia, la GPU.

Un equipo gaming que esté funcionando todos los días ocho horas, dos de esas horas a máxima carga seguramente deje una diferencia de consumo anual entre una tarjeta eficiente y una que no lo es con el mismo rendimiento ridícula, en este caso si la tarjeta menos eficiente vale un pico menos en el mercado, muy probablemente nos rente más que una más eficiente a la larga.

Este caso en concreto es con el que mucha gente difama fanatismos en la red, recomendar sin miramientos una GPU de una marca concreta por encima de cualquier otra por su eficiencia en este campo, cuando la diferencia en este entorno es ridícula en precio de energía consumida anual, pero no lo es en la diferencia real del componente, que puede llegar a ser un 20% o más caro aún para el más eficiente, diferencia que en muchos casos no amortizaríamos ni quedándonos el componente eficiente cuatro años cumpliendo la condición anterior.

Otro caso muy distinto puede ser en equipos en los que 24/7 estemos con carga pesada en la GPU o en el componente a analizar, por ejemplo en el caso famoso de los mineros que minaban con GPU y otros con CPU, equipos dedicados al cracking u otros similares.

Aquí el componente a utilizar nos renta que sea eficiente sin miramientos, puesto que en un uso constante a máxima carga la diferencia de precio anual de energía consumida puede llegar a ser bastante brutal, amortizando el componente eficiente con creces en poco tiempo, por encima del no eficiente e incluso en muchos casos por encima de la mitad de su valor a la larga.

Un último caso común puede ser un servidor, pero que no haga uso exhaustivo de la GPU, en el caso de dos GPUs en las que una sea ineficiente y otra eficiente, sin carga constante en ellas sucederá como el primer caso a pesar de ser un equipo funcionando 24/7, apenas arrojarán una diferencia pronunciada que justifique elegir el componente eficiente por el ineficiente, por que sin carga ambas consumirán lo mismo o un valor muy cercano.

Al final en un entorno real y común como el mainstream, la elección de una GPU ineficiente o eficiente (o la de cualquier otro componente con estas características), en muchos casos estará más marcada por la capacidad de nuestra fuente de alimentación para sostenerlo a máxima carga sin problemas que por la diferencia de consumo anual, casos en los que una fuente de buena calidad cumplirá en el 90% de los casos a pesar de elegir un componente ineficiente por encima de otro eficiente.

Puede haber excepciones muy concretas no habituales para elegir un componente eficiente, como equipos de espacio reducido (ITX) o de similares características, en los que por sus fuentes de tamaño reducido, costes de las mismas a diferencia de los tamaños estándar y menor tamaño para disponer de refrigeración adecuada… se prime explícitamente la eficiencia y se necesite componentes totalmente eficientes por encima de cualquier otro, este es un caso aislado pero también posible ni menos importante.

Bueno, hasta aquí este artículo de eficiencia energética en el hardware. ¡Muchas gracias por vuestro tiempo!

Buscando en mi hemeroteca de experimentos macabros con mi antigua R9 Fury Nitro, la cual he de decir que salió dura de narices (sigue viva aún con su nuevo dueño a pesar de las “perrerías” que se ha llevado), encontré un experimento bastante interesante que me gustaría publicar en este artículo, cargando módulos de distintas GPU en AMD para mostraros la peculiaridad del asunto.

Aviso: Replicar todo lo descrito aquí puede dañar de manera irreparable vuestra tarjeta gráfica, si lo hacéis corre bajo vuestra responsabilidad, yo ni el sitio se hacen responsable de lo que suceda.

Con cargando módulos de distintas GPU en AMD, nos referimos a cargar el driver de Hawaii, Polaris, Vega o el de una serie distinta a una GPU que no pertenece a esa serie, pero si tienen similitudes de la arquitectura “padre” que nos permitirá hacerlo de manera funcional, es decir en este caso la vieja GCN.

Haciendo esto podemos obtener algunas características que si tienen otras revisiones de la arquitectura como puede ser características de Polaris pero por ejemplo en Fiji (arquitectura tope de gama anterior a Polaris que forma parte de la serie R9 Fury, prueba de concepto de la que hoy es Vega), o de la propia Vega.

¿Como podemos hacerlo?, haré un mini-tutorial para explicar como cargarlo, no me explayaré mucho por que creo que poca gente va a intentar hacerlo por los riesgos que conlleva, lo cual si alguien tiene alguna duda puedo resolverla mediante comentarios, ya que la noticia va más enfocada a ver “que sucede” haciéndolo más que el como hacerlo.

– Crear y cargar un driver mod

Cargar un driver distinto en vuestra GPU AMD es sencillo, simplemente debemos desactivar en Windows la característica de seguridad que nos obliga a instalar drivers firmados digitalmente. Esto podemos hacerlo con dos simples comandos en una consola con permisos administrativos.

Comandos:

bcdedit -set loadoptions DISABLE_INTEGRITY_CHECKS
bcdedit -set TESTSIGNING ON

Después reiniciamos y ya podemos instalar drivers sin firmar o modificados.

Posteriormente, descargamos la versión del driver que queramos cargar, en este caso para facilitar el ejemplo, lo haré con el driver 19.7.1, los descomprimidos con nuestro compresor favorito y dentro de lo extraído en el directorio que muestro, tenéis que modificar ambos ficheros marcados, aunque debo recalcar que en los resultados que mostraré en el experimento serán con los drivers con los que lo hice en aquella época, puesto que ya no tengo esa GPU para replicarlos con los actuales y tampoco tengo intención de experimentar con mi actual Vega.

Ambos ficheros marcados son los que debemos editar, fijándonos en el primer recuadro marcado al principio de la línea que os muestro a continuación, que coincidirá en ambos ficheros en la línea a modificar para modificar el mismo “módulo” en ambos ficheros, si no, no funciona… posteriormente en el siguiente recuadro, modificar el Id.Hardware del módulo del driver que queramos cargar por el de nuestra GPU, tal que así.

Una vez modificados ambos ficheros con esto, ya tendremos el “mod driver” listo para cargar, el cual no cargaremos con el setup habitual de AMD, si no que primero pasaremos DDU, después de reiniciar al desinstalar con DDU, desconectaremos internet para que Windows Update no haga de las suyas y nos descargue el driver de allí antes y nos toque volver a pasar DDU.

Una vez cumplido lo anterior, lo cargaremos desde el administrador de dispositivos indicándole la carpeta para que busque automáticamente el driver y nos deje elegir el driver mod.

En “Examinar”, buscamos la carpeta del driver mod y aceptamos, nos mostrará los drivers disponibles y si hemos modificado las líneas correctamente, nos nombrará la elección de poder escoger una GPU Polaris o del módulo que hayamos escogido, aunque no sea una GPU de tal “arquitectura”.

Este es un resumen muy rápido de como hacerlo, puede haber matices o detalles más específicos por los que hoy en día no funcione, aunque no debería. Esto es como modificar el Id.Hardware de la GPU por BIOS, cosa que actualmente es muy complicado de hacer por que los BIOS de las GPU vienen firmados y si el checksum de este se ve alterado por modificar ese BIOS y lo flasheamos, la tarjeta no arrancará al corromper la firma.

Este método también sirve para cargar drivers de las últimas Polaris en las primeras, es decir un driver de una RX 590 en una RX 480 y que nuestra GPU sea reconocida como tal, recibiendo las ventajas del driver que aporte, con la particularidad de que no podemos usar el panel de control Adrenaline, ya que este se dará cuenta de la aberración y se cerrará automáticamente.

– Resultados de rendimiento en R9 Fury Nitro con Driver Hawaii, Polaris y Vega

Cargando distintos drivers, en 3dmark obtenemos los siguientes resultados:

(Driver Mod Vega 18.12.3)> Puntuación: 3428
(Driver Mod Polaris 18.12.3)> Puntuación: 3806
(Driver Fury 18.12.3)> Puntuación: 5273
(Driver Mod Hawaii 18.12.3)> Puntuación: 5312

¿Que conclusión sacamos con esto?, pues podemos hacernos a la idea con estas pruebas de que tan lejos o cerca está nuestra GPU de la revisión de arquitectura a comparar y de los cambios que han sufrido en el paso del tiempo.

Siempre se ha dicho que la vieja GCN es igual en cada versión, pero en realidad GCN desde el minuto cero ha estado recibiendo cambios, desde pequeños a nivel de caché, CU… hasta muy profundos como el comienzo de la inclusión al Tiled Rendering en Vega, que podemos ver según nos alejamos de arquitectura al cargar su driver en una GPU anterior, viendo como funciona peor en las pruebas a la vez que nos alejamos en generaciones de GPU por esos cambios.

Cabe recalcar que esto también puede hacerse con GPUs NVIDIA, solo que ellos nos lo ponen bastante más complicado, teniendo que tirar de disassemblers haciendo ingeniería inversa a una parte del driver para conseguirlo. Tal vez alguna vez me anime, cuando haya tiempo para ello, o quien sabe.

Bueno, hasta aquí la entrada de hoy, espero que os guste ya no para replicarlo si no para que veáis que diferencias podemos apreciar entre versiones de una misma arquitectura, esas que no vemos a simple vista.

¡Gracias por vuestro tiempo!