Crunchez vos adresses URL
|
Rejoignez notre discord
|
Hébergez vos photos
Affichage des résultats 1 à 25 sur 25

Discussion: Via Isiah

  1. #1
    Un article detaille et interressant sur leur nouvelle architecture: http://www.extremetech.com/article2/...2252201,00.asp

    Il restera bien entendu a voir la qualite de leur implementation, mais c'est interressant de voir qu'ils ont essentiellement comble leur retard theorique avec cette archi.
    Dernière modification par fefe ; 06/02/2008 à 17h58.
    fefe - Dillon Y'Bon

  2. #2
    Tu me prends de vitesse fefe !

    L'article de arstechnica est intéressant aussi (j'ai pas lu celui de extremetech) :
    http://arstechnica.com/articles/paed...cpu-isaiah.ars

    et biensûr celui de Sam aussi :
    http://www.canardplus.com/news-22572...on_de_cpu.html

    Les perfs en FP pourraient expliquer la possibilité de décoder du bluray en 100% soft. Pour info avec mon A64 3000+ j'arrive pas a décoder du bluray, si le CN était plus puissant qu'un A64 a fréquence égale ça ferait un sacré bond pour les perf des CPU VIA !

    edit: il serait même plus puissant, mon 3000+ tournant à 1.8 et le CN à 1.4 ... intéressant tout ça !

  3. #3
    http://www.pcinpact.com/actu/news_multi/41412.htm

    Ce que j'adore chez PCI, ce sont les titres qui transgressent la teneur du sujet (genre on balance l'effet "ultra braiiiiiite").

    Le titre c'est "VIA prépare un nouveau processeur, double coeur et 64 bit", alors qu'on ne sait rien sur la nature dual-core d'emblée.

    Puis la source "ZDNet", pour ne pas dire autre chose :D

  4. #4
    Ouais, PCI c'est un peut trop "bling bling" pour moi. Politiquement je ne m'y fais pas. J'y ai trainé mes guètres longtemps pourtant mais ils m'ont eu à l'usure.

  5. #5
    Leurs latences FPU sont impressionnantes, même pour du pipeline court à 2 GHz...
    Mis à part le fait que l'additionneur utilise un algo révolutionnaire kitusarasse, j'imagine qu'on ne connaît pas plus d'info dessus?

    Et le fused multiply-add il sera exposé en software?
    (idée fixe : je veux un FMA en x86)

  6. #6
    Citation Envoyé par Møgluglu Voir le message
    Leurs latences FPU sont impressionnantes, même pour du pipeline court à 2 GHz...
    Mis à part le fait que l'additionneur utilise un algo révolutionnaire kitusarasse, j'imagine qu'on ne connaît pas plus d'info dessus?

    Et le fused multiply-add il sera exposé en software?
    (idée fixe : je veux un FMA en x86)
    Tsss fefe va te dire qu'il vaut mieux continuer à faire des add et des mul et laisser le CPU fusionner
    So RISCy!

    Edit : phôte.
    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

  7. #7
    La discussion sur le FMA est looongue, faut pas me lancer . Il y a beaucoup d'arguments pour et beaucoup de contre .

    Mais si une chose est bien sure c'est que tu ne peux pas betement laisser le CPU le faire pour des raisons numeriques. Le CPU ne peut pas prendre les decisions de precision a la place de l'utilisateur, du moins tant que l'on reste dans les normes actuelles (en fait, il peut le faire mais detecter les cas ou c'est possible est particulierement couteux, et il reste pas mal de cas ou ca n'est pas possible...).
    fefe - Dillon Y'Bon

  8. #8
    Citation Envoyé par fefe Voir le message
    La discussion sur le FMA est looongue, faut pas me lancer .
    Au risque de sortir du sujet, je tiens à faire part de l'excellente initiative de nVidia, qui a réussi à créer un opérateur qui comporte tous les inconvénients du FMA et bien d'autres encore sans aucun des avantages, et qui l'utilise joyeusement à tort et à travers sans aucune possibilité de désactiver cette merveilleuse feature.

    J'ai nommé le MAD tronqué-arrondi.

    Celui-ci est composé d'un multiplieur simple précision, suivi d'un additionneur simple précision.
    Seulement, comme ils ont voulu radiner sur le silicium tout en se laissant la possibilité d'être IEEE-compliant un jour, ils ont mis une unité d'arrondi (au plus près) à la fin, mais pas au milieu où on a simplement une troncature.
    Leur circuit comporte probablement de la logique pour bypasser l'additionneur et utiliser l'unité d'arrondi pour faire des multiplications IEEE.

    Le résultat, c'est que dans la doc de Cuda on peut lire un truc qui ressemble à :

    Notre GPU est IEEE-compliant
    excepté pour quelques détails, tels que:
    - la division implémentée avec un inverse et une multiplication
    - la racine carrée avec une racine inverse et un inverse
    - on a que 2 modes d'arrondi et encore pas tout le temps
    - on a pas de dénormaux
    - on a pas d'exceptions
    - ah et puis en passant, notre compilateur va remplacer toutes vos multiplications suivies d'additions par des MAD tronquarondis quand ça l'arrange, ben oui, désolé.


    (j'exagère à peine )

  9. #9
    Il est IEEE-ready et pas full IEEE. C'est une starter édition....

  10. #10
    Citation Envoyé par claneys Voir le message
    Il est IEEE-ready et pas full IEEE. C'est une starter édition....
    Aaaaaaah le double c'est du float-HD
    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

  11. #11
    Mogluglu, leur GPU actuel est prévu pour faire de la prog graphique qui va vite... pas pour du code numérique. Ils essayent de faire croire le contraire avec Cuda mais c'est comment dire... tout simplement faux! Pour un GPU traditionnel la stabilité/précision numérique est folklorique. Au pire s'il y a un conflit quelconque on rajoute un biais pour stabiliser *l'affichage*. Bref il faut ressituer le MAD dans le contexte pour lequel le hard est effectivement prévu et dans ce cas rien n'est particulièrement choquant (à relativiser)... Ce qui l'est c'est leur volte face pour être un tant soit peu sèrieux avec Cuda. Peut être que ça va changer avec le hard à venir mais l'alchimie n'est pas facile.
    1/ Avoir un GPU qui va vite et qui suit les specs d'une API graphique donnée (qui se fiche bien souvent de la précision numérique)
    2/ Avoir une unité de calcul performante pour faire du calcul précis.

    Rajouter du silicium pour l'un de ces points n'est pas forcément bénéfique pour l'autre

  12. #12
    Mouais je cracherais pas sur un peu plus de prévisibilité et de précision dans les GPUs, au moins dans un mode safe, parceque les "undefined behaviours" ont toute une palette d'effet suivant les chips
    Exemple :
    normalize(float3(0)) peut générer des 0, des infinis, et sûrement même des 666
    Donc c'est trompeur tu crois que ton shader est juste, tu le testes ailleurs et hop ça marche plus.
    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

  13. #13
    Citation Envoyé par Alice Voir le message
    Rajouter du silicium pour l'un de ces points n'est pas forcément bénéfique pour l'autre
    Je pense que Larrabee repondra a la question : peut-on avoir les 2 et des performances graphiques decentes.
    fefe - Dillon Y'Bon

  14. #14
    Tramb, ca commence à arriver petit à petit... Mais c'est plutôt grossier et loin d'autoriser du code numérique robuste. De toute façon ce n'est actuellement pas leur but... Bref la seule façon de maximiser les chances qu'un shader fonctionne d'un GPU à l'autre (d'un driver à l'autre!) c'est de suivre à la lettre ce qui est dit et de ne *jamais* essayer de combler les blancs de la doc... ce qui est parfois impossible (sic)

    Citation Envoyé par fefe
    Je pense que Larrabee repondra a la question : peut-on avoir les 2 et des performances graphiques decentes.
    Tout à fait d'accord. En même temps Larrabee semble viser un rendu plus "lancer de rayons". Faire du path tracing par exemple, même lent, sans un semblant de code numérique robuste est un peu n'importe quoi...
    Dernière modification par Alice ; 29/01/2008 à 12h12. Motif: Fusion automatique

  15. #15
    Citation Envoyé par Alice Voir le message
    Mogluglu, leur GPU actuel est prévu pour faire de la prog graphique qui va vite... pas pour du code numérique. Ils essayent de faire croire le contraire avec Cuda mais c'est comment dire... tout simplement faux! Pour un GPU traditionnel la stabilité/précision numérique est folklorique. Au pire s'il y a un conflit quelconque on rajoute un biais pour stabiliser *l'affichage*. Bref il faut ressituer le MAD dans le contexte pour lequel le hard est effectivement prévu et dans ce cas rien n'est particulièrement choquant (à relativiser)... Ce qui l'est c'est leur volte face pour être un tant soit peu sèrieux avec Cuda. Peut être que ça va changer avec le hard à venir mais l'alchimie n'est pas facile.
    1/ Avoir un GPU qui va vite et qui suit les specs d'une API graphique donnée (qui se fiche bien souvent de la précision numérique)
    2/ Avoir une unité de calcul performante pour faire du calcul précis.

    Rajouter du silicium pour l'un de ces points n'est pas forcément bénéfique pour l'autre
    Oui, j'ai pensé la même chose. Un GPU est (litteralement) un processeur graphique. Lui faire faire du calcul scientifique, c'est bien, ca dépote mais c'est pas fait pour à la base et dans l'état actuel des choses. Du coup, ce n'est pas très étonnant de rencontrer des problèmes (même si le marketing sort la pelleteuse au préalable)

    Si "rajouter du silicium pour l'un de ces points n'est pas forcément bénéfique pour l'autre", est-ce que créer 2 gammes de produits est envisageable ?
    Vu les bénéfices de NVidia cette année, je ne doute pas que la faisabilité technique et opérationnelle soit là, mais est-ce que ca vaut le coup ? Y a t'il une réelle demande à ce niveau ? Est-ce que les arguments actuels contre une solution GPGPU (précision, gestion des exception, API, etc.) tomberaient avec une gamme de produit dédiés au calcul de masse ? Va t'on voir des serveurs lame de... cartes de calcul ?

  16. #16
    Je n'ai aucune objection à ce que le hardware soit conçu pour calculer vite et mal. D'ailleurs les GPU ont fait des progrès énormes et leur arithmétique est tout à fait acceptable pour beaucoup d'utilisations.

    Par contre, la couche software au-dessus doit au moins permettre d'exercer un contrôle sur la précision/compliance quand c'est possible. Qu'est-ce que ça coûte d'ajouter un flag de compilation?

    Autrement j'ai l'impression que les développeurs de Cuda se retrouvent écartelés entre les deux camps et commettent des excès des deux côtés.

    Notamment je conseille vivement la lecture du fichier cuda/include/math_functions.h de cuda 1.1. Leur implémentation des fonctions élémentaires est un modèle du genre.

    Par exemple sin et cos. Ils sont disponible en hardware avec une précision très correcte pour les arguments pas trop grands.
    Pour Cuda il a été jugé que ça risquait de ne pas suffire, et on a donc un sin/cos avec réduction d'argument :
    - pour les petits arguments (< 50000), réduction d'argument avec la méthode de Cody-Waite avec 3 constantes sur ~8 bits chacune
    - pour les grands arguments, un authentique Payne-Hanek avec constante sur 160 bits.

    Autrement dit :
    - pour les grands arguments c'est lent. Vraiment.
    - c'est redoutablement précis. Ça vous sort le sinus de 10^22 avec 7 chiffres significatifs, alors même que la distance entre deux flottants successifs est largement supérieure à la période du sinus dans cette zone-là.
    J'attend qu'on me présente une appli du monde réel où on ait besoin de connaître sin(10^22) avec 7 chiffres significatifs... (peut-être que ça fait un bon générateur pseudo-aléatoire?)
    Apparement ils sont un peu schizophrènes chez nVidia...

    Citation Envoyé par Yasko Voir le message
    Si "rajouter du silicium pour l'un de ces points n'est pas forcément bénéfique pour l'autre", est-ce que créer 2 gammes de produits est envisageable ?
    Sur la viabilité je ne sais pas, mais en tout cas c'est bien la direction vers laquelle nVidia et AMD se dirigent. Avec en particulier la double précision qui ne serait (?) disponible que sur les produits GPGPU à la Tesla.

  17. #17
    Citation Envoyé par Møgluglu
    Sur la viabilité je ne sais pas, mais en tout cas c'est bien la direction vers laquelle nVidia et AMD se dirigent. Avec en particulier la double précision qui ne serait (?) disponible que sur les produits GPGPU à la Tesla.
    Il est fort probable que le Tesla en question utilise la même archi que le GPU grand public. Le support des doubles réservé au Tesla servira à justifier le prix exhorbitant d'un rack de cartes graphiques sans sorti vidéo. Donc 2 gammes de produits? Commercialement oui. techniquement j'ai un doute.

  18. #18
    Citation Envoyé par Alice Voir le message
    Donc 2 gammes de produits? Commercialement oui. techniquement j'ai un doute.
    D'un autre côté chaque constructeur produit déjà tout une gamme de dies différents, du G86 au G92 ou du RV610 au RV670.
    Donc s'il conçoivent une archi suffisamment modulaire, ils devraient pouvoir avoir un modèle avec DP et autres features GPGPU qui serve à la fois pour Tesla et le haut de gamme GeForce/Quadro (avec éventuellement ces features désactivées), tandis que tout le milieu et bas de gamme qui représentent la grande majorité des ventes resterait en SP.

  19. #19
    Mouais.

    Rajouter des unités de calcul contre changer le déterminisme des unités de calcul, la complexité est pas vraiment la même hein

  20. #20
    La gamme G8x est globalement basée sur une même archi. On désactive quelque Multi-processor par là, on diminue le bus mémoire par ici on touche un peu la fréquence etc. Paf on a un autre GPU. C'est une mixture technico/commerciale plus que des différences architecturales profondes. La dernière révolution architecturale d'Nvidia remonte au G80 qui proposait des ALU scalaires. Depuis ils n'ont pas vraiment touché au coeur de cette archi. Je vois mal NVidia essayer de proposer 2 archi, l'une en SP l'autre DP, sur des marché aux volumes de ventes complètement différents! A voir...

  21. #21
    vu les marges financières utilisables sur l'archi DP, faut voir...
    Mes propos n'engagent personne, même pas moi.

  22. #22
    fefe - Dillon Y'Bon

  23. #23
    Pas dégueu du tout. Faut voir après en vrai (et en argent) ce que ça donne, mais s'ils le sortent en mini-ITX ... J'ai pas en tête, mais il me semble que le Eee est derrière, non?

  24. #24
    Pas mal en effet !
    C'est quoi le 4ième CPU mystère derrière le logo pcinlife ?

    Ils parlent qu'il serait au niveau d'un PD840 3.2G, penitum-D ? Faudrait comparer les chiffres avec un Core2 ça serait pas mal aussi.

    En anglais by google :
    http://translate.google.com/translat...hl=en&ie=UTF-8

  25. #25
    C'est justement la question que je voulais poser. Je pensais à C2D, mais le 2ème caractère ne ressemble pas à un '2'.

    edit : Sheep 440

    edit2: p'tet un Celeron 440 (noté C440) qui tourne lui aussi à 2GHz

    edit3: pour info ce Celeron est basé sur l'archi Core et possède 512Ko de L2
    Dernière modification par Foudge ; 06/02/2008 à 21h16.

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
  •