La première étape était de produire une carte de développement basée sur une technologie FPGA. Celle-ci vient d'être terminée et est en cours de validation. Elle permettra aux développeurs de logiciel d'avoir les premières versions du GPU et à des développeurs de matériel d'améliorer le projet ou de créer d'autres projets. Elle devrait être mise en vente assez rapidement.
C'est la première étape avant la création du GPU sur un ASIC.
NdM : FPGA, c'est pour le test, la validation, la preuve du bon fonctionnement : ces puces sont chères, mais souples car programmables et surtout utilisées en petites quantités donc non-vendues. ASIC c'est pour la production en grande quantité à destination du marché, donc ces puces sont peu chères et réduisent la consommation électrique et la chaleur dégagée, mais elles sont figées (non-programmables).
![[en]](../images/en.png)
L'annonce (1144 hits)-
Traversal tech (390 hits)
![[fr]](../images/fr.png)
Définition de FPGA (492 hits)-
Techsource (348 hits)
-
Définition de ASIC (300 hits)
> Lire la dépêche (95 commentaires, moyenne: 4,1).
Vous avez demandé le commentaire #791726.
Run by 
Cette page a été générée par Templeet en 0.1169s (dont 0.0101 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
performances
A noter sur le lien de l'annonce :
our target is a frame rate of between 20 and 30 FPS on Quake III at 1280x1024.
C'est donc assez correct (largement suffisant pour faire fonctionner compiz).
[^]Re: performances
Assez correct, c'est quand même relatif. C'est pareil qu'une geforce 2 qui date du millénaire dernier...
En plus si le prix est élevé, je ne vois pas qui en voudrait : une radeon 7500 ou une carte intel avec drivers libre serait bien plus intéressant...
[^]Re: performances
Ils parlent du FPGA !!!! donc ca ne semble au contraire très prometteur :
chez ATI, le premier prototype en FPGA du X800 il faisait combien de fps sous Q III ???
[^]Re: performances
bon, ici on ne parle pas de prototype mais d'objectif, et le x800 xt faisait env 330 images/sec avec quake 3 sous windows en 1280x1024... alors 30fps, c'est, ahem... Pas une carte pour les jeux, pas une carte pour le CAD, sans doutes pas une carte pour la video non-plus...
En plus, du pci, ça a peu ou pas d'intéret pour l'utilisateur, ce format va disparaître complètement.
[^]Re: performances
1°) une gf2 qui fait 30 fps en 1280x1024 sous quake3 ? il doit pas y en avoir tant que ca .
2°) Pourquoi le bus pci ?
Parce qu'il permet un débuggage plus simple. Je rapelle que c'est encore en dvp. Si a chaque test tu fait completement planté ta cg principale (agp par ex) ben forcément la ca va etre un peu plus chaud
Ensuite les normes (agp ou pci express) sont issus de la norme pci.
Subete ga wakatta toki…watashi ga anta wo korosu.
[^]Re: performances
Ma MX400 le fait, et elle est nettement moins performante qu'une GTS ou une ultra.
Que ce soit en PCI, en AGP ou en PCIexpress, une carte qui envoie de la merde risque toujours de faire planter la machine.
Mais de toute façon ça n'a pas grande importance vu que la machine de test n'est pas celle de développement, et qu'elle va certainement booter sur une suite de tests, donc au plus noyau linux+2-3 programmes, donc le reboot ne sera pas très long.
[^]Re: performances
la dernière fois que j'ai testé ma mx400 ne le faisait pas
pas plus que ma mx200
on a pas dis 30 fps en 640*480, on a dis en 1280*1024 hein.
Que ce soit en PCI, en AGP ou en PCIexpress, une carte qui envoie de la merde risque toujours de faire planter la machine.
Tu sais que tu peux merder dans le code verilog du pipeline 3d mais que le code pci soit tout a fait correct.
(je me demande meme si ils ont pas utilisé 2 puces séparé pour ca : une pour la gestion du pci , et une pour le core graphique proprement dis).
donc le reboot ne sera pas très long.
Ouais c'est sur, puis faut aussi avoir une machine sur lequel tu vois ce que tu tape pour balancer la mise a jour pour mettre la rom à jour sur le bon firmware. A moins que tu veuille le faire dans un test par défaut, et dans ce cas c'est super simple tu test un truc.Ah merde faut que je reboot
Tu test un autre ... a merde a nouveau
Un troisième ... a non toujours pas.
Je suis pas sur que ton linux apprécie tant que ca les reboot hard que tu lui inflige a chaque fois que tu dois débugger une ligne.
Compte le nombre de fois que tu corrige une erreur sur un code. Et imagine si tu dois rebooter à chaque fois.
Subete ga wakatta toki…watashi ga anta wo korosu.
[^]Re: performances
pour la mx400
autant pour moi , effectivement elle les atteints :
http://www.hardware.fr/articles/329-3/nvidia-geforce2-mx-200(...)
(j'ai du confondre alors avec ma mx200)
Subete ga wakatta toki…watashi ga anta wo korosu.
[^]Re: performances
30 FPS en 640x480, ma TNT2 faisait déjà beaucoup mieux, alors une GeForce 2...
Voir : http://www.tomshardware.com/2002/04/18/vga_charts_i/page4.ht(...)
Quake 3 - 1024x768 - 32 bits :
GeForce 2 Ultra : 135.5 FPS
GF2 MX 400 32MB : 59.5 FPS
TNT 2 : 22.7 FPS
[^]Re: performances
j'ai pas dis que ma mx200 faisait 30 fps en 640*480 quand meme.
Puis quand à l'erreur je m'en suis rendu compte ;) (cf le message juste au dessus du tien ;))
(ps et c'est pas du 1024*768 qu'on demandait mais du 1280*1024 , et ma mx400 atteint 40 fps en 1280*1024 en 32 bits)
Subete ga wakatta toki…watashi ga anta wo korosu.
[^]Re: performances
la gt2 Ti fait en effet 33fps... en 1600x1200.
Quake 3 utilise un moteur qui, par les standards actuels, est complètement dépassé, je n'ose même pas imaginer les fps avec une carte récente genre 8800GTX...
En tout cas, je réitère: si l'objectif est 30fps en 1280x1024 sous quake III, c'est pas réaliste pour du cad, de l'imagerie, ... Eventuellement pour de la bureautique, et encore...
ben, non... le mieux est d'avoir une machine de développement et une machine de test, la seconde utilisant effectivement le hardware en développement, de sorte que si tu plantes la bécane complètement, tu ne perdes pas tes opérations en cours (qui elles sont sur la bécane de dev, qui est équipée d'une carte graphique stable)... Et puis, il y a un truc magnifique avec les linux et unix: même avec l'affichage planté, tu peux toujours te connecter en mode terminal, via port série, ssh, ...
[^]Re: performances
> bon, ici on ne parle pas de prototype mais d'objectif
non, on parle d'objectif du prototype:
"With our development card and the OGA1 GPU, our target is a frame rate of between 20 and 30 FPS on Quake III"
Donc mieux vaudrait éviter les jugements prématurés...
[^]Re: performances
D'abord, sur le site de la carte, la section mise en gras dans la phrase est exactement l'inverse de celle que tu as mis en gras. L'emphase étant bien mise sur le fait que l'objectif est 30fps et non le fait qu'il s'agisse d'une carte de développement. Sans doutes une erreur de communication, ou du marketing mal placé.
Enfin, si la carte de développement atteint les 30fps sous quake 3 (on y est pas encore, ce n'est qu'un objectif), on aura pas magiquement 300fps avec la carte de production, à moins de tout recommencer depuis zéro avec une architecture beaucoup plus puissante.
Donc pour le cad, la video HD, l'imagerie, le jeu, ... ça me semble un peu rapé... par contre, pour faire une carte bureautique, ou pour mettre dans des serveurs, ça devrait convenir si le prix est raisonnable. Sinon, avec une carte basée sur un chip fpga, les demomakers devraient bien s'amuser ...
[^]Re: performances
"Enfin, si la carte de développement atteint les 30fps sous quake 3 (on y est pas encore, ce n'est qu'un objectif), on aura pas magiquement 300fps avec la carte de production, à moins de tout recommencer depuis zéro avec une architecture beaucoup plus puissante."
La différence sera la fréquence d'horloge, c'est tout.
"Donc pour le cad, la video HD, l'imagerie, le jeu, ... ça me semble un peu rapé... "
Pour les jeus direct X 10, oui, pour les autres non. L'imagerie et autre effet 3D marcheront bien. Le créateur du projet connait bien les problèmes de qualité d'images, la carte aura donc une "belle" sortie analogique.
[+] [^]Re: performances
Ben non, la grosse différence sera un passage à l'asic... c'est pourtant marqué... ça fera d'office une plus grande différence q'un simple changement de fréquence.
[^]Re: performances
Evidement que c'est marqué, c'est moi qui ai écrit la news !
Et d'un point de vue design, la seul différence sera la fréquence plus haute permise. La téchnologie permet aussi de baisser la conso et le prix.
Mais d'un point de vue design logique, cela sera exactement la même chose ! Le FPGA sert de plateforme de développement, à quoi sert une plateforme de dev, si tu veux faire ensuite quelques choses de complètement différent !
[^]Re: performances
Ce serait dommage de ne pas profiter du passage à l'ASIC pour faire du tuning... Le stade fpga est une opportunité pour travailler les algorithmes, le passage à l'ASIC est l'étape où on travaille et on optimise le design hardware pour assurer l'exécution de ces algorithmes sans goulots, ça ne devrait jamais être une traduction à l'identique. C'est là qu'on peut augmenter le nombre de certaines unités, faire le tuning des caches, ... Il y a d'énormes opportunités d'optimisation dans ce processus.
[^]Re: performances
erf...
Et tu valides comment ton design, si tu ne peux pas le vérifier sur une plateforme de test !
Il est évident que les optimisations ne seront pas orienté FPGA mais asic au moins en partie.
[^]Re: performances
Tu ne peux pas tout valider sur un système fpga. En dehors de l'optimisation logique, il y a les problèmes de distribution électrique, de répartition thermique voir d'interférences sont à concevoir en dehors de l'approche fpga. En mettant en place le design logique sur fpga, les développeurs rencontreront forcément des limitations opérationnelles liés au fpga lui-même, limitations qui pourront sauter au moment du passage en asic si elles sont correctement comprises et q'un plan B est modélisé.
On ne peut pas modéliser tout via le fpga, il faut juste vivre avec celà, c'est une méthode intéressante pour approcher la logique finale, mais elle est limitée et il serait dommage de traduire de manière stricte les limitations du fpga dans le design de l'asic.
[^]Re: performances
Laisses moi deviner, tu sors de l'école c'est ça ?
Tu dis toi-même que le FPGA ne permet pas de tout modéliser, mais permet tout de même de valider le fonctionnel mais tu proposait de modifier le fonctionnel sans pouvoir faire de test.
Bref, cela ne fait pas tout mais tu voudrais en faire encore moins ?
ps:
"les problèmes de distribution électrique" -> problème du fondeur ou du designer de carte
"répartition thermique" -> idem
"d'interférences" -> que pour les cartes pour l'instant (très peu pour le gusse qui fait le layout chez le fondeur)
[^]Re: performances
et hop, vive le ton condescendant...
Tu peux valider des blocs, tu peux, si tu es structuré, avoir une approche où le nombre d'instances d'une unité modélisée change entre la version fpga de la logique et la version asic.
Le fpga est un outil de modélisation mais ne devrait pas être utilisé comme limite de complexité. On pourrait imaginer un architecture modulaire où on configure un noyau d'affichage et ou rajoute des éléments de configuration modulaires comme des overlays hardware, des shaders, des unités de streaming, ... le tout en validant les blocs un à un et en décidant de les incorporer ou non dans telle ou telle version de l'asic, ce qui permet de spécialiser telle ou telle version de la puce pour tel ou tel besoin. IBM, par exemple, utilise une approche un peu similaire pour son architecture powerpc pour le marché de l'embarqué.
Pas tout à fait d'accord... Si ton modèle est purement logique et ne tenant pas compte de l'aspect physique, ou pas assez modulaire, il sera beaucoup plus difficile pour ton fondeur pour déplacer des blocs pour rééquilibrer la dissipation thermique dans la puce.
[^]Re: performances
Le ton est peut être condescendant mais je travail depuis 5 ans dans le secteur. Et bien que tu sembles connaitre le sujet, cela manque sérieusement de pragmatisme et de réalisme.
Quand tu dois mettre 2 ou 3 m¤ sur la table, tu prends le moins de risque possible. Même si tu peux multiplier les core 3D dans la puce par rapport à la version FPGA, il y a toujours le problème des points uniques d'entrée : bus mémoire, bus IO, sortie video.
L'arbitrage de bus pose des problèmes extrèment subtile de latence et doit être complétement validé. Bref, une validation unitaire ne t'assure absolument pas une validation de l'ensemble. Il suffit d'une erreur de spec et cela arrive tout le temps.
Il n'y aura pas 50 version de l'asic, cela coute déjà très chère d'en faire une !
IBM n'utilise pas du tout cette téchnique. C'est un vendeur d'IP ou de core pour être plus précis. Comme ARM vend des coeurs de cpu arm, ibm vende des core ppc. La validation des interfaces avec le reste oblige toujours simuler (mais bon 3 jours pour 10ms, on ne va pas loin), ou encore d'avoir des accélérateurs de simu comme ceux de cadence ou encore des cartes à base de fpga.
Le fondeur peut remonter des problèmes de point chaud. Mais ogc va tapper dans les 2-3 millions de portes, cela n'est pas comparrable au 100 millions d'un SOC de téléphone portable.
[^]Re: performances
Le problème, c'est que si on est pragmatique et réaliste, on investi pas dans un marché comme les cartes graphiques, surtout pour faire un produit qui sera complètement à la ramasse face à à peu près toute la concurrence.
Qui achètera cette carte? Pour quelles raisons? A l'heure actuelle, sur le site de Traversal Tech, le prix envisagé est d'au moins 1000$ pour le prototype fpga... ça va refroidir pas mal de personnes intéressées, un tel investissement... il faudrait des garanties que la montagne ne va pas accoucher d'une souris si on veut une communauté significative sur le développement du système.
On peut donc attendre que la carte trouve d'elle-même son public (ou qu'on découvre qu'il n'y en a pas), ou alors on peut pousser la réflexion un peu plus loin et chercher un moyen de se repositionner rapidement sur le marché selon les besoins. L'approche modulaire n'est pas la solution, mais peut être un début de solution: il y a des dizaines d'idées qui pourraient venir se greffer sur la colonne vertébrale de la carte et en faire des produits uniques dont certains pourraient avoir du succès. C'est aussi ça l'avantage d'un projet ouvert sur une communauté, il viendra peut-être des idées de modules inédits, qui, s'ils ne sont pas tous intégrés dans une version généraliste de la carte, mériteront une implémentation dans une version spécialisée.
Sinon, certes ibm est une boîte IP, mais quand ils te licencient un core, tu peux/dois avoir accès à une solide consultance de leur part sur le sujet, et ils peuvent te tenir par la main (et le porte-feuille) de la pré-étude jusqu'à la production des puces dans leurs infrastructures. De ce que j'avais lu, ils ont déjà pas mal modularisé leur architecture power 5 dans cet objectif.
[^]Re: performances
"A l'heure actuelle, sur le site de Traversal Tech, le prix envisagé est d'au moins 1000$ pour le prototype fpga..."
Une carte de dev fpga équivalente peut couter jusqu'à 10 000¤ sur le marché. Cela n'a pas l'air comme ça, mais c'est en fait donné...
[^]Re: performances
certes, je veux bien te croire sur parole... mais ça met tout de même l'investissement assez haut pour le hobbyiste désireux de s'investir dans le projet.
Entre ça et acheter une carte graphique plus classique et essayer de contribuer à ses pilotes, il y a clairement un pas que justement le pragmatisme tendrait à influencer.
Et le pire, c'est effectivement cette carte est en plus sans doutes vendue à pertes (en tout cas pour le milieu académique).
Tout ça pour ça...
[^]Re: performances
Je pense qu'il y aura sans doute un simulteur de la carte mis au point grace au modèle. Cela permetra de développer du code sans le fpga.
[^]Re: performances
Concernant le marché de la puce, il y a les cartes de bureau mais aussi l'embarqué, qui peut être le plus gros marché d'ailleurs.
Concernant les nouvelles idées, cela pourra se faire avec le fpga mais difficilement avec un asic. L'idée de charger le fpga en fonction de l'application est très tentant mais la technologie reste trop chère.
La carte sera opengl 1.3 ce qui est déjà pas mal. Il y a aussi des features comme les grosses résolutions, les conversion yuv <-> rgb et quelques opérations 2D accéléré.
Les shaders et autres seront vu ensuite.
[^]Re: performances
50 peut-être pas mais entre 5 et 15 ça me semble assez courant. Je ne suis pas en expert en la matière mais ayant travaillé (côté logiciel) dans des boîtes qui faisaient du chip et qui passaient par des fpga, celà n'empêchait pas d'avoir jusqu'à 15 itérations en version fondue...
Et actuellement le chip fournit par un sous-traitant sur lequel je travaille en est à sa 10e itération (qui semble être la dernière)...
[^]Re: performances
Là ou j'ai bossé, c'était plutot bon du premier coup voire au deuxième mais pas plus.
[^]Re: performances
Ca varie peut-être en fonction de la complexité du chip? Dans les exemples que je cite je parle de chips assez gros intégrant un coeur ARM + DSP + d'autres copro + périph. divers et mixant du numérique et de l'analogique. Mais je ne suis pas un spécialiste.
[^]Re: performances
A mon avis il manque une précision :
quand vous dites 'jusqu'a 15 puces style de puce fondues' il s'agit de :
15 variations du chips , mais où (presque) chacune des variations est fonctionnelle et on peut la vendre
et
15 variations du chips où seul la dernière est fonctionelle ?
Subete ga wakatta toki…watashi ga anta wo korosu.
[^]Re: performances
Dans un des cas que j'ai cité (celui ou on faisait la puce), il n'y a pas eu de puces de vendues avant la 7e itération. Pour l'autre (on est client) je ne sais pas trop. On a eu nos premières puces en itération 6 mais on n'a pas vendu de produit avant l'iteration 9. Mais il est possible que d'autres sociétés aient vendu des produits avec d'autres itérations, je n'ai pas d'info à ce sujet.
[^]Re: performances
Sauf qu'il n'existe pas de "carte" intel et que la radeon 7500 n'est plus en vente depuis longtemps.
Certaines personnes préfairent avoir un driver complet (avec swsupend, gestion multiécran correct et extention X11) et stable, plutot que des perfs brutes.
[^]Re: performances
Je parlais évidemment des chipsets intel intégrés dans de nombreux portables.
Quant au driver complet, c'est une bonne idée, mais l'idée est d'avoir une carte qui supporte aiglx et compagnie avec des perfs décentes. Si tu veux avoir ton multiécran avec aiglx, ta carte risque de se montrer assez insuffisante. Et je ne parle pas des autres joujous 3d que l'on voudrait utiliser sans être hardcore gamer.
D'ailleurs si les perfs 2d sont du même acabit que les perfs 3d, cette carte sera également assez limitante pour les opérations de défilement, avec les zolies icônes avec preview et tout.
[^]Re: performances
Il n'y a plus qu'à avoir les premiers scores à 3DMark 200\d de la carte ;)
En attendant je me satisfait de ma vieille geforce3 avec drivers proprios (en attendant de pouvoir jouer à xmoto avec nouveau)
[^]Re: performances
Hum.... 3DMark ce n'est pas exclusivement DirectX ? (mais peu-être fais-je une erreur, je ne suis pas très au courant dans ces choses là).
Si oui on peut dès lors annoncer le score. ^^
† In te confirmátus sum ex útero : de ventre matris meæ tu es protéctor meus.
[^]Re: performances
La bande passante mémoire est 30% supérieur à une geoforce 2 donc dans les fonctionnalités simples, et notament 2D, la OGC sera dans les 30% plus rapide.
[^]Re: performances
C'est simpliste comme raisonnement, la bande passante entre la puce et la mémoire graphique n'est pas directement proportionnelle à la vitesse d'exécution de la carte.
Même en 2D il y a de nombreuses opérations qui dépendent de la vitesse de connexion au bus et de la vitesse du chip graphique (opérations blit, conversion d'espace couleur, correction des couleurs, gamma, ...)
Si la vitesse du chip graphique et la connexion au bus sont insuffisantes, la vitesse pure de la ram de la carte graphique passe sérieusement au second plan.
[^]Re: performances
arf...
Tu n'a jamais entendu parler de la limitation de bande passante par rapport aux calculs pour les cpus ?
Non, parce que un asic, c'est du cablé donc encore bien plus efficace qu'un cpu (le fpga contient 96 multiplieurs 18x18 bits...). Donc dans les opération simples (ce que j'ai bien précisé), cela sera toujours la bande passante qui sera limitante.
Pour la vitesse du bus de connection, cela ne rentre en compte que pour visionner de la video. Et encore, les limites apparaissent avec la HD. en comme dis 50x sur la page, le pci a été choisi par facilité de développement, rajouter un pont pci<->pci express ne sera pas bien difficile !
[^]Re: performances
Et toi, tu as déjà entendu parler de cpu's n'exploitant pas la bande passante à cause de la complexité des opérations?
Certes le fpga est puissant, mais pour de la 2D pure, va t'il vraiment exploser un asic dédié avec une progression directement égale à l'augmentation de la bande passante?
Si je met de la ram ddr2 800 sur mon pc en lieu et place de ddr2 400, mon pc sera t'il vraiment 2x plus rapide?
[^]Re: performances
"Et toi, tu as déjà entendu parler de cpu's n'exploitant pas la bande passante à cause de la complexité des opérations?"
Oui évidement. Il y a eu des testes à l'époque ou l'on pouvait choisir entre des bus mémoires 64 ou 128 bits. Les différences se jouait sur 10% pas plus.
Par exemple, pour un codec video, la dct bouffe 99% du temps cpu est n'est pas limité par la mémoire.
Idem pour la compression AES où il parle de 20 cycles cpu par octet.
Un algo "cpu bound" ne sera jamais limité par la mémoire... par définition.
"Certes le fpga est puissant, mais pour de la 2D pure, va t'il vraiment exploser un asic dédié avec une progression directement égale à l'augmentation de la bande passante?"
Tu veux dire quoi par là ? Qu'un FPGA est moins "rapide" que son équivalent ASIC, ce qui est évident ? Qu'un ASIC dédié est plus rapide qu'un ASIC pas dédié ?
"Si je met de la ram ddr2 800 sur mon pc en lieu et place de ddr2 400, mon pc sera t'il vraiment 2x plus rapide?"
Comme dit plus haut, cela dépend des algos...