De un tiempo a esta parte, tanto NVIDIA como AMD y más tarde Intel tomaron una decisión crucial: no ofrecer soporte en sus nuevos drivers para los sistemas operativos que no fuesen de 64 bits. Esta decisión tiene unos matices bastante amplios, pero en el fondo lo que buscaban era un doble objetivo: forzar al usuario a pasar a Windows 10 y con ello lograr que la industria se mueva a las APIs de bajo nivel, pero ¿por qué?
Como decimos, no es un solo matiz o una sola decisión la que impulsó a esta toma de decisiones, ni mucho menos, pero las ventas sí las marca un solo factor: el ratio de rendimiento/precio.
Y es aquí donde ambas se jugaron hace pocos años el pastel a repartir entre las dos, ya que la excusa era forzar poco a poco a todos los usuarios para que adoptaran Windows 10 ante la negativa de Microsoft de portar DX12 a Windows 7 o inferiores.
APIs de bajo nivel, el santo grial de la optimización y rendimiento
Todo gira en torno a las APIs de bajo nivel, una carrera que comenzó AMD con Mantle y que las APIs de alto nivel en su momento como OpenGL y Direct3D tardaron meses en verla venir. Pero, ¿por qué ambas compañías se lanzaron a los brazos de Microsoft y DX12 cuando salió Windows 10?
Todos conocemos la historia que hay detrás de Mantle y DX. La implementación oficial de una API de bajo nivel significaba que la primera en adoptarla, trabajar con ella y apoyarla en sus drivers ganaría rendimiento a mismo hardware.
Una API de alto nivel tiene una ventaja muy clara frente a una de bajo nivel: admite una gran cantidad de GPUs sin que el programador del juego o del driver tengan que realizar mucho esfuerzo para que todo trabaje en conjunto.
El problema, es que una API de alto nivel también tiene un problema bastante importante y del cual tanto NVIDIA como AMD se dieron cuenta que tenían que huir.
DX9, DX10 y DX11 ofrecían amplias penalizaciones de rendimiento
Aunque esto lo tratamos en su momento, es importante entenderlo para comprender el porqué actualmente todo se dirige hacia la personalización y la optimización. Todos sabemos que la API más usada es DirectX de Microsoft, y como tal, la compañía ofrecía una serie de beneficios con sus distintas versiones.
Esto evitaba que AMD o NVIDIA tuviesen que gastar recursos en I+D aparte de personal para optimizar sus drivers con los motores de los juegos, y al mismo tiempo esto facilitaba el trabajo a los desarrolladores que ponían en manos de Microsoft la parte de la gestión del motor y recursos con la GPU.
DirectX por lo tanto hasta su versión 11 era un administrador de los recursos entre hardware y software que evitaba que ambos se viesen más de lo necesario y así no se interfería en competencias y gestión de dichos recursos de manera directa. Pero entonces la gestión se volvió tan pesada y complicada que las APIs comenzaron a realizar el llamado «overhead» de una forma cada vez más abrupta.
Las llamadas de las API al hardware y al software se multiplicaron con la complejidad de ambos y se comenzó a ver que la optimización entre desarrolladores, API y hardware estaba siendo nefasta en muchas ocasiones. Por ello, AMD trabajó durante bastante tiempo en el desarrollo de Mantle y Microsoft hizo lo propio con DX12.
DX12, la API que ha terminado aunando todo a su paso
Las famosas draw calls dejaron de ser un problema con DX12, NVIDIA y AMD ya tenían de nuevo un intermediario válido que trabajaría con su API y los desarrolladores, pero entonces ¿qué ha cambiado con respecto a DX11 y sus predecesores? Principalmente el modo de gestión de los recusos y los accesos de los mismos. DX12 es una API de bajo nivel, como Mantle, pero mucho más avanzada (Mantle fue «donada» al grupo Khronos para crear Vulkan).
Lo que diferencia a DX11 de DX12 es la llamada abstracción, es decir, con DX12 un desarrollador de un motor de juegos o de un driver tiene un acceso casi total para adaptar su código al hardware. Esto tiene una ventaja muy clara, y no es más que la optimización por parte de los programadores hacia el hardware de AMD y NVIDIA, logrando un mayor rendimiento gracias a que los drivers son mucho más «transparentes» a la hora de trabajar y asignar recursos al hardware.
Como todo, esto tiene una contrapartida también muy clara: requiere muchos más recursos por parte de los motores y los programadores, es decir, requiere más I+D, más personal y más trabajo para adaptar el código a cada arquitectura. Aunque estas arquitecturas de GPU son casi por norma general evoluciones unas de otras y por lo tanto son compatibles en cuanto a drivers, tecnologías como Ray Tracing o DLSS rompen lo establecido y requieren nuevas APIs de bajo nivel y más completas.
DX12 Ultimate: la innovación de una API de bajo nivel llevada al Ray Tracing
Lo hemos visto con DXR y ahora con DX12 Ultimate, donde NVIDIA ha cogido la delantera con sus GPUs RTX y donde AMD llegará este año para mostrar su arquitectura capaz de trabajar con el trazado de rayos en tiempo real. Esto añade una complejidad a los motores que pocos estudios están implementando tras dos años en el mercado y donde ha habido un daño colateral muy claro: el multi GPU, antiguamente llamado SLI y CrossFire.
Tras dos años, cientos de millones gastados en I+D, miles de horas de código picado y dos generaciones de GPUs después, parece que la industria sí está lista para adoptar Ray Tracing como algo que ha llegado para quedarse y es posible que volvamos a ver Multi GPU en DX12 nativo cuando la novedad deje de serlo, tal y como pasó en su momento con la teselación o el TAA.
Cuando ya no se pueda ganar rendimiento por la API y cuando se quieran vender de nuevo más gráficas porque la novedad en las arquitecturas sean pequeños pasos adelante, quizá entonces se active de nuevo el uso de varias tarjetas gráficas en los motores. De hecho, NVIDIA lleva trabajando meses en un nuevo modo de trabajo para varias GPU y suponemos que DX12 Ultimate lo soportará en algún momento mediante el correspondiente Tier.
