Intel et Larrabee

[Alice]

Ca fait maintenant un petit moment que l'on parle du projet "ultra secret" d'Intel à savoir Larrabee. Quelques articles de spéculations, quelques slides...etc Ca parle de 16 à 24 cores x86 in-order de 1.7 à 2.5 Ghz avec 32KB de L1 et 256KB de L2 privé parmis un pool de L2 partagé. On entend aussi parler de fonctions fixes (sampler de textures), d'un ring bus, de 2 double-precision FLOPS scalaire par cycle et de 16-way SIMD. Tout ce beau monde pour du calcul massif comme celui demandé par le ray-tracing. Ray-tracing tellement à la mode qu'NVidia travaille sévèrement dessus en "secret" et qu'Intel débauche à tour de bras les chercheurs en manquent de sensations fortes (et de dollars) (ex: Ingo Wald)

Ceci étant, l'avenir du rendu est au ray-tracing c'est presque sur (ou du moins un rendu hybride raster/RT), les architectures graphiques spéciques deviennent de plus en plus généralistes et performantes (Cuda & G80) et le Cell retourne la poussière qd on le code comme un bourrin (à peu près 3 fois un Core 2 Duo pour du RT codé moyennement). Les questions sont donc nombreuses:

1. Quelles sont les motivations d'Intel? Avec cette révolution qui s'ammorce dans le rendu, veut il devenir LE nouveau guru de la 3D et un acteur majeur dans la calcul hautes performances? A t'il sa place?
2. Intel serat il à la base d'une nouvelle API graphique? API propriétaire ou ouverte?
3. L'architecture est elle cohérente? et finalement à quoi ressemblerat elle réellement?
4. ...

Il y a pas mal de temps déjà (2, 3 ans?) Franck parlait que d'ici 10ans le RT allait venir bouleverser le petit monde du rendu. Je pense que ceci n'a jamais été aussi vrai. Surtout si Intel vient donner un coup de pied dans tout ça avec l'aide des plus gros monstres du milieu.

[Fanche]

et le marché des super calculateurs, ça peut pas y servir un peu? j'avoue être complètement largué la dessus,mais de mes vague souvenir de ce que j'avais lu sur le ray tracing, ça pourrait servir dans les calculs en optique (beam propagation method s'entend)
Quand est-il du calcul matriciel bien bourrin?

[Alice]

et le marché des super calculateurs, ça peut pas y servir un peu?

C'est un de leur but: Défoncer NVidia et son Cuda de "rigolo" avec du x86 bien brutal pour du calcul agressif. le Ray-tracing n'est qu'un exemple (visuel et donc parlant) ou Larrabee s'en sortirait super bien. Le cache associé à chaque core est bien utile dans le parcours de structure de partitionnement de l'espace style kd-tree. Là ou les gens se démènent à trouver des algorithmes de RT efficaces sur GPU (limiter l'utilisation d'un stack...etc), un simple CPU x86 de base s'en sort souvent bien mieux avec un modèle de prog et de gestion mémoire bien plus souple. Utiliser N cores x86 pour un RT cohérent (qui tirerait toute la substantifique moelle du SIMD) semble donc plutôt pas mal. Associer au fait qu'un CPU x86 est de base plus généraliste qu'un GPU il est tout à fait naturel de penser utiliser une telle architecture pour du calcul plus général qui se passerait d'un layout obscur à la Cuda (qui continue de masquer le comment du pourquoi de leur GPU).

[Yasko]

C'est un de leur but: Défoncer NVidia et son Cuda de "rigolo" avec du x86 bien brutal pour du calcul agressif. le Ray-tracing n'est qu'un exemple (visuel et donc parlant) ou Larrabee s'en sortirait super bien.

Faudrait pas qu'ils tardent trop alors, parce que Cuda apporte quand même un gain substantiel sur applis massivement multithread (cf expérimentations de Tridam).
Bon ok, c'était pas du RT, les résultats n'étaient pas non plus transcendants mais d'ici 2009, les GPGPU auront eux aussi progressés et auront peut-être eu le temps de s'implanter, un peu ?
Enfin, tout ça pour dire que les GPGPU ont tout intéret à jouer la course contre la montre, et Intel aussi du coup. A l'IDF, Pat apparemment était assez désinvolte sur le sujet, mais ca doit fouter sec en coulisse...
Maintenant, avec ou sans présence sur le marché, on peut compter sur Intel pour à sa sortie, balayer tous ces insignifiants GPGPU d'un revers de la rabee :D
Et 2009, pour les prémisses RT grand public, ce doit être plutôt bien.

Edit : ajout du "de" qui manquait dans ma vanne, qui du coup était un peu bancale
ah bon, toujours ?

[Alice]

Faudrait pas qu'ils tardent trop alors, parce que Cuda apporte quand même un gain substantiel sur applis massivement multithread (cf expérimentations de Tridam).

Biensur. Le terme de "rigolo" pour CUDA c'était pour illustrer comment Intel semble percevoir le GPGPU. Ceci étant, aussi costaud soit il, Cuda reste une vision d'un processeur voué à faire de la rastérization. Les contraintes imposées (même masquées) sont celles liées à la programmation graphique. Larrabee impose bien sur ses propres contraintes mais semble suffisement généraliste pour rester plus souple qu'un GPU (et donc plus simple à programmer?).

L'alchimie à laquelle NVidia se prête n'est clairement pas triviale: proposer un GPU qui expose des ressources spécifiques (virtualisées travers une API) pour offrir des performances de premier choix comme raster, mais suffisamment générales pour être une plateforme de premier plan dans les calul agressifs massivement parallèles. Dur dur! Peut être que ceci n'est qu'une étape un peu douloureuse pour ne pas être à la traine. En fin de compte peut être que le GPGPU deviendra l'arche de Noé des GPU tel qu'on les connait, laissant la rastérization en vestige du passé...

[Franck@x86]

Larrabee impose bien sur ses propres contraintes mais semble suffisement généraliste pour rester plus souple qu'un GPU (et donc plus simple à programmer?).

J'ai lu je sais plus où que chaque core de Larabee est un Pentium MMX (P55C) équipé du SSE. Ce ne sera peut-être pas aussi performant que des unités ultra spécialisés dans le calcul vectoriel, mais en contrepartie ce sera beaucoup plus facile à programmer ; d'une part parce que le jeu d'intruction x86 est bien connu des programmeurs, mais également parce que les compilos x86 sont super bien rôdés.

[Franck@x86]

Le retour du RT était plus que prévisible. Le RT est la technique la plus simple de rendu, et celle qui donne les meilleurs résultats. Après c'est juste une question de puissance de calcul.

Rappelez-vous que les premiers jeux "en rendu 3D" n'utilisaient pas de polygones mais reposaient sur des techniques 2D dérivées du lancer de rayon : raycasting (Doom) et voxel (Comanche). Bien que simples dans leur principe, elles faisaient plier pas mal de PC de l'époque (un algo de voxel tient en 30 lignes de code !).

[Franck@x86]

Pour ceux que ça intéresse voici les sources d'un vieux moteur de voxel :
http://www.cpuid.com/download/raycast.zip
L'exe tourne (directX 3 !) mais faut passer le bureau en 16 bits.
Et bon forcément c'est un peu speed sur un PC moderne.

[Foudge]

J'ai un DrawInit Failed même avec le bureau en 16bit.
J'ai testé certains modes de compatibilité (je suis sous XP) mais rien n'y fait

edit! j'ai rien dit, j'avais juste décompressé l'executable. Il avait aussi besoin des 2 textures :D

[Alice]

J'ai lu je sais plus où que chaque core de Larabee est un Pentium MMX (P55C) équipé du SSE.

Ici ? Je pense que Larrabee ressemblera autant à un Pentium MMX qu'un Core 2 Duo à un Pentium Pro... Si l'on prend Larrabee - 4 way SMT - 16 way SSE - Vec16 alors oui on obtient un truc qui ressemble à un Pentium MMX...

Le retour du RT était plus que prévisible. Le RT est la technique la plus simple de rendu, et celle qui donne les meilleurs résultats. Après c'est juste une question de puissance de calcul.

Puissance de calcul qui reste encore et toujours problématique... N'oublions pas que les seuls RT intéractifs sont cohérents, ce qui peut poser quelques problèmes dans le cas d'effet où un packet de rayons est fortement incohérent. Ceci étant un RT cohérent est selon toute vraissemblance la prochaine étape majeure pour le rendu intéractif "grand public" ce qui correspond déjà à un rendu sans hack tout pourri lié à la rastérization (au hazard les réflections)

Pour ceux que ça intéresse voici les sources d'un vieux moteur de voxel

Hey Hey... cool

[Franck@x86]

Faut expliquer un peu

Un coup de Google et hop :
La cohérence est une optimisation qui consiste à supposer que les rayons proches tapent le même triangle. L'intérêt est de lancer les rayons par paquets, par exemple par paquets de 4 pour vectorizer facilement avec un jeu d'instruction de type SSE.

[Lissyx]

ça manque de commentaires juste, le source :/

[Franck@x86]

ça manque de commentaires juste, le source :/

L'algo de Voxel ?
bah c'est simple pourtant.
La boucle j lance les rayon sur le plan XY, avec un angle de -fov/2 à +fov/2 (centré autour de l'angle d'origine), avec une altitude de départ (z).
Tu regardes la hauteur du point tapé. z est incrémenté, et tu dessines alors une colonne verticale de pixels tant que z est inférieur à cette hauteur. A l'issue de cette sous-boucle, ton z a atteint une nouvelle hauteur, et lorsque ton rayon poursuit sa route, tu ne dessines que ce qui est plus haut.

Ca ressemble fortement au rendu des murs, sauf que dans ce dernier cas les colonnes sont centrées verticalement (et ça provoque d'ailleurs une grosse déformation des lignes droites due à la projection sphérique).

[Lissyx]

Je parle de l'ensemble du code

[Alice]

Faut expliquer un peu

Yep Désolé :jap:
L'intéret du ray packing est, comme tu viens de le dire, de grouper les rayons dans un vecteur. Cependant, l'intérêt de la cohérence ne vient pas tant du fait qu'un même triangle est intersecté mais plus que le groupe de rayons suit le même chemin et intersecte un groupe de triangles contenu dans une même feuille de la structure de partitionnement de l'espace. Dans le cas où un rayon du paquet ne suit pas le même chemin que les autres, il est alors masqué et n'est plus pris en compte dans les étape suivantes.

Il n'y a aucun gain lié à la paquetisation dans le cas du test d'intersection avec un triangle. Seul l'économie de la logique de parcours de l'espace apporte un réel gain. A noter que paquer les rayons induit forcément un coût lié à la paquetisation/dépaquetisation des rayons et à leur gestion (masquage des rayons incohérents). De ce fait une perte de performances peut être observée si les paquets perdent leur cohérence (ex: réflection sur une surface aux variations de relief denses et complexes)

[Fanche]

ça veut dire quoi intersecter? et paquer?



:D

[Alice]

Petit remontage de post.

Pas grand chose de neuf à se mettre sous la dent si ce n'est qu'Intel à l'air d'en baver. Selon Ingo Wald (monsieur RT intéractif qui bosse chez Intel désormais), ils ont un mal fou pour avoir un pipeline compétitif mais un Larabee 2 est déjà dans les cartons. Bref il semblerait que Larabee soit un coup d'essai pour contrer un tant soit peu CUDA dans les applications massivement parallèles. Quant à proposer du RT intéractifs il y a encore pas mal (trop?) de travail.

Le gros problème avec le RT c'est que tout est une grosse boite noire... Avec la rastérization on cumule plusieurs effets indépendants assez facilement. Avec le RT c'est beaucoup plus compliqué. Par exemple, la triangulation on the fly de la géométrie est la prochaine étape des GPU traditionnels avec une unité de tesselation généralisée à tous les GPU (déjà presente dans le R600). Avec le RT ce n'est pas tant subdiviser qui pose problème mais d'avantage la mise à jour efficace de la structure de partitionnement des triangles dans l'espace ce qui influence directement le coeur même du moteur RT.

Autre problème majeur, l'avantage d'un lancé de rayons c'est de pouvoir gérer des montagnes de triangles de façon efficace (complexity O(log(n)) avec n = nbr de triangles). De ce fait la philosophie de RT c'est d'avaler du triangle. Comme discuté précédemment, les seuls RT intéractifs sont cohérents (<=> ils groupent plusieurs rayons pour traverser la structure de partionnement de l'espace). Hors, plus il y a de détails (de triangles) plus les chances pour que le paquet de rayons restent cohérent (<=> suivent le même chemin) sont faibles. Dès le premier rebond le paquet de rayons peut très bien devenir complètement incohérent. Dès lors la paquetisation des rayons devient une tare plus qu'une force. Si on résume, plus il y aura de triangle plus les RT cohérents seront faibles ce qui est justement un peu à l'envers par rapport à la philosophie du RT. c'est le serpent qui se mort la queue.

Bref si les RT cohérents sont rapides uniquement pour les rayons primaires (rayons qui partent de l'oeil vers la première géométrie intersectée) alors la rastérization est beaucoup plus adaptée. Comme le souligne beyond3D ici, le véritable défit en rendu temps réel n'est pas d'avoir un lancer de rayons performant. le Lancer de rayons n'est finalement qu'un outil de rendu. Le vrai défit c'est d'arriver à résoudre l'équation de rendu en temps réel, cad éclairer la scène avec de l'éclairage direct (source lumineuses) ET indirect (tous les points de la scène qui peuvent emettre eux aussi de la lumière).

Intel ne se poserait-il pas de fausses questions pour résoudre de faux problèmes?

[Møgluglu]

À propos de Cuda, au début j'étais plutôt sceptique mais en fait, plus je l'utilise, plus je trouve le modèle de programmation très simple et efficace.
Plus simple même que la programmation d'un superscalaire : le GPU a déjà suffisamment de parallélisme de données à sa disposition pour qu'on n'ait pas à faire apparaître de parallélisme d'instruction. Donc pas d'histoire de dépendances entre instructions et de remplissage de pipeline.

Du coup je ne suis pas vraiment convaincu par le principe des cores X86+SSEx.

En Cuda j'écris du code scalaire qui va s'exécuter sur une voie SIMD, avec les branchements et les accès mémoire gérés de manière transparente.

Avec Larrabee, soit c'est fait pareil (1 thread = 1 voie SIMD) et dans ce cas la compatibilité X86 n'a aucun intérêt, soit on doit programmer le SIMD "à la main" comme avec les SSE2 (1 thread = 1 ALU X86 + n voies SIMD).

Ou alors on aura un mode X86 et un mode SIMD et pas les deux en même temps... En tout cas je vois mal comment concilier compatibilité et modèle de programmation simple. (J'insiste : pour un problème massivement parallèle, programmer un G80 est bien plus simple que programmer un X86 multicore.)

[Alice]

Cuda est un coup d'essai (specs éronées/incomplètes) mais demeure une belle réussite. Le modèle de programmation par flux de données exposé à travers du C est un pas en avant beaucoup plus sinificatif que le CTM d'ATI/AMD. ATI avoue d'ailleurs à demi mots son incompétence pour sortir son API en étant le seul à présenter dans les Workshop spécialisés du GPGPU sur DX10...

Mais si CUDA est puissant il reste architecturé sur un GPU et est donc soumis à ses forces mais aussi à ses points faibles: La dépendances de données c'est le mal, les accés mémoire ça fait peur surtout qd ils sont aléatoires...etc Oui le modèle de proggrammation par flux est très bien adapté à des calculs hautement // avec des dizaine de milliers de calculs indépendants. Non il n'est pas bien adapté pour de la prog // plus généraliste(?) on dira. 500K threads qui doivent gérer un stack d'appel ou de données ca devient l'horreur sur CUDA... le stack il faut le stocker par thread. Comme la latence mémoire sur GPU est masqué par du calcul et pas par une hiérarchie de caches, la mémoire par thread est ridicule et n'autorise donc pas le stockage de stacks conséquent pour bcp de threads. Il faut donc soit réduire le nbr de threads par block et donc diminuer le parallélisme (sic! :heink: ) soit réduire l'utilisation d'un stack et là ça devient super rigolo. Dans ce cas une archi avec N core x86 & SSE++ avec un cache par core n'est pas forcément moins adaptée.

[Møgluglu]

Cuda est un coup d'essai (specs éronées/incomplètes) mais demeure une belle réussite.

Effectivement, par endroits la doc de Cuda fait bien rire (genre sqrt implémenté avec un rsq et un rcp, ou les MAD "tronqués"...) C'est sûr que nVidia c'est pas Intel.

Le modèle de programmation par flux de données exposé à travers du C est un pas en avant beaucoup plus sinificatif que le CTM d'ATI/AMD. ATI avoue d'ailleurs à demi mots son incompétence pour sortir son API en étant le seul à présenter dans les Workshop spécialisés du GPGPU sur DX10...

Le problème avec CTM, c'est surtout qu'en l'absence d'une version pour Radeon HD 2xxx, AMD n'a juste rien à proposer aujourd'hui contre Cuda.

Que CTM soit plus bas-niveau peut être vu comme un avantage : si on a les specs on peut toujours construire par dessus quelque-chose qui ressemble à Cuda. Ça revient en pratique à écrire un backend spécialisé pour gcc + une petite bibliothèque, ça me semble tout à fait réalisable. On aurait alors le contrôle sur toute la chaîne de compil, contrairement à la boîte noire Cuda.

Mais si CUDA est puissant il reste architecturé sur un GPU et est donc soumis à ses forces mais aussi à ses points faibles: La dépendances de données c'est le mal, les accés mémoire ça fait peur surtout qd ils sont aléatoires...etc Oui le modèle de proggrammation par flux est très bien adapté à des calculs hautement // avec des dizaine de milliers de calculs indépendants. Non il n'est pas bien adapté pour de la prog // plus généraliste(?) on dira.

Certes, mais le G80+Cuda n'a jamais prétendu remplacer un CPU (éventuellement multicore) et un compilo traditionnel. Quoique, sur des applis "// généralistes"...

500K threads qui doivent gérer un stack d'appel ou de données ca devient l'horreur sur CUDA... le stack il faut le stocker par thread. Comme la latence mémoire sur GPU est masqué par du calcul et pas par une hiérarchie de caches, la mémoire par thread est ridicule et n'autorise donc pas le stockage de stacks conséquent pour bcp de threads. Il faut donc soit réduire le nbr de threads par block et donc diminuer le parallélisme (sic! :heink: ) soit réduire l'utilisation d'un stack et là ça devient super rigolo. Dans ce cas une archi avec N core x86 & SSE++ avec un cache par core n'est pas forcément moins adaptée.

C'est vrai que pour une archi prévue en grande partie pour le raytracing, l'absence de vraie pile est problématique. Après, je ne suis pas convaincu que ce soit vraiment nécessaire pour d'autres types d'appli GPGPU, du genre simulations physiques (je fais de la simu de transferts radiatifs, et là ça dépote).

Et effectivement les mémoires internes et les caches sont ridicules. Mais ça c'est un compromis à faire entre puissance de calcul et mémoire, et ça ne remet pas en cause le modèle de programmation de Cuda. On peut imaginer que nVidia sorte un jour un G160 avec une vraie pile d'appels et de la mémoire/des caches en plus, sans rien toucher à Cuda.

Du coup je ne vois toujours pas ce qu'apporterait le x86, par rapport à un langage machine sur mesure.

[Alice]

Effectivement, par endroits la doc de Cuda fait bien rire (genre sqrt implémenté avec un rsq et un rcp, ou les MAD "tronqués"...) C'est sûr que nVidia c'est pas Intel.

RSQ et RCP sont des instructions supportés en hard je pense. Ces instructions sont exposées pour les shaders de l'ARBfp1.0 au NVfp4.0. Aucun SQR n'est exposé. Je pense qu'ils doivent calculé un RSQ par newton et raphston... après le "RCP" consiste à mutliplier par la valeur en question pour avoir son SQR et non son RSQ. bref SQR(x) = x * RSQ(x). pas très couteux et assez efficace pas besoin de s'embêter avec un vrai SQR. Ce qui dérange plus c'est leurs erreurs dans la doc des specs des fonctions de l'API.

Que CTM soit plus bas-niveau peut être vu comme un avantage : si on a les specs on peut toujours construire par dessus quelque-chose qui ressemble à Cuda. Ça revient en pratique à écrire un backend spécialisé pour gcc + une petite bibliothèque, ça me semble tout à fait réalisable. On aurait alors le contrôle sur toute la chaîne de compil, contrairement à la boîte noire Cuda.

CUDA peut exposé l'assembleur généré dans un *.ptx. Certes la doc est absente mais proposer un haut niveau bien documenté et proposer l'accés au bas niveau me semble beaucoup plus appropriée que d'exposer du bas niveau bien documenté et demander un travail de développement pénible et pas dutout normalisé pour avoir du haut niveau... L'approche de NVidia permet à CUDA de se démocratiser rapidement... Celle d'ATI et son CTM non.

Certes, mais le G80+Cuda n'a jamais prétendu remplacer un CPU (éventuellement multicore) et un compilo traditionnel. Quoique, sur des applis "// généralistes"...

Ils ont pourtant essayé de le faire croire... HavokFX est un exemple où la débauche de puissance offerte par le multi CPU n'est pas utilisée car on préfère surcharger le GPU qui a déjà du travail à revendre. Pour de la physique d'effet visuel d'accord... pour le reste....

C'est vrai que pour une archi prévue en grande partie pour le raytracing, l'absence de vraie pile est problématique. Après, je ne suis pas convaincu que ce soit vraiment nécessaire pour d'autres types d'appli GPGPU, du genre simulations physiques (je fais de la simu de transferts radiatifs, et là ça dépote).

On est d'accord... les appli déjà adapté à du GPGPU à l'ancienne sont toujours adapté à du GPGPU à la Cuda.

Et effectivement les mémoires internes et les caches sont ridicules. Mais ça c'est un compromis à faire entre puissance de calcul et mémoire, et ça ne remet pas en cause le modèle de programmation de Cuda. On peut imaginer que nVidia sorte un jour un G160 avec une vraie pile d'appels et de la mémoire/des caches en plus, sans rien toucher à Cuda.

Pouvoir manager des dizaines de milliers de threads, chacun avec sa pile et ses registres? à voir

Du coup je ne vois toujours pas ce qu'apporterait le x86, par rapport à un langage machine sur mesure.

Chacun démarre de son domaine de prédilection. Pour l'un le CPU x86 pour l'autre le GPU. L'un à l'avantage d'être "assez générique" l'autre d'être particulièrement adapté au calcul massivement // sur des données indépendantes. Pour arriver à du RT itéractif (but d'Intel et d'NVidia) tout ça va devrait converger. La concurrence c'est bien.

[fefe]

RSQ et RCP sont des instructions supportés en hard je pense. Ces instructions sont exposées pour les shaders de l'ARBfp1.0 au NVfp4.0. Aucun SQR n'est exposé. Je pense qu'ils doivent calculé un RSQ par newton et raphston... après le "RCP" consiste à mutliplier par la valeur en question pour avoir son SQR et non son RSQ. bref SQR(x) = x * RSQ(x). pas très couteux et assez efficace pas besoin de s'embêter avec un vrai SQR. Ce qui dérange plus c'est leurs erreurs dans la doc des specs des fonctions de l'API.

Newton Raphson n'est interressant que quand tu as a la fois un multiplieur a faible latence et besoin de peu de bits de precision (peu d'iterations), un diviseur a haut radix (16+) offrira des meilleurs latences si tu travailles en float ou double ieee, et il vaudra mieux faire un sqrt.

On est d'accord... les appli déjà adapté à du GPGPU à l'ancienne sont toujours adapté à du GPGPU à la Cuda.

Oui et il reste peu d'applis largement utilisees qui en beneficient, ca reste plus limite a des demos technologiques aujourd'hui (a part qq giltres photoshop peut etre ?).

Chacun démarre de son domaine de prédilection. Pour l'un le CPU x86 pour l'autre le GPU. L'un à l'avantage d'être "assez générique" l'autre d'être particulièrement adapté au calcul massivement // sur des données indépendantes. Pour arriver à du RT itéractif (but d'Intel et d'NVidia) tout ça va devrait converger.

Les outils de dev/debug existant sur x86 sont utilises par un grand nombre, relativement conviviaux et le nombre de dev potentiel est grand ce qui fait qu'il y a plus de monde qui demarre avec x86 comme domaine de predilection (tant mieux pour les devs a l'aise sur GPU ca leur garanti un boulot a l'avenir).

La concurrence c'est bien.

Oui, de voir les GPU offrir des fonctions de plus en plus generalistes et les fabricants de CPU construire des GPUs a base de CPU est qq chose qui ne serait pas arrive sans concurrence et il y a forcement un moment ou ca va vraiment beneficier aux consommateurs (meme si pour l'instant ca n'a pas encore abouti).

[Møgluglu]

RSQ et RCP sont des instructions supportés en hard je pense. Ces instructions sont exposées pour les shaders de l'ARBfp1.0 au NVfp4.0. Aucun SQR n'est exposé. Je pense qu'ils doivent calculé un RSQ par newton et raphston...

Méthode à base de tables + interpolation plutôt, pour RSQ, RCP, exp2, log2, sin et cos.

après le "RCP" consiste à mutliplier par la valeur en question pour avoir son SQR et non son RSQ. bref SQR(x) = x * RSQ(x). pas très couteux et assez efficace pas besoin de s'embêter avec un vrai SQR.

Exactement. C'est comme ça que Cuda et le reste du monde fait.

Ce qui dérange plus c'est leurs erreurs dans la doc des specs des fonctions de l'API.

C'est là où je voulais en venir :D . La doc Cuda dit :

To issue one instruction for a warp, a multiprocessor takes:
- 4 clock cycles for floating-point add, floating-point multiply, floating-point
multiply-add, integer add, bitwise operations, compare, min, max, type
conversion instruction;
- 16 clock cycles for reciprocal, reciprocal square root, __log(x)
[...]
Floating-point square root is implemented as a reciprocal square root followed by a
reciprocal, so it takes 32 clock cycles for a warp.

Comme si après avoir évalué un RSQ avec des tables ou du Newton on allait s'amuser à recalculer un RCP avec de nouveau des tables ou du Newton...

Par contre ce n'est que la doc qui est buggée, la bibliothèque C a l'air correcte, au moins pour ce que je connais (fonctions élémentaires).

CUDA peut exposé l'assembleur généré dans un *.ptx. Certes la doc est absente mais proposer un haut niveau bien documenté et proposer l'accés au bas niveau me semble beaucoup plus appropriée que d'exposer du bas niveau bien documenté et demander un travail de développement pénible et pas dutout normalisé pour avoir du haut niveau...

La doc du PTX est dans le SDK de Cuda. Mais PTX n'est pas l'assembleur généré, c'est un langage intermédiaire à la bytecode Java. La plupart des optimisations ont lieu lors de la traduction PTX -> asm G80 par le driver nVidia à l'exécution.
En dessous de la couche PTX, c'est complètement opaque.

On est d'accord... les appli déjà adapté à du GPGPU à l'ancienne sont toujours adapté à du GPGPU à la Cuda.

Même si Cuda ne sait faire que ça c'est déjà un immense progrès. L'année dernière j'ai passé 4 mois à porter une appli de physique sur G70 et R500 en OpenGL+Cg. À la fin je me suis dit "plus jamais ça!". En Cuda ça me prendrait 1 semaine.

L'approche de NVidia permet à CUDA de se démocratiser rapidement... Celle d'ATI et son CTM non.

Il n'y a pas un moment ou AMD annonçait qu'ils allaient fournir un environnement de plus haut niveau basé sur CTM? Ou c'était une rumeur infondée? En tout cas ce n'est pas insurmontable, même nVidia y est arrivé :whistle:

Chacun démarre de son domaine de prédilection. Pour l'un le CPU x86 pour l'autre le GPU. L'un à l'avantage d'être "assez générique" l'autre d'être particulièrement adapté au calcul massivement // sur des données indépendantes. Pour arriver à du RT itéractif (but d'Intel et d'NVidia) tout ça va devrait converger. La concurrence c'est bien.

Aujourd'hui on a 2 paradigmes : du superscalaire avec parallélisme de tâches d'un côté et du SIMD avec parallélisme de données de l'autre. Des deux côtés on a des compilateurs et outils plus ou moins efficaces.

Multiplier les coeurs et augmenter la largeur des SSE c'est bien, mais il faut aussi faire évoluer les outils en même temps. Si Intel propose quelque chose de convainquant pour exploiter ça, je veux bien (ICC avec auto-vectorisation+TBB?)...

[Alice]

fefe, merci pour les precision sur Newton et Raphson... Tant de savoirs qui s'expose est toujours un plaisir . En ce qui concerne les outils de dev/debug c'est vrai que le x86 à une belle expertise du domaine. CUDA à encore de grands progrets à faire dans le domaine. Même si le débug sur GPU à énormément progressé avec CUDA il reste encore beaucoup de travail pour éviter de planter la machinne à chaque boucle pas très nettes ou d'avoir 2 GPUs l'un se chargeant de l'affichage l'autre pour les applis CUDA.

Møgluglu, je croyais que le ptx n'était presque pas documenté. Merci pour l'info je regarderai tout ça. En ce qui concerne le GPGPU, disons clairement que le GPGPU avant Cuda c'était du bricolage puisqu'il fallait trainer les tare et les zones d'ombres d'une API graphique. De plus, le programmeur GPGPU devait être à la fois calé dans son domaine et dans la programmation graphique ce qui en faisait des hard-crade codeurs de première. CUDA rend tout ça propre et plus adapté à une utilisation plus générale ce qui lui donne ce côté à la mode. Ceci dit CUDA n'est pas le St Graal. Comme le souligne fefe, le GPGPU reste cantoné a des domaines spécifiques où il marche bien. NVidia oeuvre pour le généraliser partout mais c'est loin d'être gagné...

En ce qui concerne AMD, oui ils avaient prévu de sortir une API haut niveau. ATI a été le premier à exposer son GPU ailleurs qu'a travers une API graphique. Mais honnêtement ils aurait pu présenter comment communiquer avec un Koala, ça aurait été pareil. Presenter un concept c'est bien! Le concrétiser c'est mieux.

[Møgluglu]

Newton Raphson n'est interressant que quand tu as a la fois un multiplieur a faible latence et besoin de peu de bits de precision (peu d'iterations), un diviseur a haut radix (16+) offrira des meilleurs latences si tu travailles en float ou double ieee, et il vaudra mieux faire un sqrt.

En rendering traditionnel sur GPU, la principale utilisation du sqrt c'est pour normaliser des vecteurs (division de chaque composante par la norme euclidienne). Dans ce cas la fonction dont on a besoin c'est bien rsq et pas sqrt.

D'autre part sur un GPU la latence est une considération secondaire après le débit, la surface et le power. On préférera un circuit entièrement pipeliné à une méthode itérative.

Sur le G80 c'est implémenté avec des tables et une interpolation d'ordre 2 qui partage du matériel avec l'unité d'interpolation d'attributs. C'est décrit dans ce papier :
http://scholar.google.fr/scholar?hl=...51273586762661

[fefe]

Pour RSQ je sais mais ca ne change pas la comparaison radix vs NR. Les 2 sont iteratifs, et NR consomme des multiplieurs qui pourraient etre utilises a autre chose plutot que d'iterer sur une division ou une racine carree. NR utilise en general une lookup table pour demarrer (la LUT pour les premiers bits ne coute pas grand chose et economise pas mal de latence et d iterations).

Pour la bande passante contre la latence oui, NR est pire qu'un radix pour la bande passante en general (mais consomme moins de hard), et un radix se pipeline. Finalement dans les GPU comme tu le dis la BP est privilegiee par rapport a la latence donc les multiplieurs ont souvent une grande latence ce qui defavorise NR encore plus (chaine de mul dependants).
Le principal probleme des methodes par interpolation est qu'elles ne sont pas ieee compliant (elles peuvent mais le hardware necessaire n'est plus particulierement avantageux), par contre cote bande passante c'est particulierement efficace vu comment ca se pipeline.

Sinon un radix se pipeline aussi, mais ca devient tres couteux pour les hauts radix (qui permettent des latences faibles pas toujours recherchees sur gpu). Il y a des constructeurs de GPU qui utilisent des radix pour faire tout ce qui est division, racines carrees et 1/sqrt donc ce n'est pas necessairement une mauvaise option .

[fefe]

fefe, merci pour les precision sur Newton et Raphson...

J'ai explique un peu plus les histoires de dividers dans le cadre des CPUs dans le contexte de Penryn ici: http://forum.x86-secret.com/showpost...3&postcount=10

L'essentiel s'applique aussi aux GPUs avec le probleme supplementaire de reussire a pipeliner l'operateur, pour le meilleur cout/power, avec des sacrifices de latences moins problematiques que sur les cpus.

Dans le cas du SRT le pre/post processing n'ont pas besoin d etre pipelines car generalement tres courts, par contre pipeliner la boucle principale requiert une duplication massive du hard. Plus le radix est haut moins on replique de fois, plus il est bas plus la logique a repliquer est simple.

[Childerik]

comment y a trop de nouvelles têtes ici.... me sent seul...Niluje aide moi, Prince !
Bon alors les hardeurs, quels sont les sujets chauds du moment par chez vous? :lanceledébat:

Je ne sais pas : Larabee par exemple ? Ca fait quelques temps qu'on n'en a pas entendu parler

[Alice]

Je ne sais pas : Larabee par exemple

Tient c'est une bonne idée... Intel a débauché du beau monde dernièrement (Tim Foley, Pat Hanrahan... bref tout Neoptica). Ils débauchent tellement qu'ils n'arrivent plus à faire venir d'étranger chez eux! (oui et pourtant c'est Intel) Par contre niveau perfs le Larabee risque de se faire défoncer comme il faut. Et ce n'est pas une démo douteuse de QuakeIV RT qui inversera l'euphorie collective envers le GPU plus traditionnels. Mais bon là je fais un hors sujet...

[fefe]

Par contre niveau perfs le Larabee risque de se faire défoncer comme il faut.

Ben oui, je ne connais personne qui ait sorti leur premier GPU et ait ete directement competitif depuis 3DFX. Larrabee est sense se faire defoncer a la premiere generation, a supposer que la premiere generation soit commercialisee.