compléments

• [^]Re: compléments

  Posté par nayco (page perso, ) le 05/03/2008 à 10:46. (lien). Évalué à 2.

  En plus ça utilise des processeurs généralistes donc pas de problème de drivers!
  Et tu crois que les constructeurs de carte 3D vont laisser faire ?

  --
  Pan ! Pan !
  Ne pas utiliser : traplinuxfrnico@univ-nantes.Fr

  • [^]Re: compléments

    Posté par ndesmoul () le 05/03/2008 à 11:20. (lien). Évalué à 3.

    Aucune idée. Mais il semblerait que les GPU actuels soient pas trop adaptés aux type de calcul demandés ici. Mais je me trompe peut-être.
    D'ailleurs la question serait plutôt: est-ce que nVidia va laisser faire?
    ATI maintenant c'est AMD, donc ils sont bien placés pour aller dans les deux directions. Et Intel (qui fait également beaucoup de chipsets graphiques) a tout intérêt à promouvoir cela pour valoriser ses processeurs multi-CPU.

  • [^]Re: compléments

    Posté par Aldoo (Jabber id, ) le 05/03/2008 à 11:22. (lien). Évalué à 4.

    Rien ne les empêche de mettre un Intel Core ou équivalent sur une carte PCIe et de vendre ça sous le nom GeForce 4930500+ Deluxe GTS...
    Bon j'exagère, mais je pense que les constructeurs de carte 3D sauront s'adapter et marketer.
    Et puis, est-ce que le raytracing ne peut pas aussi tirer partie des GPU actuels ?

    • [^]Re: compléments

      Posté par Ontologia (page perso, ) le 05/03/2008 à 13:58. (lien). Évalué à 3.

      Si le raytracing se satisfait de calcul en real_32 pas trop précis, oui.
      
      Avec les nouveaux framework du genre NVidia Cuda, tu peux facilement délester le processeur de calculs simple comme addition et multiplications.
      
      D'ailleurs, en bidouillant opengl, tu peux déjà le faire, mais c'est un peu tordu.
      Je vais essayer de creuser le concept, je vous en reparlerai.

      • [^]Re: compléments

        Posté par Gart Algar (Jabber id, ) le 05/03/2008 à 14:58. (lien). Évalué à 2.

        Concernant l'utilisation possible du GPU, je cite Stephan Reiter[1] :
        
        > By the way: as far as I gathered, most of the raytracing stuff is CPU
        > based. Are there any plans to load tasks to the GPU?
        I actually tried that with a GeForce 7 in 2006 and gave a poster
        presentation at a raytracing conference. But the idea didn't turn out so
        well: With current GPU architectures there's simply too much performance
        wasted when communicating CPU<->GPU, especially read-backs are problematic
        (even with PCI-Express). A CPU-only implementation running on two cores
        outperformed the graphics card by a factor of 4-5. Using the GPU as an
        additional processing unit to the CPUs also yields a reduction in
        performance due to the associated overhead.
        
        autrement dit (traduction très approximative) que la communication entre le CPU et le GPU consomme trop de ressource par rapport à l'utilisation d'un cœur supplémentaire
        
        [1]http://icculus.org/cgi-bin/ezmlm/ezmlm-cgi?50:mss:2290:jhhho(...)

        --
        Ubuntu is an ancient african word meaning : "I can't configure Debian"

        • [^]Re: compléments

          Posté par Ontologia (page perso, ) le 08/03/2008 à 01:30. (lien). Évalué à 3.

          En fait si c'est possible, mais c'est ultra tordu.
          
          Le problème est que ça n'est intéressant que pour des calculs massifs sur de grosses quantités de données, quand l'algo est "utilisable"
          
          Par exemple, on explique comment faire Y = Y + a.X où Y et X sont des vecteurs à n dimension (n très grand) et a un scalaire.
          http://www.mathematik.uni-dortmund.de/~goeddeke/gpgpu/tutori(...)
          
          Plus d'infos ici :
          
          http://www.gpgpu.org/developer/index.shtml#conference-tutori(...)
          
          
          
          Effectivement, si tu veux veux multiplier 3 matrices et un vecteur, passe ton chemin, vu le bordel que c'est de charger des matrices dans la pile et de les multiplier à coup de glMultMatrixf, c'est forcément lent. Mais si on arrive à bidouiller pour profiter des opérations de très (trop) haut niveau de la carte dispo en openGl, alors oui il y a des choses à faire.
          
          De plus, avec les glShadingLanguage on a un outil plus flexible :
          
          http://www.ozone3d.net/tutorials/mandelbrot_set.php
          
          Donc à voir et ça ne fait que commencer

Mouarf

• [^]Re: Mouarf

  Posté par chimrod (Jabber id, page perso, ) le 04/03/2008 à 19:08. (lien). Évalué à 1.

  C'est vrai, quand on dit raytracing on pense tout de site réflection, réfraction etc. Ici rien, je ne vois pas la différence avec une représentation 3D habituelle. Peut être que ça va se développer par la suite, et qu'on finira par avoir des jeux en vrai lancé de rayon ( et là ça sera un vrai bonheur visuel !! )
  
  Par contre sur la vidéo, on voit la représentation par triangles. Dommage, le raytracing permettrait de s'en passer pour les primitives, et cela permettrai de décharger la mémoire en nombre de polygone. Après c'est peut être la charge du processeur qui ne tiendrait pas..
  
  À quand un jeu présentant des images aussi belles que sur l'irtc ? :-)

  --
  It is no bug, it's future

  • [^]Re: Mouarf

    Posté par KiKouN (Jabber id, ) le 04/03/2008 à 19:53. (lien). Évalué à 2.

    Je ne sais pas si tu as vu les vidéos de Q3, mais ils y avaient ajoutés tout ce que tu demande dedans. C'était assez impressionnant à l'époque.

    --
    KiKouN, Bucheron-Geek

    • [^]Re: Mouarf

      Posté par chimrod (Jabber id, page perso, ) le 04/03/2008 à 20:14. (lien). Évalué à 1.

      Non, je n'avais pas suivi l'actualité sur quake3 j'avoue. Était-ce en raytracing ? Je sais que c'est facile de faire des effets de réflections en 3D ( en basant ça sur le principe d'une image environementale, ça peut être assez rapide ). Le faire en lancé de rayon donne cependant des résultats différents ( par exemple en prenant en compte l'indice de réfraction pour la lumière au travers d'un solide)..
      
      Ici on n'a rien de tout ça.. mais peut être est-ce à venir par la suite..

      --
      It is no bug, it's future

      • [^]Re: Mouarf

        Posté par KiKouN (Jabber id, ) le 04/03/2008 à 20:31. (lien). Évalué à 2.

        Et bien le principe était différent. Ici, ça à l'air d'être une modification d'openGL pour utiliser le RT sans modification de l'API. Alors que sous Q3, il avait modifier le moteur de jeu pour qu'il utilise openRT, une librairie équivalante à openGL avec les même fonctions de base mais avec des extensions permettant d'utiliser le plus du RT comme les formes primitives, la réflection, etc... Ce qui permet d'adapter rapidement un jeu pour cette librairie tout en gardant sous le coude tous les avantages du RT.

        --
        KiKouN, Bucheron-Geek

    • [^]Re: Mouarf

      Posté par Gart Algar (Jabber id, ) le 05/03/2008 à 10:30. (lien). Évalué à 1.

      Pour du quake 3 en raytracing temps réel, il y avait eu http://graphics.cs.uni-sb.de/~sidapohl/egoshooter/ (screenshot http://graphics.cs.uni-sb.de/~sidapohl/egoshooter/screenshot(...) ) c'était impressionnant, mais ça tournais sur plusieurs machine. Là, c'est toujours le même moteur, mais ça tourne sur une seule machine.
      Bien sûr le pb reste l'augmentation de la résolution, c'est ce qui demande le plus de puissance. Mais l'avantage, c'est que le lancer de rayons utilise beaucoup les calculs parallèle, et donc trouve sont bonheur dans les nouveaux processeurs a plusieurs cœur.
      L'avenir proche est sûrement dans un mélange de rasterisation et de raytracing, permettant ainsi d'aller plus vite avec la 1ère et d'être plus précis avec la 2ème, notamment pour les collisions d'objet 3D

      --
      Ubuntu is an ancient african word meaning : "I can't configure Debian"

      • [^]Re: Mouarf

        Posté par ndesmoul () le 05/03/2008 à 11:23. (lien). Évalué à 2.

        D'après un des articles sont j'ai laissé le lien plus haut, ça serait une mauvaise idée de tenter de mixer les deux technos. Elles sont trop différentes et les gains obtenus en tentant tout de même de les mélanger peu intéressants.

Bof.