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

  1. Charger la bibliothèque Vulkan.
  2. Créer une instance d’API en spécifiant ses paramètres globaux (ex: logging).
  3. Choisir un ou plusieurs physical devices (ex : GPU intégré ou discret, émulation CPU).
  4. 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…

  1. Ecrire un shader en spécifiant l’interface avec l’hôte (buffers, images…).
  2. Compiler le shader, d’abord en SPIR-V puis en binaire adapté au device.
  3. Créer des ressources à attacher au shader : buffers, images & samplers
  4. Créer un pipeline qui spécifie les aspects stables de l’interface shader-hôte.
  5. Grouper les ressources en descriptor sets adaptés au pipeline.

Et enfin, pour chaque batch de calculs que j’exécute, je dois…

  1. 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…
  2. Les soumettre à la ou les command queues appropriées.
  3. 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.