Las actualizaciones de controladores de GPU para PC a menudo mencionan mejoras realizadas en el rendimiento de juegos específicos recientemente lanzados. ¿Por qué es necesaria esta actualización específica del juego? ¿Cómo interactúan los cambios específicos del juego con el código del juego?
Como alguien con algunos años de desarrollo de controladores, veo esto como dos problemas separados.
Un controlador de gráficos es una bestia muy complicada. Implementar todo de manera óptima sería una tarea simplemente imposible; es un obstáculo lo suficientemente grande como para hacer un controlador que realmente siga las especificaciones, y las especificaciones se vuelven cada vez más complejas. Entonces, desarrollas tu controlador en función de las especificaciones y un puñado de aplicaciones de prueba (ya que, en muchos casos, todavía no hay un software real ).
A lo largo viene un juego real (o punto de referencia, o algún otro caso de uso para el controlador, como la decodificación de video) que expone un cuello de botella en el controlador. A medida que avanza, descubra cómo suavizar las cosas y hacer que ese caso de uso sea más rápido. Puedes informar fácilmente que el juego XYZ es un 27,3% más rápido, pero en realidad todas las aplicaciones que tienen dicho caso de uso (por ejemplo, actualización dinámica de textura) se vuelven más rápidas.
Luego está el lado feo, las optimizaciones reales por aplicación, en las que el controlador detecta qué aplicación se está ejecutando (o qué sombreador se está compilando) y hace algo no genérico. Ha habido muchos casos publicitados de esto, donde, por ejemplo, cambiar el nombre del ejecutable de 3dmark cambia repentinamente los resultados.
Siento que este tipo de optimizaciones son una pérdida de tiempo para todos: miente a sus clientes en el caso de los puntos de referencia y puede cambiar la forma en que un sombreador se comporta de lo que el desarrollador realmente quiere. Recuerdo un caso en el que se cambió un sombreador de una búsqueda de textura a un cálculo en sombreador (que solo funcionaba para dicho hardware del fabricante) que estaba cerca, pero no exactamente el mismo resultado, y el desarrollador rechazó que esto no fuera legal mejoramiento.
En un mundo ideal no lo harían.
Sin embargo, este no es un mundo ideal, por lo que las mejoras de rendimiento específicas del juego pueden provenir de uno o más de los siguientes (no pretende ser una lista exhaustiva):
El juego está haciendo una combinación de operaciones A, B y C con los estados X, Y y Z establecidos. El controlador puede hacer suposiciones basadas en esto y llevar las cosas a una ruta de código más óptima.
El juego nunca realiza las operaciones I, J o K. Nuevamente, el conductor puede elegir una ruta de código más óptima en función de ser capaz de asumir que estas operaciones nunca se realizan.
El juego hace algunas cosas de una manera subóptima (o no tan ligeramente). El conductor lo sabe, intercepta las llamadas y las convierte en algo (¡ojalá!) Equivalente que funcione mejor con él.
Se pueden hacer compensaciones específicas del juego; por ejemplo, está bien si esta combinación de estados de renderizado es lenta porque es más importante que esa combinación vaya más rápido, así que optimicemos en consecuencia.
Es importante tener en cuenta aquí que ninguno de estos debe ser "obligatorio". Siempre que tanto el controlador como el uso de la API del juego sean conformes, las cosas deberían funcionar. Pero a veces, las compensaciones de casos especiales para poder extraer el rendimiento máximo pueden considerarse apropiadas. Me abstendré de comentar si eso es bueno o no.
fuente
Los desarrolladores de juegos superan los límites de las GPU. Podemos hacer una analogía con un juego y un motor de juego. Cuanto más avanzados sean los requisitos del juego, más avanzado debe ser el motor del juego para soportarlo. Esto es lo mismo con las tarjetas gráficas.
Los juegos de computadora y los fabricantes de GPU son buenos compañeros de cama. Les conviene trabajar juntos para mejorar la GPU, mejorando así el juego. Este es el software clásico que trabaja con la relación de hardware. Ambas partes tienen algo que agregar cuando se trata de diseñar la interfaz entre software y hardware. Esa interfaz es el controlador.
Estas actualizaciones pueden incluir correcciones de errores que encontraron los técnicos de software, o mejoras que los técnicos de hardware han realizado para cumplir con los requisitos de los técnicos de software. Encontrarás esta relación por todas partes.
Probablemente el razonamiento detrás de incluir los juegos específicos en las notas de la versión de actualización del controlador es PR. No solo muestra que el fabricante de tarjetas X funcionará realmente bien con el juego Y, sino que también muestra que el juego Y será aún mejor de lo que era antes.
fuente
Es plausible que el equipo de desarrollo del juego se topó con un error de controlador de GPU que haría que el juego no funcionara correctamente si el error de controlador no se solucionara.
También es a veces un truco de marketing . Por ejemplo, ATI / AMD recientemente incluyó una copia de Dirt 3 con sus GPU más nuevas y propuso la idea de jugar con Eyefinity con 3 monitores en este juego.
Entonces hay un poco de simbiosis allí.
Proveedor de GPU: ¡Hola! Esta nueva característica! ¡Nadie lo está usando!
Desarrollador de juegos: ¡ podríamos usarlo! ¿Combina nuestro juego con su GPU que usa esta función?
Proveedor de GPU: ¡Diablos!
fuente
La verdad es que las GPU no requieren controladores específicos del juego.
Los controladores específicos del juego son parte de un esfuerzo de marketing de los fabricantes de GPU para tratar de obtener una ventaja sobre otros fabricantes de GPU. Si pueden mostrar un mejor rendimiento en juegos populares al ajustar sus controladores para esos juegos específicos, entonces (según la teoría) atraerán a más jugadores de esos juegos.
Eso es casi todo lo que hay que hacer.
fuente