Reprise du message précédent :

Le NVIO sert surtout à réduire le nombre de transistors du GPU. Là tu l'as même pas évoqué à propos du HUB.  

Mon avis repose sur le texte du brevet.
Je ne dis que ce qui est écrit.
 
Pour ton histoire de taille du hub j'ai un début de réponse, basée sur rien du tout: Et si le GT300 n'avait pas de ROPs ? Si en fait les ROPs étaient déporté dans le hub, avec un accès direct à la mémoire. Un peu comme dans le RV770 où les ROPs sont liés aux contrôleur mémoire, et totalement indépendant des SP et des TMUs. Les ROPs pourrait donc avoir leur propre fréquence, indépendante du GPU. Quelle serait la taille d'un hub contenant un minimum de 32 ROPs ?
 
 

Bon les gars:
si vous arrêtiez de vous prendre la tête avec vos machins et attendiez tout simplement comme tout le monde que les dit gpu sortent, ou allez postuler chez les fabriquants. Chai pas moi, on est Samedi soir, sortez de chez vous et aller picoler dans un bar.......

Va dire ça aux 2000 connectés sur HFR en ce moment.

darkorel, vu le niveau de tes interventions dans ce topic, je penses que tout le monde attend que tu y ailles en 1er.

 
Ma femme en a marre que je sorte picoler, alors je traîne ici pour passer le temps

Tu picoles du HFR  maintenant quoi  
Santé

Wirmish>
 
Et moi une réponse: et si les ROPs ne prenaient quasiment aucune place?
 
Si nVidia tente l'approche "CPU" avec un truc monstrueux, il faudra en plus une interface mémoire monstrueuse, bref, 2 puces distinctes chères à produire.
 
Déporter les ROPs de la version GPU apporterait quoi? La possibilité de ne pas les intégrer à la version Tesla? Mais il faudrait quand même une interface mémoire, et avec un débit non négligeable... bref, encore un investissement supplémentaire pour enlever 3 bricoles à une puce secondaire, ces 3 bricoles étant au passage bien moins volumineuses que les TMU, qui resteraient bien entendu dans la puce?
 
A l'extrême limite on pourrait penser à l'utilisation d'un process plus ancien et moins coûteux pour la réalisation de l'interface mémoire, mais là encore je ne suis pas convaincu de gains financiers notables car ledit die serait encore sensiblement plus gros qu'un NVIO et d'une taille avoisinant celle du G92, donc un prix pas si maîtrisé que ça.

Il serait pas plus avantageux pour eux d'utiliser de la DDR5 ?

Si leur GPU est énorme, la GDDR3 peut encore être suffisante, par contre elle sera chère...
 
La GDDR3 0.8ns utilisée sur les GTX285 et dont la fréquence interne est de 1250MHz est très certainement plus chère que la GDDR5 1ns des 4870/4890 dont la fréquence interne est de seulement 450MHz.

 
L'Hydra de Lucid est une assistance qui doive être prise en compte par les drivers.
Coupler 2 cartes graphiques de marques différentes, surtout de manière transparente (sans API normalisée pour), ça n'a jamais été avancé par Lucid, c'est de la mythomanie techno-magique initialement imaginée par les forumeurs.
 
Un des buts de l'Hydra est de, par exemple, faire du multicast:
Par exemple, en temps normal (en SLI/CF), tu as une texture a uploader vers deux cartes, donc deux transferts DMA (donc double pression sur la mémoire système, pour rien).
Avec l'Hydra, tu fais un transfert DMA et le chip procède à l'upload parallèle de la texture vers chaque GPU.
Pour que ce soit cohérent il faut que le driver prenne en compte le chip Hydra.
A aucun moment un ASIC incrusté sur un chemin de communication ne pourra avoir la visualisation de l'état des ressources d'un GPU que peut avoir un driver. Par contre tu peux toujours imaginer des ASICs d'assistance qui cherchent a résoudre des problématiques plus ou moins universelles.
 

Pour résumer, c'est... une couche d'abstraction.
 
Au lieu de communiquer avec les GPU, on communique avec l'hydre qui se charge de transposer les requètes, ceci dit je me demande si ça nécessite réellement une puce...
 
Y'a pas de possibilité d'intégrer un système multi-clients directement via le PCI-Express?

A priori non, pas à ma connaissance.
 
Pour moi, Hydra est plutôt un switch PCIe suffisamment programmable (on peut imaginer un petit CPU risc avec de la ram, dont le code est fourni par le driver vidéo) qui permet de faire du multicast, transfert GPU à GPU de données spécifiques sans repasser par le northbridge+CPU+ram système, etc...
 
Non seulement c'est peut-être plus efficace que via l'approche classique, mais en plus un chipset moyenne gamme+Hydra pourrait torcher un chipset haut de gamme seul en performances. A mon avis le point clé est là.

Attention, je dis que la technique "DDaBTR" permet d'accoupler 2 cartes graphique de marque différente, mais je sais très bien que nVidia refusera que ses cartes fonctionnent en tandem avec une Radeon. Mais là ce n'est plus un problème de drivers ou de hardware mais bien un "problème" de marketing.
 
Imaginons un instant que nVidia n'ait pas de problème à partager ses GeForce avec des Radeons, et vice-versa.
 
Une compagnie X écrit un driver spécial qui tourne sur un core peu sollicité, disons le 4e core d'un C2Q ou d'un Phenom II.
Un jeu Y veut afficher une scène et envoit ses données au driver de Windows qui a son tour les redirige vers le driver DDaBTR.
 
Le driver DDaBTR sait qu'il y a 2 GPU d'installés dans l'ordinateur: une Radeon HD 4890, et une GeForce 8800 GT.
Il connaît aussi le nombre de SP/TMUs/ROPs de chaque cartes grâce à une table mise à jour à chaque update du driver.
Grâce à ces infos, le driver DDaBTR peut donc diviser la tâche de rendu équitablement entre les 2 cartes.
Il sépare donc les données en 2 groupes qu'il envoit ensuite aux drivers de la GeForce et de la Radeon.
Chaque carte effectue alors sa part de rendu, soit ~40% de la scène pour la 8800 GT, et le reste pour la HD 4890.
Pour finir, le driver DDaBTR récupère le contenu de la carte qui n'est pas branchée au moniteur et l'envoit dans le FB de l'autre.
Reste plus qu'à envoyer la scène complète au moniteur et de passer à la suivante.
 
Je répète que le concept pourrait fonctionner... si et ssi nVidia et AMD veulent que ça fonctionne.

Vive les instabilités en passant par autant de drivers logiciels

Mes posts sont à peu pret aussi constructifs que les votres, si vous voulez aller donner des cours aux concepteurs de puces allez y.Bon aller, au dodo......

Si les rumeurs sont fondées sur le bus de 512 c'est sûr que de la DDR3 sera suffisante.
Pour le prix, à mon avis nVidia s'en fou vu le prix qu'il fait facturer à ses monstres  

Non à mon avis ce n'est pas sur que sa suffira

je crois que l'histoire bus/mémoire est similaire à la dépendance cpu/gpu dans un cadre plus large, je m'explique : le GT300 sera à priori un gpu extrêmement puissant, et pour accompagner un gpu aussi puissant, il ne faut surtout pas une limitation de bande passante, cela réduirait à néant tout l'intérêt d'une telle puce, il faut donc une énorme bande passante, créée par l'ensemble de l'utilisation d'un large bus de 512 bits et de mémoire rapide style GDDR5. C'est comme utiliser une carte graphique monstrueuse avec un cpu ridicule, ca n'a pas de sens, il faut une conception homogène. Après, je ne m'y connais pas autant que tout les autres sur ce topique, alors il y a surement de quoi discuter concernant mes arguements, comme quoi c'est bien plus compliqué bla bla, mais l'idée est là.

Clair que le GT300 sera en GDDR5, espèront le !  
 
Bref moi j'attend avec impatience la bestiole Envi de testé

 
Faudrait se pencher sur le protocole du PCI-Express en fait pour en avoir le coeur net...
 
D'un autre côté ce type de "sur-protocole" existe bien sur le SATA, donc rien ne l'empêche techniquement.

 
Arrête la picole, même si on rigole
 
Bon pas complètement en fait, on peut effectivement imaginer un driver virtuel qui permette de répartir la charge entre deux cartes de même niveau de fonctionnalité.
Mais le rendement serait à relativement inférieur à une solution in-house aux fabricants, car les drivers ont plus de cartes en main pour avoir une meilleure efficacité.
 
Après le fait que ça marche peut toujours être utile, autre que le coté perfs, par un seul contexte D3D pour le dwm du bureau pour afficher sur plusieurs cartes avec un driver différent, mais bon...
 
Mais je conchie l'idée que "Les fabricants c'est des glandeur verrouillant leur marché bouh les vilains".
 
D'un point de vue ingénierie, déjà que c'est chaud d'optimiser le balancement de charge entre plusieurs GPU dont on connait les coins et recoins,  alors entre deux GPU dont l'implémentation différe largement malgré des features équivalentes, mais alors l'idée que 5 gars dans un garage puisse apprendre leur taf aux centaines d'ingés d'Intel/nVidia/AMD.... (Bon sauf si ils changent totalement d'approche peut-être )

 
Je pense que Hydra, fait un peu comme un switch managable qui a des fonctionnalitées de routeur, en gros si tu le driver vidéo peut y mettre du code custom, tu peux avoir une gestion partielle de la machine à état des GPU mis en SLI/CF. (En gros une partie des I/O de contrôle autour des transferts de ressources qui est initialement faite par le driver, peut être déportée vers Hydra pour maximiser l'efficacité de la chose et la possibilité d'enchainer des opérations DMA entre GPUs ou ram système sans interaction du CPU/Driver).
 
On peut imaginer que dans le futur, on se retrouve avec un petit core x86 ou PPC normalisé par le PCI-SIG dans certains contrôleurs PCIe pour faire de l'assistance pour certains type de charge. Et du style le chipset moyenne gamme aura un core d'assistance, le haut de gamme deux, etc....

hydra c est un buz "startup" pour avoir du fric sans garantie de resultat à ceux qui fournissent le fric
 
j aime autant te dire que le fric ils vont jamais le revoir
 
 
c est un peu comme ageia
nvidia l'a racheté pour sa bibliotheque d instruction physique et pas pour sa puce physx
 
bibliothèque d instruction qui était déjà dans pas mal de jeu (genre test drive unlimited ou frontlines fuel of war pour ne citer qu eux)

Intel compte parmis les plus gros investisseurs de Lucid.
Et je ne crois pas qu'ils sont tous stupides chez Intel... enfin, pas tous.

Ils sont pas stupides, ils sont calculateurs...
 
Même si Lucid coule ils pourront acheter les parts restantes facilement et imposer des droits de licence sur leurs brevets.

Ils sont lucid quoi ...
 
 
 

 
Au début c'est ce que je pensais, mais étant donné que leur approche a un sens, c'est appelé a être plus ou moins standardisé d'une manière ou d'une autre.

Faut dire qu'au début ils étaient resté tellement flou qu'il était difficile d'imaginer la chose...

justement c'est le "d'une autre" qui m inquiète
 
ça va finir en des trucs propriétaire
 
ça donne plus une impression de "bon on vous donne des thunes mais faut faire que du truc parallele  
"
 
limite si les fabricants donnaient pas des primes aux devs qui font des prog/jeux vraiment programmé "parralele"
 
quoi que ça serait pas bete
 
y a bien des "primes" à ceux qui trouve des failles lors de je sais plus qu'elle reunion/salon sur la securité
(genre partir avec un macbook pro tout neuf si vous trouvez une faille à l os)

http://www.diskusjon.no/index.php? [...] 26&st=3620
 
Il y a un [soit-disant] bêta testeur pour nV qui clame que le GT300 est fonctionnel dans les labos de nV, avec des fréquences de 700/1600/2100.  
Il s'appuie aussi sur la news de hardwre-infos (une manière de ne pas outrepasser le NDA ?).
 
Il dit aussi qu'il s'attend à recevoir un exemplaire cet été, pour une commercialsitation en Octobre/Novembre, avec une architecture très différente.
 
Voilà, mytho ou pas on verra bien...

le GT300 serait en GDDR3 du coup?

LOL xo

2100 ça ne ressemble pas à une fréquence GDDR5...
 
C'est un mytho ce type...

2100 mhz  gddr 5 mytho ? Tout à fait réaliste. On devrait retrouver ce genre de fréquences sur le rv870 et en finir avec la vieille gddr5 quimonda @1800mhz.
 
Toute façon ça peut pas être 2100mhz gddr 3

C'est pas 3600 la GDDR5 pour 900 réels?  
 
Et 2100 donnerait 1050 GDDR3
 
Donc si c'est de la GDDR5 ils aurait du dire 4200 ou 1050 réels
 
Enfin si maintenant en plus ils mélangent tout ça va être gentil pour comparer...

3600 pour gddr5 campi (pour 4870)
 
quad data  900*4
 
donc 2100mhz ça ferait du 8400mhz effectif   soucie la.  

Oui merci j'ai corrigé
 
J'avais compris comme toi moi

Oui enfin, c'est évident. 1050 mhz gddr 3 sur du 512bits ça donne une bp plus faible que maintenant. Alors à moins qu'ils optent pour un bus 1024 bits, ou que le but d'une nouvelle gen soit d'obtenir des perfs inférieures à l'ancienne, c'est forcément 2100 mhz = 4200mhz gddr5, si tu préfères

+1
GDDR5 obligé, sinon ça n'a aucun sens d'avoir moins de BP que les GTX285 dont certaines prennent 2800+

Oui je pense comme vous
 
C'est pour ça que le 2100 m'a choqué