Toshiba : un coprocesseur multimédia basé sur Cell

Lamtd a écrit:
Le fonctionnement de base est le même, mais pour les détails il faudrait demander à Almalexia

Je connais surtout le H264, moins le MPEG2, mais normalement c'est le même principe au niveau des macro-blocs (codage spatial/temporel).

---

louloumimil a écrit:
ils ont le meritent de faire un gpu multimedia qui consomment pas plus de 100W contrairement aux dernieres 8600

Une 7600GS consomme entre 20 et 30W, une CG sans alim externe (c'est le cas des 8600 GT il me semble) consomme moins de 75W.

---

Lamtd a écrit:
si on avait su on aurait utilisé du 60fps à la place ! :paf:

D'ailleurs aux USA c'est du 60Hz, mais à l'origine le 50/60Hz vient de la fréquence du courant utilisé il me semble (220V/50Hz en Europe, 110V/60Hz aux US)

Almalexia a écrit:
Je connais surtout le H264, moins le MPEG2, mais normalement c'est le même principe au niveau des macro-blocs (codage spatial/temporel).

Bon bah finalement on est pas plus avancé alors :paf:

Mais effectivement, y'a pas de raison que ça ne fonctionne pas sur le même principe. :)

---

Almalexia a écrit:
D'ailleurs aux USA c'est du 60Hz, mais à l'origine le 50/60Hz vient de la fréquence du courant utilisé il me semble (220V/50Hz en Europe, 110V/60Hz aux US)

Il te semble bien ;)

Almalexia a écrit:

Lamtd a écrit:
Le fonctionnement de base est le même, mais pour les détails il faudrait demander à Almalexia

Je connais surtout le H264, moins le MPEG2, mais normalement c'est le même principe au niveau des macro-blocs (codage spatial/temporel).

Le peu que j'ai regardé sur le MPEG2 a l'air de très bien se pipeliner (dans cag.csail.mit.edu... , c'est la figure 6, au niveau de la section 5 ). D'ailleurs, ça tombe bien, je suis censé trouvé un bon ordonnancement du décodage du MPEG-2 sur le Cell :ane:

Ce que je trouve "génial" dans l'histoire c'est qu'il me semble que Toshiba supporte plutôt le HD-DVD (qui équipe la Xbox360 accessoirement) et que le Cell équipe pour le moment la PS3 (qui supporte le BluRay)... c'est marrant ces histoires de pognons et d'alliances partagées quand même, comme quoi ;-)

d9pouces a écrit:
Le peu que j'ai regardé sur le MPEG2 a l'air de très bien se pipeliner (dans cag.csail.mit.edu... , c'est la figure 6, au niveau de la section 5 ). D'ailleurs, ça tombe bien, je suis censé trouvé un bon ordonnancement du décodage du MPEG-2 sur le Cell :ane:

Ouais, oki, c'est pas faux :paf: mais au niveau des perfs ça va pas faire une énorme différence quand même, surtout par rapport à la méthode de scheduling proposée pour le H.264 ? Y'a pas un des coeurs qui risque de se tourner les pouces pendant que l'autre trimme ? Et ça veut dire qu'au maximum tu ne peux tirer parti que de 2 coeurs ?

bin non, justement, si tu pipelines, tu peux exploiter tous les coeurs (sous réserve que la bande passante interne soit suffisante, et c'est justement le défaut du Cell)
Si tu prends la figure 6, tu vas par exemple faire les étapes VLD et splitter sur un coeur, Zig-Zag -> Saturation sur un autre coeur, motion vector et repeat sur un autre, les 3 motion compensation sur 3 coeurs différents...
au début seul le premier coeur va travailler, mais après ils vont tous bosser (c'est l'idée même de l'ordonnancement en régime permanent, qui permet de trouver souvent plus facilement des ordonnancements asymptotiquement optimaux)

Oki, j'avais pas pensé à décomposer ça comme ça, je voyais VLD -> joiner / splitter -> output to player, mais effectivement ça n'a aucun intérêt :paf:

Enfin le principe reste le même, bien qu'effectivement le fait de pouvoir répartir les 3 composantes sur 3 coeurs différents ça permet de mieux mettre à profit les coeurs disponibles. Donc à priori c'est valable aussi pour le H.264, cela dit, où est-ce que le plus gros du travail se fait ? Parce que si c'est le zig zag -> saturation qui prend 90% du temps, dans ce cas ta technique est plutôt inefficace, et il vaut mieux envisager une répartition au niveau des macroblocks... mais c'est tout de suite plus compliqué :/

EDIT: J'avoue j'ai pas lu le document en entier (pas trop le temps non plus de me plonger là dedans pendant les heures de boulot, même si c'est intéressant :paf:), si le sujet est abordé dedans je m'en excuse d'avance. :)
Edité le 25/09/2007 à 19:10

Lamtd a écrit:
Oki, j'avais pas pensé à décomposer ça comme ça, je voyais VLD -> joiner / splitter -> output to player, mais effectivement ça n'a aucun intérêt :paf:

Enfin le principe reste le même, bien qu'effectivement le fait de pouvoir répartir les 3 composantes sur 3 coeurs différents ça permet de mieux mettre à profit les coeurs disponibles. Donc à priori c'est valable aussi pour le H.264, cela dit, où est-ce que le plus gros du travail se fait ? Parce que si c'est le zig zag -> saturation qui prend 90% du temps, dans ce cas ta technique est plutôt inefficace, et il vaut mieux envisager une répartition au niveau des macroblocks... mais c'est tout de suite plus compliqué :/

EDIT: J'avoue j'ai pas lu le document en entier (pas trop le temps non plus de me plonger là dedans pendant les heures de boulot, même si c'est intéressant :paf:), si le sujet est abordé dedans je m'en excuse d'avance. :)

Je n'ai pas lu cet article en détail (mais je connais déjà le sujet et le mois prochain je vais à Boston travailler avec certains des auteurs), mais c'est quasiment sûr que c'est abordé ;) dans la décomposition en graphes acycliques, il y a la quantité de travail à faire dans chaque filtre ou noeud, et justement, bien choisir quelles sont les filtres à mettre sur quels coeurs (en tenant compte des contraintes de bande passante) constitue le côté intéressant de la chose :)
Accessoirement, on peut même imaginer dupliquer certains filtres, mais ça rend le problème encore plus dur :/
Edité le 25/09/2007 à 19:28

d9pouces a écrit:
Je n'ai pas lu cet article en détail (mais je connais déjà le sujet et le mois prochain je vais à Boston travailler avec certains des auteurs), mais c'est quasiment sûr que c'est abordé ;) dans la décomposition en graphes acycliques, il y a la quantité de travail à faire dans chaque filtre ou noeud, et justement, bien choisir quelles sont les filtres à mettre sur quels coeurs (en tenant compte des contraintes de bande passante) constitue le côté intéressant de la chose :)

C'est clair que c'est un sujet passionnant... en tout cas, t'as bien de la chance de pouvoir programmer sur Cell ! Quoi que si j'en crois la news, avec un peu de chance ce sera possible pour tout le monde bientot ! :D