OpenCL, Vulkan, Sycl
J'essaie de comprendre l'écosystème OpenCL et comment le vulkan entre en jeu.
- Je comprends qu'OpenCL est un framework pour exécuter du code vers gpus ainsi que cpu - en utilisant des noyaux qui peuvent être compilés en SPIR
- Vulkan peut également être utilisé comme une API de calcul en utilisant le même langage SPIR
- SYCL est une nouvelle spécification qui permet d'écrire du code opencl en tant que norme appropriée conforme à c ++ 14. Je crois comprendre qu'il n'y a pas encore de mise en œuvre gratuite de cette spécification.
Étant donné que:
Quel est le lien entre OpenCL et Vulkan? Je comprends qu'OpenCL est de niveau supérieur et résume les appareils, mais utilise-t-il (ou pourrait-il) Vulkan en interne? (au lieu de compter sur des pilotes spécifiques au fournisseur)
Vulkan est annoncé à la fois comme une API de calcul et graphique, mais j'ai trouvé très peu de ressources pour la partie de calcul - pourquoi?
Vulkan a des avantages de performance par rapport à OpenGL. Est-ce la même chose pour Vulkan vs OpenCl? (OpenCL est malheureusement connu pour être plus lent que CUDA)
SYCL utilise-t-il OpenCL en interne ou pourrait-il utiliser vulkan? Ou n'utilise-t-il ni l'un ni l'autre et s'appuie-t-il plutôt sur des API spécifiques de bas niveau à implémenter?
Quel est le lien entre OpenCL et Vulkan? Je comprends qu'OpenCL est de niveau supérieur et résume les appareils, mais utilise-t-il (ou pourrait-il) Vulkan en interne?
Ils ne sont pas du tout liés les uns aux autres.
Eh bien, ils utilisent techniquement le même langage de shader intermédiaire, mais Vulkan interdit le modèle d'exécution du noyau, et OpenCL interdit le modèle d'exécution du shader. Pour cette raison, vous ne pouvez pas simplement prendre un shader destiné à OpenCL et le coller dans Vulkan, ou vice-versa.
Vulkan est annoncé à la fois comme une API de calcul et graphique, mais j'ai trouvé très peu de ressources pour la partie de calcul - pourquoi?
Parce que le groupe Khronos aime les présentations marketing trompeuses.
Vulkan n'est pas plus une API de calcul qu'OpenGL. Il peut avoir des shaders de calcul, mais leur fonctionnalité est limitée. Le genre de choses que vous pouvez faire dans une opération de calcul OpenCL n'est tout simplement pas disponible via OpenGL/Vulkan CS.
Les CS de Vulkan, comme les CS d'OpenGL, sont destinés à être utilisés pour une chose: pour prendre en charge les opérations graphiques. Pour effectuer un tri sélectif, créez des commandes graphiques indirectes, manipulez des systèmes de particules, etc. Les CS fonctionnent avec la même précision numérique que les shaders graphiques.
Vulkan a des avantages de performance par rapport à OpenGL. Est-ce la même chose pour Vulkan vs OpenCl?
Les performances d'un système de calcul reposent principalement sur la qualité de sa mise en œuvre. Ce n'est pas OpenCL qui est lent; c'est votre implémentation OpenCL qui est plus lente qu'elle ne pourrait l'être.
Les Vulkan CS ne sont pas différents à cet égard. La performance sera basée sur la maturité des pilotes.
En outre, il y a le fait que, encore une fois, il y a beaucoup de choses que vous pouvez faire dans une opération de calcul OpenCL que vous ne pouvez pas faire dans un Vulkan CS.
SYCL utilise-t-il OpenCL en interne ou pourrait-il utiliser vulkan?
Du groupe Khronos:
SYCL (prononcé "faucille") est une couche d'abstraction multiplateforme sans redevance qui s'appuie sur les concepts sous-jacents, la portabilité et l'efficacité d'OpenCL ...
Alors oui, il est construit sur OpenCL.
Quel est le lien entre OpenCL et Vulkan?
Ils peuvent tous deux canaliser un travail séparable de l'hôte vers le GPU et le GPU vers l'hôte à l'aide de files d'attente pour réduire les frais de communication à l'aide de plusieurs threads. Directx-opengl ne peut pas?
OpenCL: version initiale du 28 août 2009. Prise en charge matérielle plus large. Les pointeurs sont autorisés mais uniquement pour être utilisés dans l'appareil. Vous pouvez utiliser la mémoire locale partagée entre les threads. Il est beaucoup plus facile de démarrer un monde bonjour. A une surcharge API pour les commandes sauf si elles sont mises en file d'attente côté périphérique. Vous pouvez choisir une synchronisation implicite multi-appareils ou une gestion explicite. Les bugs sont principalement corrigés pour 1.2 mais je ne connais pas la version 2.0.
Vulkan: première version le 16 février 2016 (mais progrès depuis 2014). Prise en charge matérielle plus étroite. SPIR-V peut-il gérer les pointeurs? Peut être pas? Pas d'option de mémoire locale? Difficile de commencer le monde bonjour. Moins de frais généraux api. Pouvez-vous choisir la gestion implicite multi-appareils? Toujours buggy pour le jeu Dota-2 et quelques autres jeux. L'utilisation à la fois de graphiques et de pipeline de calcul peut masquer encore plus de latence.
si opencl contenait du vulkan, alors il a été caché au public pendant 7 à 9 ans. S'ils pouvaient l'ajouter, pourquoi ne l'ont-ils pas fait pour opengl? (Peut-être à cause de la pression de physx/cuda?)
Vulkan est annoncé à la fois comme une API de calcul et graphique, mais j'ai trouvé très peu de ressources pour la partie de calcul - pourquoi?
Il a besoin de plus de temps, tout comme opencl.
Vous pouvez consulter les informations sur les shaders de calcul ici:
https://www.khronos.org/registry/vulkan/specs/1.0/xhtml/vkspec.html#fundamentals-floatingpoint
Voici un exemple de système de particules géré par des shaders de calcul:
https://github.com/SaschaWillems/Vulkan/tree/master/computeparticles
en dessous, il y a aussi des raytracers et des exemples de traitement d'image.
Vulkan a des avantages de performance par rapport à OpenGL. Est-ce la même chose pour Vulkan vs OpenCl?
- Vulkan n'a pas besoin de se synchroniser pour une autre API. Il s'agit de la synchronisation des tampons de commande entre les files d'attente de commandes.
- OpenCL doit se synchroniser avec opengl ou directx (ou vulkan?) Avant d'utiliser un tampon partagé (tampons d'interopérabilité cl-gl ou dx-cl). Cela a un surcoût et vous devez le masquer à l'aide de l'échange de tampon et du pipelining. S'il n'existe aucun tampon partagé, il peut s'exécuter simultanément sur du matériel moderne avec opengl ou directx.
OpenCL est malheureusement connu pour être plus lent que CUDA
C'était le cas, mais maintenant sa maturité et ses défis, en particulier avec un support matériel beaucoup plus large de tous les GPU de jeu aux fpgas utilisant la version 2.1, comme à l'avenir Intel peut mettre un fpga dans un Core i3 et l'activer pour (soft-x86 core ip ) modèle de processeur à plusieurs cœurs réduisant l'écart entre les performances d'un processeur et un processeur pour mettre à niveau son expérience de jeu cpu-physx ou simplement laisser une implémentation physique opencl le façonner et utiliser au moins% 90 die-area au lieu d'un soft-core% 10 -% 20 zone effectivement utilisée.
Avec le même prix, les GPU AMD peuvent calculer plus rapidement sur opencl et avec la même puissance de calcul, les igpus Intel consomment moins d'énergie. ( edit : sauf lorsque les algorithmes sont sensibles aux performances du cache où Nvidia a l'avantage)
En outre, j'ai écrit un noyau SGCL OpenCl et exécuté sur un HD7870 à 1,1 Tflops et vérifié Internet, puis j'ai vu un indice SGEMM sur un GTX680 pour les mêmes performances en utilisant un titre populaire sur CUDA! (Le rapport de prix de gtx680/hd7870 était de 2). (edit: le cc3.0 de Nvidia n'utilise pas le cache L1 lors de la lecture des tableaux globaux et mon noyau était purement de la mémoire locale/partagée + certains registres "en mosaïque")
SYCL utilise-t-il OpenCL en interne ou pourrait-il utiliser vulkan? Ou n'utilise-t-il ni l'un ni l'autre et s'appuie-t-il plutôt sur des API spécifiques de bas niveau à implémenter?
Ici,
https://www.khronos.org/assets/uploads/developers/library/2015-iwocl/Khronos-SYCL-May15.pdf
dit
Fournit des méthodes pour traiter les cibles qui n'ont pas OpenCL (pour l'instant!)
Une implémentation CPU de secours est débogable!
il peut donc revenir à une version purement filetée (similaire à l'apariap de Java).
Peut accéder aux objets OpenCL à partir d'objets SYCL Peut construire des objets SYCL à partir d'un objet OpenCL
Interop avec OpenGL reste dans SYCL - Utilise les mêmes structures/types
il utilise opencl (peut-être pas directement, mais avec une communication de pilote mise à niveau?), il se développe parallèlement à opencl mais peut se replier sur les threads.
du plus petit appareil embarqué OpenCL 1.2 aux accélérateurs OpenCL 2.2 les plus avancés