El otro día nuestro compañero Cristian nos daba una noticia que aparecía en la descarga oficial de la última versión de CUDA Toolkit publicado por NVIDIA: la actual última versión 10.12 será la última que tenga soporte para macOS. Tanto las herramientas de trabajo de CUDA como el driver de GPUs NVIDIA, abandonan definitivamente el sistema operativo de escritorio de Apple. NVIDIA abandona.
Históricamente, fue la versión 2.0 publicada en 2007 la primera que tuvo soporte para macOS, y desde entonces hasta esta última 10.2 se ha podido trabajar con CUDA. Siempre y cuando, por supuesto, nuestro ordenador tuviera un chipset gráfico NVIDIA, o de forma interna en el equipo como externamente. Este paso no hace más que confirmar lo que inició Apple con macOS Mojave 10.14 el pasado año, donde eliminó el soporte en su sistema de los controladores para GPUs de NVIDIA.
Pero, ¿qué es eso de CUDA? ¿Por qué Apple y NVIDIA se “separan” y parece claro la apuesta hacia GPUs de AMD? Vamos a ponerlo todo en contexto para entenderlo lo mejor posible.
De aquellos barros…
En el año 2001, Apple lanzó el primer equipo que incluía gráficos de NVIDIA, aunque Apple ya trabajaba con ATI en aquel momento (ATI sería comprada en 2008 por AMD). En principio la relación fue buena y era una opción más, pero en 2004 surgió el primer problema: Apple tuvo que retrasar el lanzamiento de su monitor Cinema HD Display porque NVIDIA no fue capaz de proporcionar a tiempo un chip gráfico, el GeForce 6800 Ultra DDL, que funcionara correctamente con este monitor.
Luego, en el año 2007, NVIDIA comenzó a enviar a sus clientes (incluida Apple) chipsets gráficos que incluían las gamas G84 y G86, como la GeForce 8600M GT que fueron puestas en algunos MacBook Pro, como los Early 2008, modelos de 15” y 17”. Estos chips gráficos presentaron algunos defectos que distorsionaban la imagen o mezclaban las líneas. Incluso llegaban a no mostrar nada tanto en la pantalla como en monitores externos. Hubo una demanda colectiva contra NVIDIA que se perdió y Apple tuvo que asumir el coste de un programa de reemplazo oficial para cubrir a los equipos por dos años desde el descubrimiento del error, aunque estuvieran fuera de garantía.
Más problemas. En esa misma época, NVIDIA creó una forma de controlar las comunicaciones de los equipos y la memoria a través de la GPU. Puso un controlador integrado que mejoraba mucho el rendimiento gráfico haciendo que el northbridge encargado del control de la memoria y el southbridge que gestiona las entradas y salidas a dispositivos, no se usaran, pasando todo por el nuevo controlador de NVIDIA. Esto provocó un conflicto entre Intel y NVIDIA y puso a Apple en una situación comprometida en medio de una pelea judicial de dos de sus proveedores más importantes en aquel momento. Conflicto que duró hasta 2011 y que impedía a Apple usar esta tecnología.
Tecnología de NVIDIA que usa su propio controlador pasando por los de las CPUs de Intel
A esto se unieron más problemas: el iPhone fue el primer dispositivo móvil que necesitó un chip gráfico especializado, pero Apple lejos de confiar en ATI o NVIDIA, encargó el chip de esos iPhone a Samsung quien puso también la GPU del equipo. NVIDIA saltó a la palestra y demandó a Qualcomm y Samsung por ser ellos los inventores del término GPU. NVIDIA pretendía que todos aquellos que usaran chips de los demandados pagaran su licencia a ellos, a lo que Apple se negó. De nuevo, situación incómoda para Apple.
Y por último, el motivo oficial: el consumo energético de los chips para portátil de NVIDIA están por encima de su competencia AMD. También es cierto que son más potentes (por lo general) pero mientras AMD apuesta por chips que consuman menos aunque penalice el rendimiento, NVIDIA no tiene problema en aumentar el consumo y las necesidades de refrigeración de sus chips. De hecho, ya pasó con los 9600M que llegaron a provocar problemas de sobrecalentamiento en equipos MacBook Pro hace años.
Un actual MacBook Pro, si ya tiene problemas térmicos con los equipos actuales con GPU de AMD, si usara NVIDIA presentaría problemas añadidos. Las baterías durarían menos y lo más probable es que el diseño de los MacBook Pro no sirviera para enfriar convenientemente una GPU de NVIDIA tal como funcionan hoy día. Y a esto se le une otro elemento: las fuentes de alimentación. En muchos casos NVIDIA necesita fuentes de mayor potencia para alimentar a sus chips y esto supondría más tamaño para los Mac.
Todo este conflicto histórico se ha llevado por delante de forma indirecta a un implicado que es estándar de la industria: CUDA. Librería cerrada y propietaria de NVIDIA para cálculo computacional. Una librería que ha demostrado ser más práctica y potente que los estándares abiertos que la industria ha querido crear como OpenCL.
A Apple no le gusta dar soporte en sus sistemas a librerías cerradas que ellos no controlen, así que ellos han creado su propio estándar Metal. Pero CUDA se ha convertido en estándar por su versatilidad y apoyo de la comunidad, y eso ha cerrado la puerta en Apple a gran parte del desarrollo profesional. Pero, ¿qué es CUDA?
CUDA
CUDA o Compute Unified Device Architecture (arquitectura unificada de dispositivos computacionales). Es una plataforma de computación en paralelo y una API creada por NVIDIA con un propósito claro: que puedan realizarse operaciones genéricas (no gráficas) en un chip gráfico. ¿Por qué? Básicamente porque la capacidad de cálculo computacional de una GPU (o unidad de proceso gráfico) es muy superior a la de cualquier CPU. Tanto en capacidad de cálculo como en procesos en paralelo (donde varias operaciones se realizan a la vez).
¿Y cómo se hace que un chip gráfico haga operaciones que no son gráficas? A través de pequeños programas que son inyectados como operaciones de cálculo en los chips, camuflados de efectos para la imagen. Hablamos de los famosos shaders.
Con el tiempo y viendo cómo permiten modificar las salidas gráficas, se han aplicado para infinidad más de efectos. Básicamente, es como un filtro en tiempo real que le aplicamos a un objeto o una imagen completa. La GPU debería mostrar una imagen de tal objeto de tal forma, pero antes que lo haga, aplicamos un shader y lo transforma, insisto, como si aplicaremos un filtro en tiempo real.
Estos pueden aplicar todo tipo de filtros para hacer que las imágenes generadas por ordenador sean más realistas, como efectos de desenfoque, mapas de normales (con qué intensidad se iluminará una superficie según le de la luz), bokeh, efectos de croma, cel shading (ese efecto que parece que los objetos parezcan planos, como dibujos, tan bien usado en el 'Legend of Zelda, Breath of the Wild') y muchos más.
¿Y cómo puedo entonces hacer cálculo computacional a través de shaders sin que modifiquen en forma alguna una salida gráfica? Obviamente, a través de esta API, de CUDA en este caso, usando determinadas operaciones concretas que hacen creer a la GPU que está calculando para aplicar efectos a gráficos cuando en realidad solo nos interesa la salida de datos que dará tras el proceso que le hemos indicado.
Minecraft, sin y con shaders aplicados
¿Y por qué se hace esto? ¿Por qué usar una GPU en vez de la propia CPU? Pues porque las necesidades gráficas que se han creado en los últimos años para videojuegos y/o aplicaciones profesionales han hecho que las GPU evolucionen mejor para cubrir la necesidad de trabajar con grandes conjuntos de datos de forma paralela, con múltiples núcleos y memorias integradas de alta velocidad.
Eso ha hecho que en tareas pesadas con grandes cantidades de datos como la re-ordenación de datos, simulaciones o aprendizaje automático, usar las GPUs sea más eficiente porque están más preparadas para esos procesos específicos que una CPU que es un componente de uso genérico y no especializado.
CUDA vs OpenCL
CUDA es cerrado y propietario. Pertenece a NVIDIA y solo funciona en sus chips gráficos. Esto, obviamente, a la industria no le gusta.
CUDA vs OpenCL
CUDA apareció en 2007 y visto cómo funcionaba, el Kronos Group (consorcio de la industria, responsable de estándares libres como OpenGL, WebGL o librería gráfica Vulkan) creó un intento de aproximarse a esta con OpenCL. Al igual que OpenGL es una librería gráfica multiplataforma con el propósito que todos los sistemas puedan programarse gráficamente de la misma forma, OpenCL pretendía crear un estándar como API de computación (de hecho significa Open Computing Language).
OpenCL no solo permite programar cálculo computacional para ejecutar en una GPU, la idea era permitir este tipo de ejecuciones en un montón de sistemas diferentes, como CPUs, aceleradores de cualquier tipo e incluso DSPs (procesadores de señales digitales). Pero el problema es el de siempre, cuanto más te alejas del hardware para conseguir un funcionamiento más homogéneo, menor rendimiento tienes porque hay más capas entre tu API y el sistema.
Esto es algo fundamental en software: si tu programa se ejecuta lo más cerca del hardware donde se ejecuta, con instrucciones más precisas, irá mucho mejor que aquel que tiene que transformar y adaptar sus llamadas en múltiples pasos. ¿Cómo entendemos esto? Miren, por ejemplo, Android. Es un sistema operativo que funciona casi en cualquier tipo de hardware o arquitectura. Y dentro de ella con infinidad de componentes. Y la SDK permite una gran retrocompatibilidad. ¿Por qué? Porque está montada sobre una máquina virtual Java. Sobre un programa.
Las librerías en iOS van cargadas como componentes binarios en el sistema operativo y las apps hablan directamente con ellas. Por eso las nuevas funciones que Apple incluye en las nuevas versiones de sus sistemas no son retrocompatibles. Pero hace a iOS más rápido y eficiente en el uso de los procesos o la memoria y por eso un iPhone siempre necesitará menos RAM que un dispositivo Android equivalente.
Sin embargo Android usa una máquina virtual software. Una que al ejecutar código intermedio y traducirlo a cada hardware en el momento que se ejecuta, permite que cualquier software más nuevo pueda ser ejecutado en sistemas antiguos y no actualizados. Básicamente Google sabe qué cosas han cambiado versión a versión y realiza adaptaciones en tiempo real cuando el código se traduce por la máquina virtual hacia el hardware y se buscan las llamadas necesarias. Así consiguen que librerías o cambios más modernos, funcionen en versiones antiguas tal como se esperaría que lo hiciera.
Es más versátil pero necesita más cantidad de proceso y más memoria para hacer lo mismo que un iPhone, mientras un iPhone no puede hacer con versiones antiguas de un sistema lo que incorporen versiones más nuevas. No es mejor ni peor. Es diferente. Lo que uno gana por un lado, el otro lo pierde por el otro y viceversa.
Volviendo al tema que nos ocupa, algo parecido sucede con OpenCL: al situarse más lejos del hardware y no estar específicamente programado para este, es más lento. CUDA está hecho específicamente para sacar el mayor potencial y hablar directamente con los chips de NVIDIA, así que al final (a pesar de ser cerrado y propietario) se ha convertido en un estándar por su elevada eficacia y porque NVIDIA oye mucho a los programadores y lo que necesitan para mejorar su librería versión a versión.
CUDA vs Apple
Ya hemos visto que a Apple no le gustan las librerías cerradas y propietarias que no puede controlar. De hecho, otra cosa que hace en sus sistemas es firmar ellos mismos los controladores de sus componentes y ponerlos a un nivel del sistema que nadie, salvo ellos, pueden tocar. Al contrario que en Windows donde yo puedo bajarme el controlador (driver) del fabricante de mi GPU e instalarlo (y funcionará porque está firmado por Microsoft y porque en Windows sí puedo tocar partes que en macOS no podría).
Apple trabaja con componentes mucho más limitados en número, y certifica a los fabricantes la creación de los controladores, para que no puedan acceder a capas del sistema que están cerradas. Así que aunque el fabricante haga los controladores, es Apple siempre quien los distribuye directamente con el sistema operativo instalado.
NVIDIA, por lo tanto, no puede proporcionar controladores que no sean los de aquellas GPUs que sí tienen algunos Mac. Todos modelos muy antiguos. En este momento, solo la GeForce GTX 680 y la Quadro K5000. ¿Qué pasa si instalamos por nosotros mismos los controladores de NVIDIA en Mojave o superior? Funcionará si lo parcheamos para que salte la comprobación de versión y firma, pero como el controlador no puede acceder a las capas cerradas del sistema, no tendremos aceleración 3D ni del uso del escritorio.
Si leemos la documentación de Apple al respecto que se puede leer en esta página, cuando instalamos una GPU externa (de hecho) si ponemos una que no esté soportada por el sistema porque algún Mac la traiga por defecto, no funcionará.
Los controladores de GPU que se entregan con macOS se han diseñado para ofrecer una experiencia de alto rendimiento y alta calidad cuando se usa una eGPU (…) Debido a esta sólida integración del sistema, en macOS solo se admiten tarjetas gráficas que utilicen la misma arquitectura de GPU que las tarjetas integradas en los productos Mac.
Si ponemos Bootcamp con Windows 10, podremos montar un Mac mini de 2018 con una NVIDIA RTX 2080 externa por Thunderbolt 3, jugar a juegos a más de 100FPS y usar CUDA para programar nuestros cálculos computacionales. Si arrancamos nuestra partición de macOS, ni sabrá qué hay enchufado y usará la Intel 630 integrada por defecto.
Metal para todos
Lo que Apple persigue es que usemos Metal, su propia librería gráfica de bajo nivel que es una API única compatible con todas sus sistemas: iOS, iPadOS, tvOS, watchOS y macOS. Una librería en C que funciona exactamente igualmente en todos sus sistemas y que, además, ofrece también funciones de cálculo computacional como CUDA. APIs que permiten usar shaders para cálculo computacional y aplicaciones científicas, tratamientos de datos o aprendizaje automático.
Craig Federighi en la presentación de Metal para su CPU A7
¿Es mejor que CUDA? Obviamente no. El recorrido que tiene NVIDIA de más de 10 años, un hardware especializado y el apoyo de la comunidad de desarrolladores, no puede compararse con una librería como Metal que lleva muchos menos años, está haciendo uso de GPUs menos especializadas y no preparadas para estas tareas como las de AMD y solo funciona en sistemas Apple (obviamente). ¿Sirve para determinadas tareas computacionales? Por supuesto. Pero es mucho más limitado.
¿Por qué hace Apple eso entonces? Básicamente, siguen defiendo su jardín vallado. No podemos olvidar que uno de los motivos que macOS sea más estable y controlado es precisamente esto. No podemos ser tan ciegos de no ver que este jardín tiene muchas ventajas, tantas como inconvenientes. Pero nos proporciona cosas que definen al sistema en sí.
CoreML permite usa de Machine Learning sobre Metal
¿Qué pasará entonces con los nuevos Mac Pro? Pues lo que podemos imaginar. Apple ya no tiene soporte desde Mojave de forma oficial de los drivers NVIDIA. Y macOS ha pasado a usar Metal como librería gráfica principal para todo. Catalina ha llevado a obsolescencia tanto OpenGL como la librería abierta OpenCL de cálculo computacional (ya estaban deprecadas en Mojave y Apple lleva tiempo avisando). Así que lo único que nos queda es usar Metal con las GPUs AMD que sí tienen soporte en los Mac.
¿Podría ser que algún día Apple diera su brazo a torcer para que pudiéramos usar NVIDIA como eGPUs (externas) o pinchadas en un Mac Pro que lo soporte? Sinceramente, deberían hacerlo. Nos guste más o menos, CUDA es un estándar y no podemos ignorarlo así como así porque, básicamente, estamos cerrando nuestros sistemas a un tipo de usuario muy especializado. Y sobre todo si hablamos de aprendizaje automático.
Metal Performance Shaders, componente para acelerar el aprendizaje automático
¿Puede hacerse aprendizaje automático con Metal y Apple? Sí, incluso aceleración de los cálculos. Apple trabaja en ello e incluso tiene shaders de rendimiento específicos para Metal. Pero comparado con NVIDIA y su librería CUDA, podríamos decir más bien que jugamos con soluciones más cercanas a usar modelos ya hechos que una verdadera aproximación científica y profesional que queda muy lejos de las capacidades que ofrece hoy día Metal.
Tal vez a Apple no le interese especializarse en este tipo de cliente profesional, pero tal vez deberían plantearse abrir un poco la puerta y, al menos, aunque ellos no pongan GPUs de NVIDIA en sus máquinas, que permitan que puedan ser usadas en Mac Pros o equipos con eGPUs.
Basta que permitan a NVIDIA hacer unos controladores que funcionen en macOS y que la librería CUDA Toolkit vuelva a funcionar en Mac. Nos dejan la opción y listo. Eso supondría dar soporte a Metal en chips NVIDIA también. Así están las cosas. Espero que ahora miren con otros ojos este conflicto y ahora, saquen ustedes sus conclusiones: estos son los hechos.
Ver 17 comentarios