Crunchez vos adresses URL
|
Rejoignez notre discord
|
Hébergez vos photos
Page 14 sur 19 PremièrePremière ... 4678910111213141516171819 DernièreDernière
Affichage des résultats 391 à 420 sur 567

Discussion: Intel et Larrabee

  1. #391
    Si j'ai bien compris, larrabee 2 ne verra pas le marché non plus, il était prévu pour fin 2010.

    @+, Arka



  2. #392
    Larrabee R.I.P
    fefe - Dillon Y'Bon

  3. #393
    C'est juste la version graphique qui est morte, le projet computing continue non ?

  4. #394
    Oui sauf que quand tu enleve tout ce qui etait pour le graphique la ressemblance entre les 2 devient assez distante. Disons que l'on peut aussi appeler Nehalem un Pentium Pro.
    fefe - Dillon Y'Bon

  5. #395
    Hum, je croyais que les coeurs et le ring bus étaient deux trucs majeurs, et ceux-là y'a vraiment des raisons de les changer ?

  6. #396
    Les texture samplers, les DMA, toutes les instructions specifiques au code graphique qui n'ont plus de raison d'etre (plus le changement global d'ISA discute dans un autre article qui pointait vers l'absence de compatibilite des"futures generations"avec le LRB originel). Gardes tu la GDDR ou evolues tu vers de la DDR buffered pour la capacite ?
    Tu as un Ringbus dans Beckton aussi (et beaucoup d'autres projets) et il change a chaque fois suivant les besoins du projet en question.

    Il y aura certainement reutilisation d'une partie importante du ring, du core et de l'ISA vectorielle, oui... Donc c'est une question de nomenclature: a partir de quelle quantite de changements changes tu le nom de l'architecture...
    fefe - Dillon Y'Bon

  7. #397
    Oui, je vois très bien ce que tu veux dire
    En fait, je croyais bêtement que le projet n'avait ajouté que très tardivement du HW pour le graphique.

  8. #398

  9. #399
    Ca depend ce que t'appelle Larrabee: si c'est le concept d'executer de l'OpenGL et du DirectX sur un multicore a base de x86 (c'etait ma comprehension et celle de beaucoup de monde), le projet est mort. Si c'est l'idee de faire un multicore avec des Pentium et AVX alors le projet est toujours en vie.

    Mais au final ce qui compte est: le nom de code est il encore utilise en interne a Intel ? Je suppose que ce genre de detail filtrera a un moment ou a un autre et il sera facile de se decider si ce projet est vivant ou mort .
    fefe - Dillon Y'Bon

  10. #400
    Ou alors c'est un zombie qui va ressortir de terre dans 5 ans comme Nehalem.

  11. #401
    Nehalem n'a jamais ete tue, ses objectifs ont toujours ete les memes, le projet a toujours garde son nom bien qu'il soit passe par de nombreuses incarnations (presque autant qu'un chat ).
    fefe - Dillon Y'Bon

  12. #402
    Quelle est la raison de vouloir à tout prix réutiliser/ressusciter un nom de projet ? Ne pas avouer qu'un produit a été abandonné ? Ce serait un aveux d'échec face aux investisseurs ?
    Parce que bon, c'est pas les noms de code qui manquent...

  13. #403
    Bonne question . Je dirais pour des raisons de PR, mais qu'est ce que je sais ?
    fefe - Dillon Y'Bon

  14. #404
    PR = Public Relations j'imagine ? Ou alors Page Rank, Pension de Retraite, Prévention Routière

  15. #405
    Citation Envoyé par Foudge Voir le message
    PR = Public Relations j'imagine ?
    Ouep.

    Et les noms de code finissent toujours par filtrer et se retrouver sur CanardPC ou SemiAccurate. Ça serait faire un cadeau à la concurrence que d'exposer la durée de vie de ses projets...

  16. #406
    Ouai, mais c'est pas comme si la concurrence n'arrivait pas quasiment toujours a connaitre les noms internes et les durees de vie des projets

  17. #407
    C'est bien ce que je dis. Tant que le nom interne et la durée de vie du projet ne change pas, tout va bien, même si ce qui est derrière le nom n'a plus rien à voir.

  18. #408
    http://www.techradar.com/news/comput...ctical--716960

    Enfin une communication interressante
    fefe - Dillon Y'Bon

  19. #409
    C'est un peu une banalité ce qu'il raconte, non ? Comment ça blazé ?

    Ca me fait penser à certaines personnes qui disent qu'un jeu d'instructions multimédia, ça ne sert à rien, le H.264 ça se fait en HW et c'est plus économe. La belle évidence. Et hop vp8 sort, ha merde on n'a rien pour accélérer, on sait faire que H.264.

  20. #410
    Citation Envoyé par newbie06 Voir le message
    Ca me fait penser à certaines personnes qui disent qu'un jeu d'instructions multimédia, ça ne sert à rien, le H.264 ça se fait en HW et c'est plus économe. La belle évidence. Et hop vp8 sort, ha merde on n'a rien pour accélérer, on sait faire que H.264.
    Tu peux avoir un ensemble de briques de base génériques accélérées en hard et du soft autour pour s'adapter au codec X ou Y. C'est pas non plus comme si les algos étaient vraiment différents d'un codec à un autre...

    Faut juste arriver à trouver le bon compromis... Oui, c'est une banalité.

    Sinon il y a d'autres moyens de permettre de la généricité que de faire des processeurs. Faire du reconfigurable, par exemple.

  21. #411
    L'approche Larrabee n'était pas mauvaise. Essayer de lui mapper le modèle de programmation DX/GL était une erreur techniquement parlant. Le tout soft lui permettait de s'affranchir des contraintes des API, contraintes dictées par les limitations des GPU, GPU longtemps designés pour répondre aux limitations directes des API graphiques.

    Un problème auto alimenté dans lequel Larrabee n'avait pas sa place en tant que solution mais plus en tant qu'alternative:
    http://www.semiaccurate.com/forums/s...ead.php?t=3361.

  22. #412
    Citation Envoyé par newbie06 Voir le message
    C'est un peu une banalité ce qu'il raconte, non ? Comment ça blazé ?
    Non justement il y a quelques details qui font que ce n'est pas une banalite...
    fefe - Dillon Y'Bon

  23. #413
    Citation Envoyé par fefe Voir le message
    Non justement il y a quelques details qui font que ce n'est pas une banalite...
    Desole, mais je ne vois pas. Je me bats regulierement pour expliquer aux gens que les voies full IP vs fully programmable ne sont pas les bonnes, alors ce qu'il raconte me semble banal.

    En revanche, un truc interessant est sa reponse a la question de savoir si l'equipe avait jamais cru pouvoir faire une carte graphique a base de LRB. C'est cela que tu voulais pointer du doigt ?

  24. #414
    Moi non plus j'ai beau relire l'article je ne trouve pas de détail caché, ça doit être plus gros que ça alors.

    Je note aussi qu'il ne parle que des unités spécialisées pour la rastérisation.
    Le modèle de programmation, le jeu d'instructions, la micro-archi... ne sont pas mis en cause dans l'échec (programmé?) du GPU Larrabee.

  25. #415
    Je n'ai pas dit qu'il etait explicite . Effectivement il ne parle que des unites de rasterization. Maintenant, pars du principe que tu ne peux pas faire la rasterization en soft, peux tu encore faire le reste du pipeline en soft etant donne la position de ton rasterizer dans le pipeline (meme si ces fonctions sont faisables individuellement en soft et ce de maniere efficace)?
    fefe - Dillon Y'Bon

  26. #416
    Hum, tu veux parler des pixel shaders qui se trouvent après la rasterization ?

  27. #417
    Oui, maintenant dessine le graphe de dependance dataflow entre tes cores generiques et les divers blocs de fonctions dediees (textures samplers et ajoute le rasterizer).
    Tu verras que tu as un gros join de taches paralleles generiques avant et apres un bloc ou tu es oblige de tout effectuer en serie. Donc au lieu d'avoir n cores qui travaillent en parallele, tu as une grosse barriere quasiment au milieu de ton pipeline en terme de quantite de calculs a faire. L'efficacite de ton load balancing vient d'exploser. En plus de la synchro tu dois router toutes les donnees... Pas particulierement difficile a faire dans une architecture dediee comme un GPU, particulierement impossible a integrer a un multicore classique qui n'accepte des fonctions dediees que comme un comme un coprocesseur accessible par MMIO.
    fefe - Dillon Y'Bon

  28. #418
    Citation Envoyé par fefe Voir le message
    Maintenant, pars du principe que tu ne peux pas faire la rasterization en soft, peux tu encore faire le reste du pipeline en soft etant donne la position de ton rasterizer dans le pipeline (meme si ces fonctions sont faisables individuellement en soft et ce de maniere efficace)?
    Euh... Genre avec un système de buffers ou passage de message tels que des threads puissent envoyer des sommets d'un côté et d'autres threads puissent récupérer des fragments de l'autre côté?
    J'imagine aisément que le scheduling, la synchro et le load balancing sont alors un merdier immonde à gérer en soft, mais a priori je ne vois pas d'impossibilité...

    [OK, tu as répondu...]

  29. #419
    Oui c'est tout a fait faisable, mais pour le faire efficacement, tu redesignes effectivement un GPU, et tu n'arrives plus a employer un multicore generique sans l'exploser, d'ou l'interet 0 d'une solution generique. Ca me semblait quand meme etre une revelation d'importance , meme si ce n'etait pas evident.
    fefe - Dillon Y'Bon

  30. #420
    Bah suffisait de coller des unités dédiées au pixel shading, des dizaines/centaines à la nVidia/AMD et avec leur propre jeu d'instruction parce que forcément des décodeurs x86 c'est un peu gros. Et voilà, facile. Ha mince, on n'a plus besoin du x86 du coup sauf ptet pour le vertex shading et la tesselation

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
  •