Et la facilité d’écriture ?
C’est le gros défaut de cette approche : plus bas niveau que CUDA, SYCL et cie.
Si je prends Vulkan, l’API la plus avancée, il faut d’abord au minimum1…
- Charger la bibliothèque Vulkan.
- Créer une instance d’API en spécifiant ses paramètres globaux (ex: logging).
- Choisir un ou plusieurs physical devices (ex : GPU intégré ou discret, émulation CPU).
- Créer pour chacun un contexte device et sa ou ses command queues (cf CUDA streams).
Puis pour me préparer à un calcul donné, je dois…
- Ecrire un shader en spécifiant l’interface avec l’hôte (buffers, images…).
- Compiler le shader, d’abord en SPIR-V puis en binaire adapté au device.
- Créer des ressources à attacher au shader : buffers, images & samplers…
- Créer un pipeline qui spécifie les aspects stables de l’interface shader-hôte.
- Grouper les ressources en descriptor sets adaptés au pipeline.
Et enfin, pour chaque batch de calculs que j’exécute, je dois…
- Construire un ou plusieurs command buffers qui mettent en place un pipeline, attachent les descriptor sets, programment des exécutions du shader, éventuellement à répétition…
- Les soumettre à la ou les command queues appropriées.
- Bien gérer la synchronisation entre ces jobs et avec l’hôte.
1
Quelques étapes en plus pour du rendu écran. Chaque étape est hautement configurable.