Reprise du message précédent :
Oui, surement vers Février voire au plus tard Avril.

Y'a rien d'avancé pour l'après GT200b chez nV, par contre chez les rouges c'est/c'était Q1 2009.  
 
Je dis c'était parce que comme TSMC patauge un peu niveau gravure...

Rectification chez PPC, Larrabee gèrera bien DX et OpenGL : http://www.presence-pc.com/actuali [...] ctX-30513/

Ils ont rectifié l'info, par contre leur orthographe s'est dégradée au passage.

En même temps ils y sont vraiment aller de leur connerie pour sortir un article pareil.

Quant à la version de D3D supportée, c'est un faux problème : le hardware est composés de CPU, pas de GPU/DSP : programmation générique, on fait ce que l'on veut dessus tant que ça rentre niveau performances. Il n'y a pas de limitation technique due à une implémentation hardware (autre que le nombre de CPU disponibles).

Il faut voir Larrabee à deux niveaux différents :

• Un calculateur parallélisé, comme Cuda et CTM/Stream et autres. Sur lequel de tierces parties pourront implémenter ce qu'elles veulent - y compris des moteurs de rendu raytracing.
• Par dessus un moteur de rendu à base de polygones/triangles, implémentant D3D et OGL et fourni par Intel.

La source originale de la citation de TomF : http://home.comcast.net/~tom_forsyth/blog.wiki.html

à tfpsly
 
sa me parait etre exactement celà ,  
 
si les cores scalent bien sa pourra dépoter pas mal .

Le Larrabee alimente nombre de rumeurs depuis un bon moment. Intel vient tout de même de réagir à l'une d'entre elle. La rumeur n'était d'ailleurs pas si surprenante puisqu'elle porte sur un point qui est évoqué à mi-mot depuis le début des annonces Larrabee : le support DirectX / OpenGL. Les choses se sont précisées il y a moins d'une semaine lorsque Fudzilla a annoncé qu'il ne serait compatible avec aucun des deux et utiliserait un mode à part.  
Justifiant le propos par l'architecture très exotique de la carte. Une affirmation à tempérer : le Larrabee est effectivement assez particulier mais pas si "exotique", pas au point de soupçonner un mode de rendu dédié sans information supplémentaire du moins.
 
Verdict aujourd'hui : Intel a répondu en affirmant un support tout à fait classique de DirectX et OpenGL. Une difficulté de moins donc pour la carte qui aura déjà fort à faire si les autres rumeurs (royalement ignorées par Intel) comme le PCB 12 couches ou l'absence d'économie d'énergie sont vraies...
source : http://www.matbe.com/actualites/42 [...] la-rumeur/

A propos de l'absence d'économie d'énergie j'ai un doute, Intel a acquis une bonne expérience dans ce domaine avec les C2D. Ce serait étonnant qu'il n'y ait rien sur leur cg.
J'espère que le 12 ils vont être un peu plus bavard qu'en ce moment...

Et même si ce n'est pas fait (ce qui serait surprenant) ne pensez-vous pas que d'ici 2009 ils ont tout à fait le temps d'y apporter les modifs nécessaires ?

Je penses aussi qu'il comptent rentabiliser le moteur havock donc certainement compatible avec cette api et la souplesse de prog du code X86
 
c'est une idée ,  je crois que leur moteur sera capable de "" tricher "" pour ne pas afficher et calculer ce qui n'a pas besoin de l'etre  des structures caché ou autres .

Ca ne se fait pas déjà ça, ne pas calculer ce qui n'est pas visible ? Je suis à peu près sûr que si.
 
> super_newbie_pro
Je ne suis pas concepteur de cpu, mais peut être faut il prendre en compte ce genre de fonctionnalité dès la conception de la puce, ce n'est peut être pas "rajoutable" à la fin.

 
Ca s'appel le HSR (Hidden Surface Removal) et ca existe depuis belle lurette  

Ça s'appelle surtout le culling.
Le HSR étant la différence entre ces deux images :

Le culling pouvant se faire en gérant un arbre BSP ou des portals en scène intérieur, un quadtree ou octree, des occluders... parfois de la triche dans des drivers pour gffx avec 3dmark...
Mais oui ça se fait depuis longtemps.

Drap je

drap

Article à lire :
 
http://www.presence-pc.com/actuali [...] ech-30573/
 
Alors que l’on attend avec impatience la QuakeCon se déroulant au début du mois prochain pour en apprendre plus sur Rage, le premier jeu utilisant l’id Tech 5, les petits génies d’id Software travaillent déjà à leur prochaine génération de moteur 3D.
 
John Carmack avait déjà défini l’orientation de l’id Tech 6 : permettre de s’affranchir des contraintes de géométrie tout comme id Tech 5 permet de s’affranchir de celles de textures. Pour cela il avait décrit sa vision à nos confrères de PC perspective. Son idée consistait à abandonner la représentation polygonale au profit d’une nouvelle structure de données : le sparse voxel octree qui serait rendue en utilisant le raycasting. Les quelques bribes d’informations qu’il dévoilait étaient intéressantes mais tout ceci restait encore assez flou, et semblait vraiment être encore au stade de la réflexion purement théorique.
 
Ainsi est on surprit d’en apprendre aussi rapidement d’avantage au détour d’un forum, par l’intermédiaire de Jon Olick. Ce nouveau venu chez id Software n’a peut être pas la célébrité d’un John Carmack mais il ne faut pas le prendre à la légère pour autant.  
Ancien lead programmeur de Naughty Dog, il a également travaillé pour Sony sur l’ensemble de bibliothèques EDGEEDGE  permettant d’exploiter au mieux le Cell. Son rôle chez id Software a consisté dans un premier temps à optimiser l’id Tech 5 afin d’obtenir les meilleures performances possibles sur la PS3 grâce à sa connaissance très avancée du CellProcesseur conçu en collaboration par IBM, Sony et Toshiba et dont le principal débouché actuel est la PlayStation 3.  
 Mais il semble qu’aujourd’hui il soit chargé de mettre en pratique la « vision » de Carmack en programmant divers tests de rendu de ce fameux sparse voxel octree.
 
Les résultats semblent prometteurs et Olick a d’ailleurs prévu de donner plus de détails sur ses travaux préliminaires au prochain Siggraph.  
On espère en apprendre d’avantage à ce moment là, mais il a déjà pu dévoiler quelques informations. On apprend ainsi qu’il utilise actuellement CUDA mais qu’il attend impatiemment de pouvoir essayer le fameux Larabee d’Intel  
qu’il juge, sur le papier, plus adapté à l’algorithme utilisé grâce à son mécanisme de cache . plus efficace dans ce cas que la Shared Memory qu’on trouve sur les GPUGraphical Processing Unit,  
 
Il nous apprend également que le plan à l’heure actuelle consiste à stocker tout l’environnement (le monde 3D) sous cette forme, tout en conservant des personnages sous forme de polygones. Représenter les personnages sous forme de voxels n’étant pas prévu avant la génération suivante (id Tech 7 donc). Enfin il semble assez confiant quand aux performances, même sur les cartes actuelles (il travaille sur une GeForceMarque utilisée par nVidia pour désigner ses puces graphiques depuis 1999. La première série nVidia à porter le nom de GeForce était la GeForce 256, d... GTX 280) tout en gardant à l’esprit qu’entre les travaux préliminaires d’un moteur et le jeu final il y a un monde : on se souvient que John Carmack a débuté ses travaux sur Doom 3 en travaillant sur une GeForce DDR !
 
Nous ne manquerons pas de vous tenir informés lorsque plus de détails sur cette technique prometteuse seront dévoilés.
 
Edit : pas eu le temps de mettre l'article en entier : now c good

Très intéressant.
Mais Carmack est un peu un OVNI dans le domaine des moteurs 3D et il n'est pas dit que le Raytracing se démocratise. Même si son futur moteur est un réussite.

Très intéressant en effet.
À première vue, ce serait un octree découpant la géométrie du monde hiérarchiquement en cube/pavé de plus en plus petits ; les générations de moyennes et petites tailles supportant des informations locales sur la géométrie (pourquoi pas sur les 6 faces en plus) : textures, normales, displacement mapping...

Vu de loin, on n'affiche que N générations. Vu de près, on descend plus loin.

Et il n'y a plus de vertexes ni triangles. Poubelle le mode de fonctionnement des GPU actuels (sauf pour les persos animés).

Exemple sur une bagnole - source : http://ompf.org/forum/viewtopic.php?f=6&t=793 :
Vue de loin (8 générations):
Vue de près (12 générations):

Mais je pense que dans l'implémentation de Carmack ne descend pas aussi loin dans l'octree : ce serait un gachi d'espace de stockage, et on peut toujours coller la caméra plus près pour voir les cubes. À mon avis les cubes ne font pas que porter une couleur comme dans l'exemple de la voiture, mais également des map de voxels ou de relief pour rajouter plus de détails (équivalent au relief mapping ou à un moteur classique de voxels sur chaque face des cubes), de normales et paramètres du matériel pour calculer l'éclairage et la couleur finale...

Ce n'est pas du raytracing au sens classique! C'est du raycasting de voxel, techno qui existe depuis plus de 20 ans pour des terrains avec une seule map de voxels (en général une highmap + texture). Voir les vieux jeux Comanche, Outcast..., et toutes les démos de voxel des 20 dernières années. Juste du lancé de rayon à travers l'octree pour trouver quel(s) voxel utiliser pour le pixel courant. Puis affichage par des techniques plus classiques de rasterisation de texels.
La (grosse) différence ici étant qu'il n'y a pas une seule map de voxels appliqué à un terrain horizontal ne pouvant pas avoir de formes complexes, mais un octree de voxels cubiques hiérarchisés, chacun portant des infos sur son matériel pour l'affichage.

Les principales difficultés :

• Avoir un lancer de rayons vs octree suffisamment performant. La grosse difficulté et de très loin.
• Streamer en temps réel les niveaux nécessaires de l'octree. C'est là l'apport principal de cet algorithme : les artistes ont désormais une totale liberté dans la création de leurs assets, et le moteur ne charge que ce dont il a besoin et peut stocker. Le reste restant sur le disque dur - voire sur les PC des artistes s'ils se sont vraiment trop lachés Carmack a déjà un tel moteur pour les textures : le MegaTexturing.

Un pdf intéressant définissant un tel système : http://lefebvre.sylvain.free.fr/oc [...] he_gpu.pdf :

drapalisation , Vous pensez que Intel transposera la dénomination "Extreme edition" sur ses GPUs ?

 
Surtout pas vu le prix des extremes editions
 
 

ben ouais c'est pour sa faut pas les mettre en situation de pseudo monopole

 
Merci tfpsly pour tes compléments d'informations !    Même si je suis un béotien total dans le rendu 3D les nouvelles technos dans ce domaine.
 
Et la nouvelle techno 3D de Carmack c'est moins gouramand que le raytracing ???
 

Ouais merci tfpsly
Mais même avec cette nouvelle techno il y a un espèce d'aliasing (dernière photo sur le nez de la Mercedes).

Ben si j'ai un peu compris ce qu'est cette techno, c'est en fait une image et au lieu d'etre calculée par blocs de pixels , c'est par cubes ( des carrés en 3D) qu'elle est calculée. Mais biensur, l'aliasing reste présent puisqu'on ne passe que dans une dimension de l'objet, ce qui n'enleve pas son effet carré, si ce n'est qu'un chouia... Tout faux ?

3 solutions à l'aliasing : découper les cubes jusqu'à avoir plus petits que la taille d'un pixel sur le near clip plane de la caméra. Interpoler entre les cubes. Ou ne pas afficher directement ces cubes, mais y stoquer des textures contenant plus d'infos sur la géométrie. La dernière solution permettant de ne pas trop découper l'octree.

oui mais c'est la plus gourmande, voir complexe ? Car l'aliasing dans le principe c'est simple, diviser un pixel pour en calculer des plus petits à la place, non ?

Pas les pixels ; les voxels, les cubes.
Et on ne peut les diviser à l'infini du fait de l'explosion de la taille en mémoire. Si on fait attention, on en voit encore sur la seconde image de la Mercedes.
 
Quand à interpoler entre les vexels, cela peut aussi être couteux car les cubes voisins peuvent être très éloignés dans l'arborescence de l'octree.
 
Et avoir plus d'info sur la géométrie dans des voxels plus grands augmente certes les calculs finals du pixel ; mais cela permet aussi de réduire la profondeur de l'octree.
 
De toute façon ceux ne sont que des hypothèses, on ignore ce que va faire Carmack (lui aussi l'ignore encore en grande partie, puisque c'est encore en R&D).
 
PS : je me demande si ce système est implémentable sur les SPEs de la PS3. Ce qui permettrait de mieux balancer les perfs entre le CPU puissant et le GPU dépassé. Mais j'ai peur que ce ne soit trop de calculs pour le Cell. Et surtout que ça occupe complètement le CPU, ne laissant pas beaucoup de perfs pour le reste du jeu.

pour moi la nécessité de progrès est dans l'éclairage pas dans la rasterisation.
 
ok pour échantillonner dans un voxel, ça fait hype, mais quid de la solution d'éclairage employée ?
 
actuellement la R&D chez tout le monde c'est comment faire de l'illumination globale en pseudo-temps réel.

Cay moche le nom "Larrabee"

L'arabe ?  
Non c'est vrai que c'est moche. Ca donne pas envie d'acheter

Un grand merci a tfpsly pour les explications
Comanche (de Novalogic's) et le Voxel Space, superbe a l'époque, et il tournait pas si mal sur mon 486DX2 66....
A l'époque le Voxel space était bien loin devant le rendu 3D, surtout pour le rendu de terrain, on avait qq chose de relativement, comment dire, organique, tout en courbe
Mais la montée en puissance des cpu a vu arriver une nouvelle gen de jeux en 3D qui ont tué le Voxel space.
Magic carpet lui aussi utilisait le voxel space, non et LBA?

Magic Carpet non, on voit bien les polygones : http://www.mobygames.com/game/dos/ [...] Id,313339/
LBA non : les décors étaient prérendus avec zbuffer au chargement des salles dans une gigantesque image dont seule une partie était visible. Puis les charactères étaient affichés en temps réel en réutilisant le zbuffer du décors pour les cacher derrière les objets et murs fixe. Source : Frédérick Raynal himself.

A oui tien, dans mes souvenirs il me semblait que, menfin c t pas hier non plus
Donc en gros on avait les comanche, et delta force...et heu...
bon sur Wiki j'ai trouvé :
    * Many NovaLogic games have used voxel-based rendering technology, including the Delta Force series and the Comanche series.
    * Westwood Studios' Command & Conquer: Tiberian Sun and Command & Conquer: Red Alert 2 use voxels to render most vehicles.
    * Westwood Studios' Blade Runner video game used voxels to render characters and artifacts.
    * Outcast, a game made by Belgian developer Appeal (now bankrupt), sports outdoor landscapes that are rendered by a voxel engine.
    * The videogame Amok for the Sega Saturn makes use of voxels in its scenarios.
    * The turn-based strategy game Sid Meier's Alpha Centauri renders all units and terrain in 3D using voxels.
    * The computer games Vangers and Perimeter both use a voxel renderer. Perimeter relies on voxels for its unique terrain molding.
    * The computer game "Thunder Brigade" was based entirely on a voxel renderer, according to BlueMoon Interactive making videocards redundant and offering increasing detail instead of decreasing detail with proximity.
    * Master of Orion 3 uses voxel graphics to render space battles and solar systems. Battles displaying 1000 ships at a time were rendered on computers without hardware graphic acceleration.
    * Build engine first person shooter games Shadow Warrior and Blood use voxels instead of sprites as an option for many of the items pickups and scenery. Duke Nukem 3D has an optional voxel model pack created by fans, which contains the high resolution pack models converted to voxels.
    * Crysis uses voxels for its terrain system.
    * Worms 4 Mayhem uses a "poxel" (polygon and voxel) engine to simulate land deformation similar to the older 2D Worms games.
    * The multi-player role playing game Hexplore uses a voxel engine allowing the player to rotate the isometric rendered playfield.
 
 
Incroyable ! ! !

Tu peux aussi ajouter Quake !
Les persos lointains étaient affichés sous formes de gros voxel placés sur les vertexes à la place des triangles.

je crois pas pour magic carpet et lba mais par exemple myst (en tout cas le 1er et le 2ème) utilisait le raytracing pour rendre les images affichées (c'était du précalculé donc possible même il  y a 15 ans)

 
ça c'est du backface culling.

 
yo  

faite péter les videos §§