spir - OpenCL, Vulkan, Sycl

modelo spir

Question

Estoy tratando de entender el ecosistema de OpenCL y cómo Vulkan entra en juego.

• Entiendo que OpenCL es un marco para ejecutar código para gpus así como para cpu - usando núcleos que pueden ser compilados para SPIR
• Vulkan también se puede usar como una api de cómputo usando el mismo lenguaje SPIR
• SYCL es una nueva especificación que permite escribir código abierto como estándar adecuado conforme a c ++ 14. Tengo entendido que todavía no hay implementación libre de esa especificación.

Dado que:

• ¿Cómo se relaciona OpenCL con vulkan? Entiendo que OpenCL es de nivel superior y abstrae los dispositivos, pero, ¿(o podría) usa Vulkan internamente? (En lugar de confiar en los controladores específicos del proveedor)

• Vulkan se promociona como una API de cómputo y gráfica, sin embargo, encontré muy pocos recursos para la parte de cómputo, ¿por qué?

• Vulkan tiene ventajas de rendimiento sobre OpenGL. ¿Lo mismo es cierto para Vulkan vs OpenCl? (Lamentablemente, OpenCL es notorio por ser más lento que CUDA)

• ¿SYCL usa OpenCL internamente o podría usar vulkan? ¿O no utiliza ninguno de los dos y, en su lugar, se basa en las especificaciones específicas del proveedor de bajo nivel que se implementarán?

Answer 1

¿Cómo se relaciona OpenCL con vulkan? Entiendo que OpenCL es de nivel superior y abstrae los dispositivos, pero, ¿(o podría) usa Vulkan internamente?

No están relacionados entre sí en absoluto.

Bueno, técnicamente utilizan el mismo lenguaje de sombreado intermedio, pero Vulkan prohíbe el modelo de ejecución de Kernel, y OpenCL prohíbe el modelo de ejecución de Shader. Debido a eso, no puedes simplemente tomar un shader para OpenCL y pegarlo en Vulkan, o viceversa.

Vulkan se promociona como una API de cómputo y gráfica, sin embargo, encontré muy pocos recursos para la parte de cómputo, ¿por qué?

Porque al Grupo Khronos le gustan los engaños publicitarios engañosos.

Vulkan no es más una API de cálculo que OpenGL. Puede tener Compute Shaders, pero su funcionalidad es limitada. El tipo de cosas que puede hacer en una operación de procesamiento de OpenCL simplemente no está disponible a través de OpenGL / Vulkan CS.

Los CS de Vulkan, al igual que los CS de OpenGL, están diseñados para ser utilizados para una sola cosa: para soportar operaciones de gráficos. Para realizar la selección de fondos, cree comandos gráficos indirectos, manipule sistemas de partículas y otras cosas similares. Los CS funcionan con la misma precisión numérica que los sombreadores gráficos.

Vulkan tiene ventajas de rendimiento sobre OpenGL. ¿Lo mismo es cierto para Vulkan vs OpenCl?

El rendimiento de un sistema de cómputo se basa principalmente en la calidad de su implementación. No es OpenCL que es lento; Es su implementación OpenCL que es más lenta de lo que podría ser.

Vulkan CS no son diferentes en este sentido. El rendimiento se basará en la madurez de los drivers.

Además, existe el hecho de que, una vez más, hay muchas cosas que puedes hacer en una operación de procesamiento OpenCL que no puedes hacer en un Vulkan CS.

¿SYCL usa OpenCL internamente o podría usar vulkan?

Del Grupo Khronos:

SYCL (pronunciado ''hoz'') es una capa de abstracción multiplataforma, libre de regalías, que se basa en los conceptos subyacentes, la portabilidad y la eficiencia de OpenCL ...

Así que sí, está construido sobre OpenCL.

Answer 2

¿Cómo se relaciona OpenCL con vulkan?

Ambos pueden canalizar un trabajo separable de host a gpu y gpu a host usando colas para reducir la sobrecarga de comunicación usando múltiples subprocesos. Directx-opengl no puede?

• OpenCL: Lanzamiento inicial el 28 de agosto de 2009. Soporte de hardware más amplio. Punteros permitidos pero solo para ser utilizados en el dispositivo. Puede utilizar la memoria local compartida entre hilos. Mucho más fácil empezar un mundo de saludo. Tiene una sobrecarga de API para los comandos a menos que estén en la cola del dispositivo. Puede elegir la sincronización implícita de múltiples dispositivos o la administración explícita. Los errores en su mayoría están arreglados para 1.2, pero no sé acerca de la versión 2.0.

• Vulkan: Lanzamiento inicial el 16 de febrero de 2016 (pero el progreso a partir de 2014). Soporte de hardware más estrecho. ¿Puede SPIR-V manejar los punteros? ¿Tal vez no? ¿No hay opción de memoria local? Es difícil empezar a hola mundo. Menos api por encima. ¿Puedes elegir la gestión implícita de múltiples dispositivos? Todavía tiene buggy para el juego Dota-2 y algunos otros juegos. El uso de ambos gráficos y la tubería de cálculo al mismo tiempo puede ocultar aún más la latencia.

si opencl tenía vulkan en él, entonces ha estado oculto al público durante 7-9 años. Si pudieran agregarlo, ¿por qué no lo hicieron para opengl (tal vez debido a la presión de physx / cuda?)

Vulkan se promociona como una API de cómputo y gráfica, sin embargo, encontré muy pocos recursos para la parte de cómputo, ¿por qué?

Necesita más tiempo, al igual que opencl.

Puedes consultar la información sobre los shaders de cálculo aquí:

https://www.khronos.org/registry/vulkan/specs/1.0/xhtml/vkspec.html#fundamentals-floatingpoint

Aquí hay un ejemplo de sistema de partículas gestionado por compiladoras:

https://github.com/SaschaWillems/Vulkan/tree/master/computeparticles

debajo de eso, hay ejemplos de procesadores de rayos y procesamiento de imágenes también.

Vulkan tiene ventajas de rendimiento sobre OpenGL. ¿Lo mismo es cierto para Vulkan vs OpenCl?

• Vulkan no necesita sincronizarse para otra API. Se trata de sincronización de búferes de comando entre colas de comando.
• OpenCL necesita sincronizarse con opengl o directx (o vulkan?) Antes de usar un búfer compartido (cl-gl o dx-cl interop buffers). Esto tiene una sobrecarga y debe ocultarse mediante el intercambio de búferes y la canalización. Si no existe un búfer compartido, puede ejecutarse simultáneamente en hardware moderno con opengl o directx.

OpenCL es tristemente notorio por ser más lento que CUDA

Lo fue, pero ahora es un cuda maduro y desafiante, especialmente con un soporte de hardware mucho más amplio desde todos los juegos de gpus a fpgas usando la versión 2.1, como en el futuro Intel puede poner un fpga en un Core i3 y habilitarlo para (soft-x86 core ip ) modelo de cpu de varios núcleos que cierra la brecha entre un rendimiento de gpu y un cpu para mejorar su experiencia de juego en cpu-physx o simplemente permite que una implementación de física abierta le dé forma y use al menos% 90 área de troquel en lugar de un% 10 de soft-core -% 20 área efectivamente utilizada.

Con el mismo precio, AMD gpus puede calcular más rápido en el sistema operativo y con la misma potencia de cómputo Intel igpus consume menos potencia. ( edición : excepto cuando los algoritmos son sensibles al rendimiento de la caché donde Nvidia tiene una mano superior)

Además, escribí un núcleo de SGEMM opencl y lo ejecuté en un HD7870 a 1.1 Tflops y comprobé Internet. Luego vi un henchmark de SGEMM en un GTX680 para el mismo rendimiento usando un título popular en CUDA (la relación de precios de gtx680 / hd7870 era 2). (edición: el cc3.0 de Nvidia no usa el caché L1 al leer arreglos globales y mi kernel era puramente local / memoria compartida + algunos registros "en mosaico")

¿SYCL usa OpenCL internamente o podría usar vulkan? ¿O no utiliza ninguno de los dos y, en su lugar, se basa en las especificaciones específicas del proveedor de bajo nivel que se implementarán?

Aquí,

https://www.khronos.org/assets/uploads/developers/library/2015-iwocl/Khronos-SYCL-May15.pdf

dice

Proporciona métodos para lidiar con objetivos que no tienen OpenCL (¡todavía!)

Una implementación de CPU de reserva es debuggable!

por lo que puede recurrir a una versión de subproceso puro (similar al aparapi de Java).

Puede acceder a objetos OpenCL desde objetos SYCL Puede construir objetos SYCL desde objeto OpenCL

Interop con OpenGL permanece en SYCL - Utiliza las mismas estructuras / tipos

utiliza opencl (¿quizás no directamente, pero con una comunicación de controlador mejorada?), se desarrolla en paralelo a opencl pero puede recurrir a subprocesos.

Desde el dispositivo integrado OpenCL 1.2 más pequeño hasta los aceleradores OpenCL 2.2 más avanzados