A l'occasion du SC11 (Supercomputing 2011), Nvidia présente la plateforme Maximus qui permet de combiner une carte Quadro, orientée graphisme professionnel, et ...
Lire la suite ...

Encore faudrait il que Nvidia ait un naming homogène!
Quadro est plutôt un nom marketing pour designer les cartes "entreprise", comprenant auparavant les séries FX (3D) et NVS (2D/multi-display), et d'autres encore plus spécifiques (CX et VX). Maintenant, les Quadro sans suffixe dont il est question ici sont elles toutes le top en 3D? A voir la liste sur wikipedia
http://en.wikipedia.org/wiki/Quadro
on peut sérieusement douter de la "Quadro 400", avec son bus mémoire 64bits, et même si les drivers "pro" sont fournis!

Elles sont au top de la gamme en terme de fonctionnalités et de performances pratiques dans les logiciels bridés sur les autres cartes, mais bien entendu pas les plus performantes dans l'absolu.

regrette l'epoque où on pouvait flasher une geforce en quadro

Si on met une ATI en affichage principal et une Tesla en calculateur, ça marche aussi ?
=>[]

Ce genre de cartes sont elles performantes en jeux ou c'est que pour le logiciel spéciaux ?

Je ne comprends pas trop la nouveauté, j'ai 1 Quadro et 2 Tesla dans mon PC et ça marche très bien :  
 
http://jfdeg256.free.fr/tesla.JPG
 

Avec quels pilotes ?

une qaudro et deux tesla fonctionnent sans probleme , mais je pense que tu configure le truc pour que tes calculs soient gérés en tesla, et ton affichage en quadro. A aucun moment tes tesla ne servent à améliorer l'affichage, et la quadro à calculer.

@ulukai08: il est cool ton PC. Quel système d'exploitation utilises-tu ? Et quelle application développes-tu avec une telle configuration ? Un code multi-GPU en CUDA ?

 
282.quelquechose, je regarderai demain. Mais c'est le même driver pour les Tesla et pour la Quadro.  
 

 
Oui et non. Mes 2 écrans sont évidement connectés sur la Quadro. Quand je lance un calcul je choisis le device sur lequel je veux que ça tourne, je peux choisir la Quadro, ça marche très bien. J'avais aussi fait un essai en connectant directement la Tesla sur l'écran. Ca marche aussi. Je peux toujours calculer sur n'importe quelle carte mais sur les benchs faisant intervenir OpenGL, l'affichage est beaucoup plus lent (le test simpleGL par exemple). L'affichage est aussi généralement moins fluide sur la Tesla mais largement suffisant pour quelqu'un qui ne fait pas de 3D.  
 
C'est pour ça que je comprends pas trop la nouveauté dans ce Maximus.

 
282.quelquechose, je regarderai demain. Mais c'est le même driver pour les Tesla et pour la Quadro.  
 

 
Oui et non. Mes 2 écrans sont évidement connectés sur la Quadro. Quand je lance un calcul je choisis le device sur lequel je veux que ça tourne, je peux choisir la Quadro, ça marche très bien. J'avais aussi fait un essai en connectant directement la Tesla sur l'écran. Ca marche aussi. Je peux toujours calculer sur n'importe quelle carte mais sur les benchs faisant intervenir OpenGL, l'affichage est beaucoup plus lent (le test simpleGL par exemple). L'affichage est aussi généralement moins fluide sur la Tesla mais largement suffisant pour quelqu'un qui ne fait pas de 3D.  
 
C'est pour ça que je comprends pas trop la nouveauté dans ce Maximus.

Après avoir regardé plus en détails, je pense que ce nouveau système permet simplement de répartir "intelligemment" les tâches 3D et calcul sur les cartes de façon autonomes dans les logiciels de CAO/calcul.  
 
Pour les personnes faisant leur propres programmes, cela ne change apparemment rien.

Il s'agit ici de combiner la puissance de calcul de la Quadro et de la Tesla, pas de pouvoir choisir l'une ou l'autre comme vous pouvez déjà le faire, il me semble.

Selon Nvidia le but est de pouvoir combiner les deux cartes dans un même système en conservant leurs spécificités et de disposer de profils pour rediriger automatiquement les tâches computer vers la carte Tesla. Mais il ne s'agit pas de combiner la puissance de calcul des 2 cartes bien que cela reste possible manuellement.
 
Maximus étant en projet depuis quelques mois déjà il est possible qu'un support beta soit déjà présent dans les pilotes de la branche 280.

Dans ce cas le gain en changeant de quadro sur le second graph de la news vient d'ou?

De la partie graphique en principe d'après ce que dit Nvidia au sujet de Maximus, mais cela semble effectivement peu probable pour cet exemple.

Sous Windows il existe deux types de drivers pour les cartes Tesla et Quadro: WDDM (Windows Display Driver Model) et TCC (Tesla Compute Cluster). Le WDDM est utilisé pour l'affichage. Ceci dit, il impose de fortes restrictions sur l'utilisation des GPUs qui posent problèmes pour le calcul (par exemple, Windows coupera le calcul si le GPU ne rend pas d'image pendant une certaine période, les latences seront plus élevées, etc). Le mode TCC est plus efficace pour les tâches de calcul. Maximus vient avec un driver unifié qui permet de faire fonctionner les deux modes efficacement (un GPU WDDM et un TCC). Une application qui ferait de l'affichage (un rendu avancé) + du calcul de simulation (de fluides par exemple) pourrait tirer avantage d'un GPU d'affichage et d'un GPU de calcul. Si le temps de rendu est supérieur au temps de calcul (et de transfert), augmenter la puissance du GPU de rendu pourra apporter de la puissance supplémentaire (d'où le résultat avec iray -- même si je ne sais pas précisément quelle partie du calcul est déportée sur la Tesla).

Désolé, je n'avais pas vu ton post. Application défense, traitement du signal, je te laisse deviner pour quels systèmes Je suis sous linux debian, et oui pour le moment CUDA multi GPU, le multi-GPU n'est pas très subtile, je divise mes données en 2 en j'envoi chaque moitié sur un GPU. J'envisage de passer sur OcL mais il faut voir la perte de temps en programmation pour les gains en portabilité.  
 
 

280.13, il faudra que je les mette à jour !
 
 

C'est peu probable en effet !

Nous n'avons pas tout ça sous linux. Ca m'a l'air bien compliqué !

@ulukai08: Il n'y a effectivement pas les mêmes difficultés avec Linux . Le driver "stable" pour CUDA est le 270.41.19 (sous Linux) et le "unstable" est le 285.05.15 (mais il faut être Reg. Developer).

@ulukai08: avec un code OpenCL sur une Tesla C2050, ça fait mal au coeur (et à la productivité) de ne pas pouvoir utiliser cuda-gdb et cuda-memcheck...

 
Oui, mais je voudrais voir les perfs sur une ATI et voir aussi si le code OpenCl tourne mieux sur CPU multicoeur que mon code OpemMP. D'ailleurs je me demande si je peux en rajouter une Radeon sur le dernier port PCIe.
 
Je suis reg developper, j'avais dû les prendre il y a quelque temps lors que c'était les derniers. Pas de soucis à signaler avec.

@ulukai08: Ce n'est pas forcément à prendre comme une vérité générale, mais les rares développeurs que je connais qui ont tenté OpenCL contre OpenMP sur CPU n'ont pas été ravi du résultat. Autrement, sans entrer dans les détails de ton application, tu dois probablement utiliser des FFT pour faire du traitement du signal, non ? Si oui, CUFFT ou un code maison ?

cufft mais pour OcL ça devra être un code maison. Et je pense que je serai loin d'atteindre les perfs de cufft ou de FFTw.
 

@ulukai08: C'est bien de viser haut. Je me demande s'il est même possible d'avoir une implémentation OpenCL du même algorithme de la FFT aussi performante que notre version CUDA. Il est fort possible que le code utilise des "intrinsics" CUDA et du PTX inliné. Il y a bien quelques années, V. Volkov (un chercheur américain) avait développé une version de la DGEMM plus efficace que CUBLAS. Ceci dit, il l'avait fait en CUDA.

 
 
Oui d'ailleurs je crois que la version de CUBLAS actuelle utilise son code. Étant donné les perfs de CUFFT par rapport à FFTw, même si OpenCL n'arrive qu'à 40 % des perfs de CUFFT, ça sera déjà largement suffisant.  
 
Une recherche rapide montre que ça existe déjà :  
 
http://www.bealto.com/gpu-fft_benchmarks-1.html
 
Mais quand je vois les codes OpenCL ça me rebute un peu