96 votes

Meilleure approche pour GPGPU/CUDA/OpenCL en Java ?

Le calcul à usage général sur les unités de traitement graphique ( GPGPU ) est un concept très intéressant pour exploiter la puissance du GPU pour tout type de calcul.

J'aimerais utiliser le GPGPU pour le traitement des images, les particules et les opérations géométriques rapides.

À l'heure actuelle, il semble que les deux concurrents dans ce domaine soient CUDA et OpenCL. J'aimerais savoir :

  • OpenCL est-il déjà utilisable depuis Java sur Windows/Mac ?
  • Quelles sont les bibliothèques qui permettent de s'interfacer avec OpenCL/CUDA ?
  • Est-il possible d'utiliser directement JNA ?
  • Est-ce que j'oublie quelque chose ?

Toute expérience du monde réel/exemple/récit de guerre est apprécié.

1 votes

J'imagine que la programmation de GPU en Java serait difficile, vu l'utilisation des pointeurs dans la programmation de cuda. Je ne sais pas s'il y aurait beaucoup d'avantages à utiliser Java pour la programmation de périphériques, car il est peu probable que vous disposiez de toutes les fonctionnalités/librairies Java implémentées qui différencient Java de C++.

2 votes

J'ai vu des démos Java impressionnantes qui utilisaient GLSL et probablement CUDA, donc c'est certainement possible.

1 votes

Avez-vous vérifié jcuda.org et jocl.org ?

62voto

zOlive Points 1011

AFAIK, JavaCL / OpenCL4Java est la seule liaison OpenCL disponible sur toutes les plates-formes à l'heure actuelle (y compris MacOS X, FreeBSD, Linux, Windows, Solaris, toutes dans les variantes Intel 32, 64 bits et ppc, grâce à son utilisation de JNA ).

Il contient des démonstrations qui fonctionnent bien à partir de Java Web Start, du moins sur Mac et Windows (pour éviter les plantages aléatoires sous Linux, voir cette page wiki comme ceci Démonstration de particules .

Il est également livré avec quelques utilitaires (génération de nombres aléatoires GPGPU, réduction parallèle de base, algèbre linéaire) et une DSL Scala .

Enfin, il s'agit des plus anciennes fixations disponibles (depuis juin 2009) et il dispose d'une communauté active d'utilisateurs .

(Disclaimer : Je suis JavaCL de l'auteur :-))

0 votes

Oh, j'étais si excité pour le JNLP, mais apparemment il n'aime pas mon macbook. Tant pis pour le multiplateforme.

5 votes

@Karl Oh désolé, j'ai cassé le JNLP (le JAR a récemment changé de nom) ! C'est maintenant corrigé, j'espère que vous réessayerez... (et pour ce qui est de la multi-plateforme : il était cassé de manière cohérente sur toutes les plateformes ;-))

3 votes

Le récent renforcement de la sécurité de Java 7 fait échouer le Web Start de Particle Demo avec une exception.

35voto

gfrost Points 695

Vous pouvez également envisager Aparapi . Il vous permet d'écrire votre code en Java et tentera de convertir le bytecode en OpenCL au moment de l'exécution.

Divulgation complète. Je suis le développeur d'Aparapi.

0 votes

L'aparapi est-il toujours maintenu ?

0 votes

@MrJedi : Je pense que oui, le dernier commit sur github ne date que de quelques jours : github.com/aparapi/aparapi

0 votes

Il est "quelque peu entretenu" ;) Je suis un mainteneur.

12voto

Ivan Points 854

CUDA est une modification du C. Pour écrire un noyau CUDA, vous devez coder en C, puis compiler sous forme exécutable avec le compilateur CUDA de Nvidia. Le code natif produit peut alors être lié à Java en utilisant JNI. Donc, techniquement, vous ne pouvez pas écrire le code du noyau à partir de Java. Il y a JCUDA http://www.jcuda.de/jcuda/JCuda.html Il vous fournit les apis de Cuda pour la gestion générale de la mémoire et des périphériques, ainsi que certaines méthodes Java implémentées dans CUDA et enveloppées dans JNI (FFT, certaines méthodes d'algèbre linéaire etc etc ).

D'autre part, OpenCL n'est qu'une API. Les noyaux OpenCL sont des chaînes simples passées à l'API. Ainsi, en utilisant OpenCL depuis Java, vous devriez être en mesure de spécifier vos propres noyaux. Le binding OpenCL pour Java est disponible ici. http://www.jocl.org/ .

2 votes

Si JNA ( jna.dev.java.net ) est pris en charge par votre plate-forme, je l'utiliserais pour invoquer le code natif, car cela demande beaucoup moins d'efforts que de coder une bibliothèque JNI.

11voto

halfwarp Points 645

J'utilise JOCL et j'en suis très satisfait.

Le principal inconvénient d'OpenCL par rapport à CUDA (du moins pour moi) est le manque de bibliothèques disponibles (Thrust, CUDPP, etc.). Cependant, CUDA peut être facilement porté vers OpenCL, et en regardant comment ces bibliothèques fonctionnent (algorithmes, stratégies, etc.), c'est en fait très agréable car vous apprenez beaucoup avec cela.

7voto

karl Points 41

Je sais qu'il est tard mais regardez ça : https://github.com/pcpratts/rootbeer1

Je n'ai pas travaillé avec, mais il semble beaucoup plus facile à utiliser que les autres solutions.

Depuis la page du projet :

Rootbeer est plus avancé que les liaisons de langage Java CUDA ou OpenCL. Avec les liaisons, le développeur doit sérialiser des graphes complexes d'objets en tableaux de types primitifs. Avec Rootbeer, cette opération est réalisée automatiquement. Toujours avec les liaisons de langage, le développeur doit écrire le noyau du GPU en CUDA ou OpenCL. Avec Rootbeer, une analyse statique du bytecode Java est effectuée (à l'aide de Soot) et le code CUDA est automatiquement généré.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X