Les graphiques sont l'un de ces problèmes "embarrassants parallèles". Haskell est censé être vraiment, vraiment bon pour le traitement parallèle. Donc, ma question est:
Quelle est la meilleure façon de jeter autant de noyaux de processeur que possible lors d'un problème de rendu?
est-il possible d'obtenir le GPU de faire la tâche à la place?
Par "problème de rendu", je veux dire des problèmes tels que:
La couleur de chaque pixel est une fonction pure de ses coordonnées.
Nous commençons par une image "entrée" existante et que chaque couleur de pixel "sortie" est une fonction pure du pixel d'entrée correspondant, ou peut-être un petit quartier de ces pixels.
Concernant n ° 1: Cela ressemble à ce qu'il est trivial, mais en fait, ce n'est pas le cas. Il existe plusieurs choix possibles de la structure de données pour stocker les pixels calculés (qui influent sur la manière dont vous pouvez y accéder, ainsi que la facilité avec laquelle vous pouvez vider le résultat sur un disque ou un écran). Il existe plusieurs façons d'exécuter sur plusieurs cœurs. Et ainsi de suite.
Il me semble que les données parallèles Haskell seraient un choix idéal pour ce type de chose. Cependant, la dernière fois que j'ai vérifié, DPH ne fonctionne pas encore. Donc c'est ça. Même en supposant que cela fonctionnait, vous créez probablement un tableau parallèle pour maintenir les pixels, puis vous devez copier les pixels pour les afficher à l'écran ou les écrire sur le disque.
J'essaierais de susciter chaque pixel, mais c'est probablement beaucoup trop fin. Je pourrais faire des pixels une liste et utiliser l'une des stratégies de liste parallèle. Ou je pourrais en faire un tableau immuable (non poxed?) Et écrire du code manuel pour commencer les étincelles. Ou je pourrais aller avec des threads explicites et des tableaux mutables. Ou je pourrais avoir un tas de travailleurs les enfermer des valeurs de pixel via un canal à un fil principal qui met les résultats au bon endroit. Ou ...
En résumé, il existe un nombre surprenant de possibilités ici, et je ne suis pas sûr qui est préférable.
Concernant n ° 2: évidemment ce type de problème est la raison entière que les GPU existent en premier lieu. Il est clair que le GPU est idéal pour attaquer ce type de problèmes. Ma question est plus "est-elle difficile de le faire de Haskell?"
3 Réponses :
Il y a Bindings RAW OpenCL , mais si vous voulez quelque chose qui vous aide à courir de haut niveau Code - plis et zips et maps, etc. - sur le GPU aujourd'hui, jetez un coup d'œil à Accélérer (Cuda Backend) et GPIPE (Backend OpenGL, pour le travail graphique; un peu Bitt depuis de nos jours) malheureusement)) .
En ce qui concerne les structures pour représenter une image rendue, une matrice non poxed est probablement votre meilleure mise: c'est l'ajustement le plus proche du matériel et vous ne faites généralement pas de mises à jour "incrémentalelles" pure sur un rendu.
La réponse courte à la question 1, en l'absence de plus en détail, est la suivante:
Écrivez votre code comme normal, à l'aide d'une bibliothèque de traitement de vecteur ou de tableau.
Si la bibliothèque ne le fais pas déjà pour vous, insérez des appels ou des combinaisons appropriés ou des combinaisons basés sur des calculs agricoles sur plusieurs processeurs.
Regardez à l'aide de REPA pour vos vecteurs - il est facile d'obtenir des opérations de Repa à utiliser N CPUS.
Si vous êtes confiant pour mélanger des langues, opencl est très polyvalent. Bien que le langage Opencl soit très proche d'être C (tellement pas haskell), vous pouvez écrire votre code de noyau dans un style plus ou moins fonctionnel et y penser comme cartographier ce noyau sur les coordonnées spatiales. Un avantage de faire des choses avec un cadre de programmation parallèle traditionnel comme Opencl est que vous pouvez vous appuyer sur le volume croissant de connaissances, les personnes HPC et les graphismes ont amassé au fil des ans dans de nombreux domaines d'application. Le reportage entre la CPU et le GPU est principalement indolore, mais vous devrez être conscient des considérations sur les types de données (par exemple, certains GPU ne prennent pas en charge la double précision).
J'ai écrit un didacticiel sur l'appelant à Opencl de Haskell . Il repose sur le relativement nouveau Bindings opencl (il existe plusieurs liaisons OPENCL sur Hackage, je ne peux pas attester de leur qualité relative) .
Je suppose que je me demandais vraiment deux questions ici - comment utiliser efficacement la CPU et comment utiliser efficacement le GPU. L'entrée de blog liée fait un travail assez décent pour expliquer comment utiliser le GPU, avec Opencl ou OpenGL. J'accepte cela comme une réponse à toute la question.
Je ne pense pas que cela puisse cibler les GPU, mais le but des données parallèles haskell est de pouvoir faire ce genre de chose.