spectras (./114) :
./111> c'est une question de mots. L'apport de cuda c'est justement qu'il retire des choses, pemettant l'accès à une sous-partie de la chaine complète (tout comme à l'époque les shaders retiraient un élément de la chaîne, permettant de mettre un custom à la place).
Au final, le point important à retenir c'est qu'avec une GeForce 8800 Ultra, tu tiens les 600fps en calcul brut sur un flou fullscreen 5x5 en 1920x1280 (en pratique c'est vrai qu'il faut renvoyer l'image pour présentation après donc tu perdras un poil, mais c'est négligeable).

Ca permet surtout de mettre en relief le type de performances atteignable, et de ne pas justifier une surconsommation de ressources par un "c'est normal le flou ça met une carte vidéo à genoux". Tout simplement parce que c'est faux : un flou propre peut être extrêmement rapide s'il est implémenté correctement. Donc soit il est foireux (ce qui est possible), soit les éventuelles lenteurs ne viennent pas de là.

Mais non ça a rien à voir. -_-
Un API graphique te donne accès à des listes de triangles et des textures, qui dont tu accèdes par des coordonnées flottantes (et non entières), via un sampler configuré pour. Les coordonnées sont transformées, et interpolées par la carte graphique, avant d'être fournies une par une (enfin, de manière parallélisée) au pixel shader qui calculera la couleur finale en utilisant uniquement les informations et les fonctions auquelles il a accès. (i.e. Tu accèdes pas directement à un élément d'un tableau 2D, y'a déjà plein de calculs "négligeables" avant...)
Les cartes graphiques ont été conçues pour ça. CUDA tire parti de l'architecture sous-jacente qui a été mis en place pour permettre les "Unified Shaders" (i.e. tous les types de shader utilisent les mêmes "Stream Processor" donc tu gagnes en souplesse). Le fait que la carte graphique soit souple permet au driver graphique de dispatcher les différentes opérations au mieux, mais ça ne te donnera jamais accès à 100% des capacités offertes par l'architecture de la carte graphique comme le fait CUDA, tu resteras toujours limité par le fait qu'un pixel shader est un pixel shader, un vertex shader un vertex shader, et ainsi de suite...
Malheureusement les forums de nvidia semblent être down, mais via le cache de google tu peux trouver par exemple:

Source (en tinyurl car sinon yN bug)
This really depends on exactly what operations you're performing. If you simply take shader code and port it directly to CUDA using texture fetches, the performance will probably not be any better.

But if you take advantage of CUDA features (shared memory, scattered writes etc.), the performance could be much higher.

For example, we have implementations of histograms in the CUDA SDK that are much faster than anything possible with shaders.
I'm not sure why you say that with more filters you need more textures. The temporary storage requirements should be the same for both methods, although with CUDA can read and write to the same buffer which might help. The maximum program length is also much greater with CUDA, which might help you perform more operations in a pass.

Bref...