Crunchez vos adresses URL
|
Rejoignez notre discord
|
Hébergez vos photos
Page 18 sur 30 PremièrePremière ... 8101112131415161718192021222324252628 ... DernièreDernière
Affichage des résultats 511 à 540 sur 883
  1. #511
    Citation Envoyé par fefe Voir le message
    Coude Arm, ok je sors
    J'adore

    @Møgluglu: C'est la première fois que j'entends parler de ce truc. C'est fait par une boite italienne apparemment. C'est normal le ventilo sur le GPU ? Je pensais que comme c'était le bas de gamme du GPU pro mobile, y'en avait pas besoin...

  2. #512
    Citation Envoyé par newbie06 Voir le message
    C'est normal le ventilo sur le GPU ? Je pensais que comme c'était le bas de gamme du GPU pro mobile, y'en avait pas besoin...
    Ça fait 12W d'après les specs, et quand tu mets 256 GPU par rack, le ventilo peut être utile...

    Car pour autant que je sache, c'est plus ou moins du sur-mesure pour le projet Mont-Blanc...
    http://blogs.nvidia.com/2011/11/worl...-in-barcelona/
    Il y a un lien vers les slides de présentation du projet.

    Ce qui m'étonne le plus, c'est que Nvidia ait pu porter ses drivers GPU sous ARM...

  3. #513
    Citation Envoyé par Møgluglu Voir le message
    Ça fait 12W d'après les specs, et quand tu mets 256 GPU par rack, le ventilo peut être utile...

    Car pour autant que je sache, c'est plus ou moins du sur-mesure pour le projet Mont-Blanc...
    http://blogs.nvidia.com/2011/11/worl...-in-barcelona/
    Il y a un lien vers les slides de présentation du projet.
    Elle a pas l'air rackable la carte de SECO.

    Ce qui m'étonne le plus, c'est que Nvidia ait pu porter ses drivers GPU sous ARM...
    Pourquoi est-ce etonnant ? Ca fait quand meme quelques annees qu'ils bossent sur ARM. En plus les drivers CUDA sont peut-etre plus simples que les drivers GPU, non ?

  4. #514
    Citation Envoyé par newbie06 Voir le message
    Elle a pas l'air rackable la carte de SECO.
    Les rapporteurs des projets européens ne s'arrêtent pas sur des petits détails comme ça.

    Mais tu dois avoir raison, sur les slides ils montrent des cartes conteneurs avec 8 modules CPU et 8 modules GPU. La carte est probablement aussi faite par SECO, mais ça serait pas la même que celle présentée sur le site.

    Pourquoi est-ce etonnant ? Ca fait quand meme quelques annees qu'ils bossent sur ARM. En plus les drivers CUDA sont peut-etre plus simples que les drivers GPU, non ?
    Pas sûr qu'ils puissent extraire des drivers le sous-ensemble nécessaire pour CUDA si facilement. Et la carte de SECO a 2 sorties HDMI branchées sur le GPU, ce qui sous-entend qu'à terme c'est censé fonctionner comme carte graphique aussi. Dans tous les cas, ça serait étonnant qu'ils fassent tout ce travail juste pour quelques cartes de dev dont les domaines d'applications sont encore obscurs et un projet de recherche dont ils ne sont même pas partenaires...
    Dernière modification par Møgluglu ; 15/03/2012 à 14h36.

  5. #515
    Citation Envoyé par Møgluglu Voir le message
    Pas sûr qu'ils puissent extraire des drivers le sous-ensemble nécessaire pour CUDA si facilement. Et la carte de SECO a 2 sorties HDMI branchées sur le GPU, ce qui sous-entend qu'à terme c'est censé fonctionner comme carte graphique aussi. Dans tous les cas, ça serait étonnant qu'ils fassent tout ce travail juste pour quelques cartes de dev dont les domaines d'applications sont encore obscurs et un projet de recherche dont ils ne sont même pas partenaires...
    Je connais quelqu'un qui bosse dans l'industrie de la 3D et ca fait deja quelques mois qu'ils ont des machines nVidia ARM pour faire du calcul. Je n'ai pas plus de details, comme souvent

    Donc ca montre que nVidia est relativement avance dans le dev de telles solutions (et ca fait quelques annees qu'il est de notoriete publique qu'ils aimeraient beaucoup avoir une solution GPGPU avec leur propre CPU), ce qui implique evidemment que la partie software est suffisamment fonctionnelle.

    EDIT : message poste chez S|A concernant l'utilisation d'ARM CUDA.
    Dernière modification par newbie06 ; 15/03/2012 à 19h34.

  6. #516
    Je viens de publier un gros article sur ARM en général.

    SI j'ai écrit des énormités (c'est possible), dites-le.

    http://www.presence-pc.com/tests/ARM...pdragon-23448/

  7. #517
    Elle propose soit d'utiliser son jeu d'instructions, soit d'utiliser les architectures qu'elle développe.
    C'est un peu ambigu : ce qu'ARM appelle architecture est justement ce que tu appelles le jeu d'instructions.

    En entrée de gamme, le Cortex A7 devrait remplacer le Cortex A5 et l'ARM11 en entrée de gamme.
    Un peu de repetition la

    si pour le moment seul Qualcomm développe ses CPU en interne
    Tu oublies Marvell ! C'est sur qu'ils ne sont pas vraiment presents dans les mobiles... Applied Micro aussi fait ses propres CPU (ARMv8).

    Un SoC moderne offre une puissance de calcul proche de celle d'un Atom
    Arg ! Ca c'est faux, ou en tout cas clairement pas prouve. Atom approche peut-etre d'ARM a un niveau de consommation similaire, mais en terme de puissance de calcul brut, l'Atom est tres certainement derriere un dual core A9... On verra bien avec Medfield, meme si je doute que cette generation change la donne.

    Rien vu d'autre, nickel

  8. #518
    Merci.

    En usage réel, visiblement l'Atom reste devant, en partie parce qu'il a souvent une fréquence plus élevée et que les devs ont plus l'habitude d'optimiser pour du x86. Après, sur des benchs synthétiques, c'est très dépendant de ce qu'on teste, surtout en 3D : quand on regartde la puce utilisé (PowerVR SGX544MP2), on a l'impression qu'Intel optimise bien ses pilotes, etc., mais la fréquence est juste bien plus élevée.

    ---------- Post added at 10h23 ---------- Previous post was at 10h21 ----------

    Pour Marvell, ils font quoi exactement ? J'ai pas trouvé trop d'infos, et le seul truc Marvell qu'on trouve, c'est le Kirkwood dans les NAS (très courant) et autres Freebox, mais c'est du ARM9, de ce que j'ai pu voir.

    J'ai bien vu un truc Marvell dans une tablette (Panasonic) mais sans qu'ils donnent d'infos.

  9. #519
    Citation Envoyé par dandu Voir le message
    En usage réel, visiblement l'Atom reste devant, en partie parce qu'il a souvent une fréquence plus élevée et que les devs ont plus l'habitude d'optimiser pour du x86. Après, sur des benchs synthétiques, c'est très dépendant de ce qu'on teste, surtout en 3D : quand on regartde la puce utilisé (PowerVR SGX544MP2), on a l'impression qu'Intel optimise bien ses pilotes, etc., mais la fréquence est juste bien plus élevée
    De quel usage reel parles-tu ? Medfield dans un telephone ? Les chiffres viennent d'ou ? Du marketing d'Intel ? Je ne crois pas plus a ces chiffres qu'aux chiffres qu'ARM clame a gauche et a droite. En l'absence de test tiers non pilote par Intel, je vais attendre avant d'emettre un avis, mais d'apres quelques mesures que j'ai faites sur un Atom desktop, j'y crois tres peu.

    Pour Marvell, ils font quoi exactement ? J'ai pas trouvé trop d'infos, et le seul truc Marvell qu'on trouve, c'est le Kirkwood dans les NAS (très courant) et autres Freebox, mais c'est du ARM9, de ce que j'ai pu voir.

    J'ai bien vu un truc Marvell dans une tablette (Panasonic) mais sans qu'ils donnent d'infos.
    Ce n'est pas du ARM9, Kirkwood est du ARMv5 (probablement derivatif du xscale rachete a Intel) et leur derniere puce est ARMv7:

    http://www.marvell.com/communication...comparison.jsp

  10. #520
    Pour les test, un essai rapide du smartphone Orange/Intel, et quelques tests de développeurs : c'est un peu au dessus d'un dual A9, essentiellement à cause de la fréquence, mais évidemment pas au niveau d'un quad.

    Pour Marvell, merci, je pensais que le Kirkwood était un simple ARM9, comme Qualcomm qui rebrand des Cortex A5 dans la gamme Snapdragon

  11. #521
    Citation Envoyé par dandu Voir le message
    Pour les test, un essai rapide du smartphone Orange/Intel, et quelques tests de développeurs : c'est un peu au dessus d'un dual A9, essentiellement à cause de la fréquence, mais évidemment pas au niveau d'un quad.
    Et tu sais quand on pourra voir des vrais tests publics ? J'aimerais beaucoup voir la non-performance des apps natives ARM Puis aussi je me demande ce que ca donne sur la duree, parce que si j'ai bien compris Medfield peut monter en frequence mais uniquement sur de tres courtes periodes ce qui favorise beaucoup les benchmarks courts (genre Sunspider).

    Enfin bref il me tarde de voir des vrais chiffres Medfield

  12. #522
    PC Inpact en a eu un, il sort cet été.

    Enfin, j'y crois moyen au final, vu que les seuls à se lancer c'est Lenovo, Lava et Motorola pas spécialement des spécialistes du smartphone (Motorola est en perte de vitesse).

    Les applis natives ARM, ça risque d'être rigolo : ils parlent d'émulation ou de « ça va pas marcher » sur 25 % des applis du store.

  13. #523
    Citation Envoyé par dandu Voir le message
    PC Inpact en a eu un, il sort cet été.
    Oui, j'ai vu ca, et j'ai bien compris du coup qu'Intel bloquait la publication de chiffres independants...

    Enfin, j'y crois moyen au final, vu que les seuls à se lancer c'est Lenovo, Lava et Motorola pas spécialement des spécialistes du smartphone (Motorola est en perte de vitesse).
    C'est un peu la reflexion que je me suis faite quand j'ai vu l'annonce des partenaires. D'un autre cote ca se comprend : les fabricants sont tres frileux, parce que partir sur du Intel, ca veut dire etre pieds et poings lies avec une seule et unique compagnie. Alors il est probable que les grands vont attendre de voir la reaction du public avant de creer une gamme specifique qui va necessiter un boulot supplementaire au niveau soft plus important qu'un simple changement de fournisseur de SoC ARM.

    Les applis natives ARM, ça risque d'être rigolo : ils parlent d'émulation ou de « ça va pas marcher » sur 25 % des applis du store.
    L'emulation je me suis deja prononce dessus : ils auront au grand minimum un ralentissement d'un facteur 2. Donc soit l'appli passe sont temps dans des lib natives, soit les performances seront tres largement insuffisantes. Apres comme tu dis niveau compatibilite ca peut piquer aussi...

  14. #524

  15. #525
    C'est basé sur un core maison d'AppliedMicro ?

  16. #526
    Citation Envoyé par Møgluglu Voir le message
    C'est basé sur un core maison d'AppliedMicro ?
    Oui, ils ont une license d'architecture.

  17. #527
    Test du tel sous medfield sur anandtech
    http://www.anandtech.com/tag/medfield

  18. #528
    Citation Envoyé par hellsing Voir le message
    Test du tel sous medfield sur anandtech
    http://www.anandtech.com/tag/medfield
    Vade retro ! Ca va dans le thread Atom ca

  19. #529
    Tu y avais déjà posté (même si ça je l'ai vu après).

    C'est surtout qu'on parlait y a 2 pages des perfs/conso et on se perdait en conjonctures.

    Au final tout ça pour ça... Ils auraient dû se focus sur meego

  20. #530
    Citation Envoyé par hellsing Voir le message
    Au final tout ça pour ça... Ils auraient dû se focus sur meego
    Bah c'est pas si mal vu d'ou ils partent. Quant a meego, c'est aupres de Nokia qu'il faut raler

    ---------- Post added at 17h59 ---------- Previous post was at 16h26 ----------

    Rigolo a lire : un bout des tout debuts d'ARM.

  21. #531
    Première démo publique d'un serveur à base de Calxeda ici.

  22. #532
    Ca sort un peu du cadre du topic mais ça parle tout de même de RISC et d'ARM : AnandTech parle du MIPS nouveau ici.
    Dernière modification par Thamior ; 10/05/2012 à 22h22.

  23. #533

  24. #534
    Oui mais ARM11 c'est pas la premiere fois qu'Intel en fait .
    fefe - Dillon Y'Bon

  25. #535
    Citation Envoyé par fefe Voir le message
    Oui mais ARM11 c'est pas la premiere fois qu'Intel en fait .
    Même en 22nm ? Parce que sinon en effet Intel en fait depuis un sacré moment

  26. #536
    En 22nm probablement, mais rien de surprenant a ce que ce soit un core qui a deja ete produit dans d'autres process Intel par le passe. Ca simplifie probablement pas mal de choses.
    fefe - Dillon Y'Bon

  27. #537
    Sortie de la debian optimisé pour les armv11 (le proc des raspberry):
    raspbian

    Le proc s'overclock assez bien sinon (900mhz h24 chez moi). Des gens en ont ici?

  28. #538
    Ouaip, j'en ai un.

    J'avais aussi atteint environ 900 MHz stable (et aussi un peu plus mais instable)

    Raspbian, c'est pas tellement que ce soit optimisé ARMv6 qui apporte des gains, c'est juste que ça utilise la FPU, alors que la Debian précédente travaillait en soft FP.

    C'est de la faute de Debian : y a un portage officiel ARMv5 sans FPU et un ARMv7 avec FPU. Pas de chance, le Raspberry Pi c'est ARMv6 avec FPU...

  29. #539
    D'un autre coté si debian se met à sortir une distro spéciale par ARM ils ont pas fini. Sans le raspberry il n'y aurait jamais eu ce besoin d'exploiter la FPU pour passer calculer rapidement en virgule flottante de manière aussi répandu à travers le monde.

    C'est toi qui a fait le dossier sur presence pc j'ai vu.

  30. #540
    Ouai c'est le foutoir cette segmentation. Un mec me raconte que son appli est bien plus rapide sur Atom que sur Cortex A9 sur Android a cause des instructions FP ; apres avoir creuse la raison etait simple : il avait compile en mode emulation soft FP Je me demande meme comment c'est possible avec le NDK...

Page 18 sur 30 PremièrePremière ... 8101112131415161718192021222324252628 ... DernièreDernière

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
  •