Azrael_CV (./6) :
Par contre je ne sais pas ce que tu entends par "RAM Locale GPU, RAM Globale GPU, RAM private GPU" ? Tu parles de la mémoire texture et autres ? Dans un contexte de programmation parallèle avec des accélérateurs et coprocesseurs, le programmeur s'intéresse uniquement à la mémoire globale. Ceux qui veulent utiliser la mémoire de "texture" par exemple devront passer par le langage spécifique au proc visé.

Disons qu'il me semble que pour être performant, il faut vraiment faire gaffe à quelle mémoire tu accèdes dans ton algorithme (voir les différents mémoires d'opencl) parce qu'utiliser tout le temps la mémoire globale dans le kernel, çà à l'air très couteux Sans parler des mémoires _locale à une compute unit:

Bref je ne sais pas comment rendre le modèle mémoire du C (un seul espace mémoire pour l'application) compatible avec Open* (Plusieurs espaces mémoires sont disponibles) tout en gardant les choses simples.

Surtout que j'avais lu un article d'un fabricant hard qui se demandait s'ils allaient réussir à maintenir la cohérence de toutes les différentes mémoires dans le futur,
où si ils allaient en déléguer une partie au soft.

Azrael_CV (./6) :
J'aime bien cette page qui résume ce qui marche, ou pas, sur un GPGPU : http://lava.cs.virginia.edu/gpu_summary.html

Ca à l'air bien

Azrael_CV (./9) :
Par pour cosinus et exponentielle. http://developer.download.nvidia.com/CUDA/training/floatingpointwebinarjune2011.pdf (pas d'autre document

Je ne comprends pas. IEEE 754 n'impose pas grand chose dans mes souvenirs pour exp et cos.
Seulement pour + * - / et sqrt
Par contre, opencl impose des précisions pour chaque opération (pas très élevés par ailleurs).

Azrael_CV (./6) :
Le seul hic est peut-on se servir du GPGPU pour faire autre chose que ce qui est du domaine de l'imagerie ?

Ca risque de faire comme pour le processeur CELL avec des milliers de SPU