Windows 7 - Page 4

Brunni (./88) :
"Les cartes nVidia de 2007" = laquelle fait 600 fps, et appliqué sur une image de quelle taille?
Parce que bon si c'est une 8800 GTX et qu'elle fait un flou sur un écran 800x600 je veux bien croire que ma 7300 y arrive pas

1920x1200.
Je sais pas quelle carte en revanche.

Si tu redescends à un flou normal (kernel de 3x3), celui qui est utilisé pour de vrai, le chiffre exact est de 2200 MPix/s.
(1600 MPix/s pour le 5x5 que je donnais en exemple ci dessus)

./87 > "Les cartes NVidia de 2007" ? Mais quelles carte ? Une GeForce 7800GTX ? Une GeForce 8800 GTX ?
En tout cas je trouve pas ces chiffres mais je sais que chez moi, après test, Geforce 9400M @ 1280x800, un simple Gaussian Blur 5x5 séparé ça plafonne à 130 FPS... C'est très loin d'être la carte(enfin, chipset en l'occurrence) graphique la plus puissante du monde certes, mais c'est aussi bien loin d'être la plus pourrie...
Après le blur de Windows me semble en plutôt être un truc >= 7x7 donc ça bouffe plus, mais impossible de trouver les valeurs exactes donc bon...

Vu que c'est nVidia, j'imagine qu'ils ont pris leur meilleur modèle du moment où ils ont fait leur whitepaper.
[edit: vu la date du document, ça serait une 8800 Ultra]

Il est implémenté comment aussi ton flou gaussien ?
Parce que là, même avec un noyau en 23x23, ils sont encore à 1000MPix/s

A titre de comparaison, ils ont également implémenté un flou gaussien en utilisant une convolution avec libfftw, et ça tourne autour de 100MPix/s. D'ailleurs c'est amusant, l'implémentation avec libfftw est beaucoup moins influencée par la taille du noyau.

Fichier joint : ProcessingEffect.fx
J'ai testé avec XNA (c'était le plus rapide) peut être qu'en Direct3D natif ça gagne quelques FPS mais voilà... (Cela dit j'ai viré le Device.Clear ça a gagné 10FPS au lieu de dégrader les performances comme c'est "officiellement" sensé le faire)
Après si c'est vraiment une 8800 Ultra faut pas chercher bien loin .
Les cartes graphiques haut de gamme sont des montres de puissance, avec en général un nombre de stream processor hallucinant (128 pour une GeForce 8800 Ultra contre 16 pour une GeForce 9400 (M ou pas M)), ça aide énormément dans les opérations intensives de ce type. Celà dit c'est normalement très limité par le cache de texture également, mais en divisant l'opération en deux ça doit aider énormément de ce côté-ci je pense.
Enfin bref, ça a beau être faisable simplement, ça bouffe toujours des ressources, et a priori Aero a été optimisé au mieux pour minimiser l'utilisation du flou

on pourrait avoir un programme normal qui permet d'exécuter ton truc?

Fichier joint : BlurTest.7z

Il ne fait rien ton exe, il faut quelque chose de spécifique ?

si, ici il produit un désagrément encouru

J'ai mis un dxwebsetup et un lien vers le runtime XNA 3.1 à l'intérieur. Si après avoir installé ça ça marche pas faut modifier/recompiler le code vous même
(Et non y'a pas nécéssairement besoin de visual studio pour ça, mais ça peut aider)

ah il me manquait xna (je sais pas a quoi ça sert mais bon)

bref je me retrouve avec une tof en plein écran, je sais pas si elle est blurrée ou pas , mais ça marque 91fps avec ma gf 8400M.

(ce serait bien que tes progs zieutent la touche ESC pour quitter, et se chient dessus poliment (vous avez pas installé blabla))

Bon le .fx n'est pas du OpenGL Shader :/ ça doit etre l'equivalent de directX

et y'a besoin d'installer toutes ces merdes aussi pour Win7, ou c'est spécifique aux programmes de GC d'avoir systématiquement 15 dépendances ?

de 31 Mo + 45 à télécharger

./95> c'est une implémentation naïve de l'algorithme, c'est pour ça qu'il est lent ton code ^^

Tss y'a que 3 dépendances, .NET 3.5 SP1 (inclus dans Win7...) DirectX (si il est pas a jour c de votre faute) et XNA 3.1 (7,3 Mo...) faut pas déconner
Et puis c'est pas ma faute je vous donne gentiment le .fx pour que vous puissiez tester par vous même, mais y'en a qui demandent un programme tout compilé

Et sinon .fx c un DirectX Effect File comme son extension l'indique presque, et à titre d'info l'image originale est dans le code source si vous voulez vérifier que c'est vraiment blur

(Vive les HS \o/ )

./105 > Ben balance une implémentation pas naïve pour voir alors
Je vois pas comment faire beaucoup mieux que 5 texture fetch + 9 opérations arithmétiques par passe moi ^^

./106> nVidia separable convolution
(utilisable pour du gaussien, vu que les noyaux gaussien sont toujours séparables)

Je rêve ou tu viens de comparer du CUDA à du Direct3D/OpenGL ? Oo
Tu es au courant que ça a presque rien à voir ?
(Sinon je te signale que l'algo utilisé dans mon .fx *est* la convolution séparée...)

les fx sont pas compilés et chargés dans le GPU?

./108> Presque rien à voir... c'est juste strictement la même chose avec un enrobage un peu différent
(en gros les quelques points d'entrée du gpu permettant de le dissocier de la communication vers l'écran)

Oui et non, les fx sont pas des Pixel Shader et Vertex Shader, mais ils peuvent en contenir ^^
Les shader HLSL sont compilés et éxécutés sur le GPU (et 1 instruction shader ASM DirectX ne fait pas forcément 1 instruction native), mais le fonctionnement est pas du tout le même que dans une architecture CUDA...
Globalement CUDA t'offre des abstractions (et des optimisations) faites pour le calcul parallélisé, tandis qu'un API graphique (qui fonctionne lui sur toutes les cartes pas juste des GeForce ≥ 8) t'offre des abstractions (et des optimisations) faites pour obtenir un rendu graphique. Le matériel est le même dans l'un comme dans l'autre (enfin CUDA implique DirectX 10 mais pas l'inverse en fait...), mais n'est pas utilisé de la même manière pour l'un et l'autre.
Enfin quoi qu'il en soit que ce soit Windows ou Linux, le rendu est fait via un API Graphique, avec des Shader si besoin ^^

PS: Si CUDA n'apportait rien par rapport à un API graphique, est-ce que nVidia se serait vraiment cassé le cul pour développer tout un framework et des driver spéciaux avec ?
Et pourquoi ça ne fonctionne pas sur tous les GPU SM3.0 si c'est si "évidemment" la même chose ? -_-

Zephyr (./103) :
et y'a besoin d'installer toutes ces merdes aussi pour Win7, ou c'est spécifique aux programmes de GC d'avoir systématiquement 15 dépendances ?

D'un autre côté, ce n'est pas un programme vraiment destiné à être diffusé

Et son truc c'est vraiment pratique pour faire des jolis tests rapidement. (enfin je sais pas pour XNA mais MDX ça roxxait sévère en tous cas).

./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à.

quand je vois le nombre de FPS qu'on peut obtenir avec un filtre moyenneur pour faire un effet de feu le tout 100% en soft sur des machines pas super puissante, je vois mal comment un 5x5 peut justifier de tant allourdir mais bon

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...

et en quoi :
=> ça diffère au juste du message que t'as cité ?
=> ça remet en question ma remarque sur les performances présumées du flou de windows ?

Je sais pas mais t'avais l'air de dire que parce que une implémentation CUDA est rapide il en est forcément de même pour une implémentation "graphique".
En voulant tester l'implémentation CUDA sur mon mac ensuite, d'ailleurs ça a pas marché (merci nVidia de ne pas fournir les driver CUDA 2.3 pour ma GeForce 9400M...), j'ai vu qu'ils proposaient une implémentation "Pixel Shader-like" et je suis alors retourné voir ton document qui parle de CUDA sur tous les slide. Là j'ai fini par trouver que sur un slide, ils comparent cette implémentation "shder-like" à l'implémentation CUDA dont tout le reste papier cause exclusivement...
Donc désolé, tu devais très certainement parler de cette implémentation, mais t'aurai pu être plus clair en citant un papier qui ne cause de ça que sur 1 slide au milieu de tous les autres
Quoi qu'il en soit... Oui le flou (version texture) est lent (et si tu fais le calcul, entre une GeForce 9400M à ~150 fps et une GeForce 8800 Ultra à ~800 FPS, la différence est peut-être pas si abusée que ça) au point que sur une carte tout juste décente (je parle de ma 9400M oui ) ça ne puisse opérer qu'à un peu plus de 2 fois le framerate standard (60Hz/60FPS).
Après le flou de Windows ne peut pas être plus rapide (et je pense qu'ils utilisent au moins un 7x7) mais DWM a été bien optimisé pour ça. Normalement il maintient un cache des textures "en dessous" pour chaque fenêtre (+/-) afin de ne pas recalculer les quelques endroits où il y avait du flou à chaque image. Mais en mettant un truc en arrière plan (iTunes en l'occurence) qui bouffe énormément de refresh, j'ai aucun problème à faire saccader Aero sur mon Macbook par exemple...

Bref, désolé

PS: Plus généralement, et ça s'adresse pas spécialement à spectras, je vous rapelle également qu'à la base, les cartes graphiques ne sont *pas* faites pour faire 50 accès texture par rendu de pixel, et que même si actuellement l'architecture normale le permet, et que les cartes graphiques moyennes arrivent à obtenir des résultats décents (pour moi +/-120 fps c'est déjà décent...) dans ce domaine, cela n'a jamais été, et n'est pas encore vraiment leur point fort (à moins d'avoir une carte graphique Pro/haut de gamme bien entendu).

Pour savoir la taille du flou utilisé par Windows, il ne suffirait pas de dessiner un unique pixel blanc sur fond noir, de mettre une fenêtre avec une zone "floue" par dessus, de faire un screenshot et de zoomer avec un soft graphique ? Si c'est effectivement une convolution 2D, ça donnera directement la dimension et les coefficients de la matrice (à ceci près que s'il y a un alpha-blending en plus, il faudra d'abord l'identifier et le "neutraliser").

GoldenCrystal (./118) :
j'ai aucun problème à faire saccader Aero sur mon Macbook par exemple...

Ce qui prouve juste que Aero est pas forcement si bien optimisé que ça...