Reprise du message précédent :
Le Larrabee c'est aussi du x86. C'est ce qui fait sa force en GPGPU sa seule utilisation faite actuellement.
 
En plus Nehalem -> Sandy Bridge, dans la version la plus grosse ça sera :
- 6 -> 8 cœurs
- 3,47GHz -> au moins 3,8GHz
- SSE -> AVX
 
En FP on devrait avoir au moins 3x plus de perf en peak... C'est pas si mal sans changer de process...

 
Le problème c'est que 3x ça va permettre tout juste diminuer le temps de rendu.
 
La je fais quelques test sous pov ray. Conseil prends la 3.7beta si tu veux aussi en faire, la 3.62 ne gère même pas le multithread.
 
Bref La je suis en train de faire glass_demo.Pov avec un Q9550, donc pas vraiment une daube. Je fais un minable 8PPS, j'en suis à 51minutes et je vois toujours rien en 512x384.
 
Tu penses que le temps réel sur CPU arrivera un jour ?  

C'est juste que Povray ne soit pas du tout optimisé.
Sachant qu'il ne vise pas le temps réel.
 
Un moteur en temps réel utilisera tout un tas d'optimisation.
 
Tu prends une simple réflexion, allé, sur un logiciel d'infographie tu vas prendre 20 itérations pour un rendu plus que correcte.
La même scène sur un moteur en temps réel te blindera à 4 itérations.
Soit 5 fois moins.
Sachant que chaque reflet est un recalcule de la scène.
 
Et encore c'est une optimisation mineure connus de tous.
 

 
bah non c est plutot ce qui fait ça faiblesse car plein d'instruction x86 qui ne servent à rien dans une vision gpgpu
 
donc un rapport nb transistor/efficacité pas terrible
 
l'intérèt du gpgpu c'est justement de faire abstraction du x86 qui est là à titre de retrocompatibilité
 
et un gpgpu travail forcément sur une plateforme qui a un cpu donc le moindre nombre de taches qui nécessite encore du x86... bah y a le cpu x86 derriere
si larabee s appuie plus sur des core x86 très simple (genre classe pentium) c'est bien pour limiter la casse en terme grosseur pour chaque core x86 qui devient dans larabee un "SPU"  
 
comme nvidia là à de nombreuse fois dit et il a pas tord... un dev il écrit pas sont soft en langage machine
on s en branle que derriere ça soit du x86, car on va pas coder en x86 brut
on utilise des outils de devs, des compilateurs, etc...

N'empêche qu'en FP32 en 32 coeur @ 2GHz c'était 2Tflops quoi...
Et l'avantage, c'est qu'en FP64 c'est que la moitié, donc 1Tflops...

y a pas de quoi être fier d avoir eu besoin de 32cores à 2Ghz pour aligner si peu de puissance brute
 
le cell dans la PS3 il fait pas 1,8Tflops depuis déjà 2ans
 
youpi intel arrive à faire.... aussi bien qu un cell vieux de 2ans    
 
c est trop fort larabeebee  

AMD fait quoi ? 2,7 Tflops en FP32 et 0,5Tflops en FP64 avec 320 coeurs ceci dit...

 
et en nb de transistor larabeebee fait combien

 
N'empeche que le Cell est moins bon qu'un vieux C2D en 64bits  

~1,75 Milliard en 45nm ~600mm²...

C'est clair, c'est la faiblesse de cette techno.

Pas vraiment l'intérêt est d'utilisé des unités fait pour le calculs parallèles et non des taches séries en boucles.

Alors non c'est pas forcé que ce soit du x86, tu prends la X-box 360, ou la PS3 c'est du power PC, donc non la on a plus du x86.

L'avantage du x86 par rapports au autres architectures, c'est quelque soit le processeur, un int serra toujours un int de la même longueur ( hors 32/64 ). Bref les normes de programmations et les standarts IEEE ne changent pas. Avec un co-processeur tel le GPU, le programmeur dois d'adapter à l'usage des grandeurs traités par le co-processeur.

Tu prends Pov-ray, tu recompiles avec un compilateur adapté ( fournis par intel ... qui compile déjà les codes cpu de 80% de la planète ), et hop ça tourne sur larabee, sans modification du code. ( bon faut quand même que ce soit fait en multithread c'est le minimum ).

Le problème de larabee est sont niveau de performance encore très très loin de ce qu'on pourrais attendre de lui, que ce soit pour du RT ou du raster.

Dans un proche avenir, on aura des GPU qui seront dis hybride et qui pourront gérer les deux mode de rendu. Comme on dis il faut savoir marcher avant de courir, et avant de vouloir sortir des moteur temps réel, il faut déjà avoir le hardware qui le supporte, Et avant cela il faut une api géré par un consortium ...

Et le RT ne dois pas être traité en GPGPU, mais en natif pour être en temps réel, pour éviter un retour inutile au CPU ...

Le GPGPU pourra accélérer le rendu software, l'avantage étant la flexibilité au niveau fonctionnalités et profondeur de rendu, et du fait qu'on est pas en temps réel le retour cpu ne pose pas vraiment de problème.

Au passage le rendu que je fais a une profondeur de 9 réflexion, et j'en suite à 29% après 2h et 19minutes. Comme quoi sans accélération on ferra jamais rien.

Au passage, quelqu'un a des infos sur l'UVD 3.0 ?
Il y a une fonctionnalité que j'aimerais bien pouvoir enfin avoir, c'est le transcoding mais high res, actuellement c'est surtout pour les smartphone car problème de qualité, pareil chez nvidia, et pareil pour celui du SB qui va arriver. Quelqu'un a des infos sur un tel projet GPGPU en dev ? ou sur un support natif via UVD 3.0 ?

Des encodeur H.264 en 1080p ça existe, mais le pb n'est pas tant la résolution que le profil supporté.
(je suis persouadé que celui de sandy bridge supporte n'importe quelle resolution, mais qu'il parle d'iPad parce que c'est le cas typique transcoder un bluray/ep d'iTunes => appareil mobile)
 
A priori actuellement les puces de base sont en Main Profile et seul les gros encodeur pro font du High Profile (et ne consomment pas que 5W )...
 
Broadcom/Imagination & autre font des encodeur H.264 faudrait trouvé les datasheet et voir ce que ça supporte en détail.
 
Le gros point fort d'Intel c'est que le moteur video est un bloc à part du GPU et du CPU, i.e. les Atom 32nm l'auront et même si leur IGP n'a que 3 UE, les perfs video seront au top, ION definitivement mort.
 
Après faudra voir qui s'en sert, la qualité et ce qu'on pourra faire avec.
A mon avis, ATI n'ira pas dans ce sens de suit car c'est un peu un truc surprise et surtout que sauf pour les APU c'est pas trop utile comparé a un soft qui utiliserai ATI Stream.

Des encodeurs H.264 en GPGPU ?
 
J'ai pas encore vu ça ...
 
Après en UVD 3.0 ou en OpenCL, je m'en tape, je veux juste que ça prenne pas une plombe pour faire du high res en multipass. Ben oui une pass c'est ridicule.

 
Badaboom 1.2 en Mainprofile + Cabac, ha on me dit que c'est du CUDA...

Bah Badaboom c'est quoi ? Un encodeur H.264 en CUDA Y'a aussi PowerVideo qui utilise CUDA pour PowerDirector.

Je pense qu'il expliquait le pourquoi du "très simple" et non sur l'utilisation forcée du x86.
 

Moi j'aurais plutôt pensé que c'était le compilateur Microsoft qui était le plus utilisé. Ceci dit, même sur processeur AMD, l'ICC se révèle plus performant donc tant mieux.
 
D'autre part, je ne suis pas sûr qu'une simple recompilation permette de faire fonctionner un logiciel sur Larrabee. Et même si ça "tourne", je parierais que les perfs seraient catastrophiques (= plus lent que sur CPU). Dans les faits il faudra de toute façon passer par LRBni (Larrabee new instructions) ou par une librairie qui va les utiliser efficacement. D'un point de vue développeur, sera-ce vraiment plus simple que CUDA ou OpenCL ? C'est même pas sûr.

 
attention aux limitations bien visibles, comme par exemple stream et Espresso 6 ou cuda et TMPGEnc.
 
il y a encodage et encodage    
 
 
 

 
Ouai mais la limitation est logiciel.
Ce n'est pas forcément à imputer au langage.
 
Un Badaboom avec un H.264/AVC High Profile pourrait le faire grandement.
 
Déjà en passant de badaboom 1.0 à 1.1 à 1.2 on à eu droit respectivement à l'évolution "BaseLine" => "Main profile" => "Main profile + CABAC" et de "720P" => "1080p" => "1080P".
Peut-être pour la 1.3

quid d'un logiciel AMD/ATI qui fait pareil avec une qualité égale à celle d'un encodage CPU !

En allant cherche mon Z-5500 chez Matériel.net j'ai posé la question concernant la gamme HD6***
Il ma dit pour le moment à part les posts et les messages sur le net il y a aucun date de sortie et plus

En fait c'est plus simple que cela. Un compilateur modifié détecte les itérations des fonctions parallèles et change le code source par un appel au librairies larabee. Sachant que les instructions sont les mêmes sur larabee que sur la FPU d'un CPU ( et que c'est principalement la le meilleurs endroit pour accélérer le rendu et que larabee supporte déjà AVX de façon même plus large que SB ) en fait la transformation par le compilateur est relativement simple et tout à fait envisageable pour ce genre de chose. Bien entendu le reste du calcul serra fait par CPU, et les branchements, ce qui me semble logique vu que c'est sa spécialité.

Je pense que c'est une solution facile et tout à fait envisageable surtout pour un acteur comme intel.

Oui tu peux gruger avec les drivers AMD, et faire tourner ça même sur une x1900, mais la qualité est la même que sur celle de Badaboom, c'est à dire proche du smartphone. Et que je sache badaboom ne supporte pas le multipass.

Donc de toute façon c'est pas une solution envisageable. D'ailleurs le x264 est un codec intéressant d'un point de vue performance, mais il a ses limites, au niveau licence.

Faut pas s'attendre à la moindre info jusqu'au 12 octobre même par eux.

Perso je connais des gens qui pourront me fournir avant le lancement, peut être pas avant la fin du NDA, j'en doute fortement, mais peut être 1-2 semaine avant le lancement officiel.

Avoir bosé dans une boite IT ça a ses petits avantages

 
Ah sympa tout ceci    
Espérons que le prix sera pas trop abusé pour la carte ultime

Aucune limite, dans l'UE y'a aucun brevet sur l'H.264...
 
De toutes façons pour les MP3 LAME est le meilleur encodeur du monde, il est totalement illégal, et on s'en sert quand même massivement...

Je ne sais pas pour les brevets, mais l'H.264 appartiens au groupe MPEG.

Oula, c'est plus complexe que ça, le MPEG c'est qu'un consortium qui developpe les technos, après la MPEG-LA pour les licences d'utilisation des brevets.
 
Le truc c'est que comme les brevets logiciels n'existent pas en UE, y'a pas de licence à avoir en UE.
 
Quoiqu'il arrive, x264 comme LAME ne sont pas illegaux, car la licence tu peut la payer et utiliser ces binaires.
 
D'autre par, je ne suis même pas sur qu'on ai besoin de payer une licence pour une utilisation non-commerciale @ home de LAME/x264.  

Le problème reste que niveau choix de l'encodeur c'est limité, et à l'heure actuelle aucun ne bénéficie d'une réelle accélération GPGPU.
 
Et franchement si la 6xxx est équipé d'une solution même propriétaire à AMD, et qui réduit sérieusement les temps d'encodages en multipass peut importe le format, ça va faire un tabac.

Non mais c'est normal, c'est pas avec du FP32 qu'on ira loin. Pour moi c'est le principal obstacle hein, qu'en FP64 les perfs soient bidon et qu'en FP32 y'ai trop d'arrondi pour combattre un encodeur qualitativement supérieur.

 
Perso, j'espère que c'est un gros fake des familles mais ça en a tout l'air ...

Bha en gros ils font une 5850 quoi.

De fortes chances, et encore au minimum ... La GTX 460 une fois OC s'en rapproche fortement donc, le mieux selon moi serait d'avoir une carte s'approchant de la HD 5870, pour 200€ ce serait top !

D'un coté, le slide dit qu'elle est au niveau d'une 5870...
(enfin au niveau fillrate/tmu )

ouaip, si c'est ça je vois pas du tout l'intêret étant donné qu'il l'ont déjà la concurrente de la 460.
Même si je suis pas pour le concept, autant renommé une carte existante pour ce concentrer sur le HDG plutôt que de pondre une carte avec des perfs qu'on a déjà et qui n'apportera pas grand chose (c'est pas comme si on était au passage dx10 => dx11 comme la HD4870 => HD5770 avec perf équivalente)

HD 5770 =  800 ALUs, 40 TMUs, 16 ROPs, 850 MHz / 4800 MHz, =108W TDP --> 1360 GFLOPS  
BART Pro =  800 ALUs, 40 TMUs, 32 ROPs, 725 MHz / 4000 MHz, <150W TDP --> 1160 GFLOPS  
BART XP  =  960 ALUs, 48 TMUs, 32 ROPs, 850 MHz / 4200 MHz, >150W TDP --> 1632 GFLOPS  
HD 5850 = 1440 ALUs, 72 TMUs, 32 ROPs, 725 MHz / 4000 MHz, =151W TDP --> 2088 GFLOPS  
HD 5870 = 1600 ALUs, 80 TMUs, 32 ROPs, 850 MHz / 4800 MHz, =188W TDP --> 2720 GFLOPS  
 
La GTX 460 OC obtient des perfs équivalente à la HD 5850, et en DX11 elle est au coude-à-coude avec la HD 5870.  
 
Ce qui est clair, c'est que d'après ses specs, le BART XP pourrait bien égaler une HD 5850.  
Pas en puissance de calcul pur (sauf optimisation IPC), mais sûrement en vitesse de rendu.

Sauf qu'on ne sait pas les nouveauté architecturales.  
De plus je pense qu'une HD 6770 aura mini 2x les perfs geometrique d'une 5870, plus l'UVD 3.0 (très important de se positionner sur la 3D alors que les GTX4xx sont déjà compatible), ça a au moins un sens commercial.

Sauf que les 960 nouvelles ALU sont plus équivalentes a 1200 anciennes ALU dans leur concept.

ça n'engage que moi mais peu importe les nouveautés architecturale, les différences en pratique ne seront surement pas bien grande ...

Vu le quasi slideshow qu'on se paye dans Lost Planet 2 avec la tesselation à fond, ça pourrai quand même tout changer... )

ouais sauf que c'est toujours pareil, on prends un exemple et on en fait une généralité ...

si encore lost planet 2 avait un quelconque interet ludique

C'est semblerais t-il la meilleur rumeur en cour, mais rien de très officiel.

Sinon à mon avis ce slide pue le fake.