Implémentation d'algorithmes via des shaders de calcul vs des shaders de pipeline

Avec la disponibilité des shaders de calcul pour DirectX et OpenGL, il est désormais possible d'implémenter de nombreux algorithmes sans passer par le pipeline de rastérisation et d'utiliser à la place l'informatique à usage général sur le GPU pour résoudre le problème.

Pour certains algorithmes, cela semble devenir la solution canonique intuitive car ils ne sont pas intrinsèquement basés sur la pixellisation, et les shaders basés sur la pixellisation semblent être une solution de contournement pour exploiter la puissance du GPU (exemple simple: créer une texture de bruit. Aucun quad n'a besoin d'être pixellisé ici ).

Étant donné un algorithme qui peut être mis en œuvre dans les deux sens, y a-t-il des avantages de performance (potentiels) généraux par rapport à l'utilisation de shaders de calcul par rapport à la voie normale? Y a-t-il des inconvénients que nous devrions surveiller (par exemple, y a-t-il une sorte de surcharge inhabituelle pour passer de / à des shaders de calcul lors de l'exécution)?

Y a-t-il peut-être d'autres avantages ou inconvénients à considérer lors du choix entre les deux?

Il n'y a pas de bonne réponse si vous souhaitez bénéficier directement de l'approche de calcul shadrs / GPGPU, cela dépend fortement du type d'algorithme que vous mettez en œuvre, les shaders de calcul et CUDA / OpenCL sont une approche plus généralisée pour surmonter certaines des limitations de ces vieilles langues d'ombrage piratent. les avantages les plus importants que vous obtiendrez:

• Accès aux informations spatiales. dans l'ancien hack GLSL (enfin, c'était un hack!) ne donne que peu d'informations sur les fragments voisins car il utilise des coordonnées de texture. Dans les shaders de calcul / CUDA / OpenCL, l'accès aux informations spatiales est beaucoup plus flexible, vous pouvez désormais implémenter des algorithmes comme l' égalisation d'histogramme sur le GPU avec un accès de texture / tampon non ordonné.
• Vous donne la synchronisation des threads et atomique .
• Espace de calcul: l'ancien hack GLSL connectera en dur l'espace de calcul sommet / fragment à votre shader. Le shader de fragments fonctionnera avec le nombre de fragments, le shader de vertex fonctionnera avec le nombre de sommets. Dans le shader de calcul, vous définissez votre propre espace.
• Évolutivité : votre shader de calcul / CUDA / OpenCL peut évoluer jusqu'au nombre de SM GPU (Streaming Multiprocessor) disponibles contrairement à votre ancien shader GLSL qui devrait être exécuté sur le même SM. (Sur la base des commentaires de Nathan Reed, il dit que ce n'est pas vrai et que les shaders devraient évoluer aussi bien que les shaders de calcul. Je ne suis toujours pas sûr d'avoir besoin de vérifier la documentation).
• Changement de contexte : il devrait y avoir un changement de contexte, mais je dirais que cela dépend de l'application, donc votre meilleur pari est de profiler votre application.

Eh bien, à mon avis , si vous voulez suivre la voie des shaders de calcul, même si certains algorithmes peuvent être plus adaptés, il y a certaines considérations que vous devez prendre en compte:

1. Matériel et compatibilité descendante . Les shaders de calcul ne sont disponibles que dans du matériel plus récent et si vous optez pour un produit commercial (par exemple un jeu), vous devez vous attendre à ce que de nombreux utilisateurs ne soient pas en mesure d'exécuter votre produit.
2. Vous avez généralement besoin de connaissances supplémentaires en architecture GPU / CPU , en programmation parallèle et en multithreading (par exemple, partage de mémoire, cohérence de la mémoire, synchronisation des threads, atomique et son effet sur les performances) que vous n'avez généralement pas besoin d'utiliser un shader rounte normal .
3. Ressources d'apprentissage , par expérience, il y a beaucoup moins de ressources d'apprentissage pour les shaders de calcul, OpenCL et CUDA (qui offrent également l'interopérabilité OpenGL) que la route des shaders habituelle.
4. Outils de débogage , avec le manque de débogage approprié, le développement d'outils peut devenir beaucoup plus difficile que la plupart des shaders, au moins les shaders peuvent être débogués visuellement.
5. Je m'attends à ce que les shaders de calcul donnent de meilleures performances que le même algorithme dans d'autres shaders; si elles ont été faites correctement en tenant compte des choses du point 2, car elles ont été conçues pour éviter les étapes supplémentaires pour le rendu graphique. Mais je n'ai aucune preuve concrète pour étayer ma demande.
6. Vous devriez également envisager CUUDA / OpenCL pour GPGPU si vous suivez cette voie.

Néanmoins, je suis sûr que c'est formidable pour l'avenir et que ce sera une excellente expérience d'apprentissage. Bonne chance!