Souvent les GPUs exposent des instructions hardware permettant d'optimiser les rendus graphiques, il est peut-être possible d'en tirer parti pour faire une transformée de Fourier accélérée.
Je me suis mal exprimé. Tout à fait d'accord que certains problèmes (typiquement une transformé de fourier) sont plus adaptés à un GPU qu'un CPU, mais cela ne veut pas dire que ce n'est pas optimisable sur CPU et que le jeux n'en vaut pas la chandelle. En ce moment on assiste à une grande passion pour le GPU, mais si les développeurs passaient autant de temps à optimiser pour CPU qu'il le font pour GPU, beaucoup de code CPU tourneraient bien plus vite.
Programmer pour GPU c'est globalement faire du C avec d’énormes contraintes. Du C où tu sais comment les données sont disposées en mémoire, du C où tu sais comment la machine charge les données. Du C où tu essayes de ne pas faire de if parce que c'est mal. Du C où tu n'aimes pas les accès aléatoire au données. Du C où tu fais toi même les copies entre la ram et le cache parce que la machine ne le fait pas pour toi. Du C sans fonctions récursives. Du C sans types "pratiques" (les doubles… LOL…).
Les instructions hardware disponibles dans un GPU sont souvent liées au pipeline graphique (globalement: remplir des triangles), qui n'est pas exposé dans OpenCL.
En pratique ce que va t'exposer OpenCL c'est certaines fonctions optimisées ou calculs vectoriels, mais tout cela est aussi disponible sur un bon CPU (sse/avx). Le truc c'est qu'avec un peu de chance, sur CPU ton compilateur va savoir exploiter cela tout seul, sur GPU il faut le faire à la main.
Ce qui fait la différence entre un GPU et un CPU c'est que l'architecture est différente, ainsi en fonction du type de problème à traiter, il est clair qu'un GPU sera plus adapté et pourra roxer à mort du pinguin en performance (en fait tout les problèmes qui peuvent se décomposer en une grosse quantité de sous problèmes identiques et indépendants nececitant beaucoup de calcul et générant peu de transactions mémoire).
Donc un GPU n'est pas une bête simple à domestiquer et un code "naïf" sur GPU ne va pas donner grand chose comparé au même code naïf sur CPU.
C'est sûr, mais pour y avoir goûté ça pique vraiment, donc ça se comprend qu'on ait envie d'avoir un driver OpenCL plutôt que de devoir jouer avec des framebuffer objects, des textures, du glsl…
Essayes OpenCL… C'est la même chose, tu remplaces les framebuffer objects par des buffer objects, les textures par des images et le glsl par de l'OpenCl ;) C'est juste plus générique et permet de cibler avec le même code deux plateformes hétérogènes (CPU et GPU), mais ce n'est finalement pas si simble.
tl/dr: Le GPU c'est cool. J'aimerais bien avoir OpenCL disponible de partout sans me poser de question, mais s'il vous plait, arrêter de brandir le mot GPU de partout en disant que cela va sauver le monde et que c'est la solution à tout les problèmes, après il y a des décideurs qui écoutent…
[^] # Re: OpenCL, Intel, hem...
Posté par Guillaum (site web personnel) . En réponse à la dépêche Sortie du noyau Linux 3.8. Évalué à 10.
Je me suis mal exprimé. Tout à fait d'accord que certains problèmes (typiquement une transformé de fourier) sont plus adaptés à un GPU qu'un CPU, mais cela ne veut pas dire que ce n'est pas optimisable sur CPU et que le jeux n'en vaut pas la chandelle. En ce moment on assiste à une grande passion pour le GPU, mais si les développeurs passaient autant de temps à optimiser pour CPU qu'il le font pour GPU, beaucoup de code CPU tourneraient bien plus vite.
Programmer pour GPU c'est globalement faire du C avec d’énormes contraintes. Du C où tu sais comment les données sont disposées en mémoire, du C où tu sais comment la machine charge les données. Du C où tu essayes de ne pas faire de if parce que c'est mal. Du C où tu n'aimes pas les accès aléatoire au données. Du C où tu fais toi même les copies entre la ram et le cache parce que la machine ne le fait pas pour toi. Du C sans fonctions récursives. Du C sans types "pratiques" (les doubles… LOL…).
Les instructions hardware disponibles dans un GPU sont souvent liées au pipeline graphique (globalement: remplir des triangles), qui n'est pas exposé dans OpenCL.
En pratique ce que va t'exposer OpenCL c'est certaines fonctions optimisées ou calculs vectoriels, mais tout cela est aussi disponible sur un bon CPU (sse/avx). Le truc c'est qu'avec un peu de chance, sur CPU ton compilateur va savoir exploiter cela tout seul, sur GPU il faut le faire à la main.
Ce qui fait la différence entre un GPU et un CPU c'est que l'architecture est différente, ainsi en fonction du type de problème à traiter, il est clair qu'un GPU sera plus adapté et pourra roxer à mort du pinguin en performance (en fait tout les problèmes qui peuvent se décomposer en une grosse quantité de sous problèmes identiques et indépendants nececitant beaucoup de calcul et générant peu de transactions mémoire).
Donc un GPU n'est pas une bête simple à domestiquer et un code "naïf" sur GPU ne va pas donner grand chose comparé au même code naïf sur CPU.
Essayes OpenCL… C'est la même chose, tu remplaces les framebuffer objects par des buffer objects, les textures par des images et le glsl par de l'OpenCl ;) C'est juste plus générique et permet de cibler avec le même code deux plateformes hétérogènes (CPU et GPU), mais ce n'est finalement pas si simble.
tl/dr: Le GPU c'est cool. J'aimerais bien avoir OpenCL disponible de partout sans me poser de question, mais s'il vous plait, arrêter de brandir le mot GPU de partout en disant que cela va sauver le monde et que c'est la solution à tout les problèmes, après il y a des décideurs qui écoutent…