Se connecter avec
S'enregistrer | Connectez-vous

Du ray tracing sur 80 threads

Par - Source: TweakTown | B 13 commentaires

Intel faisait hier la démonstration de quatre Westemere EX, chacun disposant de dix cores multithreadés faisant tourner KeyShot, un logiciel de ray tracing en temps réel.

L’application ne dépendait que des 80 threads CPU, sans faire appel à la carte graphique, pour les calculs de ray-tracing. Destinés à jouer le rôle de vitrine technologique, les changements de textures ou de lumière étaient intéressants, mais les animations étaient trop saccadées. Comme le montre cette vidéo de nos confrères de TweakTown, le fait de faire bouger l’image résulte en une perte de qualité importante.

Au final, cette débauche de puissance est impressionnante, mais elle ne laisse rien présager de bon pour l’avenir du ray-tracing, ce qui rejoint aussi nos conclusions énoncées en 2009 (cf. « Le raytracing peut-il supplanter la rastérisation ? »). La demande en ressources de cette technologie est beaucoup trop importante par rapport aux gains réels qui ne sont pas proportionnés aux ressources nécessaires. L’application a au moins le mérite de tirer un maximum parti des 80 threads, ce qui n’est pas donné à tout logiciel.

Commentaires
Interroger un expert

Votre question aux experts de la catégorie Les news : vos réactions du forum

Exemple : Android, ordinateur portable, usb, disque dur

Cette page n'accepte plus de commentaires
  • darika , 17 septembre 2010 06:17
    Le CPU c'est "has been". Il est temps que les applications exploitent CUDA ou ATiStream.
  • ErGo_404 , 17 septembre 2010 09:17
    La demande en ressources n'est pas vraiment trop importante, mais cette technique de rendu exploite des ressources dont nos ordinateurs classiques ne disposent pas. Si depuis 10 ans on utilisait cette technique de rendu, les processeurs auraient évolué en conséquence et seraient parfaitement capables de la supporter ;-)
  • darkbul , 17 septembre 2010 09:28
    Et je pense qu'un carte bi-gpu serait plus efficace que ces proco...
  • Afficher les 13 commentaires.
  • Foudge , 17 septembre 2010 09:29
    Ou plutôt OpenCL et DirectCompute, c'est quand même plus ouvert que les 2 technos que tu as cité qui ne fonctionnent que sur du matériel spécifique.
  • Foudge , 17 septembre 2010 09:34
    ErGo_404Si depuis 10 ans on utilisait cette technique de rendu, les processeurs auraient évolué en conséquence et seraient parfaitement capables de la supporter ;-)
    Nos processeurs actuels sont nuls en rasterisation, donc j'pense que ça n'aurait rien changé. Par contre nos carte 3D seraient des cartes accélératrices RT.
    Mais bon, j'pense pas que le choix qui a été fait il y a 20 ans était un mauvais choix.

  • zorro3364 , 17 septembre 2010 09:48
    les puces graphiques sont conçues pour la rasterisation. rien n'est conçu spécifiquement pour le raytracing. que se passe-t-il lorsqu'on fait de la rasterisation sur du cpu? la même chose qu'ici, sinon on aurait jamais fabriqué de puces dédiées.
    bref, une news qui sonne comme une lapalissade.

    ps: david, faut vraiment corriger cette phrase:
    "La demande en ressources de cette technologie est beaucoup trop importante par rapport aux gains réels qui ne sont pas proportionnés aux ressources nécessaires"
  • muc73 , 17 septembre 2010 09:50
    Est-ce qu'il y a des information sur la résolution de la vidéo RT?
  • Anonyme , 17 septembre 2010 09:52
    c'est plus efficace, en ayant moins de CPU mais avec une carte video CUDA, avec la meme animation en ray-tracing ?
  • Anonyme , 17 septembre 2010 10:11
    C'est un problème algorithmique, le ray tracing ne fonctionne qu'en approximation successives, pas le rendu classique. Ce qui fait qu'il nécessite une puissance de calcul énorme. A moins de trouver de nouveaux algorithmes (si ils existent) il n'y a pas de solutions pour faire du ray tracing rapide.
  • boub popsyteam , 17 septembre 2010 10:17
    Non/ y'a qu'a voir le prog de demo de raytracing de nvidia avec les bagnoles ça rame autant si c'est pas plus. Et comme il est dit à la fin y'a pas assez de ram sur les CG pour les grosses scenes.
  • zozolebo , 17 septembre 2010 10:56
    Citation :
    Ou plutôt OpenCL et DirectCompute, c'est quand même plus ouvert que les 2 technos que tu as cité qui ne fonctionnent que sur du matériel spécifique.

    Complètement d'accord. En plus OpenCL n'est pas qu'une API pour exploiter les performances de la carte graphique, c'est toute une plateforme qui met en commun tous les CPU et tous les GPU du système et qui optimise les ressources de chaque puce selon le calcul demandé (ce qui permet d'utiliser 1 carte ATI et 1 carte nVidia ensemble sur une même machine pour faire du raytracing, ou tout autre calcul puisque si le calcul n'est pas adapté pour le GPU, il sera traité automatiquement par le CPU, et inversement).

    OpenCL est la plateforme la plus simple et la plus universellement compatible pour faire simplement des calculs lourds tout en optimisant les ressources.

    Maintenant je ne connais pas DirectCompute et je ne sais pas quels sont ses avantages/inconvénients par rapport à OpenCL.
  • zozolebo , 17 septembre 2010 11:04
    Ah c'est bon, j'ai regardé et DirectCompute est en fait la branche de DirectX qui correspond à OpenCL (de la même façon que Direct3D est la branche de DirectX qui correspond à OpenGL). Donc c'est une technologie Microsoft, propriétaire... Espérons qu'OpenCL saura s'imposer un peu plus facilement qu'OpenGL car il a un potentiel plus grand que DirectCompute (OpenCL est compatible avec Linux notamment, ce qui peut être très intéressant pour les smartphones qui tournent sous Android ou Meego !!).
  • zelmorf , 17 septembre 2010 12:18
    Keyshot, de même que les autres moteurs de rendu du même genre : Iray, Bunkspeed Shot, vray RT, etc. ne sont pas du tout des moteurs de rendu destinés à l'animation temps réel, mais à la création et à la pré-visualisation d'images fixes photoréalistes et physiquement correctes (respectant les lois physiques de la lumière et des matériaux).
    Ca n'a aucun sens de comparer le moteur utilisé lors de la démonstration d'Intel à des moteurs de rendu temps réel basé sur la rastérisation comme le fait l'auteur de la news, ce n'est pas du tout la même finalité...

    A noté que plusieurs moteurs de rendu s'orientent de plus en plus vers le rendu GPU (cuda ou opencl) pour accélérer la pré-visualisation, tel que vray RT GPU par exemple (pour la pré-visualisation liée au moteur vray), en beta actuellement et qui doit sortir en décembre et accélère grandement la vitesse de rendu ( http://www.youtube.com/watch?v=B1AEYpkg41k ).