Intel et Larrabee

**Tramb** · 13/12/2007, 18h03

Bien d'accord en ce qui concerne la bande passante, je pensais plutôt au problème de garder les caches synchrones entre cores et avec la mémoire centrale.
Problème que les GPU n'ont pas car ils font bien la différence entre entrées read-only (streams de vertices, textures... ) et render targets de sortie et écrivent dans des macroblocs qui ne s'intersectent pas. Bref ils ont la belle vie.

Alors que j'espère que Larrabee permettra de bosser sur des données en mémoire centrale in-place sans 12 tonnes de setup et d'adaptations.
Ceci dit la solution la plus sensible serait de pouvoir locker les caches sur les cores, ça serait facile à utiliser ET performant

Mais bon peut-être que je rêve et que ce sera moins general purpose que je ne l'imagine.

**Alice** · 13/12/2007, 18h07

Cuda autorise l'écriture dans des blocs qui s'intersectent... Dans ce cas il faut gérer les accés concurrents à la main. Idem en ce qui concerne la lecture/écriture d'un même bloc de donnée.

**Tramb** · 13/12/2007, 18h10

Envoyé par Alice

Cuda autorise l'écriture dans des blocs qui s'intersectent... Dans ce cas il faut gérer les accés concurrents à la main. Idem en ce qui concerne la lecture/écriture d'un même bloc de donnée.

Ah tiens au temps pour moi, ceci dit je connais pas CUDA nous on passe par DX9 comme API de GPGPU, c'est génial :-D

**Doc TB** · 13/12/2007, 18h14

Envoyé par Tramb

Ah tiens au temps pour moi, ceci dit je connais pas CUDA nous on passe par DX9 comme API de GPGPU, c'est génial :-D

GG !

**Alice** · 13/12/2007, 18h15

Envoyé par Tramb

Ah tiens au temps pour moi, ceci dit je connais pas CUDA nous on passe par DX9 comme API de GPGPU, c'est génial :-D

A l'ancienne

... Ce n'est pas forcément plus mauvais. Je m'explique en codant une application par cuda on obtient pas forcément de meilleures perfs qu'a travers OpenGL/D3D. Par exemple l'écriture dans un Transform Feedback Buffer (terminologie OpenGL) est un cas typique d'accès concurrents à un tableau. En Cuda on peut faire du Stream Compaction avec un prefix scan pour faire la même chose. En OpenGL c'est tout masqué (et 10x plus facile à coder). Résultat OpenGL est BCP plus rapide que cuda... Les drivers, ca aide pas mal!

**PrinceGITS** · 14/12/2007, 09h46

Envoyé par fefe

Oui, c'est nettement plus drole

. Par exemple, on n'a jamais aussi peu parle du K10 que depuis qu'il est sorti...

J'ai ri comme un con tout seul dans mon bureau.

Envoyé par Alice

Honnêtement... plus ça va et plus je pense que le Cell est bien foutu dans sa phylosophie.

Bizarrement, je trouve aussi que Larrabee va dans le sens du Cell. Avoir des multitudes de coproc non spécialisés permet d'être très maléable. Par contre, les développeurs ont beaucoup plus de travail à fournir pour bien exploité l'architecture.
Cela fait longtemps que je n'avais pas été aussi intéressé par l'architecture d'un composant.

**Alice** · 14/12/2007, 11h27

Envoyé par PrinceGITS

Par contre, les développeurs ont beaucoup plus de travail à fournir pour bien exploité l'architecture

Justement, peut être pas tant que ça en fin de compte. Un GPU est assez facile à programmer à première vue mais bien l'exploité c'est bcp moins drôle. Une API comme OpenGL ou D3D sont des monstres sans nom bien difficile à approcher et ce n'est qu'après pas mal d'expèrience qu'on arrive à comprendre l'API dans sa globalité. De plus leur évolution anarchique est un foutoir sans nom... Vas y que je te rajoute les texture array!!!! Conceptuellement pourquoi à ton besoin de texture array! En Soft ça se code en un rien de temps. Avec une API on doit se taper la couche d'abstraction de tout ce joyeux bordel en comprenant bien qd on peut l'utiliser ou non et pourquoi tout ça est bien ou pas! Une fois maitrisé c'est bien pratique mais cet ensemble de solutions "ad'hoc" est sans doute tout aussi dur à apréhender qu'une archi comme le Cell... Pour un développeur qui nage dans la prog graphique depuis pas mal de temps, l'évolution de son API est incrémentale donc assez naturelle, pour un nouveau venu c'est le mont Everest qu'il doit escalader!

**PrinceGITS** · 14/12/2007, 11h42

D3D et OpenGL sont aussi fait pour pouvoir être utilisé sur d'autres machines (respectivement Xbox360 et toutes platformes qui supporte l'OpenGL). Donc les API doivent être décalé par rapport au hardware.
On tend quand même depuis quelques années vers un language détaché du matériel (prog objet and co). Et je pense justement que le SDK de Sony manque d'abstraction. D'où les problèmes des programmeurs actuels à maitriser la bête.

On le voit bien d'ailleurs que peu de programmeurs mettent encore les mains dans le cambouilli. Il y a très peu de moteurs graphiques très poussés dans l'optimisation. J'en vois 4, les moteurs de Carmack, le Source Engine (même s'il date

), les Unreal Engine et les CryEngine. Tous les autres sont soit sous license des ces 4 soit des moteurs multiplaformes moyen de gamme (renderware and co).

L'avantage d'Intel sur cette partie est que ce sera du x86 donc connu de tous. L'API n'aura pas besoin d'être aussi abstraite.

**Yasko** · 14/12/2007, 11h52

Le problème de l'abstraction, c'est que plus y en a et moins c'est performant.

Le x86, c'est aussi très abstrait (CISC => RISC).

µops power !

**Eld** · 14/12/2007, 11h52

Envoyé par PrinceGITS

Bizarrement, je trouve aussi que Larrabee va dans le sens du Cell.

Le Cell est quand même très hiérarchique, avec un "maître" PPE et des "esclaves" SPE, je ne crois pas que Larrabee aille dans ce sens
edit: et oui, x86 c'est mal -_-

**PrinceGITS** · 14/12/2007, 11h53

C'est quand même moins abstrait que les API.

Les microops, c'est bien mais chiant à programmer. Je préfère une bonne petite fonction toute faite !

EDIT : la philosophie du Cell est quand même très proche. Un proc central (CPU/PPE) et de coprocs génériques (SPE/Larrabee).
L'architecture est très différente, c'est sûr.

**Alice** · 14/12/2007, 12h05

Effectivement OGL tente de s'affranchir du hard et du soft. D3D ne s'affranchi lui que du hard puisque ne tournant que sur plateforme Microsoft (Hop un petit flameware gratuit en passant). Mais cela n'explique pas pour autant leur développement tentaculaire. Développer en soft ne veut pas dire se lier à un matos particulier. C'ets vrai qu'a un moment ou un autre, pour une appli devant tourner sur N plate-formes très différentes, il faudra une couche d'abstraction qui masque le tout. Mais le problème n'est finalement pas là.

Malgrès la présence d'API, un prog 3D devra utiliser tel ou telle fonctionnalité plutôt que telle ou telle autre du fait de la spécificité du GPU cible! Les programmes de NVidia et d'ATI pour développeur de jeu en est un parfait exemple. Pour aller plus loin, il n'est pas rare que les dev de jeux envoient leur shaders (basé sur une API donc) à NVIdia pour que leurs ingènieurs adaptent le code à leur GPU...

En ce qui concerne les Moteurs optimisé je pense qu'il faut aller plus loin que ceux qui sont médiatisé... Le moteur PS3 de Uncharted par exemple est semble t'il une boucherie sans nom avec du code qui déssoude (Id-Software ne s'y ai d'ailleur pas trompé vu qu'ils ont débauché un des codeurs en question). Je doute que ce jeu soit une exeption. A contrario, le source engine est un peu crado sur les bords qd à l'Unreal Engine 3 il n'est pas la panacé qu'on esseille de nous faire croire. Carmack et son ID-tech5 va être selon moi quelque chose de propre et de carré. Bref un bon moteur à la carmack aux choix techniques cohérents, d'après ce qu'on en sait. Techniquement il surpasse même le Cry-Engine2. Il risque sans doute de mettre moins de poudre aux yeux mais techniquement il sera la panacé... C'est simple, le mega-texturing est LE choix technique à avoir.. mais bon, je m'égare

EDIT: Le CryEngine2 est le plus beau... mais techniquement il est la sédimentation de N techniques ad'hoc. En étant pragmatique et vu le résultat c'est le bien. D'un point de vu technique c'est pas le top...

**PrinceGITS** · 14/12/2007, 12h27

'tain, je pensais pas être aussi à la ramasse niveau soft et hard.

Bon, on s'est un peu égaré du sujet vu qu'Intel va essayé de faire passer le ray tracing avec Larrabee.

**Eld** · 14/12/2007, 12h28

Envoyé par PrinceGITS

L'architecture est très différente, c'est sûr.

je parlais surtout niveau architecture effectivement

**Tramb** · 14/12/2007, 12h34

Mouais là on est hors-sujet (mais on s'en fout

) mais je vois pas où est *le* choix technique dans le mega-texturing.
Tel que je vois ça, on échange du CPU contre de la RAM (un cache de sous-partie de megatexture) et de la bande passante IO (pour charger le cache) et ça va pas du tout dans le sens de la compression et synthèse de données.
Ca marche quand on se déplace lentement dans le monde (FPS ou jeu de bagnole) mais bon...

Pour fabriquer cette méga-texture on ne va pas me faire croire que les artistes vont poser chaque pixel mûrement choisi à la paluche sans instancier ouat'mille trucs. Un artiste c'est feignant

(un bon programmeur aussi).

D'ailleurs j'ai remarqué que Crysis ne chargeait pas trop les CPUs sur un quad-core par contre la 8800 donc il y'a encore du taf les p'tits allemands!
Et effectivement visiblement le Unreal Engine tout neuf n'est pas la panacée spécialement en prod.

**Yasko** · 14/12/2007, 12h39

Envoyé par Tramb

Mouais là on est hors-sujet (mais on s'en fout

)

Il y avait un topic créé par Alice dans la partie Software d'x86 sur les API, les moteurs, etc.
Si un modo le retrouve dans les décombres, peut-il le ramener ici ? (bon, c'est pas du hardware, mais c'est du very advanced)

**Neo_13** · 14/12/2007, 12h45

http://forum.canardplus.com/showthread.php?t=18986 ?

**Yasko** · 14/12/2007, 12h51

Oui, c'est celui là je crois. C'est pas Alice qui l'a enfanté, mais c'est tout comme.

**Neo_13** · 14/12/2007, 13h04

ben mp sam ou tink ou ... pour ça

**Yasko** · 14/12/2007, 13h13

Je créerais bien un topic "@MODOS : Demandes de rappatriement" pour y lister les topics à secourir, mais ca va rien arranger au clivage x86/coanards.

**Neo_13** · 14/12/2007, 13h18

Envoyé par Yasko

Je créerais bien un topic "@MODOS : Demandes de rappatriement" pour y lister les topics à secourir, mais ca va rien arranger au clivage x86/coanards.

en meme temps, ça va se tasser.

**Alice** · 14/12/2007, 14h44

Le hors sujet c'est bon... mangez en

... Allez une petite dernière sortie du sentier Larabee

Envoyé par Tramb

Tel que je vois ça, on échange du CPU contre de la RAM (un cache de sous-partie de megatexture) et de la bande passante IO (pour charger le cache) et ça va pas du tout dans le sens de la compression et synthèse de données.
Ca marche quand on se déplace lentement dans le monde (FPS ou jeu de bagnole) mais bon...

A première vue on comprend pas trop l'intérêt du truc. Ca semble pas compliqué des masses, ca n'a pas l'air de révolutionner le truc... bref ça semble presque tout bidon. Ceci étant d'un point de vue prog système et multi-plateforme c'est du tout bon. Que ta plate-forme ait 4Go ou 64Mo de mémoire pour le texturing, le scheduler de texture reste le même, est totalement transparent et la finesse des textures sera bien bien bien (...) meilleure qu'avec une approche classique.

Deplus ça va très bien avec la compression de données!. Le papier de Sylvain Lefebvre qui introduit le mega-texturing utilise une compression par ondellettes pour stocker la mega-texture. Lors du rendu, en fonction de la bande passante et/ou de la quantité de mémoire disponible, le détail (les hautes fréquences) de la texture sont envoyés ou pas et en ça la compression par ondellettes est parfaitement adaptée.

Enfin, en ce qui concerne les artistes effectivement ils ne vont pas peindre chaque pixel à la main... Tout d'abord ils vont utiliser des tiles comme à leur habitude et ensuite ils affineront à la main de façon totalement intuitive: On dégrossit avec des tiles, on affine au pinceau. De ce fait, fini le vertex blending! L'avantage c'est qu'on décorrèle totalement l'apparence de la texture avec la représentation du maillage (normal!) ce que le vertex blending ne permet pas.

Bref, il y a sans doute des défauts dans le mega-texturing, mais pour l'heure ce type de scheduler de texture permet de virtualiser la plateforme cible de façon très élégante et efficace. Comme bonus, il offre à l'artiste une totale liberté sur l'habillage de l'environnement. Pour le type de jeu, Carmack parle de résoudre le problème du zoom sur une zone non pré-chargée avec l'ID-tech5... Je ne vois pas trop quelle idée il a derrière la tête mais s'il a une solution efficace elle pourrait éventuellement répondre à un déplacement rapide du joueur

**PrinceGITS** · 14/12/2007, 14h54

Connaissant Carmack, je pense qu'il va réussir à finaliser son concept de méga texture.
Il me semble que son moteur v4 a été un peu précipité pour sortir.

**Paul Verveine** · 14/12/2007, 14h55

pourquoi ne pas les laisser là bas ça reste leur place

à vous aussi de vous déplacer

**Alice** · 14/12/2007, 15h00

Envoyé par PrinceGITS

Il me semble que son moteur v4 a été un peu précipité pour sortir.

Pourquoi? Non non il a bien été finalisé...

**PrinceGITS** · 14/12/2007, 15h12

Surtout la partie mega texture qui était très pratique pour les couloirs de Doom 3.

**Alice** · 14/12/2007, 17h24

En fait dans Doom3 il n'y avais pas de mega-texture. l'ID-tech4 et le mega-texturing c'est uniquement à partir de ET Quake Wars

**Erokh** · 14/12/2007, 18h34

Et on voit ce que ça donne...
visuellement pour l'instant, l'intérêt est loin d'être flagrant

M'enfin pour ET, j'ai vraiment l'impression que les dev' ont vraiment foutu ça parce qu'on leur a demandé. En grosj 'ai vraiment le sentiment que la mega-texture pour ET, c'est une volonté uniquement politique, et que les dev' s'en seraient très bien sorti sans

**Alice** · 14/12/2007, 19h12

Visuellement l'intérêt n'est et ne sera pas flagrant Avec un texturing plus classique tu peux obtenir le même résultat... Par contre pour une quantité de mémoire donnée on obtient une plus grande finesse de texture. En bonus on allège également le drivers des N activations/désactivations nécéssaires aux N textures. De plus le création de contenue est plus aisée et, en ce qui concerne les textures, libre de toute contrainte. En fait ce n'est pas un nouveau effet à la mode qui fait plaisir a la rétine du chalant habitué aux effets qui vomissent du marketeux "next gen"! Ca fait la même chose qu'avant mais en bcp bcp mieux de tout les points de vue (artistique, performances, terchnique...). Alors oui c'est moins tape à l'oeil que les effets du moment mais techniquement c'est le bien.

Pour ET, splash damage n'a été obligé en rien. Ils ont bossé avec l'ID-tech 4 et se sont donc basé sur les technologies proposées par ce moteur voilà tout

. En fait ce qui trouble le plus dans ET ce n'est pas les Mega-texture mes les intèrieurs d'un autre age ou les joueurs semblent flotter et éventuellement le style artistique. Mais bon là on s'éloigne bcp trop du sujet initial

**fefe** · 15/12/2007, 21h22

Envoyé par Alice

Le hors sujet c'est bon... mangez en

... Allez une petite dernière sortie du sentier Larabee

Je suis a fond pour les hors sujets de qualite

. C'est pas comme si nos topics avaient a etre transforme en une dissertation structuree... Et le cote "soft" du graphique j'ai arrete avant qu'on ne parle de "shaders" donc je suis un tantinet a la bourre et ne crache pas sur l'education

Discussion: Intel et Larrabee

Outils de la discussion

Règles de messages