El otro día vuestro compadre Cristian nos daba alguna 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 labor de CUDA como el driver de GPUs NVIDIA, abandonan definitivamente el sistema operacional de escritorio de Apple. NVIDIA abandona.
Históricamente, fue la versión 2.0 notificada en 2007 la primera que tuvo soporte para macOS, y desde entonces inclusive esta última 10.2 se ha podido trabajar con CUDA. Siempre y cuando, por supuesto, vuestro ordenador tuviera un chipset gráfico NVIDIA, u de figura interna en el equipamiento como externamente. Este paso no hace mas 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 equipamiento que incluía gráficos de NVIDIA, siquiera Apple™ ya trabajaba con ATI en aquel instante (ATI sería comprada en 2008 por AMD). En inicio la relación fue buena y era alguna 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 apto de proporcionar a período 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 usuarios (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, prototipos de 15” y 17”. Estos chips gráficos presentaron algunos defectos que distorsionaban la imagen u mezclaban las líneas. Incluso llegaban a no señalar nada tanto en la monitor como en monitores externos. Hubo alguna demanda colectiva contra NVIDIA que se perdió y Apple tuvo que asumir el coste de un programa de reemplazo oficial para encubrir a los equipos por 2 años desde el hallazgo del error, siquiera estuvieran fuera de garantía.
Más problemas. En esa misma época, NVIDIA creó alguna figura de controlar las comunicaciones de los equipos y la memoria a través de la GPU. Puso un controlador integrado que mejoraba demasiado 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 reciente controlador de NVIDIA. Esto provocó un conflicto entre Intel™ y NVIDIA y puso a Apple™ en alguna ocasión comprometida en medio de alguna pelea legal de 2 de sus proveedores mas fundamentales en aquel momento. Conflicto que duró inclusive 2011 y que impedía a Apple™ usar esta tecnología.
Tecnología de NVIDIA que usa su personal controlador pasando por los de las CPUs de Intel™ A esto se unieron mas problemas: el iPhone fue el primer dispositivo teléfono que necesitó un chip gráfico especializado, pero Apple™ lejos de confiar en ATI u NVIDIA, encargó el chip de esos iPhone a Samsung™ quien puso además 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, ocasió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 sobre de su competidor AMD. También es cierto que son mas potentes (por lo general) pero durante AMD™ apuesta por chips que consuman menos siquiera penalice el rendimiento, NVIDIA no tiene problema en incrementar 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 presentes con GPU de AMD, si usara NVIDIA presentaría problemas añadidos. Las baterías durarían menos y lo mas posible es que el boceto de los MacBook Pro no sirviera para enfriar convenientemente alguna GPU de NVIDIA tal como funcionan hóy día. Y a esto se le une otro elemento: las fuentes de alimentación. En muchos sucesos NVIDIA necesita fuentes de mayor fuerza para alimentar a sus chips y esto supondría mas tamaño para los Mac.
Todo este conflicto histórico se ha llevado por adelante de figura indirecta a un involucrado 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 mas practica y poderoso que los estándares abiertos que la fábrica 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 inventado su personal estándar Metal. Pero CUDA se ha convertido en estándar por su versatilidad y respaldo de la comunidad, y eso ha cerrado la puerta en Apple™ a gran parte del desarrollo profesional. Pero, ¿qué es CUDA?
CUDA
CUDA u Compute Unified Device Architecture (arquitectura unificada de aparatos computacionales). Es alguna plataforma de computación en paralelo y alguna 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 alguna GPU (o unidad de procedimiento gráfico) es muy superior a la de cualquiera CPU. Tanto en capacidad de cálculo como en procesos en paralelo (donde hartas 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 célebres shaders.
Con el período y viendo cómo permiten modificar las salidas gráficas, se han aplicado para inmensidad mas de efectos. Básicamente, es como un filtro en período cierta que le aplicamos a un objeto u alguna imagen completa. La GPU corresponderia señalar alguna imagen de tal objeto de tal forma, pero anteriormente que lo haga, aplicamos un shader y lo transforma, insisto, como si aplicaremos un filtro en período real.
Estos pueden aplicar todo tipo de filtros para hacer que las imágenes generadas por ordenador sean mas realistas, como efectos de desenfoque, mapas de normales (con qué intensidad se iluminará alguna superficie según le de la luz), bokeh, efectos de croma, cel shading (ese efecto que parece que los elementos 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 figura alguna alguna salida gráfica? Obviamente, a través de esta API, de CUDA en este caso, usando determinadas operaciones concretas que hacen suponer 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 procedimiento que le hemos indicado.
Minecraft, sin y con shaders aplicados ¿Y por qué se hace esto? ¿Por qué usar alguna GPU en vez de la propia CPU? Pues porque las necesidades gráficas que se han inventado en los últimos años para videojuegos y/o aplicaciones profesionales han hecho que las GPU evolucionen mejor para encubrir la necesidad de trabajar con grandes conjuntos de datos de figura paralela, con múltiples núcleos y memorias integradas de alta velocidad.
Eso ha hecho que en misiones pesadas con grandes cantidades de datos como la re-ordenación de datos, simulaciones u aprendizaje automático, usar las GPUs sea mas eficiente porque están mas preparadas para esos procesos específicos que alguna CPU que es un elemento 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 fábrica 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 u librería gráfica Vulkan) creó un intento de aproximarse a esta con OpenCL. Al igual que OpenGL es alguna 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 concede programar cálculo computacional para ejecutar en alguna GPU, la idea era permitir este tipo de ejecuciones en un montón de sistemas diferentes, como CPUs, aceleradores de cualquiera tipo e inclusive DSPs (procesadores de señales digitales). Pero el problema es el de siempre, cuanto mas te alejas del hardware para adquirir un funcionamiento mas homogéneo, menor rendimiento tienes porque hay mas capas entre usted API y el sistema.
Esto es algo fundamental en software: si usted programa se ejecuta lo mas cerca del hardware donde se ejecuta, con instrucciones mas precisas, irá demasiado mejor que aquel que tiene que convertir y adaptar sus llamadas en múltiples pasos. ¿Cómo entendemos esto? Miren, por ejemplo, Android. Es un sistema operacional que funciona casi en cualquiera tipo de hardware u arquitectura. Y adentro de ella con inmensidad de componentes. Y la SDK concede alguna gran retrocompatibilidad. ¿Por qué? Porque está montada sobre alguna máquina virtual Java. Sobre un programa.
Las librerías en iOS™ van cargadas como componentes binarios en el sistema operacional y las app conversan directamente con ellas. Por eso las nuevas funciones que Apple™ incluyen en las nuevas versiones de sus sistemas no son retrocompatibles. Pero hace a iOS™ mas rápido y eficiente en el uso de los procesos u la memoria y por eso un iPhone siempre necesitará menos RAM que un dispositivo Android™ equivalente.
Sin embargo Android™ usa alguna máquina virtual software. Una que al ejecutar código intermedio y traducirlo a cada hardware en el instante que se ejecuta, concede que cualquiera software mas reciente pueda ser ejecutado en sistemas viejos y no actualizados. Básicamente Google™ sabe qué cosas han cambiado versión a versión y efectua adaptaciones en período cierta cuando el código se traduce por la máquina virtual hacia el hardware y se buscan las llamadas necesarias. Así obtienen que librerías u intercambios mas modernos, funcionen en versiones antiguas tal como se esperaría que lo hiciera.
Es mas versátil pero necesita mas medida de procedimiento y mas memoria para hacer lo idéntico que un iPhone, durante un iPhone no puede hacer con versiones antiguas de un sistema lo que incorporen versiones mas nuevas. No es mejor ni peor. Es diferente. Lo que 1 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 mas lejos del hardware y no Estad específicamente programado para este, es mas lento. CUDA está hecho específicamente para sacar el mayor potencial y hablar directamente con los chips de NVIDIA, así que al meta (a pesar de ser cerrado y propietario) se ha convertido en un estándar por su elevada eficacia y porque NVIDIA oye demasiado a los programadores y lo que requieren 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 opuesto que en Windows™ donde yo puedo bajarme el controlador (driver) del fabricante de mi GPU e instalarlo (y desempeñará porque está firmado por Microsoft™ y porque en Windows™ sí puedo tocar partes que en macOS no podría).
Apple trabaja con componentes demasiado mas 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 siquiera el fabricante haga los controladores, es Apple™ siempre quien los distribuye directamente con el sistema operacional instalado.
NVIDIA, por lo tanto, no puede proporcionar controladores que no sean los de aquellas GPUs que sí tienen algunos Mac. Todos prototipos 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 u 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 poseeremos 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 alguna GPU externa (de hecho) si ponemos alguna 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 entregar alguna experiencia de alto rendimiento y alta calidad cuando se usa alguna eGPU (…) Debido a esta sólida incorporación del sistema, en macOS solo se admiten tarjetas gráficas que utilicen la misma arquitectura de GPU que las tarjetas integradas en los artículos Mac.
Si ponemos Bootcamp con Windows™ 10, podremos montar un Mac™ mini de 2018 con alguna NVIDIA RTX 2080 externa por Thunderbolt 3, jugar a games a mas de 100FPS y usar CUDA para programar nuestros cálculos computacionales. Si arrancamos vuestra partición de macOS, ni sabrá qué hay enchufado y usará la Intel™ 630 incorporada por defecto.
Metal para todos
Lo que Apple™ persigue es que usemos Metal, su propia librería gráfica de bajo nivel que es alguna API única compatible con todas sus sistemas: iOS, iPadOS, tvOS, watchOS y macOS. Una librería en C que funciona cabalmente igualmente en todos sus sistemas y que, además, propone además funciones de cálculo computacional como CUDA. APIs que permiten usar shaders para cálculo computacional y aplicaciones científicas, procedimientos de datos u aprendizaje automático.
Craig Federighi en la presentación de Metal para su CPU A7 ¿Es mejor que CUDA? Obviamente no. El trayecto que tiene NVIDIA de mas de diez años, un hardware especializado y el respaldo de la comunidad de desarrolladores, no puede compararse con alguna librería como Metal que lleva muchos menos años, está haciendo uso de GPUs menos especializadas y no preparadas para estas misiones como las de AMD™ y solo funciona en sistemas Apple™ (obviamente). ¿Sirve para determinadas misiones computacionales? Por supuesto. Pero es demasiado mas limitado.
¿Por qué hace Apple™ eso entonces? Básicamente, siguen defiendo su jardín vallado. No podemos olvidar que 1 de los motivos que macOS sea mas estable y controlado es justamente 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 concede usa de Machine Learning sobre Metal ¿Qué pasará entonces con los recientes Mac™ Pro? Pues lo que podemos imaginar. Apple™ ya no tiene soporte desde Mojave de figura oficial de los drivers NVIDIA. Y macOS ha pasado a usar Metal como librería gráfica primordial 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 período 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) u pinchadas en un Mac™ Pro que lo soporte? Sinceramente, deberían hacerlo. Nos guste mas u 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, elemento para acelerar el aprendizaje automático ¿Puede hacerse aprendizaje automático con Metal y Apple? Sí, inclusive aceleración de los cálculos. Apple™ trabaja en ello e inclusive tiene shaders de rendimiento específicos para Metal. Pero comparado con NVIDIA y su librería CUDA, podríamos decir mas bien que jugamos con soluciones mas cercanas a usar prototipos ya hechos que alguna verdadera aproximación científica y profesional que queda muy lejos de las capacidades que propone hóy día Metal.
Tal vez a Apple™ no le interese especializarse en este tipo de usuario 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 u equipos con eGPUs.
Basta que permitan a NVIDIA hacer unos controladores que funcionen en macOS y que la librería CUDA Toolkit vuelva a desempeñar 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 ahorita miren con otros ojos este conflicto y ahora, saquen ustedes sus conclusiones: estos son los hechos.
También te recomendamos
OpenCL, la opción disponible a CUDA y el futuro de la computación GPGPU
La tecnología CUDA en Mac™ OS X, aprovechando la fuerza de las tarjetas gráficas de NVidia
NVIDIA reafirma que macOS ya no será compatible con el desarrollo de aplicaciones CUDA
–
La noticia CUDA, historia del conflicto Apple™ y NVIDIA fue notificada originalmente en Applesfera por Julio César Fernández .
el inventor es el AUTOR ORIGINAL de su link de arriba, auspiciamos al desarrollador original de la noticia sin perjudicar su reputación ni posicionamiento web.