Crunchez vos adresses URL
|
Rejoignez notre discord
|
Hébergez vos photos
Page 2 sur 19 PremièrePremière 1234567891012 ... DernièreDernière
Affichage des résultats 31 à 60 sur 567

Discussion: Intel et Larrabee

  1. #31
    Citation Envoyé par fefe Voir le message
    a supposer que la premiere generation soit commercialisee.
    Déjà.

    Car si ça se trouve, le Larabee qui sortira réellement ne ressemblera probablement pas du tout à celui qu'on connait (16 à 64 équivalents de pentium mmx). Je pensais à Nehalem, mais je m'avance en terre inconnue là .

  2. #32
    Citation Envoyé par Alice Voir le message
    Tout à fait... Sauf peut être le Kyro (le 1 était déjà compétitif). Le problème c'est qu'Intel risque de ne pas l'être (compétitif) même avec un Larabee 2 ou 3. Larabee est une sorte de "canard boiteux" qui veut faire de la rastérisation et du lancer de rayons. Ca semble plutôt sympa puisqu'on peut combiner les avantages des 2 techniques mais en fait on se traine surtout leurs inconvénients combinés. Du plus, au niveau architecture, les avantages de l'une deviennent les inconvénients de l'autre. Bref, Intel l'a compris et voudrait vite passer à un tout lancer de rayons. Problème, le lancer de rayons n'a pas vraiment de marché. En temps réel il demeure une douce utopie et se limite à peu de triangles (sic!...), à une faible résolution et à des scènes quasi statiques. En rendu hors ligne il est souvent beaucoup trop lent (Pixar ne l'utilise finalement que depuis peu de temps). Reste la simulation d'éclairage et le rendu d'images fixes ce qui est un marché assez restreint.

    Bref à voir mais je pense que Larabee risque surtout de se prendre une grande claque dans la face sous des benchmarks conventionnels et donc de se décrédibiliser. Quant à l'avenir, ce n'est pas une démo avec 2 réflexions et 3 ombres franches qui fera réver les foules.
    Larrabee ne vise pas particulierement le lancer de rayons imo, c'est juste qu'en etant base sur du hardware generique, typiquement un peu faible en fonctions specialisees 3D et en debit flottant mais excellant dans du code a branchements le raytracing y brillera beaucoup plus que sur un GPU. D'ou l'interet pour le marketing d'en parler alors que le hard n'existe pas: ils ne prennent pas trop de risques en disant qu'il y aura de bonnes perfs.

    En revanche je pense que tu oublies certains parametres dans ton evaluation de la mauvaise perf de Larrabee: il y a de bonnes chances qu'Intel le grave sur leur meilleur process et de la taille du reticule des machines de gravage. Intrinsequement ca leur donne un avantage minimum de 50% de surface et 30% de vitesse contre l'ensemble de leur competiteurs (ceux qui utilisent leur process les plus avances). Contre ceux qui sont un peu en retard en terme de process, la difference est encore plus importante.

    Donc oui Larrabee a de bonnes chances d'etre inefficace face a ce qui y est investi, en revanche face a la competition je doute qu'au dela de la premiere generation un tel avantage lie au process ne se traduise pas par un produit competitif (haut de gamme, pas de limite de prix). La premiere generation ils devront tuner leurs drivers et comprendre leurs bottlenecks architecturaux, et effectivement il y a de bonnes chances qu'ils soient tres loin de la competition. En revanche si ils insistent j'ai un doute qu'ils ne comblent pas une bonne partie du retard.

    Avec un investissement suffisant, il est tout a fait possible de construire un GPU decent en 2 ou 3 generations, et Intel si il le veut a l'argent. La question restante est de savoir a quel point ils le veulent.
    fefe - Dillon Y'Bon

  3. #33
    Citation Envoyé par fefe Voir le message
    En revanche je pense que tu oublies certains parametres dans ton evaluation de la mauvaise perf de Larrabee: il y a de bonnes chances qu'Intel le grave sur leur meilleur process et de la taille du reticule des machines de gravage. Intrinsequement ca leur donne un avantage minimum de 50% de surface et 30% de vitesse contre l'ensemble de leur competiteurs (ceux qui utilisent leur process les plus avances). Contre ceux qui sont un peu en retard en terme de process, la difference est encore plus importante.


    Le 32 nm est utilisé dans les SRAM que fabrique Intel. Larabee sera probablement avec le même process s'il sortait vraiment en 2008, surtout avec 16 unités physiques (entendez par là des problèmes de surchauffe et de superficie du die).

  4. #34
    Meme si c'est du 45nm et qu'il tape out en 2008 il aura une bonne generation d'avance (arrivera dans un process bien maitrise, qui sera tout juste accessible a la competition).
    fefe - Dillon Y'Bon

  5. #35
    Juste encore un peu hors sujet ...

    fefe, concernant Larabee effectivement ils visent sans doute plus qu'un GPU sauf que de base, Larabee vise le marché GPU haut de gamme (dixit Intel) et il est donc censé se comporter tel quel. En ce qui concerne leur avance technologique et les moyens qu'ils peuvent investir je suis tout à fait d'accord... Ceci dit ils ont un travail assez énorme à fournir. Coder un driver digne de ce nom n'est pas rigolo (50 millions de lignes de code ne tombent pas du ciel), et aller explorer des secteurs plus obscur (Lancer de rayon) est plus que risqué (API à définir, tout à faire...etc) . S'ils se prennent un gros pavé dans la face ça risque de les refroidir sévèrement pour réinvestir dans les générations à venir (cf ce que tu disais).

  6. #36
    Citation Envoyé par fefe Voir le message
    Larrabee ne vise pas particulierement le lancer de rayons imo.
    Il me semble avoir entendu parler d'une solution mixte Rasterisation / RT, du moins dans un premier temps. Ce qui peut sembler judicieux, car les outils de prod actuels sont dédiés à la rasterisation, et il faudra un peu de temps pour les adapter et les rôder.

    Quant aux drivers D3D x86, ils risquent en effet d'être assez complexes à mettre en oeuvre. Cela étant, le rendu en RT repose sur des algos assez simples, enfin en comparaison à la rasterisation et tous les effets qui vont avec.

  7. #37
    Citation Envoyé par Alice Voir le message
    Juste encore un peu hors sujet ...

    fefe, concernant Larabee effectivement ils visent sans doute plus qu'un GPU sauf que de base, Larabee vise le marché GPU haut de gamme (dixit Intel) et il est donc censé se comporter tel quel. En ce qui concerne leur avance technologique et les moyens qu'ils peuvent investir je suis tout à fait d'accord... Ceci dit ils ont un travail assez énorme à fournir. Coder un driver digne de ce nom n'est pas rigolo (50 millions de lignes de code ne tombent pas du ciel), et aller explorer des secteurs plus obscur (Lancer de rayon) est plus que risqué (API à définir, tout à faire...etc) . S'ils se prennent un gros pavé dans la face ça risque de les refroidir sévèrement pour réinvestir dans les générations à venir (cf ce que tu disais).
    Je suis tout a fait d'accord avec toi pour ce qui est du driver. Quand on voit la qualite actuelle des drivers GPU Intel (le nombre d'applis qui fail tout comme les updates qui amenent 20% de perf moyenne) c'est un signe qui ne trompe pas.

    Pour ce qui est des histoires d'optimisations pour un workload ou un autre je serais prudent avec ce qui vient du marketing d'Intel avant que le produit n'existe effectivement . Le fait que l'objectif primaire du produit soit le marche du GPU est assez evident, le fait qu'ils veuillent faire de la pub en disant que ca fait aussi le cafe et les hot dogs est assez peu surprenant, mais a mon avis c'est a peu pres comme les pretentions actuelles de certains fabriquants de GPU de faire un takeover sur les applications scientifiques qui tournent aujourd'hui sur des CPUs classiques (c'est possible, mais ca ne va pas se produire du jour au lendemain).
    fefe - Dillon Y'Bon

  8. #38
    tiens les posts ont ete bouges mais le thread apparait comme lu pour moi.
    fefe - Dillon Y'Bon

  9. #39
    Citation Envoyé par Franck@x86
    Il me semble avoir entendu parler d'une solution mixte Rasterisation / RT
    Ca se fait dans quelques papiers: Les rayons primaires (ceux qui partent de l'oeil jusqu'au premier triangle intersecté) sont géré par le raster ce qui comprend le shading et compagnie. Le lancer de rayons gère alors tous les effets plus globaux comme le reflexions.

    Citation Envoyé par Franck@x86
    Ce qui peut sembler judicieux, car les outils de prod actuels sont dédiés à la rasterisation, et il faudra un peu de temps pour les adapter et les rôder.
    C'est une solution had'oc qui risque d'avoir du mal à se démocratiser. Le raster est super puissant pour le shading et les transformations géométriques. De plus il tirera très bien parti de la structure de partitionnement de l'espace du lancer de rayons, pour culler pas mal de triangle. Problème: la structure de partitionnement de l'espace marche bien pour du statique... pas pour du dynamique puisque ca demande une mise à jour encore très couteuse. Autre problème, le rayons secondaires du RT sont souvent très incohérent et donc ne tire que très peu parti d'un lancer de rayons cohérent donc perf--. Enfin pour achever la chose, la prochaine évolution des GPU est l'unité de tesselation. En raster ça va tout seule de tesseler "on the fly". En RT rajouter des triangles c'est toucher a la structure de partionnement de l'espace donc perf--. Pour conclure là dessus, les seuls outils de prod qui utilise le RT pour la visualisation interactive, utilise un rendu progressif (on part d'une résolution pourri et on affine qd l'image devient fixe) hors la majorité des infographistes vomissent sur ce genre d'approche et préfèrent de la visu en wireframe ou en gouraud de base qu'un truc aussi mauvais.

    Citation Envoyé par Franck@x86
    le rendu en RT repose sur des algos assez simples
    C'est vrai sauf que le RT c'est une énorme boite noire qu'il faut modifier à la base pour ajouter un effet. Un exemple: la tesselation (cf plus haut). D'un point de vue développeur c'est moins "souple".
    Dernière modification par Alice ; 12/12/2007 à 18h20.

  10. #40
    Citation Envoyé par fefe
    Pour ce qui est des histoires d'optimisations pour un workload ou un autre je serais prudent avec ce qui vient du marketing d'Intel avant que le produit n'existe effectivement . Le fait que l'objectif primaire du produit soit le marche du GPU est assez evident, le fait qu'ils veuillent faire de la pub en disant que ca fait aussi le cafe et les hot dogs est assez peu surprenant, mais a mon avis c'est a peu pres comme les pretentions actuelles de certains fabriquants de GPU de faire un takeover sur les applications scientifiques qui tournent aujourd'hui sur des CPUs classiques (c'est possible, mais ca ne va pas se produire du jour au lendemain).
    Complètement d'accord. Le GPGPU fonctionne plutôt bien mais à mon avis c'est une solution bancale. Cuda/CTM clarifie un peu la chose mais ça reste la zone pour programmer la chose. (Le hard est toujours masqué, les specs loin d'être carrées, la hiérarchie mémoire un bordel sans nom...etc). L'approche du Cell est selon moi mieux adapté à ce type d'application. Il est présenté comme un proc pour faire du calcul qui fait mal, nu de toute couche d'abtraction. La spec est carré, la latence controlable, l'éxécution in order...etc En fin de compte et contrairement aux idées reçues, il est "facile" de maitriser le Cell... bien plus qu'un GPU par cuda ou même par OpenGL/D3D...
    Dernière modification par Alice ; 12/12/2007 à 19h51.

  11. #41
    un truc qui est intéresant avec larabee c'est qu'amd a le même projet dans ses cartons pour 2009 avec le rapprochement ATI/AMD

    alors nouveau marché ?
    Dernière modification par Paul Verveine ; 13/12/2007 à 01h49. Motif: question

  12. #42
    Citation Envoyé par Niluje Voir le message
    un truc qui est intéresant avec larabee c'est qu'amd a le même projet dans ses cartons pour 2009 avec le rapprochement ATI/AMD

    alors nouveau marché ?
    j'avoue esperer qu'AMD puisse tirer son épingle du jeu sur ce coup parcque le K10...
    Fucking IN business is fucking THE business

  13. #43
    de toute façon pour amd, le seul moyen de résister est de sortir de bon processeurs bien performant ou de réussir à casser les prix...

    heureusement que les 38xx ne sont pas mauvaises parce que sinon ça irait vraiment mal, enfin pas mauvaise aujourd'hui mais par rapport aux geforce 9 de demain...



    d'ailleurs je viens de me rappeler un autre truc, intel a racheter le mois dernier une boîte de solutions physiques (ou graphiques me souviens plus très bien mais c'était plus physique je crois), de quoi aquérir un peu plus de compétence technologique face à nvidia ou au duo AMD/ATI

  14. #44

  15. #45
    Citation Envoyé par Niluge
    un truc qui est intéresant avec larabee c'est qu'amd a le même projet dans ses cartons pour 2009 avec le rapprochement ATI/AMD
    Tu veux parler du projet Fusion? Fusion a une approche différente comparée au Larabee. Ils veulent intégrer le CPU et le GPU dans un même die et visent l'entré de gamme. Larabee lui est un coprocesseur à part entière et vise le haut de gamme.

    Citation Envoyé par Niluje
    d'ailleurs je viens de me rappeler un autre truc, intel a racheter le mois dernier une boîte de solutions physiques (ou graphiques me souviens plus très bien mais c'était plus physique je crois)
    Intel a racheté aussi Neoptica. Une boite bien graphique avec des gros noms dedans. Intel rachète presque tout ce qui se fait de mieux dans le domaine du RT. Bref ils se donnent "quelques" moyens pour arriver à leur fins...<_<

  16. #46
    yep je voulais parler de fusion.

  17. #47
    Fusion pour l'instant on ne sait pas si:
    -ils vont mettre un die de GPU un die de CPU dans le meme package avec un lien HT entre les 2
    -ils vont mettre un GPU et un CPU sur un die avec HT on die
    -ils vont redesigner un monstre qui est capable d'executer du x86 et du graphique sur les memes cores a l'interieur d'un die (Larrabee)
    fefe - Dillon Y'Bon

  18. #48
    Le projet d'Intel est quand même furieusement proche d'un CPU classique donc de là à ce qu'ils arrivent à un projet genre fusion avec CPU multi-core et larabee sur le même die...

    Mes Lego - Tof : Canon EOS 40D + Tamron 17-50mm F/2.8 + Canon Seepdlite 430 EX II | VDS MadCatz Arcade Fight Stick TE

  19. #49
    Citation Envoyé par fefe
    usion pour l'instant on ne sait pas si:
    -ils vont mettre un die de GPU un die de CPU dans le meme package avec un lien HT entre les 2
    -ils vont mettre un GPU et un CPU sur un die avec HT on die
    -ils vont redesigner un monstre qui est capable d'executer du x86 et du graphique sur les memes cores a l'interieur d'un die (Larrabee)
    Désolé pour le raccourci un peu brutal... Heureusement que fefe corrige tout ça. Ceci étant Larabee est plus un chapelet de "Pentium MMX++" qu'un GPU. De ce fait il demeure pour moi du x86 pur ju qui peut, certe faire du graphique raster, mais au même titre qu'un CPU conventionnel (coder un raster en x86 n'est pas la mort). Pour l'aider un peu on lui ajoute des unités fixe d'un GPU (sampler de texture...etc) mais bon ca reste un set de CPU x86. Fusion semble être plutôt un GPU conventionnel (stream processor) ET un CPU classique (donc plutôt tes 2 premiers points). Mais à vrai dire ce ne sont que des suppositions basées sur des informations pas forcément bien avérées (donc sur rien dutout). Bref à voir mais Fusion ne me semble pas une approche ala Larabee...

  20. #50
    Oui, Fusion, comme son nom l'indique, rapproche le CPU et le GPU. Je ne pense pas qu'il s'agisse d'un truc aussi ambitieux que l'art à bi.
    Et pour ce qui est de ce rapprochement, je vote pour 2 dies distincts reliés par HT (ta 1ère proposition fefe).
    Pour que le marketing d'AMD si fier de son quadcore "natif" reconnaisse que l'approche d'Intel est pragmatique, elle doit leur faire sacrement mal au fut leur nativité.

  21. #51
    Je n'avais pas ose mettre une 4 eme ligne:
    -modifier suffisament un GPU pour qu'il execute du x86 . Ca c'est l'approche Nvidia, pas l'approche AMD.

    Pour l'approche 2 dies sur un package, il n'y a pas que AMD qui peut le faire, et le pro du packaging de plusieurs dies au dernier moment jusqu'a aujourd'hui c'est Intel .
    fefe - Dillon Y'Bon

  22. #52
    Citation Envoyé par Alice Voir le message
    De ce fait il demeure pour moi du x86 pur ju qui peut, certe faire du graphique raster, mais au même titre qu'un CPU conventionnel (coder un raster en x86 n'est pas la mort). Pour l'aider un peu on lui ajoute des unités fixe d'un GPU (sampler de texture...etc) mais bon ca reste un set de CPU x86.
    Et on peut espérer qu'ils documentent ça aussi bien que le jeu x86 actuel ?
    Citation Envoyé par Wanou Voir le message
    Je t'aime...
    :wq

  23. #53
    Si c'est juste destine a etre un GPU, probablement pas, si ils comptent l'ouvrir a d'autre types d'applis, probablement. Et honnetement je ne pense pas qu'on aura la moindre reponse credible avant que Larrabee ait tapeout...
    fefe - Dillon Y'Bon

  24. #54
    Y a toujours les rumeurs, spéculations, démentis, promesses, chiffres hallucinants... On va bien s'amuser d'ici la sortie.

    Mes Lego - Tof : Canon EOS 40D + Tamron 17-50mm F/2.8 + Canon Seepdlite 430 EX II | VDS MadCatz Arcade Fight Stick TE

  25. #55
    Oui, c'est nettement plus drole . Par exemple, on n'a jamais aussi peu parle du K10 que depuis qu'il est sorti...
    fefe - Dillon Y'Bon

  26. #56
    Salut les gars, je suis nouveau dans le coin.

    quelqu'un sait comment se fera l'adressage mémoire sur les ti'cores d'un point de vue du programmeur?

    Scratchpad et DMA à la VU ou SPU?
    Mémoire partagée avec page-fault qui ramène tout tout seul?

    J'ai vaguement cherché sur le net mais peut-être que quelqu'un ici sait.
    Sleeping all day, sitting up all night
    Poncing fags that's all right
    We're on the dole and we're proud of it
    We're ready for 5 More Years

  27. #57
    D'apres les rumeurs qui parlent d'utilisation de coeurs x86 existants (des pentiums) la 2 eme solution est la plus probable parce qu'elle demanderait moins d'efforts (c'est plus complique a faire quand on n'a rien, mais quand on l'a deja pourquoi l'enlever ? ).

    Et bienvenue.
    fefe - Dillon Y'Bon

  28. #58
    Ca se tient ma foi, ceci dit je sais pas si les controlleurs mémoires classiques sur les architectures x86 tiennent bien la charge sur un parrallèlisme un peu plus massif que maintenant. Ou alors ça va être *très* sensible aux patterns d'accès, ce qui est somme toute moins chiant (se taper des pénalités vs gèrer à la main) et permet de coder le truc qui marche et de l'optimiser après.

    Finalement la solution manuelle a clairement des avantages de ce point de vue-là pour les architectes système en déplacant le problème sur les codeurs

    Et merci.
    Sleeping all day, sitting up all night
    Poncing fags that's all right
    We're on the dole and we're proud of it
    We're ready for 5 More Years

  29. #59
    Etant donne qu'il n'y avait pas de controleur memoire integre avec les Pentium et que meme si il y en avait eu, la techno de RAM supportee serait de la SDRAM ou de l'EDO, et qu'ils visent le marche des cartes graphiques discretes ou aujourd'hui des bandes passantes enormes sont necessaires pour etre competitifs, je pense ne pas m'avancer en disant qu'ils vont probablement developper une solution ad hoc.
    Dans le pire des cas ils importeront des controleurs memoire de chipsets recent et en mettront un paquet (sur une carte graphique il est possible d'avoir pour pas trop cher des bus de donnees tres large parce qu'ils n'ont pas besoin d'aller loin et la qualite de la ram est sous controle).
    Si ils arrivent avec une bande passante memoire ressemblant de pres ou de loin a un CPU ils ont perdu d'avance, et je ne doute pas qu'ils le sachent.
    fefe - Dillon Y'Bon

  30. #60
    Citation Envoyé par fefe
    c'est plus complique a faire quand on n'a rien, mais quand on l'a deja pourquoi l'enlever ?
    Pour donner toutes les cartes en main au développeur? ... Honnêtement... plus ça va et plus je pense que le Cell est bien foutu dans sa phylosophie. La latence doit être géré à la main donc maitrisable. Les instructions sont In Order et bien que les SPU soit "dual issue" tu écris du code tu sais exactement comment il sera executé... etc. Résultat une multiplication de matrice 4000 par 4000 à pu se faire en utilisant 90 à 95% des perfs théoriques de la bête. Avec un GPU obtenir ne serais ce que 80% du pic de puissance dans une application autre que théorique est déjà plus coton... Bref sur un coproc voué à du calculs massifs, pourquoi pas ne pas donner toutes les cartes aux devs... Si Larabee vise autre chose que du graphiques ça ne semble pas être une mauvaise initiative.

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •