Khronos anuncia OpenCL 3.0: presionar el botón Reset en frameworks de cómputo

En los últimos 15 años, la evolución de la informática de GPU, y ahora de manera más amplia, diversas formas de informática altamente paralela, ha tomado un rumbo interesante. Si bien las GPU cada vez más utilizadas como aceleradores de uso general se predijeron ampliamente y se han posicionado en el objetivo en gran medida, la forma en que llegamos aquí ha sido un camino interesante. La progresión de la CPU se ha disparado, las arquitecturas paralelas y compañías enteras han aumentado y disminuido, las supercomputadoras más poderosas del mundo ahora incluyen GPU como el núcleo de su rendimiento computacional, y nadie vio venir la revolución del aprendizaje profundo hasta que ya estaba sobre nosotros.

De pie sobre este panorama durante la mayor parte de la última década y media como OpenCL, el marco abierto de Khronos para programar GPU y otros aceleradores de cómputo. Originalmente nacido por Apple y ampliamente adoptado por la industria en su conjunto, OpenCL fue el primer esfuerzo (y aún más coherente) para crear una API común para la programación paralela. Al tomar lecciones de los primeros esfuerzos de propiedad del proveedor y al ensamblar un estándar más amplio que todos podrían usar, OpenCL se ha adoptado para todo, desde procesadores integrados y DSP hasta GPU que generan medio kilovatio en consumo de energía.

En general, OpenCL ha tenido un amplio éxito en el cumplimiento de los objetivos del marco para una plataforma de programación informática común (y en gran medida portátil). No solo es compatible con una amplia gama de hardware, sino que es increíblemente relevante incluso para los eventos actuales: por ejemplo, es la API de aceleración utilizada por el proyecto Folding@Home, el clúster informático más poderoso del mundo, que se está utilizando intensamente para investigar opciones de tratamiento para la pandemia de COVID-19.

Al mismo tiempo, sin embargo, así como nadie podía predecir la evolución del mercado de la computación paralela, las cosas no siempre han salido del todo según lo planeado para Khronos y el grupo de trabajo OpenCL que encabeza su desarrollo. Como hemos mencionado varias veces durante el año pasado en varios artículos, OpenCL se encuentra en un estado precario en el escritorio de la PC, su hogar original. Más de una década desde su inicio, el ecosistema informático de la GPU se está fracturando: el interés de NVIDIA se ve atenuado por el hecho de que ya tienen su API CUDA muy exitosa, los últimos controladores OpenCL de AMD son un desastre, Apple ha desaprobado OpenCL y se está moviendo a su propia API de Metal patentada. El único proveedor que parece tener un interés real en OpenCL en este momento es curiosamente Intel. Mientras tanto, OpenCL nunca se adoptó ampliamente en dispositivos móviles, a pesar de su uso irregular y el hecho de que estos están obteniendo GPU cada vez más potentes y otros bloques de procesamiento en paralelo.

Así que hoy Khronos está haciendo algo para lo que no estoy seguro de que haya un paralelismo en la industria de la computación, y ciertamente, nunca ha habido nada parecido en el ecosistema de computación de la GPU: el marco está dando un gran paso hacia atrás. Buscando restablecer el ecosistema, como al grupo le gusta llamarlo, hoy Khronos está revelando OpenCL 3.0, la última versión de su API de cómputo. Tomando en serio algunas lecciones duramente ganadas (y aprendidas), el grupo está retrocediendo el reloj en OpenCL, volviendo la API principal a una bifurcación de OpenCL 1.2.

Como resultado, todo lo desarrollado como parte de OpenCL 2.x se ha convertido en opcional: los proveedores pueden (y generalmente lo harán) continuar admitiendo esas características, pero esas características ya no son necesarias para cumplir con la especificación central. En lugar de tener que admitir todas las funciones de OpenCL, no importa cuán útil o inútil pueda ser para una plataforma determinada, el futuro de la API estará en que los proveedores elijan qué características opcionales les gustaría admitir en la parte superior del núcleo, OpenCL 1.2-especificación derrived.

Política y lamidas

En general, el anuncio de OpenCL 3.0 trae mucho que desempaquetar. Pero quizás el mejor lugar para comenzar es comprender el proceso de desarrollo de OpenCL y quiénes son los usuarios de OpenCL. Khronos, como recordatorio, es un consorcio de la industria. La organización en sí no tiene poder real, es solo una colección de compañías, y debido a que no es un titular de plataforma como Microsoft o Apple, el grupo no puede forzar el cambio tecnológico en nadie. En cambio, la fortaleza de los esfuerzos de Khronos es que obtiene un amplio respaldo de la industria para sus estándares, incorporando la experiencia y las preocupaciones de muchos proveedores en todo el ecosistema.

Sin embargo, el desafío en un enfoque colaborativo es que requiere al menos un cierto grado de armonía y acuerdo entre las empresas que participan. Si no se puede llegar a un acuerdo sobre qué hacer a continuación, entonces un proyecto no puede avanzar. O si nadie está satisfecho con el producto resultante, entonces un producto puede omitirse por completo. Establecer estándares de la industria es en última instancia una cuestión política, incluso si se trata de un estándar tecnológico.

Este es, en cierto modo, el problema con el que se ha topado OpenCL. La versión más reciente de la especificación, OpenCL 2.2, fue lanzada en 2017. Críticamente, introdujo el lenguaje del núcleo OpenCL C ++, finalmente trajo soporte para un lenguaje más moderno y orientado a objetos a una API que originalmente estaba basada en C. Igualmente crítico, sin embargo, tres años después nadie adoptó OpenCL 2.2 . Ni NVIDIA, ni AMD, ni Intel, y ciertamente ningún fabricante de dispositivos integrados.

Por un paso tan importante como lo fue OpenCL 2.2 (y 2.1 antes), el hecho es que nadie terminó particularmente contento con el estado de OpenCL después de 1.2 y 2.0. Como resultado, ha estado perdiendo relevancia y ya no cumple con los objetivos del proyecto. El proyecto OpenCL trató de complacer a todos con 2.x, y en su lugar terminó por no agradar a nadie.

OpenCL 3.0: Avanzando yendo hacia atrás

Entonces, si OpenCL 2.x ha sido ignorado en gran medida, ¿cuál es la solución para hacer que OpenCL sea relevante una vez más? Para Khronos y el grupo de trabajo OpenCL, la respuesta es volver a lo que funcionó. Y lo que mejor funcionó fue OpenCL 1.2.

Introducido por primera vez en 2011, OpenCL 1.2 fue el último de los lanzamientos de OpenCL 1.x. Según los estándares API modernos, es muy básico: se basa en C puro y carece de soporte para cosas como memoria virtual compartida o el lenguaje de representación intermedio SPIR-V. Pero al mismo tiempo, también es la última versión de la API que no incluye un montón de cosas que alguien, en algún lugar, no quiere. Es una API de computación paralela pura de nivel bastante bajo para desarrolladores de todo el espectro, desde dispositivos integrados hasta las GPU más robustas.

En última instancia, lo que el grupo de trabajo de OpenCL ha podido acordar es que OpenCL 1.2 debería ser el núcleo de una nueva especificación: que cualquier otra cosa que se publique después, no importa cuán útil en algunos casos, no sea lo suficientemente útil como debería ser requerido en todas las implementaciones. Entonces, para OpenCL 3.0, esto es exactamente lo que está sucediendo. La versión más reciente de OpenCL está heredando 1.2 y convirtiéndola en la nueva especificación central, mientras que todas las demás características más allá de eso se están moviendo fuera de la especificación central y se hacen opcionales.

Es este reinicio que Khronos y el grupo de trabajo tienen la intención de darle a OpenCL un nuevo camino hacia adelante. A pesar de retrasar el reloj en casi nueve años, OpenCL no está cerca de evolucionar. Pero su naturaleza rígida y monolítica anterior también evitó que evolucionara, porque solo había un camino hacia adelante. Si un proveedor estaba contento con OpenCL 1.2 pero quería un par de características 2.1 adicionales, por ejemplo, para cumplir con la especificación, necesitaría implementar la especificación central 2.1 completa; OpenCL 1.x / 2.x no tenía ningún mecanismo para el cumplimiento parcial. Era todo o nada, y varios vendedores eligieron “nada”.

OpenCL 3.0, por el contrario, está estructurado específicamente de manera que los proveedores puedan utilizar las piezas que necesitan, y solo esas piezas. Como se mencionó anteriormente, el núcleo real de la especificación es esencialmente OpenCL 1.2, con el soporte de consultas de funciones adicionales, así como algunos “puntos de entrada menores para mejorar la portabilidad de la aplicación”. Por encima de eso, a su vez, está todo lo demás: todas las características de OpenCL 2.x, así como las nuevas características de OpenCL 3.0. Todas estas características adicionales son opcionales, lo que permite a los proveedores de plataformas elegir qué características adicionales les gustaría admitir, si es que tienen alguna.

Por ejemplo, un proveedor integrado puede quedarse muy cerca de lo que era OpenCL 1.2, y luego adoptar un par de características como extensiones DMA asincrónicas y memoria virtual compartida. Mientras tanto, un desarrollador de GPU discreto grande y verde puede adoptar la mayoría de OpenCL 2.x, pero excluye el soporte para esa memoria virtual compartida, que no es muy útil para un acelerador discreto. Y luego, un tercer proveedor en el medio podría querer adoptar el envío del dispositivo, pero no SPIR-V. En última instancia, OpenCL 3.0 brinda a los proveedores de plataformas la capacidad de seleccionar las características que necesitan, en esencia adaptando OpenCL a sus deseos específicos.

Resulta que esto es muy similar a cómo Khronos ha abordado Vulkan, que ha tenido mucho más éxito en los últimos años. Dar a los proveedores cierta flexibilidad en lo que implementa su API ha permitido que Vulkan se extienda desde los dispositivos móviles hasta el escritorio, por lo que existe una evidencia muy clara del mundo real de que esta estructura puede funcionar. Y es este tipo de éxito lo que al grupo de trabajo de OpenCL le gustaría ver también.

En última instancia, como Khronos lo ve, las luchas de OpenCL en la última media década han surgido al tratar de hacer que todo sea para todos y al mismo tiempo mantener su naturaleza monolítica. Lo que necesitan los chicos integrados es diferente de los chicos de CPU / APU, y lo que esos chicos necesitan es diferente de los chicos de dGPU, y todavía no hemos llegado a cosas como FPGA y usos más esotéricos de OpenCL. Entonces, para asegurar su propio futuro, OpenCL necesita dejar de ser un diseño monolítico y, en cambio, adaptarse a la amplia gama de dispositivos y mercados para los que está diseñado el marco.

Caminando el camino hacia adelante

Profundizando un poco más, echemos un vistazo rápido a lo que significa OpenCL 3.0 para desarrolladores, proveedores de plataformas y usuarios en lo que respecta al desarrollo de software y la compatibilidad.

A pesar del cambio significativo en la filosofía de desarrollo, OpenCL 3.0 está diseñado para ser tan compatible con versiones anteriores como sea razonable. Para desarrolladores y usuarios, debido a que la especificación central se basa en OpenCL 1.2, las aplicaciones 1.2 se ejecutarán sin cambios en cualquier dispositivo OpenCL 3.0. Mientras tanto, para las aplicaciones OpenCL 2.x, esas aplicaciones también se ejecutarán sin cambios en los dispositivos OpenCL 3.0, siempre que dichos dispositivos admitan las funciones 2.x que se estén utilizando. Lo que, sin duda, no significa que va a ejecutar una aplicación OpenCL 2.1 en un sistema embebido en el corto plazo; pero en las PC y otros sistemas donde las aplicaciones OpenCL 2.1 ya se ejecutan, no se espera que dejen de ejecutarse en OpenCL 3.0.

La razón de esa distinción nuevamente se reduce a la inclusión opcional de características. Los proveedores de plataformas que desarrollan un tiempo de ejecución OpenCL 3.0 no necesitan admitir características 2.x, pero tampoco necesitan abandonarlas; pueden (continuar) admitiendo funciones opcionales como mejor les parezca. De hecho, la nueva especificación requiere relativamente pocos titulares de plataforma en lo que respecta al cumplimiento central. Los controladores OpenCL 1.2 y 2.x necesitan algunos cambios para cumplir con el cumplimiento 3.x, pero esto se trata principalmente de admitir las nuevas consultas de características de OpenCL. Por lo tanto, los proveedores podrán lanzar controladores 3.0 en poco tiempo.

En adelante, el enfoque estará en que los desarrolladores de aplicaciones hagan un uso adecuado de las consultas de características. Debido a que las funciones de OpenCL 2.x son opcionales, se recomienda encarecidamente a todas las aplicaciones que usan funciones opcionales 2.x / 3.0 que usen consultas de funciones para asegurarse primero de que las funciones necesarias estén disponibles; como mínimo, una aplicación puede fallar con gracia, en lugar de una falla más difícil al invocar una función que no existe. Entonces, aunque el software OpenCL 2.x continuará funcionando tal como está, se alienta a los desarrolladores a actualizar sus aplicaciones para ejecutar consultas de características.

Ahora con todo lo dicho, debe tenerse en cuenta que, dado que un conjunto de características de OpenCL 2.x previamente requeridas se han hecho opcionales, esto significa que los proveedores de plataformas pueden dejarlas si lo desean. Hablando con Khronos, no parece que esto vaya a suceder, al menos, no con los proveedores de hardware de PC, pero es una opción que reconocen. Donde es más probable que se vea (si está en algún lugar) sería el espacio incrustado y tal, donde los vendedores ya estaban arrastrando sus talones en características como SPIR-V.

Finalmente, si bien el impacto en el mundo real de esto será nulo, también vale la pena señalar que debido a que OpenCL 2.2 nunca se adoptó, el estándar OpenCL 3.0 técnicamente deja algo atrás. OpenCL C ++, que se introdujo en 2.2, no se ha incluido en la especificación OpenCL 3.0, incluso como una característica opcional. En cambio, el grupo de trabajo OpenCL lo descarta por completo.

Reemplazar OpenCL C ++ es el proyecto C ++ para OpenCL, que, a pesar de las similitudes de nombres, es un proyecto completamente diferente. Las diferencias son bastante pequeñas desde una perspectiva de programación, pero esencialmente C ++ para OpenCL se está construyendo con un enfoque por capas. En este caso, usando Clang / LLVM para compilar el código en SPIR-V, que luego puede ejecutarse en los niveles inferiores de la pila de ejecución de OpenCL como otro código. Y, por supuesto, el SYCL de Khronos también se mantiene para proporcionar programación C ++ de fuente única para cómputo paralelo. Se debe tener en cuenta que SYCL se basa en OpenCL 1.2, por lo que hace que esta transición sea bastante imperturbable.

Novedades de OpenCL 3.0: Extensiones asíncronas de DMA y SPIR-V 1.3

Además de la reversión importante a la especificación central, OpenCL también incluye algunas características nuevas y opcionales para que los vendedores y desarrolladores de plataformas puedan profundizar. Las principales son las extensiones Asynchronous DMA, que terminarán siendo una zanahoria particularmente sabrosa para los proveedores de plataformas que se han quedado con OpenCL 1.2 hasta ahora.

Con la intención de exponer las operaciones de acceso directo a la memoria en OpenCL para dispositivos que tienen hardware DMA, DMA asíncrono es exactamente lo que el nombre dice: soporte para ejecutar transferencias DMA de forma asíncrona. Esto permite que las transacciones DMA se ejecuten simultáneamente con los núcleos de cómputo, a diferencia de las operaciones síncronas que generalmente solo se pueden ejecutar entre otras operaciones de kernel de cómputo. Esto incluye poder ejecutar múltiples operaciones DMA concurrentes entre sí también.

Esta característica es particularmente notable para permitir transferencias de memoria 2D y 3D, es decir, estructuras de memoria complejas que son más avanzadas que las estructuras de memoria 1D (lineales) simples. Como es de esperar, esto pretende ser útil para imágenes y datos similares, que son inherentemente estructuras 2D / 3D para empezar.

Mientras tanto, OpenCL 3.0 también presenta el soporte SPIR-V 1.3 para OpenCL. Nuevamente, esta es una característica opcional para los titulares de la plataforma, y ​​trae OpenCL un poco más actualizado en su soporte SPIR-V, con SPIR-V principal ahora en la versión 1.5. A decir verdad, no estoy seguro de cuán relevante será la opción de soporte 1.3 en este momento, sin embargo, porque es parte de la especificación Vulkan 1.1, y de hecho muchos de los avances en más de 1.2 se centran en gráficos. jugará un papel más importante en el futuro para reforzar la interoperabilidad entre Vulkan y OpenCL.

¿Qué sigue para OpenCL?

Finalmente, como parte de la revisión general de OpenCL para 3.0, Khronos y el grupo de trabajo de OpenCL también están presentando sus planes para el desarrollo futuro de OpenCL. Al limpiar el tablero y mover tantas funciones a opcionales, le da al grupo de trabajo una nueva libertad para agregar a OpenCL según lo considere conveniente la base de usuarios. Y, siguiendo su nueva filosofía, de una manera más fragmentaria.

Una gran parte, como siempre, será la evolución continua de la especificación central de OpenCL. Mientras que 3.0 resuelve las cosas, el plan no es mantener la especificación central de 1.2 eque para siempre. Más bien, como otros proyectos de Khronos, el objetivo del grupo de trabajo sigue siendo mover extensiones ampliamente adoptadas y probadas al núcleo. Para agregar una vez más capas adicionales a la cebolla, por así decirlo, pero de una manera mucho más inteligente y medida que el desarrollo de OpenCL 2.x.

Mientras tanto, una de las características de alta prioridad para futuras versiones será lo que el grupo llama Perfil Flexible, que es otra característica centrada en la integración. Curiosamente, en algunos aspectos, esta es una versión aún más simplificada de OpenCL, que permite a los proveedores eliminar aún más funciones para que coincidan específicamente con lo que su hardware puede hacer. Por ejemplo, los modos de precisión de punto flotante como la precisión simple IEEE, que normalmente se requieren en OpenCL 1.2 / 3.0, podrían eliminarse, así como algunas llamadas a la API. Además de simplificar aún más las cosas para algunos desarrolladores, haría que OpenCL se adaptara mejor a entornos con requisitos rigurosos de certificación de seguridad (piense en automoción), ya que un conjunto de características más pequeño de OpenCL sería mucho más fácil de validar y obtener la certificación.

Mientras tanto, en el otro extremo del espectro, Khronos está estudiando una vez más la idea de conjuntos de características para OpenCL, para ayudar a los desarrolladores de software a navegar mejor las diferencias entre las principales plataformas. Si bien la naturaleza de opciones pesadas de OpenCL 3.0 lo hace relativamente fino, también perjudica la portabilidad hasta cierto punto: un desarrollador no puede contar con otra implementación de OpenCL 3.0 para tener necesariamente algo más de lo que exige la especificación central de 1.2 eqsue . Entonces, a diferencia de los conjuntos de características gráficas para GPU, los conjuntos de características OpenCL permitirían a la industria participar en alguna estandarización, por ejemplo, un perfil de PC con numerosas características modernas, y luego un perfil de aprendizaje automático con soporte para un número menor de características más relevantes para solo profundidad operaciones de aprendizaje

El grupo también está buscando oportunidades continuas para enfoques en capas, donde el soporte de OpenCL no es (y probablemente nunca será) una parte nativa de la plataforma. Este es otro concepto tomado del libro de jugadas de Vulkan, donde hay capas disponibles para ejecutar Vulkan en plataformas como el Metal de Apple. OpenCL ya tiene un proyecto activo para ejecutarse sobre Vulkan, clspv y clvk, que se ha utilizado en dispositivos móviles para ayudar a Adobe a portar y reutilizar su código OpenCL de deskto0p Premiere a Premiere Rush sin requerir una reescritura extensa. Mientras tanto, Microsoft también ha estado respaldando un proyecto OpenCL, (Open) CLOn12 , que implementará el soporte OpenCL 1.2 además de DirectX 12.

Pero la gran pregunta de capas que Khronos plantea en este momento gira en torno a OpenCL para las plataformas de Apple. El autor original de OpenCL no ha llegado más allá de admitir OpenCL 1.2, y han marcado la característica para dejarla en desuso. Entonces, si OpenCL va a seguir funcionando en las plataformas de Apple, sin importar el soporte de las nuevas características 2.xy 3.x, entonces será necesario agregar un nuevo soporte como una capa de nivel superior. Entonces, aunque actualmente no hay un proyecto OpenCL sobre Metal, parece que es solo cuestión de tiempo hasta que se inicie uno, si, por supuesto, Khronos puede encontrar suficientes partes interesadas para el proyecto. El grupo ha tenido mucho éxito con MoltenVK, su capa Vulkan-over-Metal, por lo que un proyecto OpenCL encajaría bien con eso.

Finalmente, incluso Vulkan es un proyecto potencial para el grupo de trabajo OpenCL. Las reversiones a la especificación central significan que la interoperabilidad Vulkan / OpenCL ha dado un paso atrás, y el grupo de trabajo quisiera impulsar eso. Idealmente, OpenCL debería poder trabajar dentro del mismo conjunto de memoria que Vulkan, así como importar y exportar semáforos, todo de manera explícita.

OpenCL 3.0: Provisional hoy, ¿Formalización en unos pocos meses?

Pero antes de que algo de esto pueda suceder formalmente, Khronos y el grupo de trabajo de OpenCL tendrán que trabajar mucho para lograr que OpenCL 3.0 salga por la puerta. Si bien el grupo presenta hoy OpenCL 3.0, el estándar sigue siendo provisional: se está revelando a los desarrolladores y al público en general para obtener comentarios antes de la formalización completa. Y dado el estado actual de OpenCL 2.x, el grupo está ansioso por finalizar OpenCL 3.0 más pronto que tarde.

En total, Khronos espera que puedan obtener la ratificación de la norma en unos pocos meses. Además de obtener la aceptación de miembros y desarrolladores, la finalización también requerirá que se completen las pruebas de conformidad de OpenCL 3.0 (que también ya están en desarrollo), para que el grupo pueda aprobar formalmente las implementaciones de OpenCL 3.0. Siendo la parte técnica, esto puede terminar siendo la tarea más fácil; con la especificación central OpenCL 3.0 que desenrolla tantas características y agrega tan poco a cambio, los proveedores que ya tienen implementaciones sólidas de OpenCL no deberían tener demasiados problemas para preparar sus controladores OpenCL 3.0.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *