Crunchez vos adresses URL
|
Rejoignez notre discord
|
Hébergez vos photos
Page 3 sur 19 PremièrePremière 123456789101113 ... DernièreDernière
Affichage des résultats 61 à 90 sur 567

Discussion: Intel et Larrabee

  1. #61
    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.
    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

  2. #62
    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.

  3. #63
    Citation Envoyé par Alice Voir le message
    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
    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

  4. #64
    Citation Envoyé par Tramb Voir le message
    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 !

  5. #65
    Citation 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!

  6. #66
    Citation Envoyé par fefe Voir le message
    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.

    Citation Envoyé par Alice Voir le message
    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.

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

  7. #67
    Citation 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!

  8. #68
    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.

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

  9. #69
    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 !

  10. #70
    Citation Envoyé par PrinceGITS Voir le message
    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 -_-

  11. #71
    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.

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

  12. #72
    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...
    Dernière modification par Alice ; 14/12/2007 à 12h11.

  13. #73
    '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.

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

  14. #74
    Citation Envoyé par PrinceGITS Voir le message
    L'architecture est très différente, c'est sûr.
    je parlais surtout niveau architecture effectivement

  15. #75
    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.
    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

  16. #76
    Citation Envoyé par Tramb Voir le message
    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)

  17. #77

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

  19. #79
    ben mp sam ou tink ou ... pour ça
    Mes propos n'engagent personne, même pas moi.

  20. #80
    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.

  21. #81
    Citation Envoyé par Yasko Voir le message
    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.
    Mes propos n'engagent personne, même pas moi.

  22. #82
    Le hors sujet c'est bon... mangez en ... Allez une petite dernière sortie du sentier Larabee

    Citation 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

  23. #83
    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.

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

  24. #84
    pourquoi ne pas les laisser là bas ça reste leur place

    à vous aussi de vous déplacer

  25. #85
    Citation 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é...
    Dernière modification par Alice ; 14/12/2007 à 17h44.

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

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

  27. #87
    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

  28. #88
    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
    pouet!

  29. #89
    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

  30. #90
    Citation Envoyé par Alice Voir le message
    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
    fefe - Dillon Y'Bon

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
  •