Tout est parti d'une idée saugrenue de tester DirectCompute, j'ai donc cherché des informations sur le RayTracing et implémenté un début d'algo.
 
Cette première implémentation a été réalisée en C# et cible le Framework 2, mais n'est compatible qu'avec Vista et 7 à cause des méthodes de détection des CPU (oui, il gère les machines multi-CPU, par contre je ne sais pas jusqu'à combien de threads )
 
Etant donné que je voulais tirer le maximum de performances, j'ai réalisé une petite appli qui me sert de bench perso, mais ne disposant pas de n'importe quel matériel des résultats pourraient m'être grandement utiles. Les principaux résultats dont j'ai besoin concernent les CPU avec HyperThreading, mais d'autres résultats pourraient m'être utiles également.
 
Lien vers le benchmark en question -> http://pagesperso-orange.fr/grmpf/UglyRTBench.zip
 
 
Les threads sont lancés en mode "fire and forget", ce qui est très visible lorsque la prévisualisation est activée en SMP ou SMT : 1 des threads est systématiquement à la traine car le rafraîchissement de l'UI prend énormément de ressources.
 
 
Nouveau : génération d'un rapport...

Je ne sais pas si ca pourra te servir:
 

 

 

 
Proc en coeff 19X en burn, donc 3.8Ghz
Windows 7 32bits

Possibilité de changer la résolution ?
 
Car 1920*1200 compliqué sur un PC portable 15"

L'affichage est en 960x600 et limite facultatif (case "Preview" décochée = affichage seulement à la fin du rendu pour isoler le temps passé sur le code de rendu de celui passé à l'affichage).
 
Sinon Damien, oui c'est utile, ça me permet de voir que le quad apporte maintenant un bénéfice vu que jusqu'à présent j'avais que des résultats peu probants avant la dernière modif. Le même avec preview devrait être moins sympa avec principalement 1 thread qui se traine (je les lance et j'attend simplement qu'ils finissent plutôt que de vérifier en continu l'utilisation maximum des ressources).
 
Je suis à peu près sûr que mon code fonctionne jusque 8 cores (physiques ou logiques), au-delà je ne sais pas et il en est de même pour les configs multi-CPU. Reste à voir l'efficacité obtenue, notamment sur les i7 où je ne suis pas certain que les 4 threads du test SMP soient bien attribués aux 4 cores et pas à seulement 2.
 
Edit: Certains auront peut-être aussi remarqué des artefacts sur les 5 sphères de la scène 2 (voire sur la 1 entre les 2 sphères du haut en agrandissant la fenêtre)... j'ai pas vérifié mais il y a de fortes chances que ça soit dû à la précision limitée employée (32bits, pour pouvoir porter directement les opérations sur n'importe quel GPU SM5.0 vu qu'à l'origine je pensais comparer différentes implémentations de l'algo). Au final, je devrais arriver à avoir 4 path différents pour effectuer le même rendu : C#, C++ "classique", C++ avec utilisation du SSE, HLSL.

J'ai eu un retour sur un i7, j'en attend d'autres avec des i3/i7 pour confirmer les soupçons avant de modifier l'attribution des threads. Il est possible qu'au final le mode SMT soit désactivé pour cause de perfs à la ramasse.

J'ai testé de mon coté, configue I3 330M @ 2.13 GHz (2 cores / 4 threads) :

Bon bah déjà now je suis sûr pour l'attribution des threads à revoir en SMP sur processeurs avec HT, ça aurait été trop simple si la première moitié avait été les cores physiques et la seconde les cores logiques
 
Faudrait aussi que j'ajoute un popup avec le récapitulatif, ça évitera d'avoir des screens gigantesques

Si tu as besoin de nouveau test, je suis là

Edit : j'ai voté 2.

Archive mise à jour, une version "0.3" fait son apparition dedans avec normalement de quoi corriger le souci de l'HyperThreading.
 
Autres ajouts : calcul de l'efficacité du multi-threading, sur mon C2D c'est pas mal du tout tant que je n'active pas la preview, bien que ça se soit gravement amélioré sans réelle raison (mais bon, du coup maintenant la preview est vraiment moche en multi-thread... )
 
L'UI est encore assez brouillon, quelques contrôles ne sont pas encore faits mais ne sauront tarder à l'être.
 
A noter tout de même : le temps de rendu est assez variable, faut pas hésiter à lancer 2-3 fois un test si les résultats sont louches.
 
Edit : j'ai voté 5, l'est bête ce sondage qui me demande ce que je pense de mon sujet... l'est nul évidemment

Prometteur ce petit bench    
 

 

 

Une fois que ça fonctionnera à peu près correctement, j'avancerai sur le moteur de rendu en lui-même, il y a pas mal de choses à ajouter avant de pouvoir exploiter des scènes plus sympa.
 
Actuellement tout ce que fait la boucle de rendu, c'est 6 lancers de rayon consécutifs maximum par objet touché (première passe + 5 réflexions).
 
Les premiers ajouts qui seront faits de ce côté là seront la réfraction, les plans et le texturing (actuellement le matériau est coloré, opaque, homogène et juste plus ou moins réflechissant). L'AA devrait arriver avec la correction de perspective.

J'ai testé la scène n°1, les résultat ne sont pas très normaux.
 
ST : 1.606s
SMP : 0.998 (2cpu cores - 88%)
SMT : 0.982 (4cpu threads - 44%)

Si on considère que l'HyperThreading n'apporte rien, ils le sont
 
Cette scène 1 est extrêmement légère donc c'est probablement celle qui aura inévitablement le moins bon rendement, bien que j'ai réussi à avoir 90-95% très occasionnellement.
 
Le rendement est calculé par rapport au temps de rendu avec 1 seul thread et le nombre de threads, d'où les maigres 44% en SMT puisque les 2 cores logiques n'apportent visiblement rien mais sont comptés comme utilisés : 1606/(982*4) = 40.9% (ce qui indique que tu as relancé le test ST après )
 
Par contre avec un peu de chance ça permet d'améliorer la preview en mode SMP (à tester sur la scène 1).

Oui j'ai lancé tout les tests pleins de fois
 
Je vais tester les scènes 2 et 3.
 
Bientôt je vais monter mon E6400 et/ou E8500, puis mon i5 670.
 
Et même, si l'envi me chante, sur du PIII, Sempron et athlon XP.

Les vieux coucous ça pourra être intéressant avec une version vraiment "benchable", histoire de voir le chemin parcouru.
 
Je suis en train de chercher comment corriger le problème de déformation "macro au téléobjectif", et mine de rien il semblerait que ça soit excessivement courant (j'ai croisé un site où ça apparaissait dans les illustrations d'une thèse de Master, donc ça va je ne suis pas si largué ).

Après correction du problème de perspective et ajout des plans, je me suis amusé à faire une scène un pwal plus lourde... mais juste un pwal hein
 
4 plans, 1 sphère et 96 point lights... du pipi de miaou!
 
6 minutes pour la rendre histoire d'illustrer un minimum le premier post, en 3840x2400 pour limiter l'aliasing (naturel et lié à des problèmes de précision).

Disponible en DL ?
 
L'image va apparaitre à l'écran en 3840*2400 ? Car sur mon 15"

chapeau bas en tout cas.
 
Sinon si tu veux des scores I7 920. je fais ça demain !

L'image est toujours affichée en 960x600, ça fait "juste" un AA 16x  
 
Il faut encore que je rende l'UI un tant soit peu exploitable car j'ai ajouté la sélection du niveau de profondeur (utile pour voir son impact) et c'est pas très intuitif à l'usage.
 
Je vais voir à créer un bench "auto" avec plusieurs résolutions et sortie directe des résultats et images générées.
 
A part ça j'ai encore quelques détails à inspecter, car le plafond de la scène d'illustration est normalement blanc et si la perspective est maintenant correcte j'ai un doute sur le zoom, et j'ajouterai peut-être d'autres effets avant de mettre à jour la version publique (pour le moment je ne gère que le diffuse lighting et les réflexions, même pas le specular/phong).

Toujours loin de la perfection, j'ai ajouté une archive avec un début de gestion du texturing.
 
http://pagesperso-orange.fr/grmpf/UglyRTBench0.30b.zip
 
La scène 5 cherche une texture "earth.jpg" dans le dossier du programme, je n'ai pas inclus celle que j'utilise pour la simple et bonne raison qu'elle pèse plus de 800ko.
 
La gestion du texturing est très basique, tellement qu'elle ne fonctionne pas en multi-thread.
 
L'AA est effectué assez sommairement également : en 2x et 4x la grille a de bons paramètres mais elle est inadaptée en 3/6/8x et plus (les options sont là mais nécessiteront quelques corrections avant d'être pleinement exploitables).
 
Edit: le rendu se fait en 960x600 dans cette version, cliquer sur l'image la sauvegarde.

Je n'ai pas tout compris
 
Tu as réussi a corriger les problèmes de perspective ?

Perspective = ok.
Texturing = +/- ok (non utilisable en multi-thread)
AA = +/- ok (2x et 4x corrects, 3-6-8-16-32x non même si ils apportent des améliorations)
 
Les scènes 2 et 3 ont un peu changé aussi ("plans" simulés à coups de sphères géantes remplacés, éclairage modifié), la 2 est bonne à refaire complètement.
 
A noter que je n'ai inclus le texturing que sur les sphères.
 
La bête est bientôt prête pour le passage au C++ puis HLSL.

J'ai testé la scène 4 et le ventilateur du i3 c'est énervé.
 
Tu pourrais m'expliquer quelques option :
 
 * max depth
 * Sample / pixel
 
En théorie je comprend leurs principes, mais dans la pratique du bench moins.

Le premier paramètre est assez évident à mettre en évidence, tu prends la scène 1 plus simple que la 4 et tu observes les changements en passant de 1 à 2 puis 3.
 
En fait c'est le nombre maximum de rayons générés par pixel, ce qui se traduit sur le nombre de réflexions en cascade. A chaque objet touché, si il est réfléchissant, on lance un rayon dans la direction qui convient et on effectue le même processus soit jusqu'à tomber sur un objet non réfléchissant, soit jusqu'à atteindre le nombre maximum de rayons lancés.
 
Pour le multi-sampling, il s'agit de remplacer l'unique rayon primaire lancé pour déterminer la couleur d'un pixel par un certain nombre de rayons tous présents dans la "surface" du pixel. Actuellement tous les modes utilisent le même paramètre de décalage de 22.5° et lancent Nb_Echantillons décalés de façon à les placer en cercle autour du centre du pixel, comme on a pu le voir dans des articles de Tridam sur les GPU.
 
La scène 4 est horriblement lourde avec ses 96 176 sources lumineuses, mais là elle est encore buggée vu que la sphère n'apparaît pas réfléchissante.

Merci, je comprend mieux
 
Tu as besoin de test pour les nouvelles scènes ?

Je suis en train de modifier l'AA, exit les modes supérieurs à 4x et apparition d'un choix entre SSAA et MSAA (sisi).
 
Le SSAA :
- lance 1 rayon par sample et par pixel
- fait la moyenne.
 
Le MSAA :
- lance 1 rayon par pixel (au centre)
- garde le résultat
- vérifie si chaque rayon "test" tombe ou non sur le même objet
- si un des rayons "test" tombe sur un autre objet, lance un rayon vers l'objet sur lequel il est tombé
- fait la moyenne entre le résultat mémorisé multiplié par le nombre de fois où cet objet a été touché et les rayons lancés en dehors de l'objet initial
 
Le temps de rendu est sensiblement impacté par la nuance, la qualité également puisque les réflexions sont beaucoup moins précises (1 seul rayon secondaire lancé contre 4 en SSAA 4x), ce qui fait que seule la géométrie subit un anti-aliasing.
 
Sur une scène 4 un pwal allégée et 1 seul core, ça donne :
 
- sans AA -> 32"8
- avec MSAA 4x -> 34"2
- avec SSAA 4x -> 2'11"
 
En remaniant un peu, je finirai probablement par créer un Z-Buffer.

Tu me préviendra lorsque la nouvelle version est disponible.
 
Il semble de plus en plus prometteur ce p'ti bench.

Ce qui est intéressant, c'est que ça me sert d'apprentissage...
 
Au fil des ajouts je me rend compte des améliorations possibles.
 
Bon, pour le moment je vais me focaliser sur la correction du texturing, prochaine version 0.4 avec pas mal de modifs du code qui commence à partir en vrille, probablement pas dispo demain.

Ca avance tranquillement mais surement...
 
J'ai débuggé le texturing (comme une brute : les textures sont stockées sous forme de tableaux d'octets) et remanié le code de rendu un chouilla pour permettre de gérer différents modes d'AA (apparition d'un Z-buffer transgénique).
 
Prochaines modifs: factorisation d'un bout de code, réflexions spéculaires et réfraction.
 
Finalement la prochaine version sera peut-être dispo en download ce soir, il faudra juste que je trouve des idées pour des scènes mettant en évidence les différents paramètres.

Tu commences à parler chinois pour moi
 
Mais j'aimerai bien comprendre et voir faire la même chose.

Je me parle chinois à moi-même en fait
 
Le Z-Buffer transgénique a été viré, il semblerait qu'en .NET il ne soit pas efficace de gérer des éléments de plusieurs dizaines de Mo.  
 
Vu que cette semaine risque d'être un pwal chargée, les mises à jour se feront plus tard.

Je mettrai une version plus à jour en ligne demain dans l'aprem, le temps de remanier les scènes.
 
En attendant un rendu en 3840x2400 attend les curieux dans le premier post (1Mo en JPEG "à la Paint" ).

Mise à jour, un bouton "benchmark" a fait son apparition et lance successivement chacune des 4 scènes en mode ST, SMP et SMT avant d'afficher un rapport.
 
Illustration dans le premier post.

Je viens d'essayer la nouvelle version
 

Décidément, le SMT passe mal...
 
Au vu de ces résultats, l'i5 n'est pas mieux exploité que mon bon vieux C2D. Le SMT a quand même l'air d'être plus régulier que le SMP (en admettant qu'il n'apporte rien, l'efficacité devrait être strictement divisée par 2), ce qui est assez étrange.
 
Normalement l'algo ne devrait plus changer, sauf si je m'aperçois d'une énormité, donc prochaine étape création d'une DLL en C++ avec le code de rendu équivalent (je garde la même interface).
 
Vu que j'ai dû jeter l'OS sur lequel je faisais le développement (7 RC ), ça attendra un peu, sauf grosses insomnies.

 
C'est normal le 103% là

Oui, ça arrive
 
Si tu regardes le 65% d'au-dessus ça montre à quel point il peut y avoir une variation sensible. Ca signifie juste que ton résultat ST n'était pas optimal, mais pour corriger ça c'est une autre affaire vu que c'est à priori lié à la compilation JIT.
 
Quand même bizarre que tes résultats soient si "mauvais", ou alors c'est un C2D de compet' que j'ai

Et bien moi j'ai un core i5 de compet'

 
Trop facile, d'origine il est déjà @ 3.5Ghz
 
Mon Quad a 34% d'O/C

Je parlais des scores, fréquence équivalente et je suis devant dans quelques scènes.
 
Pourtant c'est un "petit" Core i5 dual cores.